path: root/f7/a50506b3979cdbbe6743312716700585772ac0

Delivery-date: Sat, 08 Mar 2025 17:43:36 -0800
Received: from mail-qv1-f61.google.com ([209.85.219.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCSLDOOA54LRBP7EWO7AMGQE6ELB55Y@googlegroups.com>)
	id 1tr5hX-0001Wm-M1
	for bitcoindev@gnusha.org; Sat, 08 Mar 2025 17:43:36 -0800
Received: by mail-qv1-f61.google.com with SMTP id 6a1803df08f44-6e8ffe3998csf44123636d6.2
        for <bitcoindev@gnusha.org>; Sat, 08 Mar 2025 17:43:35 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1741484609; cv=pass;
        d=google.com; s=arc-20240605;
        b=V86SJpTJt42rei/q1L1Cr3ild+pzo3CjsX03qaRRjThfQO9QY+1hcflkOh6lSNL0Ne
         5MUiQQ6ZlmmY3565ucAneDy77W9DNWLjBGIf/cHeQuH4t1NqVcMRfS5epRL3pO5MadJe
         blEJ26uNgs1KB8/fCgGnFuo1pS/8luezVgtsqEndQaEnAXwJYG/0Xx3YUpVAkkr33uMB
         TCxOCISX8Yj+1EZMzv68fW0xkM75M5kCOtTWoBJwdqkRyHNM9MNjc5OrQvqzI/aM+N8x
         lb59F8OyNQfMwlf2n+SR7UBCVPmNAoMMOzWZTX5fjQNsX+4py6IXJPg97IOTYy2EkC+N
         Z6+g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=WfDPFu9GsiLgRj0SraQ9m4vXg10BZLj4eS7XfivK/mY=;
        fh=j+nPjjzB6RqQYO8vJgtvzgucHBiBJChu+mN3Wsq0HI0=;
        b=NVIQv7siuYpMIOmtwgPLWOvCsOdKr/W341B7KyyRF150BYjMRnxKba/upT5Xh1k4uo
         mIs5kCQXdBBuna+oia5psRq9dRIwmVY/oB+l6/WE+ndfFjXGpRB6y84Ir0jSnF1Rv8nr
         kNaHS80r1wm6CusSLEjDxiqyLSxS3nr4BKCqYwJkPG7PH14Qgc4/Q5+A9ayG1wQF+9PW
         NYBT74H6KQdLDsUZLpgXfsRDgbpR+TwF3t+z1tYxNBRo1O6dBlmBF1pmi3FAotPx/KOq
         d/ttBNZaTbaciOJhmzIVOqvJzffYijDd8vdAbblHIkzCeCZzbKJO+rCnjjCunttzJiYk
         iH1Q==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=kqBPNQz0;
       spf=pass (google.com: domain of nighttimesatoshi@gmail.com designates 2607:f8b0:4864:20::a32 as permitted sender) smtp.mailfrom=nighttimesatoshi@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741484609; x=1742089409; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WfDPFu9GsiLgRj0SraQ9m4vXg10BZLj4eS7XfivK/mY=;
        b=kEAXqjPaAyVCQFtO+ZHbfzffzjPJ5WiYJtRJn9giKNJMj7UM3Bg6Lkw7XDv2c+ks8Z
         M+V6ssEBBiBOKHIifxLq7a9GWc4h1zP2Nds6bYFEWaRpEcOLSm6qy7fJ9ZAhJrCJ1jPH
         dWTbG5AeE+w1RpcBu1l26h+mrrRF6vpQ8Ug3UmN4oaAw1XVeBm++mD2b3lSd1deStjH7
         6R99CJt8YZt1qEfIfWg1rs+JDF+MKpKLIviO6Algjayqb+Ugtm2rOWxZbfjei+LegdxM
         ndNFToZgh7UZqPQI1hRlKPivJtF1pGldGiuyqLJgyNMTlHUwFRXGa6c4XqCO3oe0Tn3r
         vnIw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741484609; x=1742089409; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=WfDPFu9GsiLgRj0SraQ9m4vXg10BZLj4eS7XfivK/mY=;
        b=cUlzNOMuKy+g+0Odnbu9NOLF/5hJbTH8dpqiFPdJE4XNof+qo1Fe2HG+nkAAxWWapD
         2EQZbuCtyPRYVGATmk8TLb+sXvZXIv2+yYK8rPaUUr9/NAUIUbAmJj5DdzVVNqUKEwal
         LIvbi2CKNU7k75D4ueNmol8AGgUoLcHz19CrNtZO/b8Xt478swHvSDSrkxmG9WKn7XLa
         F9DnE+IvAHlq+w3JGyKk6S/F4A2e4Cot7AzoGtqAlBpVZSWAsJyv5X3qzjUDB92KpNBv
         oRx/SVwxcs7/WTtg3AboCCYRKVv0lNkvFdTpEvSczqDqM7j8J+iPEspyYzKduRzQNJJG
         8Hvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741484609; x=1742089409;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=WfDPFu9GsiLgRj0SraQ9m4vXg10BZLj4eS7XfivK/mY=;
        b=TcamlcijREdR1EzCCzfH5pjwq6nOim9uac0c4TXTZTBVWN/DC0Id1FPOw7MsppJ0hq
         vRRIXqov5AfGE26LaKNfn7VlB3c2KbWbEKt+p4IHwMeHBU7v+95/Ig70p7M6iEIVmqI7
         YZ8iCvlu8F8sj51qXotPtsScIESWCfE3gGxdNRhc/9ZblRiJrDZl8Z50Vxz8FTjQf/x1
         Xxpy4rVUifm2tsMahcRN9z5S3nfJxpX80q7ul+7jrV1HtRtfLXgMa6paJJVdXxv1X1tK
         SwGDssmAF8EOSuwGLwlxZoXUW5NE+EeCa3JIqP/vWdJFXV2ph2TqUAwd3Jf9Kg6LPEzn
         U/Mg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWJbLhSr24GWPkNNwyOnJKmcry+6kCGDKcPnugNRWMS6kDze6fz1jlJVXxUEh5EdBgczKmoHq6FvVm5@gnusha.org
X-Gm-Message-State: AOJu0YxmKH7HfYu08x7hi8KyPSGiqbUvyafmeIYp7D1d7+4iL9HdoTrE
	0TIGXz1x1XANdfRBNHRcjGyT2ZvbNz/ISPwflC2bt21UZD5LJ7Jj
X-Google-Smtp-Source: AGHT+IHomtUmOMxX35lRc5KC391an86B8rM3fIr0YKgQjVZpJgUFRsDTtQLRFfM3bGxM1pIecAIbIw==
X-Received: by 2002:a05:6214:2421:b0:6e8:8934:337e with SMTP id 6a1803df08f44-6e90068453amr140817446d6.38.1741484609427;
        Sat, 08 Mar 2025 17:43:29 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVF142pxFi7oAG2xRAnFkiu3jacDuU9aHZEwLJZT9xP8zQ==
Received: by 2002:a05:6214:5ec7:b0:6d8:f5b9:2be3 with SMTP id
 6a1803df08f44-6e8f4d85f57ls55912316d6.0.-pod-prod-07-us; Sat, 08 Mar 2025
 17:43:26 -0800 (PST)
X-Received: by 2002:a05:620a:86c1:b0:7c5:428a:bca8 with SMTP id af79cd13be357-7c5428abd88mr499963085a.56.1741484606622;
        Sat, 08 Mar 2025 17:43:26 -0800 (PST)
Received: by 2002:a05:620a:13d7:b0:7c0:bbff:9f72 with SMTP id af79cd13be357-7c3cd030f9ems85a;
        Sat, 8 Mar 2025 17:35:53 -0800 (PST)
X-Received: by 2002:a05:6214:1c0b:b0:6e8:9a55:8259 with SMTP id 6a1803df08f44-6e9005c1fb0mr120806586d6.9.1741484152799;
        Sat, 08 Mar 2025 17:35:52 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1741484152; cv=none;
        d=google.com; s=arc-20240605;
        b=bd3QmVesIuZWeYNgmFqZlTxryiLQEvDh2rF6YLwDLB9SGZbNZa7onafPvGSVDWXaNE
         7zHV5650fRf7c8W/rqgBrkE4/5N/JK8PZbQ5zFpJL4Qc/H8IScO18hKlfwcmUopAIPl6
         wVS3K46mNdpX2uN1ocovnGle7J16c7iQKdOb7ityCSByNs8ZcrdkndG0zrvr4FhgXlB2
         aaWJ8vRhp+PatiPRAk4JsTwf7iS1x8IzFPI3sjTp7EABzwHiIQxs2RKI1P37tmvg1zcY
         DNHUt/ZeKNyqPXKhrBWbPWDxnsmmpSjM8Dqz5xzCcPEV8Lc7yAI3NHRpmyXDJAkSVLOh
         WqtQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=wCWSlA68m5UZPyxr0OILa13Tp02gOZwms5CqctAoX6U=;
        fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=;
        b=Lf3quckF9smWl+59MATNpKDwoWU5+qQRZ2DNTtjmsu9agTz3oKUJeAi9dIEHyQkW3b
         qRMMr09+VcB3Eqa9u2w2P5EHDBpd1R7Br9HDBp8fZ3NcQ/7/GraoAV4gq43wpxYWN0SE
         UKRWWf+PHBqoFDhsumoS+VyeS4HiN4WYWNY2Q6iF1rm5dQ5YPNIw0q2FjexnfZRPre+m
         Trs/sKtzsPAMCxlGN4R9TJQj8+tgVHKVBHZxfqr8uQtJ7lYfx/UjgGDtUOuYIaBqD9fp
         OVbKuVYc9wVleuAM/xU1mSlRlhXyEt7Wvw2yBjx8URHq+H/kYflTWKkF/SBXvz5+4iR9
         C0hg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=kqBPNQz0;
       spf=pass (google.com: domain of nighttimesatoshi@gmail.com designates 2607:f8b0:4864:20::a32 as permitted sender) smtp.mailfrom=nighttimesatoshi@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com. [2607:f8b0:4864:20::a32])
        by gmr-mx.google.com with ESMTPS id 6a1803df08f44-6e8f716862dsi2605706d6.8.2025.03.08.17.35.52
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 08 Mar 2025 17:35:52 -0800 (PST)
Received-SPF: pass (google.com: domain of nighttimesatoshi@gmail.com designates 2607:f8b0:4864:20::a32 as permitted sender) client-ip=2607:f8b0:4864:20::a32;
Received: by mail-vk1-xa32.google.com with SMTP id 71dfb90a1353d-523df743d05so77598e0c.2
        for <bitcoindev@googlegroups.com>; Sat, 08 Mar 2025 17:35:52 -0800 (PST)
