option_static_remotekey

[rustyrussell]

This is now just removing key rotation (no CSV symmetry). I've used the placeholder optnum 48/49, we can assign a proper one at the meeting if accepted.

I have implemented this in c-lightning as an EXPERIMENTAL_FEATURES option, but not yet merged. It seems to work, and I also have protocol tests for it.

[cfromknecht]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

[rustyrussell]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

[araspitzu]

Suggested change

	`option_simplified_commitment` is not negotiated.
	`option_static_remotekey` is not negotiated.

[rustyrussell]

Rebased to fix minor conflicts, and added minor fixes in separate commit.

[rustyrussell]

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

[sstone]

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

[Roasbeef]

Adding a CSV value makes the recovery case less self contained. The most important part about this change is making recovery of funds in the case of disaster much easier. I'd say the current nonce usage is the #1 reason users lose money on the network: they delete their app or state for w/e reason, then have lost hope even if they have a seed of some sort. Even just yesterday I met a user that lost funds in this very fashion. Remedying this situation should be amongst our highest priorities. The CSV change is a larger change that is more subtle and has affects on the incentives of the system that should be considered in isolation of making Lightning safer for the end user. In terms of fees/chain space, the straight shot output also reduces total on chain traffic as there're less sweeps required per force close. IMO, the bigger incentive issue at play is the fact that the initiator is the one that pays all fees on the commitment transaction atm.

…

On Sun, Sep 15, 2019, 7:50 PM Fabrice Drouin ***@***.***> wrote: It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today. With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet. With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate. This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLS7XBGH252NOYS55RTQJZRWTANCNFSM4IELENQA> .

[sstone]

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

[Roasbeef]

It means that if I lose data, then when the other party force closes, the funds go directly to my wallet. Surely you've encountered users that have deleted an app for w/e reason or their application state and have lost funds. This makes the recovery case even easier, resulting in less users funds being lost, or put at risk needing to be rescued via manual action. This is the #1 thing that confuses users: what do you mean if they force close the funds don't go directly into my wallet?? I need to receive some information from the other party to receive my funds once again? What if they don't always send me that information after they close out the channel (which only lnd does), does that mean my coins are lost? As is today, you'd want to do a cooperative close as you'll negotiate lower fees since the fee on the commitment transaction serves as an upper limit on the fees paid. A cooperative close also allows you to more freely send the funds elsewhere from the channel vs a force close which means the funds must be sent to a predetermined key.

…

On Sun, Sep 15, 2019 at 1:16 PM Fabrice Drouin ***@***.***> wrote: Adding a CSV value makes the recovery case less self contained. What does that mean ? Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLXQPGGJ764YXLYAQMTQJ2J2BANCNFSM4IELENQA> .

[SomberNight]

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

[Roasbeef]

Witness v1 is some ways off. Even then, wallets won't cease to use BIP 49, as there'll need to be a transition period. Even now not all outputs use witness v0, and I don't expect there ever to be 100% utilization.

…

On Mon, Sep 16, 2019, 12:12 AM ghost43 ***@***.***> wrote: With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key Having you peer include in its commit tx an output that sends directly to your wallet Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper. My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVEBMDJOLCZVRR3UTDQJ2QKVANCNFSM4IELENQA> .

[SomberNight]

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

[sstone]

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

[Roasbeef]

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

[rustyrussell]

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

[Roasbeef]

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

[Roasbeef]

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

[Roasbeef]

LGTM 🍕

[cfromknecht]

needs rebase!!

[rustyrussell]

Trivial rebase, and collapsed into a single commit.

[murchandamus]

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

[Roasbeef]

That's an implementation detail.

…

On Wed, Oct 9, 2019, 9:42 AM Mark Erhardt ***@***.***> wrote: Clarifying question: does this allow only to set an address from the Lightning Client's wallet, or would it be allowed to set an arbitrary address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#642>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTWLWKUIS5YBETCKDKIJTQNYCX3ANCNFSM4IELENQA> .

[blacktemplar]

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.

[rustyrussell]

This is now just removing key rotation (no CSV symmetry). I've used the placeholder optnum 48/49, we can assign a proper one at the meeting if accepted.

I have implemented this in c-lightning as an EXPERIMENTAL_FEATURES option, but not yet merged. It seems to work, and I also have protocol tests for it.

[cfromknecht]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

[rustyrussell]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

[araspitzu]

Suggested change

	`option_simplified_commitment` is not negotiated.
	`option_static_remotekey` is not negotiated.

