This week’s newsletter includes news and action items about minimum fees and the upcoming Bitcoin Core release, a special feature on a Schnorr signature proposal, and a write-up of the recent Building on Bitcoin conference in Lisbon.

Action items

  • Bitcoin Core minimum relay fee may be reduced in the next major release. Ensure your software doesn’t make unsafe assumptions about 1 satoshi per vbyte being the lowest possible floor. See News section below for more information.

  • Ensure your software for calculating transaction size for dynamic fees computes signature size accurately or, at least, uses a worst-case assumption of Bitcoin signatures being 72 bytes. See News section below for more information.

  • As previous newsletters announced would happen, the Bitcoin alert key was released along with a disclosure of vulnerabilities affecting Bitcoin Core 0.12.0 and earlier. Altcoins may be affected. If you have not yet checked your infrastructure for affected services, it is advised to do so now. See newsletter #1 for more details

Dashboard items

  • ● Transaction fees remain very low: as of this writing, fee estimates for confirmation 2 or more blocks in the future remain at roughly the level of the default minimum relay fee in Bitcoin Core. It’s a good time to consolidate inputs.
  • ● Block production recovery: following last week’s news about flooding in China affecting miner operations, Bitcoin block production seems to have recovered to the expected level of about one block every 10 minutes.

In a post to the bitcoin-dev mailing list, Pieter Wuille submitted a draft specification for a Schnorr-based signature format. The goal of the specification is to hopefully get everyone in agreement about what Schnorr signatures will look like on Bitcoin before work begins on an actual soft fork, so the BIP does not propose specific new opcodes, segwit witness flags, soft fork activation method, or anything else necessary to make this change part of the Bitcoin consensus rules. However, it is possible to say what this signature format will provide if it becomes the form of Schnorr signature adopted by Bitcoin.

  1. Full compatibility with existing Bitcoin private keys and public keys, meaning that existing HD wallets that upgrade won’t need to generate new recovery seeds.

  2. Roughly 10% smaller signatures, providing a slight increase to block chain capacity as Schnorr is adopted.

  3. Batch verification of signatures providing a roughly 2x speedup over individual verification for a block full of Schnorr signatures. This mainly affects nodes initially syncing or catching up after being offline.

  4. Full compression and significantly improved privacy for multisig use cases, but with required interaction: an unlimited number of participants can create a single 33-byte public key and 64-byte signature from the combination of their individual public keys and signatures, using secure multisig with the same efficiency of single-sig and increasing their privacy by making multisig look like single-sig. However, the scheme requires multistep interaction between the wallets participating in the multisig, both for creating the public key and the signature.

  5. Additional privacy-focused usecases. Examples include increased privacy for Lightning Network (LN), more private atomic swaps (either cross chain when both chains support Schnorr, or on the same chain as part of a coin mixing protocol), and fully private signing oracles (services that wait for something to happen in real life, like which team wins the world cup, and then provide a signature committing to that outcome, e.g. allowing Alice and Bob to settle a bet onchain or in a LN channel). Many of these cases also improve efficiency compared to alternatives that use current Bitcoin script.

One thing of note not in the BIP proposal is a method for signature aggregation between multiple inputs in the same transaction. This was a desired feature that could allow consolidation transactions, coinjoins, and other high-input transactions to be much more efficient than they are now. But, as the author of the proposal notes, “With the emergence of so many ideas for improvements to Bitcoin’s script execution (MAST, Taproot, Graftroot, new sighash modes, multisignature schemes, …) there is simply too much to do everything at once. Since aggregation really interacts with all other things, it seems like the better choice to pursue later.” (source)

News

  • ● Discussion about minimum relay fee: several years ago when the Bitcoin price was a fraction of its current value in USD terms, Bitcoin Core set the minimum relay fee to 1 satoshi per byte (now vbyte). With the increase in prices and other network changes, several developers discussed lowering the minimum relay fee. Gregory Maxwell is planning to open a pull request to Bitcoin Core that may roughly halve the value (although the exact amount has not been determined yet).

    This may be included in the next major version of Bitcoin Core. If so, it’ll mean that you may be able to create cheaper consolidation transactions once the change has been well deployed. However, it also means that if you don’t upgrade any nodes you use for detecting unconfirmed transactions, they may not see unconfirmed transactions with low feerates unless you change the defaults. This could affect the information you display to your users. Those nodes will still see all confirmed transactions in valid blocks.

    Note that to lower the minimum relay fee in Bitcoin Core below its default, you need to change two settings. Shown below are the two settings with their default values in Bitcoin Core 0.16.1; to lower the values, change both of them to the same value, but be aware that reducing them too far (perhaps to less than 1/10th the default) exposes you to bandwidth-wasting attacks and reduces BIP152 compact block efficiency for your node.

    minrelaytxfee=0.00001000
