From: Greg Maxwell <gmaxwell@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
Date: Fri, 2 May 2025 15:58:35 -0700 (PDT) [thread overview]
Message-ID: <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com> (raw)
In-Reply-To: <aBUlEOBqqrOIGHWC@petertodd.org>
[-- Attachment #1.1: Type: text/plain, Size: 4807 bytes --]
On Friday, May 2, 2025 at 10:23:45 PM 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 data
issue and it absolutely doesn't. It solves a particular unexciting but more
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 obviously
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 get 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 there
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 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
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 the current
Bitcoin minimum fee rate-- maybe way less if you also factor in the 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 trying
to profit off seigniorage-- creating a rare 'asset' to sell to some greater
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 to
the marginal data rates. (And one could always embed smaller jpegs,
compress them better, or not use raw json instead of an efficient encoding
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-9faae892d824n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5705 bytes --]
next prev parent reply other threads:[~2025-05-03 0:00 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
2025-04-30 15:37 ` Nagaev Boris
2025-04-30 16:30 ` Sjors Provoost
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-05-01 17:40 ` Andrew Toth
2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
2025-05-01 19:33 ` Nagaev Boris
2025-05-02 6:34 ` Anthony Towns
2025-05-02 18:29 ` Peter Todd
2025-05-03 5:14 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-01 3:01 ` Anthony Towns
2025-05-02 18:56 ` Greg Tonoski
2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-02 0:14 ` PandaCute
2025-05-02 11:16 ` [bitcoindev] " Sjors Provoost
2025-05-02 14:37 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-02 16:43 ` Greg Maxwell
2025-05-02 13:58 ` [bitcoindev] " Bob Burnett
2025-05-02 20:03 ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
2025-05-02 22:58 ` Greg Maxwell [this message]
2025-05-03 2:02 ` [bitcoindev] " Martin Habovštiak
2025-05-02 6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell
2025-05-02 9:51 ` Anthony Towns
2025-05-02 17:36 ` Greg Maxwell
2025-05-02 20:43 ` Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox