From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 23 Dec 2025 17:26:24 -0800 Received: from mail-qt1-f190.google.com ([209.85.160.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vYDdu-0006d7-UJ for bitcoindev@gnusha.org; Tue, 23 Dec 2025 17:26:24 -0800 Received: by mail-qt1-f190.google.com with SMTP id d75a77b69052e-4ed82af96fasf108707951cf.1 for ; Tue, 23 Dec 2025 17:26:22 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1766539576; cv=pass; d=google.com; s=arc-20240605; b=F4UMkqG/X7zyHeU8k1fMY0wSqQGWLVJ7U0f1Y3uaR8mkZYrlqlv8hyTijDaCvH3fmg Px0TrKrXIKsfqeotXuVlTAvCtkzZeBsTukXjZjx4/S4hb8CcN/kgXetlyMrtjp0jGwQR vz2FbyamtDkkT/fijobv100KUAmmrp9QPOqjSn7XKYN34v1inOYS+A525Z3jSTdypXvi Ti5hM47a1/u8JTjvi7e0R9VO6DZniIIQeTWxNvRoB2v1r+wTEh1+WSIZ/eFZbYGpPY+s ybQDTJuXlGvxJdnKBhswIjZdfit1GCeaR8FoTZ8rQO30auJhjUW1SjgJ4Ij8jtBFxuym wyEg== 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=TkM8fGvwP/8B2u2RyLYOWUzjNjUeYgBzultS7PVUNb8=; fh=quWBsJFhoQydSNZcxL02v1N4YeJWbhr/g4KDXpCqcjc=; b=QyHm4llt1ZW9xHu9IwrGE6qvIbOeDbJZgk35n9KWild6xZjgJ3vFcKhaFAACPiuzZw MGZjv97xBc+wV/Hz7QZnc/4V5FdbNR2efc5E5janjIeE2OeLT1rBp1rj6OBZKqISk0HO A2EpdI4HRe8Oe3Bzp4FYv4o+rGy8VyCLzA//gmqdBu6Wo3DCVoleOXytZtRB6GLXxOiY KpVXuWD4e5s/iHoTLdc52la1b/SqmXDkI38RjMYasZWzDUY/cKGwerwMgoWEnKd01MY6 t/0KSVX1qFswwfxXwc6pZXt2SBc0UQCoM0SPsCFGsoz3rugF/ax5ktDmomkUMFNsCBsR Z7CA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ZghZQ9Rq; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=gmaxwell@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=1766539576; x=1767144376; 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=TkM8fGvwP/8B2u2RyLYOWUzjNjUeYgBzultS7PVUNb8=; b=Hpldgc0HERxbLzonM3J3yop9Ys64oRCZn/XGYhunOMb4URSs0txkz/nZwKkdfWuGc7 JhXvErJaLIf6FAUU2XqCxS1uzt5fuZbW6RjzMn9aDYvexVnnG5R4i6OOllFcVzZ1pCyq sIn4VAnBlq78tT4bEQDJ7CUV9MTEZ9wU92sPhH6/aLtx6DKuFbOdWvAV3baQnLwwesZq /AkD31RyktMDMu7GdOcEYNAGC69hi4198FfF/iEx06nzwlEbseMg4HoE6hICwbqeqCs/ RB2KKFiy1GExHiKkeN6AQbLr/RTRf+wvG6X1r+9GicYeDJQzb8O4vj+yScBEL+Er7WUV bOrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766539576; x=1767144376; 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=TkM8fGvwP/8B2u2RyLYOWUzjNjUeYgBzultS7PVUNb8=; b=THHb1L8I950idQORPaR+YABdGPDiZgol9Y/YG9/HV1mc/tpZSSdibR1mXipQVRD+yO +x44vJglavcoq21B/1atCvbe9/8wRzU+wFsGNpzqA+yJnySakgJYtqAWuKzp3Fk8of7h 5PUJSaSQUVdVr6+RrvMxvCAXSuy8yTzXKA8WjJPfFHH6X5CqzssIAiz0RUvWa7iALvOC 51kiXOUybDEpCMFy2BcSPUjqDS6ImhOOWGfPK/3x3jnTc7vr0RrsJfqv/yqorl2+d6Kr clvS5sL/wqLSSqld1HU+yoK0posC9AZ8IVms6kdqDFF0hbZ0mkKYRDgl2Y5lduOVo2X0 Q9wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766539576; x=1767144376; 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=TkM8fGvwP/8B2u2RyLYOWUzjNjUeYgBzultS7PVUNb8=; b=XaTY9yBl/3wOgxaEL65Haswcqunid23pKu7Dd7zieLZ1VboPh4aoC0V3RxnGvh/NMh o8U8yE/sm3M2vdjpGXe/4KpBQdbVzsvs73MozfRObXdG+Rx1IO100/UrYvMwSG/baFtt kdM1/0zoWYeoGgxNeta6v52AQOuwkIcvBOaPQBn9/T74D4jOUMGAaImrF8NGiLsl0cXl H3Xz0m7QH7+7i5+r1Nr3wMQhcj2vhMAkiJ9mQT/S11zb5A6n4K5mlcY526kPUwMSiN/f Pqpa3uRHQXXLsb5Tm862dxxwEozoRwotESMjd2wMf/pnFcGJIJAFuqWmMF3kuadFXA7n xaHQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCU1PGFFPrHCktQG27DQEEpPXUlq0Hfgoc9M725+9nKfEXd0DbIx10rggjCbFZd1viwgF4KuYouErfRk@gnusha.org X-Gm-Message-State: AOJu0YxXmDmEhv5Q0WAh21MTsepr0WkrbyIchmn7K5UR5wwqs9PR67w+ PhNI5AGQ3FMyUi2VZM7FvvItBmNPlkoitP6qIDr6Ur9oLfoRXWFHw+k1 X-Google-Smtp-Source: AGHT+IFiMqS1vMZec+1WvscyFYZBrZn0gUu12URgqX/pZp9yWEtSqv7q+xBtsRZ/DWHRHjEvH5YnVA== X-Received: by 2002:ac8:5cd2:0:b0:4ee:2200:40a0 with SMTP id d75a77b69052e-4f4abcb8effmr258115991cf.3.1766539576104; Tue, 23 Dec 2025 17:26:16 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWb0ZAfcQ4tevSpNvk3Vjw9QS4OZYCvuo/CFU7wf/tlIWQ==" Received: by 2002:ac8:5f8d:0:b0:4ee:419f:87ab with SMTP id d75a77b69052e-4f1ce93ea34ls236948471cf.0.-pod-prod-04-us; Tue, 23 Dec 2025 17:26:10 -0800 (PST) X-Received: by 2002:a05:620a:29c1:b0:878:16ad:3a5b with SMTP id af79cd13be357-8c08fa9be29mr2284661685a.14.1766539570847; Tue, 23 Dec 2025 17:26:10 -0800 (PST) Received: by 2002:a05:6808:668b:10b0:457:b360:4f16 with SMTP id 5614622812f47-4598e2132bcmsb6e; Tue, 23 Dec 2025 11:12:42 -0800 (PST) X-Received: by 2002:a05:7022:793:b0:11b:9386:8257 with SMTP id a92af1059eb24-12172302180mr12818822c88.44.1766517161331; Tue, 23 Dec 2025 11:12:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1766517161; cv=none; d=google.com; s=arc-20240605; b=B4N40xwnF9eiXkIbAtw8On8W1fRE4bGYgfL4ddFJ70+qvewg/Mslu7ARngdJEyfPLI 7h2NQQvQ55sFBiOB+Xxl4TAooH0o7Ihib4kdJEOUlQcSXtEJS3isdH0QVQl+ePYtJajY fG1EmBJrOfjLYupI8QxGxXaYykOWm0xByLwcV9cNZMCN4X+QJYBC0iglKhViQPdBkbB6 iAhbB5SsA0UOSPq670X1MxNDQ3vZ53QBanvei1wjYPX+tWBf6FMYMfwQIpu1OFi3qkZS 5COJmUs9Rvd4thwZ0BlkLeU1v8ehhGmIb2bEEPpd1yi/sW+OkkqJk048z5sLTlDPcYn9 0gTw== 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=QuIX+5MZ+T1VWAiItKow8fIjSLmfq7TPVfRo/VBGWjI=; fh=fi22zCciWY1dXX0/x2ZuHMZzhEe1QlE02hySIXXYBB4=; b=EoKqnkP0tOCT1oYqsogLjjk8flzUdpV19UtZhXv+gfVRHHFbYQJsv5XXrkii4A/LD+ whG7v4YVsrjkSZ9iW+lCKZoevuuPju2+IFLwqqRvAHXHDipLKWMEHJ/aLsYv3AenGSXE aT0rFx11hr8gKwoifcBjb9shGwHaLA3TieGYZKDIOQ08GBXdR36aYnB9XfCMUUDjaHaL QCrevG0p1w0RvZKMnODAr49eSP4uK2rpqzv/8tXKLsKsIVVwREj8BgCyMmblzhOERaRi zVcvpwM51UYGxz0IJu60GKZzAzEwT9n6I5AH8db1Cr0CMZQuWUiZ5BSYNt/jsUgaLJQA 2xwA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ZghZQ9Rq; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=gmaxwell@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 a92af1059eb24-1217253de75si142281c88.7.2025.12.23.11.12.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Dec 2025 11:12:41 -0800 (PST) Received-SPF: pass (google.com: domain of gmaxwell@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-2a12ed4d205so46651735ad.0 for ; Tue, 23 Dec 2025 11:12:41 -0800 (PST) X-Gm-Gg: AY/fxX5OISmEeVNgFYfC8ZPouUDWrMVIyov55bKTdS6U9ppGv+c1R9/kCc6aFcytPjw yCvjPw0ZpmqpaMI7lsgAci8/H4Zu59TKneW1azPmjx0Cwl7etRLMxbh/lghvsPkdw1ThFCExmnM aw6/KXeQCAyRSiCWjMADv6yhvYHzN7pr8izkcxyMySaz/fqcIf4UAH/8L8weE8EDoSxcwd4a3nY ggjRfhKreXPmk/5qRjchlhJCGz92Y6TDynB2LfNQHBn7k45bIX2UjDRvM9W/DtoxUVs0tYbq7du rtgcjmtGHviucMjKOtU7XppUKLVYeTBdyTspAYRycbRCEfPm6ui6CrA+iTvm2w== X-Received: by 2002:a05:7022:924:b0:11b:923d:7753 with SMTP id a92af1059eb24-121721aab49mr20850753c88.3.1766517160261; Tue, 23 Dec 2025 11:12:40 -0800 (PST) MIME-Version: 1.0 References: <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com> <4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n@googlegroups.com> <959c8b53-2055-4de2-8a93-1fd169f1a159n@googlegroups.com> In-Reply-To: <959c8b53-2055-4de2-8a93-1fd169f1a159n@googlegroups.com> From: Greg Maxwell Date: Tue, 23 Dec 2025 19:12:28 +0000 X-Gm-Features: AQt7F2pLpbCCzsPbj1-M__TsbFo7nBxKCDxqRzcJClaLU3_kVJAMBQjtrqp47K8 Message-ID: Subject: Re: [bitcoindev] Re: The Cat, BIP draft discussion. To: John Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000d3bc0b0646a35381" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ZghZQ9Rq; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=gmaxwell@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 (/) --000000000000d3bc0b0646a35381 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The 'dust threshold' isn't a consensus parameter, it's just a number pulled out of the air that didn't seem unreasonable based on average fee behavior. But in any particular block transactions may need no particular fee level at all, including zero fees. And in some cases it may be very economically advantageous to spend an output even if its face value doesn't support it, NFT's being a one such example (although one I consider pretty dumb). This proposal also appears to have ignored the prior discussion particularly where it was pointed out that 'deleting' outputs will not achieve the goal of deleting the tokens connected to them (so won't eliminate the incentive), or that txouts which are predictably not going to be accessed (as this proposal claims applies to the txouts it targets) don't have as significant performance implications (because they don't need to be cached in ram). It also appears to be uninformed by advances like utxotree which makes the absolute size of the txout set much less important, but would make mass removals such as that described here expensive. Nor has it considered that given the level of fee spending on NFT traffic a requirement to keep it over some (reasonable) threshold would not likely discourage it, or the fact that existent NFT outputs are generally over the dust limit in any case (so the proposals failure to meet the opcat proponents' delusional goals is already clear). I think the list should adopt a 1 year ban on parties *and their* employer(s) (if known) for any coin confiscation proposal on the list going forward (after, of course, making the rule clear on the signup page). It's tiresome and beyond being a waste of time risks undermining public confidence in Bitcoin to see the constant trickle of these outrageous proposals in venues where they previously understood that serious discussions were to be had. People are, of course, free to discuss whatever ill-founded concepts they want but they're not entitled to the time and the reputation of the participants here for offensively misguided proposals. On Tue, Dec 23, 2025 at 6:27=E2=80=AFPM John w= rote: > Good evening all, > > Here is a related proposal by Matteo Pellegrini > @matteopelleg > > > > Lynx. > > Abstract > This proposal introduces a periodic, consensus-enforced mechanism for > rendering UTXOs below the network's dust threshold permanently unspendabl= e. > At each halving block, UTXOs that have remained below the dust threshold > since the previous halving become unspendable. These UTXOs become > unspendable and may be pruned from the UTXO set entirely, reducing node > storage requirements and eliminating the economic model that incentivizes > their creation. > > Motivation > The Bitcoin UTXO set has grown substantially due to various factors, > including inscription protocols, spam attacks, and general dust > accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO > Cleanup) by @ostrom72158 > have attempted to address this by creating lists of specific UTXOs to > render unspendable, identified by external protocol indexers. > > The Cat's approach has a fatal flaw: it relies on a list. > > Using a curated list of "non-monetary UTXOs" introduces several problems: > > 1) External dependency: The Cat requires reference indexers (Ord, Stamps, > etc.) to define which UTXOs qualify. This introduces consensus-level > dependency on external, non-Bitcoin software that can change, have bugs, = or > interpret protocols differently. > > 2) Protocol targeting: By specifically identifying inscription and stamp > outputs, the proposal makes subjective judgments about which Bitcoin uses > are legitimate. This sets a precedent for protocol-level discrimination. > > 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes > workarounds. If Ordinals dust is targeted, protocols will adapt to create > dust that doesn't match the list criteria. > > 4) Static snapshot: A one-time list cleanup provides temporary relief but > does nothing for future UTXO accumulation. > > 5) Political vulnerability: Any list-based approach requires ongoing > governance decisions about what belongs on the list, creating a permanent > political attack surface. > > A better approach targets the economic reality, not the use case. > > UTXOs below the dust threshold are, by definition, economically irrationa= l > to spend under normal fee conditions. The dust limit exists precisely > because spending these outputs costs more in fees than the output is wort= h. > These UTXOs are already "dead" in practice; this proposal simply makes th= at > reality explicit at the consensus layer. > > By using a threshold rather than a list, Lynx: > > - Requires no external indexers > - Makes no judgment about why a UTXO is small > - Applies equally to all participants > - Provides ongoing, predictable maintenance > - Removes political discretion from the process > > Impact on Inscription Protocols > > The typical Ordinals inscription is stored in a UTXO containing exactly > 546 sats; the minimum required to meet the dust limit for P2PKH addresses > and ensure transferability across all address types. This "postage" amoun= t > is standard across inscription tooling and marketplaces. > > A threshold of 999 sats captures the vast majority of inscription UTXOs > without requiring any protocol-specific targeting. The economic model of > inscriptions depends on these dust-level UTXOs being spendable; Lynx brea= ks > that model through neutral, threshold-based rules rather than list-based > discrimination. > > Specification > > Definitions > > - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is > subject to Lynx enforcement. > > - Halving block: A block at height N * 210,000 where N =E2=89=A5 1. > > - Snapshot block: A halving block at which the current dust threshold an= d > qualifying UTXOs are recorded. > > - Enforcement block: The halving block following a snapshot block (i.e., > snapshot block + 210,000 blocks). > > Lynx UTXOs: > - Existed at the snapshot block > - Had a value less than 999 sats > - Remained unspent through the enforcement period (~4 years) > > Consensus Rules > After activation, the following rules apply: > > 1) Snapshot: At each halving block H, record the set of all UTXOs with > value < 999 sats. > > 2) Enforcement: At halving block H + 210,000: > - Any UTXO that was in the snapshot set and remains unspent becomes > permanently unspendable > - Transactions attempting to spend these UTXOs are invalid > > 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their loca= l > UTXO set. Transactions referencing unknown outpoints are already rejected > as invalid; pruned Lynx UTXOs are simply treated as if they were already > spent. > > 4) Grace period: The ~4 year window between snapshot and enforcement > provides ample time for holders to consolidate sub-dust UTXOs if they wis= h > to preserve the value. > > Activation > > Activation method: TBD (Speedy Trial, BIP8, or other mechanism as > determined by community consensus) > > Recommended first snapshot: The halving following activation lock-in > > Rationale > > Why a fixed threshold? > > Using a fixed threshold of 999 sats rather than referencing the dynamic > relay dust limit provides: > > - Simplicity: One number, no script-type variations, no need to query > policy settings > > - Predictability: Everyone knows exactly what qualifies, forever > > - Consensus clarity: No ambiguity about which outputs are affected. > > Why tie to the halving? > > The halving is Bitcoin's most recognized Schelling point, using it > provides: > > - Predictability: Everyone knows exactly when halvings occur > - Sufficient notice: ~4 years is generous warning for any cleanup action > - Aligned incentives: As block rewards decrease, fee revenue and UTXO > efficiency become more critical to network sustainability > - Natural cadence: The halving already represents a moment of network-wid= e > coordination > > Why not a one-time cleanup? > > A one-time cleanup (as proposed by The Cat) provides temporary relief but > creates no ongoing pressure against dust accumulation. Periodic enforceme= nt: > > - Establishes a permanent, predictable norm > - Removes any expectation that dust UTXOs have indefinite longevity > - Discourages business models built on dust creation > - Provides continuous UTXO set maintenance > > Why pruning works without a list > > A key insight enables pruning without maintaining a separate list: Bitcoi= n > nodes already reject transactions that reference unknown outpoints. When = a > node receives a transaction spending an outpoint not in its UTXO set, it > rejects it as invalid =E2=80=94 the node doesn't need to know why the out= point is > missing (spent? never existed? pruned?). > > After enforcement, a Lynx UTXO is functionally equivalent to a spent > output. Nodes can simply delete it from the UTXO set. Any future > transaction attempting to spend it will reference an outpoint the node > doesn't recognize, and will be rejected through existing validation logic= . > > This means: > > - No separate "Lynx list" is required > - No new validation logic is needed > - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish > - The UTXO set shrinks naturally as nodes prune > > Why 999 sats? > > The threshold of 999 sats is chosen because: > > - Above all dust limits: Captures UTXOs at or below the dust limit for al= l > script types (P2PKH: 546, P2TR: 330, etc.) > - Captures all standard inscriptions: Typical inscription UTXOs contain > exactly 546 sats as "postage"; well under 999 > - Simple and memorable: A clean number that's easy to communicate and > reason about > > Backward Compatibility > > This is a soft fork. Nodes that do not upgrade will: > > - Continue to consider all historical transactions valid > - Accept blocks that exclude spends of Lynx UTXOs > - Eventually converge with upgraded nodes (as upgraded miners will not > include invalid spends) > > Wallets & Services should: > > - Warn users holding sub-threshold UTXOs after a snapshot block > - Provide consolidation tools during the grace period > - Update UTXO selection algorithms to deprioritize or exclude > sub-threshold outputs approaching a snapshot > > Security Considerations > > No confiscation > > This proposal does not transfer value to any party. Sub-threshold UTXOs > become unspendable, similar to: > > - Lost private keys > - Provably unspendable OP_RETURN outputs > - Satoshi's untouched coinbase rewards > > The bitcoin supply cap remains unchanged; the affected outputs simply > become irrecoverable. Holders receive ~4 years notice to consolidate if > they value the sats. > > Lightning Network > > Some Lightning implementations create small HTLCs and dust outputs during > channel operations. Analysis is needed to determine: > > - Whether current dust thresholds affect normal LN operations > - If LN implementations need adjustment before activation > - Whether channel close scenarios create sub-threshold outputs > > Preliminary assessment: LN dust limits are already set conservatively > above relay dust limits, so impact should be minimal. However, this > requires verification from LN implementers. > > Fixed threshold vs. future fee markets > > The 999 satoshi threshold is fixed in consensus rules and does not adjust > based on fee market conditions. > This is intentional: > > - A fixed threshold provides certainty for users and developers > - If fee markets change dramatically, a future soft fork could adjust the > threshold > - The ~4 year grace period allows the community to observe and adapt > > If Bitcoin's fee market evolves such that 999 sats becomes economically > significant to spend, this would indicate broader success of the network; > and the community could choose to lower or eliminate the threshold throug= h > a subsequent proposal. > > Acknowledgments > This proposal builds on the problem identification in "The Cat" > (Non-monetary UTXO Cleanup) while proposing a list-free alternative > mechanism. The Cat correctly identifies UTXO bloat as a problem worth > solving; Lynx offers a more neutral solution. > > > https://x.com/matteopelleg/status/2000602318346334449 > On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote: > >> I received no prior response from you, so I suspect the issue is on your >> end-- since if you sent one I would normally have been directly copied. >> >> In any case, your message makes no sense. If an output is provably >> unspendable then it is unspendable. No amount of "clever steganography" >> can change that. If you're imagining that perhaps they are *presumed* = to >> be unspendable but actually *are* spendable, then sure that would be an >> issue but with any change to consensus relevant code great care must be >> taken to not introduce errors. Actually *making* a consensus change wou= ld >> only increase the potential for mistakes. >> >> These costs are just another reason why this hysteria over a non-issue i= s >> misplaced. >> >> But in any case it is better that (any) implementations that care about >> stamps put in the effort to define their exclusions in ways that are saf= e >> than to burden everyone with a consensus change that doesn't care about = it. >> >> >> On Fri, Dec 19, 2025 at 1:49=E2=80=AFAM Jonathan Voss = wrote: >> >>> This is my third attempt to respond to this. Idk what is going wrong >>> here. >>> >>> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set withou= t >>> a consensus change is that a clever use of steganography could cause on= e of >>> those otherwise unspendable outputs to be spendable, thus causing a for= k >>> between those nodes that adopted the Stamp pruning method and those tha= t >>> did not once one of those steganographic Stamps is spent. Though this i= s >>> unlikely, it is still technically possible, and I would not put it past= the >>> denizens of the Internet to stir up trouble just for its own sake. >>> >>> On Friday, December 12, 2025 at 6:49:41=E2=80=AFPM UTC-5 Greg Maxwell w= rote: >>> >>>> On Fri, Dec 12, 2025 at 9:26=E2=80=AFPM Jonathan Voss wrote: >>>> >>>>> Since the Bitcoin Stamps outputs are already unspendable, it makes >>>>> perfect sense to mark and drop them from the UTXO set. >>>> >>>> >>>> There is no consensus change involved in not storing a provably >>>> unspendable output, it's just an implementation detail with no >>>> interoperability implications and doesn't need a BIP. Bitcoin core ha= s >>>> long done so for several types of unspendable outputs, e.g. outputs ov= er >>>> 10kb and ones starting with OP_RETURN. >>>> >>>> -- >>> 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+...@googlegroups.com. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa= 66ea0cfb79n%40googlegroups.com >>> >>> . >>> >> -- > 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/959c8b53-2055-4de2-8a93-1fd1= 69f1a159n%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/= CAAS2fgSB9tymGr_cddWSRkg36NvQqoAq%2B7%3DXkpvkbP_VpuCLJg%40mail.gmail.com. --000000000000d3bc0b0646a35381 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The 'dust threshold' isn't a consensus pa= rameter, it's just a number pulled out of the air that didn't seem = unreasonable based on average fee behavior.=C2=A0 But in any particular blo= ck transactions may need no particular fee level at all, including zero fee= s.=C2=A0 And in some cases it may be very economically advantageous=C2=A0to= spend an output even if its face value doesn't support it, NFT's b= eing a one such example (although one I consider pretty dumb).
= =C2=A0
This proposal also appears to have ignored the prior discu= ssion particularly where it was pointed out that 'deleting' outputs= will not achieve the goal of deleting the tokens connected to them (so won= 't eliminate the incentive), or that txouts=C2=A0which are predictably = not going to be accessed (as this proposal claims applies to the txouts it = targets) don't have as significant performance implications (because th= ey don't need to be cached in ram).=C2=A0 It also appears to be uninfor= med=C2=A0by advances like utxotree which makes the absolute size of the txo= ut set much less important, but would make mass removals such as that descr= ibed here=C2=A0expensive.=C2=A0 Nor has it considered that given the level = of fee spending on NFT traffic a requirement to keep it over some (reasonab= le) threshold would not likely discourage it, or the fact that existent=C2= =A0NFT outputs are generally over the dust limit in any case (so the propos= als failure to meet the opcat proponents' delusional goals is already c= lear).

I think the list should adopt a 1 year ban = on parties *and their* employer(s) (if known) for any coin confiscation=C2= =A0proposal on the list going forward (after, of course, making the rule cl= ear on the signup page).=C2=A0 It's tiresome and beyond being a waste o= f time risks undermining public confidence in Bitcoin to see the constant t= rickle of these outrageous=C2=A0proposals in venues where they previously u= nderstood that serious discussions were to be had. People are, of course, f= ree to discuss whatever ill-founded concepts they want but they're not = entitled to the time and the reputation of the participants here for offens= ively misguided proposals.=C2=A0


On Tue, Dec= 23, 2025 at 6:27=E2=80=AFPM John <johnpenner151516@gmail.com> wrote:
Good evening all,

Here is a related proposal by Matteo Pellegrini
@matteopelleg


Lynx.

Abstract
This= proposal introduces a periodic, consensus-enforced mechanism for rendering= UTXOs below the network's dust threshold permanently unspendable. At e= ach halving block, UTXOs that have remained below the dust threshold since = the previous halving become unspendable. These UTXOs become unspendable and= may be pruned from the UTXO set entirely, reducing node storage requiremen= ts and eliminating the economic model that incentivizes their creation.
=
Motivation
The Bitcoin UTXO set has grown substantially due to vario= us factors, including inscription protocols, spam attacks, and general dust= accumulation. Recent proposals such as "The Cat" (Non-monetary U= TXO Cleanup) by @ostrom72158
=C2=A0 have attempted to address this by cr= eating lists of specific UTXOs to render unspendable, identified by externa= l protocol indexers.

The Cat's approach has a fatal flaw: it rel= ies on a list.

Using a curated list of "non-monetary UTXOs"= ; introduces several problems:

1) External dependency: The Cat requi= res reference indexers (Ord, Stamps, etc.) to define which UTXOs qualify. T= his introduces consensus-level dependency on external, non-Bitcoin software= that can change, have bugs, or interpret protocols differently.

2) = Protocol targeting: By specifically identifying inscription and stamp outpu= ts, the proposal makes subjective judgments about which Bitcoin uses are le= gitimate. This sets a precedent for protocol-level discrimination.

3= ) Cat-and-mouse dynamics: Targeting specific protocols incentivizes workaro= unds. If Ordinals dust is targeted, protocols will adapt to create dust tha= t doesn't match the list criteria.

4) Static snapshot: A one-tim= e list cleanup provides temporary relief but does nothing for future UTXO a= ccumulation.

5) Political vulnerability: Any list-based approach req= uires ongoing governance decisions about what belongs on the list, creating= a permanent political attack surface.

A better approach targets the= economic reality, not the use case.

UTXOs below the dust threshold = are, by definition, economically irrational to spend under normal fee condi= tions. The dust limit exists precisely because spending these outputs costs= more in fees than the output is worth. These UTXOs are already "dead&= quot; in practice; this proposal simply makes that reality explicit at the = consensus layer.

By using a threshold rather than a list, Lynx:
<= br>- Requires no external indexers
- Makes no judgment about why a UTXO = is small
- Applies equally to all participants
- Provides ongoing, pr= edictable maintenance
- Removes political discretion from the process
Impact on Inscription Protocols

The typical Ordinals inscriptio= n is stored in a UTXO containing exactly 546 sats; the minimum required to = meet the dust limit for P2PKH addresses and ensure transferability across a= ll address types. This "postage" amount is standard across inscri= ption tooling and marketplaces.

A threshold of 999 sats captures the= vast majority of inscription UTXOs without requiring any protocol-specific= targeting. The economic model of inscriptions depends on these dust-level = UTXOs being spendable; Lynx breaks that model through neutral, threshold-ba= sed rules rather than list-based discrimination.

Specification
Definitions

-=C2=A0 Dust threshold: 999 sats. Any UTXO with a valu= e less than 999 sats is subject to Lynx enforcement.

- Halving block= : A block at height N * 210,000 where N =E2=89=A5 1.

-=C2=A0 Snapsho= t block: A halving block at which the current dust threshold and qualifying= UTXOs are recorded.

-=C2=A0 Enforcement block: The halving block fo= llowing a snapshot block (i.e., snapshot block + 210,000 blocks).

Ly= nx UTXOs:
- Existed at the snapshot block
- Had a value less than 999= sats
- Remained unspent through the enforcement period (~4 years)
Consensus Rules
After activation, the following rules apply:

1)= Snapshot: At each halving block H, record the set of all UTXOs with value = < 999 sats.

2) Enforcement: At halving block H + 210,000:
- An= y UTXO that was in the snapshot set and remains unspent becomes permanently= unspendable
- Transactions attempting to spend these UTXOs are invalid<= br>
3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their= local UTXO set. Transactions referencing unknown outpoints are already rej= ected as invalid; pruned Lynx UTXOs are simply treated as if they were alre= ady spent.

4) Grace period: The ~4 year window between snapshot and = enforcement provides ample time for holders to consolidate sub-dust UTXOs i= f they wish to preserve the value.