[rustyrussell]

Rebased to fix minor conflicts, and added minor fixes in separate commit.

[rustyrussell]

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

[sstone]

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

[Roasbeef]

Adding a CSV value makes the recovery case less self contained. The most important part about this change is making recovery of funds in the case of disaster much easier. I'd say the current nonce usage is the #1 reason users lose money on the network: they delete their app or state for w/e reason, then have lost hope even if they have a seed of some sort. Even just yesterday I met a user that lost funds in this very fashion. Remedying this situation should be amongst our highest priorities. The CSV change is a larger change that is more subtle and has affects on the incentives of the system that should be considered in isolation of making Lightning safer for the end user. In terms of fees/chain space, the straight shot output also reduces total on chain traffic as there're less sweeps required per force close. IMO, the bigger incentive issue at play is the fact that the initiator is the one that pays all fees on the commitment transaction atm.

…

On Sun, Sep 15, 2019, 7:50 PM Fabrice Drouin ***@***.***> wrote: It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today. With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet. With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate. This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLS7XBGH252NOYS55RTQJZRWTANCNFSM4IELENQA> .

[sstone]

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

[Roasbeef]

It means that if I lose data, then when the other party force closes, the funds go directly to my wallet. Surely you've encountered users that have deleted an app for w/e reason or their application state and have lost funds. This makes the recovery case even easier, resulting in less users funds being lost, or put at risk needing to be rescued via manual action. This is the #1 thing that confuses users: what do you mean if they force close the funds don't go directly into my wallet?? I need to receive some information from the other party to receive my funds once again? What if they don't always send me that information after they close out the channel (which only lnd does), does that mean my coins are lost? As is today, you'd want to do a cooperative close as you'll negotiate lower fees since the fee on the commitment transaction serves as an upper limit on the fees paid. A cooperative close also allows you to more freely send the funds elsewhere from the channel vs a force close which means the funds must be sent to a predetermined key.

…

On Sun, Sep 15, 2019 at 1:16 PM Fabrice Drouin ***@***.***> wrote: Adding a CSV value makes the recovery case less self contained. What does that mean ? Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLXQPGGJ764YXLYAQMTQJ2J2BANCNFSM4IELENQA> .

[SomberNight]

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

[Roasbeef]

Witness v1 is some ways off. Even then, wallets won't cease to use BIP 49, as there'll need to be a transition period. Even now not all outputs use witness v0, and I don't expect there ever to be 100% utilization.

…

On Mon, Sep 16, 2019, 12:12 AM ghost43 ***@***.***> wrote: With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key Having you peer include in its commit tx an output that sends directly to your wallet Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper. My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVEBMDJOLCZVRR3UTDQJ2QKVANCNFSM4IELENQA> .

[SomberNight]

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

[sstone]

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

[Roasbeef]

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

[rustyrussell]

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

[Roasbeef]

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

[Roasbeef]

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

[Roasbeef]

LGTM 🍕

[cfromknecht]

needs rebase!!

[rustyrussell]

Trivial rebase, and collapsed into a single commit.

[murchandamus]

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

[Roasbeef]

That's an implementation detail.

…

On Wed, Oct 9, 2019, 9:42 AM Mark Erhardt ***@***.***> wrote: Clarifying question: does this allow only to set an address from the Lightning Client's wallet, or would it be allowed to set an arbitrary address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#642>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTWLWKUIS5YBETCKDKIJTQNYCX3ANCNFSM4IELENQA> .

[blacktemplar]

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.

[rustyrussell]

This is now just removing key rotation (no CSV symmetry). I've used the placeholder optnum 48/49, we can assign a proper one at the meeting if accepted.

I have implemented this in c-lightning as an EXPERIMENTAL_FEATURES option, but not yet merged. It seems to work, and I also have protocol tests for it.

[cfromknecht]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

[rustyrussell]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

[araspitzu]

Suggested change

	`option_simplified_commitment` is not negotiated.
	`option_static_remotekey` is not negotiated.

[rustyrussell]

Rebased to fix minor conflicts, and added minor fixes in separate commit.

[rustyrussell]

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

[sstone]

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

[Roasbeef]

