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

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