X-Gm-Gg: ASbGncvNoWr1uhbdznaVjKSbxmZX0AVR3X7Ihd67E5F35IQm1m3rlrWBVAHgXL8YMT2
	6rSNjTFff/JSA9iBlJ0+hBqIpFpnYQw2nMEDuVsXuFZQZtOeqfFwoPgnXthgtRoYN7uUZbNGeb8
	kY1uuNC1rfZPLgGoAdB5YnfFiT
X-Received: by 2002:a05:6122:8c15:b0:520:579d:893c with SMTP id
 71dfb90a1353d-523f3d6569cmr609655e0c.1.1741484152163; Sat, 08 Mar 2025
 17:35:52 -0800 (PST)
MIME-Version: 1.0
References: <62b454f8-56be-4eae-ba3e-57c53d493f3dn@googlegroups.com> <w6yVRkZu07vMNHYp483katPNPA5nwFEx-kje8eSpjRl9S6O8rx_ViKi62XlcW2b36SF8dceUXKkBLrmrtvK7RuPd1w1y0iZ4BBP4rSleNcc=@wuille.net>
In-Reply-To: <w6yVRkZu07vMNHYp483katPNPA5nwFEx-kje8eSpjRl9S6O8rx_ViKi62XlcW2b36SF8dceUXKkBLrmrtvK7RuPd1w1y0iZ4BBP4rSleNcc=@wuille.net>
From: Nighttime Satoshi <nighttimesatoshi@gmail.com>
Date: Sat, 8 Mar 2025 19:35:41 -0600
X-Gm-Features: AQ5f1JoYNdC4-jfBFQ8mtoNGPhjxrE2CxhYVL0I4EKo3EddKcjZgd5eIecHBn4A
Message-ID: <CALQsJZX=6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees
To: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000459b47062fdee028"
X-Original-Sender: nighttimesatoshi@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=kqBPNQz0;       spf=pass
 (google.com: domain of nighttimesatoshi@gmail.com designates
 2607:f8b0:4864:20::a32 as permitted sender) smtp.mailfrom=nighttimesatoshi@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.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 (/)

--000000000000459b47062fdee028
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=99s 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=E2=80=AFPM Pieter Wuille <bitcoin-dev@wuille.ne=
t> 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 b=
e
> 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.
>
>

--=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/=
CALQsJZX%3D6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ%40mail.gmail.com.

--000000000000459b47062fdee028
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Pieter,<div><br></div><div>You&#39;re absolutely right.=
 You&#39;ve raised valid technical concerns about my original proposal rega=
rding coinbase limitations and soft fork requirements. Based on your points=
, I&#39;ve reconsidered the implementation approach to ensure it works as a=
 proper soft fork. Here&#39;s the revised mechanism. I&#39;m curious to hea=
r your thoughts:</div><div><br></div><div>The basic premise is that dust UT=
XOs are a deadweight loss to the Bitcoin Network - and we must find a solut=
ion at the L1 level that can &quot;revive&quot; these dust satoshis back in=
to the network at their full value, in order to improve Bitcoin&#39;s fungi=
bility. This dust problem will only get more significant, and I don&#39;t t=
hink the deflationary effect of lost satoshis is more valuable than the pro=
spect of full fungibility. L2 solutions are a bandaid.=C2=A0<br><br><b>Amen=
dments</b>:</div><div><b><br></b></div><div><b>1. Coinbase Transaction Inpu=
ts:<br></b><strong style=3D"color:rgb(0,0,0)"><br></strong></div><div><span=
 style=3D"color:rgb(0,0,0)"><b>Concern</b>:=C2=A0</span><span style=3D"colo=
