From: vjudeu@gazeta•pl
To: Casey Rodarmor <casey@rodarmor•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinals BIP PR
Date: Mon, 20 Nov 2023 23:20:46 +0100 [thread overview]
Message-ID: <196446418-e1135f5da0a7baa7dc932feecf123170@pmq3v.m5r2.onet> (raw)
[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]
> I've commented a few times asking the BIP editors to let me know what is needed for the BIP to either be merged or rejected.
I would accept it, if each Ordinal would require including OP_RETURN at the beginning of the TapScript, to prevent them from being pushed on-chain. In that case, they could still be moved by a single Schnorr signature. Or, even better, creating a new Ordinal should not require sending them to Taproot at all, but just the R-value of a signature, from any address type, should be sufficient to make a commitment.
Which means, if some user has some legacy address, then it should be possible to sign a regular transaction, and then, R-value of that signature could contain some Ordinal.
Also, Ordinals should support scanning the chain in a similar way as Silent Payments could do. Which means, users should not be forced to upload data, if they were already uploaded in a different form. For example, there was a user, trying to upload the whitepaper, even though it was already done, and it was wrapped in a multisig in some old transaction. Which means, Ordinals should allow scanning the chain, and discovering old data, without reinventing the wheel, and forcing users to post that data again on-chain.
Another thing to address is the content of each Ordinal: some people tried to create something like NFT. In that case, the uniqueness should be enforced. And by scanning the chain for similar data, it should note that "hey, the whitepaper was already pushed by someone, in a multisig, long time ago", so the Ordinals protocol should prevent users from uploading the same data again, and again. Because in some use cases, like NFTs, it could be misleading.
[-- Attachment #2: Type: text/html, Size: 1792 bytes --]
next reply other threads:[~2023-11-20 22:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-20 22:20 vjudeu [this message]
2023-11-21 12:13 ` Kostas Karasavvas
-- strict thread matches above, loose matches on Subject: below --
2023-11-21 23:10 vjudeu
2023-11-22 11:27 ` 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=196446418-e1135f5da0a7baa7dc932feecf123170@pmq3v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=casey@rodarmor$(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