From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 From: Pieter Wuille Cc: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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
Hi James,

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

<= div class=3D"protonmail_quote"> On Wednesday, September 25th, 2024 at 8:44 PM, James Ferguson <j= amesfergusonch@gmail.com> wrote:
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.

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

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.

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.

b) Enhanced Privacy: .
This provi= des 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 transitioni= ng to a new address on every transaction, a huge privacy leak.

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

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 chooses=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...

Cheers,

--
Pieter

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitco= indev/4_re7EWb0zy-E_Yk472AGf4WwgwxO9XCC1Y2RqYGlCV7FXpbq1ifIe-DL93-y5erlsAO_= G-27SzLcFhGq9kDs8KNE0u2GSC24cFV-rJ5X10%3D%40wuille.net.
--b1_kmeEJtrIi3ZyAj7zc4QjTONVDzvpCZdy05JmaOHmY6A--