Delivery-date: Wed, 25 Sep 2024 17:48:02 -0700
Sender: bitcoindev@googlegroups.com
Date: Wed, 25 Sep 2024 17:44:47 -0700 (PDT)
From: James Ferguson <jamesfergusonch@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <83296012-d713-482a-ad7a-3fd9bf7cded9n@googlegroups.com>
Subject: [bitcoindev] OP_KEEPCHANGE - mitigating dust outputs
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_238722_1083220999.1727311487133"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_238722_1083220999.1727311487133
Content-Type: multipart/alternative; 
	boundary="----=_Part_238723_491381663.1727311487133"

------=_Part_238723_491381663.1727311487133
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My first post to list - Hi
- tell me if I am in the wrong place or following idea is absurd=20
- otherwise please onboard me towards adding value (tell me when I've=20
overlooked standards etc)

So, at risk of proving foolish  - I think I may have a novel and useful=20
idea (did some searches and found nothing).

best James

Title: "Keep the Change" dust mitigation

Category:** Consensus (Soft Fork  - I think)

*Abstract *

Introduction of provisionally named  "OP_KEEPCHANGE" allows small residual=
=20
UTXO (change) to be automatically credited to the primary recipient=E2=80=
=99s=20
address.
 =20
This aims to reduce inefficiencies associated with the creation of dust=20
outputs, reduce bloat, improve transaction efficiency, and optimise network=
=20
performance by minimising the accumulation of tiny un-spendable UTXO.

*Motivation*

When a user sends Bitcoin, any leftover amount is typically returned to a=
=20
change address controlled by the sender.=20
If this leftover amount is sufficiently small (dust) it is not economically=
=20
spendable, representing a small reduction in the money supply.

This causes problems:

- UTXO bloat:  More UTXOs mean a larger blockchain size, increasing storage=
=20
and bandwidth requirements for nodes and threatens decentralisation.
- Higher transaction fees: Dust outputs, when combined in future=20
transactions, increase the transaction size, leading to higher fees.
- Inefficient use of UTXOs: Managing numerous small change outputs makes=20
transaction construction more complex and potentially inefficient.

OP_KEEPCHANGE mitigates these issues while offering additional secondary=20
benefits:

a) Prevention of Value Erosion:=20
When transferring funds between wallets owned by the same party, small=20
change amounts can lead to minor value erosion due to repeated fees and=20
inefficiencies.
This proposal eliminates such erosion by crediting the residual amount to=
=20
the recipient wallet.

b) Enhanced Privacy: .=20
This provides a slight improvement in transaction privacy by obfuscating=20
the typical patterns used to identify change outputs.

c) Mitigation of Money Supply Reduction:=20
As dust UTXOs accumulate over time and become economically unspendable,=20
they effectively reduce the Bitcoin money supply.
This proposal helps mitigate a calculable reduction in the overall Bitcoin=
=20
supply, preserving value and improving the network=E2=80=99s long-term=20
sustainability.

d) Recipient Benefit A provider (eg a merchant) accepting bitcoin or  fiat=
=20
exchange users buying bitcoin (especially small sums after DCA'ing) gain a=
=20
small proportional uplift in revenues at no cost to the sender)

f) Reduction in dust threshold: In so far as transaction costs are reduced=
=20
a small reduction in the dust threshold is thereby achieved

g) Equitable with positive feedback : By reducing dust UTXO size increases=
=20
- larger UTXO makes for lower default dust - All users benefit from reduced=
=20
dust whether they make further OP_KEEPCHANGE transactions or not

*High Level Specification Outline*

- Introduce  OP_KEEPCHANGE=20

- Assume some dust threshold (XXX satoshis)  configurable by wallet user

- During input UTXO selection to transfer some value, a wallet or user=20
seeks the minimum change value that would normally be generated as a return=
=20
UTXO. This involves by judicious input UTXO selection.=20
If this is below the dust threshold a transaction can be marked with=20
OP_KEEPCHANGE

- When used in a transaction, `OP_KEEPCHANGE` signals that any excess=20
change be added to the primary output instead of generating a separate=20
change output.=20

Instead of funding eternally useless UTXOs the recipient=E2=80=99s output i=
s=20
increased by this amount.

*Summary*

By implementing this fairly simple backwardly compatible mechanism, the=20
Bitcoin network can achieve greater efficiency, decentralisation, cost=20
savings, and improved privacy for its users while maintaining a healthier=
=20
and more predictable money supply.

--=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 on the web visit https://groups.google.com/d/msgid/=
bitcoindev/83296012-d713-482a-ad7a-3fd9bf7cded9n%40googlegroups.com.

