From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 23 Jan 2026 06:03:37 -0800 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vjHl7-0003bb-QQ for bitcoindev@gnusha.org; Fri, 23 Jan 2026 06:03:36 -0800 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-40445fbb208sf857481fac.1 for ; Fri, 23 Jan 2026 06:03:33 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1769177008; cv=pass; d=google.com; s=arc-20240605; b=T+pZlkL+VC9j228tcqgEU159OTvVGEVcu2To7i0SNF31WPOI228xCp3bS99HK6F7EG WUNC0jkxvZMbbLvy65F+niHfqJ1E+ZBpwizPzlaP8KUY3D0FhyQEUxeA4rJz5FJ+nI6e jqIyuH9V5Jh3BPYSYAVHyO3YigyY7Hg4YVOCdHsReWlevPEUpN+ceDIgTUryFgdzJu2u vsu45BJRXryHaFnGiY6LKqKMzacxxrS2hcMh05c8sGkRDaItdwyWilzzHa4mRK54g7jL ETBVGTD2X9xhhp8rJCyDoEZVFZCDVQaKdvA9RS7zJvBqBEthTpSTGpxHvHqHPvWvmhDW Bk5g== ARC-Message-Signature: i=3; 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=4uH6E3xik4SCTc6OOM95YB40zwIeLSirVfl1ssCuiAc=; fh=nm8nWfN84waFBKxokLpeVDsNrkRADInyoh+otXXZxew=; b=SPFDkClpK0Vn0ZTc/wUSxKs7VlfgEGPOKtqw4dpV3h6bopRf8OOolxvwhWswyNp2Kh nMUumteaHX9Sfva+FY0LP7OaWcOOWyAoygWysJ2p3g/pgnERTMyGk3ao5t2NfDGeMjLy hepjaMzwnbPOcsRelM9Yl+P8RPPvW/q+1nT+eNjg62CI2tl3apTSb/RCaw6xnyEXePcs o1m/ydbZuxUOxRozTPavOmjqPCZm0JODC/tReRXNDMmJrjWkaW5uo2+2gHub6Pt58am+ RdEnW5GddeIuH5r3oetFpU949nIZa1wT8dd8NCQZVV69CAhOLnru971L4UxWFlJZGRFR oA5Q==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Yae1Oq93; arc=pass (i=1); spf=pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=criley@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=1769177008; x=1769781808; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=4uH6E3xik4SCTc6OOM95YB40zwIeLSirVfl1ssCuiAc=; b=g3mWIIydKTKs/K06UF8v/xPA1QTNnTf75b62Yxcr0H9pG+iaBduYWcjHxOZ49DNuf9 wqwGy5rINlcIwTC05YqEtVKFR3TM0xvdtD5Rq6GVMqe1wUjaBZUKGL14DYiy3dhnMGQC KhFucmn9tz35MKCq1Y9ukWfxlghKzgNw6zthIw+ABKsMB8MH0cCLsxSQYnhCFkVoCBil osbzBRGBkn5NGlHBUbLg4BAYbniRYa2THFcfgNyaNOuUdT7AZMFCQHGfEnXMrCtdm7/P YWe6YZRp58Wa0gSskWHZwAiKaTwgGdk8le4bNk+JEtbmdqMrR9gn6mKsQF84nwbCsHQm CbUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769177008; x=1769781808; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4uH6E3xik4SCTc6OOM95YB40zwIeLSirVfl1ssCuiAc=; b=lKutN9cHhmvL6HGLZ7G9qFwbX/MhbRcblhAJq4TKCxdJ435EgXLgYtaXXP4E0AybIl rLtIe/K93aMT333KBKNlQruVF4WeUHuoMVJi/E7ZJeonKoyGqmZBgEJRNQ9ktBBMCJxL xyE9QCFMF0NtSUH/gPWIOvzw82GnPtSeTgOu2RKWdBhDtljULVaRIYkPbJBxZ1q0k8NL bX7SMbGCmBj6O//gipxlRwiRUw37Bbz8nGcx+JTTFvke7mBhzZPv56TKW+laAMFGfZYk icfmGNVWwxuz2q70HHf0zc6pVS1t5/vG3xsLAIBoNllRDfqRR4KdfCKfaGTmtJL5Fr0Z zOEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769177008; x=1769781808; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender: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=4uH6E3xik4SCTc6OOM95YB40zwIeLSirVfl1ssCuiAc=; b=MLxXTKq8c3QocQd9xkU2MqR0nMdt+lT5vXmzuMWCDL7aKUINVx7wMQ9W0zju9VQP7F nq60MqUCGXJ1FPe0L1a8dg0z01zZLX4PV1GNdFwX0JYB2i/bB9ibdr4aLaL8fEXY2t45 /j9u1tJScm/mzI7teZak3v9A+QXJor5Yw8nWQXicQxRIgdURLten36WhSuU5tMhH7mZH 2cjzl/2ZdIk/D8zYWjACHZX+4PvNPzAV/4XuPU7C2D1ZdXsAKKzohY3HlFcg03IWB98f yhcnrYmgU41iY/pEefHCUzkmNidNfZVFLJoi0PNKKe2gVrWWT/G7Z9huDGp9Z2OAr/Ai 8m4g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCU3GcwNGRFbkfhvpR1VdoVxDwD6laFvhDpYSBb33+cy2Y99+je10eCX9Cab1nepbH6+V5n3CF0PGmH9@gnusha.org X-Gm-Message-State: AOJu0YwYDBQ4wW5ffGlUAF/8erylQFfqbMaA3yda2Arf7tsnhRxp9YaQ eUjGDZqZVjJ/MBlAMy5s1/nLrYzJIvE0/PJkAxxxCjMcvbonQLIsIdmj X-Received: by 2002:a05:6871:c908:b0:408:6bba:434e with SMTP id 586e51a60fabf-408aab65fdfmr1496143fac.0.1769177006932; Fri, 23 Jan 2026 06:03:26 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HSyb4Wynu2HM3iLoBMs1ywiX3nqbXYRqAQoXOycl3gPw==" Received: by 2002:a05:6870:8917:b0:3f5:d306:979f with SMTP id 586e51a60fabf-4088207cbe6ls818475fac.0.-pod-prod-06-us; Fri, 23 Jan 2026 06:03:22 -0800 (PST) X-Received: by 2002:a05:6808:3c4d:b0:45e:ab45:d226 with SMTP id 5614622812f47-45eb1d036b6mr1677923b6e.49.1769177002290; Fri, 23 Jan 2026 06:03:22 -0800 (PST) Received: by 2002:a7b:c044:0:b0:471:13aa:415a with SMTP id 5b1f17b1804b1-4804dff037bms5e9; Thu, 22 Jan 2026 19:45:20 -0800 (PST) X-Received: by 2002:a05:600c:34d5:b0:47e:e2ec:9960 with SMTP id 5b1f17b1804b1-4804c9cf058mr29436505e9.35.1769139919005; Thu, 22 Jan 2026 19:45:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1769139918; cv=pass; d=google.com; s=arc-20240605; b=auOvBOFJ643znl5M38+rcOf+JIN0Ig2cEto1tNMj4+O2OVlM2vOJks8lUdlOBfbkyq u13oSlgF4u4U02x9nVZQPPbnYa7VzfTvnNbiYVcVdr1+0GlBadH/8jIgMWK1ER5cY+VZ KrxGn/leR1BG13SiJAX+Zfr/PghPM/Rx9Owr8pQ6VMKYBTfvfWeLELKu1o6zZnqECLbu 5lOGRyybhF54WmK+7jlCFJ8dAiecPI2LMEJnN2g/NqrffKwIJiEf1RvwkiF6NXbl1kl4 Uxd7Achx6HdQ63qM1BvwubCVySr/jVWefUcLbbw3RqfAx2K5HH5C6qH1eTQFFHmNBgM8 fNEA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=aayEF2Wl/tJ4beTc9ZOnVusi8aMBd2fPrS98HekD3UY=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=EmoTTvdZyQU7hQTjkk9p7SdXs/3lrcqD/L9bqLLSA3ZUNNnoHT4fQrjZG/NMcT5gw1 Ah63JbAEdWJr2OBjaROzYQb3pbXpxGKzRjMilNVLZKz0WpZQ6jSDG7NQIow7ZkG5/NrD fWX1aGZIGGGR20d+oqm2okPW2mUaEcGdADbmle8QtQs/HfvlUV3WuR29CPxfd1Jc2401 Y5lGP2aP5STaEfJ05hfCH9yWGnCV+NZdDpZveDxLenpzOLqxGXkvi5UXbuCcyxtM74ll KWzFpFCfJJtJzwTcY//JC50QOToFV+cEIDEFUoU688txGl0kBvaiFf0gGWg/AybE7kyt DTLw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Yae1Oq93; arc=pass (i=1); spf=pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=criley@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com. [2a00:1450:4864:20::230]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4804dafa671si97345e9.2.2026.01.22.19.45.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 19:45:18 -0800 (PST) Received-SPF: pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) client-ip=2a00:1450:4864:20::230; Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-382fceabddfso14260811fa.1 for ; Thu, 22 Jan 2026 19:45:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769139918; cv=none; d=google.com; s=arc-20240605; b=ah48ywMzSf2tm/bbztdr+rN4K+0ijyQ5+0m2THiYqz6YMsOoEdFWwTK0JJrm5ExQpq UTUMahzBLWsJK6/o4mBa2KX95kciMrhOJJtCaIW3LYwlM8mw0UCAM+JuZbERNucVc5ry nBO7qwh35pCLLtqOnH8vfmidf+VQceSekJdLA1JeymmbBZL1K15abZH/z3BYkW0gbYG5 Z2T49VCpcUaQ2r/Jcdm1xSqr0g0iwafU9IcoXJnbk8PiSD9uHps1cq7v+/OnA57ZjXg8 npuiaJBsVDuq47YWKpwGQCQM9eCX9HC5T7GsIXbQnlghaUzYcQ/cMEz3PZNe57l64yT5 j/EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=aayEF2Wl/tJ4beTc9ZOnVusi8aMBd2fPrS98HekD3UY=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=aRbEF03/4to77bZ3iOS3lnCSmuAvL0LOY/BXFhwEIi7aUyXhfSIVHdMt9I8p6jUjhC +rOcw0oUFOfKyz/wTDivGPl+cR40pOb3523JJU+OyM3MYPqvVBbRUo65eEW7FQnI8UuS Rc8tk3VVPv+wGH+sd5zTdhAiRJTH0mlvdBW9yYDBtEfQSYhpEDfsQjNp9QKXStU82/4v L2Zj/vpV+lVHMA02huyRwa6BxDoA5iPETW4t6D7hGNXi8sovWrz2wknxKIhytlWPMmOj T0ndgPM3gk+zYZHBGLz+CS5y8T9JqTdKaC3RHjq1LiJ1WBswreADxuFDmQ0Efm1W93HQ 3yFg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aIMIO11MF3IgdPlBMUq77t1QXzPylicnmZylj3LSMJSAe3wbyOoz6s7G3touEd hltKTDTm8Hw7Db3BKumEyBSTD+NWDzGFRtFgPgrOXCRilyMm2HV1LOqR+btFru25NqsRbZH7/ET 6oV4sGHxIUe89F+GA3z5nBlR2tadf/levGkWvtIt4+IMxyxHnsYUdVI3YdQpNk7oxqdzFtWaH2a kCWQO3/o/VqwrPwjJIP950UgSOt3myVwFxGD77bqhh5caURz9YgNZKNCO19llhMBF5RRmjtBeCQ aCBzxk/rX1hjNN79AQOlYSUrlDFaMRqhdQzT X-Received: by 2002:a05:651c:154b:b0:383:1232:379b with SMTP id 38308e7fff4ca-385da06dbadmr4891701fa.27.1769139917884; Thu, 22 Jan 2026 19:45:17 -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> <213ed021-c57e-40b6-8357-c797f52c7d34n@googlegroups.com> In-Reply-To: From: Chris Riley Date: Thu, 22 Jan 2026 22:45:06 -0500 X-Gm-Features: AZwV_QjfuTSErX6J7HvL-hxFIr2oWNzaP7-9UdmVFsYl2D9f3Uoto1iRnGkrxVI Message-ID: Subject: Re: [bitcoindev] Re: The Cat, BIP draft discussion. To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000005d102d064905fc1b" X-Original-Sender: criley@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Yae1Oq93; arc=pass (i=1); spf=pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=criley@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 (/) --0000000000005d102d064905fc1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The issue with defining all non-monetary data as spam is that it eliminates functionality Bitcoin has relied on since inception. Bitcoin was designed from v0.1 as a distributed timestamp server and ordering system, not solely as a payment processor. The genesis block contains non-monetary data, and early Proof-of-Existence uses pre-dated OP_RETURN. Time-locked contracts (nLockTime) have existed since v0.1 and underpin CLTV/CSV-based constructions, including the Lightning Network, DLCs, and off-chain adjudication. Sidechain anchoring and systems like OpenTimestamps depend on Bitcoin=E2=80=99s immutability as a distributed order of events. Protoco= l upgrades themselves rely on non-monetary signaling via version bits and miner flags. As stated in the whitepaper, the proof-of-work chain is a solution to distributed timestamping and majority decision-making. Monetary transactions depend on this ordering. If all non-monetary data is defined as spam, Bitcoin cannot function as Bitcoin. The opcodes in v0.1 clearly show that it was intended to do more than "Send X from A->B"-and they weren't disabled due to philosophical opposition, but DOS, consensus etc concerns. Please note, this does not imply that bulk data storage belongs on L1, merely that "spam is easy to define as anything non-monetary" isn't as easy as one might think. Have a good one :-) On Thu, Jan 22, 2026 at 4:54=E2=80=AFPM Pepe Hodler = wrote: > Hi list. > > Which brings me to my disagreement, which I know is not shared by a numbe= r > of contributors here: just as it is hard to define spam on Bitcoin > > I don't understand how anyone could be confused about the concept of spam > on bitcoin. Bitcoins is "A Peer-to-Peer Electronic Cash System" according > to the white paper. As such, anything not intended as a monetary > transaction is spam. > > The use of fake pubkeys to store data on chain, that is an unsupported an= d > unsanctioned use of bitcoin. That is spam, and an attack, not a monetary > transaction. > > Same with fake scripthash used to store arbitrary data, unsupported and > unsanctioned use of bitcoin. That is spam, and an attack, not a monetary > transaction. > > And the same goes for the Segwit exploit and the Taproot exploit. That is > exploiting bitcoin to store arbitrary data in an unsanctioned way, spam, = an > attack on bitcoin. > > When Segwit and Taproot were implemented, nobody, absolutely nobody was > welcoming those upgrades as a way to store jpegs and other garbage on > chain. That is not what bitcoin, Segwit, and Taproot were built for. > > If you are making use of OpenRelay and/or SlipStream to bypass the policy > of the majority of nodes, you are a spammer and an attacker, not a bitcoi= ner. > You are trying to skirt the only use case of bitcoin. > > When there are blocks like this one: > https://mempool.space/block/00000000000000000000ed962f87a0c350b1401fe546d= b60e6d78e34ab549378 . > Over 60% of the transactions in that block are not sending or receiving a > single sat. It's all op_returns with no sats in them. That is not what > bitcoin was designed or sanctioned for. > > These people are not users, they are attackers and spammers. How can you > look at inscriptions, runes, ordinals, fake pubkeys, fake scripthash, > stamps, and op_return with 0 sats in them and wonder if those are legit > bitcoin monetary transactions? > Now, some have tried to claim "My ordinal is a consensus valid > transaction". And of course it is, otherwise it would not have been added > to a block. But that's like saying the Nigerian prince email followed all > the SMTP and POP protocols of email, therefore it's not spam. Some spam > defenders have tried to claim they have paid their miner fee. Of course > they did, but that's like saying the sender of the Nigerian prince email > paid his internet, therefore it's not spam. > > If you are confused about what constitutes spam on bitcoin, please > explain. While I'm sure there are some transactions that could be tricky > and controversial to identify as spam, I"m sure we can all agree that > inscriptions, stamps, jpegs, fake pubkeys, fake scripthash, unusually lar= ge > Segwit data, ordinals, runes, etc, are all clearly spam. > > it's also very hard to define it in a discussion forum like this one. > > > I just did it, see above. It really wasn't that hard. How are you confuse= d > about the definition of spam as it pertains to bitcoin? Because bitcoin i= s > money, they have to obfuscate their spam to make it look like a legitimat= e > monetary transaction to the system. So you could make the case that it's > harder to distinguish spam from a real monetary transaction. But defining > spam on it's own is pretty easy. > > But ultimately, it does not belong to devs to decide what is spam. Don't > think that just because we know C++, that somehow gives us authority to > decide what direction bitcoin should be taking, and what spam is. > > That decision belongs to the nodes. And it's clear that the nodes are not > given the tools to decide for themselves what spam is or what spam isn't, > with comprehensive user configurable spam filters. > > Notions of motivation of contributors (such as they are paid by such and > such a company) should not be relevant. > > > Are you suggesting that conflict of interest is not a thing? If someone i= s > advocating against any and all measures against spam, I would really like > to know where their interests lie. > > Everything should be open to discussion which is implementation-technical > (so obviously not e.g. threats of violence or things that bring legal > liability to participants or have zero relevance to Bitcoin's technical > development) even if it's philosophy-motivated. And blocking should be > reserved either as an anti-DOS measure if volume gets out of control, or = if > it brings dangers as per the previous parenthetical. > > > This comes across as a thinly veiled attempt to censor anyone who wants t= o > combat spam, and their employees/employers. This idea of censoring > "confiscatory" proposals never came up when someone proposed confiscation > though what he called "demorage" or when someone proposed seizing Satoshi= 's > coin. > > If you want to buy or sell pancakes, or JPEgs, or anything else for that > matter, bitcoin is here to serve you. But your pancakes and your JPEGs > don't belong on the bitcoin chain. > > Disclaimer: I own bitcoin, I run a bitcoin business in El Salvador. I own > no inscriptions or spam of any kind, and I don't profit from any spam > related companies. > > 40% of the UTXO set is dust spam UTXOs that contains less than 0.0017% of > the total bitcoin issued. This constitutes an attack on bitcoin. I think = we > all should start acknowledging the problem, and stop asking ourselves > dismissive questions like "What is spam anyways?" and use that question a= s > an excuse to pretend there is no problem. > > Cheers, Pepe > > > > On Tuesday, 30 December 2025 at 08:51:56 UTC-6 Antoine Riard wrote: > > Hi list, > > > Which brings me to my disagreement, which I know is not shared by a > number of contributors here: just as it is hard to define spam on Bitcoin= , > it's also very hard to define it in a discussion forum like this one. > Making suggestions which *I* think are terrible, or detrimental, on a lis= t > like this, should never be disallowed here. Notions of motivation of > contributors (such as they are paid by such and such a company) should no= t > be relevant. Everything should be open to discussion which is > implementation-technical (so obviously not e.g. threats of violence or > things that bring legal liability to participants or have zero relevance = to > Bitcoin's technical development) even if it's philosophy-motivated. And > blocking should be reserved either as an anti-DOS measure if volume gets > out of control, or if it brings dangers as per the previous parenthetical= . > > I'm fully sharing waxwing reasonable opinion. While I can understand > gmax's sentiment being fed > up with poor coin confiscation proposals again and again on the mailing > list, the cure would be > worst than the disease. Maybe, I'm very voltairean here, but you don't > fight ill-founded opinions. > by persecuting their authors (--otherwise, down the road you take the ris= k > of seeing the bastille > popped up). Rather than you fight them back by doing the work to persuade > and to convince those > ideas you find stupid are indeed *objectively* stupid. > > To me, it's a sign of strength and confidence that Bitcoin and its > development process can > withstand and endure the most "outrageous" controversies. For sure, I hav= e > been enough times > in the shoes of someone who has to champion controversial changes (cf. > `mempoolfullrbf`) to not > negate that the strength of the process is kinda traded on the back of th= e > devs, but this is not > altering my mind on what I think should be *ideally* the development > process in terms of openess > and publicity. > > My humble opinion only, as we said. > > Best, > Antoine > OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1c= e > Le mercredi 24 d=C3=A9cembre 2025 =C3=A0 17:23:48 UTC, waxwing/ AdamISZ a= =C3=A9crit : > > Hi Greg, list: > > > 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 goi= ng > 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 discus= s > whatever ill-founded concepts they want but they're not entitled to the > time and the reputation of the participants here for offensively misguide= d > proposals. > > I'm a huge agree-er with the motivation of this comment and a huge > disagree-er with the suggestion itself. > > Actual confiscation, whatever the reason, hugely undermines Bitcoin's > value to humanity - note I am not saying its financial value, but value a= s > a project (and if we didn't see such value what the hell are we doing > here). Of course those two types of value are very closely linked, but th= ey > are still distinct. I hold that same belief even when we are talking abou= t > other suggestions of confiscation, such as to address a quantum threat - > something that has recently been discussed here, extensively. > > Which brings me to my disagreement, which I know is not shared by a numbe= r > of contributors here: just as it is hard to define spam on Bitcoin, it's > also very hard to define it in a discussion forum like this one. Making > suggestions which *I* think are terrible, or detrimental, on a list like > this, should never be disallowed here. Notions of motivation of > contributors (such as they are paid by such and such a company) should no= t > be relevant. Everything should be open to discussion which is > implementation-technical (so obviously not e.g. threats of violence or > things that bring legal liability to participants or have zero relevance = to > Bitcoin's technical development) even if it's philosophy-motivated. And > blocking should be reserved either as an anti-DOS measure if volume gets > out of control, or if it brings dangers as per the previous parenthetical= . > > Just my opinion of course, I know that moderation of lists is not a simpl= e > matter. > > Cheers, > AdamISZ/waxwing > On Tuesday, December 23, 2025 at 10:26:16=E2=80=AFPM UTC-3 Greg Maxwell w= rote: > > 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 particula= r > 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 prett= y > 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 ne= ed > 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 spendi= ng > 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 me= et > 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 goi= ng > 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 discus= s > whatever ill-founded concepts they want but they're not entitled to the > time and the reputation of the participants here for offensively misguide= d > proposals. > > > On Tue, Dec 23, 2025 at 6:27=E2=80=AFPM John wrot= e: > > 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* t= o > 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 woul= d > only increase the potential 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 about > stamps put in the effort to define their exclusions in ways that are safe > 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 here= . > > The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without = a > consensus change is that a clever use of steganography could cause one of > those otherwise unspendable outputs to be spendable, thus causing a fork > between those 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 t= he > 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 wro= te: > > On Fri, Dec 12, 2025 at 9:26=E2=80=AFPM Jonathan Voss = wrote: > > Since the Bitcoin Stamps outputs are already unspendable, it makes perfec= t > 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 has > long done so for several 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 > "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-aa66= ea0cfb79n%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+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd1= 69f1a159n%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/cf39fdca-e996-43be-ab52-573a= edd619d5n%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/= CAL5BAw0RV8A_Ny3GSoR1gCSEHxdfkWu%2BsLQCp7KJCet0Sf%3DJuQ%40mail.gmail.com. --0000000000005d102d064905fc1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

The issue with defining all non-monetary data as = spam is that it eliminates functionality Bitcoin has relied on since incept= ion. Bitcoin was designed from v0.1 as a distributed timestamp server and o= rdering system, not solely as a payment processor. The genesis block contai= ns non-monetary data, and early Proof-of-Existence uses pre-dated OP_RETURN= .

Time-locked contracts (nLockTime) have e= xisted since v0.1 and underpin CLTV/CSV-based constructions, including the<= span class=3D"gmail-Apple-converted-space">=C2=A0Lightning Netwo= rk, DLCs, and off-chain adjudication. Sidechain anchoring and= systems like=C2=A0O= penTimestamps=C2=A0depend on Bitcoin=E2=80=99s immutab= ility as a distributed order of events. Protocol upgrades themselves rely o= n non-monetary signaling via version bits and miner flags.

As stated in the whitepaper, the proof-of-work chain is a = solution to distributed timestamping and majority decision-making. Monetary= transactions depend on this ordering. If all non-monetary data is defined = as spam, Bitcoin cannot function as Bitcoin. The opcodes in v0.1 clearly sh= ow that it was intended to do more than "Send X from A->B"-and= they weren't disabled due to philosophical opposition, but DOS, consen= sus etc concerns.=C2=A0 Please note, this does not imply that bulk data sto= rage belongs on L1, merely that "spam is easy to define as anything no= n-monetary" isn't as easy as one might think.

