Delivery-date: Wed, 25 Sep 2024 18:30:06 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.40.22 as permitted sender) client-ip=185.70.40.22;
Date: Thu, 26 Sep 2024 01:22:54 +0000
To: James Ferguson <jamesfergusonch@gmail.com>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] OP_KEEPCHANGE - mitigating dust outputs
Message-ID: <4_re7EWb0zy-E_Yk472AGf4WwgwxO9XCC1Y2RqYGlCV7FXpbq1ifIe-DL93-y5erlsAO_G-27SzLcFhGq9kDs8KNE0u2GSC24cFV-rJ5X10=@wuille.net>
In-Reply-To: <83296012-d713-482a-ad7a-3fd9bf7cded9n@googlegroups.com>
References: <83296012-d713-482a-ad7a-3fd9bf7cded9n@googlegroups.com>
Feedback-ID: 19463299:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_kmeEJtrIi3ZyAj7zc4QjTONVDzvpCZdy05JmaOHmY6A"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

This is a multi-part message in MIME format.

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

Hi James,

I believe you're imagining that Bitcoin works very differently from how it =
actually does. Comments below inline.

On Wednesday, September 25th, 2024 at 8:44 PM, James Ferguson <jamesferguso=
nch@gmail.com> wrote:

> Introduction of provisionally named "OP_KEEPCHANGE" allows small residual=
 UTXO (change) to be automatically credited to the primary recipient=E2=80=
=99s address.

Bitcoin doesn't have a concept of address balances at the protocol level, o=
r even addresses at all, let alone a "primary recipient address". Balances =
you see in wallets and blockchain explorers simply report the sum of the va=
lues of UTXOs under control of a given address, but this is a local interpr=
etation made by that software; the protocol itself does not know or care ab=
out these things.

The way to "credit an address" in Bitcoin is literally to create a UTXO loc=
ked with (the script corresponding to) the address in question, so barring =
an extremely invasive overhaul of how the entire protocol works, there isn'=
t actually any UTXO set size benefit to this proposal - change UTXOs would =
still need to be created. In addition, if your proposal requires revealing =
what the recipient of a payment is (as "crediting primary recipient" implie=
s), it would necessarily also undo the primary privacy benefit of having a =
UTXO model in the first place: today, one cannot generally tell which outpu=
t of a transaction is the payee, and this is by design.

Of course, a hypothetical proposal could change anything about Bitcoin's de=
sign if it were to have enough support. If the Bitcoin ecosystem really wan=
ted an address balance model, nothing prevents the introduction of that. In=
 that case, there is no point to have UTXOs, or change, at all. Just make t=
ransaction deduct some address balances, and credit some others directly. T=
his removes many of the issues you seem to want to address much more direct=
ly (including coin selection, dust accumulation, UTXO set growth to some ex=
tent, and many more, while adding other complications in other places, of c=
ourse). However, it would also massively hurt privacy, as there would be an=
 on-chain cost to creating new addresses/balances, incentivizing keeping on=
e's funds in just one. The current UTXO model does not care about the disti=
nction between payments and change and this is very much desirable: sending=
 your change to a new change address with pristine history costs exactly th=
e same as sending it back to the address the spend coins were assigned to.

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

But it does so at the cost of incentivizing not transitioning to a new addr=
ess on every transaction, a huge privacy leak.

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

Change does not exist at the protocol level. It is just an output like any =
normal payment output, and indistinguishable from it. The protocol also has=
 no knowledge of excess - that is a concept purely local to the sender wall=
et. It chooses=E2=80=8B to add an output back to itself, to balance the amo=
unts in the inputs with the amounts in the outputs (minus fee). At the very=
 least your proposal would require a way to signal how much to send back, a=
nd to where (remember that multiple parties can cooperate to jointly constr=
uct a single transaction!). At this point you're not far off from just havi=
ng another output...

Cheers,

--
Pieter

--=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/4_re7EWb0zy-E_Yk472AGf4WwgwxO9XCC1Y2RqYGlCV7FXpbq1ifIe-DL93-y5er=
lsAO_G-27SzLcFhGq9kDs8KNE0u2GSC24cFV-rJ5X10%3D%40wuille.net.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0=
, 0, 0); background-color: rgb(255, 255, 255);">Hi James,</div><div style=
=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); b=
ackground-color: rgb(255, 255, 255);"><br></div><div style=3D"font-family: =
Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: =
rgb(255, 255, 255);">I believe you're imagining that Bitcoin works very dif=
ferently from how it actually does. Comments below inline.<br></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><=
div class=3D"protonmail_quote">
        On Wednesday, September 25th, 2024 at 8:44 PM, James Ferguson &lt;j=
amesfergusonch@gmail.com&gt; wrote:</div><div class=3D"protonmail_quote"><b=
r></div><div class=3D"protonmail_quote">
        <blockquote class=3D"protonmail_quote" type=3D"cite"><div>Introduct=
