From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 23 Dec 2025 10:27:33 -0800 Received: from mail-qv1-f56.google.com ([209.85.219.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vY76Z-0001Sk-FS for bitcoindev@gnusha.org; Tue, 23 Dec 2025 10:27:32 -0800 Received: by mail-qv1-f56.google.com with SMTP id 6a1803df08f44-88a366fa140sf244940936d6.1 for ; Tue, 23 Dec 2025 10:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766514445; x=1767119245; 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:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=Gom/FA4resgwQ81m6D92ivNONK8YKhst+CW940lIL5M=; b=h/E6DXIC/La3M7hejW1L/RAOd2yYYic3qBEFP8TUERE0rjaGX4JRU18L9lXPBNfQVs 5JqFrlH8I3eLzA2cV3yNFBo+jkuCI5/xpFBFKxzFc3VzBJAdySGWC5lzeqG94dWUSoJW wMMPeGftY4Y3zcw1MvGsjAl5rGkOTEweN5W4v3c1JNm67WRbmRlCeTLzB2R+32EIT1My ZlFN9E4tKHkg/T/TllqS5HdHhZbCjP6h1HC6C3sDoMbz24mqLgkvPo7Z9X6wGL6060vf RwJ5quuPb1F/HX+3etPeP3J3jWidESVhlki9+dhnts4TYszJQUWmwtwsbbCHcKAURoKQ 9bHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766514445; x=1767119245; 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:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=Gom/FA4resgwQ81m6D92ivNONK8YKhst+CW940lIL5M=; b=D3ntfsdV6ZFbqfzpwFIx2Hs8ui83cuUtomJmU/S42OPS+9Q27y/LYcpM+UMfRmDnqc lI0KGf0wK9t7pCTQkrBUY/D/s+Iy582791t9UIW8R35i1r6YzPT2UnjvGd6ksLMAQSJs Il/ouOvplmveFX/BMUFsdtnUThesPfAcCV4+xxadUnU4m+9BL9FdAPsJsdckAP6x+7fB 8HhEWRYIHpRZmS8haWnRQyRChRFys6EJOtcWxsSk6DxXa0rkTHmsRPdzm/k6N7mj7hWA vz1MbsncxJFUDap4NQdfqCYhQ2mTL+bt/8pqfOorDhuBRAatM4A9vas0hpGytrhcjm3j zHvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766514445; x=1767119245; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=Gom/FA4resgwQ81m6D92ivNONK8YKhst+CW940lIL5M=; b=ORctqPhNZJUsf+BHal8oB3vdUfsFUTDyy86V7fDLfBLCOiU8P7Htt6A6CjtXDAgvjj bDlG0gsEe23Xxw2P4JdmrG5P/6m9hfFknGcOw8yFyMaP9i0n5x1d2di2swmLtOkCffk6 037f5Wx3QCjqyGtOeSgycdZ+6lhdNnt0gMXfho97ZeXuKwgSDYbx+U+MemzS01X3eYlq e4M2fleyqk84jXRwG8qW5L1pbQquZZC3ZFmcXjgnTa/VaxjG34LaK1jgYCbq5NN5Pseh QIRoCH3Og95Ucb30BBgKQlgJvkp6548DEEuy1oX9+Ft+1I9qECiJLh9NH/mZX2OArC8B 7qVA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUjdUPo7hC3lPc7n/rOzulRvxkJykrMi2Wx0uH9A0q+P/o8tcDjlpxYHmKhu8s35whKIwbN0XHwpRJx@gnusha.org X-Gm-Message-State: AOJu0YzJZErAAY02dWa4jdGXbtQo9eqetLAUm5Tt3bn0rROnhprm9MOj T5pEPIUOEQ9o63c2678kcOlIVwayCDQNhK8DxJ8DZwZjsevj2271Y6hJ X-Google-Smtp-Source: AGHT+IE863YW0lYszH/WPH3tLOY+mDq7FzjATa5K2it0X8mJqYmuEA+KfevfvrkpNZyTnkUUJ5CF/g== X-Received: by 2002:a05:622a:4cce:b0:4ed:4548:ac65 with SMTP id d75a77b69052e-4f4abd806f9mr238619921cf.42.1766514444964; Tue, 23 Dec 2025 10:27:24 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbixKcZR8IFs1rN0Xk1QzEden6W3WVAURmwF0SAfEGv1g==" Received: by 2002:ac8:5f0c:0:b0:4ed:9424:fa31 with SMTP id d75a77b69052e-4f1ced7d36fls181563201cf.2.-pod-prod-01-us; Tue, 23 Dec 2025 10:27:19 -0800 (PST) X-Received: by 2002:a05:620a:4555:b0:8b2:7224:b25b with SMTP id af79cd13be357-8c08f652fb7mr2464939485a.16.1766514439639; Tue, 23 Dec 2025 10:27:19 -0800 (PST) Received: by 2002:a05:690c:7509:b0:78f:a59b:47c with SMTP id 00721157ae682-78fb3c3a601ms7b3; Sat, 20 Dec 2025 21:07:11 -0800 (PST) X-Received: by 2002:a05:690e:4192:b0:644:60d9:7510 with SMTP id 956f58d0204a3-6466a924b6dmr5014165d50.96.1766293630616; Sat, 20 Dec 2025 21:07:10 -0800 (PST) Date: Sat, 20 Dec 2025 21:07:10 -0800 (PST) From: John To: Bitcoin Development Mailing List Message-Id: <959c8b53-2055-4de2-8a93-1fd169f1a159n@googlegroups.com> In-Reply-To: References: <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com> <4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n@googlegroups.com> Subject: Re: [bitcoindev] Re: The Cat, BIP draft discussion. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_126078_1677013315.1766293630184" X-Original-Sender: johnpenner151516@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_126078_1677013315.1766293630184 Content-Type: multipart/alternative; boundary="----=_Part_126079_391364954.1766293630184" ------=_Part_126079_391364954.1766293630184 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good evening all, Here is a related proposal by Matteo Pellegrini @matteopelleg Lynx. Abstract This proposal introduces a periodic, consensus-enforced mechanism for=20 rendering UTXOs below the network's dust threshold permanently unspendable.= =20 At each halving block, UTXOs that have remained below the dust threshold=20 since the previous halving become unspendable. These UTXOs become=20 unspendable and may be pruned from the UTXO set entirely, reducing node=20 storage requirements and eliminating the economic model that incentivizes= =20 their creation. Motivation The Bitcoin UTXO set has grown substantially due to various factors,=20 including inscription protocols, spam attacks, and general dust=20 accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO=20 Cleanup) by @ostrom72158 have attempted to address this by creating lists of specific UTXOs to=20 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,= =20 etc.) to define which UTXOs qualify. This introduces consensus-level=20 dependency on external, non-Bitcoin software that can change, have bugs, or= =20 interpret protocols differently. 2) Protocol targeting: By specifically identifying inscription and stamp=20 outputs, the proposal makes subjective judgments about which Bitcoin uses= =20 are legitimate. This sets a precedent for protocol-level discrimination. 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes=20 workarounds. If Ordinals dust is targeted, protocols will adapt to create= =20 dust that doesn't match the list criteria. 4) Static snapshot: A one-time list cleanup provides temporary relief but= =20 does nothing for future UTXO accumulation. 5) Political vulnerability: Any list-based approach requires ongoing=20 governance decisions about what belongs on the list, creating a permanent= =20 political attack surface. A better approach targets the economic reality, not the use case. UTXOs below the dust threshold are, by definition, economically irrational= =20 to spend under normal fee conditions. The dust limit exists precisely=20 because spending these outputs costs more in fees than the output is worth.= =20 These UTXOs are already "dead" in practice; this proposal simply makes that= =20 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= =20 sats; the minimum required to meet the dust limit for P2PKH addresses and= =20 ensure transferability across all address types. This "postage" amount is= =20 standard across inscription tooling and marketplaces. A threshold of 999 sats captures the vast majority of inscription UTXOs=20 without requiring any protocol-specific targeting. The economic model of=20 inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks= =20 that model through neutral, threshold-based rules rather than list-based=20 discrimination. Specification Definitions - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is=20 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 and= =20 qualifying UTXOs are recorded. - Enforcement block: The halving block following a snapshot block (i.e.,= =20 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=20 value < 999 sats. 2) Enforcement: At halving block H + 210,000: - Any UTXO that was in the snapshot set and remains unspent becomes=20 permanently unspendable - Transactions attempting to spend these UTXOs are invalid 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their local= =20 UTXO set. Transactions referencing unknown outpoints are already rejected= =20 as invalid; pruned Lynx UTXOs are simply treated as if they were already=20 spent. 4) Grace period: The ~4 year window between snapshot and enforcement=20 provides ample time for holders to consolidate sub-dust UTXOs if they wish= =20 to preserve the value. Activation Activation method: TBD (Speedy Trial, BIP8, or other mechanism as=20 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=20 relay dust limit provides: - Simplicity: One number, no script-type variations, no need to query=20 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=20 efficiency become more critical to network sustainability - Natural cadence: The halving already represents a moment of network-wide= =20 coordination Why not a one-time cleanup? A one-time cleanup (as proposed by The Cat) provides temporary relief but= =20 creates no ongoing pressure against dust accumulation. Periodic enforcement= : - 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: Bitcoin= =20 nodes already reject transactions that reference unknown outpoints. When a= =20 node receives a transaction spending an outpoint not in its UTXO set, it=20 rejects it as invalid =E2=80=94 the node doesn't need to know why the outpo= int is=20 missing (spent? never existed? pruned?). After enforcement, a Lynx UTXO is functionally equivalent to a spent=20 output. Nodes can simply delete it from the UTXO set. Any future=20 transaction attempting to spend it will reference an outpoint the node=20 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 all= =20 script types (P2PKH: 546, P2TR: 330, etc.) - Captures all standard inscriptions: Typical inscription UTXOs contain=20 exactly 546 sats as "postage"; well under 999 - Simple and memorable: A clean number that's easy to communicate and=20 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=20 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= =20 outputs approaching a snapshot Security Considerations No confiscation This proposal does not transfer value to any party. Sub-threshold UTXOs=20 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=20 become irrecoverable. Holders receive ~4 years notice to consolidate if=20 they value the sats. Lightning Network Some Lightning implementations create small HTLCs and dust outputs during= =20 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= =20 relay dust limits, so impact should be minimal. However, this requires=20 verification from LN implementers. Fixed threshold vs. future fee markets The 999 satoshi threshold is fixed in consensus rules and does not adjust= =20 based on fee market conditions.=20 This is intentional: - A fixed threshold provides certainty for users and developers - If fee markets change dramatically, a future soft fork could adjust the= =20 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=20 significant to spend, this would indicate broader success of the network;= =20 and the community could choose to lower or eliminate the threshold through= =20 a subsequent proposal. Acknowledgments This proposal builds on the problem identification in "The Cat"=20 (Non-monetary UTXO Cleanup) while proposing a list-free alternative=20 mechanism. The Cat correctly identifies UTXO bloat as a problem worth=20 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= =20 > end-- since if you sent one I would normally have been directly copied.= =20 > > In any case, your message makes no sense. If an output is provably=20 > unspendable then it is unspendable. No amount of "clever steganography"= =20 > can change that. If you're imagining that perhaps they are *presumed* t= o=20 > be unspendable but actually *are* spendable, then sure that would be an= =20 > issue but with any change to consensus relevant code great care must be= =20 > taken to not introduce errors. Actually *making* a consensus change woul= d=20 > only increase the potential for mistakes. > > These costs are just another reason why this hysteria over a non-issue is= =20 > misplaced. > > But in any case it is better that (any) implementations that care about= =20 > stamps put in the effort to define their exclusions in ways that are safe= =20 > than to burden everyone with a consensus change that doesn't care about i= t. > > > 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 her= e. >> >> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without= =20 >> a consensus change is that a clever use of steganography could cause one= of=20 >> those otherwise unspendable outputs to be spendable, thus causing a fork= =20 >> between those nodes that adopted the Stamp pruning method and those that= =20 >> did not once one of those steganographic Stamps is spent. Though this is= =20 >> unlikely, it is still technically possible, and I would not put it past = the=20 >> 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 wr= ote: >> >>> On Fri, Dec 12, 2025 at 9:26=E2=80=AFPM Jonathan Voss wrote: >>> >>>> Since the Bitcoin Stamps outputs are already unspendable, it makes=20 >>>> perfect sense to mark and drop them from the UTXO set. >>> >>> >>> There is no consensus change involved in not storing a provably=20 >>> unspendable output, it's just an implementation detail with no=20 >>> interoperability implications and doesn't need a BIP. Bitcoin core has= =20 >>> long done so for several types of unspendable outputs, e.g. outputs ove= r=20 >>> 10kb and ones starting with OP_RETURN. >>> >>> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa6= 6ea0cfb79n%40googlegroups.com=20 >> >> . >> > --=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/= 959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com. ------=_Part_126079_391364954.1766293630184 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good evening all,

Here is a related proposa= l by Matteo Pellegrini
@matteopelleg



Lynx.

Abstract
This proposal introdu= ces a periodic, consensus-enforced mechanism for rendering UTXOs below the = network's dust threshold permanently unspendable. At each halving block, UT= XOs that have remained below the dust threshold since the previous halving = become unspendable. These UTXOs become unspendable and may be pruned from t= he UTXO set entirely, reducing node storage requirements and eliminating th= e economic model that incentivizes their creation.

MotivationThe Bitcoin UTXO set has grown substantially due to various factors, inc= luding inscription protocols, spam attacks, and general dust accumulation. = Recent proposals such as "The Cat" (Non-monetary UTXO Cleanup) by @ostrom72= 158
=C2=A0 have attempted to address this by creating lists of specifi= c 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 (O= rd, Stamps, etc.) to define which UTXOs qualify. This introduces consensus-= level dependency on external, non-Bitcoin software that can change, have bu= gs, or interpret protocols differently.

2) Protocol targeting: B= y specifically identifying inscription and stamp outputs, the proposal make= s subjective judgments about which Bitcoin uses are legitimate. This sets a= precedent for protocol-level discrimination.

