Should The Bitcoin “Dust Limit” Be Removed - BTC Ethereum Crypto Currency Blog

Should the “dust limit,” which denies Bitcoin transactions below a certain output value, be removed?

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 summarizes a discussion about the dust limit and includes our regular sections with descriptions of changes to services and client software, how you can prepare for taproot, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

Dust limit discussion: Bitcoin Core and other node software refuses by default to relay or mine any transaction with an output value below a certain amount, the dust limit (the exact amount varies by output type). This makes it more difficult for users to create uneconomical outputs—UTXOs that would cost more in fees to spend that they hold in value.
This week, Jeremy Rubin posted to the Bitcoin-Dev mailing list a five-point argument for removing the dust limit and stated a belief that the reason for the limit is to prevent “spam” and “dust fingerprint attacks”. Others replied with counterarguments and noted that the limit exists not to prevent spam but to prevent users from permanently wasting the resources of full node operators by creating UTXOs that the users will have no financial incentive to ever spend. Parts of the discussion also described the impact of both the dust limit and uneconomical outputs on parts of LN.
As of this writing, it did not appear any agreement was likely to be reached. At least for the short term, we expect the dust limit to remain.

Changes to services and client software

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

Spark Lightning Wallet adds BOLT12 support: The v0.3.0rc release of Spark adds partial support for BOLT12’s offers.
Blockstream announces non-custodial LN cloud service, Greenlight: In a recent blog post, Blockstream details their hosted C-Lightning-nodes-in-the-cloud service that separates node operation (Blockstream) from the control of the funds held by the node (user). Sphinx and Lastbitboth currently use the Greenlight service.
BitGo announces native segwit change outputs: Noting segwit’s adoption crossing the 75% milestone, BitGo’s blog post announces an update in their default change outputs shifting from P2SH-wrapped to native segwit outputs.
Blockstream Green desktop 0.1.10 released: The 0.1.10 version adds segwit-by-default single-sig wallets and manual coin selection features.

Preparing for taproot #9: signature adaptors

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

Imagine someone offers to donate 1,000 BTC to a particular charity if anyone can guess that person’s favorite very large number. An easy way for the donor to do this is to create an unsigned transaction paying the 1,000 BTC and then publish an encrypted copy of their signature for the transaction, with the favorite number being the decryption key.

In theory, anyone who guesses the number can decrypt the signature and then broadcast the transaction, paying the charity. But if the donor uses a standard encryption scheme like AES, there’s no easy way for third parties to know before decryption that the signature is actually valid for that transaction. Anyone who wants to put effort into number guessing has to trust that the donor is sincere and not a troll.

Let’s extend this problem a bit further. Third parties Alice and Bob want to bet on whether or not the signature is revealed. They could perhaps ask the signer for the hash of the signature and use that as the hash in an HTLC function, but that again requires trusting the donor to act honestly. Even if the signature was eventually revealed, the donor could sabotage Alice and Bob’s contract by giving them an incorrect hash.

Adaptor magic

Signature adaptors, also commonly called adaptor signatures and one-time verifiably encrypted signatures, are a solution to these problems—and to many other problems actually faced today in production systems built on Bitcoin. Although usable with Bitcoin’s existing ECDSA signature scheme, it’s much easier to use adaptors privately and costlessly in combination with the BIP340implementation of schnorr signatures for taproot. Let’s see how our example above changes if we use adaptors.

As before, the donor prepares a 1,000 BTC transaction. They sign in almost the normal way, with the one difference being that they essentially generate their nonce in two parts: a true random nonce that they will forever keep secret, and their favorite number—which they’ll initially keep secret but which is safe for other people to discover. The donor generates a fully valid signature using both of these values, adding them together as if they were a single nonce.

BIP340 signature commitments use the nonce in two forms: a numeric representation (called a scalar), which normally only the signer knows, and as a point on the Elliptic Curve (EC), which is published to enable verification.

The donor takes the commitment part of their valid signature and subtracts out the hidden scalar. This makes the signature incomplete (and thus invalid) but allows the donor to share the (invalid) signature commitment, the (valid) point for the complete nonce, and the (valid) point for the hidden number. Together these three pieces of information are a signature adaptor.

Using a slight variant on the BIP340 signature verification algorithm, anyone can verify that the signature adaptor would provide a valid signature if the hidden scalar was simply added back in to the (currently invalid) signature commitment. This is possible to verify even without knowing what that hidden number is. In short, it is now possible for users to trustlessly begin making guesses about the value of hidden scalar, secure in the knowledge that a correct guess will allow them to get the signature and send the transaction.

