Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

option_static_remotekey: first draft. #642

Open
wants to merge 2 commits into
base: master
from

Conversation

@rustyrussell
Copy link
Collaborator

commented Jul 17, 2019

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.

option_static_remotekey: first draft.
This separates out the static remotekey changes from the more ambitious
option_simplified_commitment (which also included pushme outputs and
bring-your-own-fee for HTLC outputs).

This is a much simpler stepping stone, and resolves one immediate
problem.

Suggested-by: @Roasbeef
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@cfromknecht
Copy link
Collaborator

left a comment

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?

- if `next_remote_revocation_number` equals 0:
- MUST set `your_last_per_commitment_secret` to all zeroes
- otherwise:
- MUST set `your_last_per_commitment_secret` to the last `per_commitment_secret`
it received
- if `option_static_remotekey` applies to the commitment transaction:
- MUST NOT include `my_current_per_commitment_point`.

This comment has been minimized.

Copy link
@cfromknecht

cfromknecht Jul 18, 2019

Collaborator

does this mean that it should be blank?

Obviously haven't tried to implement it yet, but I'm wondering, do we have to modify this at all? Is it possible to keep all of the DLP handling/derivation the same, but just use the raw payment_basepoint in to_remote outputs?

This comment has been minimized.

Copy link
@rustyrussell

rustyrussell Jul 18, 2019

Author Collaborator

No, I want to kill it. It's under-defined, it's been a source of problems, and even now I suspect we're seeing disagreements between c-lightning and lnd: I'm seeing sync error far too often.

So, not blank, literally not present. Of course, recipient will ignore anyway, but next extension may rely on this by appending a TLV...

This comment has been minimized.

Copy link
@cfromknecht

cfromknecht Jul 18, 2019

Collaborator

It still seems orthogonal to not tweaking the to_remote outputs. I can't imagine adding more logic in this area is going to improve the issues we're seeing... :)

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Jul 27, 2019

Member

If we want to add additional fields to this in the future, then we can't have it be absent, since w/o TLV, we don't actually have "optional fields".

@rustyrussell

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 18, 2019

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...

BOLT 3: Update derivation for option_static_remotekey
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The simplified derivation means that a node can spend a commitment
transaction even if it has lost data and doesn't know the
corresponding `payment_basepoint`. A watchtower could correlate

This comment has been minimized.

Copy link
@cfromknecht

cfromknecht Jul 18, 2019

Collaborator

is this meant to be per_commitment_point?

removed, but the disclosure of previous secret still allows
fall-behind detection. An implementation can offer both, however, and
fall back to the `option_data_loss_protect` behavior if
`option_simplified_commitment` is not negotiated.

This comment has been minimized.

Copy link
@araspitzu

araspitzu Jul 19, 2019

Contributor
Suggested change
`option_simplified_commitment` is not negotiated.
`option_static_remotekey` is not negotiated.
#### Rationale

We decide on `option_static_remotekey` at this point when we first have to generate the commitment
transaction. Even if a later reconnection does not negotiate this parameter, this channel will honor it.

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Jul 27, 2019

Member

What does the second sentence mean? That this is actually a connection level value, rather than local to this specific channel negotiation?

fields are present:
- if `option_static_remotekey` applies to the commitment transaction:
- if `next_remote_revocation_number` is greater than expected above, AND
`your_last_per_commitment_secret` is correct for that

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Jul 27, 2019

Member

Not a big deal, but there's a bit of duplication here and below.

@@ -26,6 +26,7 @@ These flags may only be used in the `init` message:
| 3 | `initial_routing_sync` | Indicates that the sending node needs a complete routing information dump | [BOLT #7](07-routing-gossip.md#initial-sync) |
| 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
| 6/7 | `gossip_queries` | More sophisticated gossip control | [BOLT #7](07-routing-gossip.md#query-messages) |
| 48/49| `option_static_remotekey` | Static key for remote output | [BOLT #3](03-transactions.md) |

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Jul 27, 2019

Member

IMO this should also be a global feature bit, so nodes can opt to only open channels to other nodes that support this new "safu commitment".

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Jul 31, 2019

Member

Also why not in order? So 10/11?

@@ -366,6 +366,12 @@ This message introduces the `channel_id` to identify the channel. It's derived f

#### Requirements

Both peers:

This comment has been minimized.

Copy link
@Roasbeef

Roasbeef Aug 1, 2019

Member

I think we may also want to define a new bit in the funding flags within the OpenChannel message to allow nodes to modulate this value, since there'll be optional and required feature bits for it. It'll take some time for channels to switch over (since I don't foresee the entire networking shutting down and transitioning to this new channel type). For some period of time, implementations will need to understand both the old and new commitment types, and a node can't feasible only use this new channel type.

If we add a new funding flag, then we'll be able to easily flip it via a config option or the like to ensure we all still understand the old and new formats. This will also be useful for new implementations as they'll still need to interface with the rest of the legacy network.

In short I propose two signalling venues:

  • the global feature bit
  • a new defined in in the open_channel message's funding flags
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants
You can’t perform that action at this time.