Idelto

Cryptocurrency news website

Bitcoin Core

Bitcoin Core 22.0 Explained

by

The Van Wirdum Sjorsnado has rebranded, and is now called Bitcoin, Explained!

Watch This Episode On YouTube

Listen To This Episode:

  • Apple
  • Spotify
  • Google
  • Libsyn
  • Overcast

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss Bitcoin Core 22.0, the latest major release of the Bitcoin Core software client, currently the de facto reference implementation of the Bitcoin protocol. 

Van Wirdum and Provoost highlight several improvements to the Bitcoin Core software. The first of these is hardware wallet support in the graphical user interface (GUI). 

While hardware wallet support has been rolling out across several previous Bitcoin Core releases, it is now fully available in the GUI. 

The second highlighted upgrade is support for the Invisible Internet Project (I2P), a Tor-like internet privacy layer. 

Van Wirdum and Provoost also briefly touch on the differences between I2P and Tor. The third upgrade discussed in the episode is Taproot support. While Taproot activation logic was already included in Bitcoin Core 0.21.1 Bitcoin Core 22.0 is the first major Bitcoin Core release ready to support Taproot when it activates this November, and includes some basic Taproot functionality. 

The fourth upgrade that Aaron and Sjors discuss is an update to the testmempoolaccept logic, which paves the way to a bigger package relay upgrade. This could in a future release allow transactions to be transmitted over the Bitcoin network in packages including several transactions at the same time. 

Additionally, Aaron and Sjors briefly discuss an extension to create multisig and add multisig address, the new NAT-PMP option, and more.

How Marco Falke Maintains The Bitcoin Network

by

Now Bitcoin Core’s most prolific developer, Marco Falke’s work is the daily maintenance and testing of an open-source project that must reject error.

Last week, Bitcoin Developer Marco Falke logged his 1,752nd commit to Bitcoin Core’s codebase, passing W. J. van der Laan to become the most prolific Core Dev in terms of the sheer number of individual changes submitted to the project.

As a full-time Bitcoin Core repository maintainer since 2016, Falke himself is the first to point out that many of his commits represent minor tweaks that are merged to the codebase relatively easily, and that this milestone in and of itself does not make him Bitcoin’s most important or enterprising contributor. But, after all, Bitcoin is code, and the work that Falke does as a maintainer of that code every day — reviewing contributions to ensure that they provide improvement to the protocol, maintaining continuity across the network and organizing the code so it is easy for developers to work with — is critical.

“When it comes to my contributions, I think the majority are smaller improvements, which are each exciting for their own reasons,” Falke told Bitcoin Magazine. “I’ve mostly continued to improve testing and spend time on quality assurance and review.”

The most substantive of Falke’s development work on Bitcoin has probably been his contributions around its testing infrastructure, something he identified early on as an inefficiency in the project that he was passionate about improving. Bitcoin’s test environment is used to review potential changes to the codebase, allowing developers to peer review one another’s work and identify potential problems. Falke has dedicated much of his career to improving this test environment so this process is more efficient.

“When I saw what a critical project Bitcoin Core was, that was the same time I realized that the testing infrastructure for Bitcoin Core was not in any way sufficient, and I was motivated to improve it,” said Falke, who started “lurking” on the Bitcoin project in 2014 and began contributing to the code the next year. “For example, the functional tests back then were mostly superficial or even completely broken — incapable of detecting any issues at all. I started off by fixing the obvious bugs in the tests and rewrote the test framework to use modern Python 3, instead of Python 2, which was being deprecated back then.”

Until last year, Falke was based in New York City, working full-time for Bitcoin research and development firm Chaincode Labs. But now he works remotely from an undisclosed location thanks to an open-source developer grant from cryptocurrency exchange OKCoin, a revenue source that he said makes it much easier for developers to work on open-source projects like Bitcoin Core.

“Apart from my work, I do enjoy getting (mostly) regular and enough sleep, since my brain will refuse to work when I am on less than eight hours of sleep for a few days,” Falke added. “Also, I try to exercise at least every second day to give my brain more time to recover and also stimulate the remainder of my body through sport.”

It should not be surprising that Bitcoin’s most active maintainer, who is also one of its quality assurance leaders, sees the project’s notorious resistance to change as one of its standout qualities.

“One major difference is the level of scrutiny,” Falke said of Bitcoin Core as a software project. “Every change to Bitcoin Core needs to go through code review. Changes that touch critical areas (consensus or networking code, for instance) or are deemed riskier, need to go through code review by multiple people… Which is a good thing for Bitcoin, because Bitcoin users wouldn’t want the consensus rules to change willy nilly.”

