[Lightning-dev] Minor protocol revisions.
Rusty Russell
rusty at rustcorp.com.au
Fri Sep 25 01:11:02 UTC 2015
Pierre <pm+lists at acinq.fr> 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.
More information about the Lightning-dev
mailing list