From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 22 Nov 2025 23:13:17 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vN4Hc-0004OQ-0Y for bitcoindev@gnusha.org; Sat, 22 Nov 2025 23:13:17 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3e89d0035c4sf4933696fac.2 for ; Sat, 22 Nov 2025 23:13:15 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1763881989; cv=pass; d=google.com; s=arc-20240605; b=RdmbaVl9bbtr/Q9AaI27Ki6j2TVOI7obU8/YTGppOdj1rw9u37vdAb0+2oSVT7iQLs TJ/kxzh3jbEzPQvrnKAEl19tP2bQ7/lL+Nn/o6XTOUCXEQKD6jXpNMKKWkQcK7J41UYq 3BUlIZnJv8NDn/Rk758PzPcpB/ZCSjJFRCbW0MaaDa8VgU4QoJjRDliPnlTBu6JbaSfW lc7FrYc2l2rUR1VtoYGqJOkHj3K5PQZVG97gMwA61iBAz9vWEFqIhQYCydqRl+V1qoFh hcgsYHpyrbOyyB36ARWwDv0Cglzg11L8OjB7PgGI736d6nZ2aRQgiNGelR0fpNHddhTQ m/sg== 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=e/7v0VaE+c1B+SAz0FXMyAtalkXlBESy8nHQzlfE0Ag=; fh=ryvJOzNoAf97raNarHT3AtlOgFb+Z/L+35TsmBLBnTw=; b=fURuFBi9n1eMtp3BPie9UCMn3uyoTTqj+435bzDqmWiIaAp4kcBoLl+dLdhwr+8BLs E1kbFGo+D73xK8jqQN2cYK5wg7w0EcIgFF39XKjW+RE+zyS4ogCm+04x6rOVb3ZSt/pU yaux9kLRCKsEVK319qBP5By83gSjYjyeT6qZ2bHf/6Csl3P6BeLr+8rueV1HrQ21IAGy LT6/QxliFi74O/hxkKsVhNo+O7zzESawn/oPFttihEAGdQ3flc20h73BpJ6CSkVCBC9o zom6cRQlHudXaRqnxr73TcF5MvqAxOW8GFlco6kEwX0TRUo3C1YBNb2U0VN41a6Qt/Nn JrSQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=emXnauTd; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=saintwenhao@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=1763881989; x=1764486789; 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=e/7v0VaE+c1B+SAz0FXMyAtalkXlBESy8nHQzlfE0Ag=; b=eBnZt3SayPa7DPU+rPYMiY96V9TFfMFTzlUZes6Xij2QgoUrET1GYU4ndhUORomQ1d UI1jW6Qa7RSCSNYQR7+39qXqRRjWV1NeGtU4YagoNnog6hEPuwNIqiY0hF/mAL8lgaCZ xFOealBFoRbNzQPabHNt5k+Kh4X7BIPPwng0K9gMbCqcIDjUBqUWQyl2jvHXegYFgTDP D+3mcGM2VUQQCZFgsYeuubVhhcPggUxQZmysIRmDfabzS2/XFgIMFt6z0QbMuCSiDfkL muesaZTnQWnNLfdAHuryUazb+BuFQMS3C/7aayWUQkfPU8dSnVZOAxL5VQabLBwdsh2K NVOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763881989; x=1764486789; 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=e/7v0VaE+c1B+SAz0FXMyAtalkXlBESy8nHQzlfE0Ag=; b=EerN+pME1O+5ZiaEovpZchDM6m4dLvgjsVNUMfSEMLMr/4o0LXfb3escHxpNvQC4X+ LwN4xZ3PAi4LFVxyKpwp3nTWCp0NXE5IIA1g3zyzLhQDiQfgQbLHotgZ7iYFwRAfAhCT xeRUXJlaHsD1Z0P2NQkrQdg7nqYukK7GYNLfLlMR0xH3kHTPIZNzYBDd1t6y8Idkpiwj pFQ7geX9KqKnMTe0GKdXvczROUiFX/OjKeeNzKbG4iA2unMQEnD+OFGjjscmsQr3KQxv xblsfShVFA/tJZeaE32MSCkAZ/hIIUkO5ZbU5qVmhgQukxSuONpTiY+PPQDO6wlorDC4 p/XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763881989; x=1764486789; 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=e/7v0VaE+c1B+SAz0FXMyAtalkXlBESy8nHQzlfE0Ag=; b=Fwd1m21rT2RBbdgWDUiWgtA6Eo/9FyflBkfDSdborWBzBuRWPjgoxp0+SSvR7KXbrl P99ep5xiId0L5iakCnZpgRF+5si+4GKoKQRGMiWKWfs5Vw9Gnn4hWgPnx+Ch4dqyL8DQ Mu67qahfE+xPjG5Gy93FqeNMyP/rZ0dZ1rSPys12kS5X49OWPSUpQZIgYOHiO7qDJfOG ajlTteLE1mMqPJlcghlSUN8wWUMe1hfUQ7pyGc3nsHOYmppoKSCyWKMnwldN6/dR4ivs Iu44YZdNTYVq4I3YAmMdn5MT0W/kwa/5dtliZYU8C4ExA6XpmLMJ2AZAU/7Msh4f1z0j bwig== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCU8X8qvONvtR5gMuLSFXDL7Mlc8Gmjv0JJtoZv24R+pATNTJ0fJhHnJM4b4PiuwPazGKdmed0L2ckYp@gnusha.org X-Gm-Message-State: AOJu0YzBrgjZta3C+5jsvyLeR0NkUjDuCdOTGnnlLMrK6a+hTKE59uSc lVP3P2FPb9RA74kdNCm/6FATwcTkDaxXZQXHi8e3nayIzoKsB44UC1Ke X-Google-Smtp-Source: AGHT+IHDSVEd/+4+M3cuqQYNdFtE4iZ3DvYDwyhTZaKilwkl2unH5Mx16FQ4e5VL+n7Ok540muGhPQ== X-Received: by 2002:a05:6870:d68f:b0:36e:8381:db00 with SMTP id 586e51a60fabf-3ecbe27ad73mr3468140fac.9.1763881989116; Sat, 22 Nov 2025 23:13:09 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZaCyXwXdFjeTqCu5igXmLZKVZEKEmkkRhV5Ie/LwrJVg==" Received: by 2002:a05:6871:4209:b0:3e8:2785:9a19 with SMTP id 586e51a60fabf-3ec9b37e37als1234761fac.1.-pod-prod-08-us; Sat, 22 Nov 2025 23:13:04 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCX1gI1D+piiQlsJ+buGDkTNwAFZi7T+ks85wCNAlg+yOt0Ysf7QdUXKZ/9gQgSr+SWuY4iTDFzsdmId@googlegroups.com X-Received: by 2002:a05:6808:3208:b0:450:be60:4351 with SMTP id 5614622812f47-4511291f266mr3103904b6e.18.1763881984476; Sat, 22 Nov 2025 23:13:04 -0800 (PST) Received: by 2002:a05:600c:c108:b0:477:b663:eee5 with SMTP id 5b1f17b1804b1-477bfd88015ms5e9; Sat, 22 Nov 2025 22:37:44 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCU/QxMWsqdDvkcq4GJzAUgaWDoeFwRWCTOea2LNs0WGH0IrxzezapeJ6CvAfHoOkCTl6FJRCjGoiUHI@googlegroups.com X-Received: by 2002:a05:600c:3588:b0:477:bcb:24cd with SMTP id 5b1f17b1804b1-477c11179ffmr81115375e9.22.1763879862469; Sat, 22 Nov 2025 22:37:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1763879862; cv=none; d=google.com; s=arc-20240605; b=ca6QkrDI3Qh+LDzrQqbAV7nUPWZERLpnDx2qNPIdX+PzG+d8ALz/X9kBxo6tvEeo3o iWq1j9oE2PKX/FD5O77g3vY9oYEmwDdOkUejWtsk6hjAUAuYjShs+TB/nRU9hKnWE3K3 c00pHYAWhHLWEtrnaQP8GudZpiGtThupkW23sLzwunOs1WdUHCO/KAqylqE7kN10E38u EJonPHUomqsh7ew/gMQeosdJcCBLPjxLpfsAFIQaVNBjy9c+sl5K67GAmeZAw7kBt3Dn 5qyDnTFbCZNPnzRi7q4NWzY6HQpIG5kRHDltJdV7njn735tDIVNPbT6qWpv2E6MhnZAS 6NQA== 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=eiV94xYrUJxWz6Sb8bD75saqkBFUPO0wJHpjP4MUeGg=; fh=UDmIxOWtnPdLALOHvVJJmWmn+JwTmQvRFMWsswwOkCQ=; b=SkHsu7y32BAMhKlcRRN02JcBEdW1BdyZiVrfpwlkkK/1GslRocioxJLINvD4PM0RMh yKU7ltSCQ4qiw+YlgRoDONtL2Tz2srEOsYYFEF5lJeecgBKPt/MMJGVt+2GJaSGFdtDD nV7kTUQGBBEi3TpJnh+dxTrGGUqQrSMAodeum63J007LqH3/o0/WqxUdjT9JA2S8jkbl VJU8ERveijCqP5EYiXdRd7w5f5sdQ1ovwMKueWVhTa9fn+HJcPK9ax8iYxat2ZLJLyGh SD5wPsMoWac7Ddr7iaHzMYmr6T2IJdh0r48kE6SwRJp73EwbieSJEat7tZIcR+x38x15 xhxg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=emXnauTd; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com. [2a00:1450:4864:20::132]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-42cb7f335f4si154998f8f.4.2025.11.22.22.37.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Nov 2025 22:37:42 -0800 (PST) Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) client-ip=2a00:1450:4864:20::132; Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5959d9a8eceso3888948e87.3 for ; Sat, 22 Nov 2025 22:37:42 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVT+F0XEusNkwkHVsejcPp5tlqG1P07wxJKXmJFECbdtWWJKeaHN8GABuc62Q+TQ3nfNGv69CfHAT+3@googlegroups.com X-Gm-Gg: ASbGncvg+HYW0ROnF39ag4f/J8g8c+YUitzsKy+fhc5NSL1Q3f5ge5lEiPoOO+saBKr ynhYhuoGy9LWifLGudJZlitfpd5qgvoQIuU08gkP1C0wcedFUjhxcj2EV4lcC9tDCcCWRMXEqwX eVK2Xc8AajdBjxywp/2NjTC0P0XylX6VufcJE+vUfIA2uEio0oM2vxzLuZw36bhv/5xVQtR0ZuP 7n9OgA0xUbZNDhIIck92BdQrT7lfT6f097QRVD1x1a2cOaVLlNZkBWKhe0I9GU1Jq0+7Rw= X-Received: by 2002:a05:6512:2304:b0:595:8062:135 with SMTP id 2adb3069b0e04-596a3eb322amr2864023e87.20.1763879861364; Sat, 22 Nov 2025 22:37:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Saint Wenhao Date: Sun, 23 Nov 2025 07:37:30 +0100 X-Gm-Features: AWmQ_bnHc79Y8W-umH525uT_3svzGbkgW7HcSUyEPR1FYri_qY6IDN7qGMu-8qo Message-ID: Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain To: Greg Maxwell Cc: Lazy Fair , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000902c8306443d4833" X-Original-Sender: saintwenhao@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=emXnauTd; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=saintwenhao@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 (/) --000000000000902c8306443d4833 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > allowing attackers access to manipulate a hash's midstate is dubious from a security perspective It is unsafe, because the attacker can pick anything as the "middle state", run it through SHA-256, and get a valid result. For example: the hash of the Genesis Block is computed in this way: hash0: 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3ba3edfd 7a7b12b2 7ac72c3e 67768f61 7fc81bc3 888a5132 3a9fb8aa hash1: bc909a33 6358bff0 90ccac7d 1e59caa8 c3c8d8e9 4f0103c8 96b18736 4719f91b 4b1e5e4a 29ab5f49 ffff001d 1dac2b7c 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000280 hash2: af42031e 805ff493 a07341e2 f74ff581 49d22ab9 ba19f613 43e2c86c 71c5d66d hash0: 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19 af42031e 805ff493 a07341e2 f74ff581 49d22ab9 ba19f613 43e2c86c 71c5d66d 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000100 hash4: 6fe28c0a b6f1b372 c1a6a246 ae63f74f 931e8365 e15a089c 68d61900 00000000 And now, let's assume that we want to skip the first 64 bytes. We get "bc90= 9a33 6358bff0 90ccac7d 1e59caa8 c3c8d8e9 4f0103c8 96b18736 4719f91b" from the network, receive "af42031e 805ff493 a07341e2 f74ff581 49d22ab9 ba19f613 43e2c86c 71c5d66d" as a result, so we can think, that our last data chunk is set to "4b1e5e4a 29ab5f49 ffff001d 1dac2b7c". However: fake0: 189dcde9 da998d89 12414f36 fb7a1edd d48a4c3b c0237088 6beec03e 46b7bafb 4b1e5e4a 29ab5f49 ffff001d 1dac2b7c 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000280 fake1: 189dcde9 da998d89 12414f36 fb7a1edd d48a4c3b c0237088 6beec03e 46b7bafb So, the attacker can pick some data, and compute any two hashes, which will go through that initialization vector, and leave it unchanged. And then, instead of shrinking data, they can be expanded into infinite size. Also, computing any difference between hashes is possible as well. For example: if we want to get a hash, which will be incremented by one: fake2: f530fddf 74afe6c6 6004c3c0 c230b193 853774a9 6ab4c304 9d09ddde d9982546 4b1e5e4a 29ab5f49 ffff001d 1dac2b7c 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000280 fake3: f530fddf 74afe6c6 6004c3c0 c230b193 853774a9 6ab4c304 9d09ddde d9982547 Other attacks are possible as well. So, I wouldn't trust middle hashes that much, unless you have a strong cryptographic proof, that they are safe in a given context. sob., 22 lis 2025 o 00:25 Greg Maxwell napisa=C5=82(a)= : > 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 t= he > 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 no= de >> 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 chan= ge >> the data, you change the hash. The design presented here is an attempt t= o >> 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 a= ble >> 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 depicti= on >> of the prophet Muhammad, and another video of the sexual abuse of childr= en. >> The design presented below lets each person decide what to remove for >> themself (if anything), while those who want everything can still have i= t >> 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. T= his >> 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 >> internal state from S(A) to S(B), then you continue hashing from B to th= e >> end of D. >> >> The hash still works as an integrity check for the data before A, and th= e >> data after B: change any of this, and the final hash will change. Now yo= u >> 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 betwe= en >> 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 objectionab= le >> data. But what if instead, we could share S(A) and S(B) across the netwo= rk, >> do it securely, and in a way where up to 100% of nodes could choose to d= rop >> 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 mi= ne >> 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. Aft= er >> that they may also be able to share (with the agreement of the receiving >> node) this modified transaction as part of initial block downloads, alon= g >> with S1 and S2 - to any other nodes that don't want this objectionable >> content. The receiving nodes wouldn't immediately and necessarily be abl= e >> 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 t= his >> email is long enough already. Email me if you're interested in discussin= g >> 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 Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CABHzxrgbxG1qy3geyNHshA-q6t= v0uNNwx5uiswUmAGDDxQjoHg%40mail.gmail.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/CAAS2fgRX3PJEy%2B7GRyANDea2Z= FfkWRGr%2B4q9YEV90zhtgv2Bag%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/= CACgYNO%2B3sWojtgoZLi7j28VDKBSPO3YEWNyxryQvoAKmaPqFBg%40mail.gmail.com. --000000000000902c8306443d4833 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> allowing attackers access to manipulate a hash's = midstate is dubious from a security perspective

