public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: alicexbt <alicexbt@protonmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: Robert Dickinson <robert.lee.dickinson@gmail.com>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Date: Sat, 28 Jan 2023 10:58:12 +0000	[thread overview]
Message-ID: <dVxjcXpVSms-352cXBUbHI893qnlQ7uuF8V9dER5-MgWc2dgXecGCUu1TMIF8z3m_hWUvtAnILxGpcQlV_KIMdUS2D-UCCf24N8JIOTnpS4=@protonmail.com> (raw)
In-Reply-To: <hhgUoi2km8Iv3HQ0aTaZiBXOHq8baEXtG5SEX_VkyYxw-4G0dewhLaj-IiFvAJsZSHW5fXSS3tukOvgzkLcvwdJIzRdBMscd2QMpA_iQBk0=@protonmail.com>

Hi Bitcoin Developers,

> 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. 

I completely agree with this.

> 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.

> 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.

Initially I considered ordinals and the use of witness for inscriptions useless and harmful. However I have changed my opinion after looking at different things and reading several comments. I do not consider such things 'useless' or 'crap' and it won't affect bitcoin fee market negatively. There is no threat to LN as well.

I consider every bitcoin transaction a legit use case and would like to share an example and different perspective of how such inscriptions might be used at different places:

During the festival of Diwali, it is a common tradition among many Indian families to buy gold coins with the image of the goddess Laxmi, the goddess of wealth and prosperity. The coins are often bought as a symbol of good luck and prosperity for the upcoming year. They may also be given as gifts to family and friends or used as a form of investment. The coins can be purchased from a variety of sources, including jewelry stores and online retailers.

If people start buying bitcoin during Diwali, and sellers use the witness to include the image of Laxmi in the inputs used, it would be an innovative way of combining traditional customs with modern technology. Since some users consider bitcoin as digital gold, I won't be surprised if this really happens in future and won't consider it bad as the transactions are paying for block space used.

/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

------- Original Message -------
On Friday, January 27th, 2023 at 6:28 PM, rot13maxi via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> 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.


  reply	other threads:[~2023-01-28 10:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 12:44 [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson
2023-01-27 12:58 ` rot13maxi
2023-01-28 10:58   ` alicexbt [this message]
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='dVxjcXpVSms-352cXBUbHI893qnlQ7uuF8V9dER5-MgWc2dgXecGCUu1TMIF8z3m_hWUvtAnILxGpcQlV_KIMdUS2D-UCCf24N8JIOTnpS4=@protonmail.com' \
    --to=alicexbt@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=robert.lee.dickinson@gmail.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