From rusty at rustcorp.com.au Thu May 26 06:41:20 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 26 May 2016 16:11:20 +0930 Subject: [Lightning-dev] Updated commitment design + Release thunder.network In-Reply-To: <2E1E73BA-0362-48D9-8B95-C9CC274A617D@blockchain.com> References: <2E1E73BA-0362-48D9-8B95-C9CC274A617D@blockchain.com> Message-ID: <874m9l5njj.fsf@rustcorp.com.au> Mats Jerratsch via Lightning-dev 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.