{"id":16837,"date":"2021-04-28T15:42:59","date_gmt":"2021-04-28T15:42:59","guid":{"rendered":"http:\/\/ci0281c3abd0002568"},"modified":"2025-10-02T10:22:04","modified_gmt":"2025-10-02T15:22:04","slug":"bitcoin-optech-newsletter-146","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-newsletter-146","title":{"rendered":"Bitcoin Optech #146: Splicing, Workshop Announcements And More"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>The Bitcoin Optech 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 to subscribe to receive this content straight to your inbox.<\/em><\/p>\n<p>This week\u2019s newsletter describes a draft specification for LN splicing, announces a workshop about transaction relay security, announces the addition of ECDSA signature adaptor support to libsecp256k1-zkp, and links to proposals to change the BIPs process. Also included are our regular sections with summaries of popular questions and answers from the Bitcoin StackExchange, announcements of software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.<\/p>\n<h2>News<\/h2>\n<ul>\n<li>Draft specification for LN splicing: Rusty Russell opened a PR to the Lightning Specifications repository (\u201cBOLTs\u201d) proposing the protocol changes necessary to accommodate <a href=\"https:\/\/bitcoinops.org\/en\/topics\/splicing\/\" target=\"_blank\" rel=\"noopener\">splicing<\/a>. He also <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2021-April\/002999.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> a link for the PR to the Lightning-Dev mailing list. Splicing will allow transferring funds from onchain outputs into an existing payment channel, or from an existing payment channel to independent onchain outputs, without the channel participants having to wait for a confirmation delay to spend the channel\u2019s other funds. This helps wallets hide from their users the technical details of managing balances. For example, Alice\u2019s wallet can automatically pay Bob offchain or onchain from the same payment channel\u2014offchain using LN through that payment channel or onchain using a splice out (withdrawal) from that payment channel.<br \/>Russell previously <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2018-October\/001434.html\" target=\"_blank\" rel=\"noopener\">proposed<\/a> a draft specification for splicing in 2018 (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2018\/10\/16\/#proposal-for-lightning-network-payment-channel-splicing\" target=\"_blank\" rel=\"noopener\">Newsletter #17<\/a>) but this new draft has the advantage of being able to use the interactive funding protocol that\u2019s included as part of C-Lightning\u2019s experimental support for <a href=\"https:\/\/bitcoinops.org\/en\/topics\/dual-funding\/\" target=\"_blank\" rel=\"noopener\">dual funding<\/a>.<\/li>\n<li>Call for topics in layer-crossing workshop: Antoine Riard <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2021-April\/003002.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> to both the Bitcoin-Dev and Lightning-Dev mailing lists about an upcoming IRC-based workshop he plans to host to discuss <a href=\"https:\/\/github.com\/ariard\/L2-zoology\" target=\"_blank\" rel=\"noopener\">challenges<\/a> with onchain transaction relay that affect layer-two protocols such as LN. The goal is to build technical consensus among the participants about which proposals are especially worth perusing so that developers and reviewers can focus on those proposals in the short term.<br \/>The post proposes an agenda that includes <a href=\"https:\/\/bitcoinops.org\/en\/topics\/package-relay\/\" target=\"_blank\" rel=\"noopener\">package relay<\/a>, fee sponsorship (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/09\/23\/#transaction-fee-sponsorship\" target=\"_blank\" rel=\"noopener\">Newsletter #116<\/a>), moving from <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0125.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP125<\/a> opt-in Replace By Fee (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/replace-by-fee\/\" target=\"_blank\" rel=\"noopener\">RBF<\/a>) to full RBF, improving coordination of security response between primarily onchain projects such as full nodes and primarily offchain projects like LN nodes, and defining what mempool and relay policies can be reasonably depended upon by layer two protocols. Riard also asks for additional topic suggestions from anyone planning to attend, with May 7th being the deadline for submissions. The workshop will likely be held mid June.<\/li>\n<li>Support for ECDSA signature adaptors added to libsecp256k1-zkp: <a href=\"https:\/\/bitcoinops.org\/en\/topics\/adaptor-signatures\/\" target=\"_blank\" rel=\"noopener\">signature adaptors<\/a> were originally described for Bitcoin by Andrew Poelstra using <a href=\"https:\/\/bitcoinops.org\/en\/topics\/schnorr-signatures\/\" target=\"_blank\" rel=\"noopener\">schnorr<\/a>-based <a href=\"https:\/\/bitcoinops.org\/en\/topics\/multisignature\/\" target=\"_blank\" rel=\"noopener\">multisignatures<\/a>. This allows a single signature to do up to three things at once: (1) prove its creator had access to a certain private key, (2) prove knowledge of an encryption key pre-selected by another party, (3) reveal a pre-selected encryption key to another party. This allows a signature alone to do many of the things we currently do with Bitcoin scripts, suggesting adaptor signatures could be used to create \u201cscriptless scripts\u201d.<br \/>Accomplishing the same on ECDSA is not as easy. However, Lloyd Fournier <a href=\"https:\/\/github.com\/LLFourn\/one-time-VES\/blob\/master\/main.pdf\" target=\"_blank\" rel=\"noopener\">suggested<\/a> it would be relatively simple if we separated goal #1 (proof of private key) from goals #2 and #3 (proving and revealing encryption keys, AKA adaptors). This requires using one signature object as just a signature and another signature object for the adaptors, so it uses OP_CHECKMULTISIG and is not quite as scriptless as before. The separated construction also requires a <a href=\"https:\/\/github.com\/ElementsProject\/secp256k1-zkp\/pull\/117\/commits\/6955af5ca8930aa674e5fdbc4343e722b25e0ca8#diff-0bc5e1a03ce026e8fea9bfb91a5334cc545fbd7ba78ad83ae5489b52e4e48856R14-R27\" target=\"_blank\" rel=\"noopener\">security warning<\/a> related to reusing some of the involved keys with Elliptic Curve Diffie Hellman (ECDH) key exchange and ElGamal encryption. Beyond that, this technique makes signature adaptors entirely usable on Bitcoin today, and it\u2019s what various <a href=\"https:\/\/bitcoinops.org\/en\/topics\/discreet-log-contracts\/\" target=\"_blank\" rel=\"noopener\">DLC<\/a> projects have been using.<br \/>In April 2020, Jonas Nick implemented support for these simplified ECDSA signature adaptors in a draft PR (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/04\/08\/#work-on-ptlcs-for-ln-using-simplified-ecdsa-adaptor-signatures\" target=\"_blank\" rel=\"noopener\">Newsletter #92<\/a>). Jesse Posner <a href=\"https:\/\/github.com\/ElementsProject\/secp256k1-zkp\/pull\/117\" target=\"_blank\" rel=\"noopener\">ported<\/a> and extended the PR to libsecp256k1-zkp, a fork of <a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\" target=\"_blank\" rel=\"noopener\">libsecp256k1<\/a> that supports more advanced cryptographic protocols. This updated PR has now been merged after a detailed review process that involved several conversations that may be of interest to anyone seeking to better understand the security of signature adaptors.<\/li>\n<li>Problems with the BIPs process: after some drama on the BIPs repository (and perhaps some previous pent-up frustrations), several discussions were started on the mailing list about adding a <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-April\/018835.html\" target=\"_blank\" rel=\"noopener\">new BIPs editor<\/a>, using a <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-April\/018849.html\" target=\"_blank\" rel=\"noopener\">bot<\/a> to merge BIPs PRs, or abandoning the <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-April\/018859.html\" target=\"_blank\" rel=\"noopener\">centralized BIPs repository<\/a> altogether.<\/li>\n<\/ul>\n<h2>Selected Q&amp;A from Bitcoin StackExchange<\/h2>\n<p><a href=\"https:\/\/bitcoin.stackexchange.com\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin StackExchange<\/em><\/a><em> is one of the first places Optech contributors look for answers to their questions\u2014or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/105522\" target=\"_blank\" rel=\"noopener\">What are the different contexts where MTP is used in Bitcoin?<\/a> David A. Harding defines Median Time Past (MTP) and outlines how MTP is used to:<\/li>\n<ol>\n<li>determine the validity of a block using its nTime field, controlling difficulty adjustment period times<\/li>\n<li>ensure that time only moves forward, simplifying <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0009.mediawiki#state-transitions\" target=\"_blank\" rel=\"noopener\">state transitions<\/a> in BIP9<\/li>\n<li>eliminate the incentive for individual miners to confirm transactions with locktimes up to two hours in the future by lying about the current time, as fixed in <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0113.mediawiki#specification\" target=\"_blank\" rel=\"noopener\">BIP113<\/a><\/li>\n<\/ol>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/105346\" target=\"_blank\" rel=\"noopener\">Can Taproot be used to commit arbitrary data to chain without any additional footprint?<\/a> Pieter Wuille answers by pointing out that while committing to data via OP_RETURN in a <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/05\/14\/#complex-spending-with-taproot\" target=\"_blank\" rel=\"noopener\">tapleaf<\/a> is possible, techniques like <a href=\"https:\/\/bitcoin.stackexchange.com\/a\/37208\/87121\" target=\"_blank\" rel=\"noopener\">pay-to-contract<\/a> and <a href=\"https:\/\/blog.eternitywall.com\/2018\/04\/13\/sign-to-contract\/\" target=\"_blank\" rel=\"noopener\">sign-to-contract<\/a> are in use currently by Liquid and <a href=\"https:\/\/opentimestamps.org\/\" target=\"_blank\" rel=\"noopener\">OpenTimestamps<\/a> and can be more efficient.<\/li>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/105694\" target=\"_blank\" rel=\"noopener\">Why does the mined block differ so much from the block template?<\/a> User Andy asks why block 680175 differs from what his getblocktemplate RPC had output around the same time that block was mined. Andrew Chow and Murch point out <a href=\"https:\/\/bitcoin.stackexchange.com\/a\/56518\/5406\" target=\"_blank\" rel=\"noopener\">Asicboost<\/a> as the reason the version field is different, while node-independent mempools and node uptime are considerations of the block\u2019s transaction discrepancies.<\/li>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/105618\" target=\"_blank\" rel=\"noopener\">Isn\u2019t Bitcoin\u2019s hash target supposed to be a power of 2?<\/a> Andrew Chow explains the \u2018leading zeros\u2019 explanation of difficulty targeting is an oversimplification and chytrik gives an example of a valid and invalid hash with the same number of leading zeros.<\/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:\/\/bitcoincore.org\/bin\/bitcoin-core-0.21.1\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Core 0.21.1rc1<\/a> is a release candidate for a version of Bitcoin Core that contains activation logic for the proposed <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> soft fork. Taproot uses <a href=\"https:\/\/bitcoinops.org\/en\/topics\/schnorr-signatures\/\" target=\"_blank\" rel=\"noopener\">schnorr signatures<\/a> and allows the use of <a href=\"https:\/\/bitcoinops.org\/en\/topics\/tapscript\/\" target=\"_blank\" rel=\"noopener\">tapscript<\/a>. These are, respectively, specified by BIPs <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0341.mediawiki\" target=\"_blank\" rel=\"noopener\">341<\/a>, <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0340.mediawiki\" target=\"_blank\" rel=\"noopener\">340<\/a>, and <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0342.mediawiki\" target=\"_blank\" rel=\"noopener\">342<\/a>. Also included is the ability to pay <a href=\"https:\/\/bitcoinops.org\/en\/topics\/bech32\/\" target=\"_blank\" rel=\"noopener\">bech32m<\/a> addresses specified by <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0350.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP350<\/a>, although bitcoins spent to such addresses on mainnet will not be secure until activation of a soft fork using such addresses, such as taproot. The release additionally includes bug fixes and minor improvements.<\/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\/21595\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21595<\/a> adds a new addrinfo command to the bitcoin-cli executable. Running bitcoin-cli -addrinfo returns a count of the network addresses of potential peers known to the node, split by network type. Sample output:<\/li>\n<\/ul>\n<blockquote>\n<p>$ bitcoin-cli -addrinfo<\/p>\n<p>{<\/p>\n<p>&#8220;addresses_known&#8221;: {<\/p>\n<p>&#8220;ipv4&#8221;: 14406,<\/p>\n<p>&#8220;ipv6&#8221;: 2511,<\/p>\n<p>&#8220;torv2&#8221;: 5563,<\/p>\n<p>&#8220;torv3&#8221;: 2842,<\/p>\n<p>&#8220;i2p&#8221;: 8,<\/p>\n<p>&#8220;total&#8221;: 25330<\/p>\n<p>}<\/p>\n<p>}<\/p>\n<\/blockquote>\n<ul>\n<li>Rust-Lightning #844 adds support for message signing, signature verification, and public key recovery using a scheme compatible with those of <a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/192\" target=\"_blank\" rel=\"noopener\">LND<\/a>, <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/10\/23\/#c-lightning-3150\" target=\"_blank\" rel=\"noopener\">C-Lightning<\/a>, and <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/08\/12\/#eclair-1499\" target=\"_blank\" rel=\"noopener\">Eclair<\/a>.<\/li>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/issues\/2356\" target=\"_blank\" rel=\"noopener\">BTCPay Server #2356<\/a> adds support for multifactor authentication using the <a href=\"https:\/\/en.wikipedia.org\/wiki\/FIDO2_Project\" target=\"_blank\" rel=\"noopener\">WebAuthN\/FIDO2<\/a> protocols. Existing multifactor authentication in BTCPay using <a href=\"https:\/\/en.wikipedia.org\/wiki\/Universal_2nd_Factor\" target=\"_blank\" rel=\"noopener\">U2F<\/a> continues to work.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\/issues\/906\" target=\"_blank\" rel=\"noopener\">Libsecp256k1 #906<\/a> reduces the number of iterations needed to compute modular inverses from 724 to 590 when using a constant-time algorithm that should be more resistant to side-channel attacks than a variable-time algorithm. The correctness of the algorithm was checked using the <a href=\"https:\/\/coq.inria.fr\/\" target=\"_blank\" rel=\"noopener\">Coq proof assistant<\/a>, with the most strict verification taking approximately 66 days of runtime. 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 the algorithmic advance that led to this improvement.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/04\/28\/\" target=\"_blank\" rel=\"noopener\">original post here<\/a>. <\/p>\n<p>Please <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">subscribe to the Bitcoin Optech newsletter<\/a> directly to receive this content straight to your inbox every month.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week\u2019s newsletter covers using Lightning Network splicing, announcements for a layer-crossing workshop and more.<\/p>\n","protected":false},"author":3246,"featured_media":10844,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[2887,460,3059],"class_list":{"0":"post-16837","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-optech","9":"tag-lightning-network","10":"tag-workshops"},"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\/cybersecurity-firm-reports-all-fortune-500-companies-exposed-on-the-dark-web.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/16837","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=16837"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/16837\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/10844"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=16837"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=16837"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=16837"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}