Newsletters: add 406 (2026-05-22)

[bitschmidty]

• news @TumaBitcoiner @kevkevinpal
  • BIP-322: Add type prefix, change PoF serialization, PSBT-based signing @murchandamus ?
  • QR-based signing flow payloads in Miniscript context
  • TCP hole punching for Bitcoin nodes behind home NATs?
  • A Post-Quantum Path for BIP 324
• client services @bitschmidty
• releases and notable code changes @Gustavojfe
• lede @bitschmidty
• topics @bitschmidty

[0xB10C]

Thanks @TumaBitcoiner for the hole punching section! Some comments are attached.

[0xB10C]

I'm not sure it's a "fact" that -natpmp=1 didn't cause any increase, but the data I've looked at and described in https://bnoc.xyz/t/did-the-number-of-reachable-nodes-in-residential-isps-increase-since-bitcoin-core-v30-0/122 suggests there wasn't a big spike, as some have hoped for.

Suggested change

	home router NAT reachable. The need comes from the fact that making `-natpmp=1` by
	home router NAT reachable. The need comes from the observation that making `-natpmp=1` by

[0xB10C]

Also not sure if "The need" is the right description here.

[0xB10C]

This is one of the possible methods described, but the delving post also discusses ways of not needing a Charlie / coordinator, which you mention below. So maybe only explain hole punching here (which isn't something new for P2P networks, but the application to Bitcoin is new I think), and then go into the possible ways of doing this on Bitcoin P2P in the next paragraph?

Suggested change

	The process works like this: Two unreachable nodes, Alice and Bob, connect to a
	coordinator node, Charlie, known as the rendezvous server. Charlie learns the public
	endpoints (i.e. IP address and port) of the nodes, and provides this information to its peers.
	Alice and Bob simultaneously initiate a TCP connection to each other, using the same local
	port used for the connection to Charlie. This creates a mapping in the NATs,
	The process works like this: Two unreachable hosts, Alice and Bob, connect to a
	coordinator host, Charlie, known as the rendezvous server. Charlie learns the public
	endpoints (i.e. IP address and port) of the hosts, and provides this information to Alice and Bob.
	Alice and Bob simultaneously initiate a connection to each other, reusing the same local
	port used for the connection to Charlie. This creates a mapping in the NATs,

[TumaBitcoiner]

Hey @0xB10C! Thanks for the feedback, I will address your comments soon.

[0xB10C]

Suggested change

	0xB10C provided two possible approaches to implement this in the Bitcoin protocol,
	0xB10C mentions multiple possible approaches for an implementation in the Bitcoin protocol,

With "coordinating through a rendezvous", "handing off", and "Tor/i2p" I think it's fine to say multiple. Saying "two possible approaches" and then listing two and another one reads weird.

[0xB10C]

Looks good!

[bitschmidty]

Feedback on @TumaBitcoiner and @Gustavojfe sections.

[LarryRuane]

Suggested change

	After some discussion and incorporating feedback on the PSBT construction, the update to BIP322
	After some discussion and incorporating feedback on the PSBT construction, the BIP322 update

[LarryRuane]

Suggested change

	- [LDK #4575][] adds a `splice_in_inputs` API that allows users to manually
	select UTXOs when [splicing][topic splicing] funds into a channel. The
	- [LDK #4575][] adds a `splice_in_inputs` API that allows users to
	select UTXOs when [splicing][topic splicing] funds into a channel manually. The