Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-06 📝 Original message: Olaoluwa Osuntokun ...
📅 Original date posted:2018-11-06
📝 Original message:
Olaoluwa Osuntokun <laolu32 at 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.
📝 Original message:
Olaoluwa Osuntokun <laolu32 at 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.