path: root/8a/61989f693081d0abe0c9b921dd058231c43974

Delivery-date: Thu, 01 May 2025 02:24:31 -0700
Received: from mail-oa1-f63.google.com ([209.85.160.63])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD2MXBGMTMEBBQ73ZTAAMGQEIHEZ56A@googlegroups.com>)
	id 1uAQ9c-0003z1-UM
	for bitcoindev@gnusha.org; Thu, 01 May 2025 02:24:31 -0700
Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-2c2b6cc2f94sf701882fac.1
        for <bitcoindev@gnusha.org>; Thu, 01 May 2025 02:24:29 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746091463; cv=pass;
        d=google.com; s=arc-20240605;
        b=kjV8fLGNm6PSAnUqoFVViRaEMQZI0rRK3mCuhYe1+/IYpOQskg8zRmfUYt7ZJI60DT
         7rCiUuytxrgelz6lcX48s4zzZSHkIT+vS7Iy80l0koDgvv9qsKlMV9mKtKreAisDOhqN
         E+nk/1Z+hLkHYJKwpSUon2kdqSpkvTtOLNlCIvCvPG4jV7meDh7BHKPjWHXb1DSSL2gh
         dzgJIZSrKXBHxJ3nU2v58hizb7NyUCIujgIOOfUKHoE1ZwX+zJ4KhDVoZuZzIoateRM5
         OPAhzwIjkc/eAn+Lk+H24pjlb1EFnYQTQW4OMFjLUXaZL8aWA8goZkdzrNfHiRzT6/YI
         N0nQ==
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=iRgmiDsg46PMHO7+tFzJOSwFuPlRuXavcQOscxxotbA=;
        fh=3Vy3ncTLz80j+01isYCLiwt0hUKJVXd+HpeY6pfRt9A=;
        b=Y/ilArUSMOlHrdeaHxUbPtngozf0JnCFt2NaIZLe4qs2O8MxUPyjCVhyDY5wki2Fpe
         gzVvab0s76arnCuJSSNWgPNn3CFcNfMGmdjRfkPJfbvtoa7icUvqM4u0t/agWI/gfohy
         9IU4gOQMQry2nrRttYMn7jPrxlm2FsaB7/buLQW4E5GEom/XvjqBeyHcXd4j53aXfEhs
         fW5xkMj2nHUlJ9+mHt2C9EE0gY/Y8+VGkvhslFJ/mF33EvtE/OaREJ0K6qcWnsAuGWAL
         ChVkfJ4kgVeiNbdX9Fe2tq2bGq/czUp9Q87j8efh6F9tVoMOuFuehm8em0us76el3b6A
         868A==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Yuawp9CQ;
       spf=pass (google.com: domain of wizkid057@gmail.com designates 2607:f8b0:4864:20::233 as permitted sender) smtp.mailfrom=wizkid057@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=1746091463; x=1746696263; 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=iRgmiDsg46PMHO7+tFzJOSwFuPlRuXavcQOscxxotbA=;
        b=drJYCOQzLCjcu/sV0fx7DGkrsBS5Z+tjMiBpKcWAGeUAYmKlQ/qcmkT3QyfCaz5g3y
         JICk1iGX7zuOqF2N0IbrZ24CybMeiBar6uORc05CSo+H/nDD/Yz/BuawyQ9Y+Bca1yMw
         X6g734B/PGfPKOi12XOhWKmO0kesM+NAOqFKPvM/RtHd2scZQc60klOarpoLiddlzRX1
         t8Jn8WehezymMNqTBy7dc1ZhuAWqHPZklNM4nsgtVPR7ZuOYpnoZYYtToGvGAhpBk2o4
         luHMOM/w3DXy0nKAvHPyiEpzjpx3aFZVigqBAZKePYOeFLJG1t+djNO+ljr/qFa2d6Cx
         FBhQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746091463; x=1746696263; 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=iRgmiDsg46PMHO7+tFzJOSwFuPlRuXavcQOscxxotbA=;
        b=hK/BjokdELSkHFbG4WmJ/ZIB2/qxx0+Ox285ABdoAmdxO3DJZt3nNljgwQHu1sBm92
         Pbj1MLdibqt6QknxsfzYBi0uBDzWx70Ua7sj0S31NRx+ywvqx39Vlco1lukFLYfuJyF5
         xxeAjPKL5A1HsgpCso0pKPN56pbJ6CPSVpQ5Z3IsdnuopDqJu2+bFeUnLS5rf55MENB5
         IbdNer4plcJzUIWEI+JnHslsFEWP0L/4p3S8Nh7Z7bIjE0EwoLyOHkmqRpHiZk5iMVkS
         4TqxR66OkgVa5EDOaTcIY4AUnaUh4fxhHj1VmKP+UiJoNZes4TPlAWy6jXRPJmWTFzfN
         5O3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746091463; x=1746696263;
        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-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=iRgmiDsg46PMHO7+tFzJOSwFuPlRuXavcQOscxxotbA=;
        b=mHyW9CPiAQJZ24hUHeKIPtBoFreg06ysG4cxPCeaEc/G/tg0BLVwN/y9JaJ3C40g/p
         PIkDFCwYg+hG5cXM/cdpGyMm5Ifi6rcx9R6wYoVyI25j/Lu4GooGs5QTS3dbKK+QUmEG
         ozG/zFLP+AfLQx2lI9wG0NjC1KsI5rA8Om3dUAx/Ku57QGbSo65ZxC969Od6sznM1WpS
         Bl21QrQRkyYOxxkcj02ZGElkCAQqmi0niQdDQlzdhMblCuxHo4zWfTlaC23ZbBudGq3A
         VSL17z4W6c33GZPY38WF/XlRctEyWNOZ8vS/9hVMk4ZxlIPLaGgbNpdF/5TPLYOxgBXR
         5ieA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVA6KjdHooNYmmM8MjllIyYQXZNF3EpuWzFonr8/0DUWi8NpXgVoJy9roAxMKhyGCnuMlUgmHFDw41t@gnusha.org
