From: Nighttime Satoshi <nighttimesatoshi@gmail.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees
Date: Sat, 8 Mar 2025 19:35:41 -0600 [thread overview]
Message-ID: <CALQsJZX=6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ@mail.gmail.com> (raw)
In-Reply-To: <w6yVRkZu07vMNHYp483katPNPA5nwFEx-kje8eSpjRl9S6O8rx_ViKi62XlcW2b36SF8dceUXKkBLrmrtvK7RuPd1w1y0iZ4BBP4rSleNcc=@wuille.net>
[-- 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 --]
prev parent reply other threads:[~2025-03-09 1:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-08 18:23 [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees Nighttime Satoshi
2025-03-08 22:13 ` Light
2025-03-08 23:15 ` Nighttime Satoshi
2025-03-08 23:48 ` Pieter Wuille
2025-03-09 1:35 ` Nighttime Satoshi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALQsJZX=6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ@mail.gmail.com' \
--to=nighttimesatoshi@gmail.com \
--cc=bitcoin-dev@wuille.net \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox