path: root/e4/fef74a76c683088adb41351dcfe43568437d53

Delivery-date: Sat, 08 Mar 2025 15:31:34 -0800
Received: from mail-yw1-f183.google.com ([209.85.128.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCSLDOOA54LRBS5GWO7AMGQES4UYHOQ@googlegroups.com>)
	id 1tr3dl-0005oq-44
	for bitcoindev@gnusha.org; Sat, 08 Mar 2025 15:31:34 -0800
Received: by mail-yw1-f183.google.com with SMTP id 00721157ae682-6fd47cf3cb9sf30752417b3.1
        for <bitcoindev@gnusha.org>; Sat, 08 Mar 2025 15:31:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741476687; x=1742081487; 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=0BaxzOQsVSTfPjlS3bTfynawpFfBOFMpILf0nMn2/Uo=;
        b=BUXanWo8J9u7kGZessq6U+qnOQwevZA4cNXhBYhhW2jfLGqlYduwxcZrtHwyGW2uWR
         6WozAUb64xS6yCPlOXRx9ecNwPi/zmuJg3IKNkPvP/92svKhYIoTtOHI5z5pdJtIfPcm
         Z/gCnwA1Q2MkmvGEKos5bA+5zj2APFJCyfy2NPVDuLsG50+0KhgbQBwKaqmeBfUMOTXe
         gHrEoVCNJXlfyJlrD5ym4bxuxnD8sKIKUX9fn73YkzUwRa9T+Nhn0rZ9EMJeWtXD3sqr
         gZQlnPEPPnPzbFRF6eOiWCYBsHa9qQv8C9qairGyFcxIHoAbqlNMZMOInyp+bEQpSp3l
         cc+w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741476687; x=1742081487; 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=0BaxzOQsVSTfPjlS3bTfynawpFfBOFMpILf0nMn2/Uo=;
        b=ekl9iICldOwehgJa/ZpxqYuwQX4OwSN474fztb+JxaI3PwrYLByg/bKXmV/jbJdioT
         0/x1w3SaPgYqh9fbkRusF/TK0gLDUkcDQOH+Dt0/miKqK84gMsw0pGEx984EELL2eIUi
         SwUsRD+v0fuTmd1DtFoMfL9V9VYN16ehixjkkOG7F4D6kpIAWn+yKLkA/Dv9u84tHkMa
         YGijlvOPAgKfnUCvokGBfjbgtVKrmfZ/b1vwbvtbXR0P7S/hwQFOv8tmWUUSulquP73S
         eKBvBbWlNm6bPhfjTEanrHcT3BYpdLKSzlkR86r64dNf6tvG9CqN6pWIEJTLrZ0VfNjZ
         9v2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741476687; x=1742081487;
        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=0BaxzOQsVSTfPjlS3bTfynawpFfBOFMpILf0nMn2/Uo=;
        b=mArMLO2Uc7l80mCAt2mwANjGd8H6Bdgy81Xdw089riN50U427S3CABK8vbyL76nh2R
         mKTM8SFwWi162slrJDUaxuxZIGrEsHkT/Kra+7Y3zRcEqOeWWJJ8yvtx7sQqgxZPCiFP
         1hmO9a0kVQlViHYvroy+p2yluSkaKwtvgKhTUHWgq+0MAXdm961ZjpsFimSVo6S3Wmq8
         wn5d3Glu7gKIJjLZPCqNzEIWDXzDGQaIdVCcpCRmpjLUDMfVwANK9y/hd8KhRXpqaVYr
         qEI4SRUMwE/+dXAr0rCHLzBpZv4h0XUJTy2r4aSPqePnWwQLSc4o7/FLsvDvRTjEeCFR
         uSbw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVmtWJ6F8/xWA6deOsGg/4/NJakCAplQr/VnZbOOnhFUj1s9vYptIhCzXD4jQiBwia61mDFkDTaA1fC@gnusha.org
X-Gm-Message-State: AOJu0Yz3m2Sr2SuJMA2v5cbR63+Ss0uBieETPacLPcwdAWtMGfHb5EGX
	cpiT3pJFIxzYwwFkh0DZDb5NPOo5hY6GTTnsua2Xc4JiytUKp73F
X-Google-Smtp-Source: AGHT+IFvRG5bpj6l5r3Qo1/TBKlg9rjO8rinEr4vfxvEbP6DONdbmxe6FtAY+e0542yyGx+z7oiONw==
X-Received: by 2002:a05:690c:998e:b0:6f6:7b02:2565 with SMTP id 00721157ae682-6febf3a7e1fmr126299487b3.26.1741476687194;
        Sat, 08 Mar 2025 15:31:27 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGnnvuwEgkevnMpuj8X9EFV185Uw2xZPFA8P3W7tPSxNg==
Received: by 2002:a25:df45:0:b0:e61:b422:146b with SMTP id 3f1490d57ef6-e6348a0607als161310276.2.-pod-prod-01-us;
 Sat, 08 Mar 2025 15:31:22 -0800 (PST)
X-Received: by 2002:a05:690c:6f0a:b0:6f0:23da:49a3 with SMTP id 00721157ae682-6febf295f42mr117068727b3.8.1741476682660;
        Sat, 08 Mar 2025 15:31:22 -0800 (PST)
Received: by 2002:a05:690c:c92:b0:6fe:b496:fc0e with SMTP id 00721157ae682-6feb4970ec7ms7b3;
        Sat, 8 Mar 2025 15:15:24 -0800 (PST)
X-Received: by 2002:a05:690c:6d09:b0:6f9:871e:6903 with SMTP id 00721157ae682-6febf3fa3d4mr120386157b3.37.1741475723713;
        Sat, 08 Mar 2025 15:15:23 -0800 (PST)
Date: Sat, 8 Mar 2025 15:15:23 -0800 (PST)
From: Nighttime Satoshi <nighttimesatoshi@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <e02354e1-19c9-420d-86bb-d052668d8805n@googlegroups.com>
In-Reply-To: <5674c8ec-a38c-487d-9736-bf3b99178335@app.fastmail.com>
References: <62b454f8-56be-4eae-ba3e-57c53d493f3dn@googlegroups.com>
 <5674c8ec-a38c-487d-9736-bf3b99178335@app.fastmail.com>
Subject: Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_187360_2026585713.1741475723239"
X-Original-Sender: nighttimesatoshi@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_187360_2026585713.1741475723239
Content-Type: multipart/alternative; 
	boundary="----=_Part_187361_1277710819.1741475723239"

------=_Part_187361_1277710819.1741475723239
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Light,

Thanks for the thoughtful questions!

1. The 546-satoshi threshold isn't intended to be permanently fixed in the=
=20
protocol. I used this value as it matches Bitcoin Core's existing dust=20
threshold for P2PKH outputs. I further noted in the proposal that a dynamic=
=20
threshold would be more appropriate than a fixed one, since the dust=20
threshold naturally fluctuates with network conditions. Wallet softwares=20
could calculates what qualifies as "dust" based on current mempool=20
conditions. And you are correct - users can designate any UTXO, but=20
economically rational users will only choose those below the spendable=20
threshold. This approach maintains my proposal's focus on economically=20
unviable outputs while allowing flexibility as network conditions evolve.

2. Great point. I focused on simple key-controlled UTXOs (P2PKH, P2WPKH)=20
for a couple of reasons:=20

   - They're straightforward to verify with a single signature
   - They represent a significant portion of dust UTXOs
   - Extending to complex scripts would substantially increase=20
   implementation complexity
  =20
I deliberately targeted simple script types for the initial implementation=
=20
to keep the proposal focused and feasible. However, future extensions could=
=20
add support for multisig and other script-based dust once we establish the=
=20
basic mechanism and validate its effectiveness.

3. You're right that the metadata requirements (txid: 32 bytes, vout: ~1-4=
=20
bytes, signature: ~64 bytes, prefix: ~7 bytes) has the risk of exceeding=20
the standard 80-byte limit. If this is the case, we could use SegWit=20
witness data instead of OP_RETURN. A new witness version could efficiently=
=20
encode this information, drastically reducing on-chain bytes, or Implement=
=20
Schnorr or aggregated signatures to reduce signature size. Economically,=20
this would significantly reduce the transaction weight, making it viable=20
even during periods of higher fees. Users would still only designate dust=
=20
UTXOs when it makes economic sense based on current fee rates. I mentioned=
=20
in passing these alternative methods in the proposal but I should clarify=
=20
them as main solutions instead.

