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

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