From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Robert Dickinson <robert.lee.dickinson@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Date: Fri, 27 Jan 2023 13:21:00 +0000 [thread overview]
Message-ID: <Y9PPvBiWOXpBefmD@camus> (raw)
In-Reply-To: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]
On Fri, Jan 27, 2023 at 09:44:10AM -0300, Robert Dickinson via bitcoin-dev wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The ordinal
> scheme is elegant and genius IMHO, but when I think about the future disk
> use of all unpruned nodes, I question whether unlimited storage is wise to
> allow for such use cases. Wouldn't it be better to find a way to impose a
> size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal construct
> for proof of ownership in the real world, so that real property can be
> transferred on the blockchain using ordinals, but storing the property
> itself on the blockchain seems nonsensical to me.
Unfortunately, as near as I can tell there is no sensible way to prevent
people from storing arbitrary data in witnesses without incentivizing
even worse behavior and/or breaking legitimate use cases.
If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).
But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable.
There's a reasonable argument that this sort of data is toxic to the
network, since even though "the market is willing to bear" the price of
scares blockspace, if people were storing NFTs and other crap on the
chain, then the Bitcoin fee market would become entangled with random
pump&dump markets, undermining legitimate use cases and potentially
preventing new technology like LN from gaining a strong foothold. But
from a technical point of view, I don't see any principled way to stop
this.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-01-27 13:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 12:44 Robert Dickinson
2023-01-27 12:58 ` rot13maxi
2023-01-28 10:58 ` alicexbt
2023-01-29 10:34 ` Robert Dickinson
2023-01-31 8:58 ` Erik Aronesty
2023-01-27 13:21 ` Andrew Poelstra [this message]
2023-01-27 15:43 ` Aymeric Vitte
2023-01-28 16:47 ` Aymeric Vitte
2023-01-28 4:26 ` Robert Dickinson
2023-12-29 12:27 ` Greg Tonoski
2023-12-29 19:01 ` Nagaev Boris
2023-12-30 9:58 ` Erik Aronesty
2024-01-01 13:33 ` Brad Morrison
2024-01-01 16:08 ` Erik Aronesty
2024-01-03 9:11 ` Brad Morrison
2024-01-03 13:05 ` Erik Aronesty
2023-02-03 19:56 ` Melvin Carvalho
2023-02-04 14:25 ` Kostas Karasavvas
2023-02-06 16:39 ` Erik Aronesty
2023-02-06 17:31 ` Claus Ehrenberg
2023-02-06 18:05 ` Erik Aronesty
2023-02-07 12:17 ` Aymeric Vitte
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=Y9PPvBiWOXpBefmD@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=robert.lee.dickinson@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