Jump to content

Recommended Posts

55 minutes ago, Men_of_coin said:

Don't know if this is just me, but @Hodor did you update the design of your blog?? It looks a lot more professional, and I love the new blog post as well. Always a privilege reading your blogs. Thank you!  

If you like it, then that's great news! :yess:

I'm using the new community XRP site to blog.  @wietsewind (Twitter handle, not XRPChat) creted it based on what is known as the "Ghost" platform.  Any of us can use it to publish a blog. 

 

Share this post


Link to post
Share on other sites

I always enjoy reading your posts. The quality is top notch but to be honest, I don't really get the Consensum mechanism (compared to pow).

Is it possible to do like a simple "real life" example of let's say 100 people in a room figuring out the order of transactions or something like that!?

Sorry for my non-existing tech knowledge =(

Share this post


Link to post
Share on other sites

Thanks @Hodor :D Yet another wonderful exposition of the virtues of XRP!

Have you considered bundling your blogs together as a book like "The Brilliant History of XRP"? I have a feeling there will be a LOT of interest...

Share this post


Link to post
Share on other sites
Guest

The sceptics are going to jump on the fact that you've used the abbreviation UNL without a definition.

Share this post


Link to post
Share on other sites

Since I was summoned:

Yes, the protection against a Sybil attack is the rule that validators must be explicitly trusted, aka the UNL. (This isn't a foolproof protection, since the attacker could convince you to trust several different entities which are in fact the same one, but it adds a degree of difficulty there, which is all you can really do.)

I do have a few nitpicks where the article is overly rosy about the XRP Ledger's advantages, but for the most part @Hodor is spot-on.

I wish I knew Bitcoin's proof-of-work system better, but my understanding is that you decide which transactions to include in the block while you're calculating the hashes. The hash is a hash of the block's data (plus a variable nonce). I think, in practice, this is not that different from how you described it, because an individual miner still has some control over what to put in the block before they calculate the hashes; I'm just nitpicking the description.

Another unimportant nitpick: the post implies that individual validators in the XRP Ledger consensus algorithm have no censorship power, but it's more accurate to say they have a very small amount of censorship power. They could choose to exclude particular transactions from their proposals, in defiance of the network rule that any valid transaction must be included in the next ledger provided it pays sufficient transaction cost. This would probably have a small but measurable effect on the time it takes the "censored" transactions to get into validated ledgers, since those transactions would lose slightly more "coin flips" in the cases where they were being broadcast right around the borderline between one ledger and the next. The size of this effect is inversely proportional to the number of validators, and you could detect when it was happening by analyzing the validators' proposals.

Interestingly, even non-validating "hub" servers could have a similar effect in the XRP Ledger by simply refusing to relay certain valid transactions to their peers. The size of this effect depends on how well-connected the network is and how centrally-located (in terms of peer topology) the censoring servers are. It's not likely to be big, but it is a possibility to consider. I think something similar was demonstrated for Bitcoin, where a malicious network operator could even drop Bitcoin transactions in transit to manipulate which ones get confirmed sooner. Ultimately, these are risks that are inherent to operating on a wild, lossy, potentially adversarial network.

Here's the big advantage of proof-of-work compared to the XRP Ledger's consensus algorithm: proof-of-work seamlessly¹ scales the number of participants who contribute to declaring a consensus on the next block; XRP Ledger's consensus mechanism requires hard work off-ledger to carefully choose trustworthy participants (UNL selection). That's why (as of this writing) Ripple hasn't yet recommended trusting any validators not run by Ripple. It's also the tiny nugget of truth behind the "centralized scamcoin" FUD.

Here's another advantage of consensus the article didn't really cover: Consensus has a simple and native mechanism to discount malicious actors: simply remove them from your UNLs. With proof-of-work, if there was an entity known to be attacking the network with a huge hashrate, you would have to add some sort of mechanism to blacklist proposals from those malicious entities, and everyone who's not on the blacklist would have to agree not to use the valid hashes (with probably skewed contents) that those entities were producing. It's awkward and full of pitfalls. By comparison, XRP Ledger's consensus mechanism is simple: just stop trusting anyone who proves themselves untrustworthy.

Anyway, both systems have their strengths and weaknesses, but my biggest personal preference for consensus is the electricity usage. Because it's a cooperative system, there's no need to spend excess electricity. It's not a wasteful competition to see who can flex their computational muscle the most. In a world where externalities from wasteful energy usage are one of the biggest threats to human society, I find a system that incentivizes waste to be reprehensible and scary. For those who've heard of the paperclip maximizer thought experiment, substitute "bitcoin" for "paperclip" and suddenly the idea sounds a whole lot more plausible. In fact, you don't even need to invent a single superintelligent A.I. to reach a similar end-state if human society is content to act out the same steps (in slow motion compared to super-AI timescales, probably).

In short, don't discount the effectiveness of proof-of-work, but I sure hope consensus wins out for everyone's sake.

 

¹"seamlessly" may be a bit of an overstatement when you consider the awkwardness of transaction fee variability, but it remains that many more unique, unrelated parties have contributed to the network-achieved consensus blocks of Bitcoin while only 1 entity, Ripple (Labs), has ever contributed to the XRP Ledger consensus validations. This remains my biggest complaint with the XRP Ledger and why I'm pushing so hard for us to really follow through on the decentralization plan this year.

Share this post


Link to post
Share on other sites
2 hours ago, GiddyUp said:

bundling your blogs together as a book

I've been encouraged to do something like this; Right now It seems like the volume is there, but the coherence is definitely lacking. 

Instead, It would be more likely that I'd just write a book itself on Ripple & XRP.  Did somebody say screenplay?  :D

Thanks for the positive feedback! 

Share this post


Link to post
Share on other sites
57 minutes ago, mDuo13 said:

 

I wish I knew Bitcoin's proof-of-work system better, but my understanding is that you decide which transactions to include in the block while you're calculating the hashes. The hash is a hash of the block's data (plus a variable nonce). I think, in practice, this is not that different from how you described it, because an individual miner still has some control over what to put in the block before they calculate the hashes; I'm just nitpicking the description.

 

That's right. The transactions are included in the block that is trying to be created, then the hash is found. The nonce and some other header data are changed to find a hash that is below the target value. But it is nitpicking just a bit ... the spirit the censorship argument is there.

Share this post


Link to post
Share on other sites
2 hours ago, Hodor said:

Instead, It would be more likely that I'd just write a book itself on Ripple & XRP.  Did somebody say screenplay?  :D

 

As long as you get Brad Pitt to play me, generic forum member.

 

 Me and Brad are quite similar...  We're both old!  :unsure:

Share this post


Link to post
Share on other sites
2 hours ago, mDuo13 said:

This would probably have a small but measurable effect on the time it takes the "censored" transactions to get into validated ledgers, since those transactions would lose slightly more "coin flips" in the cases where they were being broadcast right around the borderline between one ledger and the next. The size of this effect is inversely proportional to the number of validators, and you could detect when it was happening by analyzing the validators' proposals.

Which leads to a question I've wanted to ask you since you answered my questions in David's AMA in February'.

Suppose that an entity purposefully spawns a not-insignificant number of validators that all operate with a latency equal, or marginally lower than the preset bound b that's set by the RPCA''. Wouldn't that be an effective way to slow down the consensus protocol to its worst performance scenario ? I know that the limit would be tb, so it remains acceptable. That's more of a thoughts experiment than anything else.

 

2 hours ago, mDuo13 said:

¹"seamlessly" may be a bit of an overstatement

My view is that Bitcoin's PoW system is the brute-force solution to the double-spend problem. It makes sense that it was the first solution to emerge, like brute-force guessing is the first, naive solution that comes to mind for password cracking. And like it, Bitcoin's PoW nakedly marches towards its goal and will reach it, provably so. Just not on a timescale that's acceptable.

 

Anyway, thank you @Hodor for this article, and @mDuo13 for your honest outlook on PoW and RCPA.

-

': AMA with David Schwartz on r/IAMA 2/27/2018 at 12:30 pm (PST)

'': The Ripple Protocol Consensus Algorithm > 3. Ripple Consensus Algorithm > 3.4.1 Convergence

Edited by F6FNU
Rephrasing

Share this post


Link to post
Share on other sites
2 hours ago, mDuo13 said:

Oh, and another thing: we're going to be closing down the old Ripple wiki soon, so rather than linking the "Ledger Cycle" wiki page, I recommend linking https://developers.ripple.com/consensus.html

Since the new site doesn't have a similar step-wise listing (at least not at that web page), I kept the old reference, and added the new one along with it so that readers can refer down to both in the 'sources.' 

Thanks for the note @mDuo13  :thank_you2:

Edited by Hodor

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...