r:rgb(0,0,0)">Coinbase transactions can only have exactly one input. Allowi=
ng coinbase transactions to spend additional outputs would require a hard f=
ork.</span><br></div><div><p style=3D"color:rgb(0,0,0)"><strong>Revised Sol=
ution:</strong><span class=3D"gmail-Apple-converted-space">=C2=A0</span>Wha=
t if miners claim authorized dust UTXOs through entirely separate, regular,=
 standard-format transactions? Though not economically=C2=A0feasible for si=
ngle transactions, it becomes extremely beneficial economically when batchi=
ng 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 constrai=
nts.</p><p style=3D"color:rgb(0,0,0)"><b>2. Spending Dust Outputs Without O=
riginal Conditions</b></p><p style=3D"color:rgb(0,0,0)"><strong>Concern:=C2=
=A0</strong>The dust outputs marked for claiming by miners can&#39;t curren=
tly be spent without fulfilling their original conditions, which would requ=
ire a hard fork to change.</p><p style=3D"color:rgb(0,0,0)"><strong>Revised=
 Solution:</strong><span class=3D"gmail-Apple-converted-space">=C2=A0</span=
>What if miners are permitted to spend dust UTXOs without their original co=
nditions<span class=3D"gmail-Apple-converted-space">=C2=A0</span><strong>on=
ly under strictly defined new rules:</strong></p><p style=3D"color:rgb(0,0,=
0)"><b>*=C2=A0</b>The dust UTXO must be explicitly authorized for miner spe=
nding through an OP_RETURN-based &quot;Dust Fee Authorization&quot; (DFA) t=
ransaction.</p><p style=3D"color:rgb(0,0,0)">*The miner=E2=80=99s transacti=
on claiming this dust must occur in the exact same block as the DFA transac=
tion.</p><p style=3D"color:rgb(0,0,0)">*Only dust UTXOs below a clearly def=
ined threshold (546 sats) are eligible.</p><p style=3D"color:rgb(0,0,0)">Th=
ese new consensus rules<span class=3D"gmail-Apple-converted-space">=C2=A0</=
span><strong>strictly restrict</strong><span class=3D"gmail-Apple-converted=
-space">=C2=A0</span>previously impossible spending conditions, making it u=
nequivocally a valid soft fork. No previously illegal behavior is permitted=
 without new restrictive conditions explicitly met.</p><p style=3D"color:rg=
