1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
|
Delivery-date: Wed, 25 Sep 2024 17:48:02 -0700
Received: from mail-yw1-f187.google.com ([209.85.128.187])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDAL7PXD4IKRBOO62K3QMGQEXEILNIQ@googlegroups.com>)
id 1stcfp-0003Iu-Rj
for bitcoindev@gnusha.org; Wed, 25 Sep 2024 17:48:02 -0700
Received: by mail-yw1-f187.google.com with SMTP id 00721157ae682-6e000d68bb1sf19039217b3.1
for <bitcoindev@gnusha.org>; Wed, 25 Sep 2024 17:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1727311675; x=1727916475; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=HMMXJxy5Yqh2V2qiL07rq3FHA6HvvNb1vZLrzvSike4=;
b=Qmimr9lSdlc50qXOqQU5k+r/v6JXd5QO2aO31M81o3V8k4CveD5wTXk/dL1cHKzZ6J
61+b2cmcwslwwUe0MqtOq47SoafETfNe3CZfywIihAWIO1TzfAGZyA+yPlYfuk5FYuWB
tSKIcFkmjkaSKOEoZSRc4h0uSPQQ1ubNCwRknPvdKAqP51KeUIYjg6DAbFB1b9XSugZJ
AHuFQYmxoC6p/1C16xz2L8aUv2TiVRL0k3CzbX0V81YhOvOeacr0Un6B9STzo6mBcwNd
LwpGeVv08/KaGF5KqP9EpcY4gBUPGDlkC5fqPPA3bXEtC3F/FZKFwWZ2HAKo4gnJvGf+
B3aw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1727311675; x=1727916475; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:from:to:cc:subject:date:message-id
:reply-to;
bh=HMMXJxy5Yqh2V2qiL07rq3FHA6HvvNb1vZLrzvSike4=;
b=HkufrMaJxyJ2EVxaDyT8W60ZyehjWUK7NY7zKPg2D++NK6JeP0DrhihJeP7eNo3drL
1kfMZ7PPUh79WjxsjT3Qg/SpsiB1dhG3UyKwUDx46oF0lzDpE0a0tJ8Soqnynm0AIkcZ
+HCCV9Gtziy749VJhql0bubci0GMDgTuCpke83pLN55IfTsTBQcIjQK6XXR9dJrQQLvh
bx2xqlAuZQz6jBxXpO3sxL7Ub9VquhQYPBT3Av5GVqtCkGuq30NTMAsWChmSQIOQW+9R
NjmwvzsTaqNNAlxMDj6O4IGBppzcJshkiMd4fapNHWt03e1oKvI+mk06OpBo8ohKK6OO
WDfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1727311675; x=1727916475;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=HMMXJxy5Yqh2V2qiL07rq3FHA6HvvNb1vZLrzvSike4=;
b=SWwIhtciawo2dkUWJdzb8gZh9DJ+cXVQam6CKWstpVJlQidvMCEoFcfX97ivyx+R77
DHyO1vH0C31kla5TuWdg4wRRwdLRwzPvvb/dDZXqTZx+KwIIG6Sd8uoCUGR2NfvzZtiu
Wisqjkt+ZUeZmul7TQVULeHf8m8k8DepdPlAkj4xYZEnTenLVww9vLhfbP+sYC2QhejF
1UylTW7nhvXJlfVJHl5v+P/EYM/XvEhQNKVRXq329ad/rwDxiX4MvK7j1bt/nTP4T7SM
DyjkujuprFx+zd7ZoSgLalBIaYKjC7vxUscc1Gm2/fKWPFiDvrzh9t8GxoDpdysiJEkT
SWGg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCW3kir6h2iqsKUv89KDXYbJLXF/sjxETUtgdyNVwMHiAfI3eswpDkgtyAX/dyFHH3Fs1tOXHcDf+g8n@gnusha.org
X-Gm-Message-State: AOJu0YwrDNNwYzMC9YkOXczKJZ1H+X190rTNT/MZw2nMdpQY1i0WNcEl
1sO04NyTmhwekp5NaxSgLb/glfdgtCMaYBaC2F2ta97FSXzb1BOZ
X-Google-Smtp-Source: AGHT+IFSHr5vIzuaGP8dhUYV4UtzcANH+3LW+3YFNyXEDOzaW2kth+onnYSMcp1019IN4n+gcxf+DQ==
X-Received: by 2002:a05:6902:2284:b0:e20:2da6:ed88 with SMTP id 3f1490d57ef6-e25ca97936dmr1175971276.24.1727311675160;
Wed, 25 Sep 2024 17:47:55 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:5f47:0:b0:e1a:87fe:363e with SMTP id 3f1490d57ef6-e25c9f7f81als65375276.0.-pod-delta-02-us;
Wed, 25 Sep 2024 17:47:53 -0700 (PDT)
X-Received: by 2002:a05:690c:83:b0:695:e4b0:10ce with SMTP id 00721157ae682-6e21d9d4e63mr20557347b3.7.1727311672967;
Wed, 25 Sep 2024 17:47:52 -0700 (PDT)
Received: by 2002:a81:ad0c:0:b0:6e2:1e5e:a1e1 with SMTP id 00721157ae682-6e21f46d647ms7b3;
Wed, 25 Sep 2024 17:44:48 -0700 (PDT)
X-Received: by 2002:a05:690c:6d89:b0:6db:d221:b739 with SMTP id 00721157ae682-6e22edd31famr11043937b3.10.1727311487562;
Wed, 25 Sep 2024 17:44:47 -0700 (PDT)
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"
X-Original-Sender: jamesfergusonch@gmail.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 (/)
------=_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" 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--
|
