Jump to content
JoelKatz

An update on Ripple's XRP escrow

Recommended Posts

Just now, Odiseo said:

The escrow itself was not a contract or a service involving someone else, it's Ripple's assets and they don't need to inform the world what they do with it, they did communicate it for PR and marketing.

That really doesn't make sense.  Their latest 'gift' if you will, to the market, is the notion of the lockup.  The execution failed, and therefore they didn't deliver, but billions of dollars were already infused because of the belief the gift was real.  Trust me, it doesn't matter what Ripple did to fix it, it's the failure that FIs may focus on.

Before anyone else places me in the alarmist camp, the scope of my rants are limited to just this thread, as such, I'm not a force that could bring down the house of cards if you will.  Don't be afraid to consider and discuss the potential fallout in intelligent discourse.  I know everyone wants to dampen the fire, but we're on the porch, and the kitchen is where the flames are so it doesn't really matter what anyone says here.   Sweeping it under the rug as a non-issue simply because the fix was simple is just plain ignorant. 

Share this post


Link to post
Share on other sites
Guest
4 minutes ago, JA8 said:

Can't believe this thread is 7 pages long. It's a complete non-issue. Thanks Joel Katz for the transparency though.

We're master debaters. 

Share this post


Link to post
Share on other sites
6 minutes ago, galgitron said:

Sweeping it under the rug as a non-issue simply because the fix was simple is just plain ignorant. 

A very minor issue then. The story here is that Ripple is entirely transparent and has a commitment to get things right. The story is not that humans are fallible and occasionally make mistakes. Every knew that already. 

Share this post


Link to post
Share on other sites
1 minute ago, JA8 said:

A very minor issue then. The story here is that Ripple is entirely transparent and has a commitment to get things right. The story is not that humans are fallible and occasionally make mistakes. Every knew that already. 

Completely agree, in my mind, this was not a big deal.  I deal with bugs in my software all the time and the fix was luckily easy.  My managers however, lose sleep when these bugs crop up (I write trading software), and the wrong bug in the wrong place can cost millions of dollars.  To us down here on Earth, the escrow bug was just a misshapen cloud in the sky.  To FIs, the escrow bug indicates a fly in the ointment and portends to other potential flies.  As inconsequential as one fly may be, the FIs might say, wellllll, maybe we'll just wait a bit to see what happens...

Share this post


Link to post
Share on other sites
Guest
5 minutes ago, JA8 said:

A very minor issue then. The story here is that Ripple is entirely transparent and has a commitment to get things right. The story is not that humans are fallible and occasionally make mistakes. Every knew that already. 

Props on the Newton pic: "It is plain to me by the fountain I draw from, though I will not undertake to prove it to others."

Share this post


Link to post
Share on other sites
5 minutes ago, galgitron said:

Completely agree, in my mind, this was not a big deal.  I deal with bugs in my software all the time and the fix was luckily easy.  My managers however, lose sleep when these bugs crop up (I write trading software), and the wrong bug in the wrong place can cost millions of dollars.  To us down here on Earth, the escrow bug was just a misshapen cloud in the sky.  To FIs, the escrow bug indicates a fly in the ointment and portends to other potential flies.  As inconsequential as one fly may be, the FIs might say, wellllll, maybe we'll just wait a bit to see what happens...

The escrow fail was not a bug. It was incorrect operation of their own software. There is a difference. I make operational mistakes using software I wrote myself all the damn time.

This one just happened to botch a set of transactions involving 55B XRP. 

Is it a clowntown? yes.

Unreasonable to make such a mistake given the stakes involved? also yes.

But it is not a bug.

Share this post


Link to post
Share on other sites
2 minutes ago, corak said:

The escrow fail was not a bug. It was incorrect operation of their own software. There is a difference. I make operational mistakes using software I wrote myself all the damn time.

This one just happened to botch a set of transactions involving 55B XRP. 

Is it a clowntown? yes.

Unreasonable to make such a mistake given the stakes involved? also yes.

But it is not a bug.

@JoelKatz said, "we discovered a defect in the implementation that could cause XRP to be released from escrow prior to the intended release dates. While no funds were at risk, we wanted to correct the defect to ensure the implementation is airtight. ".  This doesn't preclude the possibility that the specs don't line up with the logic.  I'd wait until further clarification before deciding the nature of this issue.  I also find it funny that this completely irrelevant distinction is worth making a point about, yet Ripple's possible reputation fallout is a non-issue, lol.  Anyways, I'm really curious what Ripple is going to do next.

