From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
On Friday, May 2, 2025 at 10:23:45=E2=80=AFPM UTC Pe= ter Todd wrote:
# _Uninterru= pted_ 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 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.

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.

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.
=C2=A0
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,=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.

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

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.

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.

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 fe= e
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: 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>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.)

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/16f3af30-985f-40b7-afc3-9faae892d824n%40googlegroups.com.
------=_Part_109231_155298547.1746226715749-- ------=_Part_109230_847965096.1746226715749--