On Ordinals: Where do you stand?

[d5000]

Problem 2 cannot be solved,[...]

what do you mean it can't be solved?

It seems you don't really read my posts "Problem 2" is the perception of Bitcoin as the original, most prestigious blockchain ("OG"). This is actually a good feature and generates network effect, and so there's no point in "solving" it. Or do you want BTC to become a shitcoin like all others? (There were several Bitcoin clones in the past that copied the code 1:1, so the code isn't the primary network effect generator).

It also has nothing to do with illegal content. If someone wants to publish illegal content, a certain amount of "prestige" of the blockchain is normally not needed and can even be harmful if the content is meant to be a bit "hidden". "Prestige" is needed if you want to sell a NFT for the highest possible price. So they are different "problem classes". There may be exceptions, (a dumb example: let's say a whistleblower publishes a classified file of all Ukrainian defense positions on an Ordinals inscription and chooses BTC for it, just to get maximum publicity), but normally the "prestige" and "illegal content" problems are not linked.

Your "proposal" is simply censorship, and such a feature could be mis-used for all type of other censorship. Miners could, however, control inscriptions themselves, which would of course be ideal but I don't think it will work consistently. Thus I believe "Notify and take down" is a better approach, but difficult to achieve inside of the main chain (i.e. once we try to implement something like "completely ignorable OP_RETURN messages", de facto it becomes a kind of sidechain).

Your solution to 1st problem will not work. Various OP_RETURN[1] and sidechain based NFT already exist long time ago, but has very small userbase. In addition, Casey Rodarmor also state NFT user strongly prefer content stored on-chain due to various reasons[2].

I'm of course aware of coloured coins, but is there a non-federated sidechain specialized in data in operation (Bitcoin-based, of course)? I'm not aware of one, but maybe a platform like Counterparty offers such a feature ... Data sidechains don't need 2-way pegs, so they are much easier to implement than "financial" sidechains. The "novelty" would be it to be a real "chain", i.e. not only hashes in OP_RETURN pointing to distinct locations (like IPFS).

I'm also skeptic that a single measure would work. Thus what I would propose is a "battery of measures" for an "incentive framework" like I called it last page: new witness discounts for financial and small data txes, making Ordinals more expensive, in addition to a data sidechain, to achieve that there are always several alternatives for NFT lovers and the "hack" Ordinals being one of the most expensive ones.

PS: Have read Casey's post on bitcoin-dev, and I think the "data sidechain" could solve some of the problems of non-on-chain-stored NFTs he mentions, for example the bad protection of NFT buyers. My other idea - let BTC ordinal satoshi "series numbers" point to an altcoin-storage, e.g. on NMC or LTC - would also work, but would be perhaps more complex.

[1714482841]

1714482841

[franky1]

guys you dont need to even use op_return to make a viable NFT system of timestamped hash proofs

plus op_return outputs do not enclose that op_return output to a keypair to allow it to prove which NEW owner owns it when it gets transferred

op_returns and witness area junk are both just timestamped storage locks of data. not proof of transfer systems

[larry_vw_1955]

Someone already attempt that by creating PR to support BitTorrent hash/magnet link[3]. But even if this PR is merged, i expect only small user would include BitTorrent magnet link instead since many NFT user prefer storing data on-chain[2].

just storing a commitment to the monkey and then the actual monkey on bitttorrent seems like a step backwards. that would be a real waste of money if someone needs data permanence.

It also has nothing to do with illegal content. If someone wants to publish illegal content, a certain amount of "prestige" of the blockchain is normally not needed and can even be harmful if the content is meant to be a bit "hidden". "Prestige" is needed if you want to sell a NFT for the highest possible price. So they are different "problem classes". There may be exceptions, (a dumb example: let's say a whistleblower publishes a classified file of all Ukrainian defense positions on an Ordinals inscription and chooses BTC for it, just to get maximum publicity), but normally the "prestige" and "illegal content" problems are not linked.

i'm really not understanding what you're trying to say. i guess i need it dumbed down a bit. if someone is publishing illegal content to the bitcoin blockchain, they want it to be seen. that's the entire point of doing it most likely. because they got tired of having other services removing it...why would someone want their illegal nfts to be hidden that doesn't make any sense. if they want it hidden they would encrypt it.

Your "proposal" is simply censorship, and such a feature could be mis-used for all type of other censorship. Miners could, however, control inscriptions themselves, which would of course be ideal but I don't think it will work consistently. Thus I believe "Notify and take down" is a better approach, but difficult to achieve inside of the main chain (i.e. once we try to implement something like "completely ignorable OP_RETURN messages", de facto it becomes a kind of sidechain).

there's no way miners can fulfill that roll since they don't have time to do a complete inspection of the transactions because their time is dedicated to finding the right hash. anything that slows that down they can't do that.

[d5000]

if someone is publishing illegal content to the bitcoin blockchain, they want it to be seen. that's the entire point of doing it most likely. because they got tired of having other services removing it...why would someone want their illegal nfts to be hidden that doesn't make any sense. if they want it hidden they would encrypt it.

Well I try to explain again ...

First, why would you choose Bitcoin for your NFT and not, for example, Litecoin? Because a Bitcoin NFT could be probably sold for a higher price. So in this case, it makes some sense to use BTC and not an altcoin.

But now let's have the case of illegal content "they got tired of having other services removing it". The classic example is child abuse imagery or other kinds of illegal pornography. Why should you publish it on BTC and not on LTC? On both chains it's accessible for their "group", i.e. those wanting to see it, but LTC is far cheaper, there you could even store high-definition images for a modest price. It would make even more sense from the point of view of these criminals to store this content on a shitcoin on position 1000 on Coinmarketcap, because it would be even much cheaper and they could share it in their groups, but nobody outside of their groups probably would ever notice it because these coins run "under the radar" of almost everybody in the crypto community. It's accessible for this group but quite "hidden" ... that's what I meant with hidden, not something "encrypted".

I don't think this kind of criminal group (illegal porn uploaders) had any advantage publishing content on the "expensive" Bitcoin. Bitcoin would more in danger for illegal content that gives somebody some kind of "prestige" or "attention", like military classified information. But even for this group of "illegal uploaders" I think something like LTC would be a better choice, for example for a large classified e-mail leak or a map with exact positions of defenders in a war, like the (hypothetic) Ukraine example I mentioned.

But this is one of the examples where I think that the uploader doesn't need Ordinals. If you have such important information and are willing to pay for it, 15% more (with a non-Ordinal technique) would not stop you.

there's no way miners can fulfill that roll since they don't have time to do a complete inspection of the transactions because their time is dedicated to finding the right hash. anything that slows that down they can't do that.

There would have to subscribe probably to a kind of filtering service, like those employed by social media companies.  That would not be the problem, but probably not all miners would want that, and so from time to time some illegal file could pass through these controls. It would not be reliable.

[larry_vw_1955]

I don't think this kind of criminal group (illegal porn uploaders) had any advantage publishing content on the "expensive" Bitcoin. Bitcoin would more in danger for illegal content that gives somebody some kind of "prestige" or "attention", like military classified information. But even for this group of "illegal uploaders" I think something like LTC would be a better choice, for example for a large classified e-mail leak or a map with exact positions of defenders in a war, like the (hypothetic) Ukraine example I mentioned.

and you may be right. but i'm not sure everyone trusts litecoin or even knows it has ordinals. everyone knows about bitcoin though. then you got people that might upload their junk to everywhere they can find. no stopping at just one blockchain for them!

There would have to subscribe probably to a kind of filtering service, like those employed by social media companies.  That would not be the problem, but probably not all miners would want that, and so from time to time some illegal file could pass through these controls. It would not be reliable.

so you're saying instead of going straight into the mempool they have to go first to some type of staging node that all the transactions get visually checked to see if there's any naked monkeys mixed in with the more appropriate clothed ones? that would kind of require human intervention but i guess it could be doable but it would add on a delay to every transaction. maybe it wouldn't even require human intervention if AI could look at an image and make that decision. but that would require a change to how bitcoin works.

[franky1]

there's no way miners can fulfill that roll since they don't have time to do a complete inspection of the transactions because their time is dedicated to finding the right hash. anything that slows that down they can't do that.

miners(asics) dont touch or see transactions. they just hash a hash repeatedly
its the mining POOL managers that collate(decide) which transactions get into a block template. and in real world law "ignorance is not a defence"

mining pool managers would not let illicit porn into their block template because in real world law it makes them liable of "distributing illicit material"

mining pool managers can get away with adding transactions from sanctioned russians because transactions contain no identity thus there is no way to know.. this is not ignorance. this is absence of available information...
.. however mining pools are able to identify illicit porn images thus accepting such but deciding not to look. is IGNORING certain activity they can do.

so far honest pools are refusing to ad illicit porn. .. you know.. morals..
.. but it only takes one malicious mining pool manager to want to screw with the network to do it. and cause everyone to be distributing illicit content

There would have to subscribe probably to a kind of filtering service, like those employed by social media companies.  That would not be the problem, but probably not all miners would want that, and so from time to time some illegal file could pass through these controls. It would not be reliable.

so you're saying instead of going straight into the mempool they have to go first to some type of staging node that all the transactions get visually checked to see if there's any naked monkeys mixed in with the more appropriate clothed ones? that would kind of require human intervention but i guess it could be doable but it would add on a delay to every transaction. maybe it wouldn't even require human intervention if AI could look at an image and make that decision. but that would require a change to how bitcoin works.

transactions go into mempools of majority of nodes.
and mining pool managers filter which transactions they decide to put into a block

its hard to filter illicit material at the relay(unconfirmed) phase. but it is very possible and easy to filer what transactions/material gets put into blocks permenently

mining pools are the "staging node" you speak of in regards to stopping illicit porn getting into blocks

pools dont add transactions to blocks in milliseconds. there is already is a 10min average delay between mempool entry vs block entry

an average meme/image is 100k-4mb meaning viewing 1-40 images per 10 minutes is not a delay

normal transactions without these crap memes can be auto added using algo's.. where its the crap memes that can be delayed by several blocks if a honest mining pool wants to keep the blockchain clean of illicit material

again mining pools have the capability to audit transactions. and ignoring such capability is ignorance. and not a defence in court.

bitcoin has rules and accountability. thats what makes/made bitcoin better then the digital cash idea's pre 2009(pre bitcoin)

it is pools job to ensure what goes into blocks meets the rules. that includes laws and moral content

[Wind_FURY]

I believe proposals for another soft fork would open a new debate/drama within the community, which will make us split/divide further again. One group will be Ordinals users/supporters and most of the miners/mining-pools, the other group will be Bitcoin purists and probably most of the Core developers.

A fork is a bad idea because it would prevent future extensions to Taproot (witness version 1) which is the reason why this mess was allowed in first place. Not to mention that forks take a very long time to reach consenesus.

As I've said many times the correct solution should have been using standard rules to prevent this type of spam like what we have been doing all these years!
You see Ordinals attack could have happened before Taproot too but it was successfully prevented by standard rules. But after Taproot for some unknown reason the devs decided to not add any standard rules when verifying Taproot scripts (eg. a DISCOURAGE_BIG_SCRIPTS flag) and we are seeing this unwanted attack vector...

Plus it's not only about going through another controversial soft fork/hard fork, it's d5000's proposal of making a new fee structure itself! He is proposing to make a crapshoot with the part of the network that's making everything stick together. I'm stupid when it comes to programming/technical matters, but I know that's not the solution.

[franky1]

to fully enforce a fee mechanism to scare(not completely stop) meme bloat requires enforcing full node compliance to reject blocks that contain transactions that dont honour the fee mechanism, which can cause forks
yet meme bloat have other tricks to pay less than the average so even with such enforcement it wont completely stop them


however to stop meme bloat from entering future blocks, doesnt require or cause forks.
it can use the same soft consensus trick(no fork) that allowed the bloat. but in reverse to stop the bloat memes continuing to enter.. while still allowing taproot

a 80byte limit is within range of 4mb limit. thus not a block forking just a tx not entering a block thing. thus no fork
its simply hardening the rules again. (undoing the exploit) to prevent future spam

also preventing future spam by hardening consensus again does not put a stop to any new feature activations.. instead it just ensures any new feature activations are ready to activate before activation. rather then slide in a feature and then have every race to then be ready...
in short it stops new exploits from just finding their way in unverified

[garlonicon]

a 80byte limit is within range of 4mb limit. thus not a block forking just a tx not entering a block thing. thus no fork

It will make some Segwit transactions non-standard. They use DER encoding in signatures, so a 2-of-2 multisig for some P2WSH address will contain more than 80 bytes. And even if you assume N-of-N Taproot address, then still, in case of identical sighash, signatures can be combined. But when they use different sighashes, for example one signature has SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, and another signature has SIGHASH_ALL, then you cannot combine them, you need a separate signature for each sighash, so by limiting that to 80 bytes, you will make it harder for normal use cases.

[franky1]

a 80byte limit is within range of 4mb limit. thus not a block forking just a tx not entering a block thing. thus no fork

It will make some Segwit transactions non-standard. They use DER encoding in signatures, so a 2-of-2 multisig for some P2WSH address will contain more than 80 bytes. And even if you assume N-of-N Taproot address, then still, in case of identical sighash, signatures can be combined. But when they use different sighashes, for example one signature has SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, and another signature has SIGHASH_ALL, then you cannot combine them, you need a separate signature for each sighash, so by limiting that to 80 bytes, you will make it harder for normal use cases.

we are not talking about segwit
we are talking about the particular opcode specific to the taproot subclass of opcodes that allowed the meme bloat
remember taproots promise "one signature length"

[garlonicon]

remember taproots promise "one signature length"

Only when all parties agree. But if not, then there should be a way to use TapScript. And limiting that to 80 bytes will cut some legitimate use cases, when someone prepared a separating spending conditions, and suddenly it will be non-standard.

Also, how do you want to get a single signature for different sighashes, when z-value to be signed is different for each sighash?

Another thing is that going only three branches deep in a TapScript tree will give you 3*32=96 bytes, so that tree will be very limited, then you will basically force people to switch from P2TR back into P2WSH, and put the whole Script (if you push those limits only on Taproot), or you force them into splitting the Script into multiple transactions, to do any multisig with more than one sighash.

[franky1]

first of all. people like you act as if there is only 2 ways: overly restricted or extreme looseness

however there are other ways in between
looseness but with refined expectations where nodes and transactors can have certain expectations of each other depending on methods of use

do you really think that all taproot subclass of opcodes need upto4mb space for one instance..
no

you also think that code cant make rules so code has to be made to provide looseness/softness to the extremes.
it does not
it can refine space in one part and refine other space in another part where it actually flags which part it wants to use when it uses it. where by the flag then shows the node what to be looking out for and what to expect. rather than a "accept everything unchallenged"

[pooya87]

we are not talking about segwit
we are talking about the particular opcode specific to the taproot subclass of opcodes that allowed the meme bloat
remember taproots promise "one signature length"

It is not a particular OP code that allows this, it is the fact that standard rules weren't written to place a limit on the Taproot script witness size to prevent this type of attack otherwise the junk is being pushed to the stack using a simple Pushdata OP.

As for one signature that you keep repeating, you are confusing Schnorr and the changes it applied to multi-sig with Taproot.

[franky1]

we are not talking about segwit
we are talking about the particular opcode specific to the taproot subclass of opcodes that allowed the meme bloat
remember taproots promise "one signature length"

It is not a particular OP code that allows this, it is the fact that standard rules weren't written to place a limit on the Taproot script witness size to prevent this type of attack otherwise the junk is being pushed to the stack using a simple Pushdata OP.

As for one signature that you keep repeating, you are confusing Schnorr and the changes it applied to multi-sig with Taproot.

taproot has opened up a whole new set of new underclass opcodes.
some do require specific stuff or will fail.. some dont

the ones that dont have any expections assigned to them should be tightened and refined to expect what is expected
EG the opcode these ordinal spam are using should be made to expect some kind of signature script or byte length

usually people cry if i was to explain every single opcode of every feature of every generation of subclass just to then only need to explain one instance/usecase..
so i usually dumb things down to only speak of one instance

but you want the lengthy one (i expect cry babies responding)
pre segwit there were 16 opcodes and only 1 with a no expectations. where others did have expectations. but in the years prior the 'no expectation limit' opcode was not really used for multiple reasons... (anyonecanspend)

when segwit activated by using that unused opcode..  it came with its own subclass of opcodes where again most were set to limits but left one limitless/expectationless. but no one really used it for multiple reasons

and now taproot by using that unused sub opcode. SHOULD HAVE come with limitations/expectations for majority of taproot opcodes and where one opcode to be used for next generation tx formats goes UNUSED/deactivated until the next consensus activation of a new feature
.....
as for the one sig length promo
the devs PROMOTING taproot were the ones PROMOTING one sig length
not me

yes i agree. the one siglength is not a taproot thing.. AS PROVEN BY THE LACK OF SUCH FRIGGEN rule

blame them for mis promoting because they were the ones saying it was all part of taproot

where by they were even saying crap like

"no one will be able to tell if its taproot or normal segwit"
a lie because segwit is BC1Q and taproot is BC1P
you can spot a taproot without even trying

many lies were said to promote taproot and look where its ended up
i usually learn everything there is to learn and then on the forum dumb things down to ELI-5 for readers of the forum

but if you want a slightly more techno buzzword filled explanation:
taproot has its own class of opcodes
it has its own version of checkmultisig which in taproot is called checksigadd
you cant use a old class opcode checkmultisig in tapscript and cant use a tapscript opcode in legacy

ordinal spam is not put into a checksigadd opcode of taproot because that opcode expects signatures. not random bloat.
ordinal spam uses another opcode called opsuccess
there is more then one and these should not be used/active unless a new feature is activated where expected functions are ruled into that opcode by activation

the softening of consensus has allowed an exploit to allow utility of opcodes with no expected rule

tightening consensus again can plug the hole

[garlonicon]

however there are other ways in between

Yes, but your proposal of 80 bytes limit for witness is not a way "in between". It is a way to block the whole TapScript, or a significant part of it. Each Schnorr signature has 64 bytes as the bare minimum, (r,s) pair of the signature with SIGHASH_DEFAULT. Then, you can do the math and see that 80-64=16. So, what can be done with a signature and 16 bytes? Much less than needed, so people will move from P2TR to other output types, and then they will use more space for normal use cases, because then they cannot build a TapScript tree like "use this path or that path", older scripts require pushing all conditions every time.

do you really think that all taproot subclass of opcodes need upto4mb space for one instance..
no

Of course not. But if I can see Segwit usage with more than 80 witness bytes for regular use cases, then I doubt Taproot usage with that limit will cover those. Even the simple push to the stack has 520 byte limit, not 80.

[franky1]

however there are other ways in between

Yes, but your proposal of 80 bytes limit for witness is not a way "in between". It is a way to block the whole TapScript, or a significant part of it. Each Schnorr signature has 64 bytes as the bare minimum, (r,s) pair of the signature with SIGHASH_DEFAULT. Then, you can do the math and see that 80-64=16. So, what can be done with a signature and 16 bytes? Much less than needed, so people will move from P2TR to other output types, and then they will use more space for normal use cases, because then they cannot build a TapScript tree like "use this path or that path", older scripts require pushing all conditions every time.

no its not

you need to understand the opcodes better
the one that the ordinal spam uses can be limited without harming the ones that other taproot functions use

[d5000]

you got people that might upload their junk to everywhere they can find. no stopping at just one blockchain for them!

But again, if Bitcoin is under these blockchains, they would have to pay a high fee.

so you're saying instead of going straight into the mempool they have to go first to some type of staging node that all the transactions get visually checked [...] that would require a change to how bitcoin works.

No, it would not need any change. That would all be done by the miners. The miners send each tx they see in the mempool with non-financial data in it (and perhaps a certain size) to the filtering service, which may operate with humans or AI (most likely mostly with AI but with humans for a second opinion in edge cases, like Facebook etc. do it). The filtering service gives them an "OK" or "NotOK". Only then, they include it into their blocks. This would have the effect that large Ordinals inscription transactions would be often delayed at least one block, but that would make "pure financial transactions" go through faster.

RSK probably farthest thing from federated/centralized Bitcoin side-chain. I know it rely on Bitcoin merge mining for it's security, but i don't know how decentralized is it.

RSK was still mostly based on the "federation" concept - although with some improvement - in it when I last looked into it. The most decentralized I'm aware of are Stacks and Nomic, which have "dynamic" federations which can be changed at regular intervals (both use a premined altcoin to sustain the sidechain). But both are not specialized in arbitrary data (although for sure they could be used for that).

A "data sidechain" like that I had in mind doesn't even need a two-way peg like RSK/Stacks/Nomic still need. Only the data would be "outside" of the main chain, no financial transactions, but the data items would be chained together and hashed into OP_RETURN outputs on the main chain. I have no idea if the concept has some weak point but I would love to see it "live". Maybe I'll create a thread with a proof-of-concept for it elsewhere. You could even implement a governance mechanism where the nodes could decide which content has to be hidden (e.g. via some sort of Proof-of-stake) to address the "illegal content" problem.

[BlackHatCoiner]

I don't think this kind of criminal group (illegal porn uploaders) had any advantage publishing content on the "expensive" Bitcoin.

I think people really underestimate the power of anonymous protocols like Tor, I2P, Signal with the use of other encryption techniques. Criminals don't need Bitcoin to be criminals, nor does it benefit them to have illegal content included in the blockchain (at least not for the respective cost).

I'm personally more scared by the fact that the chain will be bloated with greater fool's theory junk than by child porn.

[Artemis3]

For the time being I'm downgrading to 0.21.0. According to the release notes:

"This release implements the proposed Taproot consensus rules (BIP341 and BIP342), without activation on mainnet. Experimentation with Taproot can be done on signet, where its rules are already active. (#19553)"

Indeed, it is the next release 0.21.1 that says its enabled on mainnet.

Without taproot ordinals breaks no? good for now...

[garlonicon]

For the time being I'm downgrading to 0.21.0.

If you have full node, then you will store witness data. Your node will not validate it without Taproot, but it will store that anyway. And if you have pruned node, then those ordinals will be pruned anyway. Also, there are patches to the latest version that will reject those transactions, but accept them in blocks (because you have to accept those blocks, in other cases you will land outside Bitcoin).