[Lightning-dev] ThunderNetwork - A Java LightningNetwork Implementation Working Today

[Mats Jerratsch]

2015-08-11 22:06 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> On Tue, Aug 11, 2015 at 09:26:43PM +0200, Mats Jerratsch wrote:
>> > At Commitment 20, the channel state is 0 BTC to Alice and 1 to Bob.
>> > At commitment 31, the channel state is 1 BTC to Alice and 0 to Bob.
>> >
>> > Alice is the client and Bob is the server.
>> >
>> > Presume Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
>> > version of Commitment 20. The server is out 1 BTC! This is now a hostage
>> > negotiation.
>>
>> But the 1 BTC of Commitment 20 goes straight to Bob (and not to a
>> multi-sig address). Mutating a channel transaction only hurts the
>> party that is doing the mutation. This is why RBF is a major problem,
>> if it ever gets deployed.
>
> Sorry, I usually use Bob as the attacker in my examples and Alice as the
> client, so I got mixed up there. I meant:
> At Commitment 20, the channel state is 1 BTC to Alice and 0 to Bob.
> At commitment 31, the channel state is 0 BTC to Alice and 1 to Bob.
>
> In this case, if Alice attacks Bob she's not out any money, but Bob has
> funds locked up in a 2-of-2. Bob must now negotiate with Alice to get
> his money back. Alice will probably want some 'convenience fee'.
>

But Bob has both keys of the 2-of-2 multisig. One is his (main) key,
and the other one was supplied by Alice as a requirement to update the
channel and move funds.
But that is what I meant with mitigate it. Even if Bob claims all
payments, he will lose funds due to blockchain fees. (see below)

> You can't mitigate this by setting some reserve requirement, though. So
> long as Alice has more money than Bob, she can do it. If Alice is 10x
> richer than Bob, she doesn't *care* and she knows Bob will eventually
> give up. "Two-party escrow" doesn't work because one party can have more
> money and less time-value than another. Time-value is not a universal
> value.

It is possible to say that the minimum (stealable) amount of Alice
must be higher than any sum of concurrent payments minus the
blockchain fees. This way Bob can always claim all the payments of all
Commitments of the Channel and still stay in positive net balance. It
really comes down to having an incentive to clear out payments of the
channel. Only open payments are problematic, settled balance can
always be stealed with just one transaction.

Mats Jerratsch