ripplerm Posted February 13, 2017 Share Posted February 13, 2017 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. Sapitoka, Roborovskii, enrique11 and 5 others 8 Link to comment Share on other sites More sharing options...
RafOlP Posted February 13, 2017 Share Posted February 13, 2017 (edited) 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: 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?). 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 enej, enrique11, rippleric and 1 other 4 Link to comment Share on other sites More sharing options...
winthan Posted February 13, 2017 Share Posted February 13, 2017 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? Link to comment Share on other sites More sharing options...
ripplerm Posted February 13, 2017 Author Share Posted February 13, 2017 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. Link to comment Share on other sites More sharing options...
ripplerm Posted February 13, 2017 Author Share Posted February 13, 2017 (edited) 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 ElMoskito 1 Link to comment Share on other sites More sharing options...
RafOlP Posted February 13, 2017 Share Posted February 13, 2017 7 hours ago, winthan said: which BTC gateway is it? This gateway: Link to comment Share on other sites More sharing options...
ripplerm Posted February 14, 2017 Author Share Posted February 14, 2017 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 1 Link to comment Share on other sites More sharing options...
RafOlP Posted February 14, 2017 Share Posted February 14, 2017 (edited) 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 Link to comment Share on other sites More sharing options...
ripplerm Posted February 14, 2017 Author Share Posted February 14, 2017 @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. Link to comment Share on other sites More sharing options...
RafOlP Posted February 15, 2017 Share Posted February 15, 2017 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. Link to comment Share on other sites More sharing options...
ripplerm Posted February 15, 2017 Author Share Posted February 15, 2017 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. RafOlP 1 Link to comment Share on other sites More sharing options...
ripplerm Posted February 19, 2017 Author Share Posted February 19, 2017 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? Link to comment Share on other sites More sharing options...
T8493 Posted February 19, 2017 Share Posted February 19, 2017 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? Link to comment Share on other sites More sharing options...
ripplerm Posted February 20, 2017 Author Share Posted February 20, 2017 (edited) 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 rippleric 1 Link to comment Share on other sites More sharing options...
RafOlP Posted February 26, 2017 Share Posted February 26, 2017 (edited) @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 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now