From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 20 Nov 2025 01:49:11 -0800 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vM1Hq-0004l8-6o for bitcoindev@gnusha.org; Thu, 20 Nov 2025 01:49:10 -0800 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-3e225026ef8sf1207737fac.1 for ; Thu, 20 Nov 2025 01:49:09 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1763632144; cv=pass; d=google.com; s=arc-20240605; b=bANjgMfWI6fjUhEkg4KvVZykvrMfX2/eM1Pkz4oKEeRW58WVh7X9TQEERiaE2+Djpn 0rNKWUBvR5jVJYT1wSXKsBy+ITvCOseNg+vPHbuDRqmqN9BYgl3zETgxx8QbFvsVU2Lk OekXztBE5o1SeggWpKRpsH5vJ9OO87wCFNHfvIYNTwKbo9BGdgfLjZ/VpZ0/JprUnqg8 YK3VMQFG4Qlyb6yPHR3/um9L34C8h+gXZuFJXKO2jJLlxROObQPPyXcvvhXO8QHHOIEL rlIUpTDfQiLi7Jf2/zW6B5Pu3o3iQF5FNm2MCW3mL2cW4RgIiKo6X7us0lIo4kAkaf5r MHgA== 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:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=bwU9Y1PsMAtOPbuxRwLLjIxaISQCm+L70yTAqzyIG6Y=; fh=Ljv1qLipx1aD6J/G85FoBZ5syU+GBxYzx8xfm36A4QM=; b=EpLD4n9+wNWeZCbnTUNVTXVjyYqiROVtTvq4cJKD0DHbA5dv4A/DLzYkrrrXist394 L9lBYJfvn7a97ugxcuMXYbwiSumZp1xnlWWxPMlBEXSjoONQm6OePgjnukdnkQj/zG2h 4+XmPEXLRQF+D3OVahSCWPcJDegQxVEK4rLTvW51BsxkN3xXmlIaboFyRNgXEO/Bveso bVBhRk3xwQMhEOIAjEVg3rRyYlARKzRahYwcw6Eqr4prWuM5j10Ce7ZnGkhWlcmr60Uc kKv+8cZFx+mZT4x8SZx05h+L5LQl+sLYqoWIBG/aEPZZejIL62KGs0VzAfyywuhnIlXk dsEg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=I0Clxugv; spf=pass (google.com: domain of laissez.faire.btc@gmail.com designates 2a00:1450:4864:20::541 as permitted sender) smtp.mailfrom=laissez.faire.btc@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=1763632144; x=1764236944; 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:mime-version :sender:from:to:cc:subject:date:message-id:reply-to; bh=bwU9Y1PsMAtOPbuxRwLLjIxaISQCm+L70yTAqzyIG6Y=; b=w2RKc5LGDxncuQLIF8v7t/XzPLCARFBPRTK1Koc0qd+Bfh1M/fP5bIkoIuwPZFvuiX 1JoVZ0YSSFxlwNyWy1lpq+patPqHaNDpfmrB4Fpg+ozip88nfqAfhux23qMUV36Ml5q5 TxeFzd6XNxskHf4hdtfEDd05LZYpaJe1OgzkArGtXdwUV6D8kIMqTs+uWwsZL9Bt7sK8 5cflZo+R9I+iWCNl3x7zuDuQwkaLGW9HfSGc4cTtkkyFLqcXR2MSiRbYtq+S6Jxsrkdb T+CmEHC5LcXztrdFX8HRV2+URBoGaGy43dwq8il9bdSArWGmdOBQeOWkrjhfe08CErB9 FEwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763632144; x=1764236944; 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:mime-version:from :to:cc:subject:date:message-id:reply-to; bh=bwU9Y1PsMAtOPbuxRwLLjIxaISQCm+L70yTAqzyIG6Y=; b=TjrIGoBJP0+iKzYZN64wTdKnMADEhNvsuG9fMTjfY8lvR5rO0RpQ69lhDroNWHH69y pyate/PiHKUDLD1UhC41AuE/pzuIcPh5rbUEHA3GrKQTyrMO+Lg/SB8ID9wIfUVwZVU+ Axiykgvx+WOsNc0eS86f0BPl/fo16dCC1NuQ9jvsjkMmeiUvOSl7zmf5UMYZWqlV3K75 TuOKHus/WBZOohUrksnT/JPwk6YcOfLUV/6dJVVsFRpvvjSZQbB95VciVSt5qXdWFq0j Q1Qe2Of2wcPXT/UgoCro3q9j8TWNWlnF/XLtDxwTrrHGwpNNCN5/3z7kqhyDQLUX+O8a HBOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763632144; x=1764236944; 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:mime-version :x-gm-gg:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=bwU9Y1PsMAtOPbuxRwLLjIxaISQCm+L70yTAqzyIG6Y=; b=TdIpFu/I7YABysr2bGMe96p3SyOWXdV1JSgy12Q6B+tmbVsrWYK7vTQ4ZONrgQxzHW CIOhypb1Ohv01NgtEOqCi5JGrD0dOyx0XOMHe7TbYw1xDeX28v7fk43alFD0A+ZvxZL0 XQC2jswpGo4rxOVTwmUO2OZ4Fg4NtXmqCm4WS+ELRRGmiW9u4XA8YabEgfaY60KFrhxm FfuESIfrMjcWIBFr11fw44ZhWrc8xsiNB89IBjaN0oKwE8qxkApx9llIOjFUTypYjnRC cnghittTQgvocan7GVdDMOCwSNQOBZ17wSDPjTwE5RA7tJN0oEPLRHOXyZfbyxpHL67I gUJA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCX+9H9pV4pyk+Ax+Hv/Tc1hOkFSLtv67iKWLZ4Bc2CoaH7fMJJdqiT7nXYTaETM4G/dvCbldXJ0YwaG@gnusha.org X-Gm-Message-State: AOJu0YxSvK7a3mGMzP/iJbQdgtHsD7KyaOwYXQyvvFjcfPBTNCaDxtku 2+TY84pJKEsYQ3w6C8YKBN7OSNWuY7giMIfxlupJYAz0cGn8NaXQe0mS X-Google-Smtp-Source: AGHT+IFaLyBG/7SADOQ9aCdF0iUfEseylca9St3DlCtqJaqDu9vZufFY2J+t7jZCTKHzMnNno8Ycjw== X-Received: by 2002:a05:6870:9725:b0:3e7:e08e:742 with SMTP id 586e51a60fabf-3ec9a4dbaeemr1814575fac.32.1763632143504; Thu, 20 Nov 2025 01:49:03 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YdF/FiG0PdiG22zzd088ecgC6YHmw6RDngdmAaUz97Jg==" Received: by 2002:a05:6871:4209:b0:3e8:2785:9a19 with SMTP id 586e51a60fabf-3ec9b37e37als213094fac.1.-pod-prod-08-us; Thu, 20 Nov 2025 01:48:59 -0800 (PST) X-Received: by 2002:a05:6808:2444:b0:450:d558:771d with SMTP id 5614622812f47-450ff2a82c0mr1197059b6e.30.1763632138879; Thu, 20 Nov 2025 01:48:58 -0800 (PST) Received: by 2002:a7b:c7d6:0:b0:477:b663:eee5 with SMTP id 5b1f17b1804b1-477b663f122ms5e9; Wed, 19 Nov 2025 17:58:04 -0800 (PST) X-Received: by 2002:a05:6000:22ca:b0:3f7:b7ac:f3d2 with SMTP id ffacd0b85a97d-42cb9a4a111mr756309f8f.43.1763603881706; Wed, 19 Nov 2025 17:58:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1763603881; cv=none; d=google.com; s=arc-20240605; b=gYFEyv6EejHKCXzJMVwOhTOQDqamlQCfLyKMaLAr7rTK3of18uuTEPx/e9DZYJIRp+ c2YUcuiUa8xBMVMavK8Q9FgPyJiPAuCeUVEcZ2hXpvUF12vIeGYEWyUpUV8hQ7FfsJJ2 T81fEF8zQPC7tujeUmjzAT9OFb+rijiO4PCn4gvhF3l2Kqvfzs/MM/+KxwEcLgTxoTb+ CJGLxkblZSXyOlcBEhtacmz2GOGWxxDdj2AcW8xjqhfPEc7txePs4nj5vsT1d0M7IKjs xXP853HBph+G10K3DoGekZVthl8PIZUj/UffU9hI8YpeY1OZ/VFG3RTCRZv3WPGb6lmj DxQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=7/Yzp2tWQm0veSu4+7nBm2s5fTnexoQLW0LzW2Dgjj4=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=SWLu+l0gNkIfVhg8/c/xYVg+r6gI70Y+MOwd8UHcwkkrCnGwWrIyu0Xx6Ix5DTVlNH yYleVXS7uLl/z/qvqURLi85KS38WktE+5KGlYFjOrUX86wSSz3HldyNsiuqxsXSTigFP Ey0N20i1MLCwlor2QMe8p0moF9bUh81B9IIAIk7/IeIHLCDAMOjdbTDEbua69UqU4Laq ucT+oEU93OzQkBBTMW3mCN2XoRo+E2mQCcRIsh8aQdwE/daFOr3LmNZQjJ8H5cv5XoJF ar/Rm2AOFJaMcvTMvLOFvnIT2hOonyJMoThBWPN0AOVlipWWYxwpo45sX24TnNGzoqID eBDQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=I0Clxugv; spf=pass (google.com: domain of laissez.faire.btc@gmail.com designates 2a00:1450:4864:20::541 as permitted sender) smtp.mailfrom=laissez.faire.btc@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com. [2a00:1450:4864:20::541]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-42cb7fb90e3si19923f8f.10.2025.11.19.17.58.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Nov 2025 17:58:01 -0800 (PST) Received-SPF: pass (google.com: domain of laissez.faire.btc@gmail.com designates 2a00:1450:4864:20::541 as permitted sender) client-ip=2a00:1450:4864:20::541; Received: by mail-ed1-x541.google.com with SMTP id 4fb4d7f45d1cf-6417313bddaso471456a12.3 for ; Wed, 19 Nov 2025 17:58:01 -0800 (PST) X-Gm-Gg: ASbGncvDU6w0mhsBMw9JsRqLiWY2w/TJkkK4cvqH6du6vZP+wFAcY0O3/NidHfq01SZ W+TSLKJt4CWgnCYsWbJf2+fj84o29XPW9OGBL1rJz446iLfN1A3J1h1JwaV4FZRB5B5lz+XaNqd Adzhj98F78PaAU0kFvzb40/5rhnUFI4edTXRzzHEjLFFXu0W5GxS74A/9sVtIQ93MB/Rh9V27ea S1idO83fbR2w6IcCp23jSNZ//PqpGalzHm5Y4wyBHnpI+iF5J7hM20RFtV+ATIgW1f/Q/A/rl71 GD44RUp/1xXSxee43igAIveI5M4= X-Received: by 2002:a05:6402:27cc:b0:643:8301:d107 with SMTP id 4fb4d7f45d1cf-645364828ddmr1282530a12.30.1763603880761; Wed, 19 Nov 2025 17:58:00 -0800 (PST) MIME-Version: 1.0 From: Lazy Fair Date: Thu, 20 Nov 2025 12:57:52 +1100 X-Gm-Features: AWmQ_blNbdH3X4aZeRtCnLId_mpxAtwqTOfr84wlrs09UqQ-RPOCTtXWbAB--8M Message-ID: Subject: [bitcoindev] A safe way to remove objectionable content from the blockchain To: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000d65e540643fd066f" X-Original-Sender: laissez.faire.btc@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=I0Clxugv; spf=pass (google.com: domain of laissez.faire.btc@gmail.com designates 2a00:1450:4864:20::541 as permitted sender) smtp.mailfrom=laissez.faire.btc@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 (/) --000000000000d65e540643fd066f Content-Type: text/plain; charset="UTF-8" I propose two changes to Bitcoin, one at the consensus level, and one at the client level. The purpose of this is to support filtering of objectionable content after the content has been mined, allowing each node operator to maintain only that data they find agreeable. In so doing, my hope is that we can satisfy all users, and deal with their greatest concerns. I do however acknowledge those people that want to stop miners from mining non-monetary transactions, because of the data storage and processing cost, and I recognised that this proposal does nothing to address those concerns. *** Motivation *** You can't just change or delete some data from the blockchain, because a hash of everything in a block is included in the next block. If you change the data, you change the hash. The design presented here is an attempt to achieve a compromise, where a person can have all of the benefits of running a full node, including the integrity of the ledger, yet without storing the objectionable content - and importantly without even being able to recreate that objectionable content from what data they still have. *** Preliminary *** Objectionable content is defined here as whatever you want it to be, and two users don't have to share the same views. One person might object to copyrighted material used without permission, another a negative depiction of the prophet Muhammad, and another video of the sexual abuse of children. The design presented below lets each person decide what to remove for themself (if anything), while those who want everything can still have it all. The design lets a user remove any data, and deals with the impact on the matching of block hashes, data integrity and malleability. In the case of OP_RETURN data, the result should be no functional effect at all. Whether that's also possible for other data elements will depend on the semantics of that data. *** Solution *** This solution is based on two ideas, both aimed at maintaining data integrity through hashing, while removing some of the hash's input data stream. *** First Idea *** When performing a hash of some data (D), each chunk of data that's processed updates an internal state (S) of the hashing algorithm. If you know what the internal state is at point A and then at point B, then you can compute the final hash of D even without the data between A and B. This is the first idea. First you need to know what S(A) and S(B) are, and once you do, you can compute the hash of D, without the data between A and B. You run the hashing algorithm normally up to A, then you update the internal state from S(A) to S(B), then you continue hashing from B to the end of D. The hash still works as an integrity check for the data before A, and the data after B: change any of this, and the final hash will change. Now you can safely change or delete the data in between, without breaking the integrity of the blockchain and proof of work - but only if you can securely obtain S(A) and S(B), and only if you don't need the data between A and B for anything else. The easiest way to obtain S(A) and S(B) is to calculate them yourself, but that requires that you hold the objectionable data, at least for a time. That also requires finding someone else that holds the objectionable data. But what if instead, we could share S(A) and S(B) across the network, do it securely, and in a way where up to 100% of nodes could choose to drop the data in between, permanently, without breaking anything? *** Second idea *** It may seem like there is no one you can trust to tell you what S(A) and S(B) are. There is only one source of data that a Bitcoin node can trust, and that is the blockchain, as mined by miners, with the most proof of work, and verified locally. Therefore, the second idea is that S(A) and S(B) are trusted if (and only if) they are written into the blockchain, and verified by the network. For example, we write data to the semantic effect of "In Transaction X: at byte offset A, the internal state of the hash function is S1; at byte offset B, the internal state of the hash function is S2." Miners then mine this statement into a block, and verifiers confirm that it is cryptographically accurate with respect to the data in Transaction X as described - or else they drop the new block as invalid. At this point, any node can choose to delete the data between S1 and S2. This can now be done with confidence because they can double check the accuracy, and the impact on the ledger, before they delete the data. After that they may also be able to share (with the agreement of the receiving node) this modified transaction as part of initial block downloads, along with S1 and S2 - to any other nodes that don't want this objectionable content. The receiving nodes wouldn't immediately and necessarily be able to trust S1 and S2, but they would eventually, once they have the full blockchain. *** Conclusion *** This isn't a concrete proposal - it's not even close - but perhaps it might be the start of a fruitful conversation. I have more to say, but this email is long enough already. Email me if you're interested in discussing or developing these ideas together. I have a private Discord server, but I'm open to other suggestions, or just further discussion here. Laissez faire, laissez passer. Let it be, let it go. -- 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/CABHzxrgbxG1qy3geyNHshA-q6tv0uNNwx5uiswUmAGDDxQjoHg%40mail.gmail.com. --000000000000d65e540643fd066f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I propose two changes to Bitcoin, one at the consensus le= vel, and one at the client level. The purpose of this is to support filteri= ng of objectionable content after the content has been mined, allowing each= node operator to maintain only that data they find agreeable. In so doing,= my hope is that we can satisfy all users, and deal with their greatest con= cerns.

