From laolu32 at gmail.com Tue Nov 6 06:03:19 2018 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Tue, 6 Nov 2018 17:03:19 +1100 Subject: [Lightning-dev] Commitment Transaction Format Update Proposals? In-Reply-To: References: <87in2769wc.fsf@rustcorp.com.au> Message-ID: > 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" Scratch that: the static back ups just need to include this CSV value! -- Laolu On Tue, Nov 6, 2018 at 3:29 PM Olaoluwa Osuntokun wrote: > 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 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 > 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 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 at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: