From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 10 Dec 2025 10:34:46 -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 1vTP1Q-00031w-VG for bitcoindev@gnusha.org; Wed, 10 Dec 2025 10:34:46 -0800 Received: by mail-qt1-f190.google.com with SMTP id d75a77b69052e-4ee21a0d326sf1751041cf.3 for ; Wed, 10 Dec 2025 10:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765391678; x=1765996478; 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=mNmJhjTS7hrPl9WgYMPSYJme+VWfTakHNZYT9/V9LCE=; b=fFji/uKIELSwsHa6/JoEFBu1cCvl1qgnr75ra8NFqN25EfPgDMruXc40SfFRky8emp D9CxXCiYvXVGAkMwPxf9KXtQvZb6tf4Fv5gpUzQxuCrGmBo9PALE8XGMk4IoTJSX5Mt0 euoAl1vJpORS8acwEX+TTwJ1oQR8uzuP85dMJ6M458U7INru/pYoELVmVScpgmW5qQ37 AjvsDU/4i/s/buPE39Y8EQD1pQchkI+VeJw3OUZMRd6tw0OVjn3OJGw7CgZLB+AcaFpI JYrlSIWEfTzcHstbHZ5FskNO3nreNzLjzh0XaSrg9AwzURxStcxO9KyvKXp8v4cPHOoH 10VQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil.org; s=google; t=1765391678; x=1765996478; 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=mNmJhjTS7hrPl9WgYMPSYJme+VWfTakHNZYT9/V9LCE=; b=YNe1b4DAgk5nV6GJZMwFGCkJfvYjL8VJssZXVv+fSm2uWqoQg9W1y8D/G/FwW6kkhg K5XKhA9ihoK0zX2ikZyU07bocASTKH5y5ZtcKvDHCfdiq9UwEum+NXkb+qwmKRiMN1oL aQZX/MkX1jvPdHHSQLbNhocYY7yEAc/Ogp08X3N3Si8eLrEpijub4dPA0rJweXzGUo9w bXQiJUkT92rcQ9+YuQuWcqsjbXIHFVPbgx0q+7WT2I2XCh0ZyBqp6FiP37mwvXhUFqxx jIpkCQ3cLzLAyoFXlTB/hrcVDmc80/KjUn0pD3B9pFLQEQdsz9DO4Wq3tBhbE9fWkPao zQrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765391678; x=1765996478; 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=mNmJhjTS7hrPl9WgYMPSYJme+VWfTakHNZYT9/V9LCE=; b=QoaqL1lumQAHHuaIeh6Nnx4gBve+n0qxLCHnsMSGUOqPgdKpZYuVMjvvCK5SWbkPmL Vh0fADIf7bRB7vzZZhCWeANNPb3LQrrgDNaivq/QrJrxHN+K18aVCTDV8KbdfYgnyBFI McefsKLGb0D6T5WStYmkFT1TMsMz8hJgCw25yTiu+joCUY6Hz4CSy2f6idbRdhyXxC9Y sh3IEOF2RFtlt8Qqs/h8RM4rLy1Oo0IRQkcwUVWM30hE1VoNblFFFgytZrCs+Xbdtw1O hj87zG77lslnaTiBa59JJrAcTmiBxNB+ff+sY7uf8Qm9Y3tyWIZQY1um07govVbK+cxC fX9A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUFXvzwydbMryCDOtaOiZSa27SylAIxn5uY1tCD2pHVpS2ATgE46XNNt+zyuSM8jIG/F7yGtEZEcbNh@gnusha.org X-Gm-Message-State: AOJu0Yyq+ULL60vFRi6X7Q7nOtpgDAEW29eQdUY0TEqEHdk2WFbwEwDi Ci6qc7e+ZPYkza6npqCPmMNuz0UT+ttxrJ6azqgPArJyfe5OV+urn/hH X-Google-Smtp-Source: AGHT+IEnf+/jjZyp8QacyS/X0wHFXpTPDMOQqTWUL6JXtxfEyytXbcm56RihE8sNThpAufEE+LaALg== X-Received: by 2002:a05:622a:8d07:b0:4f1:b61d:f43a with SMTP id d75a77b69052e-4f1b61df4c7mr24526491cf.28.1765391678044; Wed, 10 Dec 2025 10:34:38 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYy6nwpWG3YjnH3s63Sgb85NrdhQ66FkkW+xQgCF8sf/w==" Received: by 2002:ac8:5dd0:0:b0:4b0:8b27:4e49 with SMTP id d75a77b69052e-4f1bd8f2302ls589421cf.0.-pod-prod-02-us; Wed, 10 Dec 2025 10:34:33 -0800 (PST) X-Received: by 2002:a05:620a:7119:b0:8b2:e069:690a with SMTP id af79cd13be357-8ba3a45e603mr540318485a.68.1765391673103; Wed, 10 Dec 2025 10:34:33 -0800 (PST) Received: by 2002:a05:690c:9314:b0:78a:986f:9439 with SMTP id 00721157ae682-78c5aaeb8d7ms7b3; Wed, 10 Dec 2025 10:30:24 -0800 (PST) X-Received: by 2002:a05:690c:3382:b0:786:6b92:b1f6 with SMTP id 00721157ae682-78c95aba7b1mr29825637b3.14.1765391423375; Wed, 10 Dec 2025 10:30:23 -0800 (PST) Date: Wed, 10 Dec 2025 10:30:22 -0800 (PST) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: <049858f4-28ba-4ffb-8966-f8bef09035b7n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Reducing RAM requirements with dynamic dust MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_998602_941663234.1765391422961" X-Original-Sender: eric@voskuil.org 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.7 (/) ------=_Part_998602_941663234.1765391422961 Content-Type: multipart/alternative; boundary="----=_Part_998603_223578563.1765391422961" ------=_Part_998603_223578563.1765391422961 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Given the increasing RAM requirements, due to the increasing UTXO set I have been assured multiple times recently that this problem does not=20 exist in Bitcoin Core. I'm not sure about that, but I can say for sure that= =20 this is not a problem in Libbitcoin and is therefore not problem with the= =20 Bitcoin protocol. Best, Eric On Wednesday, December 10, 2025 at 1:12:31=E2=80=AFPM UTC-5 uuowwpevskfcord= h wrote: > Given the increasing RAM requirements, due to the increasing UTXO set, I= =20 > suggest seeing the UTXO set size as a controlled variable. A feedback=20 > mechanism sets a dynamic dust level, below from which UTXOs are=20 > removed/discarded and thus freeing RAM. > > Below is an overview essay better expressed by grok, which can also be=20 > seen in here: > https://hackmd.io/P-2lzGb8TiC86IOE3OGiYA?view > > # Enhancing Bitcoin's Scalability: A PID-Inspired Approach to Managing=20 > UTXO Set Growth > > ## Abstract > > Bitcoin=E2=80=99s UTXO set is currently an unbounded accumulator that ris= ks=20 > long-term centralization as node RAM requirements grow without limit.=20 > Existing fee incentives have proven insufficient against sustained=20 > low-value output creation (e.g., inscriptions, tokenized assets, dust-hea= vy=20 > protocols). This article proposes a soft-fork mechanism that treats UTXO= =20 > set size as a controlled variable: a slowly rising target size is defined= ,=20 > and a PID-style feedback controller, updated every difficulty epoch,=20 > dynamically raises a minimum-value floor beneath which old UTXOs become= =20 > unspendable. The result is bounded, predictable growth of the UTXO set wi= th=20 > ample warning periods, no hard caps on monetary use, and strong resistanc= e=20 > to bloat attacks=E2=80=94all while remaining fully compatible with a soft= -fork=20 > deployment. > > ## Introduction > > Bitcoin, the pioneering decentralized digital currency, operates as a=20 > complex dynamic system governed by consensus rules that ensure security,= =20 > immutability, and permissionless participation. At its core, Bitcoin=20 > maintains a distributed ledger known as the blockchain, which records all= =20 > transactions in a sequence of blocks. Each transaction involves inputs an= d=20 > outputs: inputs reference previously unspent outputs from prior=20 > transactions, while outputs create new spendable units called Unspent=20 > Transaction Outputs (UTXOs). The UTXO set represents the aggregate state = of=20 > all currently spendable coins in the network, serving as a critical=20 > component for transaction validation and wallet management. > > As Bitcoin has evolved, the UTXO set has grown significantly, influenced= =20 > by increasing adoption and diverse usage patterns. This growth, while=20 > indicative of the network's vitality, poses challenges to its long-term= =20 > scalability and decentralization. Nodes=E2=80=94computers that validate a= nd relay=20 > transactions=E2=80=94must store and process the entire UTXO set in memory= for=20 > efficient operation, which can strain resources such as random access=20 > memory (RAM). Unchecked expansion could lead to higher barriers for runni= ng=20 > full nodes, potentially centralizing control among fewer, well-resourced= =20 > participants. This article explores a proposed mechanism to address these= =20 > concerns: an adaptive control system inspired by=20 > Proportional-Integral-Derivative (PID) feedback principles, designed to= =20 > impose bounded growth on the UTXO set while preserving Bitcoin's=20 > foundational properties. > > ## Motivations for UTXO Set Management > > To appreciate the need for enhanced UTXO management, it is essential to= =20 > understand the current status quo and its vulnerabilities. Bitcoin's desi= gn=20 > prioritizes efficiency and security through mechanisms like block size=20 > limits, which cap the amount of data added per block (approximately 1 MB= =20 > base size, expandable to about 4 MB with Segregated Witness). These limit= s=20 > help control the overall blockchain size, ensuring predictable hardware= =20 > requirements for storage on hard disk drives (HDDs). Similarly, the=20 > difficulty adjustment algorithm maintains a consistent block production= =20 > rate of roughly one every 10 minutes by dynamically scaling the=20 > computational challenge for miners based on network hashrate. > > However, the UTXO set lacks comparable built-in constraints. It=20 > accumulates as users create new outputs=E2=80=94often in small=20 > denominations=E2=80=94without a mandatory mechanism to consolidate or pru= ne them.=20 > This can result from various activities, including high-frequency=20 > microtransactions, the embedding of non-monetary data (such as through=20 > protocols like Ordinals, which inscribe arbitrary information onto=20 > satoshis, Bitcoin's smallest unit), or the anchoring of sidechain or=20 > tokenized assets that leverage Bitcoin's security but operate externally.= =20 > While these innovations expand Bitcoin's utility, they can inadvertently= =20 > increase the UTXO count disproportionately to their economic value,=20 > elevating transaction fees during congestion and raising operational cost= s=20 > for nodes. > > Existing incentives, such as transaction fees, partially mitigate this by= =20 > encouraging users to consolidate low-value UTXOs to avoid higher costs.= =20 > Yet, these market-driven forces are insufficient against sustained patter= ns=20 > of low-value output creation, particularly when driven by external system= s=20 > that do not bear the full cost of network maintenance. Over time, this=20 > leads to bloat: as of recent estimates, the UTXO set exceeds several=20 > gigabytes when loaded into memory, complicating node synchronization and= =20 > validation. Without intervention, projected growth could undermine=20 > decentralization, as fewer individuals or entities might afford to=20 > participate fully in the network. > > The motivation for reform, therefore, stems from a desire to balance=20 > innovation with sustainability. An ideal solution would allow gradual UTX= O=20 > expansion to accommodate genuine monetary usage while introducing feedbac= k=20 > to curb excessive accumulation, all without compromising Bitcoin's=20 > permissionless nature or requiring a hard fork that could fragment the=20 > community. > > ## A PID-Inspired Feedback Controller for UTXO Control > > Drawing from control theory, which studies how systems maintain desired= =20 > behaviors through feedback, this proposal introduces a dynamic mechanism = to=20 > regulate UTXO set size. PID controllers, widely used in engineering for= =20 > processes like temperature regulation or autopilot systems, combine three= =20 > terms: Proportional \(P\) for immediate response to errors, Integral (I)= =20 > for correcting persistent deviations, and Derivative (D) for anticipating= =20 > changes based on trends. In Bitcoin's context, we adapt this framework to= =20 > compute a minimum value threshold=E2=80=94or "floor"=E2=80=94below which = UTXOs become=20 > ineligible for spending, effectively deprecating them over time. > > Importantly, this deprecation rule constitutes a soft fork: it restricts= =20 > the set of valid transactions to a subset of those previously allowed,=20 > without introducing new capabilities. Upgraded nodes enforce the rule,=20 > rejecting deprecated UTXOs as invalid inputs, ensuring backward=20 > compatibility and minimizing disruption. > > ### Mechanism Overview > > The controller activates at each difficulty adjustment epoch,=20 > approximately every two weeks (2016 blocks), aligning with Bitcoin's=20 > existing periodic recalibrations for predictability. > > 1. **Define a Target UTXO Size Trajectory**: Establish an increasing=20 > maximum target for the UTXO set size, denoted as $T(t)$, where $t$=20 > represents the epoch number. This could grow sublinearly with time or=20 > blockchain height to reflect organic adoption=E2=80=94 for instance, $T(t= ) =3D U_0=20 > \cdot (1 + r)^t$, with $U_0$ as the initial size and $r$ a small annual= =20 > growth rate (e.g., less than 1%). This permits expansion while preventing= =20 > unbounded divergence. > > 2. **Measure the Error**: At each epoch, compute the error $e(t) =3D S(t)= -=20 > T(t)$, where $S(t)$ is the current UTXO set size (measured by count or=20 > aggregate data footprint). > > 3. **Compute the Floor Adjustment**: Apply the PID formula to adjust the= =20 > value floor $F(t)$: > =20 > $$ \Delta F(t) =3D K_p \cdot e(t) + K_i \cdot \sum_{k=3D0}^{t} e(k) = + K_d=20 > \cdot \frac{e(t) - e(t-1)}{\Delta t} $$ > =20 > Here, $K_p, K_i, K_d$ are tunable gains, selected conservatively=20 > through simulations to ensure stability (e.g., using root locus analysis = to=20 > avoid oscillatory or unstable roots in the system's characteristic=20 > equation). The floor $F(t)$ increases only if $e(t) > 0$, applying to UTX= Os=20 > below this threshold. > > 4. **Deprecation Process**: UTXOs with values below $F(t)$ are marked as= =20 > unspendable in future transactions. To provide fairness and predictabilit= y,=20 > implement a grace period (e.g., 4-12 months) during which owners can=20 > consolidate affected UTXOs. > > 5. **Safeguards and Tuning**: Incorporate clamps on $\Delta F(t)$ (simila= r=20 > to Bitcoin's difficulty adjustment limits) to prevent abrupt changes that= =20 > might cause network congestion from mass consolidations. Periodic reviews= =20 > of gains and targets via community governance would adapt the system to= =20 > evolving conditions. > > ### Stability and Dynamics Considerations > > In dynamic systems terms, the UTXO set can be modeled as an integrator=20 > accumulating outputs minus expenditures. The PID controller introduces=20 > negative feedback to dampen this accumulation, driving $S(t)$ toward $T(t= )$=20 > with minimal overshoot. Simulations would verify robustness against=20 > adversarial scenarios, such as deliberate UTXO spam, ensuring the system'= s=20 > poles remain in the stable region of the complex plane. > > Potential benefits include reduced node resource demands, lower fees=20 > during normal operation, and enhanced decentralization. Risks, such as=20 > over-deprecation affecting small holders, can be mitigated through carefu= l=20 > gain selection. > > ## Conclusion > > This PID-inspired approach offers a principled path to managing Bitcoin's= =20 > UTXO set, fostering sustainable growth while upholding core principles. B= y=20 > integrating feedback control, Bitcoin can evolve as a resilient dynamic= =20 > system, better equipped for widespread adoption. Further research,=20 > including detailed modeling and community discourse, is essential to refi= ne=20 > and potentially implement such enhancements. > > --=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/= 049858f4-28ba-4ffb-8966-f8bef09035b7n%40googlegroups.com. ------=_Part_998603_223578563.1765391422961 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Given the increasing= =C2=A0RAM requirements, due to the increasing=C2=A0UTXO set
I have been assured multiple times recently that this problem does not e= xist in Bitcoin Core. I'm not sure about that, but I can say for sure that = this is not a problem in Libbitcoin and is therefore not problem with the B= itcoin protocol.

