path: root/da/9216103f52cf9f4b4783d37e768fa1bd728119

Delivery-date: Fri, 02 May 2025 17:00:33 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCJNLJPWXAIBBFNZ2XAAMGQERWLZKSI@googlegroups.com>)
	id 1uB0Iy-0005Ym-56
	for bitcoindev@gnusha.org; Fri, 02 May 2025 17:00:33 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e727e5392d3sf3576307276.0
        for <bitcoindev@gnusha.org>; Fri, 02 May 2025 17:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746230426; x=1746835226; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=fBZ3w85uCkHkQuvVqq7zDDGf0XZ59t2a7tf9dnLfI+M=;
        b=PbwTYuUIJxsIZf36vWWWdmUoA7DlTxgrfTwPEahcev9FdQVKMw/+RpQvV6ZFLl/XVM
         RI4xdI6f5wofvfyMHJIhn0SmckcUCcwknf1kU5NxXuUdpBRy5SNaclsePRxTBIjCJfFJ
         zmF+tx3XX2rFY1SiEQPTKRLYYzftuKDSdIby0Kpl3UPFfUQNyS2L/s2/Yn9DWaNkcq61
         LVM1viM0uaAXxCGEOeRsxYClpIjRbS/rRQ8Nub0Ecuijr0+so2G3ISCIpACvxZ7e8Q1h
         H6x3Z22mlFpJlOsfdkrNWIAvRIc2kLZk9P//IzTpBOLoPOhHmzNEAUm3ELKCWro++ZFg
         X64A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746230426; x=1746835226; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fBZ3w85uCkHkQuvVqq7zDDGf0XZ59t2a7tf9dnLfI+M=;
        b=V4sIAX26OdE7vZFPr7zJSb6TQC9ZYVhvuz16BtAxfqwqREpEeHlnarjiFJZ4TWuytv
         dT+rFuKlUKll98z6WhhAYKaC4QO6T793oJMUZFdvw138FxX9IaAvpLVxMyoKEPsJLlI5
         LOmPH/gi/ZollsODFLDPR9Xf0L2YKM1Q0NvjpDCOIioUJy3xlB9mGUvXxTobNVZ6gUVp
         zx0/wQYHIlGCfG8D0CEm81BjwwEChvdUaePUfxXtRXjD8cDPyghN+QsfkBSO6WK70SsN
         QQW3ruxIwrXblzIR9iDdIuocGEWJt7CE9sChXcuW9JwlGvEH3kiXKP/GLm/A5NdX2C1U
         e0Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746230426; x=1746835226;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=fBZ3w85uCkHkQuvVqq7zDDGf0XZ59t2a7tf9dnLfI+M=;
        b=KE//TxQM2HCekB9NMoNUqpMgKdl82u1TxPm+YgWkp8o7kNj+alxvjKm81twCmql4F7
         a1Ct1GE+xVzS3V3qJPiYssNJ3h14+Vsdwkc77micPaOQsIy//2TNdreQZCLxfNdHallE
         TLkdzUmN8tsSaCE7tueXiaCOC7DpUQ8GPqZMfpd9jxDxK3xHS+g+XeZ7nGlm4pWoV0Mn
         gMzBosX4/RpmO8b+bo/dR/6qhfZ3zfwkh5M8MAGIcCmQtJSFsiVUoQCiJr076XWYMDyp
         YfzsHu+fn/oTHKV0kOLt11SJcB5vJCNNkNsZEmJ6M5Er03AntNH16KHuRu8e6agJYZZb
         CZdg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWiNDzeo5ZjwRma+R2H+kTNDDafv3jy9QeMxX/LIjyyhzeIcIbk2DodLBzO4CdRcvJB/X8LF+JYraLW@gnusha.org
X-Gm-Message-State: AOJu0YzQE5nNZ8001/w9iVnWzZF1BjDcgGuDkKbHNazlgpv0fBU5kVln
	BC09IpTlnDct69GPFAAZHZpY6CJHpnlHYJxRxh/e4FBJJYPzt158
X-Google-Smtp-Source: AGHT+IHc463JQZcnmABZS4a3Y9p2w7hCj6d39QZWLPjY0Ok+avI5yyofmIS6tdU64sXbhzraJAjW6Q==
X-Received: by 2002:a05:6902:f86:b0:e6d:e24c:34bb with SMTP id 3f1490d57ef6-e7571a32e8bmr1672493276.2.1746230425630;
        Fri, 02 May 2025 17:00:25 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEIYXzl7IJQ2xT4szKkm6uHRdJ2DOzdaX3G0jCgJqYEFA==