Have a good one :-)


On Thu, Jan 22, 2026 at 4:54=E2=80=AFPM Pepe Hodler <pepehodler@gmail.com> wrote:
Hi list.

Which brings me to my disagreement, which I know is not shared by a number of contributors here: just as it is hard to define spam on Bitcoin

I don&#= 39;t understand how anyone could be confused about the concept of spam on bitcoin. Bitcoins is "A Peer-to-Peer Electronic Cash System" according to the white paper. As such, anything not intended as a monetary transaction is spam.

The use= of fake pubkeys to store data on chain, that is an unsupported and unsanctioned use of bitcoin. That is spam, and an a= ttack, not a monetary transaction.

Same with fake scripthash used to store arbitrary data, unsupported and unsanctioned use of bitcoin.=C2=A0That is spam, and an attack, not a mo= netary transaction.

And the same goes for the Segwit exploit and the Taproot exploit. Th= at is exploiting bitcoin to store arbitrary data in an unsanctioned way, spam, an attack on bitcoin.=C2=A0

=20

When Segwit and Taproot were implemented, nobody, absolutely nobody was welcoming those upgrades as a way to store jpegs and other garbage on chain. That is not what bitcoin, Segwit, and Taproot were built for.

If=C2=A0you are making use of OpenRelay and/or SlipStream to bypass the= =20 policy of the majority of nodes, you are a spammer and an attacker, not a bitcoiner. Yo= u are trying to skirt the only use case of bitcoin.=C2=A0

When there are= blocks like this one:=C2=A0https://mempool.space/block/00000000000000000000ed962f87a0c350b1401fe546db= 60e6d78e34ab549378=C2=A0. Over 60% of the transactions in that block ar= e not sending or receiving a single sat. It's all op_returns with no sats in them. That is not what bitcoin was designed or sanctioned for.

These people are not users, they are attackers and spammers. How can you look at inscriptions, runes, ordinals, fake pubkeys, fake scripthash, stamps, and op_return with 0 sats in them and wonder if those are legit bitcoin monetary transactions?

Now, some have tried to claim "My ordinal is a consensus valid transaction= ". And of course it is, otherwise it would not have been added to a block. But that's like saying the Nigerian prince email followed all the SMTP and POP protocols of email, therefore it's not spam.= =C2=A0= =C2=A0S= ome spam defenders have tried to claim they have paid their miner fee. Of course they did, but that's like saying the sender of the Nigeria= n prince email paid his internet, therefore it's not spam.=C2=A0 = =C2=A0

If you are confused about what constitutes spam on bitcoin, please explain. While I'm sure there are some transactions that could be tricky and controversial to identify as spam, I"m sure we can all agree that inscriptions, stamps, jpegs, fake pubkeys, fake scripthash, unusually large Segwit data, ordinals, runes, etc, are all clearly spam.=C2=A0

