- From: Jehan Tremback <jehan.tremback@gmail.com>
- Date: Wed, 2 Mar 2016 12:03:24 -0800
- To: Rafael Pereira <rafael@rippex.net>
- Cc: Dimitri De Jonghe <dimi@ascribe.io>, Melvin Carvalho <melvincarvalho@gmail.com>, Stefan Thomas <stefan@ripple.com>, Bob Way <bob@ripple.com>, Evan Schwartz <evan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CABG_PfQk_5vQB8sUUjcjgx-w4GibceLgtfRGy6Bve757r+Eo1A@mail.gmail.com>
The nice thing about ILP (and payment channels) is that you only need to trust the ledgers that you have accounts on. On Wed, Mar 2, 2016 at 11:41 AM, Jehan Tremback <jehan.tremback@gmail.com> wrote: > Bottom line, if you're going to use a ledger, you are trusting it. The > particulars of any ledger vulnerability are not important to us. Whether > it's a SQL injection at a bank, or some bitcoin thing, if you're using an > insecure ledger, you might lose money. Confirmation times, like SQL query > sanitization, have no bearing on the design of ILP itself. > > On Wed, Mar 2, 2016 at 11:28 AM, Rafael Pereira <rafael@rippex.net> wrote: > >> "the funds were either not escrowed properly, or they are not released >> (or not released permanently) by the receipt." >> How would this happen if ILP was well implemented in the ledger? >> Taking bitcoin as an example, it would mean that the escrow was confirmed >> by a bad block(s) and when the network gets back to the right chain the >> escrow would be out of funds? >> I see this as a ledger problem and a bad choice on how ILP was >> implemented - like the conditions for declaring an escrow completed. >> I think that if the conditions to declare an escrow completed were 3 >> confirmations, the transaction would be less likely to fail. >> >> This is a good point because when other transactions are tied to a step >> in a decentralized ledger's, it is important to increase the certainty >> about the finality of this ledger's declarations. >> >> Em qua, 2 de mar de 2016 às 16:11, Jehan Tremback < >> jehan.tremback@gmail.com> escreveu: >> >>> 1 2 3 >>> / \ / \ / \ >>> A B C D >>> >>> So, let's say that ledgers are numbers, and 2 is byzantine. Funds are >>> escrowed on the three ledgers. D sees the funds, and releases the receipt. >>> The funds move from C to D, no problem. However, on 2, the funds were >>> either not escrowed properly, or they are not released (or not released >>> permanently) by the receipt. Funds do not move from B to C. B gives the >>> receipt to A, and gets their money. C is the only one who is out any money. >>> >>> At this point we can say that C shouldn't have exchanged their >>> hard-earned dollars for worthless ledger2coins, but A and D are not >>> affected. >>> >>> -Jehan >>> On Wed, Mar 2, 2016 at 6:27 AM, Dimitri De Jonghe <dimi@ascribe.io> >>> wrote: >>> >>>> Op wo 2 mrt. 2016 om 07:01 schreef Melvin Carvalho < >>>> melvincarvalho@gmail.com>: >>>> >>>>> On 2 March 2016 at 05:13, Stefan Thomas <stefan@ripple.com> wrote: >>>>> >>>>>> > How many confirmations are needed for inter ledger transfers >>>>>> between two block chains? >>>>>> >>>>>> Same as any other Bitcoin transaction. There are technically two >>>>>> transactions that happen, but the second one is not in the critical path. >>>>>> (In the execution phase, all transfers can execute simultaneously.) >>>>>> >>>>> >>>>> But one block chain is bitcoin, for which confirmations are protected >>>>> by a lot of hashing. The other block chain could be (and almost certainly >>>>> will be) far less robust in terms of hashing. So how many confirms on the >>>>> second chain? I admit I dont know the fine details here, but If we stick >>>>> to two for both chains, then you could trigger a transfer in one ledger, >>>>> then do a double spend in the easier ledger, leading to a need for a >>>>> reversed transaction. Have I missed something? >>>>> >>>> >>>> Very interesting point, and deserves some more elaboration... (please >>>> correct me where I am wrong) >>>> >>>> Per ledger one has two types of transactions: >>>> (1) the locking transaction that places the funds in escrow >>>> (2) the release transaction that either pays forward (2a) or reverses >>>> (2b) the funds. >>>> >>>> Considering double-spents may happen due to a simple mistake, a faulty >>>> ledger or malicious participant behaviour (collusion, sybil attack, etc): >>>> In the case of (1), the funds are both in escrow and spent elsewhere. >>>> This might happen at the connector level when he receives a high rate of >>>> escrow requests on a certain ledger but can't keep account of his unspent >>>> outputs. One should be able to detect double-spents the >>>> condition/fulfilment process of the escrow. Indeed, it may take arbitrary >>>> time to detect this, hence a safety margin might be in order. Typically for >>>> the bitcoin blockchain one waits about 6 blocks (ie 1 hour). >>>> >>>> In the case of (2), this means that the escrow would perform a >>>> double-spent, but this requires m-of-n signatures or other fullfilment >>>> conditions. A double-spent on this level seems unlikely. Can't think of a >>>> plausible scenario at the moment, but maybe let's keep the possibility open. >>>> >>>> That said, it looks like the slowest ledger will keep the funds locked >>>> for a long time (>1 confirmations). These opportunity costs will probably >>>> be taken into account as connector fees. >>>> >>>> One could think of more possible attack vectors and locking scenario's: >>>> - transfers of amounts beyond the connector liquidity >>>> - multi-spents through various paths (will keep many connectors tied up) >>>> - cyclic paths >>>> >>>> @stefan, @evan, @others >>>> Is it worth assessing possible vulnerabilities? They might impose >>>> constraints on ledgers that want to participate. >>>> >>>> Dimi >>>> >>>> >>>> >>>> -- >> >> Obrigado, >> Rafael >> >> *Rafael Olaio - CEO* >> tel +55 11 2337.2225 >> cel +55 11 99522.7572 >> rippex.net >> >> Esta mensagem pode conter informação confidencial e/ou privilegiada. Se >> você não for o destinatário ou a pessoa autorizada a receber esta mensagem, >> não poderá usar, copiar ou divulgar as informações nela contidas ou tomar >> qualquer ação baseada nessas informações. Se você recebeu esta mensagem por >> engano, por favor avise imediatamente o remetente, respondendo o e-mail >> e em seguida apague-o.This message may contain confidential and/or >> privileged information. If you are not the addressee or authorized to >> receive this for the addressee, you must not use, copy, disclose or take >> any action based on this message or any information here in. If you have >> received this message in error, please advise the sender immediately by >> reply e-mail and delete this message. >> > >
Received on Wednesday, 2 March 2016 20:03:55 UTC