Best,
Eric

On Wednesday, December 10, 20= 25 at 1:12:31=E2=80=AFPM UTC-5 uuowwpevskfcordh wrote:
Given the increasing=C2=A0RAM requirements, due t= o the increasing=C2=A0UTXO set, I suggest seeing the UTXO set size as a con= trolled variable. A feedback mechanism sets a dynamic dust level, below fro= m which UTXOs are removed/discarded and thus freeing RAM.

Below is an overview essay bette= r expressed by grok, which can also be seen in here:

# Enhancing Bitcoin's Scalability:= A PID-Inspired Approach to Managing UTXO Set Growth

<= /div>
## Abstract

Bitcoin= =E2=80=99s UTXO set is currently an unbounded accumulator that risks long-t= erm centralization as node RAM requirements grow without limit. Existing fe= e incentives have proven insufficient against sustained low-value output cr= eation (e.g., inscriptions, tokenized assets, dust-heavy protocols). This a= rticle proposes a soft-fork mechanism that treats UTXO set size as a contro= lled variable: a slowly rising target size is defined, and a PID-style feed= back controller, updated every difficulty epoch, dynamically raises a minim= um-value floor beneath which old UTXOs become unspendable. The result is bo= unded, predictable growth of the UTXO set with ample warning periods, no ha= rd caps on monetary use, and strong resistance to bloat attacks=E2=80=94all= while remaining fully compatible with a soft-fork deployment.
=

