Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-06 📝 Original message: > This seems at odds with ...
📅 Original date posted:2018-11-06
📝 Original message:
> 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 <laolu32 at gmail.com> 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 <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 <rusty at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/237c144f/attachment-0001.html>;
📝 Original message:
> 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 <laolu32 at gmail.com> 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 <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 <rusty at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/237c144f/attachment-0001.html>;