4.Does this method actually save any onchain bytes relative to "traditional=
=20
spending"?  - The proposal is less about byte savings (though I do think it=
=20
offers benefits to it):

Traditional spending of a dust UTXO requires:

Input data (~148 vB for legacy inputs, ~68 vB for SegWit inputs)
Output data (~31 vB per output)
Transaction overhead

My mechanism removes the need for users to include the full input=20
scriptSig/witness data since miners claim the UTXO directly in their=20
coinbase transaction. This is particularly efficient when users designate=
=20
multiple dust UTXOs in a single transaction.

5. Is it worth a soft fork? I believe it is, for several reasons:

The problem of Bitcoin dust is a growing issue - especially as adoption and=
=20
price grows.
It unlocks value currently trapped in dust UTXOs without requiring users to=
=20
pay upfront fees
It provides miners with an additional revenue source, which becomes=20
increasingly important as block rewards diminish
It efficiently cleans up the UTXO set, addressing a long-term scalability=
=20
concern
It improves Bitcoin's fungibility by providing a path for stranded satoshis=
=20
to rejoin economic circulation

I should clarify an important aspect: when miners "claim" dust UTXOs, these=
=20
UTXOs are permanently destroyed, not retained in their original form. Their=
=20
value is transferred directly into the miner's coinbase output as newly=20
spendable satoshis. This permanent removal of unspendable UTXOs from the=20
set is a key benefit.
This mechanism is specifically limited to miner coinbase transactions=20
because:

Coinbase transactions already have special consensus rules that allow them=
=20
to create outputs without standard input validation
Restricting to coinbase transactions greatly simplifies security=20
considerations
Extending this capability to regular transactions would introduce=20
significant risks and complexities

Neither Lightning nor existing wallet techniques can economically address=
=20
truly unspendable dust UTXOs without user-paid fees.

Let me know what you think of these.

Warm regards,,=20
Nighttime
On Saturday, March 8, 2025 at 4:23:34=E2=80=AFPM UTC-6 Light wrote:

> Hi Nighttime,
>
> Several questions come to mind:
>
> 1. Why fix the limit at 546 sats? Why not allow any UTXO to be spent this=
=20
> way?
>
> 2. What about "dust" UTXOs owned by scripts rather than keys? e.g. multis=
ig
>
> 3. The size of this OP_RETURN output could be a barrier, both technical=
=20
> and economic:
>
> Technical: Based on the metadata contained in this output, this may be=20
> larger than the current 80-byte OP_RETURN standardness limit. Is that=20
> correct? If so, does this imply a need to increase this standardness limi=
t,=20
> or require an assumption that the user will find their own way to=20
> circumvent this limit? e.g. using Libre Relay
>
> Economic: Depending on the size of this OP_RETURN output and the current=
=20
> market fee rate, the value of the dust may still be uneconomical for the=
=20
> miner to claim. For example, if the OP_RETURN output is 100 vB and the=20
> current fee rate is 6 s/vB then a 546 sat dust output will not be=20
> economical for the miner to include in their block.
>
> 4. Given the above considerations, I wonder how this proposal is an=20
> improvement over the status quo at all. Does this method of spending a UT=
XO=20
> via OP_RETURN actually save any onchain bytes relative to "traditional=20
> spending"? And even if it does result in onchain byte savings in some or=
=20
> all cases, is it really worth all of the effort of a soft fork and wallet=
=20
> updates etc to allow them to become spendable this way if economic=20
> realities could make them uneconomical to spend anyways should we=20
> permanently transition to a paradigm of sufficiently high fee rates?
>
> Regards,
>
> Light
>
> On Sat, Mar 8, 2025, at 1:23 PM, Nighttime Satoshi wrote:
> > Dear fellow Bitcoin developers,
> >
> > I'm excited to share a proposal addressing a long-standing Bitcoin=20
> > challenge: economically unviable dust UTXOs.
> > As Bitcoin's value and transaction fees increase, more UTXOs become=20
> > effectively unspendable because the cost to move them exceeds their=20
> > value. This creates a growing dust horizon - small amounts of BTC=20
> > permanently stranded from circulation, weakening fungibility and=20
> > bloating the UTXO set.
> >
> > I'm proposing a solution that enables users to voluntarily designate=20
> > their dust UTXOs as transaction fees through cryptographic=20
> > authorization, allowing miners to claim them directly without requiring=
=20
> > traditional spending. This is a win-win-win solution for users=20
> > (reclaiming otherwise stranded value), miners (additional fee income),=
=20
> > and the network (reduced UTXO set size).
> >
> > Key Features: 1. *Entirely Voluntary* - Users must explicitly authorize=
=20
> > any dust UTXO transfer with cryptographic signatures proving ownership
> > 2. *Implementation as Soft Fork* - Backward-compatible with=20
> > non-upgraded nodes
> > 3. *Simple Security Model* - Uses familiar signature verification=20
> > without exposing private keys
> > 4. *Clearly Defined Dust Threshold* - Fixed at 546 satoshis, matching=
=20
> > Bitcoin Core's existing dust limit
> > 5. *Race Condition Prevention* - Comprehensive safeguards against=20
> > double-spend and miner race conditions
> > 6. *Minimal Consensus Impact* - Carefully designed to introduce=20
> > minimal complexity to Bitcoin's validation logic
> > Economic Benefits: 1. *UTXO Set Cleanup* - Removing millions of dust=20
> > UTXOs could significantly reduce the UTXO set size
> > 2. *Enhanced Fungibility* - Provides a pathway for stranded satoshis=20
> > to rejoin economic circulation
> > 3. *Long-term Miner Incentive* - Creates an additional fee source as=20
> > block rewards diminish
> > 4. *Complementary to Existing Solutions* - Works alongside batching,=20
> > consolidation, and Lightning Network
> > Technical Implementation:
> > The proposal uses a special OP_RETURN output format in transactions to=
=20
> > designate dust UTXOs for miner claiming:
> >
> > OP_RETURN <DUST_FEE_PREFIX> <dust_utxo_txid> <dust_utxo_vout> <signatur=
e>
> >
> > Miners can claim these UTXOs in their coinbase transaction if and only=
=20
> > if the corresponding designation transaction is included in the same=20
> > block.
> >
> > Historical Context & Contributions:
> > It seems that previous discussions on dust UTXOs have considered many=
=20
> > approaches, including forced reclamation. This proposal avoids those=20
> > controversies by requiring explicit user authorization while still=20
> > providing an economically rational path for dust cleanup.
> >
> > You can read the full proposal draft here:=20
> >=20
> https://github.com/satoshinotebook/BIPs/blob/main/unlocking-dust-utxos-as=
-transaction-fees.md
> >
> > I'd appreciate feedback on:
> >
> > 1. Technical feasibility of the soft fork implementation
> > 2. Security considerations and potential edge cases
> > 3. Economic incentive alignment
> > 4. User experience concerns for wallet implementations
> > Thank you for any feedback! I believe it offers a practical solution to=
=20
> > a growing challenge that will only become more significant as Bitcoin=
=20
> > continues to mature and evolve.
> >
> > With respect,
> >
> > Nighttime Satoshi
> >
> > nighttim...@gmail.com
> >
> > https://satoshinotebook.com
> >
> >
> > --=20
> > You received this message because you are subscribed to the Google=20
> > Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> > an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> >=20
> https://groups.google.com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c5=
3d493f3dn%40googlegroups.com=20
> > <
> https://groups.google.com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c5=
3d493f3dn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter
> >.
>

--=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/=
e02354e1-19c9-420d-86bb-d052668d8805n%40googlegroups.com.

------=_Part_187361_1277710819.1741475723239
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Light,<div><br /></div><div>Thanks for the thoughtful questions!</div><d=
iv><br /></div><div>1.=C2=A0The 546-satoshi threshold isn't intended to be =
permanently fixed in the protocol. I used this value as it matches Bitcoin =
Core's existing dust threshold for P2PKH outputs. I further noted in the pr=
oposal that a dynamic threshold would be more appropriate than a fixed one,=
 since the dust threshold naturally fluctuates with network conditions.=C2=
=A0<span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Wallet s=
oftwares could calculates what qualifies as "dust" based on current mempool=
 conditions.=C2=A0</span>And you are correct - u<span style=3D"caret-color:=
 rgb(0, 0, 0); color: rgb(0, 0, 0);">sers can designate any UTXO, but econo=
mically rational users will only choose those below the spendable threshold=
.=C2=A0</span><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0)=
;">This approach maintains my proposal's focus on economically unviable out=
puts while allowing flexibility as network conditions evolve.</span></div><=
div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br /><=
/span></div><div>2.=C2=A0Great point. I focused on simple key-controlled UT=
XOs (P2PKH, P2WPKH) for a couple of reasons:=C2=A0</div><div><ul><li>They'r=
e straightforward to verify with a single signature<br /></li><li>They repr=
esent a significant portion of dust UTXOs<br /></li><li>Extending to comple=
x scripts would substantially increase implementation complexity<br /></li>=
</ul>I deliberately targeted simple script types for the initial implementa=
tion to keep the proposal focused and feasible. However, future extensions =
could add support for multisig and other script-based dust once we establis=
h the basic mechanism and validate its effectiveness.<br /></div><div><br /=
></div><div>3. You're right that the metadata requirements (txid: 32 bytes,=
 vout: ~1-4 bytes, signature: ~64 bytes, prefix: ~7 bytes) has the risk of =
