From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Dec 2025 13:26:42 -0800 Received: from mail-ot1-f60.google.com ([209.85.210.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 1vUAev-0008N5-OD for bitcoindev@gnusha.org; Fri, 12 Dec 2025 13:26:42 -0800 Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-7c7028db074sf3203997a34.1 for ; Fri, 12 Dec 2025 13:26:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765574795; cv=pass; d=google.com; s=arc-20240605; b=GOOE3im5wGjpfLgpZfRkzwr0cgRFnzzbA1zr81Mn29BmxjGQEjWJiOtDxDI+pJesAc xFnreEh50IzNmFLyClSe4LFndFYjfF9IHT/V0xCl8qWyb6668+LjGvs9U+ijTPuYYz29 stNU9SLDvYjFu0bN7sTXk0L4LyNIvQTOOKqh8ktks6g5FTVEvrLGULvXsWmcek/ccMbR xHQmjlwOo/u4tfGZxgdtkLZPgTLszGwcWoNic+8bBAHfa6zWtB/GFyXPzHr+WK9c7UjF PZ74pD7HHRE71KdK2oa9JCAXO98gbZE/5CDVCPZ6Q5DUjV98k0MIM7XwemST7ivkOyFp Ev/Q== 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 :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=smauLNBhkP0sP5gIfaTS84FUBF9ShyCpFEHfB3CnX6c=; fh=NUBym9SC7qIhenJlzsFr0/5SFldGMHwwEJ0nfsutckA=; b=MKIwn5gEB84rUw3zUihTDu2EaqsuoAjpZPfzhb74O46e75Royo6xRhS8ITbV83vVq3 veZmldEwB7XWdsisBcdsHk/VXv0TxkROhiFRc+4pCDR8XhgRMTZv+BzHmiDG+rJIN32T LeROUfQYtnSGgITE2/AsKAoPWUMrSnRDlcX+7WeKhLJE3Pg49wJc41WJMw503BIgJYyr qFh1f0I7doVgl3HXbXF6ENNCVWHlsAa0HYdLEIIRVpPW6FVvDTuhELyD83f1Ciz6wQNF kRAix5Fe/bPhTNNjkeco6iaX1Rhk93BtZO343Mt4/Yh6DlxtrtY6ZLN92AreL/X010Q1 NPOA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DeS5gTUy; spf=pass (google.com: domain of cal.defenwycke@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=cal.defenwycke@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=1765574795; x=1766179595; 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:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=smauLNBhkP0sP5gIfaTS84FUBF9ShyCpFEHfB3CnX6c=; b=ZJ85ylhAVe2cC2GatvsKNy0ZnPa1GhDFoYZ8/7Q9DnQOo+zYphSlfTTk8I55XgcZt+ /zckLA0Si4sArLM0S007DWKegjErWR8iePNTnNTzzU7e+no7V9z6XL/di82pzRtl5rLk qPUNTIld94SSeI9DuucC7zarHxDnuR2qydni3X0ACUQdTre0Y3ln3iLSsKviIQbSgDfA DwM9akvcNs77wcHxKN7fAbufBVkrODB0WfbcqlXMBfBbxZ6a2otnv6Hvm2iNU6R6BecE JalPS2IWJkFEYR7jyQ8YBFb0GTTpc5+qDhbPgSmxaRZ8kbEMTE4dWLqdxBhiri8nZZIH 8kFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765574795; x=1766179595; 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:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=smauLNBhkP0sP5gIfaTS84FUBF9ShyCpFEHfB3CnX6c=; b=FXYs7niPYqoiSsgR42Go7PRNKLOCXudaKgvXWz3b1Bur/fVV27cRlteWprOhorA3uZ 748oAcqDiehkQs4ddZlHCyxKsy9GkkuYw56hiw4BisDJ9z/aLsI89+DtxjZxTuHMSF8j XUlL1XW4vdnkip3CMQhUv7zc0DxjXd3piWD4Y854MKKdHyGj+SXYTJ9ehZrsKxkAm8lu 2bkipg1tjiuZBAJc8p8z26hRFLZG7qXq2EfP7o6rybfiuHnYYM9XMAg5uJ7NppmXa/3w L0nS4DfxH1N5fY2uNDLLxu3wiA4QcEtgHLlQHw0M1Iybwnh5ujEw4dHjUeCw6r0ZX3ro G1Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765574795; x=1766179595; 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:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=smauLNBhkP0sP5gIfaTS84FUBF9ShyCpFEHfB3CnX6c=; b=vniNfPPi91cU4cCmVCMWTJBtcCQgj9ZbslOrXPycWkkSLCbWQQEaBASWBOoRH3cHVl qhHNnl9y6t75ccRCfYyFMrVW7pdwIJNoLZ/M62J8JI4M0RoNA93UJwm6c1TEnXzlIvGX zrWAs22xJWYGrq6l89W03vkKuNMHx/f5VucePkCdl0OzjzMb7KH/LMijYsgmZvtgLNrQ mZo5fqMbuJdKQMS+ExjndEEKieD+SbRtgnaofT04Mts3zU2SlWG18fcgP05cMCpVD7+i tKLt5fUkhHfwryMuyY1Ov1GIVeKilCynVD5hjp7lyjPTHUBfEC/c3ATo/n59SMrHXpKR dGUw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXBAkbQU2rVQFAjDjnGg2NbImRmL9fCO8+2afirliVkIc3HKGqm8Wn8ovdHm6ECe8Vm+IG8ea4/NalV@gnusha.org X-Gm-Message-State: AOJu0YwLiiTv4nngGgDhNunEto2SNxG5HoUjspdggiG45BE8Tl1m0fAu Du3dc/7LhN+RkFTeBYn/bY+Cc7Vs8IdePvD8sO9NXdK/IbPh9Ni78mok X-Google-Smtp-Source: AGHT+IGQb5ZUX5oCcnvs/R/q4oUpgG1Th6HLZPUU4/y1CamW1TdgDxsAUNXs1qGZfrRh66T9drbLNQ== X-Received: by 2002:a05:6820:174c:b0:659:9a49:8f3c with SMTP id 006d021491bc7-65b4524a54emr1425063eaf.77.1765574795144; Fri, 12 Dec 2025 13:26:35 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYnKtR7CKeekbPuZSi7WEUrrTYiEk1f9xNPVBumIlJ8xw==" Received: by 2002:a05:687c:41:10b0:331:5ba5:afd3 with SMTP id 586e51a60fabf-3f5f8780279ls510133fac.1.-pod-prod-07-us; Fri, 12 Dec 2025 13:26:31 -0800 (PST) X-Received: by 2002:a05:6808:c2ac:b0:450:d0c:50d9 with SMTP id 5614622812f47-455ac954b85mr1821964b6e.40.1765574791434; Fri, 12 Dec 2025 13:26:31 -0800 (PST) Received: by 2002:a05:6808:a597:20b0:450:d4ca:2ed2 with SMTP id 5614622812f47-455a77a595fmsb6e; Fri, 12 Dec 2025 12:17:42 -0800 (PST) X-Received: by 2002:a05:6871:7991:b0:3ec:3c21:9301 with SMTP id 586e51a60fabf-3f5f8a0bf03mr1973408fac.9.1765570661197; Fri, 12 Dec 2025 12:17:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765570661; cv=none; d=google.com; s=arc-20240605; b=fIdbLcFBtKjD6Gf0CCFtiIPuwMRS1jFH2tLEbJTOTgrp/FaBJFqI2mNfo3s52lYuXu y8fiTblD88MnwkCrurpSJQ6savhyZv7ri5PNvjeAlB57iVGJYLt24gO3YYqmCPluQSTw i0Xl+ckrB8il85FmOUttUeI/Hf1UVNqWNjK0w55II4sjuMsV0QhFupAXOLN6T/Y7aNRX IFDgDiw6G3K/afhZsPQWjE+I8+dacX/CV1LVdr6zMN0qRg+yFLjRRy8AmEvoEIz8yYqS fKzFjOVe0xhfSCfyA+gi63NP/U/ZXxvQ1hk6Sose3X9YsZIystMZDnRZgxIWVJ1Pl4KK nGIA== 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:in-reply-to:references :mime-version:dkim-signature; bh=xe9aw5iovjcxl44xss7L2R7CLCujX9aFSHLxGNUPScI=; fh=rl4+jzoCLuJam/TauP68uwdod+CpSxy1fqvE5aWyQWI=; b=Yocft7Oela8AMGkTHaB9Bi2aRPnfuNMNi0H2gUwFSTH6Tesaomhk3kx6zTrFiqZG52 yoZ6Uvb/m6cQVFeSSPMvDSAX1foOKwuAh/Ctv7rj5Ubw+QimXC3xSfYp2gXBPJpwlZZF pB+Us5030eOMlGCTzuUDofpJiKiAYNTsOnX1GV48CJtLavx0FjJRNWQs2t+/SyPRWYPH UxnhQQWndztIXEZZ1shCsuXT1REqHW/eOnE1OfOf+FkCVFoxfuGog4IUIlAA9loe+3il 17oXM4O1gtbf3w1Vkd2UUieSLh2kEQ4vxBwC4SIJ+gfCmdoPMv02aSsJiKh/NPjpLWeg DlEA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DeS5gTUy; spf=pass (google.com: domain of cal.defenwycke@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=cal.defenwycke@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com. [2607:f8b0:4864:20::1134]) by gmr-mx.google.com with ESMTPS id 586e51a60fabf-3f5fe54f3dcsi74329fac.7.2025.12.12.12.17.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Dec 2025 12:17:41 -0800 (PST) Received-SPF: pass (google.com: domain of cal.defenwycke@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) client-ip=2607:f8b0:4864:20::1134; Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-78d6dc596eeso14474777b3.0 for ; Fri, 12 Dec 2025 12:17:41 -0800 (PST) X-Gm-Gg: AY/fxX5AyOpMeppiorxJoNMKMdsTDmNCO6pr1WZXC2MtdF4CMwg2Bz8t2w+WSP2FetN Z2HaWjAdTSiUHFIontXXZ3AXRr1dGZhS0Y0uumjF6s1YgGaqZOtjK+M0QQ61N9gu0APyGBkVoXs K/PxuHlPKStvXu5LPzMwqVqerX06y3LDPQ8trqvRc/bTXOmE+3TKuNK0OiV0YoiyJxeghRFv76L Y7NP/lSAQonGwUgFG4Y+A9cGzm9gVMSLeneiGjYUonDZhoCYas5XG7pwiv0hucB86e8QvM= X-Received: by 2002:a05:690c:6e02:b0:788:ee99:f0fb with SMTP id 00721157ae682-78e66d4946fmr22978877b3.6.1765570660632; Fri, 12 Dec 2025 12:17:40 -0800 (PST) MIME-Version: 1.0 References: <382cefe0-4ac0-43d7-919b-c56fad0a9b27n@googlegroups.com> In-Reply-To: <382cefe0-4ac0-43d7-919b-c56fad0a9b27n@googlegroups.com> From: Defenwycke Date: Fri, 12 Dec 2025 20:17:28 +0000 X-Gm-Features: AQt7F2pHYZG2CTxoL9TFKH1jJ949XtfPmxNYcX5DMxqh3_X5jjwsD_F-P0Fp8u0 Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Bbitcoindev=5D_Re=3A_Draft_BIP=3A_DustSweep_=E2=80=93_policy?= =?UTF-8?Q?=2Donly_UTXO_dust_compaction?= To: Jonathan Voss Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000000d8dc30645c6f427" X-Original-Sender: cal.defenwycke@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DeS5gTUy; spf=pass (google.com: domain of cal.defenwycke@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=cal.defenwycke@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 (/) --0000000000000d8dc30645c6f427 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jonathan, Thanks for the thoughtful feedback =E2=80=94 that makes sense. I started with a very narrow definition mostly to make the invariant obvious and easy to reason about. Every DustSweep tx should monotonically reduce the UTXO set and never meaningfully compete with the fee market. As long as that holds, I=E2=80=99m not particularly attached to any one parame= ter. I agree that requiring 100% dust inputs and exactly one output is probably overly strict in practice. A majority dust requirement and an output/input ratio cap seem like reasonable ways to preserve the incentive (net UTXO reduction) while making it more usable for real wallets. My main goal here is to give operators something that=E2=80=99s safe to run= and predictable in behaviour =E2=80=94 cheap, bounded, and only active when blo= ckspace would otherwise go unused. I=E2=80=99m happy to adjust thresholds or relax constraints as long as those properties remain intact. Appreciate you taking the time to look at it. Kind regards, Defenwycke On Fri, Dec 12, 2025 at 6:16=E2=80=AFPM Jonathan Voss w= rote: > Interesting proposal. Something like that would be helpful, but perhaps i= t > would be more useful if it was not quite so narrowly defined. For example= , > instead of requiring all inputs be dust-class UTXO, it could require a > minimum of 80% dust-class inputs; instead of exactly one output, it could > be max_outputs =3D floor(n_inputs / 5) to keep a maximum output/input rat= io > of 1/5. This could allow for better aggregation of dust outputs into > economically meaningful, monetary outputs than the narrower definition > while maintaining the incentives for meaningfully reducing UTXO set size. > > I would run this policy on my node. Hashers should ultimately be okay wit= h > this policy since someone among them also has to run full nodes, and it > would provide an additional (albeit very small) fee source when block spa= ce > demand is low. > > On Thursday, December 11, 2025 at 8:34:16=E2=80=AFAM UTC-5 defenwycke wro= te: > >> Hello list, >> >> I=E2=80=99ve been working on a small policy proposal that aims to addres= s one >> very specific problem: the long-term accumulation of uneconomical dust i= n >> the UTXO set. >> >> The idea is intentionally narrow. I=E2=80=99m calling it DustSweep, and = it >> defines a strict, non-abusable class of transactions that nodes may rela= y >> and miners may include only when the mempool and block space are >> underutilised. The goal is to give wallets a predictable way to compact >> dust without introducing new spam vectors or touching consensus. >> >> A DustSweep transaction has the following properties: >> >> - >> >> all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs >> - >> >> only standard scripts (P2PKH / P2WPKH / P2TR) >> - >> >> exactly one output >> - >> >> no metadata at all (no OP_RETURN, inscriptions, TLVs, etc.) >> - >> >> minimum of 5 inputs (to ensure meaningful UTXO reduction) >> - >> >> size capped >> - >> >> it pays a flat 1 sat per input fee >> >> Nodes place these in a small, separate sub-mempool. They=E2=80=99re only= accepted >> when the normal mempool is <50% full, and they=E2=80=99re automatically = evicted if >> normal mempool usage hits 95%. Miners can include them up to a small wei= ght >> fraction (I suggest ~5%) but only after filling the block with regular >> fee-paying transactions. The intention is that DustSweep never competes >> with the fee market and only uses blockspace that would otherwise go unu= sed. >> >> This is all policy-level. No consensus changes, no new transaction >> format, nothing that affects validation. Nodes that don=E2=80=99t implem= ent it >> simply treat these as low-fee transactions and drop them. >> >> The motivation is straightforward: we don=E2=80=99t currently have a saf= e, >> structured way to compact dust, and the UTXO set continues to grow from >> outputs that are effectively unspendable under normal fee conditions. >> DustSweep tries to offer a predictable, opt-in mechanism for wallets to >> clean that up without creating any new attack surface. >> >> Full draft BIP and supporting documents are here: >> >> https://github.com/defenwycke/bip-dust-sweep >> >> I=E2=80=99d appreciate feedback on the policy details, thresholds, and w= hether >> this fits within what node operators and wallet developers would actuall= y >> want to use. Happy to adjust parameters if there=E2=80=99s a better bala= nce point. >> >> Kind regards, >> >> Defenwycke >> > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/382cefe0-4ac0-43d7-919b-c56f= ad0a9b27n%40googlegroups.com > > . > --=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 visit https://groups.google.com/d/msgid/bitcoindev/= CAOj3_X8GtJtAgcvvPZW2Ovxt31CzGtn9tssqTSZ4BeQ_bL6pxg%40mail.gmail.com. --0000000000000d8dc30645c6f427 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jonathan,

Thanks for the thoughtf= ul feedback =E2=80=94 that makes sense.

I started with a very narrow definition mostly to make the invariant obv= ious and easy to reason about. Every DustSweep tx should monotonically redu= ce the UTXO set and never meaningfully compete with the fee market. As long= as that holds, I=E2=80=99m not particularly attached to any one parameter.=

I agree that requiring 100% dust inputs and exactly one output is probab= ly overly strict in practice. A majority dust requirement and an output/inp= ut ratio cap seem like reasonable ways to preserve the incentive (net UTXO = reduction) while making it more usable for real wallets.

My main goal here is to give operators something that=E2=80=99s safe to = run and predictable in behaviour =E2=80=94 cheap, bounded, and only active = when blockspace would otherwise go unused. I=E2=80=99m happy to adjust thre= sholds or relax constraints as long as those properties remain intact.

Appreciate you taking the time to look at it.

Kind regards,

= Defenwycke


On Fri, Dec 12, 2025 at 6:16=E2= =80=AFPM Jonathan Voss <k98kurz@gma= il.com> wrote:
Interesting proposal. Something like that would be helpful, but perha= ps it would be more useful if it was not quite so narrowly defined. For exa= mple, instead of requiring all inputs be dust-class UTXO, it could require = a minimum of 80% dust-class inputs; instead of exactly one output, it could= be max_outputs =3D floor(n_inputs / 5) to keep a maximum output/input rati= o of 1/5. This could allow for better aggregation of dust outputs into econ= omically meaningful, monetary outputs than the narrower definition while ma= intaining the incentives for meaningfully reducing UTXO set size.

<= /div>
I would run this policy on my node. Hashers should ultimately be = okay with this policy since someone among them also has to run full nodes, = and it would provide an additional (albeit very small) fee source when bloc= k space demand is low.

On Thursday, December 11, 2025 at 8:34:16=E2=80= =AFAM UTC-5 defenwycke wrote:
Hello list,

I=E2=80=99ve been working on a small polic= y proposal that aims to address one very specific problem: the long-term ac= cumulation of uneconomical dust in the UTXO set.

The idea is intentionally narrow. I=E2=80=99m calling it DustSweep, and = it defines a strict, non-abusable class of transactions that nodes may rela= y and miners may include only when the mempool and block space are underuti= lised. The goal is to give wallets a predictable way to compact dust withou= t introducing new spam vectors or touching consensus.

A DustSweep transaction has the following properties:

  • all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs

  • only standard scripts (P2PKH / P2WPKH / P2TR)

  • exactly one output

  • no metadata at all (no OP_RETURN, inscriptions, TLVs, etc.)

  • minimum of 5 inputs (to ensure meaningful UTXO reduction)

  • size capped

  • it pays a flat 1 sat per input fee

Nodes place these in a small, separate sub-mempool. They=E2=80=99re only= accepted when the normal mempool is <50% full, and they=E2=80=99re auto= matically evicted if normal mempool usage hits 95%. Miners can include them= up to a small weight fraction (I suggest ~5%) but only after filling the b= lock with regular fee-paying transactions. The intention is that DustSweep = never competes with the fee market and only uses blockspace that would othe= rwise go unused.

This is all policy-level. No consensus changes, no new transaction forma= t, nothing that affects validation. Nodes that don=E2=80=99t implement it s= imply treat these as low-fee transactions and drop them.

The motivation is straightforward: we don=E2=80=99t currently have a saf= e, structured way to compact dust, and the UTXO set continues to grow from = outputs that are effectively unspendable under normal fee conditions. DustS= weep tries to offer a predictable, opt-in mechanism for wallets to clean th= at up without creating any new attack surface.

Full draft BIP and supporting documents are here:

https://github.com/defenwycke/bip-dust-swee= p

I=E2=80=99d appreciate feedback on the policy details, thresholds, and w= hether this fits within what node operators and wallet developers would act= ually want to use. Happy to adjust parameters if there=E2=80=99s a better b= alance point.

Kind regards,

Defenwycke

=

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/382cefe0-4ac0-43d7-919b-c56fad0a9b27n%40googlegrou= ps.com.

--
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 visit https://groups.google.com/d/ms= gid/bitcoindev/CAOj3_X8GtJtAgcvvPZW2Ovxt31CzGtn9tssqTSZ4BeQ_bL6pxg%40mail.g= mail.com.
--0000000000000d8dc30645c6f427--