From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Dec 2025 02:05:37 -0800 Received: from mail-qv1-f62.google.com ([209.85.219.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUMVM-0005qe-GT for bitcoindev@gnusha.org; Sat, 13 Dec 2025 02:05:37 -0800 Received: by mail-qv1-f62.google.com with SMTP id 6a1803df08f44-88a262380desf522836d6.1 for ; Sat, 13 Dec 2025 02:05:35 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765620330; cv=pass; d=google.com; s=arc-20240605; b=AQLPmzCSIoRABwUps/LVmNKlugUl7Csqb7R5aoysuTNspcfbNw06JZcbnJHvQWmDDY NPtPpdc3oNjZiO9X0dmgzfbNivaK6eqCYfTAeOHT00QeWncQYJ8eJLRHEmIQ2PzDSS9c l0umsoNI747JbI1wwmHO0NO7DV80JJnzPeIifaBFqw+fa/JcDpG/IOexSExWgfmfG0Rt XNw0bfs3h9DrXCuJ6Ei4XRfoy9RwCdnhjOBHHeKjRuI7uMxKWH7IN1XwRAsmOU7TNYiD iipivLgtyabT1nMGe9JVizLce+gs2MQ8l/rxt4LkDHxIiIfyfvV0N2J9LQnB7+nB7Y6A 4q7A== 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:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=jOT2YLt8OeA8SBiLd+fH+ndz8/wLguXRSTDyEtgC+BQ=; fh=weVCPeDL6JnwpSihvxHY7bnGJADNRPmnZYOHtYxkLyQ=; b=PTKXZyEWT6SwJamDulVsgZMQH5K116mU2w8xbeIU6evmJ2hAUn06m7jta2MZjWNTSg lba875mi1Sac/ottv/8k5u39Rmg2ni9yYcoB/MRr46Kld6J7DFQCfJxnHjL+k0Mx7CV0 hX2aAdNIPR0XEwkYA8uHDpN2ig9jf0/aEcTvhjIODs0b71NfebHGGlsMsnHaPjLpRIgU VfOr+83VpEssXUX7iud1nO9Y7bl8chtkZlYaHHhUaROJchwLbzP36xAExfGEXgdZCsoo BrdFz2lppupZWhYr/Dv24ejr2O4CM5z0oOpNFni9G0AMtRviRJbHSrNslD6Ib1V1VATZ uBQQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=CqAhLriX; spf=pass (google.com: domain of uuowwpevskfcordh@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=uuowwpevskfcordh@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765620330; x=1766225130; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=jOT2YLt8OeA8SBiLd+fH+ndz8/wLguXRSTDyEtgC+BQ=; b=kN/6VaShp5yh5JpsGIMJs3A06Ls10CI6gNFBJ+0EWJUKdTTWMPq3KthTO93Vb66JBq en1kVWxRpjKTPAWQdwB77HBVKnnec7rUnTdg23Mql93ZUTDoiPwZe1KWPOFvMW+1DwsN WXE7xiK+TPp5mc1LHUQGI5EvI4aRMG+C2CXh/zjhWEALlrOgJixUrDphc76rJjBQie6E ZQH85qxMmWFI2CPqul2koOVasQc7ZnagCACrcOxG3SL0S1I18WIkJLuI6DCBcD9/iA+7 Ce0inyJJhu6UFwDATs5PF6Gb39sAmoBLQw51IIIPv25SGeEuv9xXE2p0jR4qXs8SsDPS 0Wow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765620330; x=1766225130; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jOT2YLt8OeA8SBiLd+fH+ndz8/wLguXRSTDyEtgC+BQ=; b=T6oFrh7gxGxV/jWBcUW+UhHndn/ALFBIX/YIYp2NgaByZJHBGJ1WpdVe27HFmr2rgT cEnrBmivazZhxIrLZ6gi6U/xU5Hoi2EenVEmDvr+aKtOufP6ZTVliY7eGlyTsOeL7SYD OGmnOn7AhsUz2IS7i9Yrpl4l7F+vTBF/zlWii9ecH4T8eeculSWjJAG7H53CkoKErteQ nuXFENjbud3Syucq+BosqGWPWQ3WzInfypYs00lmCW3JrcLAJE/Bez04Cu9rD7vuWiEp 2PNj4W+eeEU9lryqzK/1wf6UGH0wUPfAFmMPeFEw5R6yjH62dr4eVF37KI7C4ahFNoYE N+bQ== X-Forwarded-Encrypted: i=2; AJvYcCUpQpYRc9aa3OAHMWbAvecXx4bFGDYKMbSgmfyoJeCZBfP812p4UxNC5UUSaHCrYiJzZlI0MB/MaWY0@gnusha.org X-Gm-Message-State: AOJu0YzzKw2ZMFH8ulOtfxWHl02Yj3ntw8hjiQVAN5KDBrcH6QfNzDus qqodNFguZKC4Pflbcga6tYKahcbY7oGrdHPgc7PaXpQEHzKj6DlJVR7e X-Google-Smtp-Source: AGHT+IEoOdNg+ObbDdFe07fRNgS4ueaS++PfJn9lWxxKHJpyVzb62/PWse5FCire28DtzxxK+ZwwLw== X-Received: by 2002:ad4:58a9:0:b0:888:8783:563 with SMTP id 6a1803df08f44-888878307b2mr33856696d6.3.1765620329474; Sat, 13 Dec 2025 02:05:29 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZrRiMHmRZBE9WJTdQmvGytDyMwxbP7pd4RBAOjxVn+fg==" Received: by 2002:a05:6214:5299:b0:886:6a14:9437 with SMTP id 6a1803df08f44-8887cd8b9adls18009816d6.2.-pod-prod-07-us; Sat, 13 Dec 2025 02:05:24 -0800 (PST) X-Received: by 2002:a05:6214:509b:b0:880:501f:5dd with SMTP id 6a1803df08f44-8887dfec80cmr79685436d6.14.1765620324170; Sat, 13 Dec 2025 02:05:24 -0800 (PST) Received: by 2002:a05:600d:4448:20b0:477:99f7:45de with SMTP id 5b1f17b1804b1-47a8de671abms5e9; Fri, 12 Dec 2025 14:22:55 -0800 (PST) X-Received: by 2002:a05:600c:528c:b0:46e:3d41:6001 with SMTP id 5b1f17b1804b1-47a93950510mr16608095e9.34.1765578173495; Fri, 12 Dec 2025 14:22:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765578173; cv=none; d=google.com; s=arc-20240605; b=h3EvSJQItLNhchYMI31dhOjWJqHBGpIgYQWT2QK8Uwy6mZ0ONlxNdN+VzduV/wJdEf fnK98fgMZNiWFxa7wlXKjc6BvscOIz3k7/UP+HCX7goAVuQqVrfFCQYwAWb9JSsWJdon hVRzMOj30ywUqCqu/Qe8+P4j56m6De48siCdrQqEVNHAsY/tebgZRK0UulBJqZoVvjV/ EyqgUQcQ/6kmA50Xe+tesc/Nw5MhdX9yZiXV2pApjFJyg9YGD9BuKfVQcD8hSoA8nkIT eq26hPun9bUPMfBGLyVCzLfoKYmWDzXEElSWlNpq9dH9Q0d4442dyV+LZWpftOZwcJ5I SwEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=UgvoBpUcIvvMNAm0Fhkvmrb43D6D4AJHWYatLYN9i+4=; fh=BBjoOV+FJpZVFYOqP+6YkPqLhGS4S9ghWhTOZCmvqBo=; b=GbwGpyXl7bd7uPgijS0JJCQEXgb4AkDMymBxzlzjAxRmPb177WvCOHQF3f7NZk0x3R BcNn4fl5nMIV1wz9RWhA0n+yYkOIWvHRWIJZjDQI5PvF5az7u9YdfB3GmcRL/CWqm/aN oWm30QwFS2rP+CDNpZDG5phwsxkODKEZo2smzQRYoJ89DVmeJDHQME49kuFx/d90+0dZ EdhD48z5TI6eHfuyCx9bFXcenMcaqfVziq+lpSm6m7OhbCKy9XJw3nDzMuWpDoYOuJ2F f9JPq+537XX0+IFeSoAjJFAJZziD+3a0wgraK5LYb4f5+mZ7mwcq5k9wbfV7e1cp3kzT hBvQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=CqAhLriX; spf=pass (google.com: domain of uuowwpevskfcordh@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=uuowwpevskfcordh@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch. [185.70.43.167]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-47a8f4e45bfsi382525e9.2.2025.12.12.14.22.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Dec 2025 14:22:53 -0800 (PST) Received-SPF: pass (google.com: domain of uuowwpevskfcordh@proton.me designates 185.70.43.167 as permitted sender) client-ip=185.70.43.167; Date: Fri, 12 Dec 2025 22:22:51 +0000 To: Eric Voskuil From: "'uuowwpevskfcordh' via Bitcoin Development Mailing List" Cc: "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Re: Reducing RAM requirements with dynamic dust Message-ID: In-Reply-To: <97065ca0-662b-4a5d-90c5-7607db41ba2fn@googlegroups.com> References: <049858f4-28ba-4ffb-8966-f8bef09035b7n@googlegroups.com> <97065ca0-662b-4a5d-90c5-7607db41ba2fn@googlegroups.com> Feedback-ID: 118992141:user:proton X-Pm-Message-ID: 629f1d43598ed45060d16f80ef8f8d6d02236d44 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: uuowwpevskfcordh@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=CqAhLriX; spf=pass (google.com: domain of uuowwpevskfcordh@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=uuowwpevskfcordh@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: uuowwpevskfcordh Reply-To: uuowwpevskfcordh 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: -1.0 (-) Thanks both Eric and Erik for the replies. I can't answer whether RAM requi= rements due to UTXO would indeed be a problem or not. I think a worse-case = performance could be considered assuming a "no-RAM" environment. This being said, I wanted to share some insights still related to the dynam= ic dust mechanism (the essay). 1. This proposal could be named "dynamic dust" plus "dust sweeping". Dynami= c dust refers to the dust level being defined by the controller at every ep= och, and dust sweeping refers to deprecation of utxos below that dust thres= hold. 2. The grace period for the sweep, individual for each transaction, allows = for a new perspective. This is, again, better portrayed by Grok: ## Annex: Addressing Concerns of Confiscation in UTXO Deprecation While the proposed PID-inspired mechanism for UTXO set management offers a = pathway to enhanced scalability, it has elicited valid criticisms, particul= arly regarding its confiscatory nature. Deprecating low-value UTXOs could b= e perceived as an involuntary seizure of assets, undermining Bitcoin's prin= ciples of ownership and immutability. This concern merits careful considera= tion, as any protocol change must preserve user trust and avoid arbitrary i= nterventions. The proposal maintains a degree of neutrality by evaluating UTXOs solely ba= sed on their satoshi (SAT) value, without interpreting their content or pur= pose. This objective criterion minimizes subjective judgments, applying uni= formly across all outputs regardless of their origin or use case. A key mitigating factor lies in the incorporation of a grace period=E2=80= =94typically spanning 6 to 12 months=E2=80=94during which owners of affecte= d UTXOs can consolidate or spend them without direct penalty. This window t= ransforms the deprecation process from outright confiscation into a dynamic= incentive structure, favoring resource allocation in a constrained system.= In Bitcoin's ecosystem, users already incur ongoing costs for participatio= n, such as transaction fees, which can render low-value UTXOs economically = immobile if fees rise persistently. Such "frozen" outputs are not labeled a= s confiscated but rather as subject to market realities. >From this perspective, low-value (or "dust") UTXOs enter a "renting" state = upon falling below the dynamic dust floor. Owners, including those engaging= in high-volume, low-value activities (e.g., data inscription or sidechain = anchoring), can extend their usability by periodically transacting them=E2= =80=94paying the requisite fees to "renew" the grace period. Failure to do = so results in expiration and deprecation, mirroring the fee-based prioritiz= ation inherent in Bitcoin's design rather than imposing an immediate puniti= ve forfeiture. This framework may inadvertently benefit miners, as sustained renewal activ= ities could increase block occupancy, elevating average fees and bolstering= network security through heightened hashrate incentives. By channeling res= ources toward productive on-chain operations, the mechanism redirects poten= tial inefficiencies into contributions that enhance overall system resilien= ce. In summary, while the confiscatory nature and risks are acknowledged, the g= race period and value-based neutrality recast deprecation as an extension o= f Bitcoin's economic model, promoting efficient resource use without compro= mising core tenets. Best regards, On Wednesday, December 10th, 2025 at 8:52 PM, Eric Voskuil wrote: > Hi Erik, >=20 > It's a good idea, that's why we did it. >=20 > Libbitcoin is a set of libraries, libbitcoin-database being one of 4 that= make up node (system, network, database, and node). (libbitcoin-server is = an additional library that adds comprehensive set of client-server interfac= es, making the node useful.) libbitcoin-database is an implementation of a = simple query interface (defined as a c++ class) over a backing store. The s= tore is a templated collection of tables. The tables are mmap-based head an= d body files used to construct multimaps, hashmaps, arraymaps, arrays, and = blobs. We mock the tables using std::vector, mock the store using = the the mocked tables, and test most of the query interface using the mock = store. The structure is highly relational, and surrogate keys are exposed t= o the caller for optimized navigation. >=20 > This is an isolated and clear storage abstraction layer. All validation i= s performed within the chain:: classes (e.g. block, header, tx, input, scri= pt, etc.) defined in the base level libbitcoin-system. There is no validato= r coupling to the store. The store retains chain objects, indexes, and vali= dation state for headers/blocks and txs as they progress through a state ma= chine. There is no utxo table, just natural relations between objects, inde= xed and related. Validation correctness of course requires store fidelity, = but is totally decoupled from it. We validate blocks concurrently, queueing= up 50,000 blocks at a time by default (e.g. with 50k threads we would vali= date all at the same time). >=20 > The store could be replaced with no impact to the query interface (as we = already do in testing). So it's not really accurate to imply that libbitcoi= n's validation is tied to mmap or even append-only. Pruning could be implem= ented in the existing model for example. The existing store could be replac= ed with something simple and light like SQLite, or a full RDBMS. We had som= e interns working the SQLite approach last summer. That would be more speci= alized for low performance scenarios, where the custom database targets ult= ra high performance. >=20 > With sufficient RAM there is never SSD access. The store can sync up and = just live in RAM, never touching a disk. Since it is append only, it's very= low impact on SSDs. As the store builds, no table body byte is ever re-wri= tten. Table heads are hashmaps buckets, small and dynamic. It performs live= automated/manual snapshotting, automatic fault detection/recovery on resta= rt, automated disk-full pause/restart, and supports hot backup. Query perfo= rmance is phenomenal. A warm node can query the full 5.2 million output Ele= ctrum query (very complex relations) in 15 seconds on my 2.1GHz workstation= . But at the low end, an off-the-shelf store is sufficient. A clear interfa= ce and swappable store makes a lot of sense. >=20 > A large utxo set makes no difference in this design. There are no operati= onal problems associated with it. Given the recent fuss about it, I figured= it was worth putting some detail behind it here. This is not theoretical, = at this point we are only working on server (client-server interfaces). The= utxo set size is a complete non-issue. >=20 > e >=20 > On Wednesday, December 10, 2025 at 2:48:43=E2=80=AFPM UTC-5 Erik Aronesty= wrote: >=20 > > Core: Keep UTXO lookups in RAM as much as possible. This gives predicta= ble validation under adversarial load and trades memory for protection from= pathological disk latency. > > Libbitcoin: Represent history in append-only, memory-mapped files. Let = the operating system decide what stays hot. Accept more disk I/O in return = for simpler concurrency and no explicit UTXO map. > >=20 > > To create 200 million outputs as an attack, the cost is roughly 48 BTC = based on eight vb per output at low feerates. > >=20 > > Given the operational problems that a very large UTXO set creates, it m= ay be worthwhile to develop a clear storage abstraction layer. > >=20 > > The goal would be to ensure that validation correctness does not depend= on the transitional behavior of a specific storage engine. > >=20 > > Once the validator has a well defined storage contract, alternate backe= nds such as a libbitcoin style layout could exist as storage formats while = still benefiting from the reliability of the rest of the Bitcoin implementa= tion. > >=20 > > (I would be interested in something like this.) > >=20 > >=20 > > On Wed, Dec 10, 2025 at 10:34=E2=80=AFAM Eric Voskuil wrote: > >=20 > > > > Given the increasing RAM requirements, due to the increasing UTXO s= et > > >=20 > > > I have been assured multiple times recently that this problem does no= t exist in Bitcoin Core. I'm not sure about that, but I can say for sure th= at this is not a problem in Libbitcoin and is therefore not problem with th= e Bitcoin protocol. > > >=20 > > > Best, > > > Eric > > >=20 > > > On Wednesday, December 10, 2025 at 1:12:31=E2=80=AFPM UTC-5 uuowwpevs= kfcordh wrote: > > >=20 > > > > Given the increasing RAM requirements, due to the increasing UTXO s= et, I suggest seeing the UTXO set size as a controlled variable. A feedback= mechanism sets a dynamic dust level, below from which UTXOs are removed/di= scarded and thus freeing RAM. > > > >=20 > > > > Below is an overview essay better expressed by grok, which can also= be seen in here: > > > > https://hackmd.io/P-2lzGb8TiC86IOE3OGiYA?view > > > >=20 > > > > # Enhancing Bitcoin's Scalability: A PID-Inspired Approach to Manag= ing UTXO Set Growth > > > >=20 > > > > ## Abstract > > > >=20 > > > > Bitcoin=E2=80=99s UTXO set is currently an unbounded accumulator th= at risks long-term centralization as node RAM requirements grow without lim= it. Existing fee incentives have proven insufficient against sustained low-= value output creation (e.g., inscriptions, tokenized assets, dust-heavy pro= tocols). This article proposes a soft-fork mechanism that treats UTXO set s= ize as a controlled variable: a slowly rising target size is defined, and a= PID-style feedback controller, updated every difficulty epoch, dynamically= raises a minimum-value floor beneath which old UTXOs become unspendable. T= he result is bounded, predictable growth of the UTXO set with ample warning= periods, no hard caps on monetary use, and strong resistance to bloat atta= cks=E2=80=94all while remaining fully compatible with a soft-fork deploymen= t. > > > >=20 > > > > ## Introduction > > > >=20 > > > > Bitcoin, the pioneering decentralized digital currency, operates as= a complex dynamic system governed by consensus rules that ensure security,= immutability, and permissionless participation. At its core, Bitcoin maint= ains a distributed ledger known as the blockchain, which records all transa= ctions in a sequence of blocks. Each transaction involves inputs and output= s: inputs reference previously unspent outputs from prior transactions, whi= le outputs create new spendable units called Unspent Transaction Outputs (U= TXOs). The UTXO set represents the aggregate state of all currently spendab= le coins in the network, serving as a critical component for transaction va= lidation and wallet management. > > > >=20 > > > > As Bitcoin has evolved, the UTXO set has grown significantly, influ= enced by increasing adoption and diverse usage patterns. This growth, while= indicative of the network's vitality, poses challenges to its long-term sc= alability and decentralization. Nodes=E2=80=94computers that validate and r= elay transactions=E2=80=94must store and process the entire UTXO set in mem= ory for efficient operation, which can strain resources such as random acce= ss memory (RAM). Unchecked expansion could lead to higher barriers for runn= ing full nodes, potentially centralizing control among fewer, well-resource= d participants. This article explores a proposed mechanism to address these= concerns: an adaptive control system inspired by Proportional-Integral-Der= ivative (PID) feedback principles, designed to impose bounded growth on the= UTXO set while preserving Bitcoin's foundational properties. > > > >=20 > > > > ## Motivations for UTXO Set Management > > > >=20 > > > > To appreciate the need for enhanced UTXO management, it is essentia= l to understand the current status quo and its vulnerabilities. Bitcoin's d= esign prioritizes efficiency and security through mechanisms like block siz= e limits, which cap the amount of data added per block (approximately 1 MB = base size, expandable to about 4 MB with Segregated Witness). These limits = help control the overall blockchain size, ensuring predictable hardware req= uirements for storage on hard disk drives (HDDs). Similarly, the difficulty= adjustment algorithm maintains a consistent block production rate of rough= ly one every 10 minutes by dynamically scaling the computational challenge = for miners based on network hashrate. > > > >=20 > > > > However, the UTXO set lacks comparable built-in constraints. It acc= umulates as users create new outputs=E2=80=94often in small denominations= =E2=80=94without a mandatory mechanism to consolidate or prune them. This c= an result from various activities, including high-frequency microtransactio= ns, the embedding of non-monetary data (such as through protocols like Ordi= nals, which inscribe arbitrary information onto satoshis, Bitcoin's smalles= t unit), or the anchoring of sidechain or tokenized assets that leverage Bi= tcoin's security but operate externally. While these innovations expand Bit= coin's utility, they can inadvertently increase the UTXO count disproportio= nately to their economic value, elevating transaction fees during congestio= n and raising operational costs for nodes. > > > >=20 > > > > Existing incentives, such as transaction fees, partially mitigate t= his by encouraging users to consolidate low-value UTXOs to avoid higher cos= ts. Yet, these market-driven forces are insufficient against sustained patt= erns of low-value output creation, particularly when driven by external sys= tems that do not bear the full cost of network maintenance. Over time, this= leads to bloat: as of recent estimates, the UTXO set exceeds several gigab= ytes when loaded into memory, complicating node synchronization and validat= ion. Without intervention, projected growth could undermine decentralizatio= n, as fewer individuals or entities might afford to participate fully in th= e network. > > > >=20 > > > > The motivation for reform, therefore, stems from a desire to balanc= e innovation with sustainability. An ideal solution would allow gradual UTX= O expansion to accommodate genuine monetary usage while introducing feedbac= k to curb excessive accumulation, all without compromising Bitcoin's permis= sionless nature or requiring a hard fork that could fragment the community. > > > >=20 > > > > ## A PID-Inspired Feedback Controller for UTXO Control > > > >=20 > > > > Drawing from control theory, which studies how systems maintain des= ired behaviors through feedback, this proposal introduces a dynamic mechani= sm to regulate UTXO set size. PID controllers, widely used in engineering f= or processes like temperature regulation or autopilot systems, combine thre= e terms: Proportional \(P\) for immediate response to errors, Integral (I) = for correcting persistent deviations, and Derivative (D) for anticipating c= hanges based on trends. In Bitcoin's context, we adapt this framework to co= mpute a minimum value threshold=E2=80=94or "floor"=E2=80=94below which UTXO= s become ineligible for spending, effectively deprecating them over time. > > > >=20 > > > > Importantly, this deprecation rule constitutes a soft fork: it rest= ricts the set of valid transactions to a subset of those previously allowed= , without introducing new capabilities. Upgraded nodes enforce the rule, re= jecting deprecated UTXOs as invalid inputs, ensuring backward compatibility= and minimizing disruption. > > > >=20 > > > > ### Mechanism Overview > > > >=20 > > > > The controller activates at each difficulty adjustment epoch, appro= ximately every two weeks (2016 blocks), aligning with Bitcoin's existing pe= riodic recalibrations for predictability. > > > >=20 > > > > 1. **Define a Target UTXO Size Trajectory**: Establish an increasin= g maximum target for the UTXO set size, denoted as $T(t)$, where $t$ repres= ents the epoch number. This could grow sublinearly with time or blockchain = height to reflect organic adoption=E2=80=94 for instance, $T(t) =3D U_0 \cd= ot (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 unbound= ed divergence. > > > >=20 > > > > 2. **Measure the Error**: At each epoch, compute the error $e(t) = =3D S(t) - T(t)$, where $S(t)$ is the current UTXO set size (measured by co= unt or aggregate data footprint). > > > >=20 > > > > 3. **Compute the Floor Adjustment**: Apply the PID formula to adjus= t the 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 \cdot \frac{e(t) - e(t-1)}{\Delta t} $$ > > > >=20 > > > > Here, $K_p, K_i, K_d$ are tunable gains, selected conservatively th= rough simulations to ensure stability (e.g., using root locus analysis to a= void oscillatory or unstable roots in the system's characteristic equation)= . The floor $F(t)$ increases only if $e(t) > 0$, applying to UTXOs below th= is threshold. > > > >=20 > > > > 4. **Deprecation Process**: UTXOs with values below $F(t)$ are mark= ed as unspendable in future transactions. To provide fairness and predictab= ility, implement a grace period (e.g., 4-12 months) during which owners can= consolidate affected UTXOs. > > > >=20 > > > > 5. **Safeguards and Tuning**: Incorporate clamps on $\Delta F(t)$ (= similar to Bitcoin's difficulty adjustment limits) to prevent abrupt change= s that might cause network congestion from mass consolidations. Periodic re= views of gains and targets via community governance would adapt the system = to evolving conditions. > > > >=20 > > > > ### Stability and Dynamics Considerations > > > >=20 > > > > In dynamic systems terms, the UTXO set can be modeled as an integra= tor accumulating outputs minus expenditures. The PID controller introduces = negative feedback to dampen this accumulation, driving $S(t)$ toward $T(t)$= with minimal overshoot. Simulations would verify robustness against advers= arial scenarios, such as deliberate UTXO spam, ensuring the system's poles = remain in the stable region of the complex plane. > > > >=20 > > > > Potential benefits include reduced node resource demands, lower fee= s during normal operation, and enhanced decentralization. Risks, such as ov= er-deprecation affecting small holders, can be mitigated through careful ga= in selection. > > > >=20 > > > > ## Conclusion > > > >=20 > > > > This PID-inspired approach offers a principled path to managing Bit= coin's UTXO set, fostering sustainable growth while upholding core principl= es. By integrating feedback control, Bitcoin can evolve as a resilient dyna= mic system, better equipped for widespread adoption. Further research, incl= uding detailed modeling and community discourse, is essential to refine and= potentially implement such enhancements. > > > >=20 > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/049858f4-28ba-4ffb-8966-f8bef09035b7n%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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/97065ca0-662b-4a5d-90c5-7607db41ba2fn%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/= ASHweqfTSVKBPOY2P4UCyK7k7C28OWcQx2SfP9Ovqv2xifZo6SJYpwYLQTjvXTuf7lCa6fqeP92= n47L6EokhlA7gHguLLgzHBQMY87rQDQk%3D%40proton.me.