Proposal: de-centralized Gateways

[ripplerm]

I had been thinking about having decentralized gateways on RCL that's  co-managed by several reputable custodians/validators from different background and geographical area, whom has very least possibility to collude with each other.

The operation can be achieved by using multi-signature features of RCL. The issuing account and hot-wallets of the Gateways are made of M-of-N multi-sig accounts, where the custodians are the signers. Thus the processes of currency-issuing and deposit/withdrawal can only be done with enough signatures from majority of the signers.

Multi-signature is supported by most crypto-currencies today. With proper set-up and selection of delegates, it could make RCL a trusted 'side-chain' or as decentralized exchanges for many cryptos out there.

[RafOlP]

We would be open to discuss this, it is an interesting concept we have been touching from time to time internally.

We designed our BTC gateway with one goal in mind: create a gateway with less dependency on trust that can be publicly audited and that can evolve to a fully decentralized operation.

The fact that you can inspect a public transaction that can be used as the trigger of something (another public transaction in this case) makes it possible to build what you are suggesting.

Nevertheless, there are some challenges:

- Trust is costly, and decentralizing it is also costly - in other words, reducing risk is costly. In a scenario where the revenue would be shared among the signing gateways I see an increase in the operational costs. In general, public coins deposits and withdrawals are free(ish) and the trading fees are cheap. The trading volumes required for such decentralized gateway to make interesting profit would be really high.

- There must be a logic for issuing and redeeeming that uses one of the two (or another idea) methods below:

1. Publicly verifiable tx-linking data: in the case of a BTC deposit, the data for to which ripple account to pay that tx should be IN the bitcoin transaction, something like plain text in the memo field. This method is fully transparent with no privacy (in our discussions this is our choice for now, but is there enough demand for that?).
2. Store data in a private data bank: this would require shared writing rights and a decentralized data base if the idea is to be fully decentralized.

- Traders would have to be comfortable with giving up privacy to get more secure - if they are moving money between exchanges this is not a big issue.

- The system must be fault tolerant in a way that a majority of signers can keep it up if a minority goes out of service for any reason. The m-of-n config must tackle this.

- Last but not least - Regulation: participants would have to agree on who are the eligible customers of such decentralized gateway (KYC, AML, licenses, etc) and they would have to build a model for accountability, legal liabilities and support to customers.

We already opened our BTC gateway for some foreign customers as beta testers and soon everyone will be able to apply for an account. We believe our implementation is the first step towards such decentralized gateway and we are open to talk about how this can evolve. So i am glad to join your discussion.

Edited February 13, 2017 by RafOlP

[winthan]

1 hour ago, RafOlP said:

We already opened our BTC gateway for some foreign customers as beta testers and soon everyone will be able to apply for an account. We believe our implementation is the first step towards such decentralized gateway and we are open to talk about how this can evolve. So i am glad to join your discussion.

3

which BTC gateway is it? 

[ripplerm]

4 hours ago, RafOlP said:

We already opened our BTC gateway for some foreign customers as beta testers and soon everyone will be able to apply for an account. We believe our implementation is the first step towards such decentralized gateway and we are open to talk about how this can evolve. So i am glad to join your discussion.

Glad to hear that a BTC gateway is coming... i really miss those time where btc2ripple is around operating in fully transparent manner.

an disadvantages of operating on RCL is that we don't have a nice GUI for traders since RL stop developing end-user client (the old Ripple Trade really sucks compared to most platforms out there)... to attract users, gateways need to invest more resources on developing better client that consist of more user-friendly interface plus some advance feature.

and IMO, gateway operator here had to be more patient to keeping their transfer fee at zero until the volume hit in. Free-ish trading is one great attraction to active traders and market-makers. Just look at those Bitcoin Exchanges in China, they had been charging zero fees for years although they had provide much better GUI experience (than Ripple) for the users.

There's certainly some demand out there for decentralized exchanges, that's why we saw development of Nxt, Bitshare, OpenLedgers, etc... anybody who's like to run a gateway on RCL had to be mentally and financially prepared for a long-term battle to compete with all those platform.

 

[ripplerm]

6 hours ago, RafOlP said:

Nevertheless, there are some challenges:

- Trust is costly, and decentralizing it is also costly - in other words, reducing risk is costly. In a scenario where the revenue would be shared among the signing gateways I see an increase in the operational costs. In general, public coins deposits and withdrawals are free(ish) and the trading fees are cheap. The trading volumes required for such decentralized gateway to make interesting profit would be really high.

my idea was an open-source codes, that's the custodians/delegates could just download and run (shouldn't be more difficult than setting up a rippled node)... this could minimize the maintaining cost of custodians to almost zero, and open up the opportunity to everyone....

in the case of ETH, all the deposit/withdraw logics can be compiled into a smart contract, this would increase the transparency and trustworthiness of gateway operation.

At the beginning phase, there shouldn't be expecting any good taste of profit, and custodians are mostly like volunteer work...  When the volume hit in then we can set some rules for profit-distribution to keep the delegates working or compete efficiently.

