From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 > > > > 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,

Thanks for the thoughtful questions!

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= =A0Wallet s= oftwares could calculates what qualifies as "dust" based on current mempool= conditions.=C2=A0And you are correct - users can designate any UTXO, but econo= mically rational users will only choose those below the spendable threshold= .=C2=A0This approach maintains my proposal's focus on economically unviable out= puts while allowing flexibility as network conditions evolve.
<= div>
<= /span>
2.=C2=A0Great point. I focused on simple key-controlled UT= XOs (P2PKH, P2WPKH) for a couple of reasons:=C2=A0
  • They'r= e straightforward to verify with a single signature
  • They repr= esent a significant portion of dust UTXOs
  • Extending to comple= x scripts would substantially increase implementation complexity
    • =
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.

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.

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):

Traditional spending of a dust UTXO requires:<= br />
Input data (~148 vB for legacy inputs, ~68 vB for SegWit inputs)=
Output data (~31 vB per output)
Transaction overhead
<= br />
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.

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

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

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.
This mechanism is specifically limited to miner coinb= ase transactions because:

Coinbase transactions already have spe= cial consensus rules that allow them to create outputs without standard inp= ut validation
Restricting to coinbase transactions greatly simplifies = security considerations
Extending this capability to regular transacti= ons would introduce significant risks and complexities

Neither L= ightning nor existing wallet techniques can economically address truly unsp= endable dust UTXOs without user-paid fees.

Let m= e know what you think of these.

Warm regards,,= =C2=A0
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 th= is way?

2. What about "dust" UTXOs owned by scripts rather than keys?= e.g. multisig

3. The size of this OP_RETURN output could be a barrier, both technical= and economic:

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

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.

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 "traditional s= pending"? 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?

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 Bit= coin=20
> challenge: economically unviable dust UTXOs.
> As Bitcoin's value and transaction fees increase, more UTXOs b= ecome=20
> effectively unspendable because the cost to move them exceeds thei= r=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 des= ignate=20
> their dust UTXOs as transaction fees through cryptographic=20
> authorization, allowing miners to claim them directly without requ= iring=20
> traditional spending. This is a win-win-win solution for users=20
> (reclaiming otherwise stranded value), miners (additional fee inco= me),=20
> and the network (reduced UTXO set size).
>
> Key Features: 1. *Entirely Voluntary* - Users must explicitly auth= orize=20
> any dust UTXO transfer with cryptographic signatures proving owner= ship
> 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, matc= hing=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 du= st=20
> UTXOs could significantly reduce the UTXO set size
> 2. *Enhanced Fungibility* - Provides a pathway for stranded satos= his=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 batchi= ng,=20
> consolidation, and Lightning Network
> Technical Implementation:
> The proposal uses a special OP_RETURN output format in transaction= s to=20
> designate dust UTXOs for miner claiming:
>
> OP_RETURN <DUST_FEE_PREFIX> <dust_utxo_txid> <dust_= utxo_vout> <signature>
>
> Miners can claim these UTXOs in their coinbase transaction if and = only=20
> if the corresponding designation transaction is included in the sa= me=20
> block.
>
> Historical Context & Contributions:
> It seems that previous discussions on dust UTXOs have considered m= any=20
> approaches, including forced reclamation. This proposal avoids tho= se=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
> https://github.com/satoshinotebook/BIPs/blob/main/unl= ocking-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 soluti= on to=20
> a growing challenge that will only become more significant as Bitc= oin=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
> https://groups.google.com/d/msgid/b= itcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups.com=20
> <https://groups.google.= com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups= .com?utm_medium=3Demail&utm_source=3Dfooter>.

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