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.
> - 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. > - `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. > - `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. 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. -- Laolu On Fri, Oct 12, 2018 at 3:57 PM Rusty Russell <ru...@rustcorp.com.au> wrote: > Hi all, > > There have been a number of suggested changes to the commitment > transaction format: > > 1. Rather than trying to agree on what fees will be in the future, we > should use an OP_TRUE-style output to allow CPFP (Roasbeef) > 2. The `remotepubkey` should be a BIP-32-style, to avoid the > option_data_loss_protect "please tell me your current > per_commitment_point" problem[1] > 3. The CLTV timeout should be symmetrical to avoid trying to game the > peer into closing. (Connor IIRC?). > > It makes sense to combine these into a single `commitment_style2` > feature, rather than having a testing matrix of all these disabled and > enabled. > > BOLT #2: > > - If `commitment_style2` negotiated, update_fee is a protocol error. > > This mainly changes BOLT #3: > > - The feerate for commitment transactions is always 253 satoshi/Sipa. > - Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi. > - Fees, OP_TRUE are always paid by the initial funder, because it's simple, > unless they don't have funds (eg. push_msat can do this, unless we > remove it?) > - HTLC-timeout and HTLC-success txs sigs are > SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees. > - `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. Two-stage because we can have 2^48 txs and > BIP-32 only supports 2^31: the first 17 bits are used to derive the > parent for the next 31 bits? > - `to_self_delay` for both sides is the maximum of either the > `open_channel` or `accept_channel`. > - `to_remote` is now a P2WSH of: > `to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG > > Cheers, > Rusty. > > [1] I recently removed checking this field from c-lightning, as I > couldn't get it to reliably work under stress-test. I may just have > a bug, but we could just fix the spec instead, then we can get our > funds back even if we never talk to the peer. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