It is unsafe, becaus= e the attacker can pick anything as the "middle state", run it th= rough SHA-256, and get a valid result. For example: the hash of the Genesis= Block is computed in this way:

hash0: 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be= 0cd19

01000000 00000000 00000000 00000000
00000000 00000000 00000= 000 00000000
00000000 3ba3edfd 7a7b12b2 7ac72c3e
67768f61 7fc81bc3 88= 8a5132 3a9fb8aa

hash1: bc909a33 6358bff0 90ccac7d 1e59caa8 c3c8d8e9 = 4f0103c8 96b18736 4719f91b

4b1e5e4a 29ab5f49 ffff001d 1dac2b7c
80= 000000 00000000 00000000 00000000
00000000 00000000 00000000 0000000000000000 00000000 00000000 00000280

hash2: af42031e 805ff493 a07341= e2 f74ff581 49d22ab9 ba19f613 43e2c86c 71c5d66d

hash0: 6a09e667 bb67= ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19

af42031e = 805ff493 a07341e2 f74ff581
49d22ab9 ba19f613 43e2c86c 71c5d66d
800000= 00 00000000 00000000 00000000
00000000 00000000 00000000 00000100
hash4: 6fe28c0a b6f1b372 c1a6a246 ae63f74f 931e8365 e15a089c 68d61900 0000= 0000

