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

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

From: Rafael Pereira <rafael@rippex.net>
Date: Wed, 02 Mar 2016 20:36:07 +0000
Message-ID: <CAFk+OK==Of72uCYjLBPVw0gmbU1LCwDtW0mbk8Oq08+C19ZBDQ@mail.gmail.com>
To: Jehan Tremback <jehan.tremback@gmail.com>
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>
Yeah, indeed.

I think that if C > D occurred in time, than in theory the receipt was
presented by C to ledger 2 in time. If ledger 2 has an admin, next step is
to claim the funds to the admin. If not... I think C will have to try to
contact B beg for the funds? Than B will contact A to see if the
transaction can be completed manually?

If the ledger has an admin, I see two possibilities:

1 - A > B escrow timed out and B did not receive any money:
In this case, B would claim to ledger 2 admin to not pay C and keep the
escrow until A > B is resolved, and C would claim the money saying that D
was provably paid in time. Ledger admin would have to resolve a dispute.

2 - A > B escrow is still in time:
Ledger 2 admin can release the funds manually to C and pass the signed
receipt to B.

Em qua, 2 de mar de 2016 às 17:03, Jehan Tremback <jehan.tremback@gmail.com>
escreveu:

> 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.
>>>
>>
>>
> --

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:36:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 20:36:49 UTC