From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 21 Nov 2025 15:25:55 -0800 Received: from mail-qt1-f183.google.com ([209.85.160.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vMaVm-0000xi-Li for bitcoindev@gnusha.org; Fri, 21 Nov 2025 15:25:55 -0800 Received: by mail-qt1-f183.google.com with SMTP id d75a77b69052e-4ed69f9ce96sf104949061cf.3 for ; Fri, 21 Nov 2025 15:25:54 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1763767548; cv=pass; d=google.com; s=arc-20240605; b=K4boEFhvjARubf7Pau0DsDc9dp7qIbf3h/vDS3fnn3KQr5kErWy+rDg6PcEKLIm6kS YVU+f939MoL2gC33rqSYza3Ya1eHsAkx7ofDhRJc+84fpWImLjZ/WT1i0nJRAWgYjnXa jqjQ0lmvA6rigxGwrrLgHRVdIfZrlFmpvoXLtvfb8Gdob/e/YTc5mF93EdrlOgNB2Vg7 xok/vad9FhTFYzjjKkhgjQsQcs3oEUduy9uBrZE/IpwmkPFDWYSJmjPl5sZ17+8/azqO pFheXHNHNVvl6HNNUnJ6rq3d+SEJ+wEqM+8k4QVyO81UKchvBvxktYs0QPY9ZFRWP5vK L4cg== 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=2TmbfBUHtpAzeovGKTLwCyQppDusC0/ADJD9i67h7Hc=; fh=e/NTyE/y5smOpvoTDaYRzYgZBpOdd2FCtPoh+WH2axk=; b=HOz/5u+NYbtSQwbY+qAcxVp68Od4DKfSAuIeLx3+RAx1phLBlSKbQku0bJxytWdfe+ ePjFB73Ssv94TzrvpERzfoRI21OcXMWbPUfOzPUc2waSSe5bOu/PRhhqsZBBvuyzYoUv X+WXqkajVxZEC/EpTD2OlRwH9WwyCtWbtmIeZLoSz2N+3gzI+N96cVFrG0cCGUhO+Ioy 0bDjwsLuRj1N6LC20PcSKSfP4+EmG3oscpHyZ41YjjmhptiSgnFPmB1kviKmF4fC7hIZ WrSkDPwAVgWXXbesgvnI+TBXrbiMyxEoUi3FZoiuLWzrZqixvvKIQfKfgGSrs4K7lq2e 3k9w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="T2q0cb/j"; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=eth3rs@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=1763767548; x=1764372348; 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=2TmbfBUHtpAzeovGKTLwCyQppDusC0/ADJD9i67h7Hc=; b=HT62MUBf5p9ceiMIIZFQkWjBNcuWJjDUyxI9bprwNdS975LC7RX+vlmCBpNy3YgWmD qgFrM3TzqBXXMv6OIEiaBiYCckglpcl5mB4gz6gSTgvVreFs3dZVLhqGW10qEnguGj77 eyKh8nbwATl7rRlmEB57wtpMw9BkE+8/k+n2aXWh9VpL4oO//ds+Sq9pHAqnPVWZlrct pkdMqjQrPB+hLFBYLm8haN2UORSiWrxorobFHU2LLlUYfcHMkDHZK94AdjBJ2DchVyEn dqtnwskwoJs6SGd3JpY0/U+3+CT9bp8HXDECLM9tKF6drbZPke0Wk+gx6ABTdw1ubD7j Uf1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763767548; x=1764372348; 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=2TmbfBUHtpAzeovGKTLwCyQppDusC0/ADJD9i67h7Hc=; b=c4mfi2Y3bxoDv1fexDhgvQgGCix1wlpxXNbzovzCCNJ4nsyDu0yQWM6iEADwUL1pu7 1L4QIPtJAeggrcvtu+PvTsGtstozucNzXIbWth7QaabZgA/vC+oM9Zy9YwHVYWz+Ztve TymwtyorNMG32ro9MhU9O4kh5Tb2xaKIlxiCPNXKVMRGy9bln8I6wYI1uHHKEhbyvoE+ o+lCSTuTOkxyGhS254sRqRXI+Dk70fNHWOiphLLAFY/c+5rgDKGVoxsczx1+KFBahDPV yP2JHhtnQg56uNRJCcaJLz46bVi/rLC7Hz6NemTyPh3zsvt5LOEFTn1d2VEcBEXnvsJ3 KIrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763767548; x=1764372348; 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=2TmbfBUHtpAzeovGKTLwCyQppDusC0/ADJD9i67h7Hc=; b=mDeXbx0cx8ptBl204FrvkMbLJ65rmn0ZCh0BHR/3RTblKB9eWsM+ne+k2OlwlPcqds C5asmS84GqqqFfCbEsO82prQ8PITdR2tqq6IXicCMiVpDIQMoPmpG9I/ebR+bs6EOdMf uFhzN5qFZ/xaljoQ+t26TWvt81wBML1bdk/hGGymFz1apQoqL+weKqSl0ijmMn16KmaR /Q49EEJKs3qP7B52shX0Q0UjnKV5GokRJwNG2fS1VqiZTRpcJhFCwiIoBf/PsrH+W0cJ 2EQDDSi5SJCtK2SoFqNPCWBSfTautIH48an1IcvfRfcUgK8ZpILuIFKiiGs/xQ5GvS/B qGew== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXjplTfYP3A+IERK37KSDYeFhHS3eue4I/27H38AQ76Ow0Un7+U+OWDkpv+eewKmyuebsvU88CF3k8u@gnusha.org X-Gm-Message-State: AOJu0YwbYpkjpp0xiTMpcBruKROZVTK1sF0D8syQzYGOzkA0BzuUtZkZ S7Se4vknJl7Fmg5KYpIuwhC/5hl2IY0LfpG/h1PXThVOg62QmW4+dwH6 X-Google-Smtp-Source: AGHT+IHxCjZVvp0Zj7wwXVoPsDGaBoLlM10y4FIcpRsd0X/wHOLVYJkeRg9n0XBXmlU+wqd4PsN1iQ== X-Received: by 2002:a05:622a:14a:b0:4ee:1f24:8c5b with SMTP id d75a77b69052e-4ee58a449f3mr65087271cf.7.1763767548121; Fri, 21 Nov 2025 15:25:48 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Ys3jLEi5+tlGugkugmzz+QkbuvfRQ9pK0EyDxU4bhMZg==" Received: by 2002:a05:622a:3cd:b0:4ee:419f:87ab with SMTP id d75a77b69052e-4ee490beb05ls53982691cf.0.-pod-prod-04-us; Fri, 21 Nov 2025 15:25:43 -0800 (PST) X-Received: by 2002:a05:620a:4613:b0:809:eb12:1ea0 with SMTP id af79cd13be357-8b33d4c71f8mr491340985a.81.1763767543369; Fri, 21 Nov 2025 15:25:43 -0800 (PST) Received: by 2002:ab3:5392:0:b0:2d1:a641:6210 with SMTP id a1c4a302cd1d6-2d332fbdb8cmsc7a; Thu, 20 Nov 2025 13:22:13 -0800 (PST) X-Received: by 2002:a2e:8501:0:b0:37b:a664:acea with SMTP id 38308e7fff4ca-37cc6781822mr10145321fa.12.1763673731245; Thu, 20 Nov 2025 13:22:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1763673731; cv=none; d=google.com; s=arc-20240605; b=WyeBf4bJNdNXh1YJeV0V++z5OzVBtFcIRyZ4Bu/l1m3WOf2M7lDSlLqk+xpdUjWVBo /zUnkdXCV9vzn562kD3LOSd4urNahA13K5x2KZIm3Xhi9Lkor9650jWU9WyipqU+RPF/ w+qSyu9h0auFCtJvp6TCELnB9yu+l7PyMz4ttr/754HRcwcCFKiRbIUuC6fY5wimWGzY x5IIUhQGdbSh/rbWhr4bNhKEH9E6Eg7ggdsIvZiZoTiPReto6/4PPXqNvwQmoAT4UMnM 6PXzwGQToFBPPaLFJr8t7tOs5qlmGh2IgZ0DahIyQYoNBsJCRRuPTUYljwZzLhAeTVYV 94vA== 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=/imlhBxfESvC8tZEesXXIon6DL+/FQLd4DwwF0/Oyb0=; fh=ZtG2GhoDHs4MJE3Iuj+UuXzZ+bE3vAzQsV4cmQkD9a0=; b=M49MsIYhTwxTlhq4UYZvfDAtGFzebVWtRkIvPCTRH0aCgtSwJn203rzobEnx7urqVe 9jIcBslq+v1FTRhDpFVmQqNteTDgVAWkutGSdua7UnSG5XbRNby395Dh2u6pgRbS9CTI mwjJElAfnFlj09fuBCjVXXMvd3nsDRqOZLLY4MR/7qmwBZUMFfGRVw1O/czJu3Gcd9Mi agQnyt2/YEVqzTczlsLxz8FylI6k9BHCtg4gewXzaqDcrvAQjkxGzvKLs5WbJPHacYMN ACTykDO7e977wAqtD24Ln4E0f3aA7oNLREHiP1jRYfZnAqXKhePPBv6bWeIghB0fzyEM Z70Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="T2q0cb/j"; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com. [2a00:1450:4864:20::52a]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-37cc6bb362csi547111fa.10.2025.11.20.13.22.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Nov 2025 13:22:11 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) client-ip=2a00:1450:4864:20::52a; Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-64312565c10so1878281a12.2 for ; Thu, 20 Nov 2025 13:22:11 -0800 (PST) X-Gm-Gg: ASbGnct3SNk11UkthuPTyNXo2cgbjg0tgumTRnE8yOsYH5q23Wq4Fvdx6mexpFsx2VD 8UAqG8apzVA9Y9EEG2qLkFqaEFSc1e9u+qHT5GyHvua4nqFM9ylxu/k4jkCTSsNT7c/ZfUxN0AB aYQA4LjMnfdB660VopkGk1zS5IWepNl9PDfpucnmxW8RUt74zX6nevmL1U88o0nJHBtDzPmRgI0 ga1uPSSOO+cKYqx0KtsOeO9NfPiDKvS2lqdK5MnGXsVNynxym0QIsFIPxpyK0IH17C39lRVEo2J e7co0/l/PeZlmA2QXa3+1lWhUb6Z0syw0dfXq+ca2HR5gej6hfayWLQU5oGMVNHRnt/LlejYg5L ndxCHfLm19aZxjBFONQbxCGhVtA== X-Received: by 2002:a17:907:7eaa:b0:b73:9fea:330a with SMTP id a640c23a62f3a-b7654dd6190mr529361166b.17.1763673730310; Thu, 20 Nov 2025 13:22:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ethan Heilman Date: Thu, 20 Nov 2025 16:21:33 -0500 X-Gm-Features: AWmQ_bkFZtY-wYkCa_BYQoQgYrc-7vVDpVPt2Bz3eHwHHut64Gij7-yyqfiWzMg 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="00000000000031e74e06440d4a40" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="T2q0cb/j"; spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=eth3rs@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 (/) --00000000000031e74e06440d4a40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not convinced your hash function approach fully does what you want it to, although it does seem doable with some additional constraints. There is a solution that does everything you want it and more, ZKPs. ZKP (Zero Knowledge Proofs) can prove that some data X hashes to some hash output Y while keeping the actual value X secret. Thus, everyone can be convinced that H(X) =3D Y even if X is deleted and no one knows what the value X was. Even more exciting, ZKPs can prove the correctness and validity of the entire Bitcoin blockchain. Thus storing old transactions is no longer needed to convince others that the chain is correct. This would remove any harmful data. Zerosync in 2017 compressed Bitcoin's blockchain into a 800 KB proof [0] which is constant size regardless of the number of transactions or bytes compressed. This approach does not require any changes to Bitcoin and you could implement a Bitcoin full node today that supports this. We have a solution to solve the problem of harmful data on the blockchain since 2017. It just requires time, money and motivated people to work on it= . [0]: Robin Linus and Lukas George, ZeroSync: Introducing Validity Proofs to Bitcoin, 2017, https://zerosync.com/zerosync.pdf On Thu, Nov 20, 2025 at 4: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/= CAEM%3Dy%2BXFMXHf7SrCy2NfA4U%2By-fsjL_b2Xb%2B1Fc8Y0wCmYr3NA%40mail.gmail.co= m. --00000000000031e74e06440d4a40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not convinced your hash function approach fully do= es what you want it to, although it does seem doable with some additional c= onstraints.

There=C2=A0is a solution that does everything you want i= t and more, ZKPs.

ZKP (Zero Knowledge Proofs) can prove that some da= ta X hashes to some hash output Y while keeping the actual value X secret. = Thus, everyone can be convinced that=C2=A0H(X) =3D Y even if X is deleted a= nd no one knows what the value X was.

Even more exciting, ZKPs can p= rove the correctness and validity of the entire Bitcoin blockchain. Thus st= oring old=C2=A0transactions is no=C2=A0longer=C2=A0needed to=C2=A0convince = others that the chain is correct. This would remove any harmful data. Zeros= ync in 2017 compressed Bitcoin's blockchain into a 800 KB proof [0] whi= ch is constant size regardless of the number of transactions or bytes compr= essed. This approach does not require any changes to Bitcoin and you could = implement a Bitcoin full node=C2=A0today that supports this.

We have= a solution to solve the problem of harmful data on the blockchain since 20= 17. It just requires time, money and motivated people to work on it.
[0]:=C2=A0 Robin Linus and Lukas George,=C2=A0 ZeroSync: Introducing Validity Proofs t= o Bitcoin, 2017,=C2=A0https:/= /zerosync.com/zerosync.pdf

On Thu, Nov 20, 202= 5 at 4:49=E2=80=AFAM Lazy Fair <laissez.faire.btc@gmail.com> wrote:
I propose two changes t= o Bitcoin, one at the consensus level, and one at the client level. The pur= pose of this is to support filtering of objectionable content after the con= tent 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 f= rom mining non-monetary transactions, because of the data storage and proce= ssing cost, and I recognised that this proposal does nothing to address tho= se concerns.

*** Motivat= ion ***

You can't ju= st change or delete some data from the blockchain, because a hash of everyt= hing 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 compr= omise, where a person can have all of the benefits of running a full node, = including the integrity of the ledger, yet without storing the objectionabl= e content - and importantly without even being able to recreate that object= ionable content from what data they still have.

=
*** Preliminary ***

Objectionable content is defined here as whatever you w= ant it to be, and two users don't have to share the same views. One per= son might object to copyrighted material used without permission, another a= negative depiction of the prophet Muhammad, and another video of the sexua= l abuse of children. The design presented below lets each person decide wha= t 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 matchi= ng of block hashes, data integrity and malleability.=C2=A0

In the case of OP_RETURN data, the resul= t should be no functional effect at all. Whether that's also possible f= or other data elements will depend on the semantics of that data.

*** Solution ***

This solution is based on two ideas, bot= h 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&= #39;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 yo= u 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 on= ce 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 intern= al 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 a= ny of this, and the final hash will change. Now you can safely change or de= lete 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 som= eone 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 ***

I= t 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, an= d verified locally. Therefore, the second idea is that S(A) and S(B) are tr= usted if (and only if) they are written into the blockchain, and verified b= y the network.

For examp= le, 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 S= 1 and S2. This can now be done with confidence because they can double chec= k 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 receiv= ing node) this modified transaction as part of initial block downloads, alo= ng with S1 and S2 - to any other nodes that don't want this objectionab= le content. The receiving nodes wouldn't immediately and necessarily be= able to trust S1 and S2, but they would eventually, once they have the ful= l blockchain.

*** Conclu= sion ***

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 lo= ng enough already. Email me if you're interested in discussing or devel= oping these ideas together. I have a private Discord server, but I'm op= en 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 &= 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/CAEM%3Dy%2BXFMXHf7SrCy2NfA4U%2By-fsjL_b2Xb%2B1Fc8Y0w= CmYr3NA%40mail.gmail.com.
--00000000000031e74e06440d4a40--