W3C home > Mailing lists > Public > public-interledger@w3.org > March 2016

Re: Blockchains and interledger (left-over question from the workshop)

From: Jehan Tremback <jehan.tremback@gmail.com>
Date: Wed, 2 Mar 2016 12:03:24 -0800
Message-ID: <CABG_PfQk_5vQB8sUUjcjgx-w4GibceLgtfRGy6Bve757r+Eo1A@mail.gmail.com>
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>
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>

> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 20:03:56 UTC