And now, let's assume that we want to skip the first= 64 bytes. We get "bc909a33 6358= bff0 90ccac7d 1e59caa8 c3c8d8e9 4f0103c8 96b18736 4719f91b" fro= m the network, receive "af42031e= 805ff493 a07341e2 f74ff581 49d22ab9 ba19f613 43e2c86c 71c5d66d"= ; as a result, so we can think, that our last data chunk is set to "4b1e5e4a 29ab5f49 ffff001d 1dac2b7c". However:

fake0: 189= dcde9 da998d89 12414f36 fb7a1edd d48a4c3b c0237088 6beec03e 46b7bafb
4b1e5e4a 29ab5f49 ffff001d 1dac2b7c
80000000 00000000 00000000 00000000=
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000= 280

fake1: 189dcde9 da998d89 12414f36 fb7a1edd d48a4c3b c0237088 6be= ec03e 46b7bafb

So, the attacker can pick some data, and compu= te any two hashes, which will go through that initialization vector, and le= ave it unchanged. And then, instead of shrinking data, they can be expanded= into infinite size.

Also, computing any difference between hashes i= s possible as well. For example: if we want to get a hash, which will be in= cremented by one:

fake2: f530f= ddf 74afe6c6 6004c3c0 c230b193 853774a9 6ab4c304 9d09ddde d9982546