it's also very hard to define it in a discussion forum like this one.=C2=A0=

I just did it, see above. It really wasn't that hard. How are you confused about the definition of spam as it pertains to bitcoin? Because=20 bitcoin is money, they have to obfuscate their spam to make it look like a legitimate monetary transaction to the system. So you could make the=20 case that it's harder to distinguish spam from a real monetary=20 transaction. But defining spam on it's own is pretty easy.=C2=A0= =C2=A0

But ultimately, it does not belong to devs to decide what is spam. Don't think that just because we know C++, that somehow gives us= =20 authority to decide what direction bitcoin should be taking, and what spam is.

That decis= ion belongs to the nodes. And it's clear that the nodes are not given the tools to decide for themselves what spam is or what spam isn'= t, with comprehensive user configurable spam filters.

Notions of motivation of contributors (such as they are paid by such and such a company) should not be relevant.

Are you suggesting that conflict of interest is not a thing? If someone is advocating against any and all measures against spam, I would really like to know where their interests lie.

Everything should be open to discussion which is implementation-technical (so obviously not e.g. threats of violence or things that bring legal liability to participants or have zero relevance to Bitcoin's technical development) even if it's philosophy-motivated. And blocking should be reserved either as an anti-DOS measure if volume gets out of control, or if it brings dangers as per the previous parenthetical.

This= =20 comes across as a thinly veiled attempt to censor anyone who wants to=20 combat spam, and their employees/employers. This idea of censoring=20 "confiscatory" proposals never came up when someone proposed=20 confiscation though what he called "demorage" or when someone proposed seizing Satoshi's coin.=C2=A0
=

If you want to buy or sell=20 pancakes, or JPEgs, or anything else for that matter, bitcoin is here to serve you. But your pancakes and your JPEGs don't belong on the bitcoi= n chain.

Disclaimer: I own bitcoin, I run a bitcoin business in El Salvador. I own no inscriptions or spam of any kind, and I don't profit from any spa= m related companies.

40% of the UTXO set is dust=20 spam UTXOs that contains less than 0.0017% of the total bitcoin issued.=20 This constitutes an attack on bitcoin. I think we all should start=20 acknowledging the problem, and stop asking ourselves dismissive=20 questions like "What is spam anyways?" and use that question as a= n=20 excuse to pretend there is no problem.

Cheers, Pepe


=20

On Tuesday, 30 December 2025 at 08:51:56 U= TC-6 Antoine Riard wrote:
Hi list,

> Which brings me to my di= sagreement, which I know is not shared by a number of contributors here: ju= st as it is hard to define spam on Bitcoin, it's also very hard to defi= ne it in a discussion forum like this one. Making suggestions which *I* thi= nk are terrible, or detrimental, on a list like this, should never be disal= lowed here. Notions of motivation of contributors (such as they are paid by= such and such a company) should not be relevant. Everything should be open= to discussion which is implementation-technical (so obviously not e.g. thr= eats of violence or things that bring legal liability to participants or ha= ve zero relevance to Bitcoin's technical development) even if it's = philosophy-motivated. And blocking should be reserved either as an anti-DOS= measure if volume gets out of control, or if it brings dangers as per the = previous parenthetical.

