[Lightning-dev] Updated commitment design + Release thunder.network

[Rusty Russell]

Mats Jerratsch via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Hey everybody,
>
> Using SegWit, I thought of a more elegant way to solve the coupling problem between revocation delay and payment timeouts. ( https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000339.html and following)

Hi Mats!

> A basic schema with one included payment can be seen here:
>
> https://raw.githubusercontent.com/blockchain/thunder/master/docs/dual-tx-diagram.png
>
> The idea is that each payment and each refund does not directly pay to their respective owner, but to a intermediate 2-of-2 transaction. For redeeming a payment, one has to also use R to broadcast Redeem-TX, for broadcasting Refund-TX one has to wait the agreed refund time. Having broadcasted the additional transaction, one basically *secured* the funds, under the premise that one has not cheated by using an old commitment transaction. If he did cheated though, the other party can claim all funds directly from the commitment outputs or from the Redeem-TX outputs.
>
> This makes it possible to set revocation delay and payment timeouts to completely separate values (if it is not obvious why this was not possible before, I suggest reading the thread linked above).
>
> Now there are two downsides to this approach:
>
> (1) Clearing a payment on the blockchain is more expensive. Because we have an additional transaction for each payment, fees for redeeming the payment are higher. One has to take into account the fee for the additional transaction when producing the outputs for the commitment transaction. However, as most channels will not get settled on the blockchain anyways, this is a minor issue.
>
> (2) Updating the commitment transaction, one has produce and send a new signature for each currently included payment. For channels that have lots of uncleared payments for a long time this might be problematic, however, uncleared payments are undesirable for many reasons and adding disincentives for delaying the clearing process is on the TODO anyways.
>
> However, having a clean solution to the problem of high refund times (>30d) and low revocation times (<3d) is more important in the long run. 

At first I wasn't sure that anyone would really set 30 day CSV delays.
I'm not sure that I want my funds locked for 30 days, or even to deal
with a node which indicates it's likely to be offline for anything like
that long.

But I'm wrong.  If you're just an occasional end-user, this might make
perfect sense to ask for a 30 day timeout as an alternative to
outsourcing enforcement.  And since it's a private arrangement between
two nodes, it could easily be added as an option.

The main downside I see is the slight additional complexity for the
on-chain case, so I really like the idea of making it an option.

> Also, following the tradition of the other releases here on the mailing list I like to bring it over here more formally.

This deserves a mail of its own!  I like to see release announcements,
and I know the subscribers do.

> Both, Node and Wallet software can be downloaded at
> https://github.com/blockchain/thundernetwork/releases
>
> Further information can be found at
> https://github.com/blockchain/thundernetwork
> https://blockchain.com/thunder

Congratulations!
Rusty.