4= b1e5e4a 29ab5f49 ffff001d 1dac2b7c
80000000 00000000 00000000 0000000000000000 00000000 00000000 00000000
00000000 00000000 00000000 0000028= 0

fake3: f530fddf 74afe6c6 6004c3c0 c230b193 853774a9 6ab4c304 9d09d= dde d9982547

Other attacks are possible as well. So, I wouldn= 't trust middle hashes that much, unless you have a strong cryptographi= c proof, that they are safe in a given context.

sob., = 22 lis 2025 o 00:25=C2=A0Greg Maxwell <gmaxwell@gmail.com> napisa=C5=82(a):
If you find blindly = trusting miners acceptable, just run SPV and then you don't store anyth= ing but block headers.

Aside, allowing attackers a= ccess to manipulate a hash's midstate is dubious from a security perspe= ctive-- 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 = <laisse= z.faire.btc@gmail.com> wrote:
I propose two changes to Bitcoin, on= e 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 ag= reeable. In so doing, my hope is that we can satisfy all users, and deal wi= th their greatest concerns.

I = do however acknowledge those people that want to stop miners from mining no= n-monetary transactions, because of the data storage and processing cost, a= nd I recognised that this proposal does nothing to address those concerns.<= /div>

*** Motivation ***
=

You can't just change or = delete some data from the blockchain, because a hash of everything in a blo= ck is included in the next block. If you change the data, you change the ha= sh. 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 - a= nd importantly without even being able to recreate that objectionable conte= nt 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 obj= ect to copyrighted material used without permission, another a negative dep= iction of the prophet Muhammad, and another video of the sexual abuse of ch= ildren. The design presented below lets each person decide what to remove f= or themself (if anything), while those who want everything can still have i= t all.

