From joseph at lightning.network Tue Aug 11 20:33:05 2015 From: joseph at lightning.network (Joseph Poon) Date: Tue, 11 Aug 2015 13:33:05 -0700 Subject: [Lightning-dev] ThunderNetwork - A Java LightningNetwork Implementation Working Today In-Reply-To: References: <20150811191043.GD8380@lightning.network> <20150811200618.GA1946@lightning.network> Message-ID: 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 wrote: > 2015-08-11 22:06 GMT+02:00 Joseph Poon : >> 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 >