Like everyone else who received the donor’s signature adaptor, Alice and Bob now have a copy of the EC point for the hidden number. Also like everyone else, they don’t know the actual scalar. But, if you recall, all the donor did to turn their valid signature into an invalid signature is subtract out the hidden number from their signature commitment while continuing to have the signature commit to the point of the hidden number. Alice can just as easily create an invalid signature by not committing to the scalar she doesn’t know but still committing to the EC point she does know. She does this by creating her own nonce pair, using the private form when creating her (invalid) signature but commiting to the aggregation of the public form of her nonce and the EC point from the donor’s signature adaptor. This produces a signature adaptor for a transaction that pays Bob. If Bob learns the scalar, he can convert that adaptor into a valid signature and send the transaction, winning the bet.

But how does Bob learn the winning number? Does he have to wait for someone else who guesses it to publish a press release? Nope. Recall one more time that the signature adaptor the donor published was their actual signature minus the scalar. When the hidden number is discovered and somebody sends the 1,000 BTC transaction, they must publish the original (valid) signature commitment. Bob can take that (valid) signature commitment and subtract from it the (invalid) signature commitment in the original signature adaptor to get the scalar. He then uses that scalar to convert Alice’s adaptor into a valid signature.

Multisignature adaptors

The previous section shows individual users modifying how they create their signatures to produce signature adaptors. It’s also possible for the parties to a multisignature to use the same trick. That’s extraordinarily useful, as many cases where signature adaptors will be used require the cooperation of two users.

For example, when Alice and Bob make the bet above, they might start by depositing funds into a script only spendable by a multisignature between them. Then Alice can produce her partial signature in the form of a signature adaptor; if Bob learns the hidden number, he can transform Alice’s adaptor into her valid partial signature and then provide his partial signature to produce a full signature spending the money.

This gives signature adaptors all the same advantages of multisignatures in general: they look like and use the same amount of space as a single signature, minimizing fees and maximizing privacy and fungibility.

In next week’s preparing for taproot column, we’ll explore one of the main ways we expect to see signature adaptors used: Point Time Locked Contracts (PTLCs), an upgrade for the venerable Hash Time Lock Contracts (HTLCs) used extensively in LN, coinswaps, and a number of other protocols.

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.

Bitcoin Core 22.0rc2 is a release candidate for the next major version of this full node implementation and its associated wallet and other software. Major changes in this new version include support for I2P connections, removal of support for version 2 Tor connections, and enhanced support for hardware wallets.
Bitcoin Core 0.21.2rc1 is a release candidate for a maintenace version of Bitcoin Core. It contains several bug fixes and small 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 #22642 updates Bitcoin Core’s release process for upcoming version 22.0 to concatenate the GPG signatures of everyone who reproducibly built the binaries into a single file which can be batch verified (example). Signatures from deterministic builders have been available for years, but this should make them more accessible and also reduce the existing dependency on the project’s lead maintainer signing the release binaries.
Bitcoin Core #21800 implements ancestor and descendant limits for mempool package acceptance. Bitcoin Core limits the number of related transactions in its mempool as a protection against DoS attacks and so that block construction is tractable for miners. By default, those limitsensure that no transaction in the mempool, combined with its mempool ancestors, can exceed 25 transactions or 101KvB in weight. The same rules apply to the transaction combined with its mempool descendants.
Those ancestor and descendant limits are enforced when a transaction is considered for addition to the mempool. If adding the transaction would cause one of the limits to be exceeded, then the transaction is rejected. Although package semantics have not been finalized, #21800 implements ancestor and descendant limit checks for validating arbitrary packages (i.e. when multiple transactions are considered for addition to the mempool at the same time). Mempool package acceptance was implemented for testing only in #20833, and will eventually be exposed over the p2p network as part of package relay.
Bitcoin Core #21500 updates the listdescriptors RPC with a private parameter that, when set, will return the private form of each descriptor. The private form contains any known private keys or extended private keys (xprvs), allowing this updated command to be used to backup the wallet.
Rust-Lightning #1009 adds a max_dust_htlc_exposure_msat channel configuration option which limits the total balance of pending “dusty HTLCs” whose amounts are below the dust limit.
This change is in preparation for a proposed option_dusty_htlcs_uncounted feature bit, which advertises that the node does not wish to count “dusty HTLCs” against max_accepted_htlcs. Node operators would likely want to adopt this feature bit sincemax_accepted_htlcs is mainly used to limit the potential size of the onchain transaction if a force-close were to happen and “dusty HTLCs” are unclaimable onchain and would never affect the final transaction size.
The newly added max_dust_htlc_exposure_msat channel configuration option ensures that even when option_dusty_htlcs_uncounted is turned on, users can still limit the total balance of “dusty HTLCs” as this balance would be lost as fees to miners in a force-close.