From rusty at rustcorp.com.au Fri Sep 25 01:11:02 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 25 Sep 2015 10:41:02 +0930 Subject: [Lightning-dev] Minor protocol revisions. In-Reply-To: References: <87r3lo2wsi.fsf@rustcorp.com.au> Message-ID: <871tdns3q1.fsf@rustcorp.com.au> Pierre writes: > Hi Rusty, > >> 1) Close now has an second ACK stage, which means you know the close ack >> has been received. > Argh, I already have trouble understanding the rationale behind all > the existing closing flows and states :-s Would it be possible to > publish an updated version of the svg ? aj, any chance you could do > the same with your 'flat' version ? Heh, this one is pretty easy. It's just an ack at the end of the mutual close handshake: close_channel close_channel_complete close_channel_ack (this is new). >> 3) HTLC rejection (eg. bad route, insufficient fees) added. > How about the 'commit tx too big' case ? will that just be an error ? A protocol error: you should never propose a HTLC which will cause the commit tx to be malformed. >> As a secondary effect, 32 bits places [an upper bound of 0.04 BTC] >> (currently about $10USD) on each HTLC. That's more than enough to cover >> the micropayment uses of lightning, yet if you lose all your money due >> to a horrible bug in the early days, I can buy you a beer and count us >> about even[1]. And we can change the protocol later if it becomes >> overly limiting. > Such a low ceiling bothers me a little bit, because it kind of states > that the micropayment use case is the primary target. Is it ? To me, > scalability and speed are the most interesting properties of > lightning. I think the early adopters are going to be microtransactions. And they're good to have: they build the network, stress-test us, and let us learn without risking too much. > I would have preferred a higher (1 BTC ?) limit, but I > understand this can be changed. Regarding the risk of bugs, you can't > loose more than the channel capacity so that's another parameter we > can play with I guess. My reference implementation refuses to create a channel which would overflow this. That was a simple check to implement (we already check that no HTLC would spend more than channel capacity of course). I use 64 bits internally, to avoid wrap issues anyway. My general philosophy here is to underpromise, and over-deliver. I can't talk to all the users individually, but if we set *our* expectations at "beer money, not rent money" that will hopefully spread. I recommend reading one of the "I was Goxxed" reddit threads for some heartbreaking perspective on what happens when innocent people get caught up in hype :( Cheers, Rusty.