public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Robert Dickinson <robert.lee.dickinson@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Date: Sun, 29 Jan 2023 07:34:54 -0300	[thread overview]
Message-ID: <CABHetKw2n7MHb-u-RjA89zwO4+VE+cJMY9Bc5h1tBptrhzgrmw@mail.gmail.com> (raw)
In-Reply-To: <dVxjcXpVSms-352cXBUbHI893qnlQ7uuF8V9dER5-MgWc2dgXecGCUu1TMIF8z3m_hWUvtAnILxGpcQlV_KIMdUS2D-UCCf24N8JIOTnpS4=@protonmail.com>

On Sat, Jan 28, 2023 at 7:58 AM alicexbt <alicexbt@protonmail.com> wrote:
>
> 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.

I fully agree with this too. It was a sloppy remark on my part--
thanks for claifying. Underlying my remark was a bit of disgust from
knowing that in the future, a (perhaps large) X number of GB of what
should have been financial data will actually turn out to be something
else entirely. Time/space on the Bitcoin blockchain is a shared
limited resource and should be treated accordingly. We can say "no
worries...the price and demand will sort everything out," but
hopefully we all want Bitcoin to be the best financial tool it can be.

“If the ax is not sharp and he does not make it sharp, then he must
use more strength. Wisdom helps one to do well.”


  reply	other threads:[~2023-01-29 10:35 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
2023-01-29 10:34     ` Robert Dickinson [this message]
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=CABHetKw2n7MHb-u-RjA89zwO4+VE+cJMY9Bc5h1tBptrhzgrmw@mail.gmail.com \
    --to=robert.lee.dickinson@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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