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.

Sign up for GitHub

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

Jump to bottom

Explicitly allow funding_locked early, and include scid. #895

Closed
wants to merge 1 commit into from
Closed

Explicitly allow funding_locked early, and include scid. #895

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 37 additions & 5 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -409,26 +409,49 @@ this channel will continue to use `option_static_remotekey` or `option_anchor_ou

This message indicates that the funding transaction has reached the `minimum_depth` asked for in `accept_channel`. Once both nodes have sent this, the channel enters normal operating mode.

As an extension, nodes which entirely funded the channel themselves,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs a feature bit, as it would allow nodes that want to actively open these zero conf channels to seek out other peers that want to accept them.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also it's possible some nodes treat the early sending of funding locked as a protocol-level error?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also it's possible some nodes treat the early sending of funding locked as a protocol-level error?

That would be very surprising, you can't be sure that a funding_locked is early, when you think it's early it may be in fact your view of the blockchain that's late. Considering this a protocol error would be a mistake, when you simply need to wait for your view of the blockchain to catch up and send your own funding_locked

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs a feature bit, as it would allow nodes that want to actively open these zero conf channels to seek out other peers that want to accept them.

I'm really hesitant on that one. At first I agreed with you (and we've defined a feature bit for that in Phoenix). But the issue is that it's not actually binding. If Alice advertises that she accepts 0-conf, you open a channel to her, but then in fact she doesn't send her funding_locked early, you'll feel a bit cheated.

But I wouldn't hold a grudge against Alice: it's dangerous for her to accept 0-conf from any random node that comes up, so we can't expect her to universally do 0-conf...she would probably do 0-conf based on a set of heuristics (is she funder or fundee? what channel type is this? is this channel part of a service she benefits from, such as opening on-the-fly for a fee?).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty dubious of this as a general-purpose extension. I'm not sure that, in practice, you'd ever really use this by going out and finding public nodes that accept 0conf payments, its more of an extension for nodes to use when communicating with their wallet vendor's or their own node, ie manually configured.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this proposal would benefit from a feature bit. I can see in the future situation where you're seeking instant inbound liquidity because the missed economic opportunity will cost you higher than the loss multiplied by the odds of double-spend event realization. If one has to probe-and-engage-in-opening %X of the network to see who is willingly to zero-conf you're moving away from the instant effect.

Further, w.r.t to the unsafety of 0-conf, I still think trust won't be binary, one might rely on other heuristics to decide if it's a "random" node or not, e.g already-opened channels, reputation scoring, pre-paid tokens, ...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really hesitant on that one. At first I agreed with you (and we've defined a feature bit for that in Phoenix). But the issue is that it's not actually binding.

So the idea here is to use it along-side the new explicit chan funding feature. We can even make the feature bits dependent on it as well. This way a node can preferentially reject zero conf funding attempts w/ nodes for w/e reason (isn't their wallet provider, etc, etc).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well. This way a node can preferentially reject zero conf funding attempts w/ nodes for w/e reason (isn't their wallet provider, etc, etc).

Why would you do that?

I can see in the future situation where you're seeking instant inbound liquidity because the missed economic opportunity will cost you higher than the loss multiplied by the odds of double-spend event realization. If one has to probe-and-engage-in-opening %X of the network to see who is willingly to zero-conf you're moving away from the instant effect.

Wouldn't this still imply a separate negotiation mechanism? If you want liquidity you'll probably engage one of the two liquidity negotiation markets that exist now. Advertising the bit is explicitly advertising "I am vulnerable to some funds-stealing attacks, please come and get it".

All that said, I think there's room for a feature bit that implies support, but not use, of the new TLV. If we expand the utility here beyond just zero conf to include SCID aliases that can be useful to advertise. Of course then the feature bit would be useless for the purpose of finding peers that will offer you unsafe forwarding features.

Copy link
Collaborator

@t-bast t-bast Aug 31, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the idea here is to use it along-side the new explicit chan funding feature.

Unfortunately even having a channel_type for this doesn't solve the issue, it would still be non-binding.
Even if your peer says ok to a 0-conf channel_type, they may decide to wait for confirmations anyway and you can't do anything about it (apart from avoiding this node in the future).

This matches what Matt says in All that said, I think there's room for a feature bit that implies support, but not use, of the new TLV. . There is some value in advertising "I may do 0-conf for you" with a feature bit, but there's a big red flag that there's no guarantee and peers shouldn't expect it to always be 0-conf.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if your peer says ok to a 0-conf channel_type, they may decide to wait for confirmations anyway and you can't do anything about it (apart from avoiding this node in the future).

Ah yeah totally makes sense, up to them if they send it or not, but either side can sort of initiate it first, letting the other side decide if they wish to cooperate in zero conf land or not. Agreed re a bit for support but not compelling usage of given the way things are specified as is.

or has other reason to trust the peer, can send this message early, and
optionally indicate the short_channel_id they will use to refer to it.


1. type: 36 (`funding_locked`)
2. data:
* [`channel_id`:`channel_id`]
* [`point`:`next_per_commitment_point`]
* [`funding_locked_tlvs`:`tlvs`]

1. `tlv_stream`: `funding_locked_tlvs`
2. types:
1. type: 1 (`short_channel_id`)
2. data:
* [`short_channel_id`:`short_channel_id`]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this scid can be made up? Is the expectation that once it has a stable ID, it's sent each time on reconnection to allow both sides to synchronize?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe name it something like short_channel_id_alias to make the semantics more clear? Presumably the SCID here would be something that the counterparty knows to forward to, so the user could also put it in invoices, etc?


#### Requirements

The sender MUST:
- NOT send `funding_locked` unless outpoint of given by `funding_txid` and
The sender:
- MUST NOT send `funding_locked` unless outpoint of given by `funding_txid` and
`funding_output_index` in the `funding_created` message pays exactly `funding_satoshis` to the scriptpubkey specified in [BOLT #3](03-transactions.md#funding-transaction-output).
- wait until the funding transaction has reached `minimum_depth` before
sending this message.
- set `next_per_commitment_point` to the per-commitment point to be used
- MUST set `next_per_commitment_point` to the per-commitment point to be used
for the following commitment transaction, derived as specified in
[BOLT #3](03-transactions.md#per-commitment-secret-requirements).
- SHOULD set `short_channel_id`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be some restrictions on SCID here if its not real - I think we'll want to avoid accidentally conflicting if we can. IIRC some folks have been using random numbers below the segwit activation height, which seems reasonable, its something like 58 bits which isn't infinite, but probably enough entropy to not worry about it, but that means this should say you MUST set it to a random value or something.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the one hand, you get to set it, if you break it you get to keep both pieces. "I will refer to this channel as X" and then you open a real channel X and you don't know which one to fwd payments to.

But that may not be obvious, so I'll add some advice.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I suppose they aren't used in gossip messages so its maybe ok that they collide? It does feel awkward that we'll let them collide in the spec just because colliding namespaces feel wrong, but I don't see any obvious issues since you can argue its just a local namespace that happens to overlap with a separate global one.

- if it is the sole contributor to the funding transaction, or has reason to trust the peer:
- MAY send `funding_locked` before the funding transaction has reached `minimum_depth`
- MAY set `short_channel_id` to a fake value, if it will route payments to that `short_channel_id`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: indent should be the same as the previous line

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the idea here is to leave the derivation of this value up to both sides? Some implementations of zero conf channels I've seen in the wild, prescribe a schema (like using some bits from the pending chan ID which is selected by the funder as is anyway) so both sides can use the same value until things are confirmed on-chain, and a "real" scid is generated.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, the freedom allowed here to implementations is attractive, since one side is effectively just telling the other "I'm referring to that channel using this value until it confirms". The other direction can use another value as long as the receiver remembers that value (and doesn't even need to write it to disk?) when it sees it in an onion payload.

- otherwise:
- MUST wait until the funding transaction has reached `minimum_depth` before sending this message.
- SHOULD re-transmit `funding_locked` if the `short_channel_id` for this chanel has changed.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necessary? It feels like nodes should instead watch confirmations on the funding tx to figure out the real short_channel_id by themselves instead of trusting anything their peer gives them? But it's true that it doesn't hurt to send it as an FYI...

btw, nit:

Suggested change
- SHOULD re-transmit `funding_locked` if the `short_channel_id` for this chanel has changed.
- SHOULD re-transmit `funding_locked` if the `short_channel_id` for this channel has changed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think this is one of those things where it doesn't hurt, this way nodes explicitly ensure that they're using teh same scid value as otherwise the channel may not be able to be routed over.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably specify the semantics here, though - like, that both SCIDs remain active forever?



The sender:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove?


A non-funding node (fundee):
- SHOULD forget the channel if it does not see the correct funding
transaction after a timeout of 2016 blocks.

The receiver:
- SHOULD ignore the `funding_locked` if it knows the `short_channel_id` of the channel and it differs from the value in `funding_locked`.

From the point of waiting for `funding_locked` onward, either node MAY
fail the channel if it does not receive a required response from the
other node after a reasonable timeout.
Expand All @@ -445,6 +468,15 @@ to broadcast the commitment transaction to get his funds back and open a new
channel. To avoid this, the funder should ensure the funding transaction
confirms in the next 2016 blocks.

Nodes which have funded the channel or trust their peers to have done,
can simply start using the channel instantly by sending
`funding_locked`. This raises the problem of how to use this new
channel in route hints, since it does not yet have a block number.
For this reason, a convincing fake number can be use; when the real
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit:

Suggested change
For this reason, a convincing fake number can be use; when the real
For this reason, a convincing fake number can be used; when the real

funding transaction is finally mined, it can re-send `funding_locked`
with the real value.


## Channel Close

Nodes can negotiate a mutual close of the connection, which unlike a
Expand Down