I do however acknowledg= e those people that want to stop miners from mining non-monetary transactio= ns, because of the data storage and processing cost, and I recognised that = this proposal does nothing to address those concerns.

*** Motivation ***
You can't just change or delete some data from= the blockchain, because a hash of everything in a block is included in the= next block. If you change the data, you change the hash. The design presen= ted here is an attempt to achieve a compromise, where a person can have all= of the benefits of running a full node, including the integrity of the led= ger, yet without storing the objectionable content - and importantly withou= t even being able to recreate that objectionable content from what data the= y still have.

*** Prelim= inary ***

Objectionable = content is defined here as whatever you want it to be, and two users don= 9;t have to share the same views. One person might object to copyrighted ma= terial used without permission, another a negative depiction of the prophet= Muhammad, and another video of the sexual abuse of children. The design pr= esented below lets each person decide what to remove for themself (if anyth= ing), while those who want everything can still have it all.

The design lets a user remove any dat= a, and deals with the impact on the matching of block hashes, data integrit= y and malleability.=C2=A0

In the case of OP_RETURN data, the result should be no functional effect = at all. Whether that's also possible for other data elements will depen= d on the semantics of that data.

*** Solution ***

This solution is based on two ideas, both aimed at maintaining data inte= grity through hashing, while removing some of the hash's input data str= eam.

