From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 25 Sep 2024 17:48:02 -0700 Received: from mail-yw1-f187.google.com ([209.85.128.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1stcfp-0003Iu-Rj for bitcoindev@gnusha.org; Wed, 25 Sep 2024 17:48:02 -0700 Received: by mail-yw1-f187.google.com with SMTP id 00721157ae682-6e000d68bb1sf19039217b3.1 for ; Wed, 25 Sep 2024 17:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1727311675; x=1727916475; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=HMMXJxy5Yqh2V2qiL07rq3FHA6HvvNb1vZLrzvSike4=; b=Qmimr9lSdlc50qXOqQU5k+r/v6JXd5QO2aO31M81o3V8k4CveD5wTXk/dL1cHKzZ6J 61+b2cmcwslwwUe0MqtOq47SoafETfNe3CZfywIihAWIO1TzfAGZyA+yPlYfuk5FYuWB tSKIcFkmjkaSKOEoZSRc4h0uSPQQ1ubNCwRknPvdKAqP51KeUIYjg6DAbFB1b9XSugZJ AHuFQYmxoC6p/1C16xz2L8aUv2TiVRL0k3CzbX0V81YhOvOeacr0Un6B9STzo6mBcwNd LwpGeVv08/KaGF5KqP9EpcY4gBUPGDlkC5fqPPA3bXEtC3F/FZKFwWZ2HAKo4gnJvGf+ B3aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727311675; x=1727916475; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=HMMXJxy5Yqh2V2qiL07rq3FHA6HvvNb1vZLrzvSike4=; b=HkufrMaJxyJ2EVxaDyT8W60ZyehjWUK7NY7zKPg2D++NK6JeP0DrhihJeP7eNo3drL 1kfMZ7PPUh79WjxsjT3Qg/SpsiB1dhG3UyKwUDx46oF0lzDpE0a0tJ8Soqnynm0AIkcZ +HCCV9Gtziy749VJhql0bubci0GMDgTuCpke83pLN55IfTsTBQcIjQK6XXR9dJrQQLvh bx2xqlAuZQz6jBxXpO3sxL7Ub9VquhQYPBT3Av5GVqtCkGuq30NTMAsWChmSQIOQW+9R NjmwvzsTaqNNAlxMDj6O4IGBppzcJshkiMd4fapNHWt03e1oKvI+mk06OpBo8ohKK6OO WDfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727311675; x=1727916475; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=HMMXJxy5Yqh2V2qiL07rq3FHA6HvvNb1vZLrzvSike4=; b=SWwIhtciawo2dkUWJdzb8gZh9DJ+cXVQam6CKWstpVJlQidvMCEoFcfX97ivyx+R77 DHyO1vH0C31kla5TuWdg4wRRwdLRwzPvvb/dDZXqTZx+KwIIG6Sd8uoCUGR2NfvzZtiu Wisqjkt+ZUeZmul7TQVULeHf8m8k8DepdPlAkj4xYZEnTenLVww9vLhfbP+sYC2QhejF 1UylTW7nhvXJlfVJHl5v+P/EYM/XvEhQNKVRXq329ad/rwDxiX4MvK7j1bt/nTP4T7SM DyjkujuprFx+zd7ZoSgLalBIaYKjC7vxUscc1Gm2/fKWPFiDvrzh9t8GxoDpdysiJEkT SWGg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW3kir6h2iqsKUv89KDXYbJLXF/sjxETUtgdyNVwMHiAfI3eswpDkgtyAX/dyFHH3Fs1tOXHcDf+g8n@gnusha.org X-Gm-Message-State: AOJu0YwrDNNwYzMC9YkOXczKJZ1H+X190rTNT/MZw2nMdpQY1i0WNcEl 1sO04NyTmhwekp5NaxSgLb/glfdgtCMaYBaC2F2ta97FSXzb1BOZ X-Google-Smtp-Source: AGHT+IFSHr5vIzuaGP8dhUYV4UtzcANH+3LW+3YFNyXEDOzaW2kth+onnYSMcp1019IN4n+gcxf+DQ== X-Received: by 2002:a05:6902:2284:b0:e20:2da6:ed88 with SMTP id 3f1490d57ef6-e25ca97936dmr1175971276.24.1727311675160; Wed, 25 Sep 2024 17:47:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:5f47:0:b0:e1a:87fe:363e with SMTP id 3f1490d57ef6-e25c9f7f81als65375276.0.-pod-delta-02-us; Wed, 25 Sep 2024 17:47:53 -0700 (PDT) X-Received: by 2002:a05:690c:83:b0:695:e4b0:10ce with SMTP id 00721157ae682-6e21d9d4e63mr20557347b3.7.1727311672967; Wed, 25 Sep 2024 17:47:52 -0700 (PDT) Received: by 2002:a81:ad0c:0:b0:6e2:1e5e:a1e1 with SMTP id 00721157ae682-6e21f46d647ms7b3; Wed, 25 Sep 2024 17:44:48 -0700 (PDT) X-Received: by 2002:a05:690c:6d89:b0:6db:d221:b739 with SMTP id 00721157ae682-6e22edd31famr11043937b3.10.1727311487562; Wed, 25 Sep 2024 17:44:47 -0700 (PDT) Date: Wed, 25 Sep 2024 17:44:47 -0700 (PDT) From: James Ferguson To: Bitcoin Development Mailing List Message-Id: <83296012-d713-482a-ad7a-3fd9bf7cded9n@googlegroups.com> Subject: [bitcoindev] OP_KEEPCHANGE - mitigating dust outputs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_238722_1083220999.1727311487133" X-Original-Sender: jamesfergusonch@gmail.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 (/) ------=_Part_238722_1083220999.1727311487133 Content-Type: multipart/alternative; boundary="----=_Part_238723_491381663.1727311487133" ------=_Part_238723_491381663.1727311487133 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My first post to list - Hi - tell me if I am in the wrong place or following idea is absurd=20 - otherwise please onboard me towards adding value (tell me when I've=20 overlooked standards etc) So, at risk of proving foolish - I think I may have a novel and useful=20 idea (did some searches and found nothing). best James Title: "Keep the Change" dust mitigation Category:** Consensus (Soft Fork - I think) *Abstract * Introduction of provisionally named "OP_KEEPCHANGE" allows small residual= =20 UTXO (change) to be automatically credited to the primary recipient=E2=80= =99s=20 address. =20 This aims to reduce inefficiencies associated with the creation of dust=20 outputs, reduce bloat, improve transaction efficiency, and optimise network= =20 performance by minimising the accumulation of tiny un-spendable UTXO. *Motivation* When a user sends Bitcoin, any leftover amount is typically returned to a= =20 change address controlled by the sender.=20 If this leftover amount is sufficiently small (dust) it is not economically= =20 spendable, representing a small reduction in the money supply. This causes problems: - UTXO bloat: More UTXOs mean a larger blockchain size, increasing storage= =20 and bandwidth requirements for nodes and threatens decentralisation. - Higher transaction fees: Dust outputs, when combined in future=20 transactions, increase the transaction size, leading to higher fees. - Inefficient use of UTXOs: Managing numerous small change outputs makes=20 transaction construction more complex and potentially inefficient. OP_KEEPCHANGE mitigates these issues while offering additional secondary=20 benefits: a) Prevention of Value Erosion:=20 When transferring funds between wallets owned by the same party, small=20 change amounts can lead to minor value erosion due to repeated fees and=20 inefficiencies. This proposal eliminates such erosion by crediting the residual amount to= =20 the recipient wallet. b) Enhanced Privacy: .=20 This provides a slight improvement in transaction privacy by obfuscating=20 the typical patterns used to identify change outputs. c) Mitigation of Money Supply Reduction:=20 As dust UTXOs accumulate over time and become economically unspendable,=20 they effectively reduce the Bitcoin money supply. This proposal helps mitigate a calculable reduction in the overall Bitcoin= =20 supply, preserving value and improving the network=E2=80=99s long-term=20 sustainability. d) Recipient Benefit A provider (eg a merchant) accepting bitcoin or fiat= =20 exchange users buying bitcoin (especially small sums after DCA'ing) gain a= =20 small proportional uplift in revenues at no cost to the sender) f) Reduction in dust threshold: In so far as transaction costs are reduced= =20 a small reduction in the dust threshold is thereby achieved g) Equitable with positive feedback : By reducing dust UTXO size increases= =20 - larger UTXO makes for lower default dust - All users benefit from reduced= =20 dust whether they make further OP_KEEPCHANGE transactions or not *High Level Specification Outline* - Introduce OP_KEEPCHANGE=20 - Assume some dust threshold (XXX satoshis) configurable by wallet user - During input UTXO selection to transfer some value, a wallet or user=20 seeks the minimum change value that would normally be generated as a return= =20 UTXO. This involves by judicious input UTXO selection.=20 If this is below the dust threshold a transaction can be marked with=20 OP_KEEPCHANGE - When used in a transaction, `OP_KEEPCHANGE` signals that any excess=20 change be added to the primary output instead of generating a separate=20 change output.=20 Instead of funding eternally useless UTXOs the recipient=E2=80=99s output i= s=20 increased by this amount. *Summary* By implementing this fairly simple backwardly compatible mechanism, the=20 Bitcoin network can achieve greater efficiency, decentralisation, cost=20 savings, and improved privacy for its users while maintaining a healthier= =20 and more predictable money supply. --=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/83296012-d713-482a-ad7a-3fd9bf7cded9n%40googlegroups.com. ------=_Part_238723_491381663.1727311487133 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My first post to list - Hi
- tell me if I am in the wrong pl= ace or following idea is absurd=C2=A0
- otherwise please on= board me towards adding value (tell me when I've overlooked standards etc)<= /div>

So, at risk of proving foolish=C2=A0 - I think I= may have a novel and useful idea (did some searches and found nothing).

best James

Title:=C2=A0= "Keep the Change" dust mitigation

Category= :**=C2=A0Consensus (Soft Fork=C2=A0 - I think)

= Abstract

Introduction of provisionally named =C2=A0"OP_K= EEPCHANGE" allows small residual UTXO (change) to be automatically credited= to the primary recipient=E2=80=99s address.
=C2=A0
This aims to = reduce inefficiencies associated with the creation of dust outputs, reduce = bloat, improve transaction efficiency, and optimise network performance by = minimising the accumulation of tiny un-spendable UTXO.

Motiva= tion

When a user sends Bitcoin, any leftover amount is typic= ally returned to a change address controlled by the sender.
If this l= eftover amount is sufficiently small (dust) it is not economically spendabl= e, representing a small reduction in the money supply.

This caus= es problems:

- UTXO bloat: =C2=A0More UTXOs mean a larger blockc= hain size, increasing storage and bandwidth requirements for nodes and thre= atens decentralisation.
- Higher transaction fees: Dust outputs, when = combined in future transactions, increase the transaction size, leading to = higher fees.
- Inefficient use of UTXOs: Managing numerous small chang= e outputs makes transaction construction more complex and potentially ineff= icient.

OP_KEEPCHANGE mitigates these issues while offering addi= tional secondary benefits:

a) Prevention of Value Erosion:
When transferring funds between wallets owned by the same party, small cha= nge amounts can lead to minor value erosion due to repeated fees and ineffi= ciencies.
This proposal eliminates such erosion by crediting the resid= ual amount to the recipient wallet.

b) Enhanced Privacy: .
This provides a slight improvement in transaction privacy by obfuscating t= he typical patterns used to identify change outputs.

c) Mitigati= on of Money Supply Reduction:
As dust UTXOs accumulate over time and = become economically unspendable, they effectively reduce the Bitcoin money = supply.
This proposal helps mitigate a calculable reduction in the ove= rall Bitcoin supply, preserving value and improving the network=E2=80=99s l= ong-term sustainability.

d) Recipient Benefit A provider (eg a m= erchant) accepting bitcoin or =C2=A0fiat exchange users buying bitcoin (esp= ecially small sums after DCA'ing) gain a small proportional uplift in reven= ues at no cost to the sender)

f) Reduction in dust threshold: In= so far as transaction costs are reduced a small reduction in the dust thre= shold is thereby achieved

g) Equitable with posi= tive feedback : By reducing dust UTXO size increases - larger UTXO makes fo= r lower default dust - All users benefit from reduced dust whether they mak= e further OP_KEEPCHANGE transactions or not

High Level Specif= ication Outline

- Introduce=C2=A0 OP_KEEPCHANGE=C2=A0
<= br />- Assume some dust threshold (XXX satoshis)=C2=A0 configurable by wall= et user

- During input UTXO selection to transfer some value, a = wallet or user seeks the minimum change value that would normally be genera= ted as a return UTXO. This involves by judicious input UTXO selection.
If this is below the dust threshold a transaction can be marked with OP_K= EEPCHANGE

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

Instead of funding eternally useless= UTXOs the recipient=E2=80=99s output is increased by this amount.
Summary

By implementing this fairly simple backwardly = compatible mechanism, the Bitcoin network can achieve greater efficiency, d= ecentralisation, cost savings, and improved privacy for its users while mai= ntaining a healthier and more predictable money supply.

--
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/msg= id/bitcoindev/83296012-d713-482a-ad7a-3fd9bf7cded9n%40googlegroups.com.=
------=_Part_238723_491381663.1727311487133-- ------=_Part_238722_1083220999.1727311487133--