From: Garlo Nicon <garlonicon@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees
Date: Thu, 13 Mar 2025 05:55:58 -0700 (PDT) [thread overview]
Message-ID: <526eb6e1-ace2-47e9-9259-e2ec74b749b6n@googlegroups.com> (raw)
In-Reply-To: <CALQsJZX=6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6501 bytes --]
I wonder, why OP used so much of AI-generated content to make these posts.
> What if miners claim authorized dust UTXOs through entirely separate,
regular, standard-format transactions?
They can do that today, no changes are needed. Just sign any dust with
SIGHASH_NONE | SIGHASH_ANYONECANPAY, or even use SIGHASH_SINGLE bug, to
spend all coins from the same public key, with the same signature.
> What if miners are permitted to spend dust UTXOs without their original
conditions only under strictly defined new rules
Then it is still a hard-fork. But your AI model probably cannot understand
it.
niedziela, 9 marca 2025 o 02:43:29 UTC+1 Nighttime Satoshi napisał(a):
> 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 <bitco...@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 <
>> nighttim...@gmail•com> wrote:
>>
>> > Dear fellow Bitcoin developers,
>> >
>> > I'm excited to share a proposal addressing a long-standing Bitcoin
>> challenge: economically unviable dust UTXOs.
>>
>>
--
You received this message because you are subscribed to the Google Groups "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/526eb6e1-ace2-47e9-9259-e2ec74b749b6n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8080 bytes --]
prev parent reply other threads:[~2025-03-14 3:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-08 18:23 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
2025-03-13 12:55 ` Garlo Nicon [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=526eb6e1-ace2-47e9-9259-e2ec74b749b6n@googlegroups.com \
--to=garlonicon@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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