From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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 Date: Thu, 26 Sep 2024 11:05:01 +0200 Message-ID: Subject: Re: [bitcoindev] OP_KEEPCHANGE - mitigating dust outputs To: Pieter Wuille Cc: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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
Pie= ter=C2=A0

<= /div>
- Thank you, ve= ry helpful explanation=C2=A0

=C2=A0So=C2=A0 suggestion sucks -=C2=A0 I withdraw it to avoid wasting = others time !
<= br>
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.

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

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

Cheers, James



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

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

On Wednesday, September 25th, 2024 at 8:44 PM, James Ferguson <<= a href=3D"mailto:jamesfergusonch@gmail.com" target=3D"_blank">jamesferguson= ch@gmail.com> wrote:

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

Bitcoin doesn't have a concept of address balances at the prot= ocol level, or even addresses at all, let alone a "primary recipient a= ddress". 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.

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 i= nvasive 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 r= ecipient 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 co= urse, a hypothetical proposal could change anything about Bitcoin'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= '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.

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

But it does so at the = cost of incentivizing not transitioning to a new address on every transacti= on, 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 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 choos= es=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're not far off from just having a= nother 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.goog= le.com/d/msgid/bitcoindev/CABCM42TOD8fOJhy-1xEhGHiW3W9-MBnrhcHLOvsNwkjSiaG0= VA%40mail.gmail.com.
--000000000000207b340623020a8c--