Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-11-05 Thread Olaoluwa Osuntokun
> 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?

2018-11-05 Thread Rusty Russell
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?

2018-11-05 Thread Olaoluwa Osuntokun
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?

2018-10-23 Thread Rusty Russell
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?

2018-10-20 Thread Jim Posen
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?

2018-10-20 Thread Conner Fromknecht
Good morning everyone,

> We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE
> for HTLC txs, without adding the "OP_TRUE"
> output to the commitment transaction

Doesn’t this require a non-zero number of HTLCs on the commitment txn? We
would still require the OP_TRUE if there are no HTLCs, right?

>From my recollection, HTLC txns with an absolute timeout won’t be accepted
in the mempool until the expiry has matured. So the commitment would have
to be held until that time before it’s descendants can bump the fee rate I
think.

I agree that we should probably modify the HTLC sighashes regardless,
though I wonder if it is a standalone replacement for OP_TRUE.

> 3. The CLTV timeout should be symmetrical to avoid
> trying to game the peer into closing. (Connor IIRC?).

I believe Jimpo proposed this :)

Best,
Conner

On Fri, Oct 19, 2018 at 03:43 Rusty Russell  wrote:

> 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
>
___
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?

2018-10-19 Thread Rusty Russell
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?

2018-10-18 Thread Fabrice Drouin
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.

Cheers,

Fabrice
___
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?

2018-10-12 Thread ZmnSCPxj via Lightning-dev



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?

2018-10-12 Thread Rusty Russell
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?

2018-10-12 Thread ZmnSCPxj via Lightning-dev
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