path: root/df/92814f8e7491c5249f11639a3bdef2f3d480f7

Delivery-date: Fri, 02 May 2025 19:05:12 -0700
Received: from mail-oo1-f62.google.com ([209.85.161.62])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDZPZFXW2IMRBTPT2XAAMGQERLBONXY@googlegroups.com>)
	id 1uB2Fa-0006q2-KQ
	for bitcoindev@gnusha.org; Fri, 02 May 2025 19:05:12 -0700
Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-60212c73868sf2110766eaf.3
        for <bitcoindev@gnusha.org>; Fri, 02 May 2025 19:05:10 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746237904; cv=pass;
        d=google.com; s=arc-20240605;
        b=TQ0S7j3GKBycgJloFpRRIVzpZ5SVxO31/zQt/bgHm+cxNGCVPxrGVeOBvTd9yYKLME
         Zug21Sj0rcVrTZUlCD2nkRMLhe9IuGo/HwDaJBM4G1nwedfPMMmXwNMM+HlKI3W0YZlE
         Rf5TR7uordB97pcVjAnzCTp0dSedbcmRjz8BAdYu5xibMu7vKTh5IuA91wC4wu0WUxoY
         vhJflfbBF20ecYBpGEqy5WHbv8sq3ISxPl4lW2TqS93BGoaA2zZCPr1OdQeATeIqUlxg
         JR0JrB+L2EwhFyDXq7Z/0XFL2CCBjpkEanY/KyaMbLHBhhkFHbbGPTLWfl00YiHJGoWC
         mbxg==
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=fP1LAA6sq9xEBB6dKMv62r0W3lhJoFVGVjmfW2IeqcY=;
        fh=aFXQeseFT2SKpEGvYrIlQuNf+efHs/iA4dGuji8giCs=;
        b=EN9RG2B7mHObj+cKNvO1Bl34kvOJ/QEfY81cGRJZrm2oCEMzflJFNIJRmh/+E7yXj7
         PPQIG7fvYuvbvRULfevAVIH28Nwb2l79hil1PiM9o1CtbhCRYf7qhrmE6RsDymJCrr4w
         wA2iS4LGOEeNageU3n6UnEmyLgbNhMTk20nTgX9itEoOIiXD+Tor95dHBmUusGpimCXR
         sSYQuWYNfxeUGv416b2/X00Hqgy5McHgy35/9wMcKDc1iuxB+KizPKBc/VsZVMBiXj7R
         c1CozL6a3mGbtxcOCq2hoE0am78Zw2QBSAKGxROq7rh284pVLCu9rHEojk3BzsD7zGmW
         bLlA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=W569dX9X;
       spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::e34 as permitted sender) smtp.mailfrom=martin.habovstiak@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=1746237904; x=1746842704; 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=fP1LAA6sq9xEBB6dKMv62r0W3lhJoFVGVjmfW2IeqcY=;
        b=Fvh5447fsorLCFvQSSD9kCjmRPGnLWJqLak0cbYX2BFwtTKZBjJa+2Mp/Ie+H78aOV
         3yFaRwnsgeB5emvY/2BLF06uDjqvYmyK1bXNfdPGZGCalG3v7kbdUeNOx1rxtft6WjSM
         xLm/dxDjWDqQusCHzFWHSXoWbpDUUwLgOkG5OcgC0TqZYX+GTprB9gyRwhHS9acjRyx+
         sqYe4TAB6wyxDD8ZCVMaL9oEz3ljDRg8sf5v+jlmoZpyUnSe/t499wYvqAHerQWOKUlj
         3uEkX/6ioGnu6x/ft9y0X/g5RbruKDhcZmVLNvCBtUnrmVhx1tN1AID92QtzG4rByBHh
         SvnA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746237904; x=1746842704; 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=fP1LAA6sq9xEBB6dKMv62r0W3lhJoFVGVjmfW2IeqcY=;
        b=bG+FtbOehjuNH03e9B4WogkL9t0NI6iaU8ycDzfjGjYAdVC+lo/S3hSumXMRV9Lrrz
         Wl6ZCRvDdPjk0uex9Xcd0foz065OvCjT1sGOfDbVW9cUwyatmREw4BfqU/+OpUViaUgY
         /YZaq3j+sERMMCzUqio5p9mHJUcgbBj2XYbSLEDC7NVz+W3UW+G3PB+dZEl/qNglSU1x
         buMJalRrbMu4iPEv/At9RxVSRwR5lcHsVCgMl0Rjk2NMc+Ejm0gyejNzDKhVNDvGJedT
         uDqCSoSrmujxWB4+Oyq/fYrhaQ7DlSeHPJpr+6xYvQOLKTpIM6nHGCmXoh2v1fQ6nE7a
         nY9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746237904; x=1746842704;
        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=fP1LAA6sq9xEBB6dKMv62r0W3lhJoFVGVjmfW2IeqcY=;
        b=XGw+KlmT+zAgIJ3avx2/RC9e/3vKX/+igxaEMII8PKB+CQ/M8QoAiretPJ0F/CqZ/R
         uWI9dtX8aIkCtK9k6oT4HJ/604X8hRTkE2sSUUiDxHjgK+SpU7wvCGt667R+F/skvGQL
         8w2VzwpgXKkMWRbPgFeugLALpK08j+G3GDa03b809+isaqE7NfbAq+vh7jfqL6p8eJD3
         67I6cvxRUPnsMiLbE1vbFaPIF88cb3hHJ5wdoY0h4fxyH6No9WgR8L5+a+qo6V5+jIe9
         uQoACeDH3kHpsT4CS8LQTTYAi0hb85RQI+2Ff1QYLnpn3ynI0I3ROXhutHxV6zfOsob2
         +96w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXXzkKwNdYkn9zJSZTV+KfUl+iwB3LDZD5b+bgiJfVCCA8ft1414tzOMdZWcQFKadhCXT1dPUktSOqa@gnusha.org
