From: rot13maxi <rot13maxi@protonmail•com>
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 12:58:49 +0000 [thread overview]
Message-ID: <hhgUoi2km8Iv3HQ0aTaZiBXOHq8baEXtG5SEX_VkyYxw-4G0dewhLaj-IiFvAJsZSHW5fXSS3tukOvgzkLcvwdJIzRdBMscd2QMpA_iQBk0=@protonmail.com> (raw)
In-Reply-To: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]
Hello,
“Unlimited storage” isn’t really accurate. It’s witness data in a taproot transaction, so the block size limit still applies. Anyone who runs an unpruned bitcoin node should be capacity-planning their disk space assuming that in the future blocks will be more full - as demand for blockspace increases, people will make better use of the space that we already have and average block weight will trend upwards. If you’re thinking about how much disk you will need when we have consistently full blocks, ordinal inscriptions don’t change that number.
- rijndael
On Fri, Jan 27, 2023 at 7:44 AM, Robert Dickinson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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.
[-- Attachment #2: Type: text/html, Size: 1818 bytes --]
next prev parent reply other threads:[~2023-01-27 12:59 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 [this message]
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
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='hhgUoi2km8Iv3HQ0aTaZiBXOHq8baEXtG5SEX_VkyYxw-4G0dewhLaj-IiFvAJsZSHW5fXSS3tukOvgzkLcvwdJIzRdBMscd2QMpA_iQBk0=@protonmail.com' \
--to=rot13maxi@protonmail$(echo .)com \
--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