{"id":17319,"date":"2021-03-24T17:35:00","date_gmt":"2021-03-24T17:35:00","guid":{"rendered":"http:\/\/ci027ee2ee8000266f"},"modified":"2021-03-24T17:35:00","modified_gmt":"2021-03-24T17:35:00","slug":"bitcoin-optech-141-signature-delegation-and-taproot-activism","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-141-signature-delegation-and-taproot-activism","title":{"rendered":"Bitcoin Optech #141: Signature Delegation And Taproot Activism"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>The <\/em><a href=\"https:\/\/bitcoinops.org\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Optech <\/em><\/a><em>newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we&#8217;re republishing the latest issue of this newsletter below. Remember <\/em><a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\"><em>to subscribe<\/em><\/a><em> to receive this content straight to your inbox.<\/em><\/p>\n<p>This week\u2019s newsletter describes a technique for signature delegation under Bitcoin\u2019s existing consensus rules, summarizes a discussion about taproot\u2019s effect on Bitcoin\u2019s resistance to quantum cryptography, and announces a series of weekly meetings to help activate taproot. Also included are our regular sections describing notable changes to services and client software, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.<\/p>\n<h2>News<\/h2>\n<ul>\n<li>Signing delegation under existing consensus rules: Imagine Alice wants to give Bob the ability to spend one of her UTXOs without immediately creating an onchain transaction or giving him her private key. This is called delegation and it\u2019s been discussed for years, perhaps most notably in recent times as part of the <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2018-February\/015700.html\" target=\"_blank\" rel=\"noopener\">graftroot proposal<\/a>. Last week, Jeremy Rubin <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018615.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> to the Bitcoin-Dev mailing list a description of a technique to accomplish delegation using Bitcoin today.<br \/>Let\u2019s say Alice has UTXO_A and Bob has UTXO_B. Alice creates a partially signed transaction spending both UTXO_A and UTXO_B. Alice signs for her UTXO using the sighash flag <a href=\"https:\/\/btcinformation.org\/en\/developer-guide#term-sighash-none\" target=\"_blank\" rel=\"noopener\">SIGHASH_NONE<\/a>, which prevents the signature from committing to any of the transaction\u2019s outputs. This gives the owner of the other input in the transaction\u2014Bob\u2014unilateral control over the choice of outputs, using his signature with the normal SIGHASH_ALL flag to commit to those outputs and prevent anyone else from modifying the transaction. By using this dual-input SIGHASH_NONE trick, Alice delegates to Bob the ability to sign for her UTXO.<br \/>This technique appears to be mainly of theoretical interest. There are other proposed delegation techniques\u2014including graftroot, <a href=\"https:\/\/bitcoinops.org\/en\/topics\/op_checktemplateverify\/\" target=\"_blank\" rel=\"noopener\">OP_CHECKTEMPLATEVERIFY<\/a>, and <a href=\"https:\/\/bitcoinops.org\/en\/topics\/op_checksigfromstack\/\" target=\"_blank\" rel=\"noopener\">OP_CHECKSIGFROMSTACK<\/a>\u2014that would likely be superior in several ways, but only this technique is currently usable on mainnet for anyone who wants to experiment with it.<\/li>\n<li>Discussion of quantum computer attacks on taproot: the original Bitcoin software provided two ways to receive bitcoin:<\/li>\n<ul>\n<li>Pay-to-Public-Key (P2PK) implemented the simple and clear method described in the <a href=\"https:\/\/bitcoin.org\/bitcoin.pdf\" target=\"_blank\" rel=\"noopener\">original Bitcoin paper<\/a> of receiving bitcoins to a public key and allowing those coins to be spent by a signature. The Bitcoin software used this by default when the public key material could be handled entirely by software.<\/li>\n<li>Pay-to-Public-Key-Hash (P2PKH) added a layer of indirection, receiving bitcoins to a hash digest that committed to the public key to be used. To spend the coins, the public key would need to be published alongside the signature, making the 20 bytes dedicated to the hash digest an overhead cost. This was used by default when the payment information might need to be handled by a person, e.g. an address that could be copied and pasted.<\/li>\n<\/ul>\n<li>Nakamoto never described why he implemented both methods, but it\u2019s widely believed that he added the hash indirection in order to make Bitcoin addresses smaller so that they could be communicated more easily. Public keys in the original Bitcoin implementation were 65 bytes, but address hashes were only 20 bytes.<br \/>In the decade since, there have been a number of developments. To make certain multisig protocols <a href=\"https:\/\/bitcoinops.org\/en\/bech32-sending-support\/#address-security\" target=\"_blank\" rel=\"noopener\">simple and secure by default<\/a>, it was determined that scripts for multiparty protocols should probably use a 32-byte commitment. Bitcoin developers also learned about previously known techniques that could compress a public key down to 33 bytes\u2014later describing how to <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/05\/29\/#move-the-oddness-byte\" target=\"_blank\" rel=\"noopener\">optimize<\/a> that to 32 bytes. Finally, <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2018\/12\/28\/#taproot\" target=\"_blank\" rel=\"noopener\">taproot\u2019s primary innovation<\/a> showed that a 32-byte public key could commit to a script with <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/03\/04\/#taproot-in-the-generic-group-model\" target=\"_blank\" rel=\"noopener\">security<\/a> similar to that of a 32-byte hash. All of this means that it no longer changes the amount of address data people have to communicate whether they use a hash or a public key\u2014it\u2019s 32 bytes either way if they want a universally applicable address format. However, directly using public keys still eliminates the extra bandwidth and storage resulting from hash indirection. If every payment went to a public key instead of a 32-byte hash, it would save about 13 gigabytes of block chain space per year. The <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0341.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP341<\/a> specification of taproot describes space savings as the reason it accepts payments to public keys in the P2PK style instead of hashes in the P2PKH style.<br \/>But P2PKH hash indirection does have one advantage: it can hide keys from public view until they\u2019re needed to authorize a spend. This means an adversary who has the ability to compromise the security of a public key might not be able to start using that ability until a transaction is broadcast, and they may lose the ability to steal funds controlled by that key once the transaction is confirmed to a certain depth. This limits the amount of time available for their attack and means a slow attack might not work. Although this has previously been discussed at length in the context of taproot\u2019s choice to directly use public keys in the P2PK style (see <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2018-January\/015620.html\" target=\"_blank\" rel=\"noopener\">1<\/a>, <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2018-December\/016556.html\" target=\"_blank\" rel=\"noopener\">2<\/a>, and newsletters <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/10\/30\/#why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance\" target=\"_blank\" rel=\"noopener\">#70<\/a> and <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/02\/26\/#could-taproot-create-larger-security-risks-or-hinder-future-protocol-adjustments-re-quantum-threats\" target=\"_blank\" rel=\"noopener\">#86<\/a>), it was the subject of <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018641.html\" target=\"_blank\" rel=\"noopener\">renewed discussion<\/a> this week on the Bitcoin-Dev mailing list after the publication of an <a href=\"https:\/\/freicoin.substack.com\/p\/why-im-against-taproot\" target=\"_blank\" rel=\"noopener\">email<\/a> opposing taproot out of fear that we could see a quantum computer powerful enough to attack Bitcoin-style public keys \u201cas soon as the end of the decade.\u201d<br \/>None of the participants in the mailing list discussion said they also opposed taproot, but they did examine the argument\u2019s premises, discuss alternatives, and evaluate what tradeoffs would be implied by those alternatives. A selection of those conversations are summarized below:<\/li>\n<ul>\n<li>&nbsp;Hashes not currently doing a good job at QC resistance: as of a <a href=\"https:\/\/twitter.com\/pwuille\/status\/1108097835365339136\" target=\"_blank\" rel=\"noopener\">2019 survey<\/a>, an attacker with a powerful QC and nothing else besides a copy of the Bitcoin block chain could steal over 1\/3 of all bitcoins. Most of those would be the result of users <a href=\"https:\/\/bitcoinops.org\/en\/topics\/output-linking\/\" target=\"_blank\" rel=\"noopener\">reusing addresses<\/a>, a discouraged practice\u2014but one that seems unlikely to go away soon.<br \/>Additionally, discussion participants pointed out that anyone who shares their individual public keys or <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0032.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP32<\/a> extended public keys (xpubs) with third parties would also be at risk from a powerful QC if their public keys leaked. This would likely include most bitcoins stored with a hardware wallet or in an LN payment channel. In short, it\u2019s possible that even though we almost universally use P2PKH-style hashed public keys today, nearly all bitcoins could be stolen by a powerful QC with access to public or third-party data. That implies that the choice to use P2PK-style non-hashed public keys with taproot doesn\u2019t significantly change Bitcoin\u2019s current security model.<\/li>\n<li>&nbsp;Taproot improvement in post-QC recovery at no onchain cost: if Bitcoiners learn that a powerful QC has manifested, or soon will, they can reject any taproot key-path spends\u2014the type of spend where only a single signature is used. However, a user who prepares ahead when creating their taproot address can also spend bitcoins received to that address using a script-path spend. In that case, the taproot address commits to a hash of the <a href=\"https:\/\/bitcoinops.org\/en\/topics\/tapscript\/\" target=\"_blank\" rel=\"noopener\">tapscripts<\/a> the user wants to use. That hash commitment can be used as part of a <a href=\"https:\/\/gist.github.com\/harding\/bfd094ab488fd3932df59452e5ec753f\" target=\"_blank\" rel=\"noopener\">scheme<\/a> to transition to a new cryptographic algorithm that\u2019s safe against QCs, or\u2014if such an algorithm is standardized for Bitcoin before QCs become a threat\u2014it can allow the owner of the bitcoins to immediately transition to the new scheme. This does only work if individual users create backup tapscript spending paths, if they don\u2019t share any public keys (including BIP32 xpubs) involved in those backup paths, and if we learn about a powerful QC before it does too much damage to Bitcoin.<\/li>\n<li>Is the attack realistic? One respondent thought a fast QC by the end of the decade <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018658.html\" target=\"_blank\" rel=\"noopener\">was<\/a> \u201con the wildly optimistic side of projected rate of progress.\u201d Another <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018649.html\" target=\"_blank\" rel=\"noopener\">noted<\/a> it was a \u201cfairly straightforward engineering challenge\u201d to turn the design for a single slow QC into a farm of QCs that could work in parallel, achieving results in a fraction of the time\u2014making any protection from P2PKH-style hash indirection irrelevant. A third respondent <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018648.html\" target=\"_blank\" rel=\"noopener\">proposed<\/a> constructing special Bitcoin addresses that could only be spent from by someone making progress on fast QCs; users could voluntarily donate bitcoins to the addresses to create an incentivized early warning system.<\/li>\n<li>&nbsp;We could add a hash-style address after taproot is activated: if a significant number of users really do think the sudden appearance of a powerful QC is a threat, we could use a follow-up soft fork to <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018641.html\" target=\"_blank\" rel=\"noopener\">add<\/a> an alternative P2PKH-style taproot address type that uses hashes. However, this has consequences that caused several respondents to oppose it:<\/li>\n<ul>\n<li>It\u2019ll create confusion<\/li>\n<li>It\u2019ll use more block space<\/li>\n<li>It <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018667.html\" target=\"_blank\" rel=\"noopener\">reduces<\/a> the size of taproot\u2019s anonymity set, both directly and when protocols such as <a href=\"https:\/\/twitter.com\/n1ckler\/status\/1334240709814136833\" target=\"_blank\" rel=\"noopener\">ring signature membership proofs<\/a> or <a href=\"https:\/\/eprint.iacr.org\/2015\/1008\" target=\"_blank\" rel=\"noopener\">Provisions<\/a> are being used<\/li>\n<\/ul>\n<li>Bandwidth\/storage costs versus CPU costs: it\u2019s <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018643.html\" target=\"_blank\" rel=\"noopener\">possible<\/a> to eliminate the extra 32-byte storage overhead from hash indirection by deriving the public key from a signature and the transaction data it signs, a technique called key recovery. Again, this was opposed. Key recovery requires a <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018644.html\" target=\"_blank\" rel=\"noopener\">significant amount of CPU<\/a> that would slow down nodes and also prevents the use of schnorr batch validation that can make historic block verification up to three times faster. It also <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018667.html\" target=\"_blank\" rel=\"noopener\">makes<\/a> anonymous membership proofs and related techniques both harder to develop and much more CPU intensive. There <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-March\/018646.html\" target=\"_blank\" rel=\"noopener\">may<\/a> also be a <a href=\"https:\/\/patents.google.com\/patent\/US7215773B1\/en\" target=\"_blank\" rel=\"noopener\">patent<\/a> issue.<\/li>\n<\/ul>\n<li>As of this writing, it appears the mailing list discussion has concluded without any obvious loss of community support for taproot. As researchers and businesses continue improving the state of the art in quantum computing, we expect to see future discussions about how to best keep Bitcoin secure.<\/li>\n<li>Weekly taproot activation meetings: ten weekly meetings to discuss details related to activating <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> have been scheduled for each Tuesday at 19:00 UTC in the <a href=\"https:\/\/webchat.freenode.net\/##taproot-activation\" target=\"_blank\" rel=\"noopener\">##taproot-activation<\/a> IRC channel, with the first <a href=\"http:\/\/gnusha.org\/taproot-activation\/2021-03-23.log\" target=\"_blank\" rel=\"noopener\">meeting<\/a> occurring yesterday (March 23rd).<\/li>\n<\/ul>\n<h2>Changes to services and client software<\/h2>\n<p><em>In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.<\/em><\/p>\n<ul>\n<li>OKCoin launches Lightning deposits and withdrawals: A <a href=\"https:\/\/blog.okcoin.com\/2021\/03\/04\/how-to-use-bitcoin-lightning-network\/\" target=\"_blank\" rel=\"noopener\">blog post<\/a> outlines OKCoin\u2019s Lightning deposit and withdrawal support. They also lowered their minimum deposit\/withdrawal limit from 0.001 to 0.000001 BTC as a result. At this time, 0.05 BTC is OKCoin\u2019s limit when transacting using LN.<\/li>\n<li>BitMEX announces bech32 support: In a <a href=\"https:\/\/blog.bitmex.com\/introducing-bech32-deposits-on-bitmex-to-deepen-bitcoin-integration-lower-fees\/\" target=\"_blank\" rel=\"noopener\">blog post<\/a>, BitMEX detailed the launch plans for bech32 deposit support. BitMEX had <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/12\/18\/#bitmex-bech32-send-support\" target=\"_blank\" rel=\"noopener\">previously<\/a> rolled out <a href=\"https:\/\/bitcoinops.org\/en\/topics\/bech32\/\" target=\"_blank\" rel=\"noopener\">bech32<\/a> withdrawal (send) support.<\/li>\n<li>Specter v1.2.0 released: <a href=\"https:\/\/github.com\/cryptoadvance\/specter-desktop\/releases\/tag\/v1.2.0\" target=\"_blank\" rel=\"noopener\">Specter v1.2.0<\/a> includes support for Bitcoin Core <a href=\"https:\/\/bitcoinops.org\/en\/topics\/output-script-descriptors\/\" target=\"_blank\" rel=\"noopener\">descriptor wallets<\/a> and coin control features.<\/li>\n<li>Breez streams audio for Lightning payments: Breez wallet has integrated an audio player which, combined with <a href=\"https:\/\/bitcoinops.org\/en\/topics\/spontaneous-payments\/\" target=\"_blank\" rel=\"noopener\">keysend<\/a>, allows users to listen to podcasts while streaming payments to the publisher and sending one-off tip payments.<\/li>\n<li>Key manager Dux Reserve announced: Thibaud Mar\u00e9chal <a href=\"https:\/\/twitter.com\/thibm_\/status\/1369331407441510405\" target=\"_blank\" rel=\"noopener\">announced<\/a> Dux Reserve, a beta open source desktop key manager supported on MacOS, Windows, and Linux and supporting Ledger, Coldcard, and Trezor hardware wallets.<\/li>\n<li>Coldcard now using libsecp256k1: Coldcard\u2019s version 4.0.0, among other features, switches to using Bitcoin Core\u2019s <a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\" target=\"_blank\" rel=\"noopener\">libsecp256k1<\/a> library for its cryptographic operations.<\/li>\n<\/ul>\n<h2>Releases and release candidates<\/h2>\n<p><em>New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/releases\/tag\/v0.10.0rc1\" target=\"_blank\" rel=\"noopener\">C-Lightning 0.10.0-rc1<\/a> is a release candidate for the next major version of this LN node software.<\/li>\n<\/ul>\n<h2>Notable code and documentation changes<\/h2>\n<p><em>Notable changes this week in <\/em><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Core<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/ElementsProject\/lightning\" target=\"_blank\" rel=\"noopener\"><em>C-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/ACINQ\/eclair\" target=\"_blank\" rel=\"noopener\"><em>Eclair<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/\" target=\"_blank\" rel=\"noopener\"><em>LND<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\" target=\"_blank\" rel=\"noopener\"><em>Rust-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\" target=\"_blank\" rel=\"noopener\"><em>libsecp256k1<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\" target=\"_blank\" rel=\"noopener\"><em>Hardware Wallet Interface (HWI)<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\" target=\"_blank\" rel=\"noopener\"><em>Rust Bitcoin<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/\" target=\"_blank\" rel=\"noopener\"><em>BTCPay Server<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin\/bips\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Improvement Proposals (BIPs)<\/em><\/a><em>, and <\/em><a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/\" target=\"_blank\" rel=\"noopener\"><em>Lightning BOLTs<\/em><\/a><em>.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/20861\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #20861<\/a> implements support for <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0350.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP350<\/a> (Bech32m format for v1+ witness addresses). Bech32m supersedes bech32 (<a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0173.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP173<\/a>) as the address format for native segwit outputs of version 1-16. Native segwit version 0 outputs (P2WPKH and P2WSH) will continue to use bech32. This PR would enable Bitcoin Core users to send payments to Pay to Taproot (P2TR) addresses once taproot outputs (<a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0341.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP341<\/a>) were defined on the network. The change should not affect any mainnet systems, but may cause address incompatibility issues in testing environments such as signet where taproot is already active using bech32-encoded addresses as previously proposed. Bech32m support will also be backported to Bitcoin Core 0.19, 0.20, and 0.21.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21141\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21141<\/a> updates the -walletnotify configuration setting that calls a user-specified command each time a transaction is seen that affects a loaded wallet. Two new placeholders are added to the arguments that can be passed to the command, %b for the hash of a block containing the transaction and %h for the height of the block. Both are set to defined values for unconfirmed transactions.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4428\" target=\"_blank\" rel=\"noopener\">C-Lightning #4428<\/a> deprecates the fundchannel_complete RPC\u2019s acceptance of txids, requesting instead that a <a href=\"https:\/\/bitcoinops.org\/en\/topics\/psbt\/\" target=\"_blank\" rel=\"noopener\">PSBT<\/a> be passed. The PSBT can be checked to ensure it contains the funding output, eliminating a <a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4416\" target=\"_blank\" rel=\"noopener\">problem<\/a> where a user who passes incorrect data can lose the ability to recover their funds.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4421\" target=\"_blank\" rel=\"noopener\">C-Lightning #4421<\/a> implements the funding transaction recovery procedure covered in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/03\/17\/#rescuing-lost-ln-funding-transactions\" target=\"_blank\" rel=\"noopener\">last week\u2019s newsletter<\/a>. Users who mistakenly funded channels with a first-party malleated transaction (e.g. using RBF) but haven\u2019t used the channel yet can now supply their transaction output to the lightning-close command to negotiate recovery with a peer supporting the shutdown_wrong_funding feature.<\/li>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/5068\" target=\"_blank\" rel=\"noopener\">LND #5068<\/a> makes available a number of new configuration options for limiting how much network gossip information LND processes. This can help on systems with limited resources.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\/issues\/831\" target=\"_blank\" rel=\"noopener\">Libsecp256k1 #831<\/a> implements an algorithm that can speed up signature verification by 15%. It can also reduce by 25% the amount of time it takes to generate signatures while still using a constant-time algorithm that maximizes side-channel resistance. It additionally removes some of Libsecp256k1\u2019s dependencies on other libraries. See <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/02\/17\/#faster-signature-operations\" target=\"_blank\" rel=\"noopener\">Newsletter #136<\/a> for more information about this optimization.<\/li>\n<\/ul>\n<p><a href=\"https:\/\/github.com\/bitcoin\/bips\/issues\/1059\" target=\"_blank\" rel=\"noopener\">BIPs #1059<\/a> adds <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0370.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP370<\/a> specifying version 2 PSBTs as previously discussed on the mailing list (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/12\/16\/#new-psbt-version-proposed\" target=\"_blank\" rel=\"noopener\">Newsletter #128<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week\u2019s Bitcoin Optech newsletter covers signature delegation, Taproot\u2019s effect on Bitcoin\u2019s resistance to quantum cryptography and more<\/p>\n","protected":false},"author":3246,"featured_media":9590,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[2887,1075],"class_list":{"0":"post-17319","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-optech","9":"tag-taproot"},"author_data":{"id":3246,"name":"Bitcoin Optech","nicename":"bitcoin-optech","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/optech-notext-96x96.png"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/bitcoin-and-modern-soft-fork-activation.png","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/17319","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/3246"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=17319"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/17319\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/9590"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=17319"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=17319"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=17319"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}