[WIP] bolt-taproot-gossip #2

ellemouton · 2023-03-10T16:42:44Z

NOTE: PR & discussions have been moved to: lightning#1059

rustyrussell

I owe you a beer (or several) for doing this! Amazing.

Mainly minor nitpicks; this seems really solid to me.

rustyrussell · 2023-03-14T04:01:51Z

bolt-taproot-gossip.md

+This document aims to update the gossip protocol defined in [BOLT 7][bolt-7] to
+allow for advertisement and verification of taproot channels. An entirely new
+set of gossip messages are defined that use Schnorr signatures and that use a
+purely TLV based schema.


The problem with TLV is that you now need everyone to check that compulsory fields are present. But some fields don't actually make sense as optional. We end up needing another version anyway.

responded here

rustyrussell · 2023-03-14T04:02:20Z

bolt-taproot-gossip.md

+fields. Timestamp fields are also updated to be block heights instead of Unix
+timestamps.


rustyrussell · 2023-03-14T04:05:04Z

bolt-taproot-gossip.md

+single one. Verifiers will then be able to aggregate the four keys
+(`bitcoin_key_1`, `bitcoin_key_2`, `node_ID_1` and `node_ID_2`) using MuSig2 key
+aggregation and then they can do a single signature verification check instead
+of four individual checks.


Can we weaken this (and future proof it) a little, by publishing only the taproot_output_key? Sure, that means any taproot output can pretend to be a channel, but this is also a feature.

Sure, that means any taproot output can pretend to be a channel

Can you elaborate a bit more on this? What do you mean by "output can pretend"?

he means that you can "announce" a channel that is not actually a channel.

without checking node_ID_1 or node_ID_2 somehow?

If we do only publish taproot_output_key does that mean we may accept a phony channel announcement?

Well, both node ids have to sign it. But we don't care what the UTXO looks like internally, just that they prove they could spend it.

I think we might want to care a little bit - like at least that they cant spend it via the script path? ie, create some LN context binding

responded here

rustyrussell · 2023-03-14T04:11:15Z

bolt-taproot-gossip.md

+
+## Timestamp fields
+
+_TODO: write about the benefits of switching to block-height based timestamps_


Automatically gains ratelimiting, and solves the "we don't have a timestamp for channel_announcements" which plagues gossip_timestamp_filter (though, there's a proposal to vastly simplify this request).

Are the cases where the reduced granularity of block height is a disadvantage? And are there consequences in case of reorgs?

In practice, implementations will backdate a little (obviously, less than 2000 blocks!) so you can spam a bit, but it's still a limit.

Reorgs in practice never reduce block height, so that's not a problem. And if it did, you would only discard updates on the now-missing block, which (see above) nobody is likely to produce.

And what about two updates that follow in (relative) quick succession that have no ordering anymore? Maybe it is all good to discourage using the p2p network for high frequency updates, but also I think it isn't ruled out that there will be other ways of transportation where the coarse grained timestamping is going to cause a problem.

completed the section on the benefits of using blockheight here

let me know if I missed anything :)

rustyrussell · 2023-03-14T04:12:52Z

bolt-taproot-gossip.md

+There also does not seem to be a big benefit in spreading the 
+`node_announcement_2` message quickly since the speed of propagation of the 
+`channel_announcement_2` and `channel_update_2` messages will still depend on a
+network wide upgrade.


Yeah, simplicity wins.

bolt-taproot-gossip.md

rustyrussell · 2023-03-14T04:36:37Z

bolt-taproot-gossip.md

+    15. type: 7 (`htlc_minimum_msat`)
+    16. type: 8 (`fee_base_msat`)
+    17. type: 9 (`fee_prop_millionths`)
+    18. type: 10 (`htlc_max_msat`)


Let's renumber to make min and max adjacent, and decide on max vs maximum and min vs minimum to keep pedants like me happy!

They're all tu64, ofc.

rustyrussell · 2023-03-14T04:38:34Z

bolt-taproot-gossip.md

+   1. type: 0 (`channel_id`)
+   2. data:
+       * [`channel_id`:`channel_id`]
+   3. type: 1 (`short_channel_id`)
+   4. data:
+       * [`short_channel_id`:`short_channel_id`]
+   5. type: 2 (`partial_signature`)
+   6. data:
+       * [`partial_signature`:`partial_signature`]