Activation

Activation meth= od: TBD (Speedy Trial, BIP8, or other mechanism as determined by community = consensus)

Recommended first snapshot: The halving following activat= ion lock-in

Rationale

Why a fixed threshold?

Using a f= ixed threshold of 999 sats rather than referencing the dynamic relay dust l= imit provides:

- Simplicity: One number, no script-type variations, = no need to query policy settings

- Predictability: Everyone knows ex= actly what qualifies, forever

- Consensus clarity: No ambiguity abou= t which outputs are affected.

Why tie to the halving?

The hal= ving is Bitcoin's most recognized Schelling point, using it provides:
- Predictability: Everyone knows exactly when halvings occur
- Suf= ficient notice: ~4 years is generous warning for any cleanup action
- Al= igned incentives: As block rewards decrease, fee revenue and UTXO efficienc= y become more critical to network sustainability
- Natural cadence: The = halving already represents a moment of network-wide coordination

Why= not a one-time cleanup?

A one-time cleanup (as proposed by The Cat)= provides temporary relief but creates no ongoing pressure against dust acc= umulation. Periodic enforcement:

- Establishes a permanent, predicta= ble norm
- Removes any expectation that dust UTXOs have indefinite longe= vity
- Discourages business models built on dust creation
- Provides = continuous UTXO set maintenance