------=_Part_238723_491381663.1727311487133
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>My first post to list - Hi</div><div>- tell me if I am in the wrong pl=
ace or following idea is absurd=C2=A0<br /></div><div>- otherwise please on=
board me towards adding value (tell me when I've overlooked standards etc)<=
/div><div><br /></div><div>So, at risk of proving foolish=C2=A0 - I think I=
 may have a novel and useful idea (did some searches and found nothing).</d=
iv><div><br /></div><div>best James</div><div><br /></div><div>Title:=C2=A0=
"Keep the Change" dust mitigation<br /></div><div><br /></div><div>Category=
:**=C2=A0Consensus (Soft Fork=C2=A0 - I think)<br /></div><div><br /></div>=
<b>Abstract </b><br /><br />Introduction of provisionally named =C2=A0"OP_K=
EEPCHANGE" allows small residual UTXO (change) to be automatically credited=
 to the primary recipient=E2=80=99s address.<div>=C2=A0 <br />This aims to =
reduce inefficiencies associated with the creation of dust outputs, reduce =
bloat, improve transaction efficiency, and optimise network performance by =
minimising the accumulation of tiny un-spendable UTXO.<br /><br /><b>Motiva=
tion</b><br /><br />When a user sends Bitcoin, any leftover amount is typic=
ally returned to a change address controlled by the sender. <br />If this l=
eftover amount is sufficiently small (dust) it is not economically spendabl=
e, representing a small reduction in the money supply.<br /><br />This caus=
es problems:<br /><br />- UTXO bloat: =C2=A0More UTXOs mean a larger blockc=
hain size, increasing storage and bandwidth requirements for nodes and thre=
atens decentralisation.<br />- Higher transaction fees: Dust outputs, when =
combined in future transactions, increase the transaction size, leading to =
higher fees.<br />- Inefficient use of UTXOs: Managing numerous small chang=
e outputs makes transaction construction more complex and potentially ineff=
icient.<br /><br />OP_KEEPCHANGE mitigates these issues while offering addi=
tional secondary benefits:<br /><br />a) Prevention of Value Erosion: <br /=
>When transferring funds between wallets owned by the same party, small cha=
nge amounts can lead to minor value erosion due to repeated fees and ineffi=
ciencies.<br />This proposal eliminates such erosion by crediting the resid=
ual amount to the recipient wallet.<br /><br />b) Enhanced Privacy: . <br /=
>This provides a slight improvement in transaction privacy by obfuscating t=
he typical patterns used to identify change outputs.<br /><br />c) Mitigati=
on of Money Supply Reduction: <br />As dust UTXOs accumulate over time and =
become economically unspendable, they effectively reduce the Bitcoin money =
supply.<br />This proposal helps mitigate a calculable reduction in the ove=
rall Bitcoin supply, preserving value and improving the network=E2=80=99s l=
ong-term sustainability.<br /><br />d) Recipient Benefit A provider (eg a m=
erchant) accepting bitcoin or =C2=A0fiat exchange users buying bitcoin (esp=
ecially small sums after DCA'ing) gain a small proportional uplift in reven=
ues at no cost to the sender)<br /><br />f) Reduction in dust threshold: In=
 so far as transaction costs are reduced a small reduction in the dust thre=
shold is thereby achieved</div><div><br /></div><div>g) Equitable with posi=
tive feedback : By reducing dust UTXO size increases - larger UTXO makes fo=
r lower default dust - All users benefit from reduced dust whether they mak=
e further OP_KEEPCHANGE transactions or not<br /><br /><b>High Level Specif=
ication Outline</b><br /><br />- Introduce=C2=A0 OP_KEEPCHANGE=C2=A0<br /><=
br />- Assume some dust threshold (XXX satoshis)=C2=A0 configurable by wall=
et user<br /><br />- During input UTXO selection to transfer some value, a =
wallet or user seeks the minimum change value that would normally be genera=
ted as a return UTXO. This involves by judicious input UTXO selection. <br =
/>If this is below the dust threshold a transaction can be marked with OP_K=
EEPCHANGE<br /><br />- When used in a transaction, `OP_KEEPCHANGE` signals =
that any excess change be added to the primary output instead of generating=
 a separate change output. <br /><br />Instead of funding eternally useless=
 UTXOs the recipient=E2=80=99s output is increased by this amount.<br /><br=
 /><b>Summary</b><br /><br />By implementing this fairly simple backwardly =
compatible mechanism, the Bitcoin network can achieve greater efficiency, d=
ecentralisation, cost savings, and improved privacy for its users while mai=
ntaining a healthier and more predictable money supply.<br /></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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/83296012-d713-482a-ad7a-3fd9bf7cded9n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/83296012-d713-482a-ad7a-3fd9bf7cded9n%40googlegroups.com</a>.=
<br />

------=_Part_238723_491381663.1727311487133--

------=_Part_238722_1083220999.1727311487133--