From: "Martin Habovštiak" <martin.habovstiak@gmail•com>
To: Greg Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
Date: Fri, 2 May 2025 23:02:42 -0300 [thread overview]
Message-ID: <CALkkCJZM4xpzKu6tb1J0YHtp-SxrFmHazetZJ7fUOj53Z2+wFA@mail.gmail.com> (raw)
In-Reply-To: <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 7455 bytes --]
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ňa pi 2. 5. 2025, 21:00 Greg Maxwell <gmaxwell@gmail•com> napísal(a):
> 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
> <https://groups.google.com/d/msgid/bitcoindev/16f3af30-985f-40b7-afc3-9faae892d824n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALkkCJZM4xpzKu6tb1J0YHtp-SxrFmHazetZJ7fUOj53Z2%2BwFA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8990 bytes --]
next prev parent reply other threads:[~2025-05-03 2:05 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 ` [bitcoindev] " Greg Maxwell
2025-05-03 2:02 ` Martin Habovštiak [this message]
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=CALkkCJZM4xpzKu6tb1J0YHtp-SxrFmHazetZJ7fUOj53Z2+wFA@mail.gmail.com \
--to=martin.habovstiak@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=gmaxwell@gmail$(echo .)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