Adding a CSV value makes the recovery case less self contained. The most important part about this change is making recovery of funds in the case of disaster much easier. I'd say the current nonce usage is the #1 reason users lose money on the network: they delete their app or state for w/e reason, then have lost hope even if they have a seed of some sort. Even just yesterday I met a user that lost funds in this very fashion. Remedying this situation should be amongst our highest priorities. The CSV change is a larger change that is more subtle and has affects on the incentives of the system that should be considered in isolation of making Lightning safer for the end user. In terms of fees/chain space, the straight shot output also reduces total on chain traffic as there're less sweeps required per force close. IMO, the bigger incentive issue at play is the fact that the initiator is the one that pays all fees on the commitment transaction atm.

…

On Sun, Sep 15, 2019, 7:50 PM Fabrice Drouin ***@***.***> wrote: It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today. With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet. With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate. This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLS7XBGH252NOYS55RTQJZRWTANCNFSM4IELENQA> .

[sstone]

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

[Roasbeef]

It means that if I lose data, then when the other party force closes, the funds go directly to my wallet. Surely you've encountered users that have deleted an app for w/e reason or their application state and have lost funds. This makes the recovery case even easier, resulting in less users funds being lost, or put at risk needing to be rescued via manual action. This is the #1 thing that confuses users: what do you mean if they force close the funds don't go directly into my wallet?? I need to receive some information from the other party to receive my funds once again? What if they don't always send me that information after they close out the channel (which only lnd does), does that mean my coins are lost? As is today, you'd want to do a cooperative close as you'll negotiate lower fees since the fee on the commitment transaction serves as an upper limit on the fees paid. A cooperative close also allows you to more freely send the funds elsewhere from the channel vs a force close which means the funds must be sent to a predetermined key.

…

On Sun, Sep 15, 2019 at 1:16 PM Fabrice Drouin ***@***.***> wrote: Adding a CSV value makes the recovery case less self contained. What does that mean ? Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLXQPGGJ764YXLYAQMTQJ2J2BANCNFSM4IELENQA> .

[SomberNight]

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

[Roasbeef]

Witness v1 is some ways off. Even then, wallets won't cease to use BIP 49, as there'll need to be a transition period. Even now not all outputs use witness v0, and I don't expect there ever to be 100% utilization.

…

On Mon, Sep 16, 2019, 12:12 AM ghost43 ***@***.***> wrote: With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key Having you peer include in its commit tx an output that sends directly to your wallet Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper. My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVEBMDJOLCZVRR3UTDQJ2QKVANCNFSM4IELENQA> .

[SomberNight]

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

[sstone]

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

[Roasbeef]

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

[rustyrussell]

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

[Roasbeef]

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

[Roasbeef]

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

[Roasbeef]

LGTM 🍕

[cfromknecht]

needs rebase!!

[rustyrussell]

Trivial rebase, and collapsed into a single commit.

[murchandamus]

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

[Roasbeef]

That's an implementation detail.

…

On Wed, Oct 9, 2019, 9:42 AM Mark Erhardt ***@***.***> wrote: Clarifying question: does this allow only to set an address from the Lightning Client's wallet, or would it be allowed to set an arbitrary address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#642>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTWLWKUIS5YBETCKDKIJTQNYCX3ANCNFSM4IELENQA> .

[blacktemplar]

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.

[rustyrussell]

This is now just removing key rotation (no CSV symmetry). I've used the placeholder optnum 48/49, we can assign a proper one at the meeting if accepted.

I have implemented this in c-lightning as an EXPERIMENTAL_FEATURES option, but not yet merged. It seems to work, and I also have protocol tests for it.

[cfromknecht]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

[rustyrussell]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

[araspitzu]

Suggested change

	`option_simplified_commitment` is not negotiated.
	`option_static_remotekey` is not negotiated.

[rustyrussell]

Rebased to fix minor conflicts, and added minor fixes in separate commit.

[rustyrussell]

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

[sstone]

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

[Roasbeef]

Adding a CSV value makes the recovery case less self contained. The most important part about this change is making recovery of funds in the case of disaster much easier. I'd say the current nonce usage is the #1 reason users lose money on the network: they delete their app or state for w/e reason, then have lost hope even if they have a seed of some sort. Even just yesterday I met a user that lost funds in this very fashion. Remedying this situation should be amongst our highest priorities. The CSV change is a larger change that is more subtle and has affects on the incentives of the system that should be considered in isolation of making Lightning safer for the end user. In terms of fees/chain space, the straight shot output also reduces total on chain traffic as there're less sweeps required per force close. IMO, the bigger incentive issue at play is the fact that the initiator is the one that pays all fees on the commitment transaction atm.

…

On Sun, Sep 15, 2019, 7:50 PM Fabrice Drouin ***@***.***> wrote: It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today. With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet. With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate. This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLS7XBGH252NOYS55RTQJZRWTANCNFSM4IELENQA> .

[sstone]

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

[Roasbeef]

It means that if I lose data, then when the other party force closes, the funds go directly to my wallet. Surely you've encountered users that have deleted an app for w/e reason or their application state and have lost funds. This makes the recovery case even easier, resulting in less users funds being lost, or put at risk needing to be rescued via manual action. This is the #1 thing that confuses users: what do you mean if they force close the funds don't go directly into my wallet?? I need to receive some information from the other party to receive my funds once again? What if they don't always send me that information after they close out the channel (which only lnd does), does that mean my coins are lost? As is today, you'd want to do a cooperative close as you'll negotiate lower fees since the fee on the commitment transaction serves as an upper limit on the fees paid. A cooperative close also allows you to more freely send the funds elsewhere from the channel vs a force close which means the funds must be sent to a predetermined key.

…

On Sun, Sep 15, 2019 at 1:16 PM Fabrice Drouin ***@***.***> wrote: Adding a CSV value makes the recovery case less self contained. What does that mean ? Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLXQPGGJ764YXLYAQMTQJ2J2BANCNFSM4IELENQA> .

[SomberNight]

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

[Roasbeef]

Witness v1 is some ways off. Even then, wallets won't cease to use BIP 49, as there'll need to be a transition period. Even now not all outputs use witness v0, and I don't expect there ever to be 100% utilization.

…

On Mon, Sep 16, 2019, 12:12 AM ghost43 ***@***.***> wrote: With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key Having you peer include in its commit tx an output that sends directly to your wallet Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper. My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVEBMDJOLCZVRR3UTDQJ2QKVANCNFSM4IELENQA> .

[SomberNight]

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

[sstone]

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

[Roasbeef]

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

[rustyrussell]

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

[Roasbeef]

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

[Roasbeef]

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

[Roasbeef]

LGTM 🍕

[cfromknecht]

needs rebase!!

[rustyrussell]

Trivial rebase, and collapsed into a single commit.

[murchandamus]

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

[Roasbeef]

That's an implementation detail.

…

On Wed, Oct 9, 2019, 9:42 AM Mark Erhardt ***@***.***> wrote: Clarifying question: does this allow only to set an address from the Lightning Client's wallet, or would it be allowed to set an arbitrary address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#642>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTWLWKUIS5YBETCKDKIJTQNYCX3ANCNFSM4IELENQA> .

[blacktemplar]

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.

[rustyrussell]

This is now just removing key rotation (no CSV symmetry). I've used the placeholder optnum 48/49, we can assign a proper one at the meeting if accepted.

I have implemented this in c-lightning as an EXPERIMENTAL_FEATURES option, but not yet merged. It seems to work, and I also have protocol tests for it.

[cfromknecht]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

[rustyrussell]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

[araspitzu]

Suggested change

	`option_simplified_commitment` is not negotiated.
	`option_static_remotekey` is not negotiated.

[rustyrussell]

Rebased to fix minor conflicts, and added minor fixes in separate commit.

[rustyrussell]

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

[sstone]

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

[Roasbeef]

Adding a CSV value makes the recovery case less self contained. The most important part about this change is making recovery of funds in the case of disaster much easier. I'd say the current nonce usage is the #1 reason users lose money on the network: they delete their app or state for w/e reason, then have lost hope even if they have a seed of some sort. Even just yesterday I met a user that lost funds in this very fashion. Remedying this situation should be amongst our highest priorities. The CSV change is a larger change that is more subtle and has affects on the incentives of the system that should be considered in isolation of making Lightning safer for the end user. In terms of fees/chain space, the straight shot output also reduces total on chain traffic as there're less sweeps required per force close. IMO, the bigger incentive issue at play is the fact that the initiator is the one that pays all fees on the commitment transaction atm.

…

On Sun, Sep 15, 2019, 7:50 PM Fabrice Drouin ***@***.***> wrote: It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today. With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet. With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate. This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLS7XBGH252NOYS55RTQJZRWTANCNFSM4IELENQA> .

[sstone]

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

[Roasbeef]

It means that if I lose data, then when the other party force closes, the funds go directly to my wallet. Surely you've encountered users that have deleted an app for w/e reason or their application state and have lost funds. This makes the recovery case even easier, resulting in less users funds being lost, or put at risk needing to be rescued via manual action. This is the #1 thing that confuses users: what do you mean if they force close the funds don't go directly into my wallet?? I need to receive some information from the other party to receive my funds once again? What if they don't always send me that information after they close out the channel (which only lnd does), does that mean my coins are lost? As is today, you'd want to do a cooperative close as you'll negotiate lower fees since the fee on the commitment transaction serves as an upper limit on the fees paid. A cooperative close also allows you to more freely send the funds elsewhere from the channel vs a force close which means the funds must be sent to a predetermined key.

…

On Sun, Sep 15, 2019 at 1:16 PM Fabrice Drouin ***@***.***> wrote: Adding a CSV value makes the recovery case less self contained. What does that mean ? Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLXQPGGJ764YXLYAQMTQJ2J2BANCNFSM4IELENQA> .

[SomberNight]

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

[Roasbeef]

Witness v1 is some ways off. Even then, wallets won't cease to use BIP 49, as there'll need to be a transition period. Even now not all outputs use witness v0, and I don't expect there ever to be 100% utilization.

…

On Mon, Sep 16, 2019, 12:12 AM ghost43 ***@***.***> wrote: With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key Having you peer include in its commit tx an output that sends directly to your wallet Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper. My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVEBMDJOLCZVRR3UTDQJ2QKVANCNFSM4IELENQA> .

[SomberNight]

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

[sstone]

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

[Roasbeef]

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

[rustyrussell]

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

[Roasbeef]

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

[Roasbeef]

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

[Roasbeef]

LGTM 🍕

[cfromknecht]

needs rebase!!

[rustyrussell]

Trivial rebase, and collapsed into a single commit.

[murchandamus]

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

[Roasbeef]

That's an implementation detail.

…

On Wed, Oct 9, 2019, 9:42 AM Mark Erhardt ***@***.***> wrote: Clarifying question: does this allow only to set an address from the Lightning Client's wallet, or would it be allowed to set an arbitrary address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#642>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTWLWKUIS5YBETCKDKIJTQNYCX3ANCNFSM4IELENQA> .

[blacktemplar]

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.

[rustyrussell]

This is now just removing key rotation (no CSV symmetry). I've used the placeholder optnum 48/49, we can assign a proper one at the meeting if accepted.

I have implemented this in c-lightning as an EXPERIMENTAL_FEATURES option, but not yet merged. It seems to work, and I also have protocol tests for it.

[cfromknecht]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

[rustyrussell]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

[araspitzu]

Suggested change

	`option_simplified_commitment` is not negotiated.
	`option_static_remotekey` is not negotiated.

[rustyrussell]

Rebased to fix minor conflicts, and added minor fixes in separate commit.

[rustyrussell]

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

[sstone]

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

[Roasbeef]

Adding a CSV value makes the recovery case less self contained. The most important part about this change is making recovery of funds in the case of disaster much easier. I'd say the current nonce usage is the #1 reason users lose money on the network: they delete their app or state for w/e reason, then have lost hope even if they have a seed of some sort. Even just yesterday I met a user that lost funds in this very fashion. Remedying this situation should be amongst our highest priorities. The CSV change is a larger change that is more subtle and has affects on the incentives of the system that should be considered in isolation of making Lightning safer for the end user. In terms of fees/chain space, the straight shot output also reduces total on chain traffic as there're less sweeps required per force close. IMO, the bigger incentive issue at play is the fact that the initiator is the one that pays all fees on the commitment transaction atm.

…

On Sun, Sep 15, 2019, 7:50 PM Fabrice Drouin ***@***.***> wrote: It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today. With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet. With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate. This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLS7XBGH252NOYS55RTQJZRWTANCNFSM4IELENQA> .

[sstone]

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

[Roasbeef]

It means that if I lose data, then when the other party force closes, the funds go directly to my wallet. Surely you've encountered users that have deleted an app for w/e reason or their application state and have lost funds. This makes the recovery case even easier, resulting in less users funds being lost, or put at risk needing to be rescued via manual action. This is the #1 thing that confuses users: what do you mean if they force close the funds don't go directly into my wallet?? I need to receive some information from the other party to receive my funds once again? What if they don't always send me that information after they close out the channel (which only lnd does), does that mean my coins are lost? As is today, you'd want to do a cooperative close as you'll negotiate lower fees since the fee on the commitment transaction serves as an upper limit on the fees paid. A cooperative close also allows you to more freely send the funds elsewhere from the channel vs a force close which means the funds must be sent to a predetermined key.

…

