Delivery-date: Thu, 13 Mar 2025 20:33:31 -0700 Received: from mail-yb1-f189.google.com ([209.85.219.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tsvnd-0003ge-Vt for bitcoindev@gnusha.org; Thu, 13 Mar 2025 20:33:31 -0700 Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e582bfcada6sf2917868276.1 for ; Thu, 13 Mar 2025 20:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1741923204; x=1742528004; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=DYgZCPsa0glvWARJH+pfbMMs+AJ3+XfL5H5kBmyXwJM=; b=iT8YVLu+ExuAkL9K+Fc3zVanSoWsRjgTKvfDMgoFkE/UAmh6iM2RsjDLaPsDCEuDEy MKo4CIU8k/prM0K9c0tL29bZK7dlLYl2zpN4croAd+NjxsgALLBDJYtbGpi2Bpqzm/65 ahFuaZjUFmhn+hhyMvC98B7ke2DtxDvRksDqIHvbyjQI2g0+QJ4Je8F8oA/5TSsrrSqb yGSIlVzHnxjhTZASBGf96K43vIdbCFuiyC3kWmXYBMy2N02gcd5pLLXct7OKqEfJ0Kqz /W/OVazNJabBIBA1L79hBW9CH+UdgMq8vttHnh4andrNZ2AhIzmmT39rsQZWUdD+mwl3 00Xg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741923204; x=1742528004; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=DYgZCPsa0glvWARJH+pfbMMs+AJ3+XfL5H5kBmyXwJM=; b=hMtdYXLGH0FR781i7KbwQi4F5Ppr8CgQKF7ifcgacXsra+l5j/Y3JjNaY9tuGEBvCj dDS6TX0Ee3TzBZiObpMI7bSl9nmiYgrYswbmKnE755wDsn54KK9ZuShqB0UW/FZpABVP 0NaxY4B3UmGGejEmMxp/nFcd9m+9zAIFoCf5JXlU3/dg76fXoN2Bbnsz6lwsMmi0z1UB /UPZA4yT4ijfCa+l7PuDcocHIBiBrVFYQGB5xuUAL85xp42c00Fkqw720t0Dg03ADHEw +DAozFShV9jJe0qalCqSMAt8o8l1FrigXVJT+0f9qMLzgzdgq5AIcQywzxVAvWL4aqr8 edEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741923204; x=1742528004; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=DYgZCPsa0glvWARJH+pfbMMs+AJ3+XfL5H5kBmyXwJM=; b=AY7n8g/0jdhc2jcedJquz1pLgGgAkMemkAdGh+vdOaWajlvwCJT1oIYk79u3Swmd6e by+ML8B6yKE23YBRO4+2akdiCqjUDjAMm6XPByieeE79V2gvIplN+6PuV0KlSq2TFe2V 3MIagR0eDbCgIrDnQuqqvw96XTOueVdpnfB/VjlmV1RmJ+aYuujIWKUiVQTQA4DCo9h3 B2dKXxZgQa3o+yzGbJX652WB/es93QUB09OrycbUMAm+LVcLZb4OeyZM9orrovS/tced QnKd6M9OXmgTF0VStDQrs4ifkTXLR0QGh3yALE+6Y1P5GzSJlvsh36BDNpKNesoNkpoL WbZA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV/S7g3vefZyNEjKyY/HP3+5hQk7kqgSdb1ke2kK7lGIEZ6eQzv/WluAv35Lezn5gUzpaW7YwYMfSx7@gnusha.org X-Gm-Message-State: AOJu0YxAx9hPcHd75j1U31VaOHy60OKVUnh8/wSORkOdB3ALEHLjmzXX ZUE0s4KnGmYilALJBEWPwqMlXTYhUjkwKYv6lMsLMaXtH0SikyvK X-Google-Smtp-Source: AGHT+IEdFyTinj8F9k7gGNjqQbxXZCqWgJRnTd59u50ZHZArn0lk0hHqDirqBTDzgty/Tkp6jgdVVQ== X-Received: by 2002:a05:6902:228c:b0:e54:9cb1:21a6 with SMTP id 3f1490d57ef6-e63f64f8162mr1157387276.11.1741923203990; Thu, 13 Mar 2025 20:33:23 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAK2yqu5qy2byqWt/Kkrl3z+SGCWQKhU3DmuEuHa1dxyGw== Received: by 2002:a25:7ac2:0:b0:e5b:423e:3be6 with SMTP id 3f1490d57ef6-e63dc2c8a09ls1734545276.1.-pod-prod-08-us; Thu, 13 Mar 2025 20:33:20 -0700 (PDT) X-Received: by 2002:a05:6902:1501:b0:e63:3e41:6579 with SMTP id 3f1490d57ef6-e63f65ee09emr1106231276.47.1741923200528; Thu, 13 Mar 2025 20:33:20 -0700 (PDT) Received: by 2002:a05:690c:288a:b0:6fb:b341:b6f6 with SMTP id 00721157ae682-6ff19b1c6f6ms7b3; Thu, 13 Mar 2025 05:56:00 -0700 (PDT) X-Received: by 2002:a05:690c:3003:b0:6fe:c021:f745 with SMTP id 00721157ae682-6fec021f9c3mr264665857b3.4.1741870559405; Thu, 13 Mar 2025 05:55:59 -0700 (PDT) Date: Thu, 13 Mar 2025 05:55:58 -0700 (PDT) From: Garlo Nicon To: Bitcoin Development Mailing List Message-Id: <526eb6e1-ace2-47e9-9259-e2ec74b749b6n@googlegroups.com> In-Reply-To: References: <62b454f8-56be-4eae-ba3e-57c53d493f3dn@googlegroups.com> Subject: Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_129772_267449275.1741870558887" X-Original-Sender: garlonicon@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_129772_267449275.1741870558887 Content-Type: multipart/alternative; boundary="----=_Part_129773_1417507890.1741870558887" ------=_Part_129773_1417507890.1741870558887 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wonder, why OP used so much of AI-generated content to make these posts. > What if miners claim authorized dust UTXOs through entirely separate,=20 regular, standard-format transactions? They can do that today, no changes are needed. Just sign any dust with=20 SIGHASH_NONE | SIGHASH_ANYONECANPAY, or even use SIGHASH_SINGLE bug, to=20 spend all coins from the same public key, with the same signature. > What if miners are permitted to spend dust UTXOs without their original= =20 conditions only under strictly defined new rules Then it is still a hard-fork. But your AI model probably cannot understand= =20 it. niedziela, 9 marca 2025 o 02:43:29 UTC+1 Nighttime Satoshi napisa=C5=82(a): > Hi Pieter, > > You're absolutely right. You've raised valid technical concerns about my= =20 > original proposal regarding coinbase limitations and soft fork=20 > requirements. Based on your points, I've reconsidered the implementation= =20 > approach to ensure it works as a proper soft fork. Here's the revised=20 > mechanism. I'm curious to hear your thoughts: > > The basic premise is that dust UTXOs are a deadweight loss to the Bitcoin= =20 > Network - and we must find a solution at the L1 level that can "revive"= =20 > these dust satoshis back into the network at their full value, in order t= o=20 > improve Bitcoin's fungibility. This dust problem will only get more=20 > significant, and I don't think the deflationary effect of lost satoshis i= s=20 > more valuable than the prospect of full fungibility. L2 solutions are a= =20 > bandaid.=20 > > *Amendments*: > > > *1. Coinbase Transaction Inputs:* > *Concern*: Coinbase transactions can only have exactly one input.=20 > Allowing coinbase transactions to spend additional outputs would require = a=20 > hard fork. > > *Revised Solution:* What if miners claim authorized dust UTXOs through=20 > entirely separate, regular, standard-format transactions? Though not=20 > economically feasible for single transactions, it becomes extremely=20 > beneficial economically when batching multiple dust UTXOs simultaneously,= =20 > significantly amortizing transaction overhead across many claims. Coinbas= e=20 > transactions remain exactly as they are today, retaining their single-inp= ut=20 > rule and current consensus constraints. > > *2. Spending Dust Outputs Without Original Conditions* > > *Concern: *The dust outputs marked for claiming by miners can't currently= =20 > be spent without fulfilling their original conditions, which would requir= e=20 > a hard fork to change. > > *Revised Solution:* What if miners are permitted to spend dust UTXOs=20 > without their original conditions *only under strictly defined new rules:= * > > ** *The dust UTXO must be explicitly authorized for miner spending=20 > through an OP_RETURN-based "Dust Fee Authorization" (DFA) transaction. > > *The miner=E2=80=99s transaction claiming this dust must occur in the exa= ct same=20 > block as the DFA transaction. > > *Only dust UTXOs below a clearly defined threshold (546 sats) are eligibl= e. > > These new consensus rules *strictly restrict* previously impossible=20 > spending conditions, making it unequivocally a valid soft fork. No=20 > previously illegal behavior is permitted without new restrictive conditio= ns=20 > explicitly met. > > > *3. Economic and Practical Viability* > > *Concern: *The economic overhead (OP_RETURN transaction plus coinbase=20 > input overhead) might be larger than simply spending the dust normally. > > *Revised Solution:* With coinbase inputs no longer altered, the overhead= =20 > is significantly reduced. Furthermore, the revised mechanism explicitly= =20 > encourages batching multiple dust authorizations into a single DFA=20 > transaction, dramatically amortizing overhead costs across many dust UTXO= s.=20 > This batching substantially improves economic viability, especially durin= g=20 > periods of lower mempool congestion where fees are minimal. > > Does this design address your concerns while preserving the original goal= =20 > of voluntary, secure, and economically rational reclamation of dust UTXOs= ? > > Your insights have been invaluable. I'm eager to receive any further=20 > feedback on this revised design. > > Thank you again for your careful review and helpful critique. > > Best regards, > > On Sat, Mar 8, 2025 at 5:49=E2=80=AFPM Pieter Wuille wrote: > >> Hello, >> >> This is not a soft fork, for two reasons: >> >> * Coinbase transactions can only have exactly one input. I don't think= =20 >> there is a particularly good reason for this besides simplicity, but tha= t=20 >> is the current rule. Allowing a coinbase transaction to additionally als= o=20 >> spend certain outputs would require a hardfork. >> >> * The outputs being marked as dust are not allowed to be spent by miners= .=20 >> Changing this requires a hardfork as well. Think about it: if this was= =20 >> possible with a softfork, it must mean that doing what you're proposing= =20 >> would *already be legal* today, and thus not need this proposed change i= n=20 >> the first place. Softforks can only outlaw formerly legal behavior. >> >> Furthermore, I don't really see the point. The proposal requires both a= =20 >> coinbase txin to spend the coin, plus a signature in a separate=20 >> transaction, in the same block. To pay the miner for the opportunity cos= t=20 >> of not including normal transactions with these bytes, the fee for this= =20 >> OP_RETURN output should economically be priced at the block's feerate fo= r=20 >> the size of the OP_RETURN output *plus* the cost of the coinbase=20 >> transaction input. Together, they are no smaller (and with witness=20 >> discount, I suspect larger) than the user just spending their "dust"=20 >> output, and thus the fee for using this OP_RETURN-based mechanism would = be=20 >> larger than the value of the dust output. >> >> --=20 >> Pieter >> >> On Saturday, March 8th, 2025 at 1:23 PM, Nighttime Satoshi < >> nighttim...@gmail.com> wrote: >> >> > Dear fellow Bitcoin developers, >> >=20 >> > I'm excited to share a proposal addressing a long-standing Bitcoin=20 >> challenge: economically unviable dust UTXOs. >> >> --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 526eb6e1-ace2-47e9-9259-e2ec74b749b6n%40googlegroups.com. ------=_Part_129773_1417507890.1741870558887 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wonder, why OP used so much of AI-generated content to make these posts.<= br />
> What if miners claim authorized dust UTXOs through entirely= separate, regular, standard-format transactions?

They can do th= at today, no changes are needed. Just sign any dust with SIGHASH_NONE | SIG= HASH_ANYONECANPAY, or even use SIGHASH_SINGLE bug, to spend all coins from = the same public key, with the same signature.

> What if miner= s are permitted to spend dust UTXOs without their original conditions only = under strictly defined new rules

Then it is still a hard-fork. B= ut your AI model probably cannot understand it.

niedziela, 9 marca 2025 o= =C2=A002:43:29 UTC+1 Nighttime Satoshi napisa=C5=82(a):
Hi Pieter,
=
You're absolutely right. You've raised valid technic= al concerns about my original proposal regarding coinbase limitations and s= oft fork requirements. Based on your points, I've reconsidered the impl= ementation approach to ensure it works as a proper soft fork. Here's th= e revised mechanism. I'm curious to hear your thoughts:

<= /div>
The basic premise is that dust UTXOs are a deadweight loss to the= Bitcoin Network - and we must find a solution at the L1 level that can &qu= ot;revive" these dust satoshis back into the network at their full val= ue, in order to improve Bitcoin's fungibility. This dust problem will o= nly get more significant, and I don't think the deflationary effect of = lost satoshis is more valuable than the prospect of full fungibility. L2 so= lutions are a bandaid.=C2=A0

Amendments:

1. Coinbase Transaction Inputs:

C= oncern:=C2=A0Coinbase transacti= ons can only have exactly one input. Allowing coinbase transactions to spen= d additional outputs would require a hard fork.

Revised Solution:=C2=A0What if miners claim authorized dust UTXOs through entirely separate, reg= ular, standard-format transactions? Though not economically=C2=A0feasible f= or single transactions, it becomes extremely beneficial economically when b= atching multiple dust UTXOs simultaneously, significantly amortizing transa= ction overhead across many claims. Coinbase transactions remain exactly as = they are today, retaining their single-input rule and current consensus con= straints.

2. Spending Dust Outputs With= out Original Conditions

Concer= n:=C2=A0The dust outputs marked for claiming by miners can't c= urrently be spent without fulfilling their original conditions, which would= require a hard fork to change.

Re= vised Solution:=C2=A0What if miners are permitted to = spend dust UTXOs without their original conditions=C2=A0only under strictly defined new rules:

*=C2=A0The dust UTXO must be explicitly authorized for miner= spending through an OP_RETURN-based "Dust Fee Authorization" (DF= A) transaction.

*The miner=E2=80=99s trans= action claiming this dust must occur in the exact same block as the DFA tra= nsaction.

*Only dust UTXOs below a clearly= defined threshold (546 sats) are eligible.

These new consensus rules=C2=A0strictly restrict=C2=A0previously impossible spending conditions, making i= t unequivocally a valid soft fork. No previously illegal behavior is permit= ted without new restrictive conditions explicitly met.

3. Economic and Practical Viability

Concern:=C2=A0The economic overhead (OP_= RETURN transaction plus coinbase input overhead) might be larger than simpl= y spending the dust normally.

Revi= sed Solution:=C2=A0With coinbase inputs no longer alt= ered, the overhead is significantly reduced. Furthermore, the revised mecha= nism explicitly encourages batching multiple dust authorizations into a sin= gle DFA transaction, dramatically amortizing overhead costs across many dus= t UTXOs. This batching substantially improves economic viability, especiall= y during periods of lower mempool congestion where fees are minimal.

Does this design=C2=A0address your concerns whil= e preserving the original goal of voluntary, secure, and economically ratio= nal reclamation of dust UTXOs?

Your in= sights have been invaluable. I'm eager to receive any further feedback = on this revised design.

Thank you again fo= r your careful review and helpful critique.

Best regards,


On Sat, Mar 8, 2025 at 5:49=E2=80=AFPM Pieter Wuil= le <bitco...@wuille.net&g= t; wrote:
Hello,

This is not a soft fork, for two reasons:

* Coinbase transactions can only have exactly one input. I don't think = there is a particularly good reason for this besides simplicity, but that i= s the current rule. Allowing a coinbase transaction to additionally also sp= end certain outputs would require a hardfork.

* The outputs being marked as dust are not allowed to be spent by miners. C= hanging this requires a hardfork as well. Think about it: if this was possi= ble with a softfork, it must mean that doing what you're proposing woul= d *already be legal* today, and thus not need this proposed change in the f= irst place. Softforks can only outlaw formerly legal behavior.

Furthermore, I don't really see the point. The proposal requires both a= coinbase txin to spend the coin, plus a signature in a separate transactio= n, in the same block. To pay the miner for the opportunity cost of not incl= uding normal transactions with these bytes, the fee for this OP_RETURN outp= ut should economically be priced at the block's feerate for the size of= the OP_RETURN output *plus* the cost of the coinbase transaction input. To= gether, they are no smaller (and with witness discount, I suspect larger) t= han the user just spending their "dust" output, and thus the fee = for using this OP_RETURN-based mechanism would be larger than the value of = the dust output.

--
Pieter

On Saturday, March 8th, 2025 at 1:23 PM, Nighttime Satoshi <nighttim...@gmail.com> wrote:

> Dear fellow Bitcoin developers,
>
> I'm excited to share a proposal addressing a long-standing Bitcoin= challenge: economically unviable dust UTXOs.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/526eb6e1-ace2-47e9-9259-e2ec74b749b6n%40googlegroups.com.
------=_Part_129773_1417507890.1741870558887-- ------=_Part_129772_267449275.1741870558887--