The views expressed are his own and do not necessarily reflect those of BTC Media Inc or Bitcoin Magazine. Also included are our regular sections with popular questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software. Also included are our regular sections with announcements of new software releases and release candidates, plus notable changes to popular Bitcoin infrastructure software. This week’s newsletter provides information about the activation of taproot and includes our regular sections with summaries of changes to services and client software, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software. ● Ledger Live supports taproot: Ledger’s client software, Ledger Live, announced taproot support in their v2.35.0 release as an experimental feature. ● Taproot locked in: the taproot soft fork and related changes specified in BIPs 340, 341, and 342 were locked in by signaling miners last weeke
/p>
This may indicate that they were falsely signaling readiness to enforce taproot’s rules, a risk we previously warned about. The delay gives time for users to upgrade their nodes to a release (such as Bitcoin Core 0.21.1 or later) that will enforce taproot’s rules, ensuring that funds received to taproot scripts after block 709,632 are safe even if there’s a problem with miners. ● Taproot activated: as expected, the taproot soft fork activated at block height 709,632. As of this writing, several large mining pools are not mining blocks containing taproot spends. Recurring offer features are planned for a future release. ● Kollider launches alpha LN-based trading platform: Kollider’s latest announcement details the derivative platform’s features including LN deposits and withdrawals plus LNAUTH and LNURL support. For example, batching customer withdrawals may save on fees for the enterprise, but will likely make child pays for parent (CPFP) uneconomical for a customer who wishes to speed up the
saction.
It would also be messy for the customer to spend from this transaction while it remains unconfirmed, as the enterprise will have to pay for this child spend when attempting to replace the parent. This field report outlines efforts CardCoins has taken in introducing a reorg- and DoS-safe implementation of such a scheme in its customer payout workflow. "Additive batching" is a scheme in which additional outputs are added to unconfirmed transactions in the mempool. The alternative method would enhance the privacy and fungibility of transactions made by single-sig users, multisignature users, and users of certain contract protocols such as taproot-enabled LN or advanced coinswaps. Overall, if the proposal is implemented, it will allow users of regular single-sig transactions or uncomplicated multisignatures to join together with users of contract protocols to mutually improve each others’ privacy and fungibility. Belcher’s proposal suggests wallets randomly choose between using either nLockTime or nSequence with 50% probability when both options are available. This wouldn’t be any more effective at preventing fee sniping, but it would provide a good reason for regular wallets to set their nSequence values to the same values that are required for transactions in certain multisignature-based contract protocols, such as ideas for coinswaps and tap
-enabled LN.
Fees go up, fees go down, but the business must always fight for fee efficiency. Anti fee sniping is a technique some wallets implement to discourage miners from trying to steal fees from each other in a way that would reduce the amount of proof of work expended on securing Bitcoin and limit users’ ability to rely on confirmation scores. ● BIP proposed for wallets to set nSequence by default on taproot transactions: Chris Belcher posted a draft BIP to the Bitcoin-Dev mailing list suggesting an alternative way wallets can implement anti fee sniping. Taproot support in the UI is planned for a future update. As of this merge, support for anchor outputs is implemented in all four LN implementations we cover. LN implementations plan to move most of their messages to this format in the future. The pull request also improves test coverage, adds more documentation to the address validation code, and improves error messages when decoding fails, especially to distinguish use of bech32 and youtu.be bech32m. ● Spark Lightning Wallet adds BOLT12 offers: Spark v0.3.0 adds offer features including offer creation, sending offer payments, and pull payments. ● LN reliability versus fee parameterization: Joost Jager started a thread on the Lightning-Dev mailing list about how to best allow users to choose between paying more fees for faster payments or waiting longer to save money.