bolt-simple-taproot: update interactive session protocol #8

sstone · 2025-08-21T14:10:51Z

Add extensions to the interactive transaction protocol, which is used for dual-funding, splicing and funding transaction fee bumping.

Includes a few changes to the current simple taproot channels proposal:

drop support for single "next local nonce" in revoke_and_ack in favour of the funding txid -> nonce map, even for nodes that do not support dual-funding (there will just be a single entry then).
the nonce map is always indexed by funding tx id, even for the current commitment transaction (instead of 32 zero bytes)

Add extensions to the interactive transaction protocol, which is used for dual-funding, splicing and funding transaction fee bumping.

t-bast · 2025-08-21T14:41:05Z

bolt-simple-taproot.md

+  or a splice transaction.
+- MUST include a `next_commit_nonce` that will be used to sign the next 
+  commitment transaction, once the interactive transaction session completes. 
+- IF the session is spending a previous funding transaction, MUST include


nit: that's only the case when spending a previous funding transaction that is using musig2

Yes but my impression was that in this document we assume that we are using simple taproot channels.

I think it's worth clarifying, we want to be future-proof and potentially cover the case where a splice upgrades to taproot (in which case we don't need to include a funding_nonce), don't we?

t-bast · 2025-08-21T14:42:42Z

bolt-simple-taproot.md

+2. types:
+    1. type: 4 (`session_nonces`)
+    2. data:
+      * [`66 or 99 * byte`:`commit_nonce` || `next_commit_nonce` || (optional) `funding_nonce`]


I'm now wondering whether we should include the optional funding_nonce in this TLV: it is completely orthogonal to the commit nonces (it's only useful when splicing a taproot channel), so it would probably be cleaner to use a separate TLV for it?

In that case this TLV should be renamed commitment_nonces and the new one funding_nonce.

Also, the length looks incorrect, it should be either 2*66*byte or 3*66*byte ?

I've tried splitting into two TLVs in ACINQ/eclair#3145 and it is trivial and cleaner, I think we should do this. We should have session_commit_nonces and session_funding_nonce as two separate TLVs fields here.

Yes it cleaner with 2 distinct TLV fields, done in 705e8cc.

+1 for two diff fields

t-bast · 2025-08-21T14:47:17Z

bolt-simple-taproot.md

+
+- MUST include a `commit_nonce` for the commitment transaction that is being 
+  built, which can be the first commitment transaction for channel opening,
+  or a splice transaction.


This is quite unclear, I don't understand what the "or a splice transaction" means here...maybe it would be easier to understand if you say that this is for the current_commitment_number, which is always 0 for the channel opening case but could be anything for splices?

Updated in 705e8cc.

t-bast · 2025-08-21T14:53:27Z

bolt-simple-taproot.md

+2. types:      * [`66*byte`: `public_nonce`]
+   1. type: 22 (`next_local_nonces`)


Wrong copy-paste?

Fixed in 705e8cc.

t-bast · 2025-08-25T09:41:45Z

bolt-simple-taproot.md

-  - MUST use the nonce associated with the empty hash key (32 zero bytes) as the
-    primary commitment nonce


Why are you removing this? It is very important to specify that this is used for single-funded channels, isn't it?