X-Gm-Message-State: AOJu0YxiZMI75f98QhDLIsEvkDsucYRU6SX6gPsUOBk/zXpCP8IhocTh
	gKbv52wrO1RzTUkgo9Txdn47O6FE1pk7NksFUGayZCi1iKRQ4M7l
X-Google-Smtp-Source: AGHT+IFXNb8rlesIhvRTSTJ2/J2TIUlv79MsvttGjnlKyRCk6zNr0Btw0hq+jvsulnK7YTdsSsRgOA==
X-Received: by 2002:a05:6820:811a:b0:606:85ad:881 with SMTP id 006d021491bc7-607ee5132dfmr2559615eaf.0.1746237904068;
        Fri, 02 May 2025 19:05:04 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFdARDvDHOqaCn4ud3EhCgjTIwBsVFM6StCDdWUu0ah4Q==
Received: by 2002:a05:6820:1044:b0:602:1ea2:b1d9 with SMTP id
 006d021491bc7-607def16e21ls737107eaf.1.-pod-prod-01-us; Fri, 02 May 2025
 19:05:00 -0700 (PDT)
X-Received: by 2002:a05:6808:6c82:b0:401:e8e:189a with SMTP id 5614622812f47-40341a6f095mr2829838b6e.31.1746237900865;
        Fri, 02 May 2025 19:05:00 -0700 (PDT)
Received: by 2002:a05:6808:1a9d:b0:3f9:f009:458e with SMTP id 5614622812f47-4034255bd1amsb6e;
        Fri, 2 May 2025 19:02:53 -0700 (PDT)
