Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message: 2015-08-11 21:16 ...
📅 Original date posted:2015-08-11
📝 Original message:
2015-08-11 21:16 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> On Tue, Aug 11, 2015 at 08:42:50PM +0200, Mats Jerratsch wrote:
>> Can you elaborate, why you think that the client is not able to close
>> the channel? I think this is a misunderstanding on your side, which
>> most of the rest of your post argues from. While there is a slight
>> favor for the server in the channel design, there is nothing what
>> prevents the client from broadcasting (and enforcing) the channel.
>
> Ah, sorry, i'm reading it more closely now. I assumed only the server
> had a copy since that what made the most sense to me under this kind of
> asymmetric model, since it makes sense to not trust the client.
Ah I see, yes, theres a lot of additional documentation needed. When
you have your head that deep into some topic for months, you assume
everyone looks at your notes and understands everything just
perfectly.
[...]
> 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.
> 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.
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.
Best Regards,
Mats Jerratsch
>
> --
> Joseph Poon
📝 Original message:
2015-08-11 21:16 GMT+02:00 Joseph Poon <joseph at lightning.network>:
> On Tue, Aug 11, 2015 at 08:42:50PM +0200, Mats Jerratsch wrote:
>> Can you elaborate, why you think that the client is not able to close
>> the channel? I think this is a misunderstanding on your side, which
>> most of the rest of your post argues from. While there is a slight
>> favor for the server in the channel design, there is nothing what
>> prevents the client from broadcasting (and enforcing) the channel.
>
> Ah, sorry, i'm reading it more closely now. I assumed only the server
> had a copy since that what made the most sense to me under this kind of
> asymmetric model, since it makes sense to not trust the client.
Ah I see, yes, theres a lot of additional documentation needed. When
you have your head that deep into some topic for months, you assume
everyone looks at your notes and understands everything just
perfectly.
[...]
> 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.
> 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.
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.
Best Regards,
Mats Jerratsch
>
> --
> Joseph Poon