Received: by 2002:a25:3d47:0:b0:e74:db4:432b with SMTP id 3f1490d57ef6-e74dcaafe3als540646276.2.-pod-prod-00-us;
 Fri, 02 May 2025 17:00:20 -0700 (PDT)
X-Received: by 2002:a05:690c:630d:b0:702:d4f:cdbc with SMTP id 00721157ae682-708bcf6467fmr116796237b3.18.1746230420829;
        Fri, 02 May 2025 17:00:20 -0700 (PDT)
Received: by 2002:a81:d448:0:b0:706:b535:945d with SMTP id 00721157ae682-708cfda3e38ms7b3;
        Fri, 2 May 2025 15:58:37 -0700 (PDT)
X-Received: by 2002:a05:690c:a8f:b0:6ff:2777:92b7 with SMTP id 00721157ae682-708ced7059bmr59180947b3.9.1746226716339;
        Fri, 02 May 2025 15:58:36 -0700 (PDT)
Date: Fri, 2 May 2025 15:58:35 -0700 (PDT)
From: Greg Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com>
In-Reply-To: <aBUlEOBqqrOIGHWC@petertodd.org>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
 <aBUlEOBqqrOIGHWC@petertodd.org>
Subject: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_109230_847965096.1746226715749"
X-Original-Sender: gmaxwell@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_109230_847965096.1746226715749
Content-Type: multipart/alternative; 
	boundary="----=_Part_109231_155298547.1746226715749"

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

On Friday, May 2, 2025 at 10:23:45=E2=80=AFPM UTC Peter Todd wrote:

# _Uninterrupted_ Illicit Data=20


To refine that, _illicit data_ is a problem and encryption at rest does not=
=20
address particularly in so far as possession of some data is a strict=20
liability crime.

Uninterrupted however means that it's more likely to get caught by random=
=20
scanning tools and whatnot -- and the encryption does that and probably=20
eliminates most of difference between interrupted and not, which is Peter=
=20
Todd's point.

But I heard someone last night say that encryption solves the illicit data=
=20
issue and it absolutely doesn't. It solves a particular unexciting but more=
=20
immediate sub part of the problem which is stuff like AV scanners.  But I=
=20
think that issue is orthogonal to this proposed change.

Aside, I'd been thinking there was a consensus limit on output sizes of=20
10kb but now I'm remembering that it's just at spend time and so obviously=
=20
wouldn't be relevant here.
=20

to make data publication somewhat more expensive with consensus changes.=20
Gregory Maxwell outlined how to do so on this mailing list years ago=20


A point of clarification,  that's really a scheme to keep arbitrary data=20
out of unprunable data.  The proofs that the values in question are what=20
they're supposed to be are themselves arbitrary data channels.  But these=
=20
proofs are prunable.

It's true that they they only need to be carried near the tip, so you could=
=20
even consider them *super prunable*.   And while perhaps you can get many=
=20
existing transaction patterns into that model, I'm pretty confident you=20
can't eliminate high bandwidth channels in script without massively=20
hobbling Bitcoin overall.  (Though hey, there are a lot of people out there=
=20
these days who would like to hobble bitcoin, so ::shrugs::) =20

Even if the functionality reduction were worth it, I dunno that the gain=20
between prunable (where most data storage stuff is) and super-prunable is=
=20
that interesting, particularly since you're looking at on the order of a=20
20%-30% increase of bandwidth for transactions and blocks to carry those=20
proofs.  Though for context I then eventually most nodes will sync through=
=20
some kind of utxo fast forward, just due to practical considerations, and=
=20
w/ that the difference in prunability degree is diminished further.

It might make sense for just *outputs* if data stuffing into the UTXO set=
=20
continues to be a problem as I think it can be done for just outputs=20
without huge functionality loss... though even so the disruption and=20
overheads yuck.  But before even considering such a disruptive change you'd=
=20
want to be really user everything was done to get the storage out of the=20
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=20
to pay even more money than that in terms of increased fees during fee=20
spikes; the difference in cost between witness space and txout space is=20
already 4x, and some are happy to publish data that way anyway.=20


A point I raised on bitcointalk: If you work out how much it costs to store=
=20
data on S3 (by far not the cheapest internet data storage) for *forever*=20
you end up with a rate that is less than a hundred thousandth the current=
=20
Bitcoin minimum fee rate-- maybe way less if you also factor in the cost of=
=20
storage decreasing, but I didn't.  Data stuffers are not particularly price=
=20
sensitive, if they were they wouldn't be using Bitcoin at all.  Schemes to=
=20
discourage them by causing them increased costs (e.g. by forcing them to=20
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 trying=
=20
to profit off seigniorage-- creating a rare 'asset' to sell to some greater=
=20
fool and profit off the difference-- further restricting them could=20
increase their volume because the resource they need has been made more=20
rare.  For the vast majority of users the ire comes about this stuff from=
=20
the fact that they've driven up fees at times, but that is dependent on=20
what they're willing to spend, which is likely not particularly related to=
=20
the marginal data rates. (And one could always embed smaller jpegs,=20
compress them better, or not use raw json instead of an efficient encoding=
=20
if they cared.. which they clearly don't.)

--=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/=
16f3af30-985f-40b7-afc3-9faae892d824n%40googlegroups.com.

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

<div><div dir=3D"auto">On Friday, May 2, 2025 at 10:23:45=E2=80=AFPM UTC Pe=
ter Todd wrote:<br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"># _Uninterru=
pted_ Illicit Data
<br /></blockquote><div><br /></div><div>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.</div><div><br /></div=
><div>Uninterrupted however means that it's more likely to get caught by ra=
ndom scanning tools and whatnot -- and the encryption does that and probabl=
y eliminates most of difference between interrupted and not, which is Peter=
 Todd'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't. =
It solves a particular unexciting but more immediate sub part of the proble=
m which is stuff like AV scanners.=C2=A0 But I think that issue is orthogon=
al to this proposed change.</div><div><br /></div><div>Aside, I'd been thin=
king there was a consensus limit on output sizes of 10kb but now I'm rememb=
ering that it's just at spend time and so obviously wouldn't be relevant he=
re.</div><div>=C2=A0</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; b=
order-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 th=
at'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're supposed to be are t=
hemselves arbitrary data channels.=C2=A0 But these proofs are prunable.</di=
v><div><br /></div><div>It's true that they they only need to be carried ne=
ar the tip, so you could even consider them *super prunable*.=C2=A0=C2=A0 A=
nd while perhaps you can get many existing transaction patterns into that m=
odel, I'm pretty confident you can't eliminate high bandwidth channels in s=
cript without massively hobbling Bitcoin overall.=C2=A0 (Though 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 function=
ality reduction were worth it, I dunno that the gain between prunable (wher=
e most data storage stuff is) and super-prunable is that interesting, parti=
cularly since you're looking at on the order of a 20%-30% increase of bandw=
idth for transactions and blocks to carry those proofs.=C2=A0 Though for co=
ntext I then eventually most nodes will sync through some kind of utxo fast=
 forward, just due to practical considerations, and w/ that the difference =
in prunability degree is diminished further.</div><div><br /></div><div>It =
might make sense for just *outputs* if data stuffing into the UTXO set cont=
inues to be a problem as I think it can be done for just outputs without hu=
ge functionality loss... though even so the disruption and overheads yuck.=
=C2=A0 But before even considering such a disruptive change you'd want to b=
e 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.</div><div><br =
/></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px so=
lid rgb(204, 204, 204); padding-left: 1ex;">have an overhead of about 6.6x.=
 Existing data encoders have been happy
<br />to pay even more money than that in terms of increased fees during fe=
e
<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: I=
f you work out how much it costs to store data on S3 (by far not the cheape=
st internet data storage) for *forever* you end up with a rate that is less=
 than a hundred thousandth the current Bitcoin minimum fee rate-- maybe way=
 less if you also factor in the cost of storage decreasing, but I didn't.=
=C2=A0 Data stuffers are not particularly price sensitive, if they were the=
y wouldn't be using Bitcoin at all.=C2=A0 Schemes to discourage them by cau=
sing them increased costs (e.g. by forcing them to encode in ways that use =
more block capacity) shouldn't be expected to work.</div><div><br /></div><=
div>And to the extent that what many of these things have been doing is try=
ing to profit off seigniorage-- creating a rare 'asset' to sell to some gre=
ater fool and profit off the difference-- further restricting them could in=
crease their volume because the resource they need has been made more rare.=
=C2=A0 For the vast majority of users the ire comes about this stuff from t=
he 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 to the =
marginal data rates. (And one could always embed smaller jpegs, compress th=
em better, or not use raw json instead of an efficient encoding if they car=
ed.. which they clearly don't.)</div><div><br /></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/16f3af30-985f-40b7-afc3-9faae892d824n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/16f3af30-985f-40b7-afc3-9faae892d824n%40googlegroups.com</a>.<br />

------=_Part_109231_155298547.1746226715749--

------=_Part_109230_847965096.1746226715749--