Bitcoin Optech Newsletter #430
Bitcoin Optech’s newsletter reviews ongoing debates about TCP hole punching for home nodes and a draft BIP for co‑signer spending policies, plus updates on BIP54. It finds that hole punching faces security trade‑offs and that the co‑signer draft seeks interoperability while BIP54 may activate around 2027.
मुख्य बातें
- Hole punching could increase honest node reachability but may also aid attackers.
- A draft BIP proposes a unified policy format for co‑signers to improve wallet compatibility.
- BIP54’s 64‑byte rule and 2,500 sigop limit remain contentious, with activation possibly in late 2027.
- Attackers could flood the hole‑punch scheme with ≈10,000 addresses, matching most honest nodes early.
- The timestamp fix in BIP54 leaves a 7,200‑second window, limiting difficulty changes to ~0.60% per retarget.
- Attacker addresses
- ≈10,000
- Sigop limit
- 2,500
- Timestamp window
- 7,200 s
- Difficulty impact
- ≈0.60%
- Activation window
- 2027 H2
TCP Hole Punching for Home Nodes
Bitcoin Optech highlights the continued discussion around TCP hole punching as a way to let nodes behind residential routers accept inbound connections. Home nodes typically only make outbound connections, and the recent default enablement of NAT‑PMP in Bitcoin Core 30.0 did not significantly improve reachability. Hole punching works by having two nodes simultaneously open connections, allowing routers to let traffic through. Proponents argue that more reachable honest nodes would make it harder for attacker‑controlled nodes, which are easier to reach, to fill outbound slots.
Security Concerns and Attacker Modeling
Critics, notably Anthony Towns, warn that the scheme could be weaponized. He estimates an attacker broadcasting about 10,000 addresses would quickly match most honest nodes, potentially increasing exposure. Towns also suggests short‑lived random inbound connections as a lower‑risk alternative. Data cited by Jonathan Harvey‑Buschel shows honest nodes are currently less reachable than attacker nodes, reinforcing the need for careful design. The debate also touches on recent TCP and protocol vulnerabilities, questioning whether the default should remain outbound‑only for home users.
Draft BIP for Co‑Signer Spending Policies
A separate thread introduces a draft BIP aimed at standardizing co‑signer policies when emulating covenants. The proposal defines a five‑part policy structure—output descriptor, co‑signer group, transaction templates, conditions, and verification profiles—ensuring at least one spend path without a co‑signer. It mandates DLC‑compatible oracle attestations and leaves serialization format (JSON vs TLV) and blinded verification details open. Feedback highlighted missing finality flags in evidence profiles and the need for policy hashes to commit to verifier semantics, which the author plans to address.
BIP54 Consensus Cleanup Progress
The newsletter also updates on BIP54, which seeks to forbid transactions with a witness‑stripped size of exactly 64 bytes and limit pre‑SegWit scripts to 2,500 signature operations. A Bitcoin Core pull request enables the new rules on regtest, and interoperability work is underway in btcd. Antoine Riard projects a realistic activation window in the second half of 2027, pending community consensus. He notes that the timestamp fix retains a 7,200‑second window, allowing only modest difficulty adjustments (~0.60% per retarget) and limiting the scope of forward‑block proposals.
Implications for the Community
For node operators, the hole‑punching debate underscores a trade‑off between connectivity and attack surface; adopting the technique may require additional safeguards or coordination via Tor. Wallet developers should monitor the co‑signer BIP draft, as its adoption could simplify multi‑signature and covenant‑like constructions across different implementations. Finally, miners and protocol stakeholders should track BIP54’s timeline, as its eventual activation will affect transaction validation rules and may influence fee dynamics.