T8493

Member
  • Content count

    1,271
  • Joined

  • Last visited

  • Days Won

    9

Reputation Activity

  1. T8493 liked a post in a topic by theshadow in XRP Wallet with SusPay?   
    Yeah, thats correct,
  2. T8493 liked a post in a topic by cmbartley in Golem now listed on Poloniex   
    Decentralized computing. You sell your computer's ability to perform computational work similar to how StorJ sells excess storage space.
  3. T8493 liked a post in a topic by kanaas in That official forum is completely useless   
    Just an idea .... Why not create the first XRP payable forum? You wanna join the club? Than you got to get you some XRP and do a micropayment for each posting. Reading is free of course .... It would be AND inventive AND another incentive to go after some XRP....
  4. T8493 liked a post in a topic by tch0 in Important Announcement: Zerocoin implementation bug   
    https://zcoin.io/language/en/important-announcement-zerocoin-implementation-bug/
    Important Announcement: Zerocoin implementation bug
    By Reuben Yap February 17, 2017
    Yesterday, our team found a bug in our implementation of Zerocoin. A typographical error on a single additional character in code allowed an attacker to create Zerocoin spend transactions without a corresponding mint. We have identified the error and are pushing the fix urgently within the next 24 hours. We urge all pools and exchanges to update once the release is out.
    From what we can see, the attacker (or attackers) is very sophisticated and from our investigations, he (or she) did many things to camouflage his tracks through the generation of lots of exchange accounts and carefully spread out deposits and withdrawals over several weeks. We estimate the attacker has created about 370,000 Zcoins which has been almost completely sold except for about 20,000+ Zcoin and absorbed on the market with a profit of around 410 BTC. In other words, the damage has already been mostly absorbed by the markets.
    To clarify a few things:
    The exploit happened due to the bug in the code and not from any weakness in the cryptography. The bug  from the typo error allowed the attacker to reuse his existing valid proofs to generate additional Zerocoin spend transactions.
    The anonymity of Zerocoin has not been compromised. We knew we were being attacked when we saw that the total mint transactions did not match up with the total spend transactions. If our total supply was not verifiable due to hidden amount transactions, we would not have been able to discover this bug.
    Despite the severity of the hack, we will not be forfeiting or blacklisting any coins. Trading will resume once pools and exchanges have had time to update their code. A new release will be pushed out pretty soon.
    Prior to this announcement we had disclosed the hack to the exchanges for them to assist in our investigations. We thank you for understanding and apologize for the silence today as we had to make sure we had all the relevant facts before making a statement on the same.
    We would also like to thank everyone who has assisted on this matter and will be posting further details in a later post.
  5. mDuo13 liked a post in a topic by T8493 in Encryption vs Quantum Computing   
    Ed25519 won't necessarily help you in this case:
    Ed25519 uses one specific elliptic curve and the length of its keys is fixed (you cannot choose longer keys as you can with e.g. ECDSA or EdDSA in general). If ECDLP can be solved quickly (on relatively general curves), then maybe both ECDSA and Ed25519 can be considered broken (the same attack on ECDLP could break both Ed25519 and ECDSA). Regarding P=NP.
    If P=NP, this doesn't automatically imply that the current cryptography is practically broken. If someone finds the polynomial algorithm with the running time O(n^10000) for some NP-complete problem (e.g. SAT), then this algorithm is pretty much useless for all practical purposes. 
    Integer factorization is not known to be a NP complete problem, but the cryptographic algorithms still rely on it.....
     
     
     
  6. T8493 liked a post in a topic by nikb in New Video Explaining Xrp as a Scam   
    I'm not going to address all the points exhaustively, one by one, but let me respond to a couple of them really quickly.
    This is a flat out lie. Our version-setting commits (in other ways, the tip of each repo) are all signed by rippled developers. Anyone downloading the code can verify that what they downloaded has not been tampered. See: https://github.com/ripple/rippled/commits/0.50.0
    Additionally, our release announcements (served over https) link to RPM packages that are signed by Ripple and cannot be tampered (and yes, the built process verifies that the code it builds from is signed by an approved developer key) and the md5sum of the rpms and the commit id at the tip of master is included in the announcement text as well. See: https://ripple.com/dev-blog/rippled-0-50-0/
     
    This is just plain silly. The caliber of people at Ripple is top notch, and the code we produce is a testament to that.
     
     
    Huh? What does the ripple website have to do with anything?
     
    Surely if they're that frequent, it should be no trouble at all to point to such changes in core consensus code.
     
    I'm not sure how to take this "criticism"... of course if an amendment is proposed and the network, collectively, accepts it, then nodes that veto it or don't support it can't continue to process transactions and become amendment blocked. What else could possibly be done? 
     
    "I CAN HAZ MOAR NONSENSE"
  7. T8493 liked a post in a topic by RafOlP in New Video Explaining Xrp as a Scam   
    After reading this and the news about the Japan guy, it looks like the scum of the bitcoin community is trying to fight XRP after laughing at it. It reminds me of a commonly used phrase...
  8. T8493 liked a post in a topic by JoelKatz in New Video Explaining Xrp as a Scam   
    I've only looked at the pictures. Watching the video would be an hour and a half of my life that I'd never get back. But I do have to say, in all fairness, the diagram in the picture does look quite a bit like the call dependency graph of the first working version of rippled. Actually, it kind of looks like the git branching too (see image).
     
    Fortunately, I learned to laugh at myself at an early age. I learned by observation -- everybody else was doing it.

  9. T8493 liked a post in a topic by cmbartley in Ledger Wallet Support for XRP   
    Agreed, I've been asking them to add xrp support.
  10. Rchopra liked a post in a topic by T8493 in Using the Exchange page to buy XRP's on GateHub Wallet   
    Because of the low liquidity (you can't buy large amounts of XRPs at the price X because not enough sellers are prepared to sell you XRPs at the price X).
     
  11. T8493 liked a post in a topic by Sukrim in Ripple Historical Database   
    Personal interest.
    I still want to be able to use cash or something equivalent when I retire. Cryptocurrencies and P2P exchanges like Ripple currently seem to be one of the few options out there to actually have something cash-like on the internet. Also I like to understand stuff as deeply as possible and at a certain point you need to start re-implementing things yourself to progress in your understanding.
  12. T8493 liked a post in a topic by Xi195 in GSR will be back   
     
    @jn_r noticed in the topic at the bottom of this post that GSR Markets (www.gsr.io) had stopped trading on RCL 1/5/17. They were responsible for a large portion of the volume on RCL up until that point.
    I sent an inquiry to them regarding their lack of activity on the ledger. They were gracious enough to provide the following response.
    This was their address creating most of the volume: rGSRqpUQAschCY5rdoRAXnnCvoGpq5toZ1
    The original topic was here: 
     
     
  13. Kakoyla liked a post in a topic by T8493 in Encryption vs Quantum Computing   
    There was a similar topic that covered digital signatures:
     
  14. T8493 liked a post in a topic by Sukrim in Ripple Historical Database   
    I concern myself mostly with rippled's database/back end, not this stuff. The only thing that is related to rippled with this project is that it has rippled in its name and will query a rippled server for data, which hopefully is correct (as it doesn't seem to actually verify any hashes or SHAmaps).
    My interest is rather in providing (full) historic data that you can import in rippled directly, so you can feed this database project with your own local server for example. Currently this is a bit on the back burner, since I've started working a little bit on fuzzing rippled which also has its challenges, especially with that little insight what they are actually doing/planning in their hidden issue tracker. There doesn't seem to be that much interest in running archiving nodes anyways, and they are not cheap to run either.
  15. T8493 liked a post in a topic by xtrapower in Why we haven't seen the MM Incentive   
    Good observation, thanks. If you put all the pieces together it seems that your conclusion is right. Bitstamp explicitly says that they are benefiting from the XRP incentive programm. But how exactly? Did they receive XRP as compensation? And i strongly believe that this is not the whole programm. Bid and Ask side liquidity must be incentiviced. 
  16. ElMoskito liked a post in a topic by T8493 in Example of code for pseudo circular payments   
    But is there any guarantee
    - that these two transactions will be included in the same closed ledger AND
    - that both transactions either succeed or fail.
    I would say that the answer is no.
    The first guarantee is probably possible if you use LastLedgerSequence with the index of the next ledger, but there is no guarantee that both transactions will  succeed.
     
     
     
  17. T8493 liked a post in a topic by Sukrim in Example of code for pseudo circular payments   
    Well, donch also wrote his own implementation of rippled, so he might have some custom path finding extensions there.
    In theory finding profitable circles is not that difficult, you just need a starting point (e.g. a certain amount of XRP), then calculate the amount of every currency you would be able to buy for that starting amount and so on. Once you reach the initial currency again, you see if you end up with more than you started. Alternatively, if you reach a different currency, you check if you would get more of that currency with your current path or the already existing one and keep moving forward with the more profitable one.
    The only problem is the time complexity of such an algorithm (and the fact that others will also run this), so you need to be fast and maybe only update the parts of your path network that change after each transaction that you observe or each ledger that is closed.
    To make a circular payment, you'd just create a path that ends at your starting point and set the appropriate flag in the transaction. Since this flag is not (yet?) implemented, you arbitrarily cut your path in half and submit the resulting 2 transactions. You could even cut it into more pieces, however it just increases cost (fees) and risk (maybe someone also takes an offer that you rely on), so cutting in 2 is the most reasonable choice. Most likely you'll either want to split very early or very late and not at half the path, so you can make sure that most of your transaction path happens atomically. Early might have the advantage that others can't react yet since they don't see where you want to go, splitting late might have the advantage that you initially get as far along the path as currently possible.
    Still circular paths are useful and would help quite a bit in making sure RCL stays profitable and offers get taken as much as possible.
  18. ElMoskito liked a post in a topic by T8493 in Example of code for pseudo circular payments   
    RippleAPI documentation is actually very well documented and it contains a lot of code samples. Have you looked at https://ripple.com/build/rippleapi/ ?
     
     
  19. papa liked a post in a topic by T8493 in Example of code for pseudo circular payments   
    Sorry, I understood your comment on github about "path split" as it would refer to one transaction on which at some point at its payment path the payment path splits and continues in two different directions (and one of the directions goes back to the starting account) - this is not possible AFAIK, but I thought that there was some kind of a loophole.
    I didn't understand that you meant "cutting" the payment path.
     
     
     
  20. T8493 liked a post in a topic by corak in B4 you give up on Ripple or XRP ask urself the Question...   
    I think at this point the open market for XRP is just a distraction, it's moving a few ten thousand USDs a day, less than the daily volume in an average OTC penny stock. The market for XRP, as far as it even has one, is made of private buyers (FIs / MMs) and private sellers (Ripple mostly). I don't think we can vote the price anywhere with our transactions. It's just small potatoes. This entire forum probably has 1/1000 of the total float combined at best, and most are just long term holding.
  21. T8493 liked a post in a topic by Haydentiff in Ripple is hiring   
    You found your way here. We're a small group because the barrier to entry is high-level thinking.
  22. papa liked a post in a topic by T8493 in Example of code for pseudo circular payments   
    Sorry, I understood your comment on github about "path split" as it would refer to one transaction on which at some point at its payment path the payment path splits and continues in two different directions (and one of the directions goes back to the starting account) - this is not possible AFAIK, but I thought that there was some kind of a loophole.
    I didn't understand that you meant "cutting" the payment path.
     
     
     
  23. rippleric liked a post in a topic by T8493 in Quantum Computer Blueprint - impact on RCL/ILP?   
    Sure, but Discrete Logarithm Problem can relatively easy use different (larger) (sub)groups.
    I've read somewhere - but don't take my words for granted, especially because I can't find the exact source right now - that solving DLP in the group of points on an elliptic curve can be relatively easy made much harder for quantum computers.
    One of the reasons was that ECDSA key lengths are currently very short compared to RSA and one can relatively easy use much longer keys without greatly affecting parameters like power consumption, storage requirements, etc. However, this depends on specific applications.
    So even if someone can build this $125 million quantum computer that can break RSA in 14 days that article doesn't directly imply that this computer will be able to solve DLP (in larger (sub)group) in the similar amount of time (and not - for example - in years which makes it pointless).
    Basically, as an interim solution (until NSA comes up with quantum-computer-resistant cryptographic schemes), one can just increase key lengths in ECDSA and make it temporarily unsusceptible to attacks by quantum computers. Increasing key lengths in RSA is less trivial because key lengths are already very long (compared to ECDSA) and you can more easily hit technical limitations of devices (memory, bandwidth, etc.).
    Look also at this statement in the article:
    But they just assume (without proof) that it would be possible to perform 2048-bit number factorization in 10 days.
     
    I really wouldn't worry about this at least not for the several years and especially not for the "low-value" (compared to the cost of building this computer) transactions.
    Maybe @JoelKatz can shed some additional light on this problem, but I guess that there is nothing that Ripple Labs can do about this future problem right now (except that they follow the development of quantum computing and wait for the NSA to come up with something).
    EDIT: This quote from Wikipedia is also in line with my prior reasoning:
    https://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths
  24. Professor Hantzen liked a post in a topic by T8493 in Quantum Computer Blueprint - impact on RCL/ILP?   
    But if they planted some kind of backdoor, then even 2048-bit keys may not help you....
     
  25. T8493 liked a post in a topic by karlos in Leaderboard incorrect?   
    Since the leaderboard was added, I noticed I'm only 14th on the list! This will just not do.

     
    I'd like to point out that people seem to like me because I am polite and rarely late. I like to eat ice cream and I really enjoy a nice pair of slacks. For every like this post gets, I will pet my dog and tell him he is a good boy.
    p.s Like this post.