From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 21 Nov 2025 15:25:57 -0800 Received: from mail-qk1-f192.google.com ([209.85.222.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vMaVo-0000xm-Ec for bitcoindev@gnusha.org; Fri, 21 Nov 2025 15:25:57 -0800 Received: by mail-qk1-f192.google.com with SMTP id af79cd13be357-8b24a25cff5sf701564685a.2 for ; Fri, 21 Nov 2025 15:25:56 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1763767550; cv=pass; d=google.com; s=arc-20240605; b=EzBFoyx5rNEvpKYpouG2N42qxSQ2Vkkn/DswlGrLwG3VSWUCaRhub2D4RCaLmuYjSo vjSDg3c6ABftyjywvtO+CMFQKBWMjwfTgfol0ymeDFJHHkLF4qhUpm4udlyRqaUiDAxf 3dWGqh5bswhhf2HWTrHXG+f7ghsAMkweuTb2N1rQt0C1ATVA8TOHs1aG/Wh3Z1cs+DA8 1iude9aKxAXkwrfDArXAKiE8kUjayz00nvF64OBueHI4rFyluDxRlE5vK7DoQv5cd7iB lYIwnpDgUT6C+WKV0jcKTD0lfkD8Gykx4a7gcRwnzz7vpDAju/mBp3w53qDvl6Mn3OyV Ct2Q== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=arJf+HmUAntm9wTD1iApvXSlfPADEb3xI7TSYS1U6Nk=; fh=2a7w0l98EEt8XD23gFUL1P5dTLLEtguY6RHNW1KM3KY=; b=X3jLjVlWk9jpFMF7H3xCnQqXm/BJxt9UVBrIY69/+BG2G1hBKZO1B41FJigoQkBKKK hY6C6oEyu8obxU9Rh4tZvEjDuVNcJcC0UYnyW/Ik7ZY7Ob5BfoAW9oSLOrHPVRirpUhg gBiXoY1FppuYg7tiSYQQh0G8GofS3ZYMvAYdKRDA/JpFuMB5ByN1Ev/SGiDU0HFPJAk/ 0L0Rj17QvvCGLGYk50VUX4X8eT1cl3mAP15A/KvbM0vmEPuhaoZ+4dL974EXEMK3GDR8 oUkPPi6cCZDF0qSNflkaeW5KqXEHKjVeCvjmujLC1FT9JYDwAZmpZ3KygM2nANHtcyp7 80Ew==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MoGy04XH; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::634 as permitted sender) smtp.mailfrom=gmaxwell@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=1763767550; x=1764372350; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=arJf+HmUAntm9wTD1iApvXSlfPADEb3xI7TSYS1U6Nk=; b=gDpWbijUV6UvUthpUGuGrj2vZtroXa/E9zvqmQwNxUezyZnZv0LrtvJYT/Uq/vf+GA 8Y4MC+pJCzUJLTDoqlbIazWDCJ6TtrkOR8lafXC00evKPBPR/9//Duu7FIs9n3IcBup1 1aGbetbdK9JxCwtMr7WHz53iBv0R0MYzIJBE9jgNhnAmdUpL77H5YxYgegkXOK4KtbX+ DEY5qzuCG0y/58lmeykS1BuuEKI5BcOQZabpo2AJlP57SOzfu0R5enMPRfqEhctXY+IG 0T/sf3olQgswXE/tOQZZzbQMALpBvB1AH6jMqBF8/dsn8fVqdLvcxJaQFjFSH+nkHTy8 94xw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763767550; x=1764372350; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=arJf+HmUAntm9wTD1iApvXSlfPADEb3xI7TSYS1U6Nk=; b=gHpEZnMgjItsT9alA1LkaFP+iyB/D8SdWupP4uWM2x1rBunFKKmRhnixxeuVWhZXML z2Rj8KPO+0In1voFPnHRT6b1YaTNaQTm0/+oTZCT5dXgCNTpCTS19vkK3BJR2MNVWjjR U1l4YvGHTxJhOU7dJKr2HQZKDpdLJ9gsEBMRXKPaUKtvhvN4VIrvs22X5KdxjZwwZwHv oc52RCpZkIHWZUdukA7B8TqZwL/BnN5sV1xTLe3qOYzP1z9VU5rrcqx0AnfQot+qpDWs ItbtM2uDhQCZxAmZz9bRs2taIDCDFIWzeb9KvVarQ0ns9Xyc3VovoGGskTz32cQrwd/0 NImw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763767550; x=1764372350; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc: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=arJf+HmUAntm9wTD1iApvXSlfPADEb3xI7TSYS1U6Nk=; b=lqVA8J2o8RH1d9pAGOJzVMgxFslmzozGerr57jI2FfOvmXUnT1mIxIYI1P7KRDfzPZ FemR0N/l6cCq5OgiPVJgAFUwIdfcbVOUm1Yi2/LUr8jfC+gSIAGJclBbHPwV8Ci/wIhL iPczvzjVOmoVFI2YBeSdrG8wPRBOMa2eXbgBuAhk2ZSSjSjtGzlGp+1NTAE8fJRAmr0k 87jwV4qNdfI8E49sqRNo/V07knjBqu/vlSwe2N3p1PTjwpysYxlmpoWOoD5MAJi3RTiN iNwbBM4J31SzPJJAV+dU4c8cUSQFwO6JZyPPG+7Ox7QBZNWJ3M+tmqwZss8S6GJe8B4u C86A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXak9yni4i3WtmX0Uq2/eEBxSgi4PWI41c2ITd5rP/kJi77AKPqkTmXjfLjoj9U15MdJLialW1VJ+J6@gnusha.org X-Gm-Message-State: AOJu0Yx6n3xjq1+YlZCKWktpLpayMm03D3bZ4J5RwN7Chk9JmUp4IuYD Y9NzJMrL6x1ZaM1JEaq0hGvRQ8LKO3ZWZE+9/LfJRfH/9Ivc6I1QOPTo X-Google-Smtp-Source: AGHT+IH4BeA7E0e/mSO+fHq7do0/xUoa4wOgMEqPaCLozxtqyY90nLDP/YuOjTD2h3WljF+ls6K3VQ== X-Received: by 2002:ac8:574c:0:b0:4e8:b288:7b6a with SMTP id d75a77b69052e-4ee58b3d669mr57105631cf.82.1763767549784; Fri, 21 Nov 2025 15:25:49 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YozSN1w92hnnb7qT5JX9zq7K8V8z02g5BFfVX+4yOVug==" Received: by 2002:a05:6214:8008:b0:880:803b:bd47 with SMTP id 6a1803df08f44-8846da603d6ls44245946d6.1.-pod-prod-05-us; Fri, 21 Nov 2025 15:25:43 -0800 (PST) X-Received: by 2002:a05:620a:7001:b0:88f:c5d4:504e with SMTP id af79cd13be357-8b33d5fda39mr491526085a.81.1763767543368; Fri, 21 Nov 2025 15:25:43 -0800 (PST) Received: by 2002:a05:6808:838a:b0:450:c180:fd79 with SMTP id 5614622812f47-450eed00357msb6e; Thu, 20 Nov 2025 10:45:55 -0800 (PST) X-Received: by 2002:a05:6e02:260a:b0:434:6f29:6cb with SMTP id e9e14a558f8ab-435a9074ef7mr39750555ab.26.1763664354427; Thu, 20 Nov 2025 10:45:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1763664354; cv=none; d=google.com; s=arc-20240605; b=B5K1X1a6sLjEk/4vtU9FV5IJRdvqKT2d6rCx242OqKziThIhtkgnbnTe5Ekust3nm9 DkjS9xgNycMqtc47j0CalgpFT1EG/GK8UUXajYImpl9rwCZN1CvDJd8GPb/bCMYY7Lt9 CXtlATItLboQ3olpp/EWdFo6ilkhWg9HkN+3Z9AvDqnfg8rOFvEF3/KjyeJNkhyHgBhn Dn8Iy5XySVb9f5vXfjtlUfTZtlW+RsmlBZkr2I55EjvK6DPyUBFYD1cMvQLkIqYu+XXr /6iMzUJ9PE/jUZOpf9p1tPt+p7Y1P/Y96/L4bSjSHOCJYQ9nFBmtYBrVomzhU5RsU4yt cnUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=u9NSTvcTvMzQh9FVErjuq61pQ9DB8hytAyyiAdxO9eA=; fh=ZtG2GhoDHs4MJE3Iuj+UuXzZ+bE3vAzQsV4cmQkD9a0=; b=aq3NJIr6sIHr+vBHqD55jc646bxiFsF/FOsy4eDwgx7SOVQpqj3V0y9yKTNkirs0IY 2yO5gaRDq6Proq4J9f8tNBfL+M1dzapb5fJ2sV8RwfdNBayNjKbhUfr47/vhfw/nvF8c 0jnXq91Wfn3vvih5JLo7gSndsjRfvt39r6nc0lIs35mIAlwjddrNIvJ8jrrostL9bowv +XMRERnaCJrvQXbGo5WpOc8TCGnRunSMyRuJLQ1znvbQ4rrxWPKSruWbDmVGy0DUo9TX 798/SHbZ4GP7IZ+ZYma6FS7dupUPCNTy3tbTIFyPG3YmIjkA8ymHA6j6Zv307AxNCyYy IvOA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MoGy04XH; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::634 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com. [2607:f8b0:4864:20::634]) by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-435a905e077si1415605ab.3.2025.11.20.10.45.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Nov 2025 10:45:54 -0800 (PST) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::634 as permitted sender) client-ip=2607:f8b0:4864:20::634; Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-29516a36affso17529705ad.3 for ; Thu, 20 Nov 2025 10:45:54 -0800 (PST) X-Gm-Gg: ASbGncvzlziwbqB7AT/EdIPOCVv9lXsRuEfgUOmkmzCWEmMunf22rB81ZteQgHx4p8M DdUjkafvCU56sOXjJbctjTcV/szWxRMefO9lvv7IFhZtTXinro/o1VVaKGoCDsWlmbno5T+c5RQ 8/XO7XxhyeuxlM+acXMwSpOm92468eH8drr5xQtsZtERZwQjdnd8j73+X9A/lETAlw+K8NY3k60 EK+ApDO+UtP/kLDXnO6dXS8ACcmrcb6ou53/naEhguvhy+BWvaSftsE0Cs8drwPOoIG4koWq9aw 9NXl1JCSQ2LkJdIb3Notrj4Xo5AxPwMWnaIEO7IB/GyqeBVRCxE= X-Received: by 2002:a05:7022:418b:b0:11b:1cae:a0fa with SMTP id a92af1059eb24-11c9373753dmr2375698c88.0.1763664353559; Thu, 20 Nov 2025 10:45:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Maxwell Date: Thu, 20 Nov 2025 18:45:41 +0000 X-Gm-Features: AWmQ_blI0BsYanGetPPzVb3Lhnix5lAl2tTD6uyICPjheIwvvegDWi--AiDn3Kc Message-ID: Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain To: Lazy Fair Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000004c077906440b1b01" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MoGy04XH; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::634 as permitted sender) smtp.mailfrom=gmaxwell@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 (/) --0000000000004c077906440b1b01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you find blindly trusting miners acceptable, just run SPV and then you don't store anything but block headers. Aside, allowing attackers access to manipulate a hash's midstate is dubious from a security perspective-- at the very least it's outside of the scope normally analyzed for security. On Thu, Nov 20, 2025 at 9:49=E2=80=AFAM Lazy Fair wrote: > 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 nod= e > 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 minin= g > non-monetary transactions, because of the data storage and processing cos= t, > and I recognised that this proposal does nothing to address those concern= s. > > *** 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 chang= e > 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 ab= le > 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 depictio= n > of the prophet Muhammad, and another video of the sexual abuse of childre= n. > 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. Th= is > is the first idea. First you need to know what S(A) and S(B) are, and onc= e > 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 betwee= n > A and B for anything else. > > The easiest way to obtain S(A) and S(B) is to calculate them yourself, bu= t > 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, a= nd > verified by the network. > > For example, we write data to the semantic effect of "In Transaction X: a= t > 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 min= e > 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. Afte= r > 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 th= is > 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-q6tv= 0uNNwx5uiswUmAGDDxQjoHg%40mail.gmail.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/= CAAS2fgRX3PJEy%2B7GRyANDea2ZFfkWRGr%2B4q9YEV90zhtgv2Bag%40mail.gmail.com. --0000000000004c077906440b1b01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you find blindly trusting miners acceptable, just = run SPV and then you don't store anything but block headers.
=
Aside, allowing attackers access to manipulate a hash's = midstate is dubious from a security perspective-- at the very least it'= s outside of the scope normally analyzed=C2=A0for security.

=
On Thu, Nov 20, 2025 at 9:49=E2=80=AFAM Lazy Fair <laissez.faire.btc@gmail.com>= wrote:
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 ob= jectionable content after the content has been mined, allowing each node op= erator 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, beca= use of the data storage and processing cost, and I recognised that this pro= posal does nothing to address those concerns.

*** Motivation ***

<= div dir=3D"auto">You can't just change or delete some data from the blo= ckchain, because a hash of everything in a block is included in the next bl= ock. 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 b= eing 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 u= sed without permission, another a negative depiction of the prophet Muhamma= d, and another video of the sexual abuse of children. The design presented = below lets each person decide what to remove for themself (if anything), wh= ile those who want everything can still have it all.

The design lets a user remove any data, and de= als with the impact on the matching of block hashes, data integrity and mal= leability.=C2=A0

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

= *** Solution ***

This so= lution is based on two ideas, both aimed at maintaining data integrity thro= ugh hashing, while removing some of the hash's input data stream.
=

*** First Idea ***

When performing a hash of some dat= a (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 witho= ut 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, wi= thout the data between A and B. You run the hashing algorithm normally up t= o A, then you update the internal state from S(A) to S(B), then you continu= e 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 t= he integrity of the blockchain and proof of work - but only if you can secu= rely 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, b= ut 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 i= t 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 trus= t 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 id= ea 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 fu= nction 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 confi= rm that it is cryptographically accurate with respect to the data in Transa= ction X as described - or else they drop the new block as invalid.

At this point, any node can choo= se to delete the data between S1 and S2. This can now be done with confiden= ce 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 (w= ith 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 eve= ntually, once they have the full blockchain.

*** Conclusion ***

This isn't a concrete proposal - it's not even clos= e - but perhaps it might be the start of a fruitful conversation. I have mo= re to say, but this email is long enough already. Email me if you're in= terested in discussing or developing these ideas together. I have a private= Discord server, but I'm open to other suggestions, or just further dis= cussion here.

Laissez fa= ire, 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://= groups.google.com/d/msgid/bitcoindev/CABHzxrgbxG1qy3geyNHshA-q6tv0uNNwx5uis= wUmAGDDxQjoHg%40mail.gmail.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/CAAS2fgRX3PJEy%2B7GRyANDea2ZFfkWRGr%2B4q9YEV90zhtgv2Bag%= 40mail.gmail.com.
--0000000000004c077906440b1b01--