b(0,0,0)"><b>3. Economic and Practical Viability<br></b></p><p style=3D"col=
or:rgb(0,0,0)"><strong>Concern:=C2=A0</strong>The economic overhead (OP_RET=
URN transaction plus coinbase input overhead) might be larger than simply s=
pending the dust normally.</p><p style=3D"color:rgb(0,0,0)"><strong>Revised=
 Solution:</strong><span class=3D"gmail-Apple-converted-space">=C2=A0</span=
>With coinbase inputs no longer altered, the overhead is significantly redu=
ced. Furthermore, the revised mechanism explicitly encourages batching mult=
iple dust authorizations into a single DFA transaction, dramatically amorti=
zing overhead costs across many dust UTXOs. This batching substantially imp=
roves economic viability, especially during periods of lower mempool conges=
tion where fees are minimal.</p><p style=3D"color:rgb(0,0,0)">Does this des=
ign=C2=A0address your concerns while preserving the original goal of volunt=
ary, secure, and economically rational reclamation of dust UTXOs?<br></p><p=
 style=3D"color:rgb(0,0,0)">Your insights have been invaluable. I&#39;m eag=
er to receive any further feedback on this revised design.</p><p style=3D"c=
olor:rgb(0,0,0)">Thank you again for your careful review and helpful critiq=
ue.</p><p style=3D"color:rgb(0,0,0)">Best regards,</p></div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 8, =
2025 at 5:49=E2=80=AFPM Pieter Wuille &lt;<a href=3D"mailto:bitcoin-dev@wui=
lle.net" target=3D"_blank">bitcoin-dev@wuille.net</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex">Hello,<br>
<br>
This is not a soft fork, for two reasons:<br>
<br>
* Coinbase transactions can only have exactly one input. I don&#39;t think =
there is a particularly good reason for this besides simplicity, but that i=
s the current rule. Allowing a coinbase transaction to additionally also sp=
end certain outputs would require a hardfork.<br>
<br>
* The outputs being marked as dust are not allowed to be spent by miners. C=
hanging this requires a hardfork as well. Think about it: if this was possi=
ble with a softfork, it must mean that doing what you&#39;re proposing woul=
d *already be legal* today, and thus not need this proposed change in the f=
irst place. Softforks can only outlaw formerly legal behavior.<br>
<br>
Furthermore, I don&#39;t really see the point. The proposal requires both a=
 coinbase txin to spend the coin, plus a signature in a separate transactio=
n, in the same block. To pay the miner for the opportunity cost of not incl=
uding normal transactions with these bytes, the fee for this OP_RETURN outp=
ut should economically be priced at the block&#39;s feerate for the size of=
 the OP_RETURN output *plus* the cost of the coinbase transaction input. To=
gether, they are no smaller (and with witness discount, I suspect larger) t=
han the user just spending their &quot;dust&quot; output, and thus the fee =
for using this OP_RETURN-based mechanism would be larger than the value of =
the dust output.<br>
<br>
-- <br>
Pieter<br>
<br>
On Saturday, March 8th, 2025 at 1:23 PM, Nighttime Satoshi &lt;<a href=3D"m=
ailto:nighttimesatoshi@gmail.com" target=3D"_blank">nighttimesatoshi@gmail.=
com</a>&gt; wrote:<br>
<br>
&gt; Dear fellow Bitcoin developers,<br>
&gt; <br>
&gt; I&#39;m excited to share a proposal addressing a long-standing Bitcoin=
 challenge: economically unviable dust UTXOs.<br>
<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/CALQsJZX%3D6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CALQsJZX%3D6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ%40ma=
il.gmail.com</a>.<br />

--000000000000459b47062fdee028--