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. 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.
  2. 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.
  3. 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.
  4. 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!
  5. 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.
  6. 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.)
  7. 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.
  8. @tev's answer is a fantastic start to understanding where XRP fits in the world of cryptocurrency. I'll provide a little more backstory, and you can read the official Introduction to Consensus article for a bit more on how the XRP Ledger's solution works. A hash function is a type of mathematical operation. It takes an input, any number you want, and produces an output, which is a number that fits in a specific size based on the hash function. For example, SHA-512 is a hash function whose output is in the range 0 to 2^512 - 1. In other words, it always produces exactly 512 bits of output. The SHA functions are a specific kind of hash function called a cryptographic hash function, which means that it has some properties that make it useful for cryptography. Among those properties is that the hash function must be "one-way": you can't convert the output back to the input without doing an insane amount of "guess-and-check" work. Another property is that changing the input even just a little bit (usually) results in a very different output. Together, along with some other stuff, these properties are useful in a variety of ways, one of which is... Bitcoin Mining One of the most central ways the Bitcoin network uses them (same with Bitcoin clones like Litecoin, etc.) is for mining: Lump a set of transactions together. Represent those transactions as data—in other words, as a very big number. Feed that number into a hash function. The output is a "hash of that block". Any other set of transactions, even slightly different will have a very different hash. That's not enough to do mining, though. The central idea of mining is that you can make people compete to come up with a hash output that has specific properties, and whoever wins will be pretty random as long as no one has way more computing power than everyone else. "Proof of Work" mining uses that to advance the "official" state of the network without relying on anyone in particular. It goes something like this: Set a goal. The Bitcoin network has a rule that says, "We're looking for a hash of this data that begins with some number of zeroes," with the number of zeroes being adjusted based on how long it took last time. Lump a bunch of potential transactions together, along with the "hash" of the previous block (with some placeholder value like 0 for the very first block) and a "nonce" which is basically a place where you can write any number you like. Represent the transactions, previous block hash, and nonce as data—again, just a big number. Let people try calculating all the hash outputs they can, adjusting the nonce and the set of transactions however they like so the inputs are slightly different. When someone comes up with a set whose hash matches the goal, they win. That set of transactions becomes the next official block. As a reward, whoever figured out the exact inputs that made that hash gets to keep all the transaction fees in that block along with some extra Bitcoins that are made up from thin air. (The number of Bitcoins created from thin air decreases over time.) Start over from step 1 for the next block. The total rate at which people worldwide are taking guessing as to a set of inputs that might result in the a hash matching the goal and testing them is called the global "hashrate". Since it's possible multiple people may figure out a hash around the same time (step 4), and different parts of the Bitcoin network may hear about one before the other, what matters most is which one people use in their inputs to the next block; if there's any doubt, the rule is you choose whichever block is first to have another winner using its hash in the inputs. That's what Bitcoiners mean when they talk about "multiple confirmations" and "longest chain". The thinking behind why this is secure comes from the fact that literally anyone can try their (computer's) hand at mining and have a chance to win, then they've chosen which transactions to include in the block. If some entities have a problem with you and don't want your transaction to happen, they can leave it out of their inputs... but others who are also mining probably won't care, so they'll include your transaction in their attempts. So the likelihood of your transaction making into the very next block is equal to the percentage of total computing power that belongs to people who're OK with your transaction, and the likelihood that you'll get into some block in the next several is much higher. That's also why one entity having more computing power than everyone else is a problem: they can make whatever block they want, and then make another block using it as a base, making their chain longer than the one that everyone else combined was working on, so they get to dictate what happens. They could even double-spend, by doing something like this: Send a Bitcoin transaction to buy, say, a delicious hamburger. Wait for the transaction to be confirmed with enough blocks in the chain after it that the burger place thinks it's final. Receive and eat a delicious burger. Find the block right before the one with the transaction that paid for the burger. Go back and calculate a bunch of new blocks based on this one that don't include your burger-buying transaction. (This is called a "fork", although there are other ways to fork, too.) Keep at it until you surpass the rest of the network's attempts at continuing the chain that has your burger-buying transaction. Now the network's longest chain is the fork that doesn't have your burger-buying transaction. The network says, "Well, that one's the longest, so it's now the official history" and the part where you paid for your burger has been retconned out of history. But by this point you've probably left the burger joint behind, quite satisfied and they'll never find you again. Later on, you can spend those same Bitcoins you used on the burgers to buy something else. That's the "51% attack" (actually a "50% + 1 attack" because, say, 50.000001% is technically enough) and why mining concentration allows double-spends. XRP Ledger and Hashes In the XRP Ledger, "ledger versions" fulfill a similar role to blocks of Bitcoin transactions, but there's no mining. The XRP Ledger doesn't care about hashrate or number of confirmations. It doesn't let literally anyone take a turn at calculating the official hash. But it does have an official hash. In fact, one of the most important ways the XRP Ledger's uses hashes is to calculate an official hash of a ledger version, which looks a lot like the incomplete process I used to describe mining above: Lump a set of transactions together. Represent those transactions as data—in other words, as a very big number. Add some more data, like roughly what time it is, what number ledger version this is, and what the outcome of all transactions so far is. This gives you another big number. Feed that number into a hash function. The output is a "hash of that ledger version". Any other set of transactions and other data, even slightly different, will have a very different hash. If you have a set of transactions and outcomes that result in a specific hash output, then you know for sure that anyone else whose data results in the same hash output as yours must have the same inputs. That's really convenient because it means you can have a whole lot of computers stay in sync with exactly the same data without having to constantly send the entire huge amount of data back and forth. You just send the hash outputs back and forth to confirm you're in sync, and if you're not, then you ask for a little bit more data until you end up in the right place. The consensus process is a fair bit different from mining. You can read all about it in other places, but basically, when you run a rippled server, you have a set of specific someones you want to agree on a block, and if they do agree, you call that block official. We call these specific someones "trusted validators" and we call the full list of them your UNL. To have a network that everyone agrees on, you need to have pretty similar UNLs, so that's why Ripple has a "recommended UNL". You can see a nice visualization of the recommended UNL at this unofficial site: https://xrpledger.info/ Oh, and I forgot to mention... Don't Worry About Hashcash "Hashcash" is the name for a technology that's basically a predecessor of Bitcoin, originally intended to help block spam emails. But really all you should need to know about hashcash is that Bitcoin took inspiration from Hashcash for the design of Bitcoin'sproof-of-work mining. Anyway, I hope this was educational and helps explain some of the mumbo-jumbo that goes on in this space.
  9. Can confirm, Arthur is not in any of the PolySign office photos on Glassdoor. Can also confirm, the "South Park"-esque avatar he uses is a fairly accurate (if stylized) depiction of what he looks like IRL.
  10. Destination tag 111111 doesn't mean anything by itself. Only the sender and the intended recipient could potentially know what it means. I've no idea who rNfRpqwq27b2xCBSNf7BzuZrmmbkc5bZr2 is so unless they volunteer themselves, I don't think you'll get an answer to this question.
  11. mDuo13

    Could XRP fork?

    I think there are quite a few others out there historically who took the rippled source code and tried to start another distributed ledger chain from it. The vast majority of them have died off. But in general, forking the XRP Ledger requires creating a "clique" of validators who all agree with and trust one another and don't trust outsiders (beyond a small percent). So it's quite easy to start down that path but actually convincing others to care about your fork is a different story.
  12. Right, the docs aren't wrong but they could be more explicit. PR opened to fix that here: https://github.com/ripple/ripple-dev-portal/pull/478
  13. Yes, those 20 would take your validations into account. If that results in your friends' UNLs being less than 90% similar to the "official" UNL, then they could (in the worst case scenario) fork away from everyone who's using only the official UNL. This paper describes the math and circumstances behind that: https://arxiv.org/abs/1802.07242; it requires some pretty extreme misbehavior and network delays for that to happen but it's possible. There would be no official trusted UNL, so the community/ecosystem would have to manage the "official" UNL. That's more or less it. Ripple will contact you before adding your UNL to the recommended list, to confirm that you have sensible policies and are properly invested in being a stable validator for the long term. If more than 20% of trusted validators disagree on the final ledger, then there is no final ledger. No progress can be made until something changes. You can call that a "crash" if you want. It doesn't mean the network is offline (you can still look up existing, finalized history and submit transactions for consideration), but it does mean no progress is made while there's a disagreement. Either the trusted validators change their positions, or the list of trusted validators changes (adding or removing) until there's consistency again. That process of changing the UNL is not automatic. Someone has to make a change—either Ripple can change the recommended UNL served by the site, or people running rippled servers can stop using Ripple's recommended UNL site and manually configure their UNLs instead. For some more discussion of this, see here: https://developers.ripple.com/consensus-protections.html#individual-validators-misbehaving
  14. The amount of an issued currency can increase or decrease. It's not guaranteed that the amount remains stable. If you abuse how rounding works, it's even possible to create more of an issued currency without the issuer making more, but the amount you can create per transaction is something like 15 orders of magnitude smaller than the amount held by the account whose transactions create it. So that would be a losing proposition unless your issued currency is worth something like 10,000,000,000,000,000 times more than XRP. XRP is not an issued currency. The total supply of XRP can only decrease, and only by the exact amount destroyed by the transaction cost (the "Fee" parameter of a transaction). There's an invariant check that guarantees this.
  15. When we say issued currencies have "15 decimal digits of precision" what we mean is that it uses decimal math (no floating point rounding weirdness) and at most 15 continuous digits of the issued currency can be nonzero values, regardless of where the decimal point is. So you can have 1.23456789012345, or 999999999999999 or 0.00000000000000123456789012345 but not 100000000.0000001. If you make a payment that is outside the precision of an issued currency, the remainder is rounded. In your example of someone who has 10000000 FOO and you send them .00000001 FOO, your balance will decrease but theirs won't increase. This was a conscious choice when the system was created. To paraphrase @JoelKatz, "If you have a trillion dollars and I pay you two hundredths of a cent, are you even going to notice? But you still have to consider the payment made since I spent my 2/100 cents."