The design lets a= user remove any data, and deals with the impact on the matching of block h= ashes, data integrity and malleability.=C2=A0

In the case of OP_RETURN data, the result should be n= o 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 ma= intaining data integrity through hashing, while removing some of the hash&#= 39;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 t= he internal state is at point A and then at point B, then you can compute t= he 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 ha= shing 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 i= n between, without breaking the integrity of the blockchain and proof of wo= rk - 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 objectionab= le 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 n= odes could choose to drop the data in between, permanently, without breakin= g anything?

*** Second i= dea ***

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 blo= ckchain, as mined by miners, with the most proof of work, and verified loca= lly. Therefore, the second idea is that S(A) and S(B) are trusted if (and o= nly if) they are written into the blockchain, and verified by the network.<= /div>

For example, we write da= ta 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 s= tate 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 n= ew 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 ***
<= div dir=3D"auto">
This isn't a concrete prop= osal - it's not even close - but perhaps it might be the start of a fru= itful conversation. I have more to say, but this email is long enough alrea= dy. Email me if you're interested in discussing or developing these ide= as together. I have a private Discord server, but I'm open to other sug= gestions, 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit http= s://groups.google.com/d/msgid/bitcoindev/CAAS2fgRX3PJEy%2B7GRyANDea2ZFfkWRG= r%2B4q9YEV90zhtgv2Bag%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/CACgYNO%2B3sWojtgoZLi7j28VDKBSPO3YEWNyxryQvoAKmaPqFBg%40ma= il.gmail.com.
--000000000000902c8306443d4833--