exceeding the standard 80-byte limit. If this is the case, we could use Seg=
Wit witness data instead of OP_RETURN. A new witness version could efficien=
tly encode this information, drastically reducing on-chain bytes, or Implem=
ent Schnorr or aggregated signatures to reduce signature size. Economically=
, this would significantly reduce the transaction weight, making it viable =
even during periods of higher fees. Users would still only designate dust U=
TXOs when it makes economic sense based on current fee rates. I mentioned i=
n passing these alternative methods in the proposal but I should clarify th=
em as main solutions instead.</div><div><br /></div><div>4.Does this method=
 actually save any onchain bytes relative to "traditional spending"? =C2=A0=
- The proposal is less about byte savings (though I do think it offers bene=
fits to it):</div><div><br />Traditional spending of a dust UTXO requires:<=
br /><br />Input data (~148 vB for legacy inputs, ~68 vB for SegWit inputs)=
<br />Output data (~31 vB per output)<br />Transaction overhead</div><div><=
br /></div><div>My mechanism removes the need for users to include the full=
 input scriptSig/witness data since miners claim the UTXO directly in their=
 coinbase transaction. This is particularly efficient when users designate =
multiple dust UTXOs in a single transaction.</div><div><br />5. Is it worth=
 a soft fork? I believe it is, for several reasons:</div><div><br /></div><=
div>The problem of Bitcoin dust is a growing issue - especially as adoption=
 and price grows.<br />It unlocks value currently trapped in dust UTXOs wit=
hout requiring users to pay upfront fees<br />It provides miners with an ad=
ditional revenue source, which becomes increasingly important as block rewa=
rds diminish<br />It efficiently cleans up the UTXO set, addressing a long-=
term scalability concern<br />It improves Bitcoin's fungibility by providin=
g a path for stranded satoshis to rejoin economic circulation<br /><br />I =
should clarify an important aspect: when miners "claim" dust UTXOs, these U=
TXOs are permanently destroyed, not retained in their original form. Their =
value is transferred directly into the miner's coinbase output as newly spe=
ndable satoshis. This permanent removal of unspendable UTXOs from the set i=
s a key benefit.<br />This mechanism is specifically limited to miner coinb=
ase transactions because:<br /><br />Coinbase transactions already have spe=
cial consensus rules that allow them to create outputs without standard inp=
ut validation<br />Restricting to coinbase transactions greatly simplifies =
security considerations<br />Extending this capability to regular transacti=
ons would introduce significant risks and complexities<br /><br />Neither L=
ightning nor existing wallet techniques can economically address truly unsp=
endable dust UTXOs without user-paid fees.</div><div><br /></div><div>Let m=
e know what you think of these.</div><div><br /></div><div>Warm regards,,=
=C2=A0</div><div>Nighttime</div><div class=3D"gmail_quote"><div dir=3D"auto=
" class=3D"gmail_attr">On Saturday, March 8, 2025 at 4:23:34=E2=80=AFPM UTC=
-6 Light wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex=
;">Hi Nighttime,
<br>
<br>Several questions come to mind:
<br>
<br>1. Why fix the limit at 546 sats? Why not allow any UTXO to be spent th=
is way?
<br>
<br>2. What about &quot;dust&quot; UTXOs owned by scripts rather than keys?=
 e.g. multisig
<br>
<br>3. The size of this OP_RETURN output could be a barrier, both technical=
 and economic:
