Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
> 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@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
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
Olaoluwa Osuntokun 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 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 Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
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@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
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
Jim Posen writes: > Instead of leaving an extra output for CPFP, is it not sufficient to just > sign all inputs with ANYONECANPAY and expect the sender to make an exact > output for the fees input? It would require an extra tx assuming they don't > already have a properly sized UTXO handy (which they may!), but I believe > CPFP would require that as well. Am I missing something? Yeah, that would change the txid which the HTLC txs rely on :( > I'm a fan of the symmetric delays because it simplifies the game theory > analysis, but I don't think the delays need to be the same for both > participants (max of `to_self_delay` for both sides), just that the delay > is applied equally regardless of who publishes the commitment tx. Like your > `to_self_delay` can be what I specify and vice versa, what's the reason for > taking the max? If you don't take the max, you're back into the Game Theory. Your delay is short, mine is long, so I want you to drop to chain please. Also, there's a fairness argument: if you want me to suffer a long delay, you should too. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
Instead of leaving an extra output for CPFP, is it not sufficient to just sign all inputs with ANYONECANPAY and expect the sender to make an exact output for the fees input? It would require an extra tx assuming they don't already have a properly sized UTXO handy (which they may!), but I believe CPFP would require that as well. Am I missing something? I'm a fan of the symmetric delays because it simplifies the game theory analysis, but I don't think the delays need to be the same for both participants (max of `to_self_delay` for both sides), just that the delay is applied equally regardless of who publishes the commitment tx. Like your `to_self_delay` can be what I specify and vice versa, what's the reason for taking the max? -jimpo ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
Fabrice Drouin writes: > Hello, > >> 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) > > We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without > adding the "OP_TRUE" output to the commitment transaction. We would still > need the update_fee message to manage onchain fees for the commit tx (but > not the HTLC txs) but there would be no reason anymore to refuse fee rates > that are too high and channels would not get closed anymore when there's a > spike in onchain fees. Agreed, that was in the details below: - HTLC-timeout and HTLC-success txs sigs are SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees. The only problem with these proposals is that it requires you have an available UTXO to make the CPFP etc. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, October 12, 2018 2:36 PM, Rusty Russell wrote: > ZmnSCPxj zmnsc...@protonmail.com writes: > > > Good morning Rusty and list, > > > > > 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) > > > > > > > My understanding is that this would require some base-layer changes at > > Bitcoin level first? At minimum IsStandard() modification, and I believe > > luke-jr suggested, to make a consensus rule that OP_TRUE would not be > > spendable beyond the block it appears in (i.e. it is used only for CPFP > > hooking) to reduce UTXO database size at lower layer. > > If you look further down, it's actually a P2WSH to "OP_TRUE". Wastes > some space, but it works today. Ah, I see. This will change again if the luke-jr proposal pushes through? Will robots arise which will attempt to claim as many OP_TRUE outputs as they can find, claiming them afterwards during very-low-fee periods? > > > > 3. The CLTV timeout should be symmetrical to avoid trying to game the > > > peer into closing. (Connor IIRC?). > > > > > > > I know this has been discussed before, but I wonder the rationale for the > > original asymmetric design, and the rationale for the new symmetric design. > > The original design does the minimum necessary (youmust have a > to-yourself delay to give time for the penalty tx to work). But, when > combined with fee asymmetry (funder pays), it can lead the fundee to not > care whether it forces the funder to perform a unilateral, or does a > graceful mutual close. > > It's not a major issue, but aligning incentives (to mutual close) makes > sense if we're changing other things I think. > I understand. I suppose this is minor improvement. It is also enabled somewhat by item 1 above (OP_TRUE CPFP hook). Currently, advantage of asymmetric is that the other side can CPFP the transaction. Now, with both having a CSV delay, neither side can CPFP, but with the CPFP hook anyone (including robots which might want to opportunistically steal OP_TRUE outputs during low-fee eras) can CPFP the transaction. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
ZmnSCPxj writes: > Good morning Rusty and list, > >> >> 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) >> > > My understanding is that this would require some base-layer changes at > Bitcoin level first? At minimum IsStandard() modification, and I believe > luke-jr suggested, to make a consensus rule that OP_TRUE would not be > spendable beyond the block it appears in (i.e. it is used only for CPFP > hooking) to reduce UTXO database size at lower layer. If you look further down, it's actually a P2WSH to "OP_TRUE". Wastes some space, but it works today. >> 3. The CLTV timeout should be symmetrical to avoid trying to game the >> peer into closing. (Connor IIRC?). > > I know this has been discussed before, but I wonder the rationale for the > original asymmetric design, and the rationale for the new symmetric design. The original design does the minimum necessary (you *must* have a to-yourself delay to give time for the penalty tx to work). But, when combined with fee asymmetry (funder pays), it can lead the fundee to not care whether it forces the funder to perform a unilateral, or does a graceful mutual close. It's not a major issue, but aligning incentives (to mutual close) makes sense if we're changing other things I think. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
Good morning Rusty and list, > > 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) > My understanding is that this would require some base-layer changes at Bitcoin level first? At minimum IsStandard() modification, and I believe luke-jr suggested, to make a consensus rule that OP_TRUE would not be spendable beyond the block it appears in (i.e. it is used only for CPFP hooking) to reduce UTXO database size at lower layer. It seems the other parts of this proposal, do not need this base-layer change; so, this may delay the other parts (but perhaps it is not at all an issue to delay the other parts of this proposal...?). > 3. The CLTV timeout should be symmetrical to avoid trying to game the > peer into closing. (Connor IIRC?). I know this has been discussed before, but I wonder the rationale for the original asymmetric design, and the rationale for the new symmetric design. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