I'm fully sharing waxwing reasonable opi= nion. While I can understand gmax's sentiment being fed
up with poor= coin confiscation proposals again and again on the mailing list, the cure = would be
worst than the disease. Maybe, I'm very voltairean here, bu= t you don't fight ill-founded opinions.
by persecuting their authors= (--otherwise, down the road you take the risk of seeing the bastille
po= pped up). Rather than you fight them back by doing the work to persuade and= to convince those
ideas you find stupid are indeed *objectively* stupid= .

To me, it's a sign of strength and confidence that Bitcoin and= its development process can
withstand and endure the most "outrage= ous" controversies. For sure, I have been enough times
in the shoes= of someone who has to champion controversial changes (cf. `mempoolfullrbf`= ) to not
negate that the strength of the process is kinda traded on the = back of the devs, but this is not
altering my mind on what I think shoul= d be *ideally* the development process in terms of openess
and publicity= .

My humble opinion only, as we said.

Best,
Antoine
OTS= hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce
=
Le mercredi 24 d=C3=A9cembre 2025 =C3=A0 17:23:48 UT= C, waxwing/ AdamISZ a =C3=A9crit=C2=A0:
Hi Greg, list:
<= br>
>=C2=A0I think the list should adopt a 1 year ban on parti= es *and their*=20 employer(s) (if known) for any coin confiscation=C2=A0proposal on the list= =20 going forward (after, of course, making the rule clear on the signup=20 page).=C2=A0 It's tiresome and beyond being a waste of time risks under= mining public confidence in Bitcoin to see the constant trickle of these=20 outrageous=C2=A0proposals in venues where they previously understood that= =20 serious discussions were to be had. People are, of course, free to=20 discuss whatever ill-founded concepts they want but they're not entitle= d to the time and the reputation of the participants here for offensively misguided proposals.=C2=A0

I'm a huge agree-e= r with the motivation of this comment and a huge disagree-er with the sugge= stion itself.

