Delivery-date: Thu, 26 Sep 2024 02:47:04 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of jamesfergusonch@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) client-ip=2607:f8b0:4864:20::632;
MIME-Version: 1.0
References: <83296012-d713-482a-ad7a-3fd9bf7cded9n@googlegroups.com> <4_re7EWb0zy-E_Yk472AGf4WwgwxO9XCC1Y2RqYGlCV7FXpbq1ifIe-DL93-y5erlsAO_G-27SzLcFhGq9kDs8KNE0u2GSC24cFV-rJ5X10=@wuille.net>
In-Reply-To: <4_re7EWb0zy-E_Yk472AGf4WwgwxO9XCC1Y2RqYGlCV7FXpbq1ifIe-DL93-y5erlsAO_G-27SzLcFhGq9kDs8KNE0u2GSC24cFV-rJ5X10=@wuille.net>
Reply-To: james@kwiqly.com
From: James Ferguson <jamesfergusonch@gmail.com>
Date: Thu, 26 Sep 2024 11:05:01 +0200
Message-ID: <CABCM42TOD8fOJhy-1xEhGHiW3W9-MBnrhcHLOvsNwkjSiaG0VA@mail.gmail.com>
Subject: Re: [bitcoindev] OP_KEEPCHANGE - mitigating dust outputs
To: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000207b340623020a8c"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

Pieter

- Thank you, very helpful explanation

 So  suggestion sucks -  I withdraw it to avoid wasting others time !

However,  it seems dust benefits could be achieved simply by wallets
proposing dust roundup to recipient when creating the transaction rather
than providing a change output - It seems wallet providers could automate
this small benefit to be adopted with no protocol change.

So it fair to describe dust as a "tragedy of the commons" (wallets leave
value at small cost but no benefit) that bloats the time chain ?

Thanks for your assistance - I want to get into this but need to pick a
niche to grow initial understanding. - Suggestions welcome

Cheers, James


On Thu, 26 Sept 2024 at 03:23, Pieter Wuille <bitcoin-dev@wuille.net> wrote=
:

> Hi James,
>
> I believe you're imagining that Bitcoin works very differently from how i=
t
> actually does. Comments below inline.
>
> On Wednesday, September 25th, 2024 at 8:44 PM, James Ferguson <
> jamesfergusonch@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,
> or even addresses at all, let alone a "primary recipient address". Balanc=
es
> you see in wallets and blockchain explorers simply report the sum of the
> values of UTXOs under control of a given address, but this is a local
> interpretation made by that software; the protocol itself does not know o=
r
> care about these things.
>
> The way to "credit an address" in Bitcoin is literally to create a UTXO
> locked 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" implies), it would necessarily also undo the primary
> privacy benefit of having a UTXO model in the first place: today, one
> cannot generally tell which output of a transaction is the payee, and thi=
s
> is by design.
>
> Of course, a hypothetical 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 tha=
t.
> In that case, there is no point to have UTXOs, or change, at all. Just ma=
ke
> 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 selection, dust accumulation, UTXO set growth to
> some extent, and many more, while adding other complications in other
> places, of course). However, it would also massively hurt privacy, as the=
re
> would be an on-chain cost to creating new addresses/balances, incentivizi=
ng
> keeping one's funds in just one. The current UTXO model does not care abo=
ut
> the distinction between payments and change and this is very much
> desirable: sending your change to a new change address with pristine
> history costs exactly the same as sending it back to the address the spen=
d
> 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
> address on every transaction, a huge privacy leak.
>
> - 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.
>
>
> Change does not exist at the protocol level. It is just an output like an=
y
> normal payment output, and indistinguishable from it. The protocol also h=
as
> no knowledge of excess - that is a concept purely local to the sender
> wallet. It *chooses*=E2=80=8B to add an output back to itself, to balance=
 the
> amounts 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, and to where (remember that multiple parties can cooperate to joint=
ly
> construct a single transaction!). At this point you're not far off from
> just having 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/CABCM42TOD8fOJhy-1xEhGHiW3W9-MBnrhcHLOvsNwkjSiaG0VA%40mail.gmail=
.com.

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">Pie=
ter=C2=A0</div><div class=3D"gmail_default" style=3D"font-size:small"><br><=
/div><div class=3D"gmail_default" style=3D"font-size:small">- Thank you, ve=
ry helpful explanation=C2=A0</div><div class=3D"gmail_default" style=3D"fon=
t-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:sma=
ll">=C2=A0So=C2=A0 suggestion sucks -=C2=A0 I withdraw it to avoid wasting =
others time !</div><div class=3D"gmail_default" style=3D"font-size:small"><=
br></div><div class=3D"gmail_default" style=3D"font-size:small">However,=C2=
=A0 it seems dust benefits=C2=A0could be achieved simply by wallets proposi=
ng dust roundup to recipient=C2=A0when creating the transaction rather than=
 providing=C2=A0a change output - It seems wallet providers could automate =
