Olaoluwa Osuntokun <laol...@gmail.com> writes: > Hi Rusty, > > I'm a big fan in general of most of this! Amongst many other things, it'll: > simplify the whole static channel backup + recovery workflow, and avoid all > the fee related headaches we've run into over the past few months.
I certainly hope so! >> - HTLC-timeout and HTLC-success txs sigs are >> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees. > > Would this mean that we no longer extend fees to the second-level > transactions as well? If so, then a dusty HTLC would be determined solely by > looking at the direct output, rather than the resulting output in the second > layer. Good point, yes. >> - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, >> `local_delayedpubkey`, and `remote_delayedpubkey` derivation now uses a >> two-stage unhardened BIP-32 derivation based on the commitment number. > > It seems enough to _only_ modify the derivation for local+remote pubkey (so > the direct "settle" keys). This constrains the change to only what's > necessary to simplify the backup+recovery workflow with the current > commitment design. By restricting the change to these two keys, we minimize > the code impact to the existing implementations, and avoid unnecessary > changes that don't make strides towards the immediate goal. I was thinking in the long term when we drop backwards compat, then we only have one derivation scheme? >> - `to_remote` is now a P2WSH of: >> `to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG > > This seems at odds with the goal of "if the remote party force closes, then > I get my funds back immediately without requiring knowledge of any secret > data". If it was just a plain p2wkh, then during a routine seed import and > rescan (assuming ample look ahead as we know this is a "special" key), I > would pick up outputs of channels that were force closed while I was down > due to my dog eating my hard drive. Good point; we need to weigh the benefits of symmetry (which seems to require this) against this additional complication. > Alternatively, since the range of CSV values can be known ahead of time, I > can brute force a set of scripts to look for in the chain. However, this > results in potentially a very large number of scripts (depending on how many > channels one has, and bounds on the acceptable CSV) I need to scan for. I don't suppose we could get everyone to agree on the same CSV values? :) Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev