path: root/ab/d6e21b964fa7de8fd50d297e102063613c52de

Delivery-date: Thu, 01 May 2025 11:08:16 -0700
Received: from mail-yb1-f185.google.com ([209.85.219.185])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDK6LL4DT4ARBBHRZ3AAMGQET7SXEHA@googlegroups.com>)
	id 1uAYKU-0007Lf-3U
	for bitcoindev@gnusha.org; Thu, 01 May 2025 11:08:16 -0700
Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e72ced90ffdsf1735206276.0
        for <bitcoindev@gnusha.org>; Thu, 01 May 2025 11:08:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746122888; x=1746727688; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=WXAU+3tLR2rqvIvDGi6ctLUoUpYoxHyz8wU9hoNECfg=;
        b=OBBhrYaoYz5zo0Lk8WEHyy8Hlurc1kFNEOMnXaD8JxKuyWvF8bxaRqtVAn5yhHHvMM
         affuiJ/J202UcKjMpv+ts1FaB67Jryc1wVVFRaaYsbJl6KuLWHx4stfr615t69oKd0eR
         W0aULJtgdEUeW/cXyCfKRIW2EzgNZ8vjJ6OcuMxaHOIhs/AF3Qh5y81XEes+5k7L+67k
         /RZtSqbdnGhM7KUzRRKi9IOOUO8ehQS9TRV/IibrD4+r6Zkov9XQrr6ktDc1Ogczt3D1
         vSPvcfwa5S6NdvWBkr2fImzjhSxWTYezHLrlsPbeaQY9bLa3YYlP10Xx4J+pl/Eh8Z0g
         tmyg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746122888; x=1746727688; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=WXAU+3tLR2rqvIvDGi6ctLUoUpYoxHyz8wU9hoNECfg=;
        b=c9WJTX/FfAKXpDZ/+D2xD4LClw4c2exCBL9EsYAMYzZz3PnAKBHT9HSPCJT/KaTJeJ
         tcgTGs8mNI26Mp52G887IffVZ8lPsgxg9oxD3PE3DSp4n/Q5RdesNfulHPTU7FRyhp7B
         BteXLRnIaDLJd2kLXG5Vju5WyOHJIDZ3dhz1KhzsW1qPNctg3SW81Eh8yhfLx/jPdgoj
         rtllxEb9PA3GoMIDFQvgw+OB5t0Hl1BaBw8XgUrX+y/mgQvXl0ft9kk31Az8HAKTkLCG
         MwmY3SxtRP3TZKeUrkrEhfnYUeTusMax081KIMpCHy+iLGxtsUZlmcBkC+HSHmrhooPO
         ZeUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746122888; x=1746727688;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WXAU+3tLR2rqvIvDGi6ctLUoUpYoxHyz8wU9hoNECfg=;
        b=eeNfB5aWicoMdAnPHL3rrmp/ILjwy/EKpBbVYj7zhaD7MAoIxUASiKTQcJknVidoyj
         2li1rjqe4WHDnFzCn+rcWFt0icaqpiXuA2Z7l4qcUvxOXJdguZneplPxKBuNHM31Kr1v
         FbYxVYzCI++jLHtOpgVcm5DbRzSeUfREz/uy9YpdPzcUW+JM4ewR8QCZQy+o+VvFaJ1c
         I6LHQD1xMRqiA+b2wcvqiObEwmHyRSyabHtlau5MK4XGSSJoq43iO6Xfpw9zdx/QMStJ
         7VdQyVkgRrkynS7VQKyBD1/2+0yMo0veh/eO2iSbr89ZmkvIV0k1Xab2bV7g/FrBvItw
         Yi6A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXMl9LOBnobcsOs8aKyIgPGPEzBlkdXpz4VW5qlmGQbdUyYlorT13zVXnzlAel4YOOFauh3/tP9On6f@gnusha.org
X-Gm-Message-State: AOJu0YxX0Nzfvy+qDC6N40RPTmE3oxtk8CT/lh/ml+WTY2vRT3NE+uf8
	58D6tbdxemMl3oHro5qfCVdQGIry07Yxy5iiJx7ZVWyB0XNu7o4A
X-Google-Smtp-Source: AGHT+IFHD+eT2cOGAiAChrDXePmxZ92NB0CY4PzUycs6+LE/Q+ElKKlfxeD5aqrcUgWJOicyPs21OQ==
X-Received: by 2002:a05:6902:a09:b0:e72:ba52:87f5 with SMTP id 3f1490d57ef6-e756555811emr62269276.15.1746122887957;
        Thu, 01 May 2025 11:08:07 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBGMNJUYaqhkhMLUaf6tiBYc4aEp8XgGhzUhDjj09SMCsA==
Received: by 2002:a25:2941:0:b0:e74:29b5:5ab2 with SMTP id 3f1490d57ef6-e74dc1e6bf2ls614450276.1.-pod-prod-03-us;
 Thu, 01 May 2025 11:08:04 -0700 (PDT)
X-Received: by 2002:a05:690c:4884:b0:6ef:77e3:efe6 with SMTP id 00721157ae682-708ced45653mr4680417b3.13.1746122884335;
        Thu, 01 May 2025 11:08:04 -0700 (PDT)
Received: by 2002:a81:ee08:0:b0:708:1ea1:3cd5 with SMTP id 00721157ae682-708bca3a47ams7b3;
        Thu, 1 May 2025 10:40:17 -0700 (PDT)
X-Received: by 2002:a05:690c:4884:b0:6ef:77e3:efe6 with SMTP id 00721157ae682-708ced45653mr2909447b3.13.1746121216319;
        Thu, 01 May 2025 10:40:16 -0700 (PDT)
Date: Thu, 1 May 2025 10:40:15 -0700 (PDT)
From: Andrew Toth <andrewstoth@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <1e353962-1665-4bc5-8a35-e349fdf4832cn@googlegroups.com>
In-Reply-To: <CAMW46uk0nTh6wyFYshYoYd2YrmpK9gkNvSfDMqO9t32dA9zmmg@mail.gmail.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org>
 <CEB83B34-6C5B-469E-9914-20940F27EEC0@sprovoost.nl>
 <d18b4149-5523-44bd-8332-2b7962f4b674@dashjr.org>
 <QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net>
 <f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com>
 <CALkkCJY5T5sd5Am0M6abhaMMicwVNvSfwYQP1jMjxfVsuT8Jaw@mail.gmail.com>
 <CAMW46uk0nTh6wyFYshYoYd2YrmpK9gkNvSfDMqO9t32dA9zmmg@mail.gmail.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_75092_1221089082.1746121215961"
X-Original-Sender: andrewstoth@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_75092_1221089082.1746121215961
Content-Type: multipart/alternative; 
	boundary="----=_Part_75093_1872975406.1746121215961"

------=_Part_75093_1872975406.1746121215961
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

FWIW I've written a tool to xor your blocks dir without having to resync.=
=20
https://github.com/andrewtoth/blocks-xor/

On Thursday, May 1, 2025 at 5:24:22=E2=80=AFAM UTC-4 Jason Hughes wrote:

> I believe you greatly overestimate the skill and competence of the people=
=20
> who would do this type of thing. You could accomplish what you've laid ou=
t.=20
> I could accomplish it. But the people who will actually do this to Bitcoi=
n=20
> once there's unrestricted OP_RETURN likely can not accomplish it today.=
=20
> What you've laid out is a more technical attack than this variant of atta=
ck=20
> is capable of... and what will actually happen is that once unlimited=20
> OP_RETURN is a thing, people willing to, but not currently able, will tak=
e=20
> the easy route for such attacks after someone with technical knowledge=20
> makes the "Connect your wallet, upload your data" button for them.
>
> All of that said, you make excellent points for ridding Bitcoin of=20
> arbitrary data completely. :)
>
> On Tue, Apr 29, 2025 at 3:20=E2=80=AFPM Martin Habov=C5=A1tiak <martin.h.=
..@gmail.com>=20
> wrote:
>
>> Hi,
>>
>> I have a little demo for you.
>>
>> Firstly, I think the kind of illegal content most people have in mind ar=
e=20
>> images. So let's start with a question: if one takes an illegal picture =
and=20
>> sets every 173th pixel to a red dot will it become legal?
>>
>> If you have trouble imagining it, here's an example for you:=20
>> https://imgur.com/a/J7RTPL7
>>
>> If you believe it would, we can end this conversation and my point is=20
>> moot.
>> However, I think you'll agree the image would still be illegal.
>>
>> Next, I think it's obvious that an attacker seeking to harm bitcoin user=
s=20
>> would choose an any image format he likes. So for this example I'm picki=
ng=20
>> BMP.
>>
>> If you encode the image above to BMP, which is uncompressed, the red=20
>> pixels turn into bytes 253, 7, 2 which happen to encode witness element=
=20
>> length 519. The header size is 54 bytes, so stick the byte 54 at the fro=
nt=20
>> and you have a valid serialization of a sequence of witness elements.
>>
>> Do you see what this means?
>>
>>
>> ...
>>
>>
>> Yes, it's too late to fix this. It's already trivially possible to make=
=20
>> your node store a sequence of bytes that is considered illegal. If you'r=
e=20
>> worried about it you have to resync the chain right now.
>>
>> Disclaimer: the numbers above might be a bit off, I did most computation=
=20
>> in my head. Still, the point stands even if the pixels have a bit differ=
ent=20
>> spacing/color.
>>
>> Same thing with malware distribution, except you can easily skip the=20
>> invalid bytes using jump instructions or other techniques, so that might=
 be=20
>> even worse.
>>
>> Happy syncing!
>>
>> Martin
>>
>>
>> D=C5=88a ut 29. 4. 2025, 11:15 Jason Hughes (wk057) <wizk...@gmail.com>=
=20
>> nap=C3=ADsal(a):
>>
>>> I was asked to take my comments to the mailing list, so here we go.
>>>
>>> First, see my comments on Github PR #32359:
>>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933
>>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919
>>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756
>>>
>>> Next, I'll once again point out relevant history for those just tuning=
=20
>>> in:
>>>
>>> OP_RETURN was only made standard in a limited size to encourage less=20
>>> harmful data carrying in Bitcoin. Attackers were using harmful methods =
of=20
>>> data carrying in unspendable UTXOs, and so a way to inject a small amou=
nt=20
>>> of data was TOLERABLE over this harmful UTXO bloat that.  That mostly=
=20
>>> worked, and such practices were quickly minimized. This remained the ca=
se=20
>>> for about a decade without significant issue. Bitcoin is not file stora=
ge,=20
>>> and this was known to developers at that time.  Sadly, eventually an=20
>>> exploit called 'inscriptions' happened which blew the cap off of the si=
ze=20
>>> limitation of arbitrary data storage... and to make matters worse,=20
>>> developers refused to patch the exploit or otherwise enforce the decade=
 old=20
>>> limit on arbitrary data size. If that wasn't bad enough, exploiters get=
 a=20
>>> 75% discount on transaction fees.
>>>
>>> With that history in mind, removing limits on OP_RETURN standardness=20
>>> size is pointless. Relaxing OP_RETURN size limits without dealing with =
the=20
>>> inscriptions exploit means no one will use this for anything besides=20
>>> attacking the network with the worst possible data. There's little to n=
o=20
>>> incentive to use OP_RETURN for data storage when using the 'inscription=
s'=20
>>> exploit costs 4x less in transactions. What's the point of having a=20
>>> "standard" way to store arbitrary data if the exploit method is 4x chea=
per?=20
>>> And the nonstandard version of the exploit allows 4x the data?
>>>
>>> Further, the inscriptions exploit currently requires chunking the data=
=20
>>> between PUSH opcodes, meaning an on-disk analysis doesn't actually dire=
ctly=20
>>> reveal the underlying data the injector intended.  I can still run=20
>>> something like "photorec" on my system and not have to sift through=20
>>> thousands of 'inscriptions'. Removing the size limit on OP_RETURN break=
s=20
>>> this happenstance obfuscation that has saved us to-date. After this cha=
nge,=20
>>> when data is recovered from a full node system, whatever some anonymous=
=20
>>> person decided to stuff into an OP_RETURN will be serialized in plainte=
xt=20
>>> directly on disk. For the low price of a few sats per byte, an attacker=
 can=20
>>> now directly poison the storage of every full node runner.
>>>
>>> If you can't imagine the harm this will do to the ecosystem, let me=20
>>> paint some pictures for you:
>>>
>>> First, there's the obvious. Everyone running a node will now be=20
>>> guaranteed to "posses and distribute" content that is likely illegal in=
=20
>>> their jurisdiction. Not only are you storing this as a full node runner=
,=20
>>> you're serving it to others. Hooray. /s
>>>
>>> Next, there's less obvious abuses. For example, let's say I want to=20
>>> distribute malware. Well, might as well just store it in an OP_RETURN.=
=20
>>> Then, any time I compromise a system with a Bitcoin node I know my malw=
are=20
>>> is directly on their system in a mostly predetermined spot already and =
I=20
>>> don't even need to retrieve it from elsewhere! And, even better, my mal=
ware=20
>>> can use the Bitcoin P2P network itself to distribute itself. Just find =
a=20
>>> willing full node, grab the block it's in. Thanks for the boost, node=
=20
>>> runners!
>>>
>>> Worse, in order to actually participate in the network, everyone MUST=
=20
>>> download all of this data from others (who must host it for you), proce=
ss=20
>>> it, and generally must host it for others to do the same. The network c=
an't=20
>>> survive with 100% pruned nodes. I think too many users nowadays don't=
=20
>>> understand that running a full node is the ONLY way to actually partici=
pate=20
>>> in Bitcoin.
>>>
>>> It's bad enough that chunked partly-obfuscated things exist on the=20
>>> systems of full node runners today. It'll be even worse if that's=20
>>> unrestricted with the removal of such limits.
>>>
>>> As I said in my Github comment: This is far more than a small technical=
=20
>>> change. This is a fundamental change to the nature of what the Bitcoin=
=20
>>> network itself is in its entirety. Ten years ago, developers of the=20
>>> reference implementation knew this, and acted in the best interest of=
=20
>>> Bitcoin itself. Today, too many developers don't understand this duty.
>>>
>>> That may sound like hyperbole, but it really isn't. If this change is=
=20
>>> merged into Bitcoin Core, and Bitcoin Core then continues to be the=20
>>> reference implementation... Bitcoin as we know it changes forever in th=
e=20
>>> most fundamental way imaginable: The reference implementation explicitl=
y=20
>>> turning the Bitcoin network into an arbitrary data storage system, inst=
ead=20
>>> of evolving it as a decentralized currency.
>>>
>>> That's not Bitcoin anymore, and we might as well give up on Bitcoin eve=
r=20
>>> being a thing if this is the path chosen.  There are very few paths tha=
t=20
>>> lead to a worthless Bitcoin, and this is probably in the top 3 worst=20
>>> options.
>>>
>>> I can't understate this. It's one thing to refuse to act when faced wit=
h=20
>>> an attack/exploit/etc.  That takes actual courage and conviction to do=
=20
>>> what's right for the ecosystem... and I _almost_ can't fault the curren=
t=20
>>> batch of devs for not having that courage.  However, it's another to op=
enly=20
>>> make sweeping changing to the ecosystem in an effort to make such thing=
s=20
>>> acceptable.
>>>
>>> Have the courage to reject this type of thing for the sake of the=20
>>> overall project.
>>>
>>> JH
>>> aka wk057
>>> aka wizkid057
>>> On Saturday, April 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille w=
rote:
>>>
>>>> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <lu...@dashjr.or=
g>=20
>>>> wrote:=20
>>>>
>>>> > That's nonsense. They were and continue to be very effective, even=
=20
>>>> with=20
>>>> > only a small amount of adoption. Further, mining centralization and=
=20
>>>>
>>>> Standardness rules have definitely been effective in the past, if we g=
o=20
>>>> far enough back in time. But back then:=20
>>>>
>>>> * There were far less financial incentives to bypass them. Standardnes=
s=20
>>>> adds inconvenience to people developing infrastructure on top, which c=
an=20
>>>> nudge in another direction. But I don't see how million-dollar (or mor=
e)=20
>>>> business incentives would be thwarted by the need to communicate with=
=20
>>>> miners directly (see below). These incentives will only increase as th=
e=20
>>>> subsidy dwindles.=20
>>>>
>>>> * There was far more reason for rules of this kind; the network was=20
>>>> small and far less valuable, and there were significant concerns about=
=20
>>>> increased node operation cost with a quickly-growing blockchain. With=
=20
>>>> blocks consistently full for most of the time for years now, even at t=
imes=20
>>>> without so-called "spam", that concern just does not exist; nodes will=
 be=20
>>>> processing the same amount of transaction data anyway. I think I share=
=20
>>>> Luke's feelings around non-financially-relevant transactions on-chain,=
 but=20
>>>> given sufficient demand for block space anyway, there just is no need =
to=20
>>>> discriminate.=20
>>>>
>>>> > pools denying miners options has been the biggest barrier to that=20
>>>> > adoption. There is no significant financial impact either, that's=20
>>>> just=20
>>>> > FUD; miners using the fixed and improved spam filters have in fact=
=20
>>>> > earned significantly more than miners using Core.=20
>>>>
>>>> I am doubtful of this claim, and would like to see evidence of it.=20
>>>>
>>>> > It would be a pain, but it is definitely viable. Thankfully, policy=
=20
>>>> > works just fine for spam filtration, and can be adapted much quicker=
.=20
>>>>
>>>> Nobody is required to adopt policy, and I think you're burying your=20
>>>> head in the sand if you believe even in a world with more decentralize=
d=20
>>>> hashpower, miners/hashers would voluntarily choose to disregard=20
>>>> transactions that pay a significant fee, if the potential gains from=
=20
>>>> accepting them exceed the cost of building infrastructure to bypass=20
>>>> whatever policy exists.=20
>>>>
>>>> Bitcoin users do have a means to deny usage of the chain to truly=20
>>>> damaging use: consensus changes. Those are not optional, apply to ever=
yone=20
>>>> equally, do not create incentives for bypass, and - and I believe that=
 is a=20
>>>> good thing - can only be adopted with very wide agreement.=20
>>>>
>>>> > > b) centralisation=20
>>>> >=20
>>>> > No, this is more FUD.=20
>>>>
>>>> The **entire** reason why Bitcoin uses PoW, as opposed to using a=20
>>>> traditional consensus system with a federation of block-builders, is t=
o=20
>>>> avoid censorship. If anyone dislikes the choices current miners make i=
n=20
>>>> what transactions they accept, they can - without asking anyone for=20
>>>> permission - join the set of miners, and earn a proportional piece of =
the=20
>>>> pie. While it is the case that today mining power is quite concentrate=
d in=20
>>>> a number of businesses, the set of such businesses can, and has, chang=
ed=20
>>>> over time. This is a very valuable property.=20
>>>>
>>>> Part of the puzzle to make that permissionlessness of mining work is=
=20
>>>> access to fee-paying transactions from the public. If sufficient econo=
mic=20
>>>> demand exist for transactions that the public network denies, miners a=
nd=20
>>>> creators of such transaction will develop transaction rails that bypas=
s=20
>>>> that network.=20
>>>>
>>>> If it comes to a point where that economic demand is so high that=20
>>>> miners need to rely on private transaction rails to realistically comp=
ete,=20
>>>> I feel we'd be giving up on one of the most valuable properties the ne=
twork=20
>>>> has. I realize this is a slipstreamery-slope argument, but it is alrea=
dy=20
>>>> happening, and once the rails are ubiquitous, it will be very hard to =
go=20
>>>> back to a public network.=20
>>>>
>>>> ---=20
>>>>
>>>> Because of all these reasons, Concept ACK on relaxing the OP_RETURN=20
>>>> limits, including removing them entirely. I have been a strong propone=
nt of=20
>>>> these limits in the past, and I'm not happy with seeing the demand for=
=20
>>>> those transactions. But I also recognize the reality that that demand=
=20
>>>> exists, and the alternative of pushing that demand to bypass the publi=
c=20
>>>> network is far more damaging.=20
>>>>
>>>> I will add that I am not in favor of relaxing many other standardness=
=20
>>>> rules in Bitcoin Core, such as transaction sizes and other resource=20
>>>> limitations. These have significant impact on the public's ability to=
=20
>>>> verify and relay transactions, and reason about incentive compatibilit=
y=20
>>>> while doing so. Significant and sustained economic demand for such=20
>>>> transactions may at some point too mean the policy needs to be revised=
 to=20
>>>> avoid an even worse outcome, but I'm hopeful that is not the case. How=
ever,=20
>>>> these arguments do not apply to OP_RETURN limits, which don't serve an=
=20
>>>> objective harm reduction beyond a subjective "that isn't what you shou=
ld be=20
>>>> using the chain for".=20
>>>>
>>>> --=20
>>>> Pieter=20
>>>>
>>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to bitcoindev+...@googlegroups.com.
>>> To view this discussion visit=20
>>> https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0=
669cc0a7b8n%40googlegroups.com=20
>>> <https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c=
0669cc0a7b8n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>> .
>>>
>>
>
> --=20
> *Jason Hughes*
>
>

--=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/=
1e353962-1665-4bc5-8a35-e349fdf4832cn%40googlegroups.com.

------=_Part_75093_1872975406.1746121215961
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

FWIW I've written a tool to xor your blocks dir without having to resync. h=
ttps://github.com/andrewtoth/blocks-xor/<br /><br /><div class=3D"gmail_quo=
te"><div dir=3D"auto" class=3D"gmail_attr">On Thursday, May 1, 2025 at 5:24=
:22=E2=80=AFAM UTC-4 Jason Hughes wrote:<br/></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204=
, 204); padding-left: 1ex;"><div dir=3D"ltr"><div>I believe you greatly ove=
restimate the skill and competence of the people who would do this type of =
thing. You could accomplish what you&#39;ve laid out. I could accomplish it=
. But the people who will actually do this to Bitcoin once there&#39;s unre=
stricted OP_RETURN likely can not accomplish it today. What you&#39;ve laid=
 out is a more technical attack than this variant of attack is capable of..=
. and what will actually happen is that once unlimited OP_RETURN is a thing=
, people willing to, but not currently able, will take the easy route for s=
uch attacks after someone with technical=C2=A0knowledge makes the=C2=A0&quo=
t;Connect your wallet, upload your data&quot; button for them.</div><div><b=
r></div><div>All of that said, you make excellent=C2=A0points for ridding B=
itcoin of arbitrary data completely. :)</div></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 29, 2025 at 3:20=
=E2=80=AFPM Martin Habov=C5=A1tiak &lt;<a href data-email-masked rel=3D"nof=
ollow">martin.h...@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"auto">Hi,<div dir=3D"auto"><br></di=
v><div dir=3D"auto">I have a little demo for you.<div dir=3D"auto"><br></di=
v><div dir=3D"auto">Firstly, I think the kind of illegal content most peopl=
e have in mind are images. So let&#39;s start with a question: if one takes=
 an illegal picture and sets every 173th pixel to a red dot will it become =
legal?</div><div dir=3D"auto"><br></div><div dir=3D"auto">If you have troub=
le imagining it, here&#39;s an example for you:=C2=A0<a href=3D"https://img=
ur.com/a/J7RTPL7" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://imgur.com/a/J7RTPL7&=
amp;source=3Dgmail&amp;ust=3D1746207379473000&amp;usg=3DAOvVaw3OS4MMhfpczkq=
OmxstLCej">https://imgur.com/a/J7RTPL7</a></div><div dir=3D"auto"><br></div=
><div dir=3D"auto">If you believe it would, we can end this conversation an=
d my point is moot.</div><div dir=3D"auto">However, I think you&#39;ll agre=
e the image would still be illegal.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Next, I think it&#39;s obvious that an attacker seeking to harm=
 bitcoin users would choose an any image format he likes. So for this examp=
le I&#39;m picking BMP.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
If you encode the image above to BMP, which is uncompressed, the red pixels=
 turn into bytes 253, 7, 2 which happen to encode witness element length 51=
9. The header size is 54 bytes, so stick the byte 54 at the front and you h=
ave a valid serialization of a sequence of witness elements.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Do you see what this means?</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">...</=
div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Yes, it&#39;s too late to fix this. It&#39;s already trivially possible =
to make your node store a sequence of bytes that is considered illegal. If =
you&#39;re worried about it you have to resync the chain right now.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Disclaimer: the numbers above m=
ight be a bit off, I did most computation in my head. Still, the point stan=
ds even if the pixels have a bit different spacing/color.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">Same thing with malware distribution, exc=
ept you can easily skip the invalid bytes using jump instructions or other =
techniques, so that might be even worse.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Happy syncing!</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Martin</div><br><br><div class=3D"gmail_quote" dir=3D"auto"><div =
dir=3D"ltr" class=3D"gmail_attr">D=C5=88a ut 29. 4. 2025, 11:15 Jason Hughe=
s (wk057) &lt;<a href data-email-masked rel=3D"nofollow">wizk...@gmail.com<=
/a>&gt; nap=C3=ADsal(a):<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">I was asked to take my comments to the mailing list, so here we =
go.<br><br>First, see my comments on Github PR #32359:<br>-=C2=A0<a href=3D=
"https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933" rel=
=3D"noreferrer nofollow" target=3D"_blank" data-saferedirecturl=3D"https://=
www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/bitcoin/pull/=
32359%23issuecomment-2835467933&amp;source=3Dgmail&amp;ust=3D17462073794740=
00&amp;usg=3DAOvVaw3EPmB-Vna5X5negTwBrPnP">https://github.com/bitcoin/bitco=
in/pull/32359#issuecomment-2835467933</a><br>-=C2=A0<a href=3D"https://gith=
ub.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919" rel=3D"noreferre=
r nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.co=
m/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/bitcoin/pull/32359%23issue=
comment-2835638919&amp;source=3Dgmail&amp;ust=3D1746207379474000&amp;usg=3D=
AOvVaw1fJ6r-h5WQIN16fc_gsTVr">https://github.com/bitcoin/bitcoin/pull/32359=
#issuecomment-2835638919</a><br>-=C2=A0<a href=3D"https://github.com/bitcoi=
n/bitcoin/pull/32359#issuecomment-2834012756" rel=3D"noreferrer nofollow" t=
arget=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den=
&amp;q=3Dhttps://github.com/bitcoin/bitcoin/pull/32359%23issuecomment-28340=
12756&amp;source=3Dgmail&amp;ust=3D1746207379474000&amp;usg=3DAOvVaw20BJdFK=
2SikegDoa3OBS3g">https://github.com/bitcoin/bitcoin/pull/32359#issuecomment=
-2834012756</a><br><br>Next, I&#39;ll once again point out relevant history=
 for those just tuning in:<br><br>OP_RETURN was only made standard in a lim=
ited size to encourage less harmful data carrying in Bitcoin. Attackers wer=
e using harmful methods of data carrying in unspendable UTXOs, and so a way=
 to inject a small amount of data was TOLERABLE over this harmful UTXO bloa=
t that.=C2=A0 That mostly worked, and such practices were quickly minimized=
. This remained the case for about a decade without significant issue. Bitc=
oin is not file storage, and this was known to developers at that time.=C2=
=A0 Sadly, eventually an exploit called &#39;inscriptions&#39; happened whi=
ch blew the cap off of the size limitation of arbitrary data storage... and=
 to make matters worse, developers refused to patch the exploit or otherwis=
e enforce the decade old limit on arbitrary data size. If that wasn&#39;t b=
ad enough, exploiters get a 75% discount on transaction fees.<div><br></div=
><div>With that history in mind, removing limits on=C2=A0OP_RETURN standard=
ness size is pointless. Relaxing OP_RETURN size limits without dealing with=
 the inscriptions exploit means no one will use this for anything besides a=
ttacking the network with the worst possible data. There&#39;s little to no=
 incentive to use OP_RETURN for data storage when using the &#39;inscriptio=
ns&#39; exploit costs 4x less in transactions. What&#39;s the point of havi=
ng a &quot;standard&quot; way to store arbitrary data if the exploit method=
 is 4x cheaper? And the nonstandard version of the exploit allows 4x the da=
