Jump to content

Recommended Posts

By default, the no ripple flag is set automatically when a trust line is created. Gateways should disable this behavior by setting their accounts "DefaultRipple" flag.

If account A sets up a trust line to account B, account A can set the no ripple flag however they want. But account B, the "passive" side needs to have the no ripple flag set automatically if they want it set. By default, the passive side sets the no ripple flag. Gateways do not want no ripple set by them on their trust lines when customers create them, so though should set the "DefaultRipple" flag.

"DefaultRipple" is an account flag set with the "AccountSet" transaction. No Ripple is two trust line flags, one for each direction.

Share this post


Link to post
Share on other sites

with reference to the document https://ripple.com/files/GB-2015-04.pdf , it seems like this flag has been introduced only after March 2015. So did the trust lines created before this date has the noripple flag available ? And was the default behaviour of account was one of the form of vulnerability for rippling, as referenced ?

Share this post


Link to post
Share on other sites

In the very beginning, no ripple didn't exist. When it was added in December of 2013, you still had to manually set it on a trust line in all cases. The logic was that users would set it when they added a trust line to a gateway.

Later an attack was discovered that leveraged the fact that if I created a trust line to you, you had no chance to set the "no ripple" flag on it. This could hurt you even if you extended no trust. To fix that, in March of 2015 we changed the behavior so that the passive side of a trust line would automatically set the "no ripple" flag on it. This would, of course, be a disaster for gateways, so we added an account flag "DefaultRipple" to disable this behavior.

 

Share this post


Link to post
Share on other sites

Some more information : Trust lines have two two sides where noripple can be enabled, or disabled. So if UserA trusts UserB, the line could look like this : 

UserA -- R/N ------- R/N --> UserB

Note that user A can only control their side of the trust line, and that four possible configurations exist.

 

Before asfDefaultRipple was added, setting a trust line to the gateway (or any address on the network) would look like this : 

User -- R/N ------- R --> Gateway

 

After asfDefaultRipple was added, if asfDefaultRipple was disabled,  the trust line would look like : 

User -- R/N ------- N --> Gateway

 

But... after asfDefaultRipple was added, if it was enabled (as it should be for gateways), the trust line would look like : 

User -- R/N ------- R --> Gateway

 

 

 

Share this post


Link to post
Share on other sites

Further, a gateway issued asset cannot ripple between users if two N's (noripple true) appear in a row (at least that's how I conceptualize)

So money can flow from UserA to UserB in these three cases : 

  1. UserA -- R/N ------- R --> Gateway <-- R ------- R/N -- UserB
  2. UserA -- R/N ------- N --> Gateway <-- R ------- R/N -- UserB
  3. UserA -- R/N ------- R --> Gateway <-- N ------- R/N -- UserB

And money cannot flow from UserA to UserB in this case : 

  • UserA -- R/N ------- N --> Gateway <-- N ------- R/N -- UserB

The gateway bulletin https://ripple.com/files/GB-2015-04.pdf prevented a subtle attack, but also made it so that a gateway could still have users sending IOUs to each other, which is identically case 1 above.

Share this post


Link to post
Share on other sites
1 hour ago, namini said:

I gotta buy the book "Ripple made easy" or "Ripple for dummies" because after 3 years it still is super complicated to me, nice explanation anyway.

That is a fair criticism. Ripple does a lot. The price we pay for that is complexity.

Share this post


Link to post
Share on other sites

i'd like an example of xrp cross-currency autobridging across ILP-enabled exchanges via Codius smart contracts between multinational banks triggering Ethereum instances at the central banks using hard-coded Fugger-trustlines...

3 - 2 - 1 .. go!

Share this post


Link to post
Share on other sites

Great explanations here! Given the current RCL environment (low-liquidity, disparate currency prices), are there present use-cases where enabling rippling is advantageous or useful?

I can understand it's usefulness in a future where currencies of the same type have reliably congruent value, but it in the current environment rippling appears to provide advantage only to malicious actors who find ways to use the feature to exchange an asset of lesser value for an asset of greater value, behind the back of the more valuable asset holder.  Pretty much the only "attacks" or bugs/issues with RCL that have endangered user funds - that I'm aware of - have been related to rippling, and yet it appears to provide little to no present advantage or use... is that fair comment, or surely am I missing something?

Share this post


Link to post
Share on other sites

Ripple as a concept initially was built around rippling and not so much around the gateway concept. In a strong end-user centric market, rippling would be much more common and useful. If only less than a handful gateways like currently are transacting in scale, it of course is hard to see the advantages.

Conceptually, I'd recommend looking at rippling as "implicit offers" compared to the explicit ones that end up in order books. Both have their place and their advantages as well as risks.

One advantage would be for example that it is very easy for someone to offer a "hub" between a lot of IOUs and even automatically (though quality settings) have a chance for a guaranteed profit without having to submit a single transaction. I really hope that with ILP enablement later this year one of the first use cases will be more native cryptocurrencies on RCL, which would offer lots of trading potential as well as potential for more interesting gateway models than with the regulation heavy fiat currency market. This depends on client/wallet support though and in that regard unfortunately there still is a lot to be done. Whoever manages to have a profitable business case for a well made and tested Ripple wallet would be doing more for the XRP price than the umpteenth bank announcement which anyways will just use Ripple Inc's closed source ILP implementation and never touch XRP even in passing (why should they, if there are no actual offers or useful gateways out there anyways?).

Share this post


Link to post
Share on other sites

 

What is the default when adding a trust line, without defining a trustset flag? For me, rippling was enabled! I thought it is off by default.

Edited by Coolio

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

In case this helps the next person,

I was struggling with this because when i submitted the trustset transaction, even though i was only using the  2147483648 (tfFullyCanonicalSig) flag, I could see the RippleState flag set to 131072 (tfSetNoRipple) on the ledger so i assumed it was OK, but i was wrong.

When you submit the transaction with the flags set to 2147614720 ( tfFullyCanonicalSig and the tfSetNoRipple ) you will see the RippleState flag for that trustline set to  2228224 which is 131072 (tfSetNoRipple) AND 2097152 (tfClearFreeze).

hopefully this saves someone wasted time down the road.

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