Topic: NFTs in the Bitcoin blockchain - Ordinal Theory (Read 9138 times)

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.

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.

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

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.

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.

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.

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

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

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.


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.