This week’s newsletter summarizes a discussion about the minimum allowed transaction size and includes our regular sections with popular questions and answers from the Bitcoin Stack Exchange, releases and release candidates, and notable merges from Bitcoin infrastructure projects.
None this week.
● Minimum transaction size discussion: Thomas Voegtlin posted to the Bitcoin-Dev mailing list about creating transactions with stripped sizes (non-witness sizes) as small as 60 bytes. Bitcoin Core refuses to relay or mine transactions smaller than 82 bytes. Gregory Sanders notes that the motivation for this rule is CVE-2017-12842 (described in Newsletter #27) where an attacker who can get a specially-crafted 64-byte transaction confirmed into a block can use it to convince SPV lightweight clients that one or more other arbitrary transactions have been confirmed, such as fake transactions that pay to lightweight wallets. As described in Newsletter #36, permanently eliminating the ability to perform that attack was proposed in the consensus cleanup soft fork by forbidding transactions with a stripped size of fewer than 65 bytes.
After describing the motivation for the current relay rule, Sanders asks whether the rule can be simplified to only forbid transactions whose stripped size is exactly 64 bytes. ZmnSCPxj replies that anything under 64 bytes could still be vulnerable, but that the 65-bytes-or-greater rule seems fine.
Selected Q&A from Bitcoin Stack Exchange
Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or 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.
● What are the sizes of single-sig and 2-of-3 multisig taproot inputs? Murch lists a variety of ways of spending from a taproot output and their associated costs.
● What if the mempool exceeds 300 MB? Andrew Chow and Murch outline how a node behaves after its mempool’s maximum size is reached. The node will begin to drop transactions with the lowest feerate and increase its
minMempoolFeeRatecommunicated to peers in order to keep the mempool size under that node’s
● Why isn’t RFC6979 used for schnorr signature nonce generation? Pieter Wuille describes some of the downsides of using RFC6979 and why BIP340 uses a simpler nonce-generation algorithm inspired by Ed25519.
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.
Notable code and documentation changes
Note: the commits to Bitcoin Core mentioned below apply to its master development branch and so those changes will likely not be released until version 0.21, about six months after the release of the upcoming version 0.20.
● Bitcoin Core #18956 uses the API on Windows systems to require Windows 7 or later. All release notes since the October 2018 release of Bitcoin Core 0.17 have announced that the only supported versions of Windows are version 7 or later.
● Bitcoin Core #18861 prevents the node from replying to a P2P protocol
getdatarequest for a transaction that it hasn’t yet announced to the requesting peer. This prevents surveillance nodes from circumventing Bitcoin Core’s existing privacy-enhancing behavior of waiting a slightly different amount of time for each peer (or group of peers) before announcing new transactions to them, causing each transaction to propagate across the network using a different path. Randomizing the propagation path of each transaction makes it less reliable for surveillance nodes to assume that the first node announcing a transaction was the first node to receive it.
● Bitcoin Core #17681 allows the wallet to internally derive new addresses for a BIP32 HD wallet seed even after that seed is no longer the wallet’s active seed. This makes it safe to switch to a new HD seed with the
sethdseed(set HD seed) RPC even while the node is performing an initial block chain download, such as when restoring a wallet backup on a newly-started node—the updated code ensures the wallet will see any payments to addresses previously derived from the old HD seed.
● Bitcoin Core #18895 updates the RPCs that return data about individual transactions in the mempool (e.g.
getmempoolentry) with an
unbroadcastfield that indicates whether or not any of the local node’s peers have requested a copy of the transaction (see Newsletter #96 for a summary of broadcast tracking). Additionally, the
getmempoolinfoRPC is updated with an
unbroadcastcountfield indicating the number of unbroadcast transactions. For privacy, the broadcast status of a transaction is only tracked if it was submitted by either the node’s wallet or the
● Bitcoin Core #18677 adds a new
--enable-multiprocessbuild configuration option that will produce additional binaries alongside the existing
bitcoin-qtbinaries. For now, the only difference between the new and old binaries is their name. However, if PR #10102 is merged, the new binaries will split the functions of node, wallet, and GUI into separate executables that communicate with each other when necessary. The build option is currently disabled by default. See also Newsletter #39 for the last time we wrote about the multiprocess sub-project.
● C-Lightning #3738 adds initial support for BIP174 Partially Signed Bitcoin Transactions (PSBT), making use of libwally’s PSBT support. The only user-visible change is that the PSBT form of the transaction is returned by the
txprepareRPC, but the PR is tagged in GitHub as working towards dual funding of new channels (see Newsletter #83 for discussion of using PSBT for interactive construction of funding transactions).