X-Gm-Message-State: AOJu0Yzy1RVyj3fjjPCXeEa6iXfCOIIJ19u214QNxTW5sQQkWgYXV72j
	kdAjtn41/Qj6AxpCM4NwCITiu5fWtN1JQ/jp4uJeEcVA7CPlRt7P
X-Google-Smtp-Source: AGHT+IHMOqIT5vmcveY3dJqfhA6JxdedO90UXhUDJsNv7CAGZzSHFILi+b+LoARv8XKDtWJdLGV47A==
X-Received: by 2002:a05:6871:6a5:b0:2c1:e9a3:3ab3 with SMTP id 586e51a60fabf-2da8c832364mr1147870fac.33.1746091462740;
        Thu, 01 May 2025 02:24:22 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBGdA9pDv/oMVE2aoTsIWSvgvlzAg4Hqm635uMCCqOhZ4A==
Received: by 2002:a05:6871:a48c:b0:29e:3d45:93e6 with SMTP id
 586e51a60fabf-2da8a517657ls493828fac.1.-pod-prod-03-us; Thu, 01 May 2025
 02:24:19 -0700 (PDT)
X-Received: by 2002:a05:6808:1913:b0:3fb:174f:821d with SMTP id 5614622812f47-403344a9aa1mr1241877b6e.35.1746091459168;
        Thu, 01 May 2025 02:24:19 -0700 (PDT)
Received: by 2002:a05:6808:158c:b0:3fa:da36:efcd with SMTP id 5614622812f47-40220c785bamsb6e;
        Tue, 29 Apr 2025 17:10:42 -0700 (PDT)
X-Received: by 2002:a05:6602:3713:b0:861:c238:bf03 with SMTP id ca18e2360f4ac-86495e87f3fmr177737439f.8.1745971841519;
        Tue, 29 Apr 2025 17:10:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1745971841; cv=none;
        d=google.com; s=arc-20240605;
        b=ly89qZgiHcnYG3xx6yWUvSbrLX7TlplVko4uZuNkQ/qlSWqx6GIJcXlVsCIRBQDBM3
         4Y+ieZ1OYm3OYn376pHT3XiXZU+9HxzS7oMSZ5XBvjh8Cv25BgX+d93lo9I8AhkQI/vz
         dB0XS9C6oiIx3082gr2eYhxXdqfBDbcfoh3+ox6OGCt8xb0ozC3DpgqkbJbToER7ApFx
         XI0QIgvX5f5DiPRQ9sIlWjq8rIVF78WiE08HORha3ukbPcl0ubBd7s3Ka9fxIjF51VS3
         OMA3Az+MxVxH5YJjDXihuZ6DO4BhtYLugdyvsw+rSVn1QXUJN9F276HkRh+qCq52idCR
         WG0Q==
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=Xxfj39m9QMJ5QIeh8s6yEwpvH5Dn2D1nTC3h3HpV3qk=;
        fh=FHPCOD3vptmuEQg9drujpZ488lCS6X5YsZgbHrlMbXI=;
        b=TPGWHrkRr+SCaZH+W5AStMw08ryQGDt7oKLkl0y6/0OjXcrmgKursT/oCIlMxeW+5r
         U6vEyVqhgTB3DfO6aQZWIEm4mGQ2NArAswdnm0CqO7eLjbGCQjApn2Wr8ui76kzSGaPr
         5MxF01DF5ZBKdQj6enCmUM/Lng5rp46zldbsZc0bS+HblVnDcOcLhJKoRZNbxH8zdOma
         yeDNnnuWe8HiUdyaaZp2tqbHwPQ7uWPsGRJdep4XFSZTF6ymKyCisnqzarrhPVfZIb8+
         /hc0YqgUxzmqjc9lgC2/2nMrb7RGXCfEaeYZ4YLuQNG3/akTSw7DrWa6doUj6pk8Kl1d
         cwQQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Yuawp9CQ;
       spf=pass (google.com: domain of wizkid057@gmail.com designates 2607:f8b0:4864:20::233 as permitted sender) smtp.mailfrom=wizkid057@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com. [2607:f8b0:4864:20::233])
        by gmr-mx.google.com with ESMTPS id ca18e2360f4ac-8648bd21aafsi11559539f.0.2025.04.29.17.10.41
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 29 Apr 2025 17:10:41 -0700 (PDT)
Received-SPF: pass (google.com: domain of wizkid057@gmail.com designates 2607:f8b0:4864:20::233 as permitted sender) client-ip=2607:f8b0:4864:20::233;
Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3f8ae3ed8f4so4573355b6e.3
        for <bitcoindev@googlegroups.com>; Tue, 29 Apr 2025 17:10:41 -0700 (PDT)
X-Gm-Gg: ASbGncsrewuWFN86puYBj+k9OjCQarrkkYgAsZdOkzna1ksfp6u2gSfu+KseTXEC48m
	gOuWqnWI0YOY3RV6PobSVQ7kz4tdL3c2ZaiD1WsjD99X8lU/V4M7nUIhzMbz9kkAVDBZAKQ3Mat
	PTLmbyk965CUEBfjOhgJ861N+S6u6J7gU=
X-Received: by 2002:a05:6808:319b:b0:3fe:b0ad:f92a with SMTP id
 5614622812f47-40239e65f80mr917743b6e.6.1745971840972; Tue, 29 Apr 2025
 17:10:40 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CALkkCJY5T5sd5Am0M6abhaMMicwVNvSfwYQP1jMjxfVsuT8Jaw@mail.gmail.com>
From: Jason Hughes <wizkid057@gmail.com>
Date: Tue, 29 Apr 2025 20:10:28 -0400
X-Gm-Features: ATxdqUG2XSfV-Y-ulNQR0p1dIdmRqupgXY6nBaFK-fzG7UrJSUrf_dwO1gkAIJE
Message-ID: <CAMW46uk0nTh6wyFYshYoYd2YrmpK9gkNvSfDMqO9t32dA9zmmg@mail.gmail.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
To: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000005e7c750633f3bfa2"
X-Original-Sender: wizkid057@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=Yuawp9CQ;       spf=pass
 (google.com: domain of wizkid057@gmail.com designates 2607:f8b0:4864:20::233
 as permitted sender) smtp.mailfrom=wizkid057@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: <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 (/)

--0000000000005e7c750633f3bfa2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I believe you greatly overestimate the skill and competence of the people
who would do this type of thing. You could accomplish what you've laid out.
I could accomplish it. But the people who will actually do this to Bitcoin
once there's unrestricted OP_RETURN likely can not accomplish it today.
What you'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 such attacks after someone with technical knowledge
makes the "Connect your wallet, upload your data" button for them.

All of that said, you make excellent points for ridding Bitcoin of
arbitrary data completely. :)

On Tue, Apr 29, 2025 at 3:20=E2=80=AFPM Martin Habov=C5=A1tiak <
martin.habovstiak@gmail.com> wrote:

> Hi,
>
> I have a little demo for you.
>
> Firstly, I think the kind of illegal content most people have in mind are
> images. So let's start with a question: if one takes an illegal picture a=
nd
> sets every 173th pixel to a red dot will it become legal?
>
> If you have trouble imagining it, here's an example for you:
> https://imgur.com/a/J7RTPL7
>
> If you believe it would, we can end this conversation and my point is moo=
t.
> 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 users
> would choose an any image format he likes. So for this example I'm pickin=
g
> BMP.
>
> 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 519. The header size is 54 bytes, so stick the byte 54 at the fron=
t
> 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
> your node store a sequence of bytes that is considered illegal. If you're
> worried about it you have to resync the chain right now.
>
> Disclaimer: the numbers above might be a bit off, I did most computation
> in my head. Still, the point stands even if the pixels have a bit differe=
nt
> spacing/color.
>
> Same thing with malware distribution, except you can easily skip the
> invalid bytes using jump instructions or other techniques, so that might =
be
> even worse.
>
> Happy syncing!
>
> Martin
>
>
> D=C5=88a ut 29. 4. 2025, 11:15 Jason Hughes (wk057) <wizkid057@gmail.com>
> 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 i=
n:
>>
>> OP_RETURN was only made standard in a limited size to encourage less
>> harmful data carrying in Bitcoin. Attackers were using harmful methods o=
f
>> data carrying in unspendable UTXOs, and so a way to inject a small amoun=
t
>> of data was TOLERABLE over this harmful UTXO bloat that.  That mostly
>> worked, and such practices were quickly minimized. This remained the cas=
e
>> for about a decade without significant issue. Bitcoin is not file storag=
e,
>> and this was known to developers at that time.  Sadly, eventually an
>> exploit called 'inscriptions' happened which blew the cap off of the siz=
e
>> limitation of arbitrary data storage... and to make matters worse,
>> developers refused to patch the exploit or otherwise enforce the decade =
old
>> limit on arbitrary data size. If that wasn't bad enough, exploiters get =
a
>> 75% discount on transaction fees.
>>
>> With that history in mind, removing limits on OP_RETURN standardness siz=
e
>> is pointless. Relaxing OP_RETURN size limits without dealing with the
>> inscriptions exploit means no one will use this for anything besides
>> attacking the network with the worst possible data. There's little to no
>> incentive to use OP_RETURN for data storage when using the 'inscriptions=
'
>> exploit costs 4x less in transactions. What's the point of having a
>> "standard" way to store arbitrary data if the exploit method is 4x cheap=
er?
>> And the nonstandard version of the exploit allows 4x the data?
>>
>> Further, the inscriptions exploit currently requires chunking the data
>> between PUSH opcodes, meaning an on-disk analysis doesn't actually direc=
tly
>> reveal the underlying data the injector intended.  I can still run
>> something like "photorec" on my system and not have to sift through
>> thousands of 'inscriptions'. Removing the size limit on OP_RETURN breaks
>> this happenstance obfuscation that has saved us to-date. After this chan=
ge,
>> when data is recovered from a full node system, whatever some anonymous
>> person decided to stuff into an OP_RETURN will be serialized in plaintex=
t
>> 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.
>>
>> If you can't imagine the harm this will do to the ecosystem, let me pain=
t
>> some pictures for you:
>>
>> First, there's the obvious. Everyone running a node will now be
>> guaranteed to "posses and distribute" content that is likely illegal in
>> their jurisdiction. Not only are you storing this as a full node runner,
>> you're serving it to others. Hooray. /s
>>
>> Next, there's less obvious abuses. For example, let's say I want to
>> distribute malware. Well, might as well just store it in an OP_RETURN.
>> Then, any time I compromise a system with a Bitcoin node I know my malwa=
re
>> is directly on their system in a mostly predetermined spot already and I
>> don't even need to retrieve it from elsewhere! And, even better, my malw=
are
>> can use the Bitcoin P2P network itself to distribute itself. Just find a
>> willing full node, grab the block it's in. Thanks for the boost, node
>> runners!
>>
>> Worse, in order to actually participate in the network, everyone MUST
>> download all of this data from others (who must host it for you), proces=
s
>> it, and generally must host it for others to do the same. The network ca=
n't
>> survive with 100% pruned nodes. I think too many users nowadays don't
>> understand that running a full node is the ONLY way to actually particip=
ate
>> in Bitcoin.
>>
>> It's bad enough that chunked partly-obfuscated things exist on the
>> systems of full node runners today. It'll be even worse if that's
>> unrestricted with the removal of such limits.
>>
>> As I said in my Github comment: This is far more than a small technical
>> change. This is a fundamental change to the nature of what the Bitcoin
>> network itself is in its entirety. Ten years ago, developers of the
>> reference implementation knew this, and acted in the best interest of
>> 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
>> merged into Bitcoin Core, and Bitcoin Core then continues to be the
>> reference implementation... Bitcoin as we know it changes forever in the
>> most fundamental way imaginable: The reference implementation explicitly
>> turning the Bitcoin network into an arbitrary data storage system, inste=
ad
>> of evolving it as a decentralized currency.
>>
>> That's not Bitcoin anymore, and we might as well give up on Bitcoin ever
>> being a thing if this is the path chosen.  There are very few paths that
>> lead to a worthless Bitcoin, and this is probably in the top 3 worst
>> options.
>>
>> I can't understate this. It's one thing to refuse to act when faced with
>> an attack/exploit/etc.  That takes actual courage and conviction to do
>> what's right for the ecosystem... and I _almost_ can't fault the current
>> batch of devs for not having that courage.  However, it's another to ope=
nly
>> make sweeping changing to the ecosystem in an effort to make such things
>> acceptable.
>>
>> Have the courage to reject this type of thing for the sake of the overal=
l
>> project.
>>
>> JH
>> aka wk057
>> aka wizkid057
>> On Saturday, April 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille wr=
ote:
>>
>>> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <lu...@dashjr.org=
>
>>> wrote:
>>>
>>> > That's nonsense. They were and continue to be very effective, even
>>> with
>>> > only a small amount of adoption. Further, mining centralization and
>>>
>>> Standardness rules have definitely been effective in the past, if we go
>>> far enough back in time. But back then:
>>>
>>> * There were far less financial incentives to bypass them. Standardness
>>> adds inconvenience to people developing infrastructure on top, which ca=
n
>>> nudge in another direction. But I don't see how million-dollar (or more=
)
>>> business incentives would be thwarted by the need to communicate with
>>> miners directly (see below). These incentives will only increase as the
>>> subsidy dwindles.
>>>
>>> * There was far more reason for rules of this kind; the network was
>>> small and far less valuable, and there were significant concerns about
>>> increased node operation cost with a quickly-growing blockchain. With
>>> blocks consistently full for most of the time for years now, even at ti=
mes
>>> without so-called "spam", that concern just does not exist; nodes will =
be
>>> processing the same amount of transaction data anyway. I think I share
>>> Luke's feelings around non-financially-relevant transactions on-chain, =
but
>>> given sufficient demand for block space anyway, there just is no need t=
o
>>> discriminate.
>>>
>>> > pools denying miners options has been the biggest barrier to that
>>> > adoption. There is no significant financial impact either, that's jus=
t
>>> > FUD; miners using the fixed and improved spam filters have in fact
>>> > earned significantly more than miners using Core.
>>>
>>> I am doubtful of this claim, and would like to see evidence of it.
>>>
>>> > It would be a pain, but it is definitely viable. Thankfully, policy
>>> > works just fine for spam filtration, and can be adapted much quicker.
>>>
>>> Nobody is required to adopt policy, and I think you're burying your hea=
d
>>> in the sand if you believe even in a world with more decentralized
>>> hashpower, miners/hashers would voluntarily choose to disregard
>>> transactions that pay a significant fee, if the potential gains from
>>> accepting them exceed the cost of building infrastructure to bypass
>>> whatever policy exists.
>>>
>>> Bitcoin users do have a means to deny usage of the chain to truly
>>> damaging use: consensus changes. Those are not optional, apply to every=
one
>>> equally, do not create incentives for bypass, and - and I believe that =
is a
>>> good thing - can only be adopted with very wide agreement.
>>>
>>> > > b) centralisation
>>> >
>>> > No, this is more FUD.
>>>
>>> The **entire** reason why Bitcoin uses PoW, as opposed to using a
>>> traditional consensus system with a federation of block-builders, is to
>>> avoid censorship. If anyone dislikes the choices current miners make in
>>> what transactions they accept, they can - without asking anyone for
>>> permission - join the set of miners, and earn a proportional piece of t=
he
>>> pie. While it is the case that today mining power is quite concentrated=
 in
>>> a number of businesses, the set of such businesses can, and has, change=
d
>>> over time. This is a very valuable property.
>>>
>>> Part of the puzzle to make that permissionlessness of mining work is
>>> access to fee-paying transactions from the public. If sufficient econom=
ic
>>> demand exist for transactions that the public network denies, miners an=
d
>>> creators of such transaction will develop transaction rails that bypass
>>> that network.
>>>
>>> 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 f=
eel
>>> we'd be giving up on one of the most valuable properties the network ha=
s. I
>>> realize this is a slipstreamery-slope argument, but it is already
>>> happening, and once the rails are ubiquitous, it will be very hard to g=
o
>>> back to a public network.
>>>
>>> ---
>>>
>>> Because of all these reasons, Concept ACK on relaxing the OP_RETURN
>>> limits, including removing them entirely. I have been a strong proponen=
t of
>>> these limits in the past, and I'm not happy with seeing the demand for
>>> those 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.
>>>
>>> I will add that I am not in favor of relaxing many other standardness
>>> rules in Bitcoin Core, such as transaction sizes and other resource
>>> limitations. These have significant impact on the public's ability to
>>> verify and 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 outcome, but I'm hopeful that is not the case. Howe=
ver,
>>> these arguments do not apply to OP_RETURN limits, which don't serve an
>>> objective harm reduction beyond a subjective "that isn't what you shoul=
d be
>>> using the chain for".
>>>
>>> --
>>> Pieter
>>>
>>> --
>> 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/f4f6831a-d6b8-4f32-8a4e-c06=
69cc0a7b8n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0=
669cc0a7b8n%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/=
CAMW46uk0nTh6wyFYshYoYd2YrmpK9gkNvSfDMqO9t32dA9zmmg%40mail.gmail.com.

--0000000000005e7c750633f3bfa2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I believe you greatly overestimate the skill and comp=
etence 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 ac=
tually do this to Bitcoin once there&#39;s unrestricted OP_RETURN likely ca=
n not accomplish it today. What you&#39;ve laid out is a more technical att=
ack than this variant of attack is capable of... and what will actually hap=
pen is that once unlimited OP_RETURN is a thing, people willing to, but not=
 currently able, will take the easy route for such attacks after someone wi=
th technical=C2=A0knowledge makes the=C2=A0&quot;Connect your wallet, uploa=
d your data&quot; button for them.</div><div><br></div><div>All of that sai=
d, you make excellent=C2=A0points for ridding Bitcoin of arbitrary data com=
pletely. :)</div></div><br><div class=3D"gmail_quote gmail_quote_container"=
><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=3D"mailto:martin.habovstiak@gmail.=
com">martin.habovstiak@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"auto">Hi,<div dir=3D"auto"><br=
></div><div dir=3D"auto">I have a little demo for you.<div dir=3D"auto"><br=
></div><div dir=3D"auto">Firstly, I think the kind of illegal content most =
people 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 be=
come legal?</div><div dir=3D"auto"><br></div><div dir=3D"auto">If you have =
trouble imagining it, here&#39;s an example for you:=C2=A0<a href=3D"https:=
//imgur.com/a/J7RTPL7" target=3D"_blank">https://imgur.com/a/J7RTPL7</a></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">If you believe it would, w=
e can end this conversation and my point is moot.</div><div dir=3D"auto">Ho=
wever, I think you&#39;ll agree the image would still be illegal.</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Next, I think it&#39;s obvious th=
at an attacker seeking to harm bitcoin users would choose an any image form=
at he likes. So for this example 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 i=
s uncompressed, the red pixels turn into bytes 253, 7, 2 which happen to en=
code witness element length 519. The header size is 54 bytes, so stick the =
byte 54 at the front and you have a valid serialization of a sequence of wi=
tness elements.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Do you s=
ee 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"au=
to"><br></div><div dir=3D"auto">Yes, it&#39;s too late to fix this. It&#39;=
s already trivially possible to make your node store a sequence of bytes th=
at is considered illegal. If you&#39;re worried about it you have to resync=
 the chain right now.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Di=
sclaimer: the numbers above might be a bit off, I did most computation in m=
y head. Still, the point stands even if the pixels have a bit different spa=
cing/color.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Same thing w=
ith malware distribution, except you can easily skip the invalid bytes usin=
g 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"gma=
il_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">D=C5=88a ut 29=
. 4. 2025, 11:15 Jason Hughes (wk057) &lt;<a href=3D"mailto:wizkid057@gmail=
.com" target=3D"_blank">wizkid057@gmail.com</a>&gt; nap=C3=ADsal(a):<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">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/bitco=
in/pull/32359#issuecomment-2835467933" rel=3D"noreferrer" target=3D"_blank"=
>https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933</a><=
br>-=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/32359#issuecom=
ment-2835638919" rel=3D"noreferrer" target=3D"_blank">https://github.com/bi=
tcoin/bitcoin/pull/32359#issuecomment-2835638919</a><br>-=C2=A0<a href=3D"h=
ttps://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/3=
2359#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 limited size to encourage less harmful data carrying in Bitco=
in. Attackers were using harmful methods of data carrying in unspendable UT=
XOs, and so a way to inject a small amount of data was TOLERABLE over this =
harmful UTXO bloat that.=C2=A0 That mostly worked, and such practices were =
quickly minimized. This remained the case for about a decade without signif=
icant issue. Bitcoin is not file storage, and this was known to developers =
at that time.=C2=A0 Sadly, eventually an exploit called &#39;inscriptions&#=
39; happened which blew the cap off of the size limitation of arbitrary dat=
a storage... and to make matters worse, developers refused to patch the exp=
loit or otherwise enforce the decade old limit on arbitrary data size. If t=
hat wasn&#39;t bad enough, exploiters get a 75% discount on transaction fee=
s.<div><br></div><div>With that history in mind, removing limits on=C2=A0OP=
_RETURN standardness size is pointless. Relaxing OP_RETURN size limits with=
out dealing with the inscriptions exploit means no one will use this for an=
ything besides attacking the network with the worst possible data. There&#3=
9;s little to no incentive to use OP_RETURN for data storage when using the=
 &#39;inscriptions&#39; exploit costs 4x less in transactions. What&#39;s t=
he point of having a &quot;standard&quot; way to store arbitrary data if th=
e exploit method is 4x cheaper? And the nonstandard version of the exploit =
allows 4x the data?<br><br>Further, the inscriptions exploit currently requ=
ires chunking the data between PUSH opcodes, meaning an on-disk analysis do=
esn&#39;t actually directly reveal the underlying data the injector intende=
d.=C2=A0 I can still run something like &quot;photorec&quot; on my system a=
nd not have to sift through thousands of &#39;inscriptions&#39;. Removing t=
he size limit on OP_RETURN breaks this happenstance obfuscation that has sa=
ved 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 w=
ill be serialized 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 fu=
ll node runner.<div><br></div><div>If you can&#39;t imagine the harm this w=
ill do to the ecosystem, 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 j=
urisdiction. Not only are you storing this as a full node runner, you&#39;r=
e 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 mal=
ware. Well, might as well just store it in an OP_RETURN. Then, any time I c=
ompromise a system with a Bitcoin node I know my malware is directly on the=
ir system in a mostly predetermined spot already and I don&#39;t even need =
to retrieve it from elsewhere! And, even better, my malware can use the Bit=
coin 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>Wo=
rse, in order to actually participate in the network, everyone MUST downloa=
d all of this data from others (who must host it for you), process it, and =
generally must host it for others to do the same. The network can&#39;t sur=
vive with 100% pruned nodes. I think too many users nowadays don&#39;t unde=
rstand that running a full node is the ONLY way to actually participate in =
Bitcoin.</div><div><br></div><div>It&#39;s bad enough that chunked partly-o=
bfuscated things exist on the systems of full node runners today. It&#39;ll=
 be even worse if 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 t=
han a small technical change.=C2=A0This is a fundamental change to the natu=
re of what the Bitcoin network itself is in its entirety. Ten years ago, de=
velopers of the reference implementation knew this, and acted in the best i=
nterest of Bitcoin itself. Today, too many developers don&#39;t understand =
this duty.<br><br>That may sound like hyperbole, but it really isn&#39;t. I=
f this change is merged into Bitcoin Core, and Bitcoin Core then continues =
to be the reference implementation... Bitcoin as we know it changes forever=
 in the most fundamental way imaginable: The reference implementation expli=
citly turning the Bitcoin network into an arbitrary data storage system, in=
stead of evolving it as a decentralized currency.<br><br>That&#39;s not Bit=
coin anymore, and we might as well give up on Bitcoin ever being a thing if=
 this is the path 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=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
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" target=3D"_blank">h=
ttps://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc=
0a7b8n%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>

<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/CAMW46uk0nTh6wyFYshYoYd2YrmpK9gkNvSfDMqO9t32dA9zmmg%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAMW46uk0nTh6wyFYshYoYd2YrmpK9gkNvSfDMqO9t32dA9zmmg%40mail.g=
mail.com</a>.<br />

--0000000000005e7c750633f3bfa2--