X-Received: by 2002:a05:6a21:900e:b0:1f5:6a1a:329b with SMTP id adf61e73a8af0-20cdfee9a76mr8815529637.32.1746237772110;
        Fri, 02 May 2025 19:02:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1746237772; cv=none;
        d=google.com; s=arc-20240605;
        b=NFGXUIOBZv8ZrW0MlRhTzdMjQ0mlwXdoeacstM1ii6kAMlJTdV7MBsg4+DBAwgskZy
         9nIjBGzjh27Q17iY23xrd0vae3FgzoUU7wiXiABkhqxmwYBeIij3f3j2UwgKLVGa9Kk2
         fY1o9grknhs1pqkIZcTw63wQGnHVSTbd0A2ASzP1uIJivfsxqyK2GtDKG9w9qbc5MZ4q
         20O0dwZgutrduoR6+CeQoKOsFKqXogDsa8YpkZpzfuEnXin5t2TA9c08BtX+GseMrHoS
         XkKlcHE5agOqQE6TQhBcgEK6hTLAmVOcXmXF+8j/mS9oyI8JTwyKPtv7TtPystLCK/5w
         gIDQ==
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=AGumZrcbnxrbpcwpv19t2ro9f2+Du7I0DYTL7FVTJPo=;
        fh=buJUvwPPgdi5Z5zmcvUt6NajLrOVgzwZz6n1oNFrtB8=;
        b=dzP7ngZN5gzaLFEMsmmlZdtX96lPSCnHI6CES6MUiA5BIA68XL04nF0NFhDnSBhrkK
         DLojmHAARZDe170dFO40HdloR7H7/nTxSoNFu3rH/ud2Hyo9wYAHyzmxVoUV2trkc1aU
         8b7P5V0Sm0gdY49IX385d12GQ01mPoZjKZkPoVd5kVz4gyNH8jf3bEiz+PcoubrXohCo
         qyDQRFUsmsKqVTRm/Na0AueZBRHztGlHic0faglslElMxgmP4nCcwoX58MIIlLbbhqhg
         AR5ARI9zExRP2aSWGMGMO4W18d0mJLCw0QbeiKNptFm9G6xS9+n846yXLCkdZvQq+BD+
         GtCQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=W569dX9X;
       spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::e34 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com. [2607:f8b0:4864:20::e34])
        by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-74058b7e01dsi42481b3a.0.2025.05.02.19.02.52
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 02 May 2025 19:02:52 -0700 (PDT)
Received-SPF: pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::e34 as permitted sender) client-ip=2607:f8b0:4864:20::e34;
Received: by mail-vs1-xe34.google.com with SMTP id ada2fe7eead31-4c308e7b84fso697696137.1
        for <bitcoindev@googlegroups.com>; Fri, 02 May 2025 19:02:52 -0700 (PDT)
X-Gm-Gg: ASbGncuP75qiAzlC6g01dEvM7xpI/YcjziVIFoOqpgACI5insjzBid9wJNbRclYQq7d
	OFpABBDsG5/5Yed3i9M4oHp3Zlf8EyEPfZBieiwV1qf0Lle1bPvuZjiZ2B16fxNuW/uZ2SYfedt
	wzJtgHSv8RGFQ/rRrcLuK2JCF9IszgaBnOUIyyqTRCRE41LcouUAI8S2jcmyfFiAs=
X-Received: by 2002:a05:6102:1589:b0:4da:e71a:17db with SMTP id
 ada2fe7eead31-4dafb568959mr3641711137.13.1746237771059; Fri, 02 May 2025
 19:02:51 -0700 (PDT)
MIME-Version: 1.0
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
 <aBUlEOBqqrOIGHWC@petertodd.org> <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com>
In-Reply-To: <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com>
From: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
Date: Fri, 2 May 2025 23:02:42 -0300
X-Gm-Features: ATxdqUEdOYnSXuVLf7LllQhgD6XEtdWsmQ7_urcZm4e6IwychSy7W5ASwC59yAk
Message-ID: <CALkkCJZM4xpzKu6tb1J0YHtp-SxrFmHazetZJ7fUOj53Z2+wFA@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's
 Advocate Position
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000099c78063431aa9f"
X-Original-Sender: martin.habovstiak@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=W569dX9X;       spf=pass
 (google.com: domain of martin.habovstiak@gmail.com designates
 2607:f8b0:4864:20::e34 as permitted sender) smtp.mailfrom=martin.habovstiak@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 (/)

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

A few more points:
* I've just happened to talk to a lawyer and he confirmed that a) merely
having illegal content as a part of the chain is not illegal, at least not
as long as it's not possible to trivially open it with general-purpose
software b) images that are illegal with a bunch of red dots would still be
illegal
* That being said, confusing scanning tools is somewhat interesting but
solved by xoring. Being able to xor without redownloading is already
possible with an external tool. It'd be nice to have it integrated but I
think the people who want it should make the PR (or finance it)
* Funnily enough, my first Bitcoin project ever involved hiding data into
bitcoin addresses by grinding: https://github.com/Kixunil/btcsteg so it's
accessible to anyone who can google (disclaimer: I've never actually sent
anything into the chain using it; also please don't send any tips to that
address)

* There was an argument, that doing the red dot thing is difficult for
non-technical people. That's nonsense, I literally used ChatGPT to write
the code because I was lazy. It spit out perfectly working code on first
attempt.