ion of provisionally named  "OP_KEEPCHANGE" allows small residual UTXO (cha=
nge) to be automatically credited to the primary recipient=E2=80=99s addres=
s.</div></blockquote><div style=3D"font-family: Arial, sans-serif; font-siz=
e: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></=
div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: r=
gb(0, 0, 0); background-color: rgb(255, 255, 255);">Bitcoin doesn't have a =
concept of address balances at the protocol level, or even addresses at all=
, let alone a "primary recipient address". Balances you see in wallets and =
blockchain explorers simply report the sum of the values of UTXOs under con=
trol of a given address, but this is a local interpretation made by that so=
ftware; the protocol itself does not know or care about these things.</div>=
<div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0=
, 0, 0); background-color: rgb(255, 255, 255);"><br></div><div style=3D"fon=
t-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgrou=
nd-color: rgb(255, 255, 255);">The way to "credit an address" in Bitcoin is=
 literally to create a UTXO locked with (the script corresponding to) the a=
ddress in question, so barring an extremely invasive overhaul of how the en=
tire protocol works, there isn't actually any UTXO set size benefit to this=
 proposal - change UTXOs would still need to be created. In addition, if yo=
ur proposal requires revealing what the recipient of a payment is (as "cred=
iting primary recipient" implies), it would necessarily also undo the prima=
ry privacy benefit of having a UTXO model in the first place: today, one ca=
nnot generally tell which output of a transaction is the payee, and this is=
 by design.<br></div><div style=3D"font-family: Arial, sans-serif; font-siz=
e: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></=
div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: r=
gb(0, 0, 0); background-color: rgb(255, 255, 255);">Of course, a hypothetic=
al proposal could change anything about Bitcoin's design if it were to have=
 enough support. If the Bitcoin ecosystem really wanted an address balance =
model, nothing prevents the introduction of that. In that case, there is no=
 point to have UTXOs, or change, at all. Just make transaction deduct some =
address balances, and credit some others directly. This removes many of the=
 issues you seem to want to address much more directly (including coin sele=
ction, dust accumulation, UTXO set growth to some extent, and many more, wh=
ile adding other complications in other places, of course). However, it wou=
ld also massively hurt privacy, as there would be an on-chain cost to creat=
ing new addresses/balances, incentivizing keeping one's funds in just one. =
The current UTXO model does not care about the distinction between payments=
 and change and this is very much desirable: sending your change to a new c=
hange address with pristine history costs exactly the same as sending it ba=
ck to the address the spend coins were assigned to.<br></div><div style=3D"=
font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backg=
round-color: rgb(255, 255, 255);"><br></div><blockquote class=3D"protonmail=
_quote" type=3D"cite"><div>b) Enhanced Privacy: . <br></div><div>This provi=
des a slight improvement in transaction privacy by obfuscating the typical =
patterns used to identify change outputs.</div></blockquote><div style=3D"f=
ont-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgr=
ound-color: rgb(255, 255, 255);"><br></div><div style=3D"font-family: Arial=
, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(2=
55, 255, 255);">But it does so at the cost of incentivizing not transitioni=
ng to a new address on every transaction, a huge privacy leak.</div><div st=
yle=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0)=
; background-color: rgb(255, 255, 255);"><br></div><blockquote class=3D"pro=
tonmail_quote" type=3D"cite"><div>- When used in a transaction, `OP_KEEPCHA=
NGE` signals that any excess change be added to the primary output instead =
of generating a separate change output.</div></blockquote><div style=3D"fon=
t-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgrou=
nd-color: rgb(255, 255, 255);"><br></div><div style=3D"font-family: Arial, =
sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255=
, 255, 255);">Change does not exist at the protocol level. It is just an ou=
tput like any normal payment output, and indistinguishable from it. The pro=
tocol also has no knowledge of excess - that is a concept purely local to t=
he sender wallet. It <b>chooses</b>=E2=80=8B to add an output back to itsel=
f, to balance the amounts in the inputs with the amounts in the outputs (mi=
nus fee). At the very least your proposal would require a way to signal how=
 much to send back, and to where (remember that multiple parties can cooper=
ate to jointly construct a single transaction!). At this point you're not f=
ar off from just having another output...</div></div><div class=3D"protonma=
il_quote" style=3D"font-family: Arial, sans-serif; font-size: 14px; color: =
rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><div class=
=3D"protonmail_quote" style=3D"font-family: Arial, sans-serif; font-size: 1=
4px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Cheers,</d=
iv><div class=3D"protonmail_quote" style=3D"font-family: Arial, sans-serif;=
 font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255)=
;"><br></div><div class=3D"protonmail_quote" style=3D"font-family: Arial, s=
ans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255,=
 255, 255);">-- <br></div><div class=3D"protonmail_quote" style=3D"font-fam=
ily: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-co=
lor: rgb(255, 255, 255);">Pieter</div><div class=3D"protonmail_quote" style=
=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); b=
ackground-color: rgb(255, 255, 255);"><br></div><div class=3D"protonmail_qu=
ote">
    </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/4_re7EWb0zy-E_Yk472AGf4WwgwxO9XCC1Y2RqYGlCV7FXpbq1ifI=
e-DL93-y5erlsAO_G-27SzLcFhGq9kDs8KNE0u2GSC24cFV-rJ5X10%3D%40wuille.net?utm_=
medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitco=
indev/4_re7EWb0zy-E_Yk472AGf4WwgwxO9XCC1Y2RqYGlCV7FXpbq1ifIe-DL93-y5erlsAO_=
G-27SzLcFhGq9kDs8KNE0u2GSC24cFV-rJ5X10%3D%40wuille.net</a>.<br />

--b1_kmeEJtrIi3ZyAj7zc4QjTONVDzvpCZdy05JmaOHmY6A--