3) Cat-and-mouse d= ynamics: Targeting specific protocols incentivizes workarounds. If Ordinals= dust is targeted, protocols will adapt to create dust that doesn't match t= he list criteria.

4) Static snapshot: A one-time list cleanup pr= ovides 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 irrational to spend under normal fee conditions= . The dust limit exists precisely because spending these outputs costs more= in fees than the output is worth. These UTXOs are already "dead" in practi= ce; this proposal simply makes that reality explicit at the consensus layer= .

By using a threshold rather than a list, Lynx:

- Re= quires no external indexers
- Makes no judgment about why a UTXO is sm= all
- Applies equally to all participants
- Provides ongoing, pre= dictable maintenance
- Removes political discretion from the process
Impact on Inscription Protocols

The typical Ordinals i= nscription is stored in a UTXO containing exactly 546 sats; the minimum req= uired to meet the dust limit for P2PKH addresses and ensure transferability= across all address types. This "postage" amount is standard across inscrip= tion tooling and marketplaces.

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

Specificatio= n

Definitions

-=C2=A0 Dust threshold: 999 sats. Any U= TXO 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.

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

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

Lynx UTXOs:
- Existed at the snapshot blo= ck
- Had a value less than 999 sats
- Remained unspent through th= e enforcement period (~4 years)