As a thought experiment, how many of you out there can justify the 'non-issue' stance when transmulgated into my mechanic analogy?  Would you go back to the mechanic if he forgot to put 4 lug nuts on your wheel even though he fixed it and no harm came from it?  How well does the analogy hold if you are the FI customer and the mechanic is Ripple.

Share this post


Link to post
Share on other sites
Guest
3 minutes ago, galgitron said:

@JoelKatzAs a thought experiment, how many of you out there can justify the 'non-issue' stance when transmulgated into my mechanic analogy?  Would you go back to the mechanic if he forgot to put 4 lug nuts on your wheel even though he fixed it and no harm came from it?  How well does the analogy hold if you are the FI customer and the mechanic is Ripple.

I can... ;)

Share this post


Link to post
Share on other sites
4 minutes ago, galgitron said:

@JoelKatz said, "we discovered a defect in the implementation that could cause XRP to be released from escrow prior to the intended release dates. While no funds were at risk, we wanted to correct the defect to ensure the implementation is airtight. ".  This doesn't preclude the possibility that the specs don't line up with the logic.  I'd wait until further clarification before deciding the nature of this issue.  I also find it funny that this completely irrelevant distinction is worth making a point about, yet Ripple's possible reputation fallout is a non-issue, lol.  Anyways, I'm really curious what Ripple is going to do next.

As a thought experiment, how many of you out there can justify the 'non-issue' stance when transmulgated into my mechanic analogy?  Would you go back to the mechanic if he forgot to put 4 lug nuts on your wheel even though he fixed it and no harm came from it?  How well does the analogy hold if you are the FI customer and the mechanic is Ripple.

Where in my post have I said it is a non-issue? Stop arguing against your strawman please.

Share this post


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

Is this why the Current Stable Version was updated to 0.80.2 around 17 hours ago? (I'm non-Technical!)

No. The escrow problem was just a defect in the transactions we used and we issued new transactions to fix it.

The upgrade to 0.80.2 fixes a different bug having to do with receiving a transaction from a peer that you have already received. A fix for a previous bug that would cause the transaction to be aggressively suppressed caused a chain reaction that resulted in network instability.

Rippled uses a structure called the "HashRouter" to track objects it has received from peers. When it receives an object that it needs to share (such as a transaction or a validation) it dispatches it to be checked for validity. While it's being checked, the HashRouter ensures that it's only checked once and also keeps track of any additional peers we receive that same object from. If we do decide to relay it, the HashRouter tells us which peers we have not received it from and relays it to just those. If the object is invalid, we punish the peer that made us dispatch it. If it's valid, we reward the peer that gave it to us first. Duplicates of recent objects are just ignored -- if they're bad, we already punished someone, and if they're good, they just gave them to us late and that's okay.

The HashRouter has a five minute entry expiration to keep it from tracking more and more objects as time goes by. This time can be extended if an object is received again. For everything but transactions, this is great. You would never want to process something like a proposal or validation more than once -- it's only useful to the server if it's fresh.

Not so for transactions. A transaction may be invalid now but the exact same transaction valid three minutes later, for example, if the account issuing the transaction is created on the ledger. We used to just use the same HashRouter logic for transactions, and this made it hard to "resurrect" a transaction like this. The fix for this problem resulted in a new problem -- excessive dispatching of identical transactions close in time. This not only filled the transaction dispatch queue (resulting in dropped transactions) but, worse, it caused excessive peer punishment for sending invalid transactions. (If we dispatch it and then discover it's a duplicate, we punish the peer because if it's a duplicate and not recent, the peer should not have sent it to us. But it was recent, we just didn't realize it.)

Long story short, the fix is to suppress dispatching transactions received from peers if, and only if, they haven't been dispatched in the last ten seconds. The only change (other than to change the version number) is this one. The change information is here:

https://github.com/ripple/rippled/commit/fbfb4bd74ecfffcf3d77f28aade0b0fcebeebcbb

There are also some tuning changes to improve network stability given the higher volume we've seen recently and a change to reduce resource consumption. There are no changes to any ledger or transaction behavior other than the dispatch change.

Share this post


Link to post
Share on other sites
Guest
6 minutes ago, galgitron said:

@JoelKatz

As a thought experiment, how many of you out there can justify the 'non-issue' stance when transmulgated into my mechanic analogy? 

I just hope you wore protection. 

 

Share this post


Link to post
Share on other sites
4 minutes ago, corak said:

Where in my post have I said it is a non-issue?

Sorry, that was meant for the general audience, not specific to your statement

4 minutes ago, corak said:

Stop arguing against your strawman please.

Stop telling me to stop whatever I feel like doing

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...