As possibly the world’s most important open-source software project, Bitcoin is a pioneer in a few ways. From Falke’s perspective, another one of the most critical things that sets the Bitcoin project apart is the opportunity given to users to verify new code releases (provided as “compiled release binaries,” or compiled versions of the application for computers to read and implement) and protect against malware injection. To help users authenticate the new releases, Core Devs provide “reproducible builds,” software compilations that serve as instructions to verify new code — something that Falke said should be a standard way to ship releases in the world of open-source software, but is not yet.

Finally, Falke also highlighted Bitcoin’s thorough “fuzz testing,” a quality assurance technique that helps discover code errors that otherwise might lead to security breaches or other malfunctions.

“Bitcoin Core is also extensively fuzz tested, which is also not yet the norm for the average open-source project,” he said. “I am already happy with the overall state of our testing infrastructure, but I think an area of still low-hanging fruits for improvement are the fuzz tests.”

Falke also sees education as a major need in the Bitcoin Dev community, something that he helps with as he can.

As someone whose work is in the daily nurturing of Bitcoin Core, now leading its history in the number of successful changes made to the code, Falke is clearly happy maintaining the network and keeping it running for the rest of us.

Taproot Activation Brings Massive Upgrades To Bitcoin

by

Taproot brings new optimizations to security and usability to the Bitcoin network as the activation is locked in.

By the time this is published, Taproot will be locked-in for activation. This means that on block 709,632 (mid-November 2021), the new rules defined by a series of Bitcoin Improvement Proposals (BIPs) will be activated and start being enforced. This is a momentous achievement for Bitcoin and will enable so many awesome new things for not just Bitcoin but everything built on top of it, too.

Previously, it was debated if Bitcoin could come to consensus on another soft fork after the drama behind the 2017 SegWit upgrade. This previous soft fork spun out multiple camps that hard forked from the original Bitcoin chain, creating new altcoins. Meanwhile, the Bitcoin community was left with deep battle scars after months of debating and fighting for what resulted in a user activated soft fork (UASF).

It’s been almost four years since SegWit activated and people were skeptical that the Bitcoin community could overcome these battle scars for the next upgrade to Bitcoin. However, we have done it! It was a long process of debating on pull requests (PRs), Internet Relay Chat (IRC) channels, and Twitter, but it has finally come to a close.

Taproot as an upgrade had virtually no push back; by and large every core developer agreed with the consensus changes proposed in BIP340, BIP341 and BIP342. These BIPs propose changes that add privacy and optimizations as well as enabling new features in the future without any new security assumptions. Taproot by itself is a no-brainer upgrade to the Bitcoin protocol. The controversy came in when the discussions started on how to activate Taproot.

The controversy began with BIP8 which was created in response to what happened with SegWit. It made two changes to BIP9, the activation method used for SegWit. The first change was to define the start and end times of the activation by block height instead of real-world time. This makes defining the activation window slightly better because we aren’t reliant on blocks having exactly a 10-minute block time but with the tradeoff of being worse for test networks.

The second change was to add an optional user activated soft fork (UASF) at the end of the activation, known as lock-in-on-timeout or LOT. Both of these changes sparked heavy debate on if they should be made and resulted in many PRs being opened and closed to Bitcoin Core. The LOT parameter was eventually thrown out and replaced with a procedure called Speedy Trial.

Speedy Trial was proposed to break the stalemate between the two camps arguing over how to set LOT (true vs false). Speedy Trial described a three-month activation window instead of a one-year window, but with a minimum activation height that would be further in the future and with no UASF. This was structured so that we could either activate quickly or fail quickly. If we were to fail quickly, we could go back to debating. Or if we did activate quickly, the surrounding ecosystem would have more time to prepare for the upgrade.

Most developers agreed to try Speedy Trial which led to two PRs being opened to Bitcoin Core, one by Andrew Chow and another by A.J. Towns. Chow’s PR proposed using block height while Towns’ used real-world time. This led to further debate and lots of discussion on IRC that was eventually settled with Chow and Towns agreeing to move forward with Towns’ proposal.

All of this debate finally led to the culmination of Taproot being able to activate. Then we just needed miners to signal, which happened relatively quickly. Alejandro De La Torre, vice president of Poolin, had already gotten mining pools to commit to saying they would signal. However, at the start only Slush Pool was signaling. The plebs took to the streets and made memes donning green squares, a reference to taproot.watch’s way of showing which blocks signaled for activation and which did not. However, after only three difficulty adjustment periods we have achieved almost 99% of the hash power from miners signaling and have locked in the activation of Taproot.

