From rusty at rustcorp.com.au Wed Jun 1 06:47:33 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 01 Jun 2016 16:17:33 +0930 Subject: [Lightning-dev] Updated commitment design + Release thunder.network In-Reply-To: <3F1739FA-FD6C-443F-940B-34C50E1B5B45@blockchain.com> References: <2E1E73BA-0362-48D9-8B95-C9CC274A617D@blockchain.com> <874m9l5njj.fsf@rustcorp.com.au> <3F1739FA-FD6C-443F-940B-34C50E1B5B45@blockchain.com> Message-ID: <87vb1t9zi2.fsf@rustcorp.com.au> Mats Jerratsch writes: > 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. But nodes need to publish their HTLC time subtraction anyway. If they're using dual-tx, that'll just be lower than otherwise. BTW, my prototype started by using times everywhere, but I'm switching to blocks. The protobuf file supports both, but I now think that adds complexity. Block counts are what active nodes care about, particularly when we're talking about tight timings: I'm comfortable with a 6 block delay, but not a 1 hour delay. And for larger counts, they're roughly convertible anyway (a UI problem, really). > 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. You can't really create < 546 satoshi outputs anyway, since they'd be non-standard ATM. I currently keep those off-chain (they add to fees). A probabalistic scheme is possible, but it adds an extra round-trip (we both need to generate the random number before we know what's in the tx to exchange signatures). And even then, you can decide to dump your tx onchain if it works in your favour, so a probabalistic scheme is probably pointless. Cheers, Rusty.