Edited February 13, 2017 by ripplerm

[RafOlP]

7 hours ago, winthan said:

which BTC gateway is it? 

This gateway:

 

[ripplerm]

20 hours ago, RafOlP said:

This gateway:

 

It would be great if your bitcoin bridge can implement federal-protocol style like btc2ripple...

or let users just state the target bitcoin address in memo field for withdrawal...

this will pretty much simplify the process and attract more users.

[RafOlP]

43 minutes ago, ripplerm said:

It would be great if your bitcoin bridge can implement federal-protocol style like btc2ripple...

or let users just state the target bitcoin address in memo field for withdrawal...

this will pretty much simplify the process and attract more users.

BTC2ripple used "services" not federation if I remember well - the integration to rippletrade was really neat, nevertheless it is client-dependent. Memo field would require less client-side compatibility (only allowing the use of memo field) but it is less private (I don't remember how private was BTC2ripple.

EDIT: @ripplerm your wallet is very interesting, how hard do you think it would be to create a desktop version of it?

Edited February 14, 2017 by RafOlP

[ripplerm]

@RafOlP:  dont need a desktop version...

the wallet is a just a single html page... to run it locally, simply clone the codes onto a PC then open the index.html with firefox.

however if u are thinking like compiling it into an executable, (I haven't tried this) but it shouldn't be hard.

[RafOlP]

13 hours ago, ripplerm said:

@RafOlP:  dont need a desktop version...

the wallet is a just a single html page... to run it locally, simply clone the codes onto a PC then open the index.html with firefox.

however if u are thinking like compiling it into an executable, (I haven't tried this) but it shouldn't be hard.

Ok, what I haven't checked out is how it handles the Secret Keys and signing, could you please point to me where to look at it in the code? One thing that would be very useful would be to encrypt the TXT file with the wallet's properties.

I like very much the flows you created in the wallet, they are very direct.

[ripplerm]

6 hours ago, RafOlP said:

Ok, what I haven't checked out is how it handles the Secret Keys and signing, could you please point to me where to look at it in the code?

https://github.com/ripplerm/ripple-wallet/blob/gh-pages/js/mywallet.js#L923-L934

basically i just create an account-secrets mapping at $scope.secrets, and also cache them into Remote object of ripple-lib for signing use...

all signing are done with my ripplelib.

[ripplerm]

Actually during past few months, i had spent much of my pass-time building a prototype multi-sig gateway. (codes in nodejs, ripple-lib).

The one I'm working is a gateway between RCL and Steem.

the reason I chose Steem as first testing ground is becoz it's multi-sig scheme is quite similar to RCL, which allow setting/changes of signers on a fix account name/address... and I'm kinda like its idea of SBD (a token pegged to USD).

Since January-2017, the gateway was test-runing with 2-of-3 multisign accounts on RCL and STEEM blockchain.

 

Here's the current set-up:

on RCL:

•     Issuing address: rKYyUDK7N4Wd685xjfMeXM9G8xEe5ciVkC
•     Issuing currencies: STM, USD (ious for STEEM and Steem-backed-Dollar  from Steem blockchain).
•     hot-wallet address: r3dpA9FBczceWTWh4FRquuSvEVaQyU3GNg
  • signers:
    • rLSQVWfU2ZzCyRTKXUa6oHKbQ225uVrwD1
    • rnt8KdAo9CDUPzyJZszeCogxwFRtniomN3
    • r9BLkJQyJ22si2RgKv9HpUcuAN2g9sqh3b
•     dummy user:  r3DuKhPk9mCnYyMn449TitkDskPpNT7rWY

on Steem:

•  gateway account: @steemiex
•  dummy user: @rcl

 

Deposit and Withdrawal processes are totally public and transparent. Users of the gateway just need to state their target account in memo field when making a deposit/withdrawal. When a validator node see a deposit/withdraw, it will construct a raw txn, sign it and publish its signature via memo on RCL... the respective txn will then be broadcasted when enough signatures were collected. (take about 1 minute under normal condition)

 

The codes is almost ready... so I'm wondering if anybody here interested to join as validators to this gateway?

[T8493]

39 minutes ago, ripplerm said:

The codes is almost ready... so I'm wondering if anybody here interested to join as validators to this gateway?

2

How do you ensure atomicity of these transactions? Just by different people signing transactions in both ledgers?

 

[ripplerm]

7 hours ago, T8493 said:

How do you ensure atomicity of these transactions? Just by different people signing transactions in both ledgers?

the transactions are not atomic.

main concept of the setting is the multi-party controll... the gateway will work continuously as long as majority of the nodes are working and honest.

a small problem of RCL is that it's only support max 8-signers, so the highest degree of decentralization we can have now is 5-of-8 multi-sigs. High confidence level still can be build if each validator is trustworthy and well-known by community, so that people believe they won't collude.

Edited February 20, 2017 by ripplerm

[RafOlP]

@ripplerm We would be interested in discussing the model, shall we meet?

Anyone from @gatehub, RippleFox, Mr. Ripple? @enej?

Edited February 26, 2017 by RafOlP