+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--

+