{"id":15017,"date":"2021-08-19T22:00:00","date_gmt":"2021-08-19T22:00:00","guid":{"rendered":"http:\/\/ci028b147770002426"},"modified":"2025-10-01T15:31:07","modified_gmt":"2025-10-01T20:31:07","slug":"the-dust-limit-bitcoin","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/the-dust-limit-bitcoin","title":{"rendered":"Should The Bitcoin \u201cDust Limit\u201d Be Removed?"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>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&#8217;re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.<\/em><\/p>\n<p>This week\u2019s 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.<\/p>\n<h2>News<\/h2>\n<ul>\n<li>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 <a href=\"https:\/\/bitcoinops.org\/en\/topics\/uneconomical-outputs\/\" target=\"_blank\" rel=\"noopener\">dust limit<\/a> (the exact amount varies by output type). This makes it more difficult for users to create uneconomical outputs\u2014UTXOs that would cost more in fees to spend that they hold in value.<br \/>This week, Jeremy Rubin <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-August\/019307.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> 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 \u201cspam\u201d and \u201c<a href=\"https:\/\/bitcoinops.org\/en\/topics\/output-linking\/\" target=\"_blank\" rel=\"noopener\">dust fingerprint attacks<\/a>\u201d. Others <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-August\/019308.html\" target=\"_blank\" rel=\"noopener\">replied<\/a> with <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-August\/019310.html\" target=\"_blank\" rel=\"noopener\">counterarguments<\/a> 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 <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-August\/019327.html\" target=\"_blank\" rel=\"noopener\">described<\/a> the <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/bitcoin-dev\/2021-August\/019333.html\" target=\"_blank\" rel=\"noopener\">impact<\/a> of both the dust limit and uneconomical outputs on parts of LN.<br \/>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.<\/li>\n<\/ul>\n<h2>Changes to services and client software<\/h2>\n<p><em>In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.<\/em><\/p>\n<ul>\n<li>Spark Lightning Wallet adds BOLT12 support: The <a href=\"https:\/\/github.com\/shesek\/spark-wallet\/releases\/tag\/v0.3.0rc\" target=\"_blank\" rel=\"noopener\">v0.3.0rc release<\/a> of <a href=\"https:\/\/github.com\/shesek\/spark-wallet\" target=\"_blank\" rel=\"noopener\">Spark<\/a> adds partial support for BOLT12\u2019s <a href=\"https:\/\/bitcoinops.org\/en\/topics\/offers\/\" target=\"_blank\" rel=\"noopener\">offers<\/a>.<\/li>\n<li>Blockstream announces non-custodial LN cloud service, Greenlight: In a recent <a href=\"https:\/\/blockstream.com\/2021\/07\/21\/en-greenlight-by-blockstream-lightning-made-easy\/\" target=\"_blank\" rel=\"noopener\">blog post<\/a>, 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). <a href=\"https:\/\/sphinx.chat\/\" target=\"_blank\" rel=\"noopener\">Sphinx<\/a> and <a href=\"https:\/\/gl.striga.com\/\" target=\"_blank\" rel=\"noopener\">Lastbit<\/a>both currently use the Greenlight service.<\/li>\n<li>BitGo announces native segwit change outputs: Noting segwit\u2019s adoption crossing the 75% milestone, <a href=\"https:\/\/blog.bitgo.com\/native-segwit-change-outputs-for-bitcoin-c021406aaae2\" target=\"_blank\" rel=\"noopener\">BitGo\u2019s blog post<\/a> announces an update in their default change outputs shifting from P2SH-wrapped to <a href=\"https:\/\/bitcoinops.org\/en\/topics\/bech32\/\" target=\"_blank\" rel=\"noopener\">native segwit<\/a> outputs.<\/li>\n<li>Blockstream Green desktop 0.1.10 released: The <a href=\"https:\/\/github.com\/Blockstream\/green_qt\/releases\/tag\/release_0.1.10\" target=\"_blank\" rel=\"noopener\">0.1.10 version<\/a> adds segwit-by-default single-sig wallets and manual <a href=\"https:\/\/bitcoinops.org\/en\/topics\/coin-selection\/\" target=\"_blank\" rel=\"noopener\">coin selection<\/a> features.<\/li>\n<\/ul>\n<h2>Preparing for taproot #9: signature adaptors<\/h2>\n<p><em>A weekly <\/em><a href=\"https:\/\/bitcoinops.org\/en\/preparing-for-taproot\/\" target=\"_blank\" rel=\"noopener\"><em>series<\/em><\/a><em> about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.<\/em><\/p>\n<p>Imagine someone offers to donate 1,000 BTC to a particular charity if anyone can guess that person\u2019s 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.<\/p>\n<p>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\u2019s 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.<\/p>\n<p>Let\u2019s 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 <a href=\"https:\/\/bitcoinops.org\/en\/topics\/htlc\/\" target=\"_blank\" rel=\"noopener\">HTLC<\/a> 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\u2019s contract by giving them an incorrect hash.<\/p>\n<h3>Adaptor magic<\/h3>\n<p><a href=\"https:\/\/bitcoinops.org\/en\/topics\/adaptor-signatures\/\" target=\"_blank\" rel=\"noopener\">Signature adaptors<\/a>, also commonly called <em>adaptor signatures<\/em> and <em>one-time verifiably encrypted signatures<\/em>, are a solution to these problems\u2014and to many other problems actually faced today in production systems built on Bitcoin. Although usable with Bitcoin\u2019s existing ECDSA signature scheme, it\u2019s much easier to use adaptors privately and costlessly in combination with the <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0340.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP340<\/a>implementation of <a href=\"https:\/\/bitcoinops.org\/en\/topics\/schnorr-signatures\/\" target=\"_blank\" rel=\"noopener\">schnorr signatures<\/a> for taproot. Let\u2019s see how our example above changes if we use adaptors.<\/p>\n<p>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\u2014which they\u2019ll 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.<\/p>\n<p>BIP340 signature commitments use the nonce in two forms: a numeric representation (called a <em>scalar<\/em>), which normally only the signer knows, and as a <em>point<\/em> on the Elliptic Curve (EC), which is published to enable verification.<\/p>\n<p>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 <em>signature adaptor<\/em>.<\/p>\n<p>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.<\/p>\n<p>Like everyone else who received the donor\u2019s signature adaptor, Alice and Bob now have a copy of the EC point for the hidden number. Also like everyone else, they don\u2019t 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\u2019t 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\u2019s 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.<\/p>\n<p>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\u2019s adaptor into a valid signature.<\/p>\n<h3>Multisignature adaptors<\/h3>\n<p>The previous section shows individual users modifying how they create their signatures to produce signature adaptors. It\u2019s also possible for the parties to a <a href=\"https:\/\/bitcoinops.org\/en\/topics\/multisignature\/\" target=\"_blank\" rel=\"noopener\">multisignature<\/a> to use the same trick. That\u2019s extraordinarily useful, as many cases where signature adaptors will be used require the cooperation of two users.<\/p>\n<p>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\u2019s adaptor into her valid partial signature and then provide his partial signature to produce a full signature spending the money.<\/p>\n<p>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.<\/p>\n<p>In next week\u2019s <em>preparing for taproot<\/em> column, we\u2019ll explore one of the main ways we expect to see signature adaptors used: Point Time Locked Contracts (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/ptlc\/\" target=\"_blank\" rel=\"noopener\">PTLCs<\/a>), an upgrade for the venerable Hash Time Lock Contracts (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/htlc\/\" target=\"_blank\" rel=\"noopener\">HTLCs<\/a>) used extensively in LN, coinswaps, and a number of other protocols.<\/p>\n<h2>Releases and release candidates<\/h2>\n<p><em>New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/bitcoincore.org\/bin\/bitcoin-core-22.0\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Core 22.0rc2<\/a> 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 <a href=\"https:\/\/bitcoinops.org\/en\/topics\/anonymity-networks\/\" target=\"_blank\" rel=\"noopener\">I2P<\/a> connections, removal of support for <a href=\"https:\/\/bitcoinops.org\/en\/topics\/anonymity-networks\/\" target=\"_blank\" rel=\"noopener\">version 2 Tor<\/a> connections, and enhanced support for hardware wallets.<\/li>\n<li><a href=\"https:\/\/bitcoincore.org\/bin\/bitcoin-core-0.21.2\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Core 0.21.2rc1<\/a> is a release candidate for a maintenace version of Bitcoin Core. It contains several bug fixes and small improvements.<\/li>\n<\/ul>\n<h2>Notable code and documentation changes<\/h2>\n<p><em>Notable changes this week in <\/em><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Core<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/ElementsProject\/lightning\" target=\"_blank\" rel=\"noopener\"><em>C-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/ACINQ\/eclair\" target=\"_blank\" rel=\"noopener\"><em>Eclair<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/\" target=\"_blank\" rel=\"noopener\"><em>LND<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\" target=\"_blank\" rel=\"noopener\"><em>Rust-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\" target=\"_blank\" rel=\"noopener\"><em>libsecp256k1<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\" target=\"_blank\" rel=\"noopener\"><em>Hardware Wallet Interface (HWI)<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\" target=\"_blank\" rel=\"noopener\"><em>Rust Bitcoin<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/\" target=\"_blank\" rel=\"noopener\"><em>BTCPay Server<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin\/bips\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Improvement Proposals (BIPs)<\/em><\/a><em>, and <\/em><a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/\" target=\"_blank\" rel=\"noopener\"><em>Lightning BOLTs<\/em><\/a><em>.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/22642\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #22642<\/a> updates Bitcoin Core\u2019s release process for upcoming version 22.0 to concatenate the GPG signatures of everyone who <a href=\"https:\/\/bitcoinops.org\/en\/topics\/reproducible-builds\/\" target=\"_blank\" rel=\"noopener\">reproducibly built<\/a> the binaries into a single file which can be batch verified (<a href=\"https:\/\/gist.github.com\/harding\/78631dbcd65ff4a499e164c4e9dc85d4\" target=\"_blank\" rel=\"noopener\">example<\/a>). 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\u2019s lead maintainer signing the release binaries.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21800\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21800<\/a> 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 <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2018\/12\/04\/#fn:fn-cpfp-limits\" target=\"_blank\" rel=\"noopener\">limits<\/a>ensure 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.<br \/>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, <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21800\" target=\"_blank\" rel=\"noopener\">#21800<\/a> 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 <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/06\/02\/#bitcoin-core-20833\" target=\"_blank\" rel=\"noopener\">#20833<\/a>, and will eventually be exposed over the p2p network as part of <a href=\"https:\/\/bitcoinops.org\/en\/topics\/package-relay\/\" target=\"_blank\" rel=\"noopener\">package relay<\/a>.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21500\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21500<\/a> 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.<\/li>\n<li>Rust-Lightning #1009 adds a max_dust_htlc_exposure_msat channel configuration option which limits the total balance of pending \u201cdusty HTLCs\u201d whose amounts are below the <a href=\"https:\/\/bitcoinops.org\/en\/topics\/uneconomical-outputs\/\" target=\"_blank\" rel=\"noopener\">dust limit<\/a>.<br \/>This change is in preparation for a proposed option_dusty_htlcs_uncounted feature bit, which advertises that the node does not wish to count \u201cdusty HTLCs\u201d 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 \u201cdusty HTLCs\u201d are unclaimable onchain and would never affect the final transaction size.<br \/>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 \u201cdusty HTLCs\u201d as this balance would be lost as fees to miners in a force-close.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/08\/18\/\" target=\"_blank\" rel=\"noopener\">original post here.<\/a> <\/p>\n<p>Please <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">subscribe to the Bitcoin Optech newsletter<\/a> directly to receive this content straight to your inbox every month.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Should the \u201cdust limit,\u201d which denies Bitcoin transactions below a certain output value, be removed?<\/p>\n","protected":false},"author":3246,"featured_media":15018,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[2887,2254],"class_list":["post-15017","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technical","tag-bitcoin-optech","tag-technical"],"author_data":{"id":3246,"name":"Bitcoin Optech","nicename":"bitcoin-optech","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/optech-notext-96x96.png"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/img_6289.png","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/15017","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/3246"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=15017"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/15017\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/15018"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=15017"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=15017"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=15017"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}