RCL-to-RCL transaction via ILP

[Duke67]

Many of us here are concerned about privacy of RCL transactions and we have already been discussing these issues here for several times.

We know that ILP can connect any ledger to any ledger. I think I would like to have an option to route RCL-to-RCL transactions via ILP. This seems to be useless, but maybe it could add some extra privacy. The cost of a few seconds longer transaction and a little higher fee is bearable...

[xourexe]

I can't see your point. What would the connector's role be in that scheme?

What about mixing protocols like CreditMix, described in this forum by @pedrorechez?

 

Don't you think it could be a better solution?

Edited August 27, 2016 by xourexe

[T8493]

18 minutes ago, Duke67 said:

Many of us here are concerned about privacy of RCL transactions and we have already been discussing these issues here for several times.

We know that ILP can connect any ledger to any ledger. I think I would like to have an option to route RCL-to-RCL transactions via ILP. This seems to be useless, but maybe it could add some extra privacy. The cost of a few seconds longer transaction and a little higher fee is bearable...

You send 1813.13421 XRP from account A and another account B receives (1813.13421 - transaction fees) XRPs several seconds later. Where is privacy?

 

 

[jn_r]

The connectors will have no privacy, the sender/receiver will...

Speaking of which, I still don't know how to get the 'best price' from all available connectors. Imo there should be something like an orderbook where available connectors quote their price (wouldn't that be an exchange?) On Interledger.org it is described as "Interledger Quoting Protocol" (ILQP), but it has yet to be filled in...

Edited August 27, 2016 by jn_r

[RafOlP]

Privacy layer added by ILP connections would be to create separate transactions that are apparently not linked to each other because the Path is not entirely written in the RCL.

This idea would be more powerful if ILP was enabled for all issuances and not only for XRP. Then you could have different transactions apparently not connected. 

If it was just XRP, collecting transactions with very similar amounts would be trivial, if it was for all issuances, that would require more work but I'm not sure it would be real privacy.

[T8493]

3 minutes ago, RafOlP said:

if it was for all issuances, that would require more work but I'm not sure it would be real privacy.

One needs provably secure cryptographic scheme for this and not this mixing/hiding mumbo jumbo.

 

Edited August 27, 2016 by T8493

[RafOlP]

5 minutes ago, T8493 said:

One needs provably secure cryptographic scheme for this and not this mixing/hiding mumbo jumbo.

 

"One" can have a lot of different levels of privacy requirements.

And I was referring to the ILP, not the mixing protocol.

[Duke67]

1 hour ago, T8493 said:

You send 1813.13421 XRP from account A and another account B receives (1813.13421 - transaction fees) XRPs several seconds later. Where is privacy?

The privacy would be improved because you cannot see the transaction immediately on the protocol. Bithomp will not see the link. This transaction is out/in, so not immediately visible without a matching/pairing tool that would link the sender/receiver accounts for you.

I could also imagine a market maker/liquidity provider who's business model is selling "privacy enhanced" transaction services for an extra fee. With a bag of money one can mix that kind of transactions via various currencies and also spread over a predefined time period (10 mins?), so there goes your 1813.13421 -> 1813.13421 example....

 

Edited August 27, 2016 by Duke67

[T8493]

45 minutes ago, Duke67 said:

I could also imagine a market maker/liquidity provider who's business model is selling "privacy enhanced" transaction services for an extra fee. With a bag of money one can mix that kind of transactions via various currencies and and also spread over a predefined time period (10 mins?), so there goes your 1813.13421 -> 1813.13421 example....

Any reasonably competent & powerful adversary can probably break or significantly weaken this schema. Or at least this schema can provide enough information to narrow its search to a small subset of accounts.

If one sends X XRPs from account A to account B then B will always receive (X - transaction fees) XRPs in some predefined amount of time (maybe in several transactions). Similar mixing has been already broken before in crypto (KeyCoin or some similar scam coin in 2014/2015 - someone even wrote a POC app in C# that deanonymized transactions)

Check out also this for example: http://www.coindesk.com/us-government-lockheed-martin-bitcoin-analysis-tool/

 

 

 

 

Edited August 27, 2016 by T8493

[Duke67]

Everybody knows that having just meta data is enough to get almost the entire picture. There is nothing new here. And smart people knew that very well even years before Snowden.

I am talking about "enhanced" privacy, not the "ultimate" one, because let's be honest - there is no such thing. On top of that, the "enhanced privacy transaction provider" would need to be a regulated business with money transfer license, otherwise it is shut down very quickly in every normal country.

[T8493]

26 minutes ago, Duke67 said:

I am talking about "enhanced" privacy, not the "ultimate" one, because let's be honest - there is no such thing. On top of that, the "enhanced privacy transaction provider" would need to be a regulated business with money transfer license, otherwise it is shut down very quickly in every normal country.

If you want that kind of privacy, then you already have such services. Just send XRPs from an account A to an exchange (Kraken), wait some time and then withdraw XRPs to account B.

Ordinary trolls won't be able to associate your transactions from account A with transactions to account B.

 

 

 

[tulo]

57 minutes ago, T8493 said:

If you want that kind of privacy, then you already have such services. Just send XRPs from an account A to an exchange (Kraken), wait some time and then withdraw XRPs to account B.

Ordinary trolls won't be able to associate your transactions from account A with transactions to account B.

 

Doing that is the same of sending XRP from A to C accounts and then back to A. So everything is still on RCL.

BTW I think having privacy for payments on the same (public) network is impossible for definition.

[T8493]

24 minutes ago, tulo said:

Doing that is the same of sending XRP from A to C accounts and then back to A. So everything is still on RCL.

BTW I think having privacy for payments on the same (public) network is impossible for definition.

No, it is not necessarily the same, because Kraken mixes this with transactions of other people. And Kraken may send XRPs from the account that is not the same account to which you sent your XRPs.

There are some cryptographical schemes (zero knowledge proofs) that may provide privacy on the public network in some cases.

 

Edited August 27, 2016 by T8493

[karlos]

14 hours ago, Duke67 said:

Many of us here are concerned about privacy of RCL transactions and we have already been discussing these issues here for several times.

Yes in my opinion ILP doesn't solve the privacy problem with the RCL at all. As it stands now, anyone using RCL has no transaction confidentiality.

Maybe the RCL will find some niche use, but certainly not as a bridge for the worlds cross-border payments. Unless this major hurdle is overcome (if that's even possible).

[kanaas]

Is a hosted wallet, like one@gatehub, not the most easy logical way to go for transactions you want to hide?