From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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> In-Reply-To: From: Nighttime Satoshi Date: Sat, 8 Mar 2025 19:35:41 -0600 X-Gm-Features: AQ5f1JoYNdC4-jfBFQ8mtoNGPhjxrE2CxhYVL0I4EKo3EddKcjZgd5eIecHBn4A Message-ID: Subject: Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees To: Pieter Wuille Cc: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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
Hi Pieter,

You're absolutely right.= You've raised valid technical concerns about my original proposal rega= rding 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 hea= r your thoughts:

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 "revive" these dust satoshis back in= to the network at their full value, in order to improve Bitcoin's fungi= bility. This dust problem will only get more significant, and I don'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

Amen= dments:

1. Coinbase Transaction Inpu= ts:

Concern:=C2=A0Coinbase transactions can only have exactly one input. Allowi= ng coinbase transactions to spend additional outputs would require a hard f= ork.

Revised Sol= ution:=C2=A0Wha= 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.

2. Spending Dust Outputs Without O= riginal Conditions

Concern:=C2= =A0The dust outputs marked for claiming by miners can't curren= tly be spent without fulfilling their original conditions, which would requ= ire a hard fork to change.

Revised= Solution:=C2=A0What if miners are permitted to spend dust UTXOs without their original co= nditions=C2=A0on= ly under strictly defined new rules:

*=C2=A0The dust UTXO must be explicitly authorized for miner spe= nding through an OP_RETURN-based "Dust Fee Authorization" (DFA) t= ransaction.

*The miner=E2=80=99s transacti= on claiming this dust must occur in the exact same block as the DFA transac= tion.

*Only dust UTXOs below a clearly def= ined threshold (546 sats) are eligible.

Th= ese new consensus rules=C2=A0strictly restrict=C2=A0previously impossible spending conditions, making it u= nequivocally a valid soft fork. No previously illegal behavior is permitted= without new restrictive conditions explicitly met.

3. Economic and Practical Viability

Concern:=C2=A0The economic overhead (OP_RET= URN transaction plus coinbase input overhead) might be larger than simply s= pending the dust normally.

Revised= Solution:=C2=A0With 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.

Does this des= ign=C2=A0address your concerns while preserving the original goal of volunt= ary, secure, and economically rational reclamation of dust UTXOs?

Your insights have been invaluable. I'm eag= er to receive any further feedback on this revised design.

Thank you again for your careful review and helpful critiq= ue.

Best regards,


On Sat, Mar 8, = 2025 at 5:49=E2=80=AFPM Pieter Wuille <bitcoin-dev@wuille.net> wrote:
<= 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,

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 i= s the current rule. Allowing a coinbase transaction to additionally also sp= end certain outputs would require a hardfork.

* 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'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.

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 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'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 "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 &= 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/bitcoindev/CALQsJZX%3D6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ%40ma= il.gmail.com.
--000000000000459b47062fdee028--