What are Bitcoin developers busy with a week before the halving? Quick look!

Written in front:

There are less than 5 days left until the third halving in Bitcoin’s history. So what are Bitcoin developers busy with during this period?

In this week’s Bitcoin Technical Weekly, developers look at how to use enhanced QR codes to complete large Bitcoin transactions, followed by a report on building high-availability Lightning Network (LN) nodes, followed by technical topics such as the Simplicity programming language, and finally, the regular section, including major updates to popular Bitcoin infrastructure such as C-Lightning, LND, Bitcoin Core, and BIP.

Before we get into this week’s official content, let’s celebrate a little bit!

QR codes for large Bitcoin transactions

A QR code can actually contain about 3 kilobytes of data, which is enough to accommodate transactions for average users, but it is not enough for those large transactions.

In response, Riccardo Casatta and Christopher Allen have each posted a thread on the Bitcoin developer mailing list (1, 2) in the hopes of standardizing a method for visually communicating partially signed Bitcoin transactions (PSBTs) and other potentially large blocks of data associated with Bitcoin wallet interactions. See previous discussions in the Spectre DIY repository, and continued discussions in the Airgapped Signing repository.

Running a Lightning Network Node in an Enterprise Environment

Author: Roman Taranchenko (Suredbits Engineer)

From the excitement you feel when you send a Lightning Network payment for the first time, to the excitement that fades away after receiving a payment through the Lightning Network, it is always desirable to think about how to operate your node in a safe and reliable manner. But failures almost always happen unexpectedly. How do you recover after a possible failure? How do you back up reliably? How do you keep your seeds in a safe place? Questions like these are what we want to solve.

At Suredbits, we use the Eclair client to run LN nodes. Although Eclair itself is very robust, we have taken some steps to make it more reliable, such as using PostgreSQL as the database backend and AWS Secrets Manager to store private keys.

Eclair has a built-in online backup feature, but it requires manual setup and scripting to automate, which is not really scalable and can be error-prone. Running PostgreSQL on AWS RDS allows us to automate backups and replication in a way that many DevOps engineers are familiar with, which makes it easier to restore database states.

Using PostgreSQL as the remote database backend makes node failover easier to implement, because if a node crashes for some reason, you don’t need to restore the database from a backup, you can just point the new Eclair client to the correct database server. Here’s a quick demo of automatic failover, implemented with two Eclair instances and AWS’s RDS, ELB, and NAT Gateway.

In the failover scenario described in the demo, we need a secure way to allow the node's private key seeds to be shared between Eclair instances. Eclair stores the seeds in a file on the local file system, which should be backed up somewhere and restored when needed. The current Eclair implementation requires additional steps to be automated. Instead, we use the AWS Secrets Manager storage tool, which is specifically designed to securely store various secrets (including database passwords and encryption keys). Now, to share seeds between instances, just point them to the correct secret location in the configuration file. Once configured, the instance can be stored as an AMI image and can be re-imaged as many times as needed without manual configuration.

The steps we have taken above are just the first steps towards building an enterprise-grade Lightning Network node. There are still more problems to be solved. For example, which hardware security modules (HSM) can be used for Lightning Network nodes, or how to failover Bitcoin Core nodes in a multi-instance setup. But we believe that our work is a solid foundation for extending Eclair and making it more fault-tolerant.

For more information on this topic, see our presentation.

Disclaimer: Since private keys are involved, please do not use third-party cloud services without a thorough risk assessment.

Bitcoin developers’ focus

Bitcoin Transcripts is a record of technical presentations and discussions about Bitcoin. In this weekly report, we will select some of the discussions that developers have paid close attention to in the past month.

1. Simplicity: The next generation of Bitcoin smart contract programming language

Adam Back presented Simplicity, a next-generation replacement for the Bitcoin Script scripting language that focuses on provable security and expressiveness, in a Blockstream webinar. Adam Back discussed how developers could implement new features like SIGHASH_NOINPUT without a soft fork, assuming Simplicity could be applied to Bitcoin. He also showed a demo of what we can do with Simplicity today. (Text, video, slides)

2. Attacking Bitcoin Core

Amiti Uttarwar presented Evolution at LA BitDevs, discussing how to evaluate changes to Bitcoin's p2p layer based on five goals: reliability, timeliness, accessibility, privacy, and upgradeability. She discussed the dangers of network partitions and eclipse attacks, then explained why (block-relay-only) block relay connections and anchor nodes are effective mitigation measures. (Text, video)