Why pruning works without a list
=
A key insight enables pruning without maintaining a separate list: Bitc= oin nodes already reject transactions that reference unknown outpoints. Whe= n a node receives a transaction spending an outpoint not in its UTXO set, i= t rejects it as invalid =E2=80=94 the node doesn't need to know why the= outpoint is missing (spent? never existed? pruned?).

After enforcem= ent, a Lynx UTXO is functionally equivalent to a spent output. Nodes can si= mply delete it from the UTXO set. Any future transaction attempting to spen= d it will reference an outpoint the node doesn't recognize, and will be= rejected through existing validation logic.

This means:

- No= separate "Lynx list" is required
- No new validation logic is= needed
- Pruning is optional; nodes MAY keep Lynx UTXOs if they wish- The UTXO set shrinks naturally as nodes prune

Why 999 sats?
The threshold of 999 sats is chosen because:

- Above all dust limi= ts: Captures UTXOs at or below the dust limit for all script types (P2PKH: = 546, P2TR: 330, etc.)
- Captures all standard inscriptions: Typical insc= ription UTXOs contain exactly 546 sats as "postage"; well under 9= 99
- Simple and memorable: A clean number that's easy to communicate= and reason about

Backward Compatibility

This is a soft fork.= Nodes that do not upgrade will:

