Topic: On Ordinals: Where do you stand? - page 28. (Read 9235 times)

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.

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.

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

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.

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"

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.

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

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

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.

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


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

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!


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.

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

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.

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.

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.

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

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



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.

he says he dislikes memes being on independant file systems

yet..
he wants memes on hundreds of thousands of nodes

yet in both cases casey has not figured out a true blockchain proof of transfer

his ordinals crap relies on website explorers to make a path be being told to follow output 0. but has nothing in those output 0's that prove the ordinal

so again. its back to basics
he wants a meme put on a blockchain where hundreds of thousands of people have a copy but cant do anything with and no system to prove any real transfer.

as for saying doing transfers off-chain. that again would not have proof of transfer either.

thus he has things backwards.

the file can be stored off chain in multiple locations to only those that want to store/display it. and instead only the proof of transfer could be done onchain. with nothing more then an average tx length

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


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

[1] https://en.bitcoin.it/wiki/Colored_Coins
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021413.html
[3] https://github.com/casey/ord/pull/1805

doing a FORK(risk of chain split(definition of fork 2009-2016)) just to impose a fee mechanism that makes it more expensive is a stupid idea

however
patching the exploit of opcode data length back to a rational amount does not require a FORK
because under 100bytes is a under 4mb rule so it does not break old node compatibility
in short: it can be done using the same soft consensus bypass trick used alot since 2017

yep there is a difference between forks and consensus bypass trick

and guess what
it does not mean it then prevents future changes.. it just fixes the existing one

future changes can happen using a proper consensus activation routine
nodes upgrade first for readiness, then they flag for readiness ..and if majority is ready, then it activates

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

You've reverted back to going out of your way to not get it... why? Adding a filehash is unnecessary as following movement of the ordinal is all that matters, Casey isn't the one doing the inscriptions or transfers, and the 'dead weight' cannot be transferred. It is forever associated with a single ordinal as per the rules of the protocol.

You can pose as many "what ifs" as you want but let's get the basics of how it works right first.