incrementalrelayfee=0.00001000

    If your organization produces end-user software, you may wish to ensure that it works with transactions and fee estimations set below the value of 1 satoshi per byte. Please contact Optech if you need more information about minimum relay fees.

  • ● Unrelayable transactions: At least two major services were identified as creating transactions with feerates below the current minimum due to a misunderstanding about the maximum size of a Bitcoin signature, which is 72 bytes. Bitcoin signatures vary in size, with half of all randomly-generated signatures being 72 bytes, slightly less than half being 71 bytes, and the small remainder being 70 bytes or smaller.

    At a guess, the developers of some software looked at a randomly-selected signature, saw that it was 71 bytes, and assumed all signatures would be 71 bytes. However, when the software generates a 72-byte signature, this makes the actual size of the transaction one byte larger per signature than the estimated size, causing the fees paid per byte to be slightly lower than expected.

    This didn’t cause significant problems when fee estimates were high, but now that fee estimates are near the default minimum relay fee of 1 satoshi per byte, any transactions created with a fee slightly below that may not be relayed to miners and so remain unconfirmed indefinitely.

    It is recommended that organizations check their software to ensure it, at the least, makes a worst-case assumption of signatures being 72 bytes.

  • ● Upcoming Bitcoin Core 0.17 feature freeze: next week developers plan to stop merging new features for the next major version of Bitcoin Core. The features already present will be further tested and documented, translations will be updated, and other parts of the release process followed. If your organization will be depending on a feature in the next six months, now could be your last chance to ensure it’s part of 0.17. Features currently not yet merged but likely to be added to Bitcoin Core 0.17.0 include:

    • scantxoutset RPC that allows searching the unspent transaction output set for addresses or scripts. Intended for use with address sweeping, e.g. finding funds that you own and bringing them into one of your current wallets.

    • ● BIP174 Partially Signed Bitcoin Transactions (PSBTs) support, a protocol for exchanging information about Bitcoin transactions between wallets to facilitate better interoperability between multisig wallets, hot/cold wallets, coinjoins, and other cooperating wallets.

    • ● Delayed transaction sending by network group, a proposal that is hoped will make it harder for spy nodes to determine which client first broadcast a transaction (indicating it may have been the spender).

  • ● Efficient reimplementation of Electrum Server: in an announcement to the bitcoin-dev mailing list this week was a claim that a Rust-based reimplementation of Electrum server is much more efficient than the Python version. Optech has not performed any testing on this and can’t confirm, but Electrum server is known to be used by several Bitcoin businesses both internally and hosted on behalf of their customers, so some readers of this newsletter may wish to investigate.

Building on Bitcoin

Building on Bitcoin was a Bitcoin technology conference that took place in Lisbon last week. It was well attended by both Bitcoin protocol developers and applications engineers. A video is available, as are several transcripts by Bitcoin developer Bryan Bishop (kanzure).

The following talks may be of particular interest to Bitcoin Optech companies:

  • ● Merchant adoption - Sergej Kotliar, CEO of Bitrefill gave a personal account of the fee market spike at the end of last year, important UX considerations for Bitcoin and Lightning payments, and Bitrefill’s experiences in integrating Lightning. This talk was fascinating due to the real-world empirical data that Sergej shared and his first-hand experience of fees, scaling, and Lightning.
  • ● Blind Signatures in Sciptless Scripts - Jonas Nick spoke about using Schnorr signatures as the basis of doing blind coinswaps (where a server cannot link coins) or exchanging ‘ecash tokens’ on Bitcoin or Lightning, among other things. This talk presents leading edge thinking about what’s possible with scriptless scripts and the ideas presented are quite a long way from being implementable on Bitcoin. However, it is interesting to see some of the new applications that will be unlocked by adopting Schnorr signatures into Bitcoin.
  • ● LN story - Fabrice Drouin presented a history of the development of the Lightning Network. A lot of interesting background for anyone planning to integrate and use Lightning payments.