*** First Idea ***<= /div>

When performing a hash o= f some data (D), each chunk of data that's processed updates an interna= l state (S) of the hashing algorithm. If you know what the internal state i= s at point A and then at point B, then you can compute the final hash of D = even without the data between A and B. This is the first idea. First you ne= ed to know what S(A) and S(B) are, and once you do, you can compute the has= h of D, without the data between A and B. You run the hashing algorithm nor= mally up to A, then you update the internal state from S(A) to S(B), then y= ou continue hashing from B to the end of D.

The hash still works as an integrity check for the data= before A, and the data after B: change any of this, and the final hash wil= l change. Now you can safely change or delete the data in between, without = breaking the integrity of the blockchain and proof of work - but only if yo= u can securely obtain S(A) and S(B), and only if you don't need the dat= a between A and B for anything else.

The easiest way to obtain S(A) and S(B) is to calculate them y= ourself, but that requires that you hold the objectionable data, at least f= or a time. That also requires finding someone else that holds the objection= able data. But what if instead, we could share S(A) and S(B) across the net= work, do it securely, and in a way where up to 100% of nodes could choose t= o drop the data in between, permanently, without breaking anything?

*** Second idea ***

It may seem like there is no one yo= u can trust to tell you what S(A) and S(B) are. There is only one source of= data that a Bitcoin node can trust, and that is the blockchain, as mined b= y miners, with the most proof of work, and verified locally. Therefore, the= second idea is that S(A) and S(B) are trusted if (and only if) they are wr= itten into the blockchain, and verified by the network.