Consensus Rules
After activ= ation, the following rules apply:

1) Snapshot: At each halving b= lock 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
- Tr= ansactions attempting to spend these UTXOs are invalid

3) Prunin= g: After enforcement, nodes MAY prune Lynx UTXOs from their local 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 wish = to preserve the value.

Activation

Activation method: = TBD (Speedy Trial, BIP8, or other mechanism as determined by community cons= ensus)

Recommended first snapshot: The halving following activat= ion 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-t= ype variations, no need to query policy settings

- Predictabilit= y: Everyone knows exactly what qualifies, forever

- Consensus cl= arity: 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 exac= tly when halvings occur
- Sufficient notice: ~4 years is generous warn= ing for any cleanup action
- Aligned incentives: As block rewards decr= ease, fee revenue and UTXO efficiency become more critical to network susta= inability
- Natural cadence: The halving already represents a moment o= f network-wide coordination

Why not a one-time cleanup?
A one-time cleanup (as proposed by The Cat) provides temporary relief bu= t creates no ongoing pressure against dust accumulation. Periodic enforceme= nt:

- Establishes a permanent, predictable norm
- Removes a= ny 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 i= nsight enables pruning without maintaining a separate list: Bitcoin nodes a= lready reject transactions that reference unknown outpoints. When a node re= ceives a transaction spending an outpoint not in its UTXO set, it rejects i= t as invalid =E2=80=94 the node doesn't need to know why the outpoint is mi= ssing (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 r= eference an outpoint the node doesn't recognize, and will be rejected throu= gh existing validation logic.

