From: Greg Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
Date: Mon, 5 May 2025 16:55:34 -0700 (PDT) [thread overview]
Message-ID: <47079bf1-19de-4354-880d-2d197cecb0a2n@googlegroups.com> (raw)
In-Reply-To: <aBkxapFiBxC_TeEy@petertodd.org>
[-- Attachment #1.1: Type: text/plain, Size: 2596 bytes --]
On Monday, May 5, 2025 at 11:39:02 PM UTC Peter Todd wrote:
When you originally proposed the scheme that may have been true. But
these days you could probably use zero-knowledge-proofs to prove that
hash digests are in fact hash digests, without having to include the
actual pre-images of those hash digests.
The schemes that I'm aware of mostly have huge side-channels in the proof.
I think I constructed one before that didn't have one for proving bilinear
keys, and it only proved a pubkey was a pubkey, but at best it's an extra
constraint.
Goes back to what you're trying to accomplish, like assume network capacity
to process/forward blocks as a fixed amount. Your concern with NFTs is them
driving up fees. So now every transaction has to carry a proof its not
embedding a jpeg and so the effective throughput of the network is halved
or reduced by 30% or whatever from the proofs. Not a win. And of course
were then imagining something with more cryptographic complexity than the
whole of bitcoin just to close high bandwidth channels. And low bandwidth
channels on the order of 24 to 32-bits per independently adjustable piece
of data still exist.
But Amazon doesn't offer a service to store data on S3 forever.
It doesn't my example was an economic analysis that just assumed you bought
an investment to yield enough to pay for the S3. If you actually want it
you can construct it as a legal entity.
Also of course, S3 only offers storage. Not publication. Things like
Citrea (and Lightning) specifically need data publication.
Right I might have been unclear. Some people are laboring under a mistaken
belief that the objective of people putting large amounts of data in the
blockchain is just to "store stuff" --- and my point is that it's
outrageously uneconomical for that. While there may be some on the margin,
the reality is that people storing something believe they're getting some
benefit out of doing it that they don't get from an actual storage
solution. On reddit I went over a few
examples: https://old.reddit.com/r/Bitcoin/comments/1kea81d/why_is_this_sub_quiet_about_the_current_debate/mqi0vfw/
--
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/47079bf1-19de-4354-880d-2d197cecb0a2n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3406 bytes --]
next prev parent reply other threads:[~2025-05-06 0:07 UTC|newest]
Thread overview: 55+ 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-05 6:04 ` Bitcoin Error Log
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
2025-05-05 21:45 ` Peter Todd
2025-05-05 23:55 ` Greg Maxwell [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-05 9:18 ` Anthony Towns
2025-05-05 21:34 ` [bitcoindev] Weak blocks give an advantage to large miners Peter Todd
2025-05-06 8:56 ` Sjors Provoost
2025-05-02 20:43 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
2025-05-04 20:04 ` Nagaev Boris
2025-05-05 11:42 ` Greg Maxwell
2025-05-05 14:32 ` Nagaev Boris
2025-05-05 21:30 ` Peter Todd
2025-05-05 14:05 ` Greg Maxwell
[not found] ` <20250502064744.92B057C0EE2@smtp.postman.i2p>
2025-05-07 1:20 ` pithosian
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=47079bf1-19de-4354-880d-2d197cecb0a2n@googlegroups.com \
--to=gmaxwell@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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