- Continue to consider all historic= al transactions valid
- Accept blocks that exclude spends of Lynx UTXOs<= br>- Eventually converge with upgraded nodes (as upgraded miners will not i= nclude invalid spends)

Wallets & Services should:

- Warn = users holding sub-threshold UTXOs after a snapshot block
- Provide conso= lidation tools during the grace period
- Update UTXO selection algorithm= s to deprioritize or exclude sub-threshold outputs approaching a snapshot
Security Considerations

No confiscation

This proposal d= oes not transfer value to any party. Sub-threshold UTXOs become unspendable= , similar to:

- Lost private keys
- Provably unspendable OP_RETUR= N outputs
- Satoshi's untouched coinbase rewards

The bitcoin = supply cap remains unchanged; the affected outputs simply become irrecovera= ble. Holders receive ~4 years notice to consolidate if they value the sats.=

Lightning Network

Some Lightning implementations create smal= l HTLCs and dust outputs during channel operations. Analysis is needed to d= etermine:

- Whether current dust thresholds affect normal LN operati= ons
- If LN implementations need adjustment before activation
- Wheth= er channel close scenarios create sub-threshold outputs

Preliminary = assessment: LN dust limits are already set conservatively above relay dust = limits, so impact should be minimal. However, this requires verification fr= om LN implementers.