## Introduction

<= span>Bitcoin, the pioneering decentralized digital currency, operates as a = complex dynamic system governed by consensus rules that ensure security, im= mutability, and permissionless participation. At its core, Bitcoin maintain= s a distributed ledger known as the blockchain, which records all transacti= ons in a sequence of blocks. Each transaction involves inputs and outputs: = inputs reference previously unspent outputs from prior transactions, while = outputs create new spendable units called Unspent Transaction Outputs (UTXO= s). The UTXO set represents the aggregate state of all currently spendable = coins in the network, serving as a critical component for transaction valid= ation and wallet management.

As Bitco= in has evolved, the UTXO set has grown significantly, influenced by increas= ing adoption and diverse usage patterns. This growth, while indicative of t= he network's vitality, poses challenges to its long-term scalability an= d decentralization. Nodes=E2=80=94computers that validate and relay transac= tions=E2=80=94must store and process the entire UTXO set in memory for effi= cient operation, which can strain resources such as random access memory (R= AM). Unchecked expansion could lead to higher barriers for running full nod= es, potentially centralizing control among fewer, well-resourced participan= ts. This article explores a proposed mechanism to address these concerns: a= n adaptive control system inspired by Proportional-Integral-Derivative (PID= ) feedback principles, designed to impose bounded growth on the UTXO set wh= ile preserving Bitcoin's foundational properties.

