path: root/c5/83ce99e632bf61a85c83c85c6ddf2a345cbd60

Delivery-date: Thu, 26 Sep 2024 02:47:04 -0700
Received: from mail-oa1-f62.google.com ([209.85.160.62])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDAL7PXD4IKRBD632S3QMGQEN6OBZIQ@googlegroups.com>)
	id 1stl5T-0001BL-9p
	for bitcoindev@gnusha.org; Thu, 26 Sep 2024 02:47:04 -0700
Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-27808f6bfefsf890235fac.2
        for <bitcoindev@gnusha.org>; Thu, 26 Sep 2024 02:47:02 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1727344017; cv=pass;
        d=google.com; s=arc-20240605;
        b=kKRGdYRp+rDlYUclv6/VqmH+paqJXlCkkwwLjo6KgyF4/5pYmmqtk2a+teYDdCXR3H
         Ot3jJeGInQQOOCSkxNL6rh6gmQT4kxgKqWDWevLI1fA8MVNuh02pH5z9iGYPcrdE8aHn
         55iDZ51UVwW1aDk+phjb4UJVtOR5JPaN41AyyBqxy7fE6lxxCwQgOKLce90efdXNzcNa
         mFOeZc0yuI7XyF5km8LNGZyzNBglY6Og/5j3CObyVKPGa3oBIxkcreFQ9GaCmKnbc+0h
         hK54S0i5wQPpURd/F/t79a3p6G0edBHPR23ovSOmbpM5kz3qn9zPQNaaJeDe4+gJomlV
         Px7Q==
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
         :reply-to:in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=WFJhzb+HtLxtNGrTDO24uwD44DhfA14skXaaLvrlGU0=;
        fh=aukl+4OdHRVvu7L7RVRaoCf1oq3f2W4svD6egMpYvIA=;
        b=lcRxKnSojvLTBV4MTPsnbFDR91Qvbj/LkvgU0G9ONdmKI+fNEiIP+IAEqHw2cZnWA0
         SceR0zbQe/MSRcX4O2wOCi0SL3ffKGeuG+8SGb1D8hNTUakQrkqJKragC15N4bUEy+CT
         c37UYroGW1qDZWrGNVDbqY7ATCRJVm6tBhFL0GPdMe2CNuo+jK7YqaTPPMwG1IztNCU8
         WvgfXQ8It6P73kxpkrxL3sZTYBqz/pRX38sGuulTod6NgL3tIJ7IBc6HYpdL3G2/2lIg
         a3lmajCXvyg3lTOltqWD1PLXFd9d8npAEE3DnfFQhJfcqLeCETn/LLrrpsGJaO1pEFFN
         jPtA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=dXAFTA8S;
       spf=pass (google.com: domain of jamesfergusonch@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=jamesfergusonch@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=1727344017; x=1727948817; 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:reply-to
         :in-reply-to:references:mime-version:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WFJhzb+HtLxtNGrTDO24uwD44DhfA14skXaaLvrlGU0=;
        b=B9zcYHPLRKlPcoPwuudMegVZcE9tUUCelzdgfEFZw6bF7vEhReC6b0MeWvZsA7PKJY
         EwHq5Yl9kDNxYvKvZmmbv1+6EQTlBGlf1fMCGs460/7WjgdgicP3/wlk6oNsOBAJhZyN
         5Qwy0viQBQUhEtghb5eiABAQNXHzP7YD4JWlC0COHg80RNKspbMFyVAUJgylCHpOofdu
         bBxtVk9KvwrGofqlqbDo9B1YywlLu/umQwDOiGIDrwn3LbwBJSQf0dDtz9Lnjh4P16iQ
         m5fS7SZlHnPPHS1oe6SfkF08YAUXdm/ca9SirzX2g3yFqFHtGKzLJvOiuhuqlqMWuNcd
         HeBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1727344017; x=1727948817; 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:reply-to
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WFJhzb+HtLxtNGrTDO24uwD44DhfA14skXaaLvrlGU0=;
        b=BEY/8/8mWNvHAlz4H4N4/MNCfdj98vnZ0Pq8mvP2dh6CyEOA0t/7vzMmwSZiej2PY3
         cXbrsnionVa9l9xDyi/A8i6xwXyGVXbEhw9Q3digPOmq4ziE7ROUK9EEN7FbAZINRJu3
         ElRzCHQGAaobSwm109taM7vC9cm128FokShTWnSvr13aGFhIyFKjJpG712Mct1JBBlX+
         61mxwgFFnxh7pj9SRruDu5akQeG4wke9snNpkPbo5tmYGwtnQAld8SKg+r5yKDOJgayA
         XLmoWrg7PvhEtDTQCs1Dgvlq9WW4o1b1wqpFOJCBSIpu3fgYoWoiCjp1Y6pop0snOKkr
         EFmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1727344017; x=1727948817;
        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:reply-to
         :in-reply-to:references:mime-version:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=WFJhzb+HtLxtNGrTDO24uwD44DhfA14skXaaLvrlGU0=;
        b=W8a6C80sD1Te59vMM6CjoPzwb2SAgN9P9EfplX0jNPHsZQRSMQbANce6uHks6ryjOI
         Yc3bdM4ohlsXwrS4KJPU4+pH56k+KmPwNYFp6WNDwtyh+L2zmBfsAyu8WqXh8EzyM2oq
         5bch+mVfhcLoPSUHnTC88qcmIfYuZTqHCZCQMbdANY01S7QCGRbWiX2V7rx2w7TtDBcM
         qCgdDOAjlrEwtgvSKqp45RSv0R9X8/9uUwSqVjtc7g5ifY8KCgtNi93wleUWineXpRTN
         NFzR0KFwqiSQespaCpARtmvXaQuwo8/Bf0H2hb7gHSJAd9La5g4oYhzMwu0PCemn3Ear
         8AkQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUpdYpMuZS11PCVOILboSPpygKm/cU75rl5kbwXXSrcVDkb5XCNKPtNETzaY/CIsY0iKLJ0aaxmAvmq@gnusha.org
X-Gm-Message-State: AOJu0YwaOEAFWXzwB/wmyTSrkHQfsl12wW2BqQOMBaow8scO+2sEZ8/J
	ykYn6vlukIk5CU87QzSyaJV/PSRzTtD2DyozEds4fw4FcTUzLWM9
X-Google-Smtp-Source: AGHT+IGho+Wr1x4m2VlJ2+Y7rCRJfzc2puNFFCk9QwnKgs5WE482NyLhDr23incw3ZkiuyaIlhalrg==
X-Received: by 2002:a05:6871:4f04:b0:286:f2cc:7a71 with SMTP id 586e51a60fabf-286f2cc8df5mr1925515fac.32.1727344016813;
        Thu, 26 Sep 2024 02:46:56 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6871:d205:b0:25e:8e6:12bf with SMTP id
 586e51a60fabf-286f91e9ecdls599269fac.2.-pod-prod-07-us; Thu, 26 Sep 2024
 02:46:55 -0700 (PDT)
X-Received: by 2002:a05:6808:220d:b0:3e0:3984:31b5 with SMTP id 5614622812f47-3e29b76c2camr4611060b6e.12.1727344014981;
        Thu, 26 Sep 2024 02:46:54 -0700 (PDT)
Received: by 2002:aca:1918:0:b0:3e2:56b7:2b6a with SMTP id 5614622812f47-3e29bcf08c7msb6e;
        Thu, 26 Sep 2024 02:05:28 -0700 (PDT)
X-Received: by 2002:a05:6870:a3d0:b0:268:a79a:be0d with SMTP id 586e51a60fabf-286e1799697mr3778149fac.47.1727341527734;
        Thu, 26 Sep 2024 02:05:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1727341527; cv=none;
        d=google.com; s=arc-20240605;
        b=Z3gCwxJW8KrqxhGvPX7/h2PGutUnyBp/HVWPIhEtqicCUTP7ybGbgfrog48hNV8/sI
         mCUBKR3R7lL8UpXQW6hFrQor71DDyFW+Zi6fLISiJE7UNRqgqZLfzQF/b9gw4EOnfJF6
         UrIPci7jkpu8yUZa6Av0mes0Y917fWNptBTeo67+CDryFlfuESPJ5fhjqr0ymWFQPQ+Y
         DAh70bDnxiwdjm0XbIMgmb9mmnkPyRRPp8QgCehhK0mwpvJf0b4XUZUDrnB6Ovuj8Up8
         XaoHgNvHwP+BIOJgulhwLQSgr5neeeSBG7aOC7+ARSaEOb+LCscOCffquPgrrOFPtRuN
         uH7g==
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:reply-to:in-reply-to:references
         :mime-version:dkim-signature;
        bh=Nl+Kv+V0wVEn+rR2PijgwFwTRKw64X9dBvlEItCqkuY=;
        fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=;
        b=N7FcgESIxJSR80cC3RvYmvEPIU3kln9pO+tCE+SNnXBCCOJyydK+uxPEjCw4E9t7D8
         d2zptcfPRzT4RmByy1HRdE8Z0OVwZgqghKOsWLwTXk35dwVWag52MUWeDDahatnurnsG
         JJWWM7/uSNwAXI0Zhj0fBUoZENojP/H6vlXGlpc0Rput3CpeHBuQ3ZgEhmJ+BNOFmCcM
         oy8xKqE13N4fdyhVm0YjBcgpllHWK7iIP8hMEQ48YasfmxT2V5JhQSvifdt/qIQSaQxN
         y21316Nc1PlO06/Xer66REKqq3NC2QB1gsjStKIjfsFjKnszWbaVossbNY/7FVxPd/rB
         4PgA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=dXAFTA8S;
       spf=pass (google.com: domain of jamesfergusonch@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=jamesfergusonch@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com. [2607:f8b0:4864:20::632])
        by gmr-mx.google.com with ESMTPS id 586e51a60fabf-286fd7889dasi52658fac.3.2024.09.26.02.05.27
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 26 Sep 2024 02:05:27 -0700 (PDT)
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;
Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-207115e3056so5443545ad.2
        for <bitcoindev@googlegroups.com>; Thu, 26 Sep 2024 02:05:27 -0700 (PDT)
X-Received: by 2002:a17:902:e5cd:b0:20b:202b:4d20 with SMTP id
 d9443c01a7336-20b202b4fddmr27411895ad.27.1727341527068; Thu, 26 Sep 2024
 02:05:27 -0700 (PDT)
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"
X-Original-Sender: jamesfergusonch@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=dXAFTA8S;       spf=pass
 (google.com: domain of jamesfergusonch@gmail.com designates
 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=jamesfergusonch@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: <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 (/)

--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--