- From: Daniel Bateman <7daniel77@gmail.com>
- Date: Thu, 28 Jan 2016 14:34:57 -0500
- To: Steven Roose <stevenroose@gmail.com>
- Cc: Evan Schwartz <evan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CAB1OcyHJ2Vkt8Vg=cqwLNveEsnhasOOzUwBj3MWW3Ms-D2BKOA@mail.gmail.com>
Steven, Thank you for your message. I understand that the gateway is only involved during a withdraw, but that is the point. If you're conducting a transaction, you cannot be assured of the validity until the withdrawal of funds is complete. Daniel On Jan 28, 2016 2:30 PM, "Steven Roose" <stevenroose@gmail.com> wrote: > Daniel. That is not true, non-XRP payments require no additonal trust in > the gateway then when not making payments. All non-XRP payments happen > within Ripple without involvement of the gateway. The gateway is only > involved when withdrawing or depositing money out of or into Ripple. > > So with SusPay, the only additional trust in the gateway while a > transactions is suspended is that the gateway will not lose the funds while > the transaction is in suspension. That extra trust is actually negligible > since that trust is automatically assumed while just owning the IOU > currency, that's what the trust limits are for. > > So basically the only problem is that a user can possibly change its trust > level while incoming or outgoing transactions are suspended. However, I > don't think that should be so much of an issue. A user can now already > change its trust limit to an amount lower than the amount of currency he > owns. What that induced is that he can only spend the currency and no > longer receive it. > > I would be interested in hearing what other additional complexities are > involved here.. > > On Thu, Jan 28, 2016 at 8:17 PM, Daniel Bateman <7daniel77@gmail.com> > wrote: > >> Steven, >> >> Non-XRP payments require trusting the gateway that is issuing the non-XRP >> currency/commodity/security etc. >> >> Does this fully answer your question? If not, please specify further. >> >> Daniel >> > >
Received on Friday, 29 January 2016 08:58:14 UTC