Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-24 📝 Original message: Pierre <pm+lists at ...

📅 Original date posted:2015-09-24
📝 Original message:
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.