Now that we can confidently say that Taproot will be part of the Bitcoin protocol, we should know what this will mean for Bitcoin and its many layers. As stated in the beginning, Taproot brings privacy and optimizations while allowing for new features in the future.

Taproot is able to add privacy to Bitcoin by allowing users to create multiple spending rules for their funds, but they only need to reveal the rules that were used for that transaction. In some cases there is no need to reveal there ever were other spending rules. The average Bitcoin user today doesn’t have a need for these sorts of complex rule scripts. However, most scaling solutions in Bitcoin do. Layers such as the Lightning Network, Liquid, and other sidechains all use scripted rules like multisig, hash time locks, and other tools to make their system secure. Today this all needs to be put on chain and revealed to the entire network. With Taproot this information no longer needs to be revealed all the time and transactions like Lightning channel opens can look exactly like a normal user’s transactions. So not only will it benefit Lightning users but it will benefit everyone as the general anonymity set of Bitcoin will grow, making privacy-compromising chain analysis harder to do.

Along with all these privacy improvements are lots of optimizations. Since we no longer need to reveal as much information on-chain, transactions will use less data and thus will reduce fees. This also means that more transactions will fit in each block and every unspent transaction output (UTXO) will be that much more efficient.

Not only do we get space-saving optimizations from Taproot, but we also get optimizations that will help with the speed of verifying transactions. Today, Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for signing transactions, but Taproot adds a new way to sign called Schnorr signatures. Schnorr signatures enable some of the space-saving optimizations we talked about while also being faster to verify, so running a full node will be less resource intensive with the same transaction throughput if Taproot sees significant adoption.

Taproot will also enable many new use cases and features. Something that has been talked about for awhile is Point Time Lock Contracts (PTLCs). PTLCs are a change to the Lightning Network that enable developers to build more complex applications on top of Lightning like Discreet Log Contracts, stuck-less payments and more. Taproot also allows for much less invasive upgrades in the future. Taproot left many new upgrade paths that we are already seeing people write proposals to use, namely SIGHASH_ANYPREVOUT. This should make the next Bitcoin soft fork happen more quickly and be less controversial as it will not carry as much weight as the upgrades before it.

In conclusion, Bitcoin has upgraded and has taken a step forward in making privacy better for its users. This did not come easy and it certainly shouldn’t have. However, now it’s time to celebrate and then start building.

This is a guest post by Ben Carman. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.

Bitcoin Optech #149: Relay Reliability Workshops And More

by

This week’s newsletter discussed the previously proposed transaction relay reliability workshop, updates to Bitcoin software and more.

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’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter provides updates on the previously proposed transaction relay reliability workshop and CVE-2021-31876. Also included are our regular sections describing updates to services and client software, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

  • Relay reliability workshop scheduled: as mentioned in Newsletter #146, Antoine Riard will be hosting IRC-based meetings to discuss how to make unconfirmed transaction relay more reliable for contract protocols such as LN, coinswaps, and DLCs. The schedule is:
    • Jun 15th, 19:00–20:30 UTC: guidelines about L2 protocols onchain security design; coordination of cross-layer security disclosures; full-RBF proposal
    • June 22nd (same time): generic layer two fee bumping primitive (such as package relay)
    • June 29th (same time): reserved for additional discussion
  • CVE-2021-31876 BIP125 implementation discrepancy follow up: after the publication of last week’s newsletter, there was additional discussion about the discrepancy between BIP125 opt-in Replace-by-Fee (RBF) and Bitcoin Core’s implementation. Olaoluwa Osuntokun confirmed that the btcd full node implements BIP125 as specified, meaning it does allow child transactions to be replaced based on inherited signaling. Ruben Somsen noted that a hypothetical variation of spacechains, a type of one-way pegged sidechain, would be affected by the problem. On the other hand, Antoine “Darosior” Poinsot mentioned that the Revault vault architecture wouldn’t be affected.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

  • Blockchain.com supports segwit: v4.49.1 of Blockchain.com’s wallet adds the ability to create a wallet with native segwit send and receive support.
  • Sparrow 1.4.0 released: Sparrow 1.4.0 adds the ability to create a child pays for parent (CPFP) transaction from the transaction list screen, user-defined fee amounts during coin selection, and various other improvements.
  • Electrum 4.1.0 enhances Lightning features: Electrum 4.1.0 adds trampoline payments, multipath payments, channel backups, and other Lightning features. Additionally, this version of Electrum supports bech32m.
  • BlueWallet v6.1.0 released: BlueWallet’s v6.1.0 release adds Tor support, SLIP39 support, and functionality for using PSBTs with HD watch-only wallets.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

  • LND 0.13.0-beta.rc2 is a release candidate that adds support for using a pruned Bitcoin full node, allows receiving and sending payments using Atomic MultiPath (AMP), and increases its PSBT capabilities, among other improvements and bug fixes.

