Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank

Profile Information

  • Gender
    Not Telling
  • Ripple Address
  1. First question: You can do it with ripple-lib or software built on top of it that is capable. You would use a settings transaction to set the regular key pair (providing its address in the regularKey field), then send just about any transaction you want using the regular key just to confirm it works (if you've got nothing better to do, you can send a "settings" transaction with no arguments), then use a second settings transaction to disable the master key pair. That last transaction to disable the master key pair has to be signed using the master key. Second question: It sounds like the version you use uses deterministic nonces, so I think you are OK. But I'm not a cryptographer, so, uh... please don't hold me liable if I'm wrong. If you're not sure, it's safer to rotate the keys.
  2. mDuo13

    Galgitron's new blog: Proof of Not Working

    Over the years I've been really impressed that Proof of Work actually worked and continued working. I mean, I hate how incredibly wasteful it is, but I had to respect the fact that it was a real thing. But 2018 was a real wake-up call to the fact that 51% attacks were not just for obscure joke coins. Galgitron makes a convincing case that proof of work as a whole is doomed. That's both interesting and scary.
  3. RFC6979 wasn't even published until Aug 2013, which is after the XRP Ledger was created. It's certainly likely that some software that's been around since the beginning uses random nonces instead of deterministic nonces, which is still secure as long as they're truly random. If they're less random, that's a problem. It is my understanding that prior to around August/July 2015, the rippled server used OpenSSL instead of libsecp256k1 for signatures. The OpenSSL implementation does not (did not at the time?) use deterministic nonces, but rather uses random nonces. As long as the source of randomness was strong enough (depends on your system, but probably yes) then you're probably OK. I dug into the history of ripple-lib and couldn't find anything one way or the other on the signing implementation prior to around July/August 2015. It's hard to say whether someone is actually affected, though, even knowing what code they used to generate their signatures. Most people won't be affected unless they made a lot of signatures with questionable software... but it's a sliding scale—the less random your nonces, the fewer signatures it takes to figure out your private key. The extreme case is if you reuse the exact same nonce it only takes just two signatures. Incidentally, this is the exact mistake Sony made with the PS3 back in like 2011. They used the exact same nonce on every signature... oops. Long story short, it's not a bad precaution to rotate your keys anyway. BTW, credit for actually writing the article goes mostly to @nikb. I just proofread and posted it.
  4. I personally don't know what performance benefits it's expected to have. Presumably some; I think it reduces the space required to store a lot of the ledger? The problem is that switching over after enabling it would require a long downtime as every server re-calculates the V2 version of the ledger. If I'm recalling correctly, it also affects backwards compatibility of data. That's why it's commented out in the codebase right now—Ripple doesn't want it to get enabled by accident. Honestly, the downsides may outweigh the upsides now, given the extent to which people already rely on the XRP Ledger for actual business 24/7.
  5. mDuo13


    Counterpoint: If, during that amount of time, you realize that an attacker has gained control of your destination account and changed the key, you have that much time to take legal action to regain control of the account. Assuming the attacker doesn't blackhole the account (changing it to a key they don't know) you may have a while for the legal gears of justice to grind and return control of the account to you.
  6. Salutations! We've published new documentation to the XRP Ledger Dev Portal! These changes include: List Your Exchange on XRP Charts - New guide for exchanges that want to see their volume show up on XRP Charts. https://developers.ripple.com/list-your-exchange-on-xrp-charts.html Ledger History - Explainer for the history that servers store and the options that exist around this. https://developers.ripple.com/ledger-history.html Online Deletion - Info on why and how the online deletion feature of `rippled` works. https://developers.ripple.com/online-deletion.html Plus, no less than three new tutorials around ledger history and deletion: Configure Online Deletion: https://developers.ripple.com/configure-online-deletion.html Configure Advisory Deletion: https://developers.ripple.com/configure-advisory-deletion.html Configure Full History: https://developers.ripple.com/configure-full-history.html As always, we welcome feedback and contributions. If these docs helped you, or if you need help figuring them out, we'd love to hear from you!
  7. mDuo13

    noripple flag

    Yeah, that's a trap. If someone opens a trust line to you, NoRipple gets enabled on your side of the trustline (if you haven't changed your DefaultRipple setting). But if you open a trust line to someone else, you have to use the tfSetNoRipple flag or your side of the trust line doesn't enable NoRipple. (That is, rippling is enabled.) It's super confusing and I think it should be changed. It's a transaction processing change, so it would have to be an amendment. I also think a more elegant solution would be to remove NoRipple and simply follow the DefaultRipple settings in all cases. I think there are basically no situations where setting the NoRipple setting individually on trust lines gets you what you want, and having to do that leaves a lot of gotchas (this one included).
  8. If financial institutions decide to pass their savings onto customers, then the XRP ecosystem and Ripple in particular will have achieved a great thing, especially for those who're sending home remittances with small incomes. If they don't pass on their savings, then we're not done until we find a competitor who will. If enough entrants in the market are able to reduce their costs, eventually someone will want to gain market share by undercutting their competitors. I don't think Ripple is offering exclusivity agreements for this tech and that's why.
  9. On a personal level, I think a small, predictable amount of inflation is good for a currency. On a professional level, Ripple has staked a lot on XRP having a fixed supply, so I wouldn't expect that to change.
  10. mDuo13

    New docs on binary format

    Not quite. Next up are some docs on managing online delete and ledger history. Also on my short list is actually signing transactions, and potentially deserialization. But validation manifests are a good thing to doc also. Thanks for sharing the Go sample from rubblelabs. That's useful. I may add a link from the docs, too.
  11. Hey, XRP 2 has already been created and it's owned by Ripple. (I'm joking, but also kind of telling the truth, because "XRP II, Inc." is a wholly owned subsidiary that manages Ripple's XRP assets.) I do think that the decentralization of the XRP Ledger's validators this year has prompted some of the most introspection in cryptocurrency and decentralization on a conceptual level that we've had since the earliest days. It really makes you wonder, "What is decentralization?" and more importantly, "What's the point of decentralization?" Like this post: It's all about the power structure. Who has the power to make the rules? Who has to follow? I've been thinking yesterday that achieving consensus in a blockchain is a good start but ultimately it's an incomplete solution. If you can't recognize when everyone agrees, then you can't do much in the way of business and trade. A consensus algorithm—whether proof of work, XRP Ledger consensus, or otherwise—handles this case. But the world changes, people change, so your actual consensus doesn't last forever. What happens when you can't agree? One possibility is tyranny of the majority. Whichever group is slightly larger or has slightly more (mining/political/whatever) power gets to dictate the rules, and everyone else can either abide or do no business. Another possibility is incompatible forks. As @jcdenton puts it, "If you hate puppies, you're not my friend anymore." We've already seen this happen in Bitcoin more than once as the block size wars and whatnot have gone on. Over time the number of forks is bound to increase as people realize some of their wants and needs are mutually incompatible. Sadly, proof-of-work requires that any fork have sufficient size or it's vulnerable to manipulation and attack by individuals or small organizations. Ironically, XRP Ledger consensus makes it safe to maintain forks of much smaller size... but for whatever reason the Stellar debacle is the only time the XRP ecosystem has really seen the need to fracture (and really a lot of that is just Jed wanting to do things his way)... yet. I think it's inevitable that if XRP stays around and grows, a hard-fork between incompatible visions for the technology will happen someday, just like it will for any other coin of sufficient size. Did you think I was going to end this post on that bleak note? Nah, because there's at least one other visionary who reached a similar conclusion and said, "Well, the problem is really that all the ledgers are incompatible with each other" and invented a compatibility layer to link them all. So after people finally stop trying to get everyone to agree to the same thing, then move on from not talking to each other, they're finally able to agree to disagree and still do business. Whatever the future is for the crypto ecosystem, the larger money supply has to be interconnected to be useful.
  12. For the first time, we have pretty detailed documentation describing the binary format of transactions and how to convert transactions from their JSON format to the binary format: https://developers.ripple.com/serialization.html These docs come with functional Python code (by yours truly) implementing all of the steps so you can see how the serialization works exactly. Which is good, because this stuff is waaaaay deep in the nitty-gritty of how the protocol works. This isn't quite enough to implement offline signing in the language of your choice, since you still have to know how to make a deterministic 256-bit key from a 128-bit XRP Ledger seed value, plus you'll need an actual implementation of the signature algorithm (whether ECDSA w/ secp256k1, or Ed25519), but it's a major first step in opening the door to more client libraries (hopefully implemented by parties other than Ripple?) in various programming languages, lowering the barrier to entry for more developers who might be interested in using the XRP Ledger. Let me know if these docs are useful to you or if you have trouble understanding. I'd be happy to clarify what I can!
  13. This is true of like 90% of ideas people have for blockchains and the fact that Ripple's leaders have realized this from the beginning is a big part of why I think Ripple is a smart company.
  14. mDuo13

    Execute multiple transactions atomically

    Correct, atomic "composed transactions" are one of the biggest "feature advantages" Stellar has but the XRP Ledger doesn't. In the XRP Ledger, the AccountTxnID field will let you guarantee that a second transaction executes only if a specific previous transaction executes, but it doesn't guarantee you that the second transaction will execute. So if you're looking for guaranteeing transaction P and transaction Q both happen in that order, you can rule out Q happening by itself but you can't rule out P happening by itself. And, in most cases, you don't even need to use AccountTxnID to do that because the Sequence number already guarantees that the transaction with Sequence N+1 won't execute unless the transaction with Sequence N has already executed. The only case you need AccountTxnID is if you have two systems both capable of signing transactions to one account and you want to make sure that they don't both send the same transactions. (If you have, say, a hot wallet that automatically signs transactions, and a hot backup server to the one running your hot wallet, and they get netsplit so the backup thinks the primary is offline but the primary is still working, you could end up with two servers both trying to send equivalent transactions even if you didn't mean to. That's the fairly niche situation AccountTxnID is meant to avoid.)
  15. If someone controls >80% of trusted validators, that party is in full control of the network. Others who follow along and trust them will do so as long as the transactions they send are not in contradiction with the rules of the network as the other servers understand them. If you connect to the network and have no history stored at all, you have to take your trusted validators' word for what the state and history of the network are. You would have no way of knowing if the state those validators are telling you about is contradictory with the state that the network was following yesterday. But you could change your configuration to trust a different set of validators who you think are more honest. If you are running a server and it has any history at all, then it enforces the rules it knows and the history it has. It won't approve of new transactions that don't follow the rules of the network as it knows them. If the trusted validators are using some different rules (i.e. new transaction types or fields, or just processing things incorrectly) your server will stop making progress in declaring ledgers validated because the new ones don't make sense to it. I think there may be some exceptions, so that your server will correctly jump chains if you reconfigure it to use a set of validators who're currently on a history that's incompatible with the history your server was previously on, but I'm not totally sure where the boundaries are.