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

[Rusty Russell]

Mats Jerratsch <mats at blockchain.com> 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.