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 11:41:58 -0800
Message-ID: <CABG_PfRJp3=2tBHx3q9Sf=WOBCvs_=UnW1jDq_9RwygT2k=3mw@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>
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 19:42:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 19:42:29 UTC