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

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