Actual confiscation, whatever the re= ason, hugely undermines Bitcoin's value to humanity - note I am not say= ing its financial value, but value as a project (and if we didn't see s= uch value what the hell are we doing here). Of course those two types of va= lue are very closely linked, but they are still distinct. I hold that same = belief even when we are talking about other suggestions of confiscation, su= ch as to address a quantum threat - something that has recently been discus= sed here, extensively.

Which brings me to my disag= reement, which I know is not shared by a number of contributors here: just = as it is hard to define spam on Bitcoin, it's also very hard to define = it in a discussion forum like this one. Making suggestions which *I* think = are terrible, or detrimental, on a list like this, should never be disallow= ed here. Notions of motivation of contributors (such as they are paid by su= ch and such a company) should not be relevant. Everything should be open to= discussion which is implementation-technical (so obviously not e.g. threat= s of violence or things that bring legal liability to participants or have = zero relevance to Bitcoin's technical development) even if it's phi= losophy-motivated. And blocking should be reserved either as an anti-DOS me= asure if volume gets out of control, or if it brings dangers as per the pre= vious parenthetical.

Just my opinion of course, I = know that moderation of lists is not a simple matter.

<= div>Cheers,
AdamISZ/waxwing
On Tuesday, Dece= mber 23, 2025 at 10:26:16=E2=80=AFPM UTC-3 Greg Maxwell wrote:
The 'dust threshold' isn't a consensus parameter,= it's just a number pulled out of the air that didn't seem unreason= able based on average fee behavior.=C2=A0 But in any particular block trans= actions may need no particular fee level at all, including zero fees.=C2=A0= And in some cases it may be very economically advantageous=C2=A0to spend a= n output even if its face value doesn't support it, NFT's being a o= ne such example (although one I consider pretty dumb).
=C2=A0
This proposal also appears to have ignored the prior discussion part= icularly where it was pointed out that 'deleting' outputs will not = achieve the goal of deleting the tokens connected to them (so won't eli= minate the incentive), or that txouts=C2=A0which are predictably not going = to be accessed (as this proposal claims applies to the txouts it targets) d= on't have as significant performance implications (because they don'= ;t need to be cached in ram).=C2=A0 It also appears to be uninformed=C2=A0b= y advances like utxotree which makes the absolute size of the txout set muc= h less important, but would make mass removals such as that described here= =C2=A0expensive.=C2=A0 Nor has it considered that given the level of fee sp= ending on NFT traffic a requirement to keep it over some (reasonable) thres= hold would not likely discourage it, or the fact that existent=C2=A0NFT out= puts are generally over the dust limit in any case (so the proposals failur= e 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=C2=A0proposal= on the list going forward (after, of course, making the rule clear on the = signup page).=C2=A0 It's tiresome and beyond being a waste of time risk= s undermining public confidence in Bitcoin to see the constant trickle of t= hese outrageous=C2=A0proposals in venues where they previously understood t= hat serious discussions were to be had. People are, of course, free to disc= uss whatever ill-founded concepts they want but they're not entitled to= the time and the reputation of the participants here for offensively misgu= ided proposals.=C2=A0


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

Here is a related proposal by Matteo Pellegrini
@matte= opelleg



Lynx.

Abstra= ct
This proposal introduces a periodic, consensus-enforced mechanism for= rendering UTXOs below the network's dust threshold permanently unspend= able. At each halving block, UTXOs that have remained below the dust thresh= old since the previous halving become unspendable. These UTXOs become unspe= ndable and may be pruned from the UTXO set entirely, reducing node storage = requirements and eliminating the economic model that incentivizes their cre= ation.

Motivation
The Bitcoin UTXO set has grown substantially du= e to various factors, including inscription protocols, spam attacks, and ge= neral dust accumulation. Recent proposals such as "The Cat" (Non-= monetary UTXO Cleanup) by @ostrom72158
=C2=A0 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 fl= aw: 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-Bitcoi= n software that can change, have bugs, or interpret protocols differently.<= br>
2) Protocol targeting: By specifically identifying inscription and s= tamp outputs, the proposal makes subjective judgments about which Bitcoin u= ses are legitimate. This sets a precedent for protocol-level discrimination= .

3) Cat-and-mouse dynamics: Targeting specific protocols incentiviz= es workarounds. If Ordinals dust is targeted, protocols will adapt to creat= e dust that doesn't match the list criteria.

4) Static snapshot:= A one-time list cleanup provides temporary relief but does nothing for fut= ure UTXO accumulation.

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

A better approach t= argets 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 out= puts costs more in fees than the output is worth. These UTXOs are already &= quot;dead" in practice; this proposal simply makes that reality explic= it at the consensus layer.

By using a threshold rather than a list, = Lynx:

- Requires no external indexers
- Makes no judgment about w= hy a UTXO is small
- Applies equally to all participants
- Provides o= ngoing, 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 re= quired to meet the dust limit for P2PKH addresses and ensure transferabilit= y across all address types. This "postage" amount is standard acr= oss inscription tooling and marketplaces.

A threshold of 999 sats ca= ptures the vast majority of inscription UTXOs without requiring any protoco= l-specific targeting. The economic model of inscriptions depends on these d= ust-level UTXOs being spendable; Lynx breaks that model through neutral, th= reshold-based rules rather than list-based discrimination.

Specifica= tion

Definitions

-=C2=A0 Dust threshold: 999 sats. Any UTXO w= ith a value less than 999 sats is subject to Lynx enforcement.

- Hal= ving 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 threshold and= qualifying UTXOs are recorded.

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