On Sun, Sep 15, 2019 at 1:16 PM Fabrice Drouin ***@***.***> wrote: Adding a CSV value makes the recovery case less self contained. What does that mean ? Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLXQPGGJ764YXLYAQMTQJ2J2BANCNFSM4IELENQA> .

[SomberNight]

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

[Roasbeef]

Witness v1 is some ways off. Even then, wallets won't cease to use BIP 49, as there'll need to be a transition period. Even now not all outputs use witness v0, and I don't expect there ever to be 100% utilization.

…

On Mon, Sep 16, 2019, 12:12 AM ghost43 ***@***.***> wrote: With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key Having you peer include in its commit tx an output that sends directly to your wallet Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper. My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVEBMDJOLCZVRR3UTDQJ2QKVANCNFSM4IELENQA> .

[SomberNight]

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

[sstone]

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

[Roasbeef]

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

[rustyrussell]

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

[Roasbeef]

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

[Roasbeef]

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

[Roasbeef]

LGTM 🍕

[cfromknecht]

needs rebase!!

[rustyrussell]

Trivial rebase, and collapsed into a single commit.

[murchandamus]

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

[Roasbeef]

That's an implementation detail.

…

On Wed, Oct 9, 2019, 9:42 AM Mark Erhardt ***@***.***> wrote: Clarifying question: does this allow only to set an address from the Lightning Client's wallet, or would it be allowed to set an arbitrary address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#642>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTWLWKUIS5YBETCKDKIJTQNYCX3ANCNFSM4IELENQA> .

[blacktemplar]

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.

[rustyrussell]

This is now just removing key rotation (no CSV symmetry). I've used the placeholder optnum 48/49, we can assign a proper one at the meeting if accepted.

I have implemented this in c-lightning as an EXPERIMENTAL_FEATURES option, but not yet merged. It seems to work, and I also have protocol tests for it.

[cfromknecht]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

[rustyrussell]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

[araspitzu]

Suggested change

	`option_simplified_commitment` is not negotiated.
	`option_static_remotekey` is not negotiated.

[rustyrussell]

Rebased to fix minor conflicts, and added minor fixes in separate commit.

[rustyrussell]

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

[sstone]

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

[Roasbeef]

Adding a CSV value makes the recovery case less self contained. The most important part about this change is making recovery of funds in the case of disaster much easier. I'd say the current nonce usage is the #1 reason users lose money on the network: they delete their app or state for w/e reason, then have lost hope even if they have a seed of some sort. Even just yesterday I met a user that lost funds in this very fashion. Remedying this situation should be amongst our highest priorities. The CSV change is a larger change that is more subtle and has affects on the incentives of the system that should be considered in isolation of making Lightning safer for the end user. In terms of fees/chain space, the straight shot output also reduces total on chain traffic as there're less sweeps required per force close. IMO, the bigger incentive issue at play is the fact that the initiator is the one that pays all fees on the commitment transaction atm.

…

On Sun, Sep 15, 2019, 7:50 PM Fabrice Drouin ***@***.***> wrote: It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today. With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet. With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate. This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLS7XBGH252NOYS55RTQJZRWTANCNFSM4IELENQA> .

[sstone]

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

[Roasbeef]

It means that if I lose data, then when the other party force closes, the funds go directly to my wallet. Surely you've encountered users that have deleted an app for w/e reason or their application state and have lost funds. This makes the recovery case even easier, resulting in less users funds being lost, or put at risk needing to be rescued via manual action. This is the #1 thing that confuses users: what do you mean if they force close the funds don't go directly into my wallet?? I need to receive some information from the other party to receive my funds once again? What if they don't always send me that information after they close out the channel (which only lnd does), does that mean my coins are lost? As is today, you'd want to do a cooperative close as you'll negotiate lower fees since the fee on the commitment transaction serves as an upper limit on the fees paid. A cooperative close also allows you to more freely send the funds elsewhere from the channel vs a force close which means the funds must be sent to a predetermined key.

…

On Sun, Sep 15, 2019 at 1:16 PM Fabrice Drouin ***@***.***> wrote: Adding a CSV value makes the recovery case less self contained. What does that mean ? Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLXQPGGJ764YXLYAQMTQJ2J2BANCNFSM4IELENQA> .

[SomberNight]

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

[Roasbeef]

Witness v1 is some ways off. Even then, wallets won't cease to use BIP 49, as there'll need to be a transition period. Even now not all outputs use witness v0, and I don't expect there ever to be 100% utilization.

