From matsjj at gmail.com Tue Aug 11 20:44:27 2015 From: matsjj at gmail.com (Mats Jerratsch) Date: Tue, 11 Aug 2015 22:44:27 +0200 Subject: [Lightning-dev] ThunderNetwork - A Java LightningNetwork Implementation Working Today In-Reply-To: References: <20150811191043.GD8380@lightning.network> <20150811200618.GA1946@lightning.network> Message-ID: Sweet! Do you mind if I start calling it a Lightning Network Implementation then? ;) Also note that both these problems can be eliminated with OP_CLTV, which will be implemented at least somewhat soon. 2015-08-11 22:33 GMT+02:00 Joseph Poon : > 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 >>