Fixed threshold vs. future fee markets

Th= e 999 satoshi threshold is fixed in consensus rules and does not adjust bas= ed on fee market conditions.=C2=A0
This is intentional:

- A fixed= threshold provides certainty for users and developers
- If fee markets = change dramatically, a future soft fork could adjust the threshold
- The= ~4 year grace period allows the community to observe and adapt

If B= itcoin's fee market evolves such that 999 sats becomes economically sig= nificant to spend, this would indicate broader success of the network; and = the community could choose to lower or eliminate the threshold through a su= bsequent proposal.

Acknowledgments
This proposal builds on the pr= oblem identification in "The Cat" (Non-monetary UTXO Cleanup) whi= le proposing a list-free alternative mechanism. The Cat correctly identifie= s UTXO bloat as a problem worth solving; Lynx offers a more neutral solutio= n.


https://x.com/matteopelleg/s= tatus/2000602318346334449
On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Ma= xwell wrote:
I received no prior response from you, so I suspect the = issue is on your end-- since if you sent one I would normally have been dir= ectly copied.=C2=A0

In any case, your message make= s no sense. If an output is provably unspendable then it is unspendable.=C2= =A0 No amount of "clever steganography" can change that.=C2=A0 = =C2=A0If you're imagining that perhaps they are *presumed* to be unspen= dable but actually *are* spendable, then sure that would be an issue but wi= th any change to consensus relevant code great care must be taken to not in= troduce errors.=C2=A0 Actually *making* a consensus change would only incre= ase the potential for mistakes.