…

On Mon, Sep 16, 2019, 12:12 AM ghost43 ***@***.***> wrote: With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key Having you peer include in its commit tx an output that sends directly to your wallet Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper. My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVEBMDJOLCZVRR3UTDQJ2QKVANCNFSM4IELENQA> .

[SomberNight]

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

[sstone]

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

[Roasbeef]

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

[rustyrussell]

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

[Roasbeef]

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

[Roasbeef]

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

[Roasbeef]

LGTM 🍕

[cfromknecht]

needs rebase!!

[rustyrussell]

Trivial rebase, and collapsed into a single commit.

[murchandamus]

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

[Roasbeef]

That's an implementation detail.

…

On Wed, Oct 9, 2019, 9:42 AM Mark Erhardt ***@***.***> wrote: Clarifying question: does this allow only to set an address from the Lightning Client's wallet, or would it be allowed to set an arbitrary address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#642>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTWLWKUIS5YBETCKDKIJTQNYCX3ANCNFSM4IELENQA> .

[blacktemplar]

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.

[rustyrussell]

This is now just removing key rotation (no CSV symmetry). I've used the placeholder optnum 48/49, we can assign a proper one at the meeting if accepted.

I have implemented this in c-lightning as an EXPERIMENTAL_FEATURES option, but not yet merged. It seems to work, and I also have protocol tests for it.

[cfromknecht]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

[rustyrussell]

Thanks @rustyrussell, definitely like the size of diff :)

Do we also want to modify the derivations described in BOLT 3 to say that that the payment_basepoint is not tweaked?

Huh, somehow my rebase lost that part! I def did edit that, will push...

[araspitzu]

Suggested change

	`option_simplified_commitment` is not negotiated.
	`option_static_remotekey` is not negotiated.

[rustyrussell]

Rebased to fix minor conflicts, and added minor fixes in separate commit.

[rustyrussell]

OK, I am now running this on my two main test nodes:

mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605
testnet: 031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769

[sstone]

It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today.

With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet.

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate.

This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game.

[Roasbeef]

Adding a CSV value makes the recovery case less self contained. The most important part about this change is making recovery of funds in the case of disaster much easier. I'd say the current nonce usage is the #1 reason users lose money on the network: they delete their app or state for w/e reason, then have lost hope even if they have a seed of some sort. Even just yesterday I met a user that lost funds in this very fashion. Remedying this situation should be amongst our highest priorities. The CSV change is a larger change that is more subtle and has affects on the incentives of the system that should be considered in isolation of making Lightning safer for the end user. In terms of fees/chain space, the straight shot output also reduces total on chain traffic as there're less sweeps required per force close. IMO, the bigger incentive issue at play is the fact that the initiator is the one that pays all fees on the commitment transaction atm.

…

On Sun, Sep 15, 2019, 7:50 PM Fabrice Drouin ***@***.***> wrote: It just hit me that switching to static remote keys without adding a CSV delay, as for the to-local keys, is making incentives for using mutual vs force close worse than they are today. With the current specs, not having a delay on the to-remote is already a problem: if you can get your peer to publish their commit tx, you get a UTXO that you can spend right away, while they have to wait to spend theirs. However, most implementations will use BIP32 wallets and will want spend this output (and pay onchain fees) and send it to a wallet key, as it makes backup/restore of onchain funds much easier (you just need your seed). So it's still better to negotiate a mutual close whenever possible, as it will return your funds directly to your BIP32 wallet. With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key, which means that in practice getting your peers to publish their commit tx will always be the fastest solution, and could also be the cheapest if fees are going up and you don't want to negotiate. This is why I would strongly prefer that we add a CSV delay to the to-remote output: users would then have an incentive to mutual close channels whenever possible, and not play the "get your peer to close first" game. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLS7XBGH252NOYS55RTQJZRWTANCNFSM4IELENQA> .

[sstone]

Adding a CSV value makes the recovery case less self contained.

What does that mean ?

Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ?

[Roasbeef]

It means that if I lose data, then when the other party force closes, the funds go directly to my wallet. Surely you've encountered users that have deleted an app for w/e reason or their application state and have lost funds. This makes the recovery case even easier, resulting in less users funds being lost, or put at risk needing to be rescued via manual action. This is the #1 thing that confuses users: what do you mean if they force close the funds don't go directly into my wallet?? I need to receive some information from the other party to receive my funds once again? What if they don't always send me that information after they close out the channel (which only lnd does), does that mean my coins are lost? As is today, you'd want to do a cooperative close as you'll negotiate lower fees since the fee on the commitment transaction serves as an upper limit on the fees paid. A cooperative close also allows you to more freely send the funds elsewhere from the channel vs a force close which means the funds must be sent to a predetermined key.