this small benefit to be adopted with no protocol=C2=A0change.</div><div cl=
ass=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gma=
il_default" style=3D"font-size:small">So it fair to describe dust as a &quo=
t;tragedy of the commons&quot; (wallets leave value at small cost but=C2=A0=
no benefit) that bloats the time chain ?</div><div class=3D"gmail_default" =
style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"f=
ont-size:small">Thanks for your assistance - I want to get into this but ne=
ed to pick a niche to grow initial understanding. - Suggestions welcome</di=
v><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-size:small">Cheers, James</div><div clas=
s=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gmail=
_default" style=3D"font-size:small"><br></div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 26 Sept 2024 at 03:23=
, Pieter Wuille &lt;<a href=3D"mailto:bitcoin-dev@wuille.net">bitcoin-dev@w=
uille.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><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);background-col=
or:rgb(255,255,255)"><br></div><div style=3D"font-family:Arial,sans-serif;f=
ont-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">I believe=
 you&#39;re imagining that Bitcoin works very differently from how it actua=
lly does. Comments below inline.<br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
       =20
            </div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        On Wednesday, September 25th, 2024 at 8:44 PM, James Ferguson &lt;<=
a href=3D"mailto:jamesfergusonch@gmail.com" target=3D"_blank">jamesferguson=
ch@gmail.com</a>&gt; wrote:</div><div><br></div><div>
        <blockquote type=3D"cite"><div>Introduction of provisionally named =
 &quot;OP_KEEPCHANGE&quot; allows small residual UTXO (change) to be automa=
tically credited to the primary recipient=E2=80=99s address.</div></blockqu=
ote><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"font-family:=
Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,2=
55,255)">Bitcoin doesn&#39;t have a concept of address balances at the prot=
ocol level, or even addresses at all, let alone a &quot;primary recipient a=
ddress&quot;. Balances you see in wallets and blockchain explorers simply r=
eport the sum of the values of UTXOs under control of a given address, but =
this is a local interpretation made by that software; the protocol itself d=
oes not know or care about these things.</div><div style=3D"font-family:Ari=
al,sans-serif;font-size: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;c=
olor:rgb(0,0,0);background-color:rgb(255,255,255)">The way to &quot;credit =
an address&quot; in Bitcoin is literally to create a UTXO locked with (the =
script corresponding to) the address in question, so barring an extremely i=
nvasive overhaul of how the entire protocol works, there isn&#39;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 r=
ecipient of a payment is (as &quot;crediting primary recipient&quot; 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.<br></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"font-family:Arial,sans-ser=
if;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Of co=
urse, a hypothetical proposal could change anything about Bitcoin&#39;s des=
ign if it were to have enough support. If the Bitcoin ecosystem really want=
ed 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 tr=
ansaction deduct some address balances, and credit some others directly. Th=
is removes many of the issues you seem to want to address much more directl=
y (including coin selection, dust accumulation, UTXO set growth to some ext=
ent, and many more, while adding other complications in other places, of co=
urse). However, it would also massively hurt privacy, as there would be an =
on-chain cost to creating new addresses/balances, incentivizing keeping one=
&#39;s funds in just one. The current UTXO model does not care about the di=
stinction between payments and change and this is very much desirable: send=
ing your change to a new change address with pristine history costs exactly=
 the same as sending it back to the address the spend coins were assigned t=
o.<br></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><blockquote type=
=3D"cite"><div>b) Enhanced Privacy: . <br></div><div>This provides a slight=
 improvement in transaction privacy by obfuscating the typical patterns use=
d to identify change outputs.</div></blockquote><div style=3D"font-family:A=
rial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,25=
5,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)">But it does so at the =
cost of incentivizing not transitioning to a new address on every transacti=
on, a huge privacy leak.</div><div style=3D"font-family:Arial,sans-serif;fo=
nt-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div>=
<blockquote type=3D"cite"><div>- 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.</div></blockquote><div style=3D"font-f=
amily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb=
(255,255,255)"><br></div><div style=3D"font-family:Arial,sans-serif;font-si=
ze:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">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 o=
f excess - that is a concept purely local to the sender wallet. It <b>choos=
es</b>=E2=80=8B to add an output back to itself, to balance the amounts in =
the inputs with the amounts in the outputs (minus fee). At the very least y=
our proposal would require a way to signal how much to send back, and to wh=
ere (remember that multiple parties can cooperate to jointly construct a si=
ngle transaction!). At this point you&#39;re not far off from just having a=
nother output...</div></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><d=
iv style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);ba=
ckground-color:rgb(255,255,255)">Cheers,</div><div style=3D"font-family:Ari=
al,sans-serif;font-size: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;c=
olor:rgb(0,0,0);background-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)">Pieter</div><div style=3D"font-family:Arial,sans-s=
erif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br=
></div><div>
    </div></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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CABCM42TOD8fOJhy-1xEhGHiW3W9-MBnrhcHLOvsNwkjSiaG0VA%4=
0mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/d/msgid/bitcoindev/CABCM42TOD8fOJhy-1xEhGHiW3W9-MBnrhcHLOvsNwkjSiaG0=
VA%40mail.gmail.com</a>.<br />

--000000000000207b340623020a8c--