On Ordinals: Where do you stand?

[franky1]

due to the noise of doomad and blackhatcoiners social drama temper tantrum..
lets go over the basics of this topic actual discussion

NFT are tokens that have a feature to transfer ownership(otherwise they are just dead weight)*

these ordinal crap do not do ownership transfer on bitcoin
thus the occurrence on bitcoin is not NFT related, due to not having proof of ownership transfer feature in the blockchain data

they are just inserted dead weight and using bitcoin as a meme library of dead weight

there are ways of ownership transfer.. but casey cant figure it out so his project is not for nft value ownership transfer.. and bitcoin was never intended to be a meme library


*dictionary: token
-a voucher that can be exchanged for goods or services, typically one given as a gift or forming part of a promotional offer.
-a metal or plastic disc used to operate a machine or in exchange for particular goods or services.

tokens are not meant to just lay dead and serve no purpose after creation, they are suppose to be passed around

[d5000]

messing with the fee's in regards to ordinal crap does not work because mining pools accept the meme crap with less than normal fee's and even wit no fee at all.. so no point thinking it can be fixed with fee's

That are anomalies, the well known case of the almost 4 MB picture seems to have been a "protest against censorship", i.e. an unique event (where the mining pool chose to throw away around 120.000 USD). If pools would continue with that, nobody would lend them mining power anymore. In fact if you chose a "non-ordinal" pool the miner would get more fees in this case. (Yep, NFTers could bribe pools, but that would have the same effect than a tx fee increase.)

In addition, data storage with older methods, as I wrote before, was possible until Ordinals appeared. It was only ~15% more expensive. IMO the current "ordinals fad" could have also happened with the old methods, as 15% more would not change much. But 4x would be quite a lot and make some of the NFT folks re-think if they shouldn't use another chain.

I'm not totally against a "tightening" of the rules, but I'd tend to avoid it as it would set a bad precedent ... hey, let's try feature X out, but if Y appears we don't like, let's tighten the rules so Y isn't possible anymore! That's imo against Bitcoin's long term oriented philosophy. It could also lead to a new "update war" (if it's really not a fork, I believe it would be a soft fork, if it's protocol enforced and not only through "nonstandard" rules).

