public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Kostas Karasavvas <kkarasavvas@gmail•com>
To: vjudeu@gazeta•pl
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinals BIP PR
Date: Wed, 22 Nov 2023 13:27:03 +0200	[thread overview]
Message-ID: <CABE6yHsstgUBTC+5FU+LiHMTAkLJDCynNthCRosOBjpAAS1-MA@mail.gmail.com> (raw)
In-Reply-To: <196658683-e78610e544d8c89fc4432671990127cb@pmq1v.m5r2.onet>

[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]

On Wed, Nov 22, 2023 at 1:11 AM <vjudeu@gazeta•pl> wrote:

> > Since it is spent it does not bloat the mempool.
>
> This is not the case. If you post some 100 kB TapScript, with some
> Ordinal, then it of course bloats mempools, because then other users could
> post 100 kB less, when it comes to regular payments. If you have Ordinals
> in the current form, then they take place of regular payments. Which means,
> you can include some payment, or some data. You cannot include both,
> because you can produce 4 MB block per 10 minutes. It is always a choice:
> confirm this payment, or confirm that data.
>
>

I meant the UTXO set, not the mempool. But still, even for the mempool,
since tx fees are paid I don't see it as bloat. It is competing with the
other txs and won. The bloat is of course in storage since the blocks are
'fuller' with ordinals... but that is the whole point of ordinals (see
below).


> > Regardless of OP_RETURN the data will be on chain. What am I missing?
>
> If you have regular OP_RETURN, the data is pushed on-chain. However, if
> your OP_RETURN is part of your TapScript, then you cannot provide any valid
> input to satisfy that kind of TapScript, so it cannot be pushed on-chain.
> Which means, you have to use another TapScript branch, without OP_RETURN,
> or simply spend by key. Note that regular OP_RETURNs are placed in
> transaction outputs, but in that case, TapScript is revealed in transaction
> input (and to be more specific, in the witness part), which prevents from
> posting a commitment on-chain, if it contains OP_RETURN at the beginning of
> the TapScript.
>

I see, thanks.


> > If there was no need for people in this list to discuss it before I
> don't see why a BIP is needed now.
>
> It is needed, but for a different reason. There should be a BIP, but not
> to promote Ordinals, but to handle them properly, and to provide regular
> users a way, to compete with the currently posted Ordinals, in this
> fee-based competition. Which means, regular users should have a way, to
> turn their Ordinals into proper commitments. They should be hidden behind
> some R-value, instead of being posted as a TapScript, and fully revealed in
> the witness. That would make it smaller, cheaper, and will provide more
> room for more regular payments, while preserving the strong cryptographical
> proof, that a given data is connected with a given transaction input.
>
> Also, it would allow them to be uncensorable, because then users could
> decide to hide any Ordinal behind their signature, in any address type (it
> works even on P2PK), and then reveal it later, but not on-chain, to not
> take a room of other regular payments. In general, transactions should
> always contain payments, and Ordinals could be attached as a feature, and
> not the other way around, when the actual payment is just a feature to be
> discarded, and the posted data is what people care about. Bitcoin is a
> payment system first, and not a P2P cloud storage, so it should work as
> "always a payment, and optionally also an Ordinal", and not "just a data
> push, and unfortunately a payment, because the protocol forced us to
> include some satoshis".
>

The whole point of ordinals is supposed to have the data on-chain (the
ordinals team can correct me). You are not suggesting merely a technical
design change, you are suggesting a completely different design and
business logic, which I believe would never be accepted by the ordinals
team*, and thus no point for this BIP now. We'll just have to wait for
their reply and see.

* This is fair game for a new competing project. However, the 'on-chain'
part is the main ordinals selling point so a new project would not even be
competing.

[-- Attachment #2: Type: text/html, Size: 4594 bytes --]

  reply	other threads:[~2023-11-22 11:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-21 23:10 vjudeu
2023-11-22 11:27 ` Kostas Karasavvas [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-11-20 22:20 vjudeu
2023-11-21 12:13 ` Kostas Karasavvas
2023-10-23 14:57 Léo Haf
2023-10-23 17:26 ` Ryan Breen
2023-10-21  5:38 Casey Rodarmor
2023-10-23 13:45 ` Andrew Poelstra
2023-10-23 15:35 ` Peter Todd
2023-10-23 16:32   ` Tim Ruffing
2023-10-26 22:05     ` Peter Todd
2023-10-23 17:43   ` Andrew Poelstra
2023-10-23 18:29     ` Luke Dashjr
2023-10-24  1:28       ` alicexbt
2023-10-24 22:56       ` Olaoluwa Osuntokun
2023-10-24 23:08         ` Christopher Allen
2023-10-25  0:15         ` Luke Dashjr
2023-10-26 22:11         ` Peter Todd
2023-10-27  9:39           ` Alexander F. Moser
2023-10-27 17:05           ` alicexbt
2023-11-09  2:15       ` Casey Rodarmor
2023-11-09 22:32         ` Claus Ehrenberg

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=CABE6yHsstgUBTC+5FU+LiHMTAkLJDCynNthCRosOBjpAAS1-MA@mail.gmail.com \
    --to=kkarasavvas@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=vjudeu@gazeta$(echo .)pl \
    /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