Notable code and documentation changes

Notable changes 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 #21462 adds tooling for attesting to outputs of Guix builds and verifying these attestations against those of others. After this change, Windows and macOS code signing remain the only missing piece before Guix builds reach feature-parity with Gitian builds.
  • Bitcoin Core GUI #280 prevents displaying invalid Bitcoin addresses in an error dialog, eliminating the ability to display an arbitrary message in an official-looking dialog. A simple “invalid address” error is now displayed instead. (See the PR for illustrative before and after screenshots.)
  • Bitcoin Core #21359 updates the fundrawtransaction, send and walletcreatefundedpsbt RPCs with a new include_unsafe parameter that can be used to spend unconfirmed UTXOs created by other users in the transaction. This allows fee bumping a transaction using CPFP and was added for that reason by a developer working on implementing anchor outputs in the Eclair LN node. The option should only be used when necessary, as unconfirmed transactions created by other users can be replaced, which may prevent any child transactions from being confirmed.
  • LND #5291 improves the way LND ensures that PSBTs for funding transactions only spend segwit UTXOs. LN requires segwit UTXOs in order to prevent txid malleability from making refund transactions unspendable. LND previously checked this by looking for the WitnessUtxo field in the PSBT, but this field is technically optional for segwit UTXOs and so some PSBT creators don’t provide it. The updated code will use the provided value if present or, if it’s not present, scan the UTXO set for the necessary information.
  • LND #5274 limits the maximum amount of funds the node reserves to allow CPFP fee bumping for anchor outputs to ten times the per-channel amount. For nodes with large numbers of channels, this limits their capital requirements. If they need to close more than 10 channels, they can use the funds received from closing one channel to close the next channel in a domino effect.
  • LND #5256 allows reading the wallet passphrase from a file. This is mainly meant for container-based setups where the passphrase is already stored in a file, so using that file directly doesn’t create any additional security problems.
  • LND #5253 adds support for Atomic Multipath Payment (AMP) invoices across high-level LND RPC commands such as SendPayment, AddInvoice, and SubscribeInvoice. AMP invoices are currently an LND-only feature and only accept HTLCs that have the AMP feature bits set as well as an AMP payload. This extends prior work that enabled use of AMP by providing manually specfied payment parameters to the SendPayment RPC.
  • Libsecp256k1 #850 adds a secp256k1_ec_pubkey_cmp method that compares two public keys and returns which one of them sorts earlier than the other (or returns that they’re equal). This was proposed for use with BIP67 key sorting, in particular as used with the sortedmulti output script descriptor.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.

Bitcoin Optech #148: A Security Disclosure Affecting Protocols

by