=
## Motivations for UTXO Set Management
To appreciate the need for enhanced UTXO management, it = is essential to understand the current status quo and its vulnerabilities. = Bitcoin's design prioritizes efficiency and security through mechanisms= like block size limits, which cap the amount of data added per block (appr= oximately 1 MB base size, expandable to about 4 MB with Segregated Witness)= . These limits help control the overall blockchain size, ensuring predictab= le hardware requirements for storage on hard disk drives (HDDs). Similarly,= the difficulty adjustment algorithm maintains a consistent block productio= n rate of roughly one every 10 minutes by dynamically scaling the computati= onal challenge for miners based on network hashrate.

<= /div>
However, the UTXO set lacks comparable built-in constraints= . It accumulates as users create new outputs=E2=80=94often in small denomin= ations=E2=80=94without a mandatory mechanism to consolidate or prune them. = This can result from various activities, including high-frequency microtran= sactions, the embedding of non-monetary data (such as through protocols lik= e Ordinals, which inscribe arbitrary information onto satoshis, Bitcoin'= ;s smallest unit), or the anchoring of sidechain or tokenized assets that l= everage Bitcoin's security but operate externally. While these innovati= ons expand Bitcoin's utility, they can inadvertently increase the UTXO = count disproportionately to their economic value, elevating transaction fee= s during congestion and raising operational costs for nodes.

Existing incentives, such as transaction fees, part= ially mitigate this by encouraging users to consolidate low-value UTXOs to = avoid higher costs. Yet, these market-driven forces are insufficient agains= t sustained patterns of low-value output creation, particularly when driven= by external systems that do not bear the full cost of network maintenance.= Over time, this leads to bloat: as of recent estimates, the UTXO set excee= ds several gigabytes when loaded into memory, complicating node synchroniza= tion and validation. Without intervention, projected growth could undermine= decentralization, as fewer individuals or entities might afford to partici= pate fully in the network.

The motiva= tion for reform, therefore, stems from a desire to balance innovation with = sustainability. An ideal solution would allow gradual UTXO expansion to acc= ommodate genuine monetary usage while introducing feedback to curb excessiv= e accumulation, all without compromising Bitcoin's permissionless natur= e or requiring a hard fork that could fragment the community.
<= div>
## A PID-Inspired Feedback Controller for UTXO Con= trol

Drawing from control theory, whi= ch studies how systems maintain desired behaviors through feedback, this pr= oposal introduces a dynamic mechanism to regulate UTXO set size. PID contro= llers, widely used in engineering for processes like temperature regulation= or autopilot systems, combine three terms: Proportional \(P\) for immediat= e response to errors, Integral (I) for correcting persistent deviations, an= d Derivative (D) for anticipating changes based on trends. In Bitcoin's= context, we adapt this framework to compute a minimum value threshold=E2= =80=94or "floor"=E2=80=94below which UTXOs become ineligible for = spending, effectively deprecating them over time.

Importantly, this deprecation rule constitutes a soft fork: it= restricts the set of valid transactions to a subset of those previously al= lowed, without introducing new capabilities. Upgraded nodes enforce the rul= e, rejecting deprecated UTXOs as invalid inputs, ensuring backward compatib= ility and minimizing disruption.

### = Mechanism Overview

The controller act= ivates at each difficulty adjustment epoch, approximately every two weeks (= 2016 blocks), aligning with Bitcoin's existing periodic recalibrations = for predictability.

1. **Define a Tar= get UTXO Size Trajectory**: Establish an increasing maximum target for the = UTXO set size, denoted as $T(t)$, where $t$ represents the epoch number. Th= is could grow sublinearly with time or blockchain height to reflect organic= adoption=E2=80=94 for instance, $T(t) =3D U_0 \cdot (1 + r)^t$, with $U_0$= as the initial size and $r$ a small annual growth rate (e.g., less than 1%= ). This permits expansion while preventing unbounded divergence.

2. **Measure the Error**: At each epoch, comput= e the error $e(t) =3D S(t) - T(t)$, where $S(t)$ is the current UTXO set si= ze (measured by count or aggregate data footprint).

3. **Compute the Floor Adjustment**: Apply the PID formula t= o adjust the value floor $F(t)$:
=C2=A0 =C2=A0
=C2=A0 =C2=A0 $$ =C2=A0\Delta F(t) =3D K_p \cdot e(t) + K= _i \cdot \sum_{k=3D0}^{t} e(k) + K_d \cdot \frac{e(t) - e(t-1)}{\Delta t} $= $
=C2=A0 =C2=A0
=C2=A0 =C2=A0= Here, $K_p, K_i, K_d$ are tunable gains, selected conservatively through si= mulations to ensure stability (e.g., using root locus analysis to avoid osc= illatory or unstable roots in the system's characteristic equation). Th= e floor $F(t)$ increases only if $e(t) > 0$, applying to UTXOs below thi= s threshold.

4. **Deprecation Process= **: UTXOs with values below $F(t)$ are marked as unspendable in future tran= sactions. To provide fairness and predictability, implement a grace period = (e.g., 4-12 months) during which owners can consolidate affected UTXOs.

5. **Safeguards and Tuning**: Incorporat= e clamps on $\Delta F(t)$ (similar to Bitcoin's difficulty adjustment l= imits) to prevent abrupt changes that might cause network congestion from m= ass consolidations. Periodic reviews of gains and targets via community gov= ernance would adapt the system to evolving conditions.
### Stability and Dynamics Considerations

In dynamic systems terms, the UTXO set can be modele= d as an integrator accumulating outputs minus expenditures. The PID control= ler introduces negative feedback to dampen this accumulation, driving $S(t)= $ toward $T(t)$ with minimal overshoot. Simulations would verify robustness= against adversarial scenarios, such as deliberate UTXO spam, ensuring the = system's poles remain in the stable region of the complex plane.=

Potential benefits include reduced node res= ource demands, lower fees during normal operation, and enhanced decentraliz= ation. Risks, such as over-deprecation affecting small holders, can be miti= gated through careful gain selection.

## Conclusion

This PID-inspired approach = offers a principled path to managing Bitcoin's UTXO set, fostering sust= ainable growth while upholding core principles. By integrating feedback con= trol, Bitcoin can evolve as a resilient dynamic system, better equipped for= widespread adoption. Further research, including detailed modeling and com= munity discourse, is essential to refine and potentially implement such enh= ancements.

--
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/049858f4-28ba-4ffb-8966-f8bef09035b7n%40googlegroups.com.
------=_Part_998603_223578563.1765391422961-- ------=_Part_998602_941663234.1765391422961--