…

On Sun, Sep 15, 2019 at 1:16 PM Fabrice Drouin ***@***.***> wrote: Adding a CSV value makes the recovery case less self contained. What does that mean ? Having you peer include in its commit tx an output that sends directly to your wallet feels just plain wrong. What is the point of even negotiating a mutual close then ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLXQPGGJ764YXLYAQMTQJ2J2BANCNFSM4IELENQA> .

[SomberNight]

With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key
Having you peer include in its commit tx an output that sends directly to your wallet

Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper.

My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address.

[Roasbeef]

Witness v1 is some ways off. Even then, wallets won't cease to use BIP 49, as there'll need to be a transition period. Even now not all outputs use witness v0, and I don't expect there ever to be 100% utilization.

…

On Mon, Sep 16, 2019, 12:12 AM ghost43 ***@***.***> wrote: With this proposal, without adding a CSV delay to the to-remote output, implementation will most likely set their static remote key to one of their BIP32 wallet key Having you peer include in its commit tx an output that sends directly to your wallet Note that the to-remote-output pays to a p2wpkh script; and longer term there will be wallets who would not by default derive p2wpkh addresses for their main on-chain addresses. E.g. when witness v1 gets soft forked in, some wallets might want to only have witness v1 addresses, and those will then need to sweep the to-remote outputs, at which point a cooperative close paying directly to one of their main witness v1 addresses (as soon as will be allowed for a cooperative close to do so, as it is not atm) would be cheaper. My point is that it's not necessarily a true assumption that the commitment tx having a static p2wpkh output can always directly pay to a main wallet address. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#642>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVEBMDJOLCZVRR3UTDQJ2QKVANCNFSM4IELENQA> .

[SomberNight]

There are already wallets that only derive witness v0 outputs, e.g. Wasabi and Electrum.

edit; and there is no need for a transition period between v0 and v1, as in theory anyone who can pay to v0 can also do so to v1.

[sstone]

@Roasbeef I don't see why adding a delay here prevents you from recovering your funds ? My point is that not having such a delay was bad before and we're making it worse.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

@SomberNight well we'll have eltoo by then won't we :) but it may not be soon...

[Roasbeef]

I don't see why adding a delay here prevents you from recovering your funds ?

It doesn't prevent it, it makes it less self contained: recovery logic now needs additional data (to reconstruct the script).

My point is that not having such a delay was bad before and we're making it worse.

With my response being that the real incentive issue here is the initiator always paying the fees whenever a channel closes.

The fact that you currently need you peer's commit point is a different problem. the to-remote key could have been derived from the remote commit point (I don't think it makes security/privacy worse) and it would have made recovery much simpler.

This is the very problem that's being fixed with this change.

[rustyrussell]

@Roasbeef Meeting nodes say this is pending your ack to merge? Ping!

[Roasbeef]

@rustyrussell needs a rebase! I'll make another PR to add that note re compatibility with detecting proper data loss from state zero.

[Roasbeef]

Actually, the current text looks fine, scratch my last comment, doing one final pass over everything.

[Roasbeef]

LGTM 🍕

[cfromknecht]

needs rebase!!

[rustyrussell]

Trivial rebase, and collapsed into a single commit.

[murchandamus]

This appears to allow to self-select an address from the Lightning Client's wallet only. Is anything planned that would require channels to close to an arbitrary user-selected addresses in the force-close scenario?

[Roasbeef]

That's an implementation detail.

…

On Wed, Oct 9, 2019, 9:42 AM Mark Erhardt ***@***.***> wrote: Clarifying question: does this allow only to set an address from the Lightning Client's wallet, or would it be allowed to set an arbitrary address? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#642>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTWLWKUIS5YBETCKDKIJTQNYCX3ANCNFSM4IELENQA> .

[blacktemplar]

I have a question for this change: With this change is it possible to use low fees on the commitment transaction and in the case of a force close use CPFP to get the transaction through? I really hope this is possible some day since if the fee market gets serious the high fees for commitment transactions serving as an upper bound will be a big problem in my opinion. Using CPFP would enable a much more dynamic fee system and every participant could decide for themselves how fast they need the assets / how much they want to pay for fees.