Lynx UTXOs:
- Existed at the snapshot block
- Had a value le= ss than 999 sats
- Remained unspent through the enforcement period (~4 y= ears)

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,0= 00:
- Any UTXO that was in the snapshot set and remains unspent becomes = permanently unspendable
- Transactions attempting to spend these UTXOs a= re invalid

3) Pruning: 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 the= y were already spent.

4) Grace period: The ~4 year window between sn= apshot and enforcement provides ample time for holders to consolidate sub-d= ust UTXOs if they wish to preserve the value.

Activation

Acti= vation method: TBD (Speedy Trial, BIP8, or other mechanism as determined by= community consensus)

Recommended first snapshot: The halving follow= ing activation lock-in

Rationale

Why a fixed threshold?
Using a fixed threshold of 999 sats rather than referencing the dynamic r= elay dust limit provides:

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

- Predictability: Everyo= ne knows exactly what qualifies, forever

- Consensus clarity: No amb= iguity 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 occ= ur
- Sufficient notice: ~4 years is generous warning for any cleanup act= ion
- Aligned incentives: As block rewards decrease, fee revenue and UTX= O efficiency become more critical to network sustainability
- Natural ca= dence: 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 again= st dust accumulation. Periodic enforcement:

- Establishes a permanen= t, predictable norm
- Removes any expectation that dust UTXOs have indef= inite 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 nodes already reject transactions that reference unknown out= points. 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 k= now why the outpoint is missing (spent? never existed? pruned?).

Aft= er enforcement, a Lynx UTXO is functionally equivalent to a spent output. N= odes can simply delete it from the UTXO set. Any future transaction attempt= ing to spend it will reference an outpoint the node doesn't recognize, = and will be rejected through existing validation logic.

This means:<= br>
- No separate "Lynx list" is required
- No new validati= on logic is needed
- Pruning is optional; nodes MAY keep Lynx UTXOs if t= hey wish
- The UTXO set shrinks naturally as nodes prune

Why 999 = sats?

The threshold of 999 sats is chosen because:

- Above al= l dust limits: Captures UTXOs at or below the dust limit for all script typ= es (P2PKH: 546, P2TR: 330, etc.)
- Captures all standard inscriptions: T= ypical inscription UTXOs contain exactly 546 sats as "postage"; w= ell 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 a= ll 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
- Pr= ovide consolidation tools during the grace period
- Update UTXO selectio= n 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 unspendab= le OP_RETURN outputs
- Satoshi's untouched coinbase rewards

T= he bitcoin supply cap remains unchanged; the affected outputs simply become= irrecoverable. Holders receive ~4 years notice to consolidate if they valu= e 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

P= reliminary assessment: LN dust limits are already set conservatively above = relay dust limits, so impact should be minimal. However, this requires veri= fication from LN implementers.

Fixed threshold vs. future fee market= s

The 999 satoshi threshold is fixed in consensus rules and does not= adjust based on fee market conditions.=C2=A0
This is intentional:
- A fixed threshold provides certainty for users and developers
- If f= ee markets change dramatically, a future soft fork could adjust the thresho= ld
- The ~4 year grace period allows the community to observe and adapt<= br>
If Bitcoin's fee market evolves such that 999 sats becomes econo= mically significant to spend, this would indicate broader success of the ne= twork; and the community could choose to lower or eliminate the threshold t= hrough a subsequent proposal.

Acknowledgments
This proposal build= s on the problem identification in "The Cat" (Non-monetary UTXO C= leanup) while proposing a list-free alternative mechanism. The Cat correctl= y identifies UTXO bloat as a problem worth solving; Lynx offers a more neut= ral 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 bee= n directly copied.=C2=A0

In any case, your message= makes no sense. If an output is provably unspendable then it is unspendabl= e.=C2=A0 No amount of "clever steganography" can change that.=C2= =A0 =C2=A0If you're imagining that perhaps they are *presumed* to be un= spendable but actually *are* spendable, then sure that would be an issue bu= t with any change to consensus relevant code great care must be taken to no= t introduce errors.=C2=A0 Actually *making* a consensus change would only i= ncrease the potential for mistakes.

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

But in any case it is better that (any) implementation= s that care about stamps put in the effort to define their exclusions in wa= ys that are safe 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 <k98...@gmail.com> wrote:
This is my thi= rd attempt to respond to this. Idk what is going wrong here.

=
The problem with dropping Bitcoin Stamps UTXOs from the UTXO set witho= ut a consensus change is that a clever use of steganography could cause one= of those otherwise unspendable outputs to be spendable, thus causing a for= k between those nodes that adopted the Stamp pruning method and those that = did not once one of those steganographic Stamps is spent. Though this is un= likely, it is still technically possible, and I would not put it past the d= enizens of the Internet to stir up trouble just for its own sake.

On Friday, December 12, 2025 at 6:49:41=E2=80=AF= PM 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 St= amps outputs are already unspendable, it makes perfect sense to mark and dr= op them from the UTXO set.

There is no consensus change involved in not storing a p= rovably unspendable output, it's just an implementation detail with no = interoperability implications and doesn't need a BIP.=C2=A0 Bitcoin cor= e has long done so for several types of unspendable outputs, e.g. outputs o= ver 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.

--
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.

--
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/cf39fdca-e996-43be-ab52-573aedd619d5n%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/CAL5BAw0RV8A_Ny3GSoR1gCSEHxdfkWu%2BsLQCp7KJCet0Sf%3DJuQ%= 40mail.gmail.com.
--0000000000005d102d064905fc1b--