Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message: Sweet! Do you mind if I ...
📅 Original date posted:2015-08-11
📝 Original message:
Sweet!
Do you mind if I start calling it a Lightning Network Implementation then? ;)
Also note that both these problems can be eliminated with OP_CLTV,
which will be implemented at least somewhat soon.
2015-08-11 22:33 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> 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
>>
📝 Original message:
Sweet!
Do you mind if I start calling it a Lightning Network Implementation then? ;)
Also note that both these problems can be eliminated with OP_CLTV,
which will be implemented at least somewhat soon.
2015-08-11 22:33 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> 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
>>