<br>
<br>Technical: Based on the metadata contained in this output, this may be =
larger than the current 80-byte OP_RETURN standardness limit. Is that corre=
ct? If so, does this imply a need to increase this standardness limit, or r=
equire an assumption that the user will find their own way to circumvent th=
is limit? e.g. using Libre Relay
<br>
<br>Economic: Depending on the size of this OP_RETURN output and the curren=
t market fee rate, the value of the dust may still be uneconomical for the =
miner to claim. For example, if the OP_RETURN output is 100 vB and the curr=
ent fee rate is 6 s/vB then a 546 sat dust output will not be economical fo=
r the miner to include in their block.
<br>
<br>4. Given the above considerations, I wonder how this proposal is an imp=
rovement over the status quo at all. Does this method of spending a UTXO vi=
a OP_RETURN actually save any onchain bytes relative to &quot;traditional s=
pending&quot;? And even if it does result in onchain byte savings in some o=
r all cases, is it really worth all of the effort of a soft fork and wallet=
 updates etc to allow them to become spendable this way if economic realiti=
es could make them uneconomical to spend anyways should we permanently tran=
sition to a paradigm of sufficiently high fee rates?
<br>
<br>Regards,
<br>
<br>Light
<br>
<br>On Sat, Mar 8, 2025, at 1:23 PM, Nighttime Satoshi wrote:
<br>&gt; Dear fellow Bitcoin developers,
<br>&gt;
<br>&gt; I&#39;m excited to share a proposal addressing a long-standing Bit=
coin=20
<br>&gt; challenge: economically unviable dust UTXOs.
<br>&gt; As Bitcoin&#39;s value and transaction fees increase, more UTXOs b=
ecome=20
<br>&gt; effectively unspendable because the cost to move them exceeds thei=
r=20
<br>&gt; value. This creates a growing dust horizon - small amounts of BTC=
=20
<br>&gt; permanently stranded from circulation, weakening fungibility and=
=20
<br>&gt; bloating the UTXO set.
<br>&gt;
<br>&gt; I&#39;m proposing a solution that enables users to voluntarily des=
ignate=20
<br>&gt; their dust UTXOs as transaction fees through cryptographic=20
<br>&gt; authorization, allowing miners to claim them directly without requ=
iring=20
<br>&gt; traditional spending. This is a win-win-win solution for users=20
<br>&gt; (reclaiming otherwise stranded value), miners (additional fee inco=
me),=20
<br>&gt; and the network (reduced UTXO set size).
<br>&gt;
<br>&gt; Key Features: 1. *Entirely Voluntary* - Users must explicitly auth=
orize=20
<br>&gt; any dust UTXO transfer with cryptographic signatures proving owner=
ship
<br>&gt;  2. *Implementation as Soft Fork* - Backward-compatible with=20
<br>&gt; non-upgraded nodes
<br>&gt;  3. *Simple Security Model* - Uses familiar signature verification=
=20
<br>&gt; without exposing private keys
<br>&gt;  4. *Clearly Defined Dust Threshold* - Fixed at 546 satoshis, matc=
hing=20
<br>&gt; Bitcoin Core&#39;s existing dust limit
<br>&gt;  5. *Race Condition Prevention* - Comprehensive safeguards against=
=20
<br>&gt; double-spend and miner race conditions
<br>&gt;  6. *Minimal Consensus Impact* - Carefully designed to introduce=
=20
<br>&gt; minimal complexity to Bitcoin&#39;s validation logic
<br>&gt; Economic Benefits: 1. *UTXO Set Cleanup* - Removing millions of du=
st=20
<br>&gt; UTXOs could significantly reduce the UTXO set size
<br>&gt;  2. *Enhanced Fungibility* - Provides a pathway for stranded satos=
his=20
<br>&gt; to rejoin economic circulation
<br>&gt;  3. *Long-term Miner Incentive* - Creates an additional fee source=
 as=20
<br>&gt; block rewards diminish
<br>&gt;  4. *Complementary to Existing Solutions* - Works alongside batchi=
ng,=20
<br>&gt; consolidation, and Lightning Network
<br>&gt; Technical Implementation:
<br>&gt; The proposal uses a special OP_RETURN output format in transaction=
s to=20
<br>&gt; designate dust UTXOs for miner claiming:
<br>&gt;
<br>&gt; OP_RETURN &lt;DUST_FEE_PREFIX&gt; &lt;dust_utxo_txid&gt; &lt;dust_=
utxo_vout&gt; &lt;signature&gt;
<br>&gt;
<br>&gt; Miners can claim these UTXOs in their coinbase transaction if and =
only=20
<br>&gt; if the corresponding designation transaction is included in the sa=
me=20
<br>&gt; block.
<br>&gt;
<br>&gt; Historical Context &amp; Contributions:
<br>&gt; It seems that previous discussions on dust UTXOs have considered m=
any=20
<br>&gt; approaches, including forced reclamation. This proposal avoids tho=
se=20
<br>&gt; controversies by requiring explicit user authorization while still=
=20
<br>&gt; providing an economically rational path for dust cleanup.
<br>&gt;
<br>&gt; You can read the full proposal draft here:=20
<br>&gt; <a href=3D"https://github.com/satoshinotebook/BIPs/blob/main/unloc=
king-dust-utxos-as-transaction-fees.md" target=3D"_blank" rel=3D"nofollow" =
data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://=
github.com/satoshinotebook/BIPs/blob/main/unlocking-dust-utxos-as-transacti=
on-fees.md&amp;source=3Dgmail&amp;ust=3D1741559812025000&amp;usg=3DAOvVaw0R=
Ok437cB6eORoTsiAvXBm">https://github.com/satoshinotebook/BIPs/blob/main/unl=
ocking-dust-utxos-as-transaction-fees.md</a>
<br>&gt;
<br>&gt; I&#39;d appreciate feedback on:
<br>&gt;
<br>&gt;  1. Technical feasibility of the soft fork implementation
<br>&gt;  2. Security considerations and potential edge cases
<br>&gt;  3. Economic incentive alignment
<br>&gt;  4. User experience concerns for wallet implementations
<br>&gt; Thank you for any feedback! I believe it offers a practical soluti=
on to=20
<br>&gt; a growing challenge that will only become more significant as Bitc=
oin=20
<br>&gt; continues to mature and evolve.
<br>&gt;
<br>&gt; With respect,
<br>&gt;
<br>&gt; Nighttime Satoshi
<br>&gt;
<br>&gt; <a href data-email-masked rel=3D"nofollow">nighttim...@gmail.com</=
a>
<br>&gt;
<br>&gt; <a href=3D"https://satoshinotebook.com" target=3D"_blank" rel=3D"n=
ofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://satoshinotebook.com&amp;source=3Dgmail&amp;ust=3D174155981202500=
0&amp;usg=3DAOvVaw2kaeEDlhuQ8BlCmFZUpXL_">https://satoshinotebook.com</a>
<br>&gt;
<br>&gt;
<br>&gt; --=20
<br>&gt; You received this message because you are subscribed to the Google=
=20
<br>&gt; Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send=20
<br>&gt; an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+=
...@googlegroups.com</a>.
<br>&gt; To view this discussion visit=20
<br>&gt; <a href=3D"https://groups.google.com/d/msgid/bitcoindev/62b454f8-5=
6be-4eae-ba3e-57c53d493f3dn%40googlegroups.com" target=3D"_blank" rel=3D"no=
follow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3D=
https://groups.google.com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d=
493f3dn%2540googlegroups.com&amp;source=3Dgmail&amp;ust=3D1741559812025000&=
amp;usg=3DAOvVaw2TfLaNyiF35ExcsBYNAwFb">https://groups.google.com/d/msgid/b=
itcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups.com</a>=20
<br>&gt; &lt;<a href=3D"https://groups.google.com/d/msgid/bitcoindev/62b454=
f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups.com?utm_medium=3Demail&amp;u=
tm_source=3Dfooter" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/=
msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%2540googlegroups.com=
?utm_medium%3Demail%26utm_source%3Dfooter&amp;source=3Dgmail&amp;ust=3D1741=
559812025000&amp;usg=3DAOvVaw10DB4N2TSWLSvcYYWPw_ei">https://groups.google.=
com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups=
.com?utm_medium=3Demail&amp;utm_source=3Dfooter</a>&gt;.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/e02354e1-19c9-420d-86bb-d052668d8805n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/e02354e1-19c9-420d-86bb-d052668d8805n%40googlegroups.com</a>.<br />

------=_Part_187361_1277710819.1741475723239--

------=_Part_187360_2026585713.1741475723239--