* I'm writing a (Slovak) article about this and one of the points I made is
requiring signatures to prove dlog knowledge for non-p2tr outputs would
require more than double the size of current OP_RETURN limit per typical
transaction. IOW, if today every single transaction added a maximum
standard OP_RETURN it'd still be less data than trying to prevent it. And
that's just data size. Signature verification is MUCH more costly than
processing of OP_RETURN and whatnot.

* Requiring signatures and preimages for Taproot would destroy protocols
relying on NUMS and also completely remove all the benefits of Taproot.


So yeah, I don't see this ever being implemented. It's also quite ironic
that attempts to fight spam would make it much worse.


D=C5=88a pi 2. 5. 2025, 21:00 Greg Maxwell <gmaxwell@gmail.com> nap=C3=ADsa=
l(a):

> On Friday, May 2, 2025 at 10:23:45=E2=80=AFPM UTC Peter Todd wrote:
>
> # _Uninterrupted_ Illicit Data
>
>
> To refine that, _illicit data_ is a problem and encryption at rest does
> not address particularly in so far as possession of some data is a strict
> liability crime.
>
> Uninterrupted however means that it's more likely to get caught by random
> scanning tools and whatnot -- and the encryption does that and probably
> eliminates most of difference between interrupted and not, which is Peter
> Todd's point.
>
> But I heard someone last night say that encryption solves the illicit dat=
a
> issue and it absolutely doesn't. It solves a particular unexciting but mo=
re
> immediate sub part of the problem which is stuff like AV scanners.  But I
> think that issue is orthogonal to this proposed change.
>
> Aside, I'd been thinking there was a consensus limit on output sizes of
> 10kb but now I'm remembering that it's just at spend time and so obviousl=
y
> wouldn't be relevant here.
>
>
> to make data publication somewhat more expensive with consensus changes.
> Gregory Maxwell outlined how to do so on this mailing list years ago
>
>
> A point of clarification,  that's really a scheme to keep arbitrary data
> out of unprunable data.  The proofs that the values in question are what
> they're supposed to be are themselves arbitrary data channels.  But these
> proofs are prunable.
>
> It's true that they they only need to be carried near the tip, so you
> could even consider them *super prunable*.   And while perhaps you can ge=
t
> many existing transaction patterns into that model, I'm pretty confident
> you can't eliminate high bandwidth channels in script without massively
> hobbling Bitcoin overall.  (Though hey, there are a lot of people out the=
re
> these days who would like to hobble bitcoin, so ::shrugs::)
>
> Even if the functionality reduction were worth it, I dunno that the gain
> between prunable (where most data storage stuff is) and super-prunable is
> that interesting, particularly since you're looking at on the order of a
> 20%-30% increase of bandwidth for transactions and blocks to carry those
> proofs.  Though for context I then eventually most nodes will sync throug=
h
> some kind of utxo fast forward, just due to practical considerations, and
> w/ that the difference in prunability degree is diminished further.
>
> It might make sense for just *outputs* if data stuffing into the UTXO set
> continues to be a problem as I think it can be done for just outputs
> without huge functionality loss... though even so the disruption and
> overheads yuck.  But before even considering such a disruptive change you=
'd
> want to be really user everything was done to get the storage out of the
> unprunable data first, e.g. by getting rid of limits on op_return size.
>
> have an overhead of about 6.6x. Existing data encoders have been happy
> to pay even more money than that in terms of increased fees during fee
> spikes; the difference in cost between witness space and txout space is
> already 4x, and some are happy to publish data that way anyway.
>
>
> A point I raised on bitcointalk: If you work out how much it costs to
> store data on S3 (by far not the cheapest internet data storage) for
> *forever* you end up with a rate that is less than a hundred thousandth t=
he
> current Bitcoin minimum fee rate-- maybe way less if you also factor in t=
he
> cost of storage decreasing, but I didn't.  Data stuffers are not
> particularly price sensitive, if they were they wouldn't be using Bitcoin
> at all.  Schemes to discourage them by causing them increased costs (e.g.
> by forcing them to encode in ways that use more block capacity) shouldn't
> be expected to work.
>
> And to the extent that what many of these things have been doing is tryin=
g
> to profit off seigniorage-- creating a rare 'asset' to sell to some great=
er
> fool and profit off the difference-- further restricting them could
> increase their volume because the resource they need has been made more
> rare.  For the vast majority of users the ire comes about this stuff from
> the fact that they've driven up fees at times, but that is dependent on
> what they're willing to spend, which is likely not particularly related t=
o
> the marginal data rates. (And one could always embed smaller jpegs,
> compress them better, or not use raw json instead of an efficient encodin=
g
> if they cared.. which they clearly don't.)
>
> --
> 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/16f3af30-985f-40b7-afc3-9faa=
e892d824n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/16f3af30-985f-40b7-afc3-9fa=
ae892d824n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=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/=
CALkkCJZM4xpzKu6tb1J0YHtp-SxrFmHazetZJ7fUOj53Z2%2BwFA%40mail.gmail.com.

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

<div dir=3D"auto"><p dir=3D"ltr">A few more points:<br>
* I&#39;ve just happened to talk to a lawyer and he confirmed that a) merel=
y having illegal content as a part of the chain is not illegal, at least no=
t as long as it&#39;s not possible to trivially open it with general-purpos=
e software b)=C2=A0images that are illegal with a bunch of red dots would s=
till be illegal<br>
* That being said, confusing scanning tools is somewhat interesting but sol=
ved by xoring. Being able to xor without redownloading is already possible =
with an external tool. It&#39;d be nice to have it integrated but I think t=
he people who want it should make the PR (or finance it)<br>
* Funnily enough, my first Bitcoin project ever involved hiding data into b=
itcoin addresses by grinding:=C2=A0<a href=3D"https://github.com/Kixunil/bt=
csteg" target=3D"_blank" rel=3D"noreferrer">https://github.com/Kixunil/btcs=
teg</a> so it&#39;s accessible to anyone who can google (disclaimer: I&#39;=
ve never actually sent anything into the chain using it; also please don&#3=
9;t send any tips to that address)</p><p dir=3D"ltr">* There was an argumen=
t, that doing the red dot thing is difficult for non-technical people. That=
&#39;s nonsense, I literally used ChatGPT to write the code because I was l=
azy. It spit out perfectly working code on first attempt.</p><p dir=3D"ltr"=
>* I&#39;m writing a (Slovak) article about this and one of the points I ma=
de is requiring signatures to prove dlog knowledge for non-p2tr outputs wou=
ld require more than double the size of current OP_RETURN limit per typical=
 transaction. IOW, if today every single transaction added a maximum standa=
