Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message: On Tue, Aug 11, 2015 at ...
📅 Original date posted:2015-08-11
📝 Original message:
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'.
>
> > Let's presume that you set up some kind of reserve requirement instead:
> > At Commitment 20, the channel state is 0.05 BTC to Alice and 0.95 to Bob.
> > At commitment 31, the channel state is 0.95 BTC to Alice and 0.05 to Bob.
> >
> > Again, Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
> > version of Commitment 20. The server is out 0.95 BTC! But wait, you say,
> > Alice might be out 0.05 of her own BTC. This model breaks down because
> > it's still a hostage scenario! Alice tells Bob, "hey, I know I have 0.05
> > BTC stuck here (and you have 0.9 stuck), but I'm rich. I don't care how
> > long it takes, how about you give me a 'tax' of 0.1 BTC. You'll get your
> > money back... well most of it, just sign this transaction where I get
> > 0.15".
>
> The same as above, if she resignes commitment 20, she is losing 0.05
> BTC, while Bob does still get the 0.95 BTC.
At Commitment 20, the channel state is 0.95 BTC to Alice and 0.05 to Bob.
At commitment 31, the channel state is 0.05 BTC to Alice and 0.95 to Bob.
> There is a problem with channel histories, where Alice holds all the
> funds at one point, and Bob holds all the funds at some later point,
> as open payments are not as secure as those settled balances. I
> mitigate this by setting a hard requirement on the spendable amount. I
> will describe this in more detail soon.
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.
--
Joseph Poon
📝 Original message:
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'.
>
> > Let's presume that you set up some kind of reserve requirement instead:
> > At Commitment 20, the channel state is 0.05 BTC to Alice and 0.95 to Bob.
> > At commitment 31, the channel state is 0.95 BTC to Alice and 0.05 to Bob.
> >
> > Again, Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
> > version of Commitment 20. The server is out 0.95 BTC! But wait, you say,
> > Alice might be out 0.05 of her own BTC. This model breaks down because
> > it's still a hostage scenario! Alice tells Bob, "hey, I know I have 0.05
> > BTC stuck here (and you have 0.9 stuck), but I'm rich. I don't care how
> > long it takes, how about you give me a 'tax' of 0.1 BTC. You'll get your
> > money back... well most of it, just sign this transaction where I get
> > 0.15".
>
> The same as above, if she resignes commitment 20, she is losing 0.05
> BTC, while Bob does still get the 0.95 BTC.
At Commitment 20, the channel state is 0.95 BTC to Alice and 0.05 to Bob.
At commitment 31, the channel state is 0.05 BTC to Alice and 0.95 to Bob.
> There is a problem with channel histories, where Alice holds all the
> funds at one point, and Bob holds all the funds at some later point,
> as open payments are not as secure as those settled balances. I
> mitigate this by setting a hard requirement on the spendable amount. I
> will describe this in more detail soon.
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.
--
Joseph Poon