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 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.
In this case, the client can hold up funds from the server completely
and attack the server by mutating their transaction.
Presume Alice and Bob have a channel open together. They both
contributed 0.5 bitcoin for a total balance of 1 BTC.
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.
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".
--
Joseph Poon
š Original message:
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.
In this case, the client can hold up funds from the server completely
and attack the server by mutating their transaction.
Presume Alice and Bob have a channel open together. They both
contributed 0.5 bitcoin for a total balance of 1 BTC.
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.
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".
--
Joseph Poon