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

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.

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.

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.

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

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.

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

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.

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

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

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.

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)

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.

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

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.

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?

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

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

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

Whether you like NFTs or not, ordinals are done through an unintended exploit of the taproot upgrade. NFT people act like this is a new feature added through Taproot that allows NFTs. No its not, that was never the intention. It's an unintended exploit and so instead of having a bitcoin chain full of money transactions we have arbitrary data of crappy digital images spamming the blockchain. I got no problem with people that wanna spend lots of money on stupid generated digital images doing it on Bitcoin if they do it in a way that doesn't block the actual intended use of Bitcoin! Like make a side chain or something for this.  In Ethereum there's an actual intentionally developed token type for non-fungible tokens. In Bitcoin its just an unintended exploit of an upgrade that the devs didn't see.

Nothing wrong with the ordinals project per se, it's a new feature of Bitcoin even if it was an unintended feature. But when it gets in the way of the main purpose of Bitcoin - money transactions for the entire world, we've got a serious problem. And it's not like these NFTs are doing anything useful. They are just image NFTs, which is like the dumbest form of NFTs. There are plenty of actually compelling use cases for NFTs in the world that hopefully will be developed by the crypto community in the future, but just images as NFTs is like the lowest hanging fruit of that technology. So not only is it not good that bitcoin is being exploited in this way and thereby becoming much less useful thanks to NFT spam, but instead of people being like oh wow NFTs on Bitcoin let's actually try to start making useful NFTs people at this point actually think NFTs ARE images so they don't even think to do anything else and instead just spam bitcoin with image file data.

@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


to make ordinal memes no longer available to be on the network is easy as using the trojan backdoor trick in the opposite direction
upto 80bytes is within the upto weight rule.. and wont cause a hard FORK or soft FORK

it would however harden consensus to not allow random bloat to be put onto the blockchain, without first needing to use consensus to decide if new code deserves to be part of bitcoin protocol
(consensus = consent+census = uniting consent of majority survey)


thus improving security where by again we can get back to some semblance of consensus that requires nodes to upgrade first BEFORE changes are activated

as for a way to turn the dead weight memes into a form of NFT that has proof of transfer
thats an easy trick but if those idiots that love the meme crap cant work it out.. GOOD

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.

those three examples are not user node consent (consensus)
you are the one in different posts and topics saying:

-there was never consent and trying to prove it
-you then say users get the choice by deciding not to run the software
-then you say core can do what they like and add what code they like and no one should stop them

funny part is
"it was PROPOSED" to be activated by softfork
you forget to include the whole conversations of back in those days

discussions came about how a soft consensus back then was dangerous so then it became a  need of 55% of miner adoption before activation. where miners had to run the updated software first and then flag they were running and ready to activate it. before it would activate

years later
things now dont even require that.. because consensus has been softened multiple times where by this ordinals crap got allowed to occur


just because a trojan back door exists and every few years the door is widened. does not mean we need to put up with the crap and keep widening the door and letting all crap in

the 55% was also controversial
also as all those bips mention, there are risks of forks doing it their way in earlier years so they had to be careful..
where a consequence.. they eventually gave up trying bip12.
and also bip16 caused a fork(chain split)
https://github.com/bitcoin/bitcoin/issues/925
because yep softforks went bad in 2012

oh and also if you dare read the bips.. you will read things like

which with both the fact that the lower threshold(55%) caused problems and that it requires node readiness to verify..  is why they raised the limits to 75% and the 95% (ISM) (Is Super Majority 75% then 95% (oh this was in 2012 too))
after the attempts of lowering the requirements caused issues.


but
then years later the trojan adorers wanted to just not require any % and just let anything in by pretending soft consensus was error free (it was not, but trojan adorers dont like that being discussed)


so the way things are done now... do to them getting their way since 2017
the CONSENSUS SOFTENING lately is not about fork risk. because it just makes old nodes LIMP/ FOOL nodes that dont validating new stuff (thus not even a true backward compatibility)

something that has been controversial for years

but doomad doesnt like anyone talking about that, he just wants core to throw anything in untested and unverified

BIP12 is from 2011.  It was proposed to be activated by softfork.  This proves beyond all doubt that franky1 is a gormless imbecile who does not understand consensus.
BIP16 is from 2012.  It was proposed to be activated by softfork.  This proves beyond all doubt that franky1 is a gormless imbecile who does not understand consensus.
BIP18 is from 2012.  It was proposed to be activated by softfork.  This proves beyond all doubt that franky1 is a gormless imbecile who does not understand consensus.

Do I need to continue?  You are either completely delusional or completely braindead if you think Bitcoin never used backwards-compatible (or, as franky1 likes to call it, "rape", because he's a vile, disgusting, inhuman piece of shit) code prior to SegWit.