ta?<br><br>Further, the inscriptions exploit currently requires chunking th=
e data between PUSH opcodes, meaning an on-disk analysis doesn&#39;t actual=
ly directly reveal the underlying data the injector intended.=C2=A0 I can s=
till run something like &quot;photorec&quot; on my system and not have to s=
ift through thousands of &#39;inscriptions&#39;. Removing the size limit on=
 OP_RETURN breaks this happenstance obfuscation that has saved us to-date. =
After this change, when data is recovered from a full node system, whatever=
 some anonymous person decided to stuff into an OP_RETURN will be serialize=
d in plaintext directly on disk. For the low price of a few sats per byte, =
an attacker can now directly poison the storage of every full node runner.<=
div><br></div><div>If you can&#39;t imagine the harm this will do to the ec=
osystem, let me paint some pictures for you:<br><br>First, there&#39;s the =
obvious. Everyone running a node will now be guaranteed to &quot;posses and=
 distribute&quot; content that is likely illegal in their jurisdiction. Not=
 only are you storing this as a full node runner, you&#39;re serving it to =
others. Hooray. /s</div><div><br></div><div>Next, there&#39;s less obvious =
abuses. For example, let&#39;s say I want to distribute malware. Well, migh=
t as well just store it in an OP_RETURN. Then, any time I compromise a syst=
em with a Bitcoin node I know my malware is directly on their system in a m=
ostly predetermined spot already and I don&#39;t even need to retrieve it f=
rom elsewhere! And, even better, my malware can use the Bitcoin P2P network=
 itself to distribute itself. Just find a willing full node, grab the block=
 it&#39;s in. Thanks for the boost, node runners!<br><br>Worse, in order to=
 actually participate in the network, everyone MUST download all of this da=
ta from others (who must host it for you), process it, and generally must h=
ost it for others to do the same. The network can&#39;t survive with 100% p=
runed nodes. I think too many users nowadays don&#39;t understand that runn=
ing a full node is the ONLY way to actually participate in Bitcoin.</div><d=
iv><br></div><div>It&#39;s bad enough that chunked partly-obfuscated things=
 exist on the systems of full node runners today. It&#39;ll be even worse i=
f that&#39;s unrestricted with the removal of such limits.</div><div><br></=
div>As I said in my Github comment:=C2=A0This is far more than a small tech=
nical change.=C2=A0This is a fundamental change to the nature of what the B=
itcoin network itself is in its entirety. Ten years ago, developers of the =
reference implementation knew this, and acted in the best interest of Bitco=
in itself. Today, too many developers don&#39;t understand this duty.<br><b=
r>That may sound like hyperbole, but it really isn&#39;t. If this change is=
 merged into Bitcoin Core, and Bitcoin Core then continues to be the refere=
nce implementation... Bitcoin as we know it changes forever in the most fun=
damental way imaginable: The reference implementation explicitly turning th=
e Bitcoin network into an arbitrary data storage system, instead of evolvin=
g it as a decentralized currency.<br><br>That&#39;s not Bitcoin anymore, an=
d we might as well give up on Bitcoin ever being a thing if this is the pat=
h chosen.=C2=A0

There are very few paths that lead to a worthless Bitcoin, and this is prob=
ably in the top 3 worst options.<br><br>I can&#39;t understate this. It&#39=
;s one thing to refuse to act when faced with an attack/exploit/etc.=C2=A0 =
That takes actual courage and conviction to do what&#39;s right for the eco=
system... and I _almost_ can&#39;t fault the current batch of devs for not =
having that courage.=C2=A0 However, it&#39;s another to openly make sweepin=
g changing to the ecosystem in an effort to make such things acceptable.<br=
><br>Have the courage to reject this type of thing for the sake of the over=
all project.</div><div><br></div><div>JH<br>aka wk057<br>aka wizkid057</div=
><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Satur=
day, April 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Saturday, April 26t=
h, 2025 at 7:45 AM, Luke Dashjr &lt;<a rel=3D"nofollow noreferrer">lu...@da=
shjr.org</a>&gt; wrote:
<br>
<br>&gt; That&#39;s nonsense. They were and continue to be very effective, =
even with
<br>&gt; only a small amount of adoption. Further, mining centralization an=
d
<br>
<br>Standardness rules have definitely been effective in the past, if we go=
 far enough back in time. But back then:
<br>
<br>* There were far less financial incentives to bypass them. Standardness=
 adds inconvenience to people developing infrastructure on top, which can n=
udge in another direction. But I don&#39;t see how million-dollar (or more)=
 business incentives would be thwarted by the need to communicate with mine=
rs directly (see below). These incentives will only increase as the subsidy=
 dwindles.