These costs are ju= st another reason why this hysteria over a non-issue is misplaced.

But in any case it is better that (any) implementations th= at care about stamps put in the effort to define their exclusions in ways t= hat are safe than to burden everyone with a consensus change that doesn'= ;t care about it.


=
On F= ri, Dec 19, 2025 at 1:49=E2=80=AFAM Jonathan Voss <k= 98...@gmail.com> wrote:
This is my third attempt to= respond to this. Idk what is going wrong here.

The prob= lem with dropping Bitcoin Stamps UTXOs from the UTXO set without a consensu= s change is that a clever use of steganography could cause one of those oth= erwise unspendable outputs to be spendable, thus causing a fork between tho= se nodes that adopted the Stamp pruning method and those that did not once = one of those steganographic Stamps is spent. Though this is unlikely, it is= still technically possible, and I would not put it past the denizens of th= e Internet to stir up trouble just for its own sake.

On Friday, Decembe= r 12, 2025 at 6:49:41=E2=80=AFPM UTC-5 Greg Maxwell wrote:
On Fri, Dec 12, 2025 at 9:26=E2=80=AFPM Jonathan Voss <k98...@gmail.com> wrote:
Since th= e Bitcoin Stamps outputs are already unspendable, it makes perfect sense to= mark and drop them from the UTXO set.

There is no consensus c= hange involved in not storing a provably unspendable output, it's just = an implementation detail with no interoperability implications and doesn= 9;t need a BIP.=C2=A0 Bitcoin core has long done so for several types of un= spendable outputs, e.g. outputs over 10kb and ones starting with OP_RETURN.=

--
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+...@googlegroups.com.
To view this discussion visit htt= ps://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cf= b79n%40googlegroups.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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%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/msgid/bitcoindev/CAAS2fgSB9tymGr_cddWSRkg36NvQqoAq%2B7%3DXkpvkbP_VpuCLJg%= 40mail.gmail.com.
--000000000000d3bc0b0646a35381--