rd OP_RETURN it&#39;d still be less data than trying to prevent it. And tha=
t&#39;s just data size. Signature verification is MUCH more costly than pro=
cessing of OP_RETURN and whatnot.</p><p dir=3D"ltr">* Requiring signatures =
and preimages for Taproot would destroy protocols relying on NUMS and also =
completely remove all the benefits of Taproot.</p><p dir=3D"ltr"><br></p><d=
iv dir=3D"auto">So yeah, I don&#39;t see this ever being implemented. It&#3=
9;s also quite ironic that attempts to fight spam would make it much worse.=
</div><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" clas=
s=3D"gmail_attr">D=C5=88a pi 2. 5. 2025, 21:00 Greg Maxwell &lt;<a href=3D"=
mailto:gmaxwell@gmail.com" target=3D"_blank" rel=3D"noreferrer">gmaxwell@gm=
ail.com</a>&gt; nap=C3=ADsal(a):<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv><div dir=3D"auto">On Friday, May 2, 2025 at 10:23:45=E2=80=AFPM UTC Pete=
r Todd wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"># _Uninterrupted_ Illici=
t Data
<br></blockquote><div><br></div><div>To refine that, _illicit data_ is a pr=
oblem and encryption at rest does not address particularly in so far as pos=
session of some data is a strict liability crime.</div><div><br></div><div>=
Uninterrupted however means that it&#39;s more likely to get caught by rand=
om scanning tools and whatnot -- and the encryption does that and probably =
eliminates most of difference between interrupted and not, which is Peter T=
odd&#39;s point.</div><div><br></div><div>But I heard someone last night sa=
y that encryption solves the illicit data issue and it absolutely doesn&#39=
;t. It solves a particular unexciting but more immediate sub part of the pr=
oblem which is stuff like AV scanners.=C2=A0 But I think that issue is orth=
ogonal to this proposed change.</div><div><br></div><div>Aside, I&#39;d bee=
n thinking there was a consensus limit on output sizes of 10kb but now I&#3=
9;m remembering that it&#39;s just at spend time and so obviously wouldn&#3=
9;t be relevant here.</div><div>=C2=A0</div><blockquote style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">to =
make data publication somewhat more expensive with consensus changes.
<br>Gregory Maxwell outlined how to do so on this mailing list years ago
<br></blockquote><div><br></div><div>A point of clarification,=C2=A0 that&#=
39;s really a scheme to keep arbitrary data out of unprunable data.=C2=A0 T=
he proofs that the values in question are what they&#39;re supposed to be a=
re themselves arbitrary data channels.=C2=A0 But these proofs are prunable.=
</div><div><br></div><div>It&#39;s true that they they only need to be carr=
ied near the tip, so you could even consider them *super prunable*.=C2=A0=
=C2=A0 And while perhaps you can get many existing transaction patterns int=
o that model, I&#39;m pretty confident you can&#39;t eliminate high bandwid=
th channels in script without massively hobbling Bitcoin overall.=C2=A0 (Th=
ough hey, there are a lot of people out there these days who would like to =
hobble bitcoin, so ::shrugs::)=C2=A0 <br></div><div><br></div><div>Even if =
the functionality reduction were worth it, I dunno that the gain between pr=
unable (where most data storage stuff is) and super-prunable is that intere=
sting, particularly since you&#39;re looking at on the order of a 20%-30% i=
ncrease of bandwidth for transactions and blocks to carry those proofs.=C2=
=A0 Though for context I then eventually most nodes will sync through some =
kind of utxo fast forward, just due to practical considerations, and w/ tha=
t the difference in prunability degree is diminished further.</div><div><br=
></div><div>It might make sense for just *outputs* if data stuffing into th=
e UTXO set continues to be a problem as I think it can be done for just out=
puts without huge functionality loss... though even so the disruption and o=
verheads yuck.=C2=A0 But before even considering such a disruptive change y=
ou&#39;d want to be really user everything was done to get the storage out =
of the unprunable data first, e.g. by getting rid of limits on op_return si=
ze.</div><div><br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">have an overhead of abo=
ut 6.6x. Existing data encoders have been happy
<br>to pay even more money than that in terms of increased fees during fee
<br>spikes; the difference in cost between witness space and txout space is
<br>already 4x, and some are happy to publish data that way anyway.
<br></blockquote><div><br></div><div>A point I raised on bitcointalk: If yo=
u work out how much it costs to store data on S3 (by far not the cheapest i=
nternet data storage) for *forever* you end up with a rate that is less tha=
n a hundred thousandth the current Bitcoin minimum fee rate-- maybe way les=
s if you also factor in the cost of storage decreasing, but I didn&#39;t.=
=C2=A0 Data stuffers are not particularly price sensitive, if they were the=
y wouldn&#39;t be using Bitcoin at all.=C2=A0 Schemes to discourage them by=
 causing them increased costs (e.g. by forcing them to encode in ways that =
use more block capacity) shouldn&#39;t be expected to work.</div><div><br><=
/div><div>And to the extent that what many of these things have been doing =
is trying to profit off seigniorage-- creating a rare &#39;asset&#39; to se=
ll to some greater fool and profit off the difference-- further restricting=
 them could increase their volume because the resource they need has been m=
ade more rare.=C2=A0 For the vast majority of users the ire comes about thi=
s stuff from the fact that they&#39;ve driven up fees at times, but that is=
 dependent on what they&#39;re willing to spend, which is likely not partic=
ularly related to the marginal data rates. (And one could always embed smal=
ler jpegs, compress them better, or not use raw json instead of an efficien=
t encoding if they cared.. which they clearly don&#39;t.)</div><div><br></d=
iv></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 noreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups=
.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/16f3af30-985f-40b7-afc3-9faae892d824n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/16f3af30-985f-40b7=
-afc3-9faae892d824n%40googlegroups.com</a>.<br>
</blockquote></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/CALkkCJZM4xpzKu6tb1J0YHtp-SxrFmHazetZJ7fUOj53Z2%2BwFA%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CALkkCJZM4xpzKu6tb1J0YHtp-SxrFmHazetZJ7fUOj53Z2%2BwFA%40ma=
il.gmail.com</a>.<br />

--000000000000099c78063431aa9f--