NFTs in the Bitcoin blockchain - Ordinal Theory

[Wind_FURY]

--snip--

It's obviously wrong, Ordinals TX has size more than 0.

I didn't say Ordinals transaction size isn't zero. I said technically it isn't a waste in block space. Why? Because the data isn't embedded within the structure where the UTXO set is stored. It goes to the structure of the block where witness data are stored, which is prunable.

1. While it's true you can prune witness data, AFAIK there's no full node which let you do that.
2. It's still waste of block size since Ordinals TX has size more than 0. Possibility of pruning witness data actually means it's not waste of storage space.

The point is Ordinals embeds data in the structure of the blocks that store witness data, not the part of the block where the UTXO set resides. In that context, I don't know what's "wasted" because none of the embedded data is "stealing" space from actual Bitcoin transactions. Plus as a consensus rule, the block size is regulated up to 4MB. It's allowed to be that large.

But Bitcoin Stamps is something different, and it should be more concerning in my opinion.

It's definitely more concerning, although it's easier to make such TX become non-standard.

Does making them non-standard come with a hard fork?

[1714635407]

1714635407

[1714635407]

1714635407

[1714635407]

1714635407

[1714635407]

1714635407

[1714635407]

1714635407

[ABCbits]

--snip--

1. While it's true you can prune witness data, AFAIK there's no full node which let you do that.
2. It's still waste of block size since Ordinals TX has size more than 0. Possibility of pruning witness data actually means it's not waste of storage space.

The point is Ordinals embeds data in the structure of the blocks that store witness data, not the part of the block where the UTXO set resides. In that context, I don't know what's "wasted" because none of the embedded data is "stealing" space from actual Bitcoin transactions. Plus as a consensus rule, the block size is regulated up to 4MB. It's allowed to be that large.

What? There's no part of block dedicated to store UTXO set. UTXO set is created by your full node. As a reminder, SegWit and Taproot TX include data classified as witness data.

It's definitely more concerning, although it's easier to make such TX become non-standard.

Does making them non-standard come with a hard fork?

No, it only requires node operator update their node software which doesn't relay non-standard TX. But miner could include those non-standard TX on their block and deemed valid by other node.

[Wind_FURY]

--snip--

1. While it's true you can prune witness data, AFAIK there's no full node which let you do that.
2. It's still waste of block size since Ordinals TX has size more than 0. Possibility of pruning witness data actually means it's not waste of storage space.

The point is Ordinals embeds data in the structure of the blocks that store witness data, not the part of the block where the UTXO set resides. In that context, I don't know what's "wasted" because none of the embedded data is "stealing" space from actual Bitcoin transactions. Plus as a consensus rule, the block size is regulated up to 4MB. It's allowed to be that large.

What? There's no part of block dedicated to store UTXO set. UTXO set is created by your full node. As a reminder, SegWit and Taproot TX include data classified as witness data.

Pardon me, I try to learn but I'm not very technical, but I believe you already knew what I was trying to say, that those dick pics and fart sounds in Ordinals are not embedded in the part of the block where the transactions reside if a user sends Bitcoin. They go to the part of the block where the witness data reside.

It's definitely more concerning, although it's easier to make such TX become non-standard.

Does making them non-standard come with a hard fork?

No, it only requires node operator update their node software which doesn't relay non-standard TX. But miner could include those non-standard TX on their block and deemed valid by other node.

Technically, from the viewpoint of the Bitcoin network with the current consensus rules, are Bitcoin Stamps "non-standard" transactions?

[garlonicon]

They go to the part of the block where the witness data reside

There is one problem: there is no other space than witness. You have 1 MB non-witness limit or 4 MB witness limit. Which means, if you create a transaction with 100 kB witness, then it means, you take a space, which could be taken by 25 kB regular data, in a plain, old, 1 MB block limit, or you can take 100 kB witness of another transactions, used for regular payments.

Which means: there is always a choice: confirm this Ordinal, or confirm this regular payment. It is not "1 MB non-witness plus 3 MB witness-only". It is just "4 MB witness", which means, every four bytes of witness, just take the space of one byte of non-witness, which could be there.

Also, note that the famous "almost 4 MB ordinal transaction" included in block 774628, took a lot of space from regular transactions. Note that this particular block has only 63 transactions! Which means, there is no separation, like "witness here, and non-witness there". Because everything is counted into "4 MB witness limit".

Edit:

There's no part of block dedicated to store UTXO set. UTXO set is created by your full node. As a reminder, SegWit and Taproot TX include data classified as witness data.

Exactly. The ability to create and spend UTXOs didn't change with Segwit. You still need to specify transaction inputs and outputs in a "legacy 1 MB" space. Which means, if you assume that all outputs are just set to OP_TRUE, and all inputs are just empty, then you can count the maximum amount of UTXOs, which could be consumed and created within a block. And this value is identical for Segwit and legacy.

Unless you put the whole transaction inside the witness, but then, it means a single "coin" is used by more than one user (which means for example N-of-N multisig, behind a single UTXO). But of course, Ordinals do not help there, instead they make things worse, because they fill blocks with data, which could be evaluated always into a huge OP_NOP, and which take the space of regular payments, that could be handled instead.

[Wind_FURY]

They go to the part of the block where the witness data reside

There is one problem: there is no other space than witness. You have 1 MB non-witness limit or 4 MB witness limit. Which means, if you create a transaction with 100 kB witness, then it means, you take a space, which could be taken by 25 kB regular data, in a plain, old, 1 MB block limit, or you can take 100 kB witness of another transactions, used for regular payments.

Which means: there is always a choice: confirm this Ordinal, or confirm this regular payment. It is not "1 MB non-witness plus 3 MB witness-only". It is just "4 MB witness", which means, every four bytes of witness, just take the space of one byte of non-witness, which could be there.

Also, note that the famous "almost 4 MB ordinal transaction" included in block 774628, took a lot of space from regular transactions. Note that this particular block has only 63 transactions! Which means, there is no separation, like "witness here, and non-witness there". Because everything is counted into "4 MB witness limit".

Edit:

There's no part of block dedicated to store UTXO set. UTXO set is created by your full node. As a reminder, SegWit and Taproot TX include data classified as witness data.

Exactly. The ability to create and spend UTXOs didn't change with Segwit. You still need to specify transaction inputs and outputs in a "legacy 1 MB" space. Which means, if you assume that all outputs are just set to OP_TRUE, and all inputs are just empty, then you can count the maximum amount of UTXOs, which could be consumed and created within a block. And this value is identical for Segwit and legacy.

Unless you put the whole transaction inside the witness, but then, it means a single "coin" is used by more than one user (which means for example N-of-N multisig, behind a single UTXO). But of course, Ordinals do not help there, instead they make things worse, because they fill blocks with data, which could be evaluated always into a huge OP_NOP, and which take the space of regular payments, that could be handled instead.

TIL, thank you!

OK, then for my next question. I may already know the answer, but I would like to hear it from people smarter than me.

- If there isn't truly any separation for witness data and non-witness data, then does that mean that making the block size larger, let's make "triple" the current size, won't truly help the network if the demand for block space increases as well?

What it might actually do is encourage more developers to inscribe and mint BRC-20 tokens and NFTs.

Because, there are some users that are suggesting that they want a block size increase under the display of "It's merely a joke, bro".

[garlonicon]

If there isn't truly any separation for witness data and non-witness data, then does that mean that making the block size larger, let's make "triple" the current size, won't truly help the network if the demand for block space increases as well?

Exactly.

1. If you want to increase maximum block size from 4 MB witness into 12 MB "second witness", then you need another soft-fork, if you want to have that data processed, and stored by every single full node (because if not, then it is easy, and you can have "unlimited commitments", that would be recognized only by upgraded nodes, and nobody else).

2. If you would have for example 12 MB "second witness", then each block would still have "1 MB legacy" limit, which means, if you can consume M UTXOs, and create N UTXOs on average, within a 4 MB witness, then that value will not increase in case of 12 MB "second witness", or even 1 GB "second witness", because all UTXOs are consumed and created in a "1 MB legacy" section, which means, that all non-Segwit nodes, still need to get that information in a backward-compatible way.

What it might actually do is encourage more developers to inscribe and mint BRC-20 tokens and NFTs.

If someone really want that functionality, then it is better to use commitments, than to push those data on-chain. Which means, if you have any signature, then you can convert R-value of that, into a matching Taproot address, and then upgraded nodes can store commitments to that data. Then, it is cheaper, and it is enforced by consensus rules in the same way, because Ordinals are just huge OP_NOPs, which means, you only need a matching connection between your data, and a particular address. And you don't need to push that data on-chain, to reach such connection. And also, moving things from TapScript into "any signature" means, that people could use those features on all address types, where OP_CHECKSIG is available, including altcoins like Grin.

Because, there are some users that are suggesting that they want a block size increase under the display of "It's merely a joke, bro".

I guess many people didn't try to change witness factor from 4 into 12 or anything bigger, and check, what is the final outcome of changes like that. Because I guess they think about it as "1 MB legacy + 3 MB witness", but this is not the case.

Edit: Also, in case of commitments, it is really "4 MB witness + unlimited commitments", which is what some people want, so I don't understand, why they don't want to implement it in that way, and they want block size increase instead.

[nutildah]

It appears that there are some efforts being made to take BRC-20 to the 2nd layer:

https://twitter.com/BRC20com/status/1745477227636982253

Some data will still be settled on L1 but this is a great initiative which is driven by a couple of factors:

1. fees
2. the need to perform advanced, virtual machine-type transactions that can't be done on L1.

This is hard to read but it further explains the thinking of our new bitcoin shittoken friends, for anyone who may be interested:

https://brc20.com/wiki/brc20-strategic-partnership-to-release-first-brc20-focussed-l2-ecosystem

[DooMAD]

It appears that there are some efforts being made to take BRC-20 to the 2nd layer:

https://twitter.com/BRC20com/status/1745477227636982253

Some data will still be settled on L1 but this is a great initiative which is driven by a couple of factors:

1. fees
2. the need to perform advanced, virtual machine-type transactions that can't be done on L1.

This is hard to read but it further explains the thinking of our new bitcoin shittoken friends, for anyone who may be interested:

https://brc20.com/wiki/brc20-strategic-partnership-to-release-first-brc20-focussed-l2-ecosystem

Welcome news.  This also lends credence to the notion that, rather than being a deliberate "attack", as some claim, this was largely just an inconsiderate use of resources.  A near-miss of a "Tragedy of the commons", if you will. 

If they're genuinely trying to make their usage more efficient, this should eventually bring some resolution to the conflict.  And is a far more constructive approach than looking to block or otherwise prevent people doing stuff.

[Medusah]

This also lends credence to the notion that, rather than being a deliberate "attack", as some claim, this was largely just an inconsiderate use of resources.

Surely if ordinal people switch to using this second layer, but until that happens, I would not be so sure.  If the layer is ready for production and they insist on transacting ordinals on the main layer, then that gives us a hint.

[Wind_FURY]

It appears that there are some efforts being made to take BRC-20 to the 2nd layer:

https://twitter.com/BRC20com/status/1745477227636982253

Some data will still be settled on L1 but this is a great initiative which is driven by a couple of factors:

1. fees
2. the need to perform advanced, virtual machine-type transactions that can't be done on L1.

This is hard to read but it further explains the thinking of our new bitcoin shittoken friends, for anyone who may be interested:

https://brc20.com/wiki/brc20-strategic-partnership-to-release-first-brc20-focussed-l2-ecosystem

Welcome news.  This also lends credence to the notion that, rather than being a deliberate "attack", as some claim, this was largely just an inconsiderate use of resources.  A near-miss of a "Tragedy of the commons", if you will. 

If they're genuinely trying to make their usage more efficient, this should eventually bring some resolution to the conflict.  And is a far more constructive approach than looking to block or otherwise prevent people doing stuff.

It obviously IS an inconsiderate use of resources, especially precious limited capital held in Bitcoin units. Although, the high fees that were paid to mint those NFT/BRC-20 were also good for the health of the network, because they were redistributed back to the Bitcoin economy through the miners selling those coins to pay for their expenses.

If BRC-20 users keep trying to sustain the unsustainable by sending more money into the Bitcoin economy, then that's absolutely good for the growth of the network.