public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Ordinals BIP PR
@ 2023-10-21  5:38 Casey Rodarmor
  2023-10-23 13:45 ` Andrew Poelstra
  2023-10-23 15:35 ` Peter Todd
  0 siblings, 2 replies; 22+ messages in thread
From: Casey Rodarmor @ 2023-10-21  5:38 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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

Dear List,

The Ordinals BIP PR has been sitting open for nine months now[0]. 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've also reached out to the
BIP editors via DM and email, but haven't received a response.

There has been much misunderstanding of the nature of the BIP process.
BIPS, in particular informational BIPs, are a form of technical
documentation, and their acceptance does not indicate that they will be
included in any implementation, including Bitcoin Core, nor that they they
have consensus among the community.

Preexisting BIPs include hard-fork block size increases, hard-fork
proof-of-work changes, colored coin voting protocols, rejected soft fork
proposals, encouragement of address reuse, and drivechain.

I believe ordinals is in-scope for a BIP, and am hoping to get the PR
unstuck. I would appreciate feedback from the BIP editors on whether it is
in-scope for a BIP, if not, why not, and if so, what changes need to be
made for it to be accepted.

Best regards,
Casey Rodarmor

[0] https://github.com/bitcoin/bips/pull/1408

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

^ permalink raw reply	[flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinals BIP PR
@ 2023-10-23 14:57 Léo Haf
  2023-10-23 17:26 ` Ryan Breen
  0 siblings, 1 reply; 22+ messages in thread
From: Léo Haf @ 2023-10-23 14:57 UTC (permalink / raw)
  To: Casey Rodarmor, Bitcoin Protocol Discussion

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

 BIPs such as the increase in block size, drives-chains, colored coins, etc... were proposals for Bitcoin improvements. On the other hand, your BIP brings absolutely no improvement, on the contrary it is a regression, but you already know that.

I strongly invite you to retract or if the desire continues to push you to negatively affect the chain, to create OIPs or anything similar, as far as possible from the development of Bitcoin and real BIPs that improve Bitcoin.

Léo Haf. 

> Le 23 oct. 2023 à 10:23, Casey Rodarmor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> a écrit :
> 
> Dear List,
> 
> The Ordinals BIP PR has been sitting open for nine months now[0]. 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've also reached out to the BIP editors via DM and email, but haven't received a response.
> 
> There has been much misunderstanding of the nature of the BIP process. BIPS, in particular informational BIPs, are a form of technical documentation, and their acceptance does not indicate that they will be included in any implementation, including Bitcoin Core, nor that they they have consensus among the community.
> 
> Preexisting BIPs include hard-fork block size increases, hard-fork proof-of-work changes, colored coin voting protocols, rejected soft fork proposals, encouragement of address reuse, and drivechain.
> 
> I believe ordinals is in-scope for a BIP, and am hoping to get the PR unstuck. I would appreciate feedback from the BIP editors on whether it is in-scope for a BIP, if not, why not, and if so, what changes need to be made for it to be accepted.
> 
> Best regards,
> Casey Rodarmor
> 
> [0] https://github.com/bitcoin/bips/pull/1408
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

^ permalink raw reply	[flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinals BIP PR
@ 2023-11-20 22:20 vjudeu
  2023-11-21 12:13 ` Kostas Karasavvas
  0 siblings, 1 reply; 22+ messages in thread
From: vjudeu @ 2023-11-20 22:20 UTC (permalink / raw)
  To: Casey Rodarmor, Bitcoin Protocol Discussion, Bitcoin Protocol Discussion

[-- 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 --]

^ permalink raw reply	[flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinals BIP PR
@ 2023-11-21 23:10 vjudeu
  2023-11-22 11:27 ` Kostas Karasavvas
  0 siblings, 1 reply; 22+ messages in thread
From: vjudeu @ 2023-11-21 23:10 UTC (permalink / raw)
  To: Kostas Karasavvas, Bitcoin Protocol Discussion

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

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

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2023-11-22 11:27 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-21  5:38 [bitcoin-dev] Ordinals BIP PR 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
2023-10-23 14:57 Léo Haf
2023-10-23 17:26 ` Ryan Breen
2023-11-20 22:20 vjudeu
2023-11-21 12:13 ` Kostas Karasavvas
2023-11-21 23:10 vjudeu
2023-11-22 11:27 ` Kostas Karasavvas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox