Visit the unique article*
This week’s e-newsletter discusses modifications to companies and consumer software program and why wallets ought to wait earlier than producing Taproot addresses.
The Bitcoin Optech e-newsletter offers readers with a top-level abstract of crucial technical information taking place in Bitcoin, together with assets that assist them study extra. To assist our readers keep up-to-date with Bitcoin, we’re republishing the newest difficulty of this article under. Remember to subscribe to obtain this content material straight to your inbox.
This week’s e-newsletter describes current modifications to companies and consumer software program, discusses why wallets ought to wait earlier than producing taproot addresses, lists new software program releases and launch candidates, and summarizes notable modifications to fashionable Bitcoin infrastructure software program.
No vital information this week.
Changes to companies and consumer software program
In this month-to-month function, we spotlight fascinating updates to Bitcoin wallets and companies.
Preparing for taproot #5: why are we ready?
A weekly collection about how builders and repair suppliers can put together for the upcoming activation of taproot at block peak 709,632.
Earlier entries on this collection noticed us encouraging builders engaged on wallets and companies to start implementing taproot upgrades now in order that they’re prepared when taproot prompts. But we’ve additionally warned in opposition to producing any addresses for P2TR earlier than block 709,632 as this might trigger your service or your customers to lose cash.
The motive to not generate addresses prematurely is that any fee to a P2TR-style output could be spent by anybody prior to dam 709,632. The cash could be utterly unsecured. But beginning with that block, 1000’s of full nodes will start implementing the principles of BIP341 and BIP342 (and, by affiliation, BIP340).
If it was assured that there wouldn’t be a reorganization of the block chain, it will be secure to start out producing addresses for P2TR as quickly as the ultimate pre-taproot block was seen (block 709,631). But there’s motive to be involved about block chain reorgs—not simply unintended reorgs but additionally these intentionally created to take cash from early P2TR funds.
Imagine numerous individuals all eager to be one of many first to obtain a P2TR fee. They naively ship themselves some cash as quickly as they see block 709,631.1 Those funds can be safe in block 709,632, however they are often stolen by any miner who creates an alternative choice to block 709,631. If the worth of the cash despatched to P2TR outputs is giant sufficient, it might simply change into extra worthwhile to try to mine two blocks as a substitute of only one (see our payment sniping subject for extra particulars).
For this motive, we don’t suggest your software program or service generate addresses for P2TR till you suppose the reorg danger has been successfully eradicated. We suppose ready 144 blocks (roughly at some point) after activation is a fairly conservative margin that minimizes danger with out considerably delaying you or your customers from profiting from the advantages of taproot.
- 709,631: final block the place anybody can spend cash despatched to a P2TR-style output
- 709,632: first block the place P2TR outputs can solely be spent in the event that they fulfill the BIP341 and BIP342rules.
- 709,776: an affordable block at which wallets can begin giving their customers bech32m receiving addresses for P2TR outputs
None of the above modifications the recommendation given within the first a part of this collection to allow paying to bech32m addresses as quickly as attainable. If somebody requests fee to an tackle for P2TR earlier than you suppose it’s secure, that’s their danger to take.
Releases and launch candidates
New releases and launch candidates for fashionable Bitcoin infrastructure initiatives. Please contemplate upgrading to new releases or serving to to check launch candidates.
- LND 0.13.1-beta is a upkeep launch with minor enhancements and bug fixes for options launched in 0.13.0-beta.
- Rust-Lightning 0.0.99 is a launch with a number of API and configuration modifications. See its launch notesfor particulars.
- Eclair 0.6.1 is a brand new launch with efficiency enhancements, a number of new options, and a number of other bug fixes. In addition to its launch notes, see the descriptions of Eclair #1871 and #1846 within the notable modifications part under.
Notable code and documentation modifications
Notable modifications this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.
- Bitcoin Core #22112 modifications the assumed port for I2P addresses to be 0 as a substitute of 8333 (which is the default for IPv4 and IPv6 addresses), and prevents connections to I2P addresses with ports apart from 0. The SAM v3.1 specification (which is supported by Bitcoin Core), doesn’t embody the idea of ports. This restriction could also be lifted if Bitcoin Core is up to date to assist SAM v3.2, which does embody the idea of ports.
- C-Lightning #4611 updates the plugin-provided keysend RPC so as to add a routehintsparameter which permits offering data for routing funds to unannounced channels.
- C-Lightning #4646 makes two modifications in preparation for eradicating previous conduct. The first change assumes nodes assist the TLV-style encoding added in 2019 (see Newsletter #55). Only nodes that explicitly point out they don’t assist TLV encoding can be handled in another way. The second change makes fee secrets and techniques required (see Newsletter #75 for earlier dialogue and Newsletter #126 for when LND started requiring it).
- C-Lightning #4614 updates the listchannels RPC with a brand new optionally available destinationparameter that can be utilized to solely return channels that result in the requested node.
- Eclair #1871 modifications its SQLite settings to extend by 5x the variety of HTLCs it could possibly course of per second and in addition enhance its robustness in opposition to knowledge loss. Referenced within the PR is a weblog postby Joost Jager evaluating HTLC throughput in varied node software program.
- Eclair #1846 provides opt-in assist for utilizing an upfront shutdown script—an tackle the node specifies when negotiating a brand new channel that the distant peer agrees would be the solely tackle it’ll enable for use in a later mutual shut of the channel. See additionally Newsletter #76 describing LND’s implementation of this function.
- Rust-Lightning #975 makes the bottom fee forwarding payment configurable with a default worth of 1 satoshi (the market price as of July 2021). LN routing nodes can cost two charges to route a fee, a hard and fast base payment or a proportion of the quantity routed; many nodes use each. Previously, Rust-Lightning set the bottom payment to the estimated payment required to settle the HTLC on-chain, which was a lot increased than 1 sat.
- BTCPay Server #2462 makes it simpler to make use of BTCPay to trace funds constructed from a separate pockets, such because the case the place the operator of an occasion desires to pay a refund utilizing their very own private pockets.
- Users who wish to obtain a P2TR fee within the first taproot block ought to generate an tackle they don’t share with anybody after which create a transaction to that tackle with nLockTime set to 709,631. That transaction could be broadcast as quickly as block 709,631 has been obtained. The nLockTime will make sure the transaction can’t be included into any block earlier than 709,632, the place taproot guidelines are enforced. Messing about with new script varieties and customized locktimes could be harmful in the event you don’t know what you’re doing, so please take care.
Find the unique submit right here.
Please subscribe to the Bitcoin Optech e-newsletter on to obtain this content material straight to your inbox each month.