Because for each commitment the corresponding commit nonce is indexed by the actual funding txid (I've removed the special case the the current commit tx that was indexed by 32 zero bytes). But I will specify that for single-funded channels, since the funding tx id is not known yet when open/accept are exchanged, the funding txid used to generate the corresponding commit nonce should be 32 zero bytes.

t-bast · 2025-08-25T11:38:35Z

bolt-simple-taproot.md

-   3. type: 22 (`local_nonces`)
-   4. data:
-      * [`local_nonces`: `nonces_map`]
+      * [`next_local_nonces`: `nonces_map`]


nonces_map doesn't seem to be defined anywhere. I think you're referring to the local_nonces type defined earlier, but it must be made more precise. Also, there is an issue in the current definition of local_nonces, it explicitly encodes the length of the map but it's unnecessary since the length is already encoded in the TLV.

It is currently defined as:

local_nonces - type: 22 - data: - [u16: num_entries] - [num_entries * nonce_entry: entries] where nonce_entry is: - [32*byte: txid] - [66*byte: public_nonce]

But it should be:

local_nonces - type: 22 - data: - [... * nonce_entry: entries] where nonce_entry is: - [32*byte: txid] - [66*byte: public_nonce]

Updated in 705e8cc, it matches how eclair encodes this field.

It was defined in lightning@4c1314a

This PR looks to be against an older commit,

t-bast · 2025-08-25T13:19:28Z

bolt-simple-taproot.md

+2. types:
+    1. type: 4 (`commit_nonces`)
+    2. data:
+      * [`2*66*byte`:`commit_nonce` || `next_commit_nonce`]


IIRC we need to follow a stricter structure because cln uses a parser to automatically generate the right data structs in C. I believe it should be changed to the following to work correctly:

1. `tlv_stream`: `tx_complete_tlvs` 2. types: 1. type: 4 (`commit_nonces`) 2. data: * [`66*byte`:`commit_nonce`] * [`66*byte`:`next_commit_nonce`]

bolt-simple-taproot.md

Co-authored-by: Bastien Teinturier <[email protected]>

Roasbeef

Thanks for this PR!

I did an initial pass over the set of changes. I think somehow the PR was made against an older revision, or maybe it's just the diff rendering oddly.

Not super familiar with the interactive tx protocol, so was mainly looking for consistency related issues.

Roasbeef · 2025-09-05T23:54:42Z

bolt-simple-taproot.md

+2. types:
+    1. type: 4 (`session_nonces`)
+    2. data:
+      * [`66 or 99 * byte`:`commit_nonce` || `next_commit_nonce` || (optional) `funding_nonce`]


+1 for two diff fields

Roasbeef · 2025-09-05T23:56:50Z

bolt-simple-taproot.md

 1. `tlv_stream`: `revoke_and_ack_tlvs`
 2. types:
-   1. type: 4 (`next_local_nonce`)
+   1. type: 22 (`next_local_nonces`)


Looks like this diff is against an older version of the set of changes?

See this commit in the BOLTs repo: lightning@4c1314a

Roasbeef · 2025-09-05T23:58:57Z

bolt-simple-taproot.md

   * [`66*byte`: `public_nonce`]

-### Channel Funding
+### Channel Establishment v1


Isn't the prior heading valid?

The new heading serves to delineate the new set of messages.

Roasbeef · 2025-09-05T23:59:46Z

bolt-simple-taproot.md

-   3. type: 22 (`local_nonces`)
-   4. data:
-      * [`local_nonces`: `nonces_map`]
+      * [`next_local_nonces`: `nonces_map`]


It was defined in lightning@4c1314a

This PR looks to be against an older commit,

Roasbeef · 2025-09-06T00:00:47Z

bolt-simple-taproot.md

+The recipient:
+
+- MUST fail the channel if `next_local_nonces` is absent or cannot be parsed.
+- MUST fail the channel if an active commitment funding txid is missing in 


Don't nonces for all the current commitments need to be included?

Roasbeef · 2025-09-06T00:06:00Z

bolt-simple-taproot.md


 The recipient:

- MUST fail the channel if `next_local_nonce` is absent, or cannot be parsed as


This was more precise.

Roasbeef · 2025-09-06T00:12:16Z

bolt-simple-taproot.md

 #### local_nonces
 - type: 22
 - data:
-   * [`u16`: `num_entries`]


Rationale for dropping the prefix byte of the number of elements?

It is already encoded in the length part of the TLV (type-length-value), so it's completely redundant to re-encode it?

Roasbeef · 2025-09-06T00:13:44Z

bolt-simple-taproot.md

     `musig2.NonceGen` algorithm with the required values, and the `rand'`
     value set to `k_i`.

+  4. Use the id of the commitment's funding transaction as extra input, as


👍

id -> TXID

Roasbeef · 2025-09-06T00:13:52Z

bolt-simple-taproot.md


 We add `option_simple_taproot` to the set of defined channel types.

+Since the id of the funding transaction is not known yet when nodes exchange


Roasbeef · 2025-09-06T00:14:21Z

bolt-simple-taproot.md


+Since the id of the funding transaction is not known yet when nodes exchange
+`open_channel` and `accept_channel`, a dummy funding txid of 32 zero-byte
+must be used instead as extra input to the nonce generation algorithm to 


must -> SHOULD

The nonce generation protocol defined above is optional.

bolt-simple-taproot: update interactive session protocol

3404309

Add extensions to the interactive transaction protocol, which is used for dual-funding, splicing and funding transaction fee bumping.

t-bast mentioned this pull request Aug 21, 2025

extension-bolt: simple taproot channels (feature 80/81) lightning/bolts#995

Open

t-bast reviewed Aug 21, 2025

View reviewed changes

t-bast mentioned this pull request Aug 25, 2025

Lightning Specification Meeting 2025/08/25 lightning/bolts#1283

Closed

27 tasks

t-bast reviewed Aug 25, 2025

View reviewed changes

t-bast mentioned this pull request Aug 25, 2025

Split commit nonces from funding nonce in tx_complete ACINQ/eclair#3145

Merged

t-bast reviewed Aug 25, 2025

View reviewed changes

Fixup: address review comments

705e8cc

t-bast reviewed Aug 25, 2025

View reviewed changes

sstone and others added 2 commits August 25, 2025 17:51

Fixup! make TLVs easier to parse and other fixes

e79ba49

Co-authored-by: Bastien Teinturier <[email protected]>

Nonce generation: use dummy funding txid for single-funded channels

5f6e088

Roasbeef requested changes Sep 6, 2025

View reviewed changes

		2. types: * [`66*byte`: `public_nonce`]
		1. type: 22 (`next_local_nonces`)

		- MUST use the nonce associated with the empty hash key (32 zero bytes) as the
		primary commitment nonce


		The recipient:

		- MUST fail the channel if `next_local_nonce` is absent, or cannot be parsed as


		We add `option_simple_taproot` to the set of defined channel types.

		Since the id of the funding transaction is not known yet when nodes exchange

bolt-simple-taproot: update interactive session protocol #8

Are you sure you want to change the base?

bolt-simple-taproot: update interactive session protocol #8

Uh oh!

Conversation

sstone commented Aug 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Roasbeef left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants