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

[Mats Jerratsch]

>> 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.

Yes exactly, this high of a revocation timeout is not for 24/7 nodes, but rather to ease problems for endusers when adopting to this new way of transacting.

Keep in mind though that only the revocation value is a private arrangement.
The dual-tx approach is backward compatible, meaning it is possible relaying payments with the old setup, with the cost of using long refund times. It is not possible to relay a payment that is optimised for dual-tx over hops that don’t support it, because they would deduct their usual refund-time (often between 1-2 days per hop), leaving no room for the rest of the route.

Yes when having multiple payments with different timeouts one has to keep track of when to broadcast which transaction, but this is similar to the current approach. It does make it significantly harder to transact sub-dust amounts though. For a 1 satoshi payments one would often pay >500 satoshi for claiming it on-chain.

What we can do, however, is to use the old schema for these low-amount payments, given that a long clearance time isn’t that much of a problem for these either way.

Cheers
Mats
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160530/188f3b8d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160530/188f3b8d/attachment.sig>