path: root/71/5ae4d6115fec9e4447af533b805fc535af2753

Delivery-date: Wed, 25 Sep 2024 18:30:06 -0700
Received: from mail-qv1-f60.google.com ([209.85.219.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBFPS2K3QMGQEQC2X47I@googlegroups.com>)
	id 1stdKX-0003kd-F7
	for bitcoindev@gnusha.org; Wed, 25 Sep 2024 18:30:06 -0700
Received: by mail-qv1-f60.google.com with SMTP id 6a1803df08f44-6cb2e16ea95sf9405216d6.1
        for <bitcoindev@gnusha.org>; Wed, 25 Sep 2024 18:30:05 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1727314199; cv=pass;
        d=google.com; s=arc-20240605;
        b=KRgAfq8uUDxfG4hDYFzc9+nenbHZw2ZCTPeTcwvu46vQWs12II/UuQIpFvP5d8fiA/
         P/z0V6tac50mttPPksZhimpRmhd2C1al+KjBzQvpGrumEJO7yQdkqNbvk4fpvnOvgbFJ
         SMlZ52WZCnBbA+dmF2bPGjm519bONS+hGqV1u6igMv8omgij94AYzH2KHTcsOfm+oZFd
         EFk3j9OsSZg4TizVJ+e059RVi7v53tIOSskqh/WG2JTLylOL3FHGvTi5FG8lory/JXWm
         2UWp0zpdWQyHveoAkolzI4fz2hC+Yi0i1L7f2l3f8ESPZSGmAFbAyo/d39dnborR4VTH
         WKoQ==
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:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:sender
         :dkim-signature;
        bh=wrT0LCQ/9rNHnerHbr6wAVj0d12n5Vf3UlcVWLMIHFg=;
        fh=+CqfcpGEqmWFvcC9qTO8+I6MFeYiL2uFBAeWvV1XTlw=;
        b=ikmalKsOOcQ21sjc0+4nZw81DQJgDvvRp2g6HNowwUuL9DnJDMXGgrXLkayxCtlDo/
         wByybkb4r/JmBD/+gf4M8r21SQ1iVHH6PpbfgMrowjzjFgQSW2zRNgPXKimCSnCiSUJH
         v4mYMRk2Q7Csm61c+AryQlPu4BeLdmjSs0jAZPZeo6YzkC7IS8/8AdsLYDoGYvjtzFlG
         pSW7owq5sSjy6hB2sknu/InL804coUzBe/pgaGYzgYR32f49JbXJZ9jhRpUovkOrx9WV
         Bn3kjxOdxHc1ZsgJ+2jC1aVHCG8i+iMUMLxoiYH0/cckR83h/k/iJeOOD2LN5Du4mMhv
         CZMQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@wuille.net header.s=protonmail header.b=KaiFUWpA;
       spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.40.22 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1727314199; x=1727918999; 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:mime-version:feedback-id:references:in-reply-to
         :message-id:subject:cc:from:to:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wrT0LCQ/9rNHnerHbr6wAVj0d12n5Vf3UlcVWLMIHFg=;
        b=DnUV581oqJ19ZvJbknzhF8PH0T4uRPfoNiEf9ers9y0eBJUD0ib+jb4dHkysQLy/9l
         sbn2pNGBdVADmxpNB8kgMAAjT8e/AfIiSvM1iKMkF7T6NZuA/25dYWxXiwYTr77cGuhh
         /GO4DbpLbRrz5aes0jkVK3ylYf1cvlyvDyMrViO6z9Aop8UDscCAu5Gonk9Jh7z7FqhP
         qASfFRXSURfFpbmcx3IO61xqNS3sQmUrbduCXyDSnUJE+rrortf6mMxpfYKxcusPcfK2
         O/voIaaUGmAJDKsMDQ0wIUGxDeIAQlAeCl0gLoGlhm2Eh7CVkwbO46T4SL5Sdd3P1bQ1
         LNng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1727314199; x=1727918999;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:mime-version:feedback-id:references:in-reply-to
         :message-id:subject:cc:from:to:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=wrT0LCQ/9rNHnerHbr6wAVj0d12n5Vf3UlcVWLMIHFg=;
        b=oN4yY8N6mHtxPVblktgsJJv7AMf2qk1puY+5Ec1G4s3g8tW+Q+K3jqZMeUq9I6ZSOv
         NdlPdRl3rWkzEUMrhHcNrgYBxvLjxIxnpkwFPRJNTs1m6kZwy0gFKf8sbmu9Rrbi/3wO
         8GM2g0PkpNDJn9WhxshqTA4TXl1c4pN2G25wIw9C+Yisc33BTruJU/Z53RRYeY41tIUU
         Ax8dKsrPo1pcGAJKNbSoV8nx3YusDY+mnmI2o36yPg7yiPYNdLipFWfGQx/goIDkUqac
         VEPEH2xGm3XifnTlJ1Rxjdj3xwshebvRUvQM8ekGW9J9dEwL+yl/F6GVLP7PAIAq/C5v
         OPHQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVwcDfouG0xCFbbfS0T9nBi22yT5B9vzXWzaSikh8X8akpVICiVLAp0JBfTifJKg+EigLmc6ZNKkTxS@gnusha.org
X-Gm-Message-State: AOJu0YxSlEQIUBclSn0YHs4Sk8KnqN4G2rEa5+hXvp1/s/9czKFbthDO
	CAM26aHDXSSFbhi0C6AR3iTrfHS86l+mFQkZYUdm41xFN+FjQ8RN
X-Google-Smtp-Source: AGHT+IHj7VbgAdiDvWypGLOS6BYyBKDtk9dCcawu0cZoESE/i8YoO5JhgovC+Mu6mdWx7XVEIIvKkQ==
X-Received: by 2002:a05:6214:550a:b0:6cb:35ea:a343 with SMTP id 6a1803df08f44-6cb35eaa55bmr3258066d6.5.1727314199043;
        Wed, 25 Sep 2024 18:29:59 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6214:27cb:b0:6bf:4817:dd88 with SMTP id
 6a1803df08f44-6cb2ee9d71els10530146d6.1.-pod-prod-02-us; Wed, 25 Sep 2024
 18:29:57 -0700 (PDT)
X-Received: by 2002:a05:620a:440c:b0:7a9:b55c:ced8 with SMTP id af79cd13be357-7ace744d61dmr710962185a.44.1727314197614;
        Wed, 25 Sep 2024 18:29:57 -0700 (PDT)
Received: by 2002:a37:e316:0:b0:7a8:f6bb:1076 with SMTP id af79cd13be357-7ae2f13729cms85a;
        Wed, 25 Sep 2024 18:23:03 -0700 (PDT)
X-Received: by 2002:a2e:be1b:0:b0:2ef:2638:48cd with SMTP id 38308e7fff4ca-2f91ca42720mr27451451fa.30.1727313781955;
        Wed, 25 Sep 2024 18:23:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1727313781; cv=none;
        d=google.com; s=arc-20240605;
        b=Ogwq5WzMJIpUo1R429GW2otWjuvmkAqpm32+3AY2vhvSHvpbnrOs4km52Flgg5gIAQ
         gzGyBh8uo3O/l2CsBiZMw0JsrPQPzH/EoftNKL8/Ac9lCdwX+MPJPkL0PFapT+kp7Odi
         3JGr5IWqec7pivMLpjRSfPUldlj5yx901pNjChoqjBB7Q8pDRmBJI2LMuEvnRPzaI+Qy
         DFMYLtxtidZRsjqxIMC/i0RBYNKsl0o9arFc4n9wknoTLU7I1088QFtwEq2CLaTymoYg
         GppVLQh8k/wJzzq3vHiJfypil+7DEnwRM+W7JT/B/trckdqIN0mjHMey12zpEpJ3GdMS
         n0kg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=1UadhAbvR18FK1ZpTB+U2TlPy0YNOsw37o3prZMfSYQ=;
        fh=YIWojSLlsYtPZOMcBNMAXaLq0hs2HpYhJYP8hKLyU/g=;
        b=TF60UyZYtiqwQY1R5jdQB/UFzVERwVRAmegBMhljeKezVt+nBzyJwxVXRaXFzEhG8i
         SkrKGt6JQkIGI2O6VpzpzCWij5bcwFNsGIkpnnq80MkopexC+FvuMCCU19GJW+xyHrUN
         1A06Ten37Vhr+ySEARWSHfQ+EWA1eX256B1sqE40mKM+mo5r8Oehvg5qi/qS6HWZ9iVu
         b+1j1PdMDYuVZOzwTTPSriG2pyFSq2nD9DP9A5xuQkVIXNZ0umnBEvsi96MfWymRZj8O
         4KubHcx1OmCuxEN8KJu9jY5pTRUcdq8BTMxxZMdyK++t8+6o1YQwSWPAbLLfxGp2K4x5
         1DmQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@wuille.net header.s=protonmail header.b=KaiFUWpA;
       spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.40.22 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net
Received: from mail-4022.proton.ch (mail-4022.proton.ch. [185.70.40.22])
        by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-2f8d28b43d0si1018301fa.7.2024.09.25.18.23.01
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 25 Sep 2024 18:23:01 -0700 (PDT)
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
X-Pm-Message-ID: 43da635ae5d13413c0ea54b9ad1e463a2b0bc58b
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_kmeEJtrIi3ZyAj7zc4QjTONVDzvpCZdy05JmaOHmY6A"
X-Original-Sender: bitcoin-dev@wuille.net
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@wuille.net header.s=protonmail header.b=KaiFUWpA;       spf=pass
 (google.com: domain of bitcoin-dev@wuille.net designates 185.70.40.22 as
 permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net;       dmarc=pass
 (p=NONE sp=NONE dis=NONE) header.from=wuille.net
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.7 (/)

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