The Dust Limit Bitcoin – Bitcoin Magazine: Bitcoin News, Articles, Charts, and Guides

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.

Source