This week’s newsletter covers a security disclosure, a summary of a Bitcoin Core PR Review Club meeting and more.

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’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter describes a security disclosure affecting protocols depending on a certain BIP125 opt-in replace by fee behavior and includes our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

  • CVE-2021-31876 discrepancy between BIP125 and Bitcoin Core implementation: the BIP125 specification of opt-in Replace By Fee (RBF) says that an unconfirmed parent transaction that signals replaceability makes any child transactions that spend the parent’s outputs also replaceable through inferred inheritance. This week, Antoine Riard posted to the Bitcoin-Dev mailing list the full disclosure of his previously privately reported finding that Bitcoin Core does not implement this behavior. It is still possible for child transactions to be replaced if they explicitly signal replaceability or for them to be evicted from the mempool if their parent transaction is replaced.
    Riard analyzed how the inability to use inherited replaceability might affect various current and proposed protocols. Only LN appears to be affected and only in the sense that an existing attack (see Newsletter #95) that uses pinning becomes cheaper. The ongoing deployment of anchor outputs by various LN implementations will eliminate the ability to perform that pinning.
    As of this writing, there has not been any substantial discussion of the issue on the mailing list.
  • Call for Brink grant applications: Bitcoin Optech encourages any engineer contributing to open source Bitcoin or Lightning projects to apply for a Brink grant before the application deadline on May 17th. Initial grants are one year long and allow developers to work full time on open source projects from anywhere in the world.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Introduce node rebroadcast module is a PR (#21061) by Amiti Uttarwar that continues work on the rebroadcast project (see Newsletters #64, #96, #129 and #142), previously discussed in review clubs #16698 and #18038, whose goal is to make node rebroadcast behavior for wallet transactions indistinguishable from that of other peers’ transactions.

The review club discussion focused on current transaction behavior and the proposed changes:

  • Why might we want to rebroadcast a transaction? When our transaction didn’t propagate (perhaps our node was offline) or appears to have been dropped by other nodes’ mempools in the network.
  • Why does a node drop a transaction from its mempool? Apart from being included in a block, a transaction can expire after 14 days, be squeezed out of a node’s limited mempool size (default size 300 MiB) by higher-fee transactions, be replaced via BIP125 opt-in Replace-By-Fee (RBF), be removed if a conflicting transaction is included in a block, or be included in a block that is later reorged out (in which case the node will try to re-add it while updating the mempool to be consistent again after the reorg).
  • What could be an issue with the current behavior of each wallet being responsible for rebroadcasting its own transactions?
    This can be a privacy leak that allows linking the IP address to the wallet address, as under the current rebroadcasting behavior, a node that broadcasts a transaction more than once is essentially announcing that the transaction is from its wallet.
  • When might a miner exclude a transaction that is in our mempool? When the miner deprioritized it for having a low fee, didn’t see it yet, removed it from its mempool by RBF, censored it, or mined an empty block.
  • When might a miner include a transaction that is not in our mempool? When the miner manually prioritized the transaction (e.g. as a commercial service), received it before our node, or the transaction conflicted with another one in our mempool but not in theirs.
  • How would the proposal under review decide which transactions to rebroadcast?
    Once per new block, it proposes to rebroadcast transactions above an estimated feerate that are at least 30 minutes old, have been rebroadcast no more than 6 times and not more recently than 4 hours ago, with up to 3/4 of the transactions that fit the block.
  • Why might we want to keep a transaction in our rebroadcast attempt tracker even after it has been removed from our mempool?
    After a consensus rule change, there can be non-updated nodes on the network rebroadcasting transactions that don’t meet the new consensus rules. Keeping transactions in the rebroadcast attempt tracker would avoid these nodes rebroadcasting them too many times (a maximum of 6 times over 90 days) and allow the transactions to expire.
  • When would we remove a transaction from our rebroadcast attempt tracker? When the transaction is confirmed, RBFed, or conflicts with another transaction included in a block.
  • How would the estimated minimum feerate for rebroadcast be calculated? Why not use the lowest feerate in the last mined block?
    The rebroadcast feerate floor would be estimated once a minute by assembling a block from the mempool to simulate inclusion in the next mined block. This approach is better than using the lowest feerate of the last mined block because it calculates fees based on the immediate future in a changing environment instead of based on the past.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

  • Rust-Lightning 0.0.14 is a new release that makes Rust Lightning more compatible with getting data from Electrum-style servers, adds additional configuration options, and improves compliance with the LN specification, among other bug fixes and improvements.

Notable code and documentation changes

Notable changes 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 #20867 increases the number of keys that can be included in multisig descriptors and used in the addmultisigaddress and createmultisig RPCs from 16 to 20. The increased limit can only be used in P2WSH outputs. P2SH outputs are limited to 520 byte scripts which are only large enough to hold 15 compressed public keys.
  • Bitcoin Core GUI #125 enables users to adjust the autoprune block space size from the default in the intro dialog. It also adds an improved description for how the pruned storage works, clarifying that the entire blockchain must be downloaded and processed but will be discarded in the future to keep disk usage low.
  • C-Lightning #4489 adds a funder plugin for configuring dual-funding contribution behavior in response to incoming channel open requests. Users will be able to specify a general contribution policy (percent match, percent available funds, or fixed contribution), a wallet reserve amount under which no dual-funding contributions will happen, a maximum contribution amount for any single channel open request, and more.
    This PR represents the last step in enabling experimental dual-funding support between C-Lightning nodes. The interactive transaction construction and channel establishment v2 protocols arising out of this work is still being standardized in the open BOLTs #851 PR.
  • C-Lightning #4496 adds the ability for plugins to register topics about which they plan to publish notifications. Other plugins can subscribe to those topics to receive notifications. C-Lightning already had several built-in topics, but this merged PR allows plugin authors to create and consume notifications for any new topic category they’d like to use.
  • Rust Bitcoin #589 starts the process of implementing support for taproot with schnorr signatures. The existing ECDSA support is moved to a new module but continues to be exported under existing names to preserve API compatibility. A new util::schnorr module adds support for BIP340 schnorr key encodings. Issue #588 is being used to track the complete implementation of taproot compatibility.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.