I would definitely not use a TLV for channel_id. Every other message starts with channel_id, we should keep it fixed. The other two fields, well, they're OK, but it seems weird that they're optional.

bolt-taproot-gossip.md

rustyrussell · 2023-03-14T04:49:35Z

bolt-taproot-gossip.md

+
+This section fleshes out the algorithms that the peers will need in order to
+construct and verify the partial signature that will be included in the
+`announcement_signatures_2` messages.


TBH, I didn't review this, but I believe your math from here on down :)

joostjager · 2023-03-14T07:41:44Z

bolt-taproot-gossip.md

+   Nodes will do this by checking that they are able to derive the output key 
+   found on-chain by using the advertised `bitcoin_key_1` and `bitcoin_key_2` 
+   along with a [BIP86 tweak][bip86-tweak]. This provides a slightly weaker
+   binding to the LN context than legacy channels do but at least somewhat 


Maybe useful to the reader to explain how it is weaker?

@joostjager You mean in terms of what is visible to the blockchain?

Example

Suggested change

binding to the LN context than legacy channels do but at least somewhat

binding to the LN context than legacy channels do, as taproot addresses do not reveal any details related to the underlying script, but at least somewhat

You mean in terms of what is visible to the blockchain?

the proof to other nodes that this output will be used for a channel (and is thus not a fake channel)

An outsider verifies that the taproot address pays to the combination of the node's bitcoin keys, but what extra is verified for legacy channels then that can't be done anymore? I am comparing to https://github.com/lightning/bolts/blob/33098ad37a442a7677c246ea9e195b7260abe8d2/07-routing-gossip.md?plain=1#L132

no extra verification but rather that for legacy channels, there is a greater expense for an attacker to advertise a channel that is not actually a channel cause they will need to provide 2 signatures and pay for those bytes. With p2tr, there the on-chain remains the cost of one signature. I will add this detail to the explanation 👍

joostjager · 2023-03-14T07:42:56Z

bolt-taproot-gossip.md

+
+## Timestamp fields
+
+_TODO: write about the benefits of switching to block-height based timestamps_


Are the cases where the reduced granularity of block height is a disadvantage? And are there consequences in case of reorgs?

joostjager · 2023-03-14T07:48:20Z

bolt-taproot-gossip.md

+`announcement_signatures` and `channel_announcement` messages.
+
+The opportunity is also taken to rework the `node_announcement` and
+`channel_update` messages to take advantage of Schnorr signatures and TLV


Could you also not take this opportunity and keep using ecdsa signatures for those? That seems to reduce the delta of this proposal significantly, and maybe without loss of functionality for the user?

responded here

ellemouton · 2023-03-14T14:59:22Z

Thanks so much for the initial set of comments @rustyrussell & @joostjager!!

Im planning on finishing up the TODOs today & tomorrow and then I will close this & re-open against the main Bolt repo. Then we can continue discussions there? (want to avoid spreading the discussions across 2 places - rookie error on my side for opening this here publicly 😅 )

GeorgeTsagk · 2023-03-14T17:15:47Z

bolt-taproot-gossip.md

+  `node_1` and `node_2` use to identify their nodes in the network.
+- `bitcoin_key_1` and `bitcoin_key_2` respectively refer to the public keys
+  that `node_1` and `node_2` will use for the specific channel being opened.
+  The funding transactions output will be derived from these two keys.


Suggested change

The funding transactions output will be derived from these two keys.

The funding transaction's output will be derived from these two keys.

GeorgeTsagk · 2023-03-14T17:30:29Z

bolt-taproot-gossip.md

+   Nodes will do this by checking that they are able to derive the output key 
+   found on-chain by using the advertised `bitcoin_key_1` and `bitcoin_key_2` 
+   along with a [BIP86 tweak][bip86-tweak]. This provides a slightly weaker
+   binding to the LN context than legacy channels do but at least somewhat 


@joostjager You mean in terms of what is visible to the blockchain?

Example

Suggested change

binding to the LN context than legacy channels do but at least somewhat

binding to the LN context than legacy channels do, as taproot addresses do not reveal any details related to the underlying script, but at least somewhat

GeorgeTsagk · 2023-03-14T17:32:09Z

bolt-taproot-gossip.md

+   binding to the LN context than legacy channels do but at least somewhat 
+   limits how the output can be spent due to the script-path being disabled.
+3. The owners of `bitcoin_key_1` and `bitcoin_key_2` agree to be associated with  
+   a channel owned by `node_1` and `node_2`.


Since the public announcements of channels pretty much reveal what the output is being used for, would it be fair to mention that this mainly benefits private channels?

gossip only applies to public channels :)

would it be fair to mention that this mainly benefits private channels

Oh sorry by "this" I meant taproot channels, not gossip 🙈

Different phrasing: Taproot outputs all do look the same regardless of being used for a channel or not, but any participant in LN will eventually receive a (public) channel announcement that marks some taproot UTXO as a channel, so effectively it's only the private channels that can remain "incognito"

your statement is correct but not sure how this applies to the linked comment? sorry if im missing something 🙈

GeorgeTsagk · 2023-03-14T17:36:12Z

bolt-taproot-gossip.md

+single one. Verifiers will then be able to aggregate the four keys
+(`bitcoin_key_1`, `bitcoin_key_2`, `node_ID_1` and `node_ID_2`) using MuSig2 key
+aggregation and then they can do a single signature verification check instead
+of four individual checks.


Sure, that means any taproot output can pretend to be a channel

Can you elaborate a bit more on this? What do you mean by "output can pretend"?

ellemouton · 2023-03-16T14:46:46Z

Thanks for the comments everyone! I have now opened a PR to the main Bolt repo. I have done my best so carry over the main comments over to that PR so that we can continue discussing there. Feel free to re-post a comment there if I have missed something!

Signed-off-by: Rusty Russell <[email protected]> Header from folded patch 'bolt_2__set_an_initiator_in_quiescence.patch': BOLT #2: Set an initiator in quiescence. This is especially useful for protocols such as splicing; for simplified commitment transactions, there is already an implied initiator at each point, so having the negotiation at splicing time would be redundant. Signed-off-by: Rusty Russell <[email protected]> Header from folded patch 'option_quiesce__feature_to_support_stfu_method.patch': option_quiesce: feature to support stfu method. In practice, sftu is useless unless you have something (e.g. channel_upgrade) which uses it, but adding a feature is best practice IMHO. Signed-off-by: Rusty Russell <[email protected]>

ellemouton force-pushed the gossip1.5 branch 3 times, most recently from 76450ea to 8507d94 Compare March 13, 2023 16:36

bolt-taproot-gossip

a491093

ellemouton force-pushed the gossip1.5 branch from 8507d94 to a491093 Compare March 13, 2023 16:38

ellemouton changed the title ~~bolt-taproot-gossip~~ [WIP] bolt-taproot-gossip Mar 13, 2023

rustyrussell reviewed Mar 14, 2023

View reviewed changes

joostjager reviewed Mar 14, 2023

View reviewed changes

GeorgeTsagk reviewed Mar 14, 2023

View reviewed changes

ellemouton mentioned this pull request Mar 16, 2023

extension-bolt: taproot gossip (features 32/33) lightning/bolts#1059

Draft

ellemouton closed this Mar 16, 2023

		fields. Timestamp fields are also updated to be block heights instead of Unix
		timestamps.


		## Timestamp fields

		_TODO: write about the benefits of switching to block-height based timestamps_

	binding to the LN context than legacy channels do but at least somewhat
	binding to the LN context than legacy channels do, as taproot addresses do not reveal any details related to the underlying script, but at least somewhat

	The funding transactions output will be derived from these two keys.
	The funding transaction's output will be derived from these two keys.

[WIP] bolt-taproot-gossip #2

[WIP] bolt-taproot-gossip #2

Conversation

ellemouton commented Mar 10, 2023 • edited Loading

rustyrussell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager Mar 16, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ellemouton commented Mar 14, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GeorgeTsagk Mar 15, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ellemouton commented Mar 16, 2023

ellemouton commented Mar 10, 2023 •

edited

Loading

joostjager Mar 16, 2023 •

edited

Loading

GeorgeTsagk Mar 15, 2023 •

edited

Loading