[bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees

[bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees

[Nighttime Satoshi]

[-- Attachment #1.1: Type: text/plain, Size: 3651 bytes --]

Dear fellow Bitcoin developers,

I'm excited to share a proposal addressing a long-standing Bitcoin 
challenge: economically unviable dust UTXOs.

As Bitcoin's value and transaction fees increase, more UTXOs become 
effectively unspendable because the cost to move them exceeds their value. 
This creates a growing dust horizon - small amounts of BTC permanently 
stranded from circulation, weakening fungibility and bloating the UTXO set.

I'm proposing a solution that enables users to voluntarily designate their 
dust UTXOs as transaction fees through cryptographic authorization, 
allowing miners to claim them directly without requiring traditional 
spending. This is a win-win-win solution for users (reclaiming otherwise 
stranded value), miners (additional fee income), and the network (reduced 
UTXO set size).
Key Features:
   
   1. *Entirely Voluntary* - Users must explicitly authorize any dust UTXO 
   transfer with cryptographic signatures proving ownership
   2. *Implementation as Soft Fork* - Backward-compatible with non-upgraded 
   nodes
   3. *Simple Security Model* - Uses familiar signature verification 
   without exposing private keys
   4. *Clearly Defined Dust Threshold* - Fixed at 546 satoshis, matching 
   Bitcoin Core's existing dust limit
   5. *Race Condition Prevention* - Comprehensive safeguards against 
   double-spend and miner race conditions
   6. *Minimal Consensus Impact* - Carefully designed to introduce minimal 
   complexity to Bitcoin's validation logic

Economic Benefits:
   
   1. *UTXO Set Cleanup* - Removing millions of dust UTXOs could 
   significantly reduce the UTXO set size
   2. *Enhanced Fungibility* - Provides a pathway for stranded satoshis to 
   rejoin economic circulation
   3. *Long-term Miner Incentive* - Creates an additional fee source as 
   block rewards diminish
   4. *Complementary to Existing Solutions* - Works alongside batching, 
   consolidation, and Lightning Network

Technical Implementation:

The proposal uses a special OP_RETURN output format in transactions to 
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 if 
the corresponding designation transaction is included in the same block.
Historical Context & Contributions:

It seems that previous discussions on dust UTXOs have considered many 
approaches, including forced reclamation. This proposal avoids those 
controversies by requiring explicit user authorization while still 
providing an economically rational path for dust cleanup.

You can read the full proposal draft here: 
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 a 
growing challenge that will only become more significant as Bitcoin 
continues to mature and evolve.

With respect,

Nighttime Satoshi

nighttimesatoshi@gmail.com

https://satoshinotebook.com

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5701 bytes --]

Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees

[Light]

Hi Nighttime,

Several questions come to mind:

1. Why fix the limit at 546 sats? Why not allow any UTXO to be spent this 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 correct? If so, does this imply a need to increase this standardness limit, or require an assumption that the user will find their own way to circumvent this limit? e.g. using Libre Relay

Economic: Depending on the size of this OP_RETURN output and the current 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 current fee rate is 6 s/vB then a 546 sat dust output will not be economical for the miner to include in their block.

4. Given the above considerations, I wonder how this proposal is an improvement over the status quo at all. Does this method of spending a UTXO via OP_RETURN actually save any onchain bytes relative to "traditional spending"? And even if it does result in onchain byte savings in some or 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 realities could make them uneconomical to spend anyways should we 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 
> challenge: economically unviable dust UTXOs.
> As Bitcoin's value and transaction fees increase, more UTXOs become 
> effectively unspendable because the cost to move them exceeds their 
> value. This creates a growing dust horizon - small amounts of BTC 
> permanently stranded from circulation, weakening fungibility and 
> bloating the UTXO set.
>
> I'm proposing a solution that enables users to voluntarily designate 
> their dust UTXOs as transaction fees through cryptographic 
> authorization, allowing miners to claim them directly without requiring 
> traditional spending. This is a win-win-win solution for users 
> (reclaiming otherwise stranded value), miners (additional fee income), 
> and the network (reduced UTXO set size).
>
> Key Features: 1. *Entirely Voluntary* - Users must explicitly authorize 
> any dust UTXO transfer with cryptographic signatures proving ownership
>  2. *Implementation as Soft Fork* - Backward-compatible with 
> non-upgraded nodes
>  3. *Simple Security Model* - Uses familiar signature verification 
> without exposing private keys
>  4. *Clearly Defined Dust Threshold* - Fixed at 546 satoshis, matching 
> Bitcoin Core's existing dust limit
>  5. *Race Condition Prevention* - Comprehensive safeguards against 
> double-spend and miner race conditions
>  6. *Minimal Consensus Impact* - Carefully designed to introduce 
> minimal complexity to Bitcoin's validation logic
> Economic Benefits: 1. *UTXO Set Cleanup* - Removing millions of dust 
> UTXOs could significantly reduce the UTXO set size
>  2. *Enhanced Fungibility* - Provides a pathway for stranded satoshis 
> to rejoin economic circulation
>  3. *Long-term Miner Incentive* - Creates an additional fee source as 
> block rewards diminish
>  4. *Complementary to Existing Solutions* - Works alongside batching, 
> consolidation, and Lightning Network
> Technical Implementation:
> The proposal uses a special OP_RETURN output format in transactions to 
> 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 
> if the corresponding designation transaction is included in the same 
> block.
>
> Historical Context & Contributions:
> It seems that previous discussions on dust UTXOs have considered many 
> approaches, including forced reclamation. This proposal avoids those 
> controversies by requiring explicit user authorization while still 
> providing an economically rational path for dust cleanup.
>
> You can read the full proposal draft here: 
> 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 
> a growing challenge that will only become more significant as Bitcoin 
> continues to mature and evolve.
>
> With respect,
>
> Nighttime Satoshi
>
> nighttimesatoshi@gmail.com
>
> https://satoshinotebook.com
>
>
> -- 
> 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 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups.com 
> <https://groups.google.com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/5674c8ec-a38c-487d-9736-bf3b99178335%40app.fastmail.com.

Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees

[Nighttime Satoshi]

[-- Attachment #1.1: Type: text/plain, Size: 10597 bytes --]

Hi Light,

Thanks for the thoughtful questions!

1. The 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 proposal that a dynamic 
threshold would be more appropriate than a fixed one, since the dust 
threshold naturally fluctuates with network conditions. Wallet softwares 
could calculates what qualifies as "dust" based on current mempool 
conditions. And you are correct - users can designate any UTXO, but 
economically rational users will only choose those below the spendable 
threshold. This approach maintains my proposal's focus on economically 
unviable outputs while allowing flexibility as network conditions evolve.

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

   - They're straightforward to verify with a single signature
   - They represent a significant portion of dust UTXOs
   - Extending to complex scripts would substantially increase 
   implementation complexity
   
I deliberately targeted simple script types for the initial implementation 
to keep the proposal focused and feasible. However, future extensions could 
add support for multisig and other script-based dust once we establish 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 SegWit 
witness data instead of OP_RETURN. A new witness version could efficiently 
encode this information, drastically reducing on-chain bytes, or Implement 
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 
UTXOs when it makes economic sense based on current fee rates. I mentioned 
in passing these alternative methods in the proposal but I should clarify 
them as main solutions instead.

4.Does this method actually save any onchain bytes relative to "traditional 
spending"?  - The proposal is less about byte savings (though I do think it 
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 
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:

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

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

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

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

Let me know what you think of these.

Warm regards,, 
Nighttime
On Saturday, March 8, 2025 at 4:23:34 PM 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 
> 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 
> correct? If so, does this imply a need to increase this standardness limit, 
> or require an assumption that the user will find their own way to 
> circumvent this limit? e.g. using Libre Relay
>
> Economic: Depending on the size of this OP_RETURN output and the current 
> 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 
> current fee rate is 6 s/vB then a 546 sat dust output will not be 
> economical for the miner to include in their block.
>
> 4. Given the above considerations, I wonder how this proposal is an 
> improvement over the status quo at all. Does this method of spending a UTXO 
> via OP_RETURN actually save any onchain bytes relative to "traditional 
> spending"? And even if it does result in onchain byte savings in some or 
> 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 
> realities could make them uneconomical to spend anyways should we 
> 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 
> > challenge: economically unviable dust UTXOs.
> > As Bitcoin's value and transaction fees increase, more UTXOs become 
> > effectively unspendable because the cost to move them exceeds their 
> > value. This creates a growing dust horizon - small amounts of BTC 
> > permanently stranded from circulation, weakening fungibility and 
> > bloating the UTXO set.
> >
> > I'm proposing a solution that enables users to voluntarily designate 
> > their dust UTXOs as transaction fees through cryptographic 
> > authorization, allowing miners to claim them directly without requiring 
> > traditional spending. This is a win-win-win solution for users 
> > (reclaiming otherwise stranded value), miners (additional fee income), 
> > and the network (reduced UTXO set size).
> >
> > Key Features: 1. *Entirely Voluntary* - Users must explicitly authorize 
> > any dust UTXO transfer with cryptographic signatures proving ownership
> > 2. *Implementation as Soft Fork* - Backward-compatible with 
> > non-upgraded nodes
> > 3. *Simple Security Model* - Uses familiar signature verification 
> > without exposing private keys
> > 4. *Clearly Defined Dust Threshold* - Fixed at 546 satoshis, matching 
> > Bitcoin Core's existing dust limit
> > 5. *Race Condition Prevention* - Comprehensive safeguards against 
> > double-spend and miner race conditions
> > 6. *Minimal Consensus Impact* - Carefully designed to introduce 
> > minimal complexity to Bitcoin's validation logic
> > Economic Benefits: 1. *UTXO Set Cleanup* - Removing millions of dust 
> > UTXOs could significantly reduce the UTXO set size
> > 2. *Enhanced Fungibility* - Provides a pathway for stranded satoshis 
> > to rejoin economic circulation
> > 3. *Long-term Miner Incentive* - Creates an additional fee source as 
> > block rewards diminish
> > 4. *Complementary to Existing Solutions* - Works alongside batching, 
> > consolidation, and Lightning Network
> > Technical Implementation:
> > The proposal uses a special OP_RETURN output format in transactions to 
> > 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 
> > if the corresponding designation transaction is included in the same 
> > block.
> >
> > Historical Context & Contributions:
> > It seems that previous discussions on dust UTXOs have considered many 
> > approaches, including forced reclamation. This proposal avoids those 
> > controversies by requiring explicit user authorization while still 
> > providing an economically rational path for dust cleanup.
> >
> > You can read the full proposal draft here: 
> > 
> 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 
> > a growing challenge that will only become more significant as Bitcoin 
> > continues to mature and evolve.
> >
> > With respect,
> >
> > Nighttime Satoshi
> >
> > nighttim...@gmail.com
> >
> > https://satoshinotebook.com
> >
> >
> > -- 
> > 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 email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit 
> > 
> https://groups.google.com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups.com 
> > <
> https://groups.google.com/d/msgid/bitcoindev/62b454f8-56be-4eae-ba3e-57c53d493f3dn%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e02354e1-19c9-420d-86bb-d052668d8805n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 13672 bytes --]

Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees

[Pieter Wuille]

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 is the current rule. Allowing a coinbase transaction to additionally also spend certain outputs would require a hardfork.

* The outputs being marked as dust are not allowed to be spent by miners. Changing this requires a hardfork as well. Think about it: if this was possible with a softfork, it must mean that doing what you're proposing would *already be legal* today, and thus not need this proposed change in the first 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 transaction, in the same block. To pay the miner for the opportunity cost of not including normal transactions with these bytes, the fee for this OP_RETURN output 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. Together, they are no smaller (and with witness discount, I suspect larger) than 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 <nighttimesatoshi@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 "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/w6yVRkZu07vMNHYp483katPNPA5nwFEx-kje8eSpjRl9S6O8rx_ViKi62XlcW2b36SF8dceUXKkBLrmrtvK7RuPd1w1y0iZ4BBP4rSleNcc%3D%40wuille.net.

Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees

[Nighttime Satoshi]

[-- Attachment #1: Type: text/plain, Size: 5597 bytes --]

Hi Pieter,

You're absolutely right. You've raised valid technical concerns about my
original proposal regarding coinbase limitations and soft fork
requirements. Based on your points, I've reconsidered the implementation
approach to ensure it works as a proper soft fork. Here's the revised
mechanism. I'm curious to hear your thoughts:

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 "revive"
these dust satoshis back into the network at their full value, in order to
improve Bitcoin's fungibility. This dust problem will only get more
significant, and I don't think the deflationary effect of lost satoshis is
more valuable than the prospect of full fungibility. L2 solutions are a
bandaid.

*Amendments*:


*1. Coinbase Transaction Inputs:*
*Concern*: Coinbase transactions can only have exactly one input. Allowing
coinbase transactions to spend additional outputs would require a hard fork.

*Revised Solution:* What if miners claim authorized dust UTXOs through
entirely separate, regular, standard-format transactions? Though not
economically feasible for single transactions, it becomes extremely
beneficial economically when batching multiple dust UTXOs simultaneously,
significantly amortizing transaction overhead across many claims. Coinbase
transactions remain exactly as they are today, retaining their single-input
rule and current consensus constraints.

*2. Spending Dust Outputs Without Original Conditions*

*Concern: *The dust outputs marked for claiming by miners can't currently
be spent without fulfilling their original conditions, which would require
a hard fork to change.

*Revised Solution:* What if miners are permitted to spend dust UTXOs
without their original conditions *only under strictly defined new rules:*

** *The dust UTXO must be explicitly authorized for miner spending through
an OP_RETURN-based "Dust Fee Authorization" (DFA) transaction.

*The miner’s transaction claiming this dust must occur in the exact same
block as the DFA transaction.

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

These new consensus rules *strictly restrict* previously impossible
spending conditions, making it unequivocally a valid soft fork. No
previously illegal behavior is permitted without new restrictive conditions
explicitly met.


*3. Economic and Practical Viability*

*Concern: *The economic overhead (OP_RETURN transaction plus coinbase input
overhead) might be larger than simply spending the dust normally.

*Revised Solution:* With coinbase inputs no longer altered, the overhead is
significantly reduced. Furthermore, the revised mechanism explicitly
encourages batching multiple dust authorizations into a single DFA
transaction, dramatically amortizing overhead costs across many dust UTXOs.
This batching substantially improves economic viability, especially during
periods of lower mempool congestion where fees are minimal.

Does this design address your concerns while preserving the original goal
of voluntary, secure, and economically rational reclamation of dust UTXOs?

Your insights have been invaluable. I'm eager to receive any further
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 PM Pieter Wuille <bitcoin-dev@wuille.net> 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
> is the current rule. Allowing a coinbase transaction to additionally also
> spend certain outputs would require a hardfork.
>
> * The outputs being marked as dust are not allowed to be spent by miners.
> Changing this requires a hardfork as well. Think about it: if this was
> possible with a softfork, it must mean that doing what you're proposing
> would *already be legal* today, and thus not need this proposed change in
> the first 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
> transaction, in the same block. To pay the miner for the opportunity cost
> of not including normal transactions with these bytes, the fee for this
> OP_RETURN output 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. Together, they are no smaller (and with witness
> discount, I suspect larger) than 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 <
> nighttimesatoshi@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 "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALQsJZX%3D6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7420 bytes --]