3. LND v0.10

Laolu Osuntokun, Joost Jager, and Oliver Gugger discussed LND v0.10 at the Reckless VR event. Osuntokun covered Tor and RPC enhancements in the recently released LND client, as well as a new channel feature called anchor outputs that addresses the challenge of estimating on-chain fees months in advance. Jager discussed the challenges of multipart payments, including the splitting algorithm, what happens when payment shards arrive at different times, and strategies for handling multipart payment failures. Finally, Gugger discussed partially signed Bitcoin transaction (PSBT) channels and the channel abstraction work that makes them possible. (Text, video)

4. Grokking Bitcoin

Kalle Rosenbaum attended a Bitcoin developer meetup and gave a speech at the London Bitcoin Developer Conference. The meetup discussion focused on Bitcoin technical education, BIP32 HD wallets, and the role of soft fork upgrades. In the speech, Rosenbaum discussed how the 2017 Segregated Witness (segwit) upgrade solved transaction malleability and quadratic hashing issues.

Major Bitcoin Infrastructure Updates

1. C-Lightning 0.8.2 is now officially released, which adds support for opening channels of any size (using the --large channels configuration parameter), provides a keysend plugin for receiving spontaneous payments, and includes other new features and bug fixes. For a complete list of updates to the client, read its new FAQ;

2. LND 0.10.0-beta adds support for sending multi-path payments, using funding channels from external wallets via PSBT, the ability to create invoices greater than 0.043 BTC, and other new features and bug fixes, and users can read the new operational security documentation.

3. Bitcoin Core 0.20.0rc1 is a release candidate for the next major version of Bitcoin Core.

Notable code and documentation changes:

Note: The Bitcoin Core commit changes mentioned below apply to its main development branch, so these changes may not be included until the 0.21 version, which is about 6 months after the upcoming 0.20 release.

1. Bitcoin Core #16528 allows createwallet RPC to create a wallet that uses output script descriptors to export specific scriptPubKeys that the wallet uses to receive payments. This is a major improvement over the old wallet scanning payment method, which derives each type of script handled by the wallet for each public key in the wallet. Descriptor wallets should be more efficient (because they do not need to scan unused script types), easier to upgrade to new script types (such as taproot), and easier to use external tools (such as multi-signature wallets, or HWI-compatible hardware wallets through PSBT).

By default, descriptor wallets use the popular BIP32 HD wallet paths specified by BIP 44, BIP 49, and BIP 84, instead of the non-standardized paths used in the legacy Bitcoin Core HD wallet. Many wallet RPCs don't work with descriptor wallets, either because they don't conform to the descriptor or because developers are still tweaking them to accommodate new edge cases. It's still early days for this PR to be merged in the 0.21 client, and the developers have decided to make descriptor wallets a non-default option.

2. Bitcoin Core#18038 improves privacy when initially broadcasting transactions by reducing the frequency with which wallets attempt to resend from about 30 minutes to about once a day. Previously, entities monitoring the network could see multiple broadcasts of the same transaction from the same node during these resends and conclude which wallet the initiator used. By reducing the frequency of resend attempts, the probability of the initiator of the transaction being identified is reduced.

In order to ensure that new transactions can reach the network even without frequent rebroadcasts from the wallet, this PR also adds a type of non-broadcast transaction to the storage pool mempool. Non-broadcast transactions are transactions that have been submitted locally through a wallet or RPC, but have not yet been successfully relayed to peer nodes on the network. Such unbroadcasted transactions remain in the storage pool and will be rebroadcast every 10-15 minutes until the peer obtains the transaction by sending a getdata P2P message for the transaction to the node.

3. BIP#893 makes several changes to the BIP340 specification for schnorr public keys and signatures, and also makes related changes to the BIP341 specification for taproot.

4. BIP#903 simplifies the previously proposed BIP322 specification for general signature messages (see Weekly Report No. 91). The change mainly removes the details that allow multiple scripts (addresses) to sign the same message in the same proof.

5. BIP#900 updates the signet specification of BIP325 so that all signets use the same hard-coded genesis block (block 0), but independent signets can be distinguished by their network magic (message start byte).