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 StackExchange, releases and release candidates, and notable merges from Bitcoin infrastructure projects.

Action items

None this week.

News

  • ● 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 StackExchange

Bitcoin StackExchange 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.

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

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

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 getdata request 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. getrawmempool and getmempoolentry) with an unbroadcast field 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 getmempoolinfo RPC is updated with an unbroadcastcount field 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 sendrawtransaction RPC.

  • ● Bitcoin Core #18677 adds a new --enable-multiprocess build configuration option that will produce additional binaries alongside the existing bitcoind and bitcoin-qt binaries. 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.

  • ● Bitcoin Core #18594 allows bitcoin-cli -getinfo to print the balance of each wallet loaded in multiwallet mode.

  • ● 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 txprepare RPC, 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).

  • ● LND #4227 removes raw private key handling from various packages, paving the way for hardware wallet signing support. The larger effort to remove all private key handling can be tracked here.