<br>
<br>* There was far more reason for rules of this kind; the network was sma=
ll and far less valuable, and there were significant concerns about increas=
ed node operation cost with a quickly-growing blockchain. With blocks consi=
stently full for most of the time for years now, even at times without so-c=
alled &quot;spam&quot;, that concern just does not exist; nodes will be pro=
cessing the same amount of transaction data anyway. I think I share Luke&#3=
9;s feelings around non-financially-relevant transactions on-chain, but giv=
en sufficient demand for block space anyway, there just is no need to discr=
iminate.
<br>
<br>&gt; pools denying miners options has been the biggest barrier to that
<br>&gt; adoption. There is no significant financial impact either, that&#3=
9;s just
<br>&gt; FUD; miners using the fixed and improved spam filters have in fact
<br>&gt; earned significantly more than miners using Core.
<br>
<br>I am doubtful of this claim, and would like to see evidence of it.
<br>
<br>&gt; It would be a pain, but it is definitely viable. Thankfully, polic=
y
<br>&gt; works just fine for spam filtration, and can be adapted much quick=
er.
<br>
<br>Nobody is required to adopt policy, and I think you&#39;re burying your=
 head in the sand if you believe even in a world with more decentralized ha=
shpower, miners/hashers would voluntarily choose to disregard transactions =
that pay a significant fee, if the potential gains from accepting them exce=
ed the cost of building infrastructure to bypass whatever policy exists.
<br>
<br>Bitcoin users do have a means to deny usage of the chain to truly damag=
ing use: consensus changes. Those are not optional, apply to everyone equal=
ly, do not create incentives for bypass, and - and I believe that is a good=
 thing - can only be adopted with very wide agreement.
<br>
<br>&gt; &gt; b) centralisation
<br>&gt;=20
<br>&gt; No, this is more FUD.
<br>
<br>The **entire** reason why Bitcoin uses PoW, as opposed to using a tradi=
tional consensus system with a federation of block-builders, is to avoid ce=
nsorship. If anyone dislikes the choices current miners make in what transa=
ctions they accept, they can - without asking anyone for permission - join =
the set of miners, and earn a proportional piece of the pie. While it is th=
e case that today mining power is quite concentrated in a number of busines=
ses, the set of such businesses can, and has, changed over time. This is a =
very valuable property.
<br>
<br>Part of the puzzle to make that permissionlessness of mining work is ac=
cess to fee-paying transactions from the public. If sufficient economic dem=
and exist for transactions that the public network denies, miners and creat=
ors of such transaction will develop transaction rails that bypass that net=
work.
<br>
<br>If it comes to a point where that economic demand is so high that miner=
s need to rely on private transaction rails to realistically compete, I fee=
l we&#39;d be giving up on one of the most valuable properties the network =
has. I realize this is a slipstreamery-slope argument, but it is already ha=
ppening, and once the rails are ubiquitous, it will be very hard to go back=
 to a public network.
<br>
<br>---
<br>
<br>Because of all these reasons, Concept ACK on relaxing the OP_RETURN lim=
its, including removing them entirely. I have been a strong proponent of th=
ese limits in the past, and I&#39;m not happy with seeing the demand for th=
ose transactions. But I also recognize the reality that that demand exists,=
 and the alternative of pushing that demand to bypass the public network is=
 far more damaging.
<br>
<br>I will add that I am not in favor of relaxing many other standardness r=
ules in Bitcoin Core, such as transaction sizes and other resource limitati=
ons. These have significant impact on the public&#39;s ability to verify an=
d relay transactions, and reason about incentive compatibility while doing =
so. Significant and sustained economic demand for such transactions may at =
some point too mean the policy needs to be revised to avoid an even worse o=
utcome, but I&#39;m hopeful that is not the case. However, these arguments =
do not apply to OP_RETURN limits, which don&#39;t serve an objective harm r=
eduction beyond a subjective &quot;that isn&#39;t what you should be using =
the chain for&quot;.
<br>
<br>--=20
<br>Pieter
<br>
<br></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href rel=3D"noreferrer nofollow" data-email-masked>bitcoindev+..=
.@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer nofollow" target=3D"=
_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3D=
https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669c=
c0a7b8n%2540googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&amp;s=
ource=3Dgmail&amp;ust=3D1746207379474000&amp;usg=3DAOvVaw13qVymD6uylX2fQgeD=
t9-X">https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-=
c0669cc0a7b8n%40googlegroups.com</a>.<br>
</blockquote></div></div></div>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><i>Jason Hughes</i><div><i><br></i></div></div><=
/div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/1e353962-1665-4bc5-8a35-e349fdf4832cn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/1e353962-1665-4bc5-8a35-e349fdf4832cn%40googlegroups.com</a>.<br />

------=_Part_75093_1872975406.1746121215961--

------=_Part_75092_1221089082.1746121215961--