But if the spam problem persisted and did result in problematic fee structures (let's say a situation like late 2017/early 2018), then I would support such a rule tightening as an emergency measure. However, the current situation isn't that dramatic -- that 1 sat/byte works is not the norm at all, in several periods of the past you'd have to wait several months to get such a low-fee tx through. ~3-4 sat/byte like currently for 1-day txes, isn't that bad, in 2019 several times you'd have to pay 10+.

[franky1]

when you worry about "tightening the rules"

a few things to remember is just because people used op_return to spam data at XXbytes per output in the past.
does not mean its reason to allow a different opcode(activated in 2021... that allows XXXXXXXbytes) to continue

the old limit was a 10kb limit not a 4mb limit of an opcode

what you need to realise is taproot was promised as a 1 signature length
thats what its main purpose was. allowing complex scripts that reduced to a signature length

so they need to fix it to meet its promise

what you describe as tightening the rules. is actually returning the limits to reasonable/ rational utility pre taproot.

it still would allow taproot. but with the byte limits of their promised features

[larry_vw_1955]

But if the spam problem persisted and did result in problematic fee structures (let's say a situation like late 2017/early 2018), then I would support such a rule tightening as an emergency measure. However, the current situation isn't that dramatic -- that 1 sat/byte works is not the norm at all, in several periods of the past you'd have to wait several months to get such a low-fee tx through. ~3-4 sat/byte like currently for 1-day txes, isn't that bad, in 2019 several times you'd have to pay 10+.

well you seem to have a well rounded reasonable stance but i think you're not really addressing or paying attention to the other issue which has nothing to do with transaction fees which is storing illegal materials on ordinals. that's not problematic in anyway? what if someone want to upload instructions on how to make a very powerful pipe bomb along with the electronics to detonate it maybe even remotely? that's ok? just saying "they can find that on other places on the internet" doesn't really excuse it from being on bitcoin though does it?

[pooya87]

~

The problem with using the fee rate to discourage this particular type of spam is partly because of miners who can ignore the said "standard" rule and still accept them with low fee to no fees. Another reason in my opinion is that the spammers at some point may not care about paying even much higher fees than 4x, etc. if the market for the junk they are creating grows big enough that it becomes profitable to trade them.

It is kind of like trading on a CEX. For example if you are trading with 1BTC and making 25% profit (which is normal in shitcoin pump and dump market) that is 0.25BTC and you don't see anybody caring about paying 0.004BTC in fees (2x 0.2% for buy and sell) although that's a huge fee to pay when seen alone.

We already know that in the past there have been many shittokens like NFTs that were sold for tens of millions of dollars, ignoring many of them that were fake sales for money laundering purposes there are still enough of them with high prices that is enough to conclude a fee market is not going to discourage this type of spam if the same thing starts happening in bitcoin.

[franky1]

ordinals paying low fee per byte in comparison to genuine transactions is NOT an anomaly

screw it
lets take the latest block at time of this post
(that way you cant say im being picky by only choosing an anomalous block

https://www.blockchain.com/explorer/blocks/btc/780416
https://www.blockchain.com/explorer/transactions/btc/f332487eb94750162db7777be985371cdd26951dd3943da19f7d6667123333ba
1.753 sats per byte
for an ordinal meme

block size 2,131,705bytes
0.14792359fee
= 6.939 sat per byte

so while other transactions per paying 6.9sat per byte
the ordinal bloat paid 1.753sat per byte

and yes i am talking about actual bytes for actual sats.. no clumsy/cludgy math

the ordinal memes are paying less than the average

[pooya87]

https://www.blockchain.com/explorer/transactions/btc/f332487eb94750162db7777be985371cdd26951dd3943da19f7d6667123333ba
1.753 sats per byte

That wasn't the best example of this attack to use if you wanted to make a point.

First of all the fee rate is 7 sat/vbyte which is the correct rate to look at not the per byte one blockchain.com reports.

But since I know you don't understand the vbyte measure you can compare the total amount of fee paid by this tx to the rest of the transactions. It paid 0.0019964BTC which as you can clearly see, in a block with 935 transactions this spam tx is among the top 20-ish transactions with the most amount of fee paid in total.

In other words these attackers don't mind paying something like $41 to spam the blockchain.

P.S. I just realized that blockchain.info (now .com) that is known for being super lazy in implementing stuff (like SegWit, even correct fee estimation in their wallet) has already added the code to recognize Ordinals spam and even show the junk image inside them. It is very surprising to see them jump onboard of this spam attack this quickly basically encouraging this behavior while having a history of acting maliciously towards bitcoin useful features in general.

[franky1]

no offence
but i do understand the vbyte measure/segwit. i just choose to use the normal real world data measures of real world bytes and real world sat costs.. not cores silly GUI based cludgy math of miscounting crap and multiplying other crap

tx fee    199,640
tx bytes 113,796
=fee per byte=1.75~ sat/byte


imagine it this way
you go to a fruit and veg market.. you pick up 6 apples  of mixed variety
you go to the counter and pay $1.20

rational minds say hmm thats $0.20 per apple.. logic. common sense
6 apples in your hand.. $1.20 leaves your pocket

but nah. you are fooled into listening to this...
whilst paying you are TOLD verbally that 1 apple is $0.50.. another is $0.60 another is $0.01 and the other 3 are $0.03 each
all because the grocer is doing a special offer it decided to do at the counter

then you look at your receipt of hard data. and it just says 6 apples, total $1.20
yep the receit make no mention of the "promotion" of certain apples

reality is.. evidence is.. 6 real world apples for real world cost $1.20 is $0.20 each

not some cludgy math manipulation seen in the GUI to pretend to offer discount for one and different rates of premium for the others

..
try to take a chance on yourself. clear your mind of the promotional stuff.. and just read hard data of blockchain data.. and you will see real bitcoin blockchain data does not even understand what a vbyte is

its just a GUI measure inside core software.. not something measured in blockchain data

and no im not talking about blockchain.com the service
im talking about blockchain data.. the blockchain(the bitcoin network data)

and yes many wallet services and software always has to play catch up AFTER new features appear.. because yep instead of consensus.. where wallets, software and nodes upgrade first and then rules activate(good network security).. core have changed the paradigm to change rules first them make the whole community of bitcoin have to catch up and follow core. and insert the cludgy crap that core have implemented without the mass readiness of the network.. as this topic of crappy memes has proven.

here is one little funny
blockchain.com signed the NYA to say it wants and adores segwit in may 2017 but didnt implement segwit into its blockchain.com/wallet service until 2018 because core didnt release wallet functionality for segwit until 2018
meaning many software/wallet services didnt implement utility of segwit until after that

the community has become too reliant and too enamoured(adored) by core and use their silly buzzwords and GUI expressions. that people have stopped thinking about things in actual real world view of blockchain hard data of "bitcoin network"(again i mean blockchain data not the service of similar name)

[d5000]

i think you're not really addressing or paying attention to the other issue which has nothing to do with transaction fees which is storing illegal materials on ordinals.

I have addressed that earlier in many posts (discussion with @n0nce some weeks ago). My stance is still the same: those who want to attack bitcoin this way do not need Ordinals. If Ordinals is "capped" then they would have only to pay 15% more fees with the old methods. They could even attack Monero or Grin this way (see here).

In fact I'm adressing this problem in my last post, see the part about the "notify and takedown" system for a OP_RETURN based "data sidechain".

The spam problem has its roots in two aspects:

1) the perceived low cost of the Bitcoin blockchain with respect to Ethereum,
2) the condition of Bitcoin as the "OG" cryptocurrency.

Problem 2 cannot be solved, it's even one of Bitcoin's main network effect generators of financial purposes. We can try to attack problem 1, although there is no perfect solution. IMO the goal should be to offer first "better" alternatives than Ordinals which do not generate spam conditions, like a data sidechain and OP_RETURN improvements, and only if the problem persists, then go and tighten rules (and @franky1: I sorta agree with you partially in your last post about rule tightening, although still - it's not my preferred way to act in this case, as the devs may have had their reasons allowing big taproot scripts).

The problem with using the fee rate to discourage this particular type of spam is partly because of miners who can ignore the said "standard" rule and still accept them with low fee to no fees.

I addressed this point in my answer to @franky1 here, in short: this way to act would never be sustainable for miners over longer timeframes, they would get lower profits and pools offering that "service" would lose hashrate (and miner bribing doesn't change anything in the equation).

Another reason in my opinion is that the spammers at some point may not care about paying even much higher fees than 4x, etc. if the market for the junk they are creating grows big enough that it becomes profitable to trade them.

This can definitively happen, but I don't think that such high profits can be expected for more than a certain "highly valuable", limited number of inscriptions, imo much lesser than whats happening currently, perhaps 50-100 inscriptions per day. So the block chain congestion would imo definitively decrease a lot.

[larry_vw_1955]

Problem 2 cannot be solved, it's even one of Bitcoin's main network effect generators of financial purposes.

what do you mean it can't be solved? it has to be solved. because you can't storing illegal things on ordinals if it's too popular then the government might try and stepping in. and no one will want to distribute illegal material too. so no one wants problem 2 to exist. of course it has to be solved. the only question is how. it has to be solved on ordinals because ordinals got very popular. so that's a no brainer. that it has to be solved.

one way to solve it could be to have transactions put into a pending state while they get examined to see if they has bad image or content. if not then it can be approve otherwise declined and they lost their transaction fee too. i know it sounds ridiculous and unworkable but it has to be done i think.

[franky1]

when it comes to "fee" rate incentive to stop spam

it requires transactions to abide by a fee rate or if they appear in a block that block gets rejected..

also if you forget about cores user interface/front-end-GUI/display. cludgy math of "fee" and look at block data of real bytes vs sats paid..  these spammy memes pay less sats per bytes then genuine payment users

as for the "coz op_return allows" arguments about rationalising why some want non payment data(meme spam) in the witness area to continue(facepalm)

here is the thing. the op_return stuff is not witness data it sits inside the barrier of the imposed 1mb base tx data.. thus even if there was 1 tx of thousands of op_return spam. it would only take up 1mb of data not 4mb
there were other rules that the max tx had to be 20% of base 1mb meaning only 0.2mb per tx was allowed

see the difference

i dont know why people are debating different methods of including non payment data (memes) via different methods. bitcoin was not made for it. so should have code .. yep code.. to prevent it

as for those arguing "well the exploit let it in lets see what happens" thats as bad as saying "well an exploit let in a blockreward change to 2000coins a block, lets see what happens"

if the whole softening of consensus has caused exploits to be let in before nodes are ready to verify the new feature that was suppose to be activated.. where by people need to download/ upgrade node software anyway.
a quick patch could be included to then fix the bug and then everyone downloads it and seals the trojan hole that allowed the exploit (limit taproot sigops lengths to under 100bytes or the 1 signature length they promised)(the main purpose of taproot)

as for those that want a bitcoin NFT where a file hash is showing a proof of transfer (thus no need of bitcoin being a meme library but just a timestamp proof of transfer of file hash NFT system. there is a simple way to do that using features over a decade old, which does not cause any mass bloat compared to average tx size

[larry_vw_1955]

a quick patch could be included to then fix the bug and then everyone downloads it and seals the trojan hole that allowed the exploit (limit taproot sigops lengths to under 100bytes or the 1 signature length they promised)(the main purpose of taproot)

bitcoin nft enthusiasts would be very upset if that happened. and they would be wondering how could that possibly happen.  

as for those that want a bitcoin NFT where a file hash is showing a proof of transfer (thus no need of bitcoin being a meme library but just a timestamp proof of transfer of file hash NFT system. there is a simple way to do that using features over a decade old, which does not cause any mass bloat compared to average tx size

room for improvement for ordinals i guess? you're giving casey some ammunition there franky  say casey puts in a filehash for the subsequent transfers of the dead weight.  not that anyone would care they don't care about how it works just that it works, at least those bitcoin nft enthusiasts. they could care less how any of it works as long as they can see a picture of a monkey and other people agree they "own" it.

but they probably are smart enough to realize that their monkey can never "go away" unlike on ethereum where their monkey could possibly disappear oneday due to file hosting issues. they're that smart but no further.

[Wind_FURY]

...

Yep, I more or less agree -- my remark was about the way the "sub-consensus" works in the case of Ordinals and Omni/Counterparty, and it's identic. Both assign "significance" to data which would normally be read as "arbitrary" with the standard Bitcoin tools (which follow only the Bitcoin protocol).

I've thought a bit how the Ordinals problem could be dealt with without censorship or hard forks, but simply using incentive mechanisms and/or possible soft forks. Apart from making ordinal-type taproot scripts non-standard, which could be a "short term" strategy but is a bit of a "hack", I think there could be a more long-term oriented, "cleaner" strategy to provide a clear "incentive framework": creating two new transaction types with even better witness discounts than Segwit-style transactions.

The first type would be for pure financial transactions without OP_RETURN scripts nor any contracts. It would get 4x discount in comparison to today. Maybe even with a privacy mechanism in the style of Monero or Grin.

The second type would be for small data inscriptions with a single OP_RETURN output to up to a few hundreds of bytes, and would get 2x the Segwit-style witness discount. I would prefer 200 bytes instead of 80, or even a bit more, to be able to support at least some of the Ordinal Inscription use cases, without opening to things like JPEGs.

For larger inscriptions, a "data sidechain" could be supported "semi-officially", with a client offering to store inscriptions which are hashed into a small OP_RETURN output, but separately from the main chain. (This could include the "notify and takedown" mechanism I outlined here).

We could allow some more types to be supported by the 2x category, like popular contract types (multisig, atomic swaps/Lightning HTLCs and channel openings etc.). There could be a mechanism similar to "standardness" to enable them for that category.

We would then have a new "minimum fee level" 4 times lower than now, so - always having the current "fee market" in mind - the fee level for the current categories would be moving two "steps" higher for the current transaction types:

- standard non-segwit transactions: paying 8x the new minimum fee
- standard segwit transactions with full contracts, including Ordinals: paying 4x the minimum fee
- new "small data" / limited contract transactions: paying 2x the minimum fee
- simple financial transactions: paying 1x the minimum fee

Ordinals Inscriptions would then, on average, pay approximately 4 times the fees they pay now (with similar network congestion).

This is just a very general idea, which should (from my understanding, please correct if not) be achievable with a soft fork. The advantage is: we would not rule out new contracts and innovation in that field, but make it up to 4x more expensive until it is accepted generally.

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.

Core developers who might reject Ordinals will probably be Adam Back, Gregory Maxwell and Luke DashJr.

[348Judah]

And i also think about this as nothing compared to the crossboarder transaction charges with fiat currency, bitcoin is a network that solve this challenge and till this present moment, the cost of making a bitcoin transaction is less than one dollar, which is about zero point charges which i think isn't that much compared to where we all were coming from before a solution is been done about the ordinals for people to enjoy as low as 1 sat/vbyt for a transaction fee, i could remember the recent i did overnight which is 10 sat/vbyt and got confirmed less than 5 minutes, while before the introduction of ordinals i use 1 or 2 sat/vbyt with lowest priority and got confirmed the same time or even more depending on how congested the mempool is, so the difference am talking about is not something that big which could be unaffordable till a solution is made about ordinals.

[nutildah]

say casey puts in a filehash for the subsequent transfers of the dead weight.  

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.

[pooya87]

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

[franky1]

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

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

[ABCbits]

--snip--

The spam problem has its roots in two aspects:

1) the perceived low cost of the Bitcoin blockchain with respect to Ethereum,
2) the condition of Bitcoin as the "OG" cryptocurrency.

Problem 2 cannot be solved, it's even one of Bitcoin's main network effect generators of financial purposes. We can try to attack problem 1, although there is no perfect solution. IMO the goal should be to offer first "better" alternatives than Ordinals which do not generate spam conditions, like a data sidechain and OP_RETURN improvements, and only if the problem persists, then go and tighten rules (and @franky1: I sorta agree with you partially in your last post about rule tightening, although still - it's not my preferred way to act in this case, as the devs may have had their reasons allowing big taproot scripts).

--snip--

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

as for those that want a bitcoin NFT where a file hash is showing a proof of transfer (thus no need of bitcoin being a meme library but just a timestamp proof of transfer of file hash NFT system. there is a simple way to do that using features over a decade old, which does not cause any mass bloat compared to average tx size

room for improvement for ordinals i guess? you're giving casey some ammunition there franky  say casey puts in a filehash for the subsequent transfers of the dead weight.  not that anyone would care they don't care about how it works just that it works, at least those bitcoin nft enthusiasts. they could care less how any of it works as long as they can see a picture of a monkey and other people agree they "own" it.

but they probably are smart enough to realize that their monkey can never "go away" unlike on ethereum where their monkey could possibly disappear oneday due to file hosting issues. they're that smart but no further.

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

[franky1]

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

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