📅 Original date posted:2015-08-11
📝 Original message:
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
Mats Jerratsch [ARCHIVE] /
npub1hz…q5x8w
2023-06-09 12:43:58
in reply to nevent1q…ycfe
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-09 12:43:58Event JSON
{
"id": "0a2df81810accf6e13485ab18fe045842c9ed274a17eb749ea981b6037e49c81",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314638,
"kind": 1,
"tags": [
[
"e",
"66681ffe7bd947a6d8c9a87dbb7582790b0efc37d305797619761486e2dc1149",
"",
"root"
],
[
"e",
"62bee65af16eae5c17201904eedb57bf4a19e8912bf46ba97fbc588a144c6c67",
"",
"reply"
],
[
"p",
"ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211"
]
],
"content": "📅 Original date posted:2015-08-11\n📝 Original message:\n2015-08-11 22:06 GMT+02:00 Joseph Poon \u003cjoseph at lightning.network\u003e:\n\u003e On Tue, Aug 11, 2015 at 09:26:43PM +0200, Mats Jerratsch wrote:\n\u003e\u003e \u003e At Commitment 20, the channel state is 0 BTC to Alice and 1 to Bob.\n\u003e\u003e \u003e At commitment 31, the channel state is 1 BTC to Alice and 0 to Bob.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Alice is the client and Bob is the server.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Presume Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)\n\u003e\u003e \u003e version of Commitment 20. The server is out 1 BTC! This is now a hostage\n\u003e\u003e \u003e negotiation.\n\u003e\u003e\n\u003e\u003e But the 1 BTC of Commitment 20 goes straight to Bob (and not to a\n\u003e\u003e multi-sig address). Mutating a channel transaction only hurts the\n\u003e\u003e party that is doing the mutation. This is why RBF is a major problem,\n\u003e\u003e if it ever gets deployed.\n\u003e\n\u003e Sorry, I usually use Bob as the attacker in my examples and Alice as the\n\u003e client, so I got mixed up there. I meant:\n\u003e At Commitment 20, the channel state is 1 BTC to Alice and 0 to Bob.\n\u003e At commitment 31, the channel state is 0 BTC to Alice and 1 to Bob.\n\u003e\n\u003e In this case, if Alice attacks Bob she's not out any money, but Bob has\n\u003e funds locked up in a 2-of-2. Bob must now negotiate with Alice to get\n\u003e his money back. Alice will probably want some 'convenience fee'.\n\u003e\n\nBut Bob has both keys of the 2-of-2 multisig. One is his (main) key,\nand the other one was supplied by Alice as a requirement to update the\nchannel and move funds.\nBut that is what I meant with mitigate it. Even if Bob claims all\npayments, he will lose funds due to blockchain fees. (see below)\n\n\u003e You can't mitigate this by setting some reserve requirement, though. So\n\u003e long as Alice has more money than Bob, she can do it. If Alice is 10x\n\u003e richer than Bob, she doesn't *care* and she knows Bob will eventually\n\u003e give up. \"Two-party escrow\" doesn't work because one party can have more\n\u003e money and less time-value than another. Time-value is not a universal\n\u003e value.\n\nIt is possible to say that the minimum (stealable) amount of Alice\nmust be higher than any sum of concurrent payments minus the\nblockchain fees. This way Bob can always claim all the payments of all\nCommitments of the Channel and still stay in positive net balance. It\nreally comes down to having an incentive to clear out payments of the\nchannel. Only open payments are problematic, settled balance can\nalways be stealed with just one transaction.\n\nMats Jerratsch",
"sig": "24bfda9035af10e92c2a6e096be3e6f0f2328f8758997cdeb446cdb38ca2ac36e4934de25d00262081e46cc2770e9d2750c5e7d10c16b261559c4dcbbd2ac618"
}