For example, we write data to the semantic = effect of "In Transaction X: at byte offset A, the internal state of t= he hash function is S1; at byte offset B, the internal state of the hash fu= nction is S2." Miners then mine this statement into a block, and verif= iers confirm that it is cryptographically accurate with respect to the data= in Transaction X as described - or else they drop the new block as invalid= .

At this point, any nod= e can choose to delete the data between S1 and S2. This can now be done wit= h confidence because they can double check the accuracy, and the impact on = the ledger, before they delete the data. After that they may also be able t= o share (with the agreement of the receiving node) this modified transactio= n as part of initial block downloads, along with S1 and S2 - to any other n= odes that don't want this objectionable content. The receiving nodes wo= uldn't immediately and necessarily be able to trust S1 and S2, but they= would eventually, once they have the full blockchain.

*** Conclusion ***
This isn't a concrete proposal - it's not= even close - but perhaps it might be the start of a fruitful conversation.= I have more to say, but this email is long enough already. Email me if you= 're interested in discussing or developing these ideas together. I have= a private Discord server, but I'm open to other suggestions, or just f= urther discussion here.

= Laissez faire, laissez passer.

Let it be, let it go.

--
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/ms= gid/bitcoindev/CABHzxrgbxG1qy3geyNHshA-q6tv0uNNwx5uiswUmAGDDxQjoHg%40mail.g= mail.com.
--000000000000d65e540643fd066f--