This means:

- No separa= te "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?

T= he threshold of 999 sats is chosen because:

- Above all dust lim= its: Captures UTXOs at or below the dust limit for all script types (P2PKH:= 546, P2TR: 330, etc.)
- Captures all standard inscriptions: Typical i= nscription UTXOs contain exactly 546 sats as "postage"; well under 999
- Simple and memorable: A clean number that's easy to communicate and reas= on about

Backward Compatibility

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

- Continue to consider all histo= rical transactions valid
- Accept blocks that exclude spends of Lynx U= TXOs
- Eventually converge with upgraded nodes (as upgraded miners wil= l 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 appro= aching a snapshot

Security Considerations

No confisca= tion

This proposal does not transfer value to any party. Sub-thr= eshold UTXOs become unspendable, similar to:

- Lost private keys=
- Provably unspendable OP_RETURN outputs
- Satoshi's untouched c= oinbase rewards

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

Lightning Network
<= br />Some Lightning implementations create small HTLCs and dust outputs dur= ing channel operations. Analysis is needed to determine:

- Wheth= er current dust thresholds affect normal LN operations
- If LN impleme= ntations need adjustment before activation
- Whether channel close sce= narios create sub-threshold outputs

Preliminary assessment: LN d= ust limits are already set conservatively above relay dust limits, so impac= t should be minimal. However, this requires verification from LN implemente= rs.

Fixed threshold vs. future fee markets

The 999 sa= toshi threshold is fixed in consensus rules and does not adjust based on fe= e market conditions.=C2=A0
This is intentional:

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

If Bitcoin's fee market evolves such that 999 sats becomes economically s= ignificant to spend, this would indicate broader success of the network; an= d the community could choose to lower or eliminate the threshold through a = subsequent proposal.

Acknowledgments
This proposal builds o= n 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/2= 000602318346334449
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 co= pied.=C2=A0

In any case, your message makes no sen= se. If an output is provably unspendable then it is unspendable.=C2=A0 No a= mount of "clever steganography" can change that.=C2=A0 =C2=A0If y= ou're imagining that perhaps they are *presumed* to be unspendable but = actually *are* spendable, then sure that would be an issue but with any cha= nge to consensus relevant code great care must be taken to not introduce er= rors.=C2=A0 Actually *making* a consensus change would only increase the po= tential for mistakes.

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

But in any case it is better that (any) implementations that care ab= out stamps put in the effort to define their exclusions in ways that are sa= fe than to burden everyone with a consensus change that doesn't care ab= out it.


On Fri, Dec 19= , 2025 at 1:49=E2=80=AFAM Jonathan Voss <k98...@gmail.com> wrote:
This is my t= hird attempt to respond to this. Idk what is going wrong here.

The problem with dropping Bitcoin Stamps UTXOs from the UTXO set wit= hout a consensus change is that a clever use of steganography could cause o= ne of those otherwise unspendable outputs to be spendable, thus causing a f= ork 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 is = 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 wrote:
=
On Fri, Dec 12, 2025 at 9:26=E2=80=AFPM Jonathan Voss <= k98...@gmail.com> wrote:
Since the Bitcoin Stamps outputs are already unspendable, it makes p= erfect 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 implicatio= ns and doesn't need a BIP.=C2=A0 Bitcoin core has long done so for seve= ral types of unspendable 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+...@googlegro= ups.com.
To view this discussion visit ht= tps://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0c= fb79n%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com.
------=_Part_126079_391364954.1766293630184-- ------=_Part_126078_1677013315.1766293630184--