Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message: Ah I see, if you use a ...

📅 Original date posted:2015-08-11
📝 Original message:
Ah I see, if you use a hash-based revocation, then the only primary
attack vector left is with the Funding and HTLCs (which can be
partially mitigated with a reserve)

On 8/11/15, Mats Jerratsch <matsjj at gmail.com> wrote:
> 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
>