On Ordinals: Where do you stand?

[Wind_FURY]

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

Plus to fully enforce something that will break the incentive structure, which I will sound like a broken record to SAY that it's truly what's making everything stick together, will definitely risk breaking Bitcoin. I believe from the miners' and full nodes' viewpoint, transactions should only be merely transactions, it shouldn't matter from where it came from, to who it's sent to, or what kind of transaction it might be, let the fee market do its job.

[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

Plus to fully enforce something that will break the incentive structure, which I will sound like a broken record to SAY that it's truly what's making everything stick together, will definitely risk breaking Bitcoin. I believe from the miners' and full nodes' viewpoint, transactions should only be merely transactions, it shouldn't matter from where it came from, to who it's sent to, or what kind of transaction it might be, let the fee market do its job.

nah its not.. but nice try. i guess the latest campaign script has deceived you again
forget the campaigners that recruited you...
. forget their scripts for one moment
where you are pretending to be against the bloat memes. but then loudly saying you dont want the meme spam to stop and instead want everyone else to pay more

just ask yourself .. for yourself. do you personally want to pay more and wait even longer for your btc payments.. personally.. just to turn bitcoin into a meme library
or do you want to transactions to be lean and cheap where more people can transact freely and the TOTAL utility of many then affords the "incentive" for mining pools

here is one thing..
even if memes dont get into blocks. they can sit in mempools pending for days-weeks and it only takes 75 memes of 4mb to fill a 300mb mempool and cause all other transactions to "pay more" to avoid being trimmed off the bottom of the 300mb limit of mempool
emphasis: even if a meme never gets into a block and just keeps getting re-broadcast to mess with the mempool trimming mechanism

if you cant see this is a attack vector to cause less transactions per block but more fees per block breaking bitcoins utility and desire.. then you have your nose to close to your teams latest campaign scripts and not allowing yourself to see beyond the speeches.

short couple of questions, with easy answer that will reveal your convictions/mindset:
a. do you prefer 4mb of about 75 spam memes paying 4000000sat total to pool
b. do you prefer 1.5mb of about3000 normal tx paying 4000000sat total to pool
c. do you prefer 4mb of around 8000 normal tx paying 4000000sat total to pool

[Wind_FURY]

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

Plus to fully enforce something that will break the incentive structure, which I will sound like a broken record to SAY that it's truly what's making everything stick together, will definitely risk breaking Bitcoin. I believe from the miners' and full nodes' viewpoint, transactions should only be merely transactions, it shouldn't matter from where it came from, to who it's sent to, or what kind of transaction it might be, let the fee market do its job.

nah its not.. but nice try. i guess the latest campaign script has deceived you again
forget the campaigners that recruited you...
. forget their scripts for one moment
where you are pretending to be against the bloat memes. but then loudly saying you dont want the meme spam to stop and instead want everyone else to pay more

You're not getting the context. I actually agree to the debate that changes in the fee structure might break Bitcoin. Simply, I'm saying don't take the risk of playing with the incentive structure that has already been set in place. Let the fee market do its job, and figure itself out.

I'm not debating for Ordinals either, but don't "fix" any part of the network that doesn't need any "fixing".

[franky1]

without code changes.. the spam, by just sitting in mempool plays with the fee structure
it also plays with the tx per block structure
it also plays with the time expectation for payment settlement

but hey an exploit has been allowed and you dont want to fix it because you think its not broke

oh and the fee mechanism you think will "figure itself out" wont figure itself out to make spam disappear in blocks...
because said spam can manipulate fee's of other people in the pending(zero-confirm) stage of mempool filling

[Wind_FURY]

without code changes.. the spam, by just sitting in mempool plays with the fee structure
it also plays with the tx per block structure
it also plays with the time expectation for payment settlement

but hey an exploit has been allowed and you dont want to fix it because you think its not broke

oh and the fee mechanism you think will "figure itself out" wont figure itself out to make spam disappear in blocks...
because said spam can manipulate fee's of other people in the pending(zero-confirm) stage of mempool filling

I'm merely talking about what I see, without expressing my personal bias or personal opinions. In that context, I'm also neither thinking about it in labels such as "spam". I'm thinking about it with a neutral viewpoint.

Block space is limited, if demand goes up, fees go up, and miners simply do their job looking for the most profitable outcome for them per current block.

[pooya87]

For the time being I'm downgrading to 0.21.0.

What you want is Bitcoin Core 0.12.1 or older since it has no SegWit support which means your node will not store any witness data. But i have doubt you can simply just keep using folder which created by newer version of Bitcoin Core.

Version 0.21.0 seems to have the full code for witness version 1 verification so I'm not so sure if your node would even avoid relaying such transactions: https://github.com/bitcoin/bitcoin/blob/v0.21.0/src/script/interpreter.cpp#L1885

In case you don't mind storing the transactions but you just want to stop relaying the attack transactions you can downgrade to 0.20.0 where witness version 1 is non-standard
https://github.com/bitcoin/bitcoin/blob/v0.20.0/src/script/interpreter.cpp#L1528
since unfortunately that is the only way apart from having to modify the source code and adding something like a hack like this

Code:

static const unsigned int MAX_SPAM_SIZE = 100;
static const unsigned int MAX_SPAM_STACK_SIZE = 3;

if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION) {
    if (stack.size() > MAX_SPAM_STACK_SIZE) {
         return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION);
    }
    for (int i = 0; i < stack.size(); i++) {
        if (stacktop(-(i+1)).size() > MAX_SPAM_SIZE) {
               return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION);
        }
    }
}

Added before line 1939.
Keep in mind that I'm not a c++ dev and this is untested but it won't affect your block verification since the SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION is a standard rule (policy flag) so there is no risk of rejecting a valid block by accident and causing a fork.

Or you could go nutz and instead of doing the above, reject the whole script spending path by adding this

Code:

if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION) {
     return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION);
}

on line 1923. This is again another standard rule added to reject transactions from your mempool but still verifies transactions in any block you receive.
This means you won't relay these spam transactions and won't contribute to this attack as a full node.

[vjudeu]

What about this filter? https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831

[pooya87]

What about this filter? https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831

Considering that the EvalScript method is called by a lot more places than just Taproot scripts, I'd say it is not a good idea to place it there specially if you are not checking the sigversion variable.

Additionally the script is only checking if the current OP code is OP_FALSE and if the next OP code were OP_IF it will reject it. That means it will also reject any other "normal" conditional script where the user wants to access the OP_ELSE conditions, for example it will also reject this.
We don't want to reject OP_FALSE OP_IF scripts, we want to reject spam attacks where the stack item(s) is bigger than a certain value.


I used a real example (this) and ran the script manually and I believe a much easier approach is just rejecting the transaction after line 1925 by doing a quick check on its size considering that this spam attack uses the "script" (redeem script which is the witness item before the last) to push the garbage to the stack.
Something simple like after line 1925:

Code:

static const unsigned int MAX_SPAM_SIZE = 100;

if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION) {
    if (script.size() > MAX_SPAM_STACK_SIZE) {
         return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION);
    }
}

But this will only reject the Ordinals Attack with its current design. The attack can be modified to go around this limit and spam the chain in another way which is why my initial code was more restrictive to number of stack/witness items to be 3 and length of each being 100 tops.

[DooMAD]

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

My understanding is that Devs like to work on code with a degree of "future-proofing" in mind.  Your proposal does have a certain degree of finality about it.  Imagine if a future developer came up with some novel new method of transaction batching that massively aided with scaling, or some other equally worthwhile proposal, but they needed to use that particular opcode and 85 bytes of data to make it work.  All of a sudden, we're looking at a hard fork in order to raise the limit again.  It's only reasonable that they explore other options first before potentially painting themselves into a corner like that.

[franky1]

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

My understanding is that Devs like to work on code with a degree of "future-proofing" in mind.  Your proposal does have a certain degree of finality about it.  Imagine if a future developer came up with some novel new method of transaction batching that massively aided with scaling, or some other equally worthwhile proposal, but they needed to use that particular opcode and 85 bytes of data to make it work.  All of a sudden, we're looking at a hard fork in order to raise the limit again.  It's only reasonable that they explore other options first before potentially painting themselves into a corner like that.

A these should not all be pre-activated to just let anything in.
B each should be default deactivated. and then get activated via node updates when they have a purpose via code/decisions of what they should be used for
where node users have had a choice/opportunity to upgrade to be ready to enforce the rules


i know you dont know what consensus is. but after soo many years,, you should know by now

get it yet
nodes should update to be ready to verify new rules then the rules activate
rather then new crap start and everyone race to catchup try to understand the crap

and yes not all new changes get to just happen .. they require the community to have vetted the code and understand the code to then see it as good/worthy of activating

..
i know you want systems that reduce utility of bitcoin
for years you did not want block space changes that allow more transactions with your fake cries of 4mb bloat is bad"
now you cry that 4mb bloat is good because this bloat also reduces transaction counts

your campaign is all about reducing transaction counts per block no matter the method.
yes i call them campaigns as its obvious you have a particular cause you follow that differs from bitcoins utility

you also campaign for reducing how many full nodes(full verification and archiving) are on th network protecting the network

you also campaign for the less users to pay more..

all of your campaigning defy the natural utility/ethos of bitcoin

you love the idea that nodes dont have to upgrade and that nodes get stripped blocks. or nodes choose to prune whole sections of the blockchain.

you goal is not to evolve bitcoin to be a system that allows more transaction on chain (more p2p digital cash utility)
you want another network to be the p2p digital cash

so there is no point in you playing your silly games of pretending your desires are about aiding bitcoin evolution

what you defend is not bitcoin. but human developers that are sponsored to implement code that sways people into using other networks

you do not idolise utility of the masses. you idolise corporate networks wanting to make profit from users by doing middlemen crap

[DooMAD]

*noise*

Tinpot despot franky, clueless as ever.  Your view of how Bitcoin ought to be is the one that would be most profitable for middlemen.  Your blinded fervor and misguided concept of scaling is a threat to decentralisation.  You want "dOuBlE fAsTeR" and no other alternatives to "dOuBlE fAsTeR".  You claim you don't want large increases, but you have never expressed a single alternative.  So naturally, like every other time someone has given you an inch and you've taken the absolute fucking piss and a country mile with it, if those securing the chain did grant a blocksize increase, you'd be straight onto badgering everyone for another one the moment those larger blocks started to fill.  One trick (and likely braindead) pony.  Mr "dOuBlE fAsTeR forever".

[franky1]

i have expressed many options. your ignorance and attitude of blind obedience to the central point of failure called core(they admit they are) has blinded you of other options which you ignore or pretend you dont remember

you advertise other networks that need middlemen(routers)
you are the one proposing fee mechanisms that do not benefit the user but benefit centralised pool managers (not the asic miners)

i have said for many years of fee mechanisms that punish only the spammers not everyone. thus fairly punishes the abusers
https://bitcointalk.org/index.php?topic=1811430.msg18046048#msg18046048

i have said that no one deserves a whole blockspace for 1 transaction. where it should be fair lean transactions to allow more individuals to transact per block.. not less
(unlike you that has always wanted less transactions per block via many campaigns you have promoted)

i have even said get rid of the cludgy miscount of bytes and instead streamline the code back to basics so that using a 4mb blockspace can allow actual transactors to use 4mb of space.. meaning more utility of space of the whole 4mb so that the average 2k tx per mb becomes upto 8k for 4mb of space. instead of the cludge that exists today of miscounting bytes which only allows an average of 3k tx for 1.5mb of space 6 years after so many promises of "scaling" were made

[Boakse]

Well, let's interrupt...

I don't get Ordinals full (I think)

But I can put all of the data of a floppy 1,44mb in a block?
However we can not open or use this data?

Can this be made to use?

ex. Can I put an old floppy game; Prince of persia -> dump the data in the BTC blockchain -> using Ordinal(s) (?)  and open this data
again on any pc?  Run it? use it?
(Don't come by, its a dos thing, there is lots of small data or apps to fit in 1,44mb floppy ex.)

I think I like Ordinals if such use cases (this is just the most simple thing) are possible?
Open -things- from the BTC "ordinal" input \ (layer?) or even Execute "things" from the "Ordinal" input...


Or do I sound really dumb or stupid here




Is Bitcoin just really and only there to transfer; "money" "wealth" "asset" "currency" and more of that , and NOT DATA?

Who decides it use case? isn't that up to "the market" and future?

ex. Could there be a moment in future Time that using the Bitcoin protocol to "hold\protect\share" data (in the blockchain) will be worth MORE in fees than transferring Bitcoin itself (as money\currency) on the Blockchain...?  By a good plus-up difference in fee?

And (say) more than 50% off the Block size can\will be used for data and not "sending" Bitcoin for currency or payment...?

Is that Good? is it Bad?


My Crystal ball just left me behind

[moderator's note: consecutive posts merged]

[nullama]

~snip~
But I can put all of the data of a floppy 1,44mb in a block?
However we can not open or use this data?

Yes, you can upload and download data from the Blockchain.

Here is for example how to grab the bitcoin whitepaper from the blockchain:

seq 0 947 | (while read -r n; do bitcoin-cli gettxout 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713 $n | jq -r '.scriptPubKey.asm' | awk '{ print $2 $3 $4 }'; done) | tr -d '\n' | cut -c 17-368600 | xxd -r -p > bitcoin.pdf

You end up with a bitcoin.pdf file in your computer, grabbed from the blockchain.

[LewisMachina]

I don't like the burden that is getting loaded on full nodes as we progress into bull market, full node disk space will get more costly but I love it.

NFTs are normie magnet and Bitcoin needs normies. mETH heads discovered NFTs in 2017 later reaped the benefits in 2021. Their space filled with normie NFT chasers. Solana fully dedicated their project into NFTs and look at them their ecosystem is filled with larps and normies.

Bitcoin started with a cyber punk community and with each passing cycle it progressed into normie land. Ordinals are reversing that kicking off with normies and with each passing cycle bitcoin pilling the normies and turning them into something else. Pretty great.

[nutildah]

ex. Can I put an old floppy game; Prince of persia -> dump the data in the BTC blockchain -> using Ordinal(s) (?)  and open this data
again on any pc?  Run it? use it?

Yes actually, this is Inscription #146:

https://ordinals.com/inscription/8022be710a15f03761d095ef0e6ed97cbb554fd58fa6e238ce23c2e46033bca6i0

Somebody uploaded the entire Zork text adventure game from the 80s, and the funny thing is, it works! You can play it right in the ordinals explorer. Pretty awesome if you ask me. Its a bit less than 160 kb of extra data.

[vapourminer]

i had no idea you could run actual code directly on the ordinals site.

kinda scary actually. i do not like this capability.

edit: off topic but zork was one of my 1st computer games back in the 80s. recognized it immediately lol

[KiaKia]

I have no interest in this ordinal thing but it's cool that someone comes up with this idea, to me it's just another opportunity to make some money off this so-called utility.

I doubt if people will utilize it anyway, we already have NFT, and NFT is been utilized by business giants in the world today.

I don't see how Ordinals will take the same road when the news was out I do take advantage of Ordinal Finance, I got in early and made some profits then I sold it all, including a few NFTs, then I bought Bitcoin.

I am excited to see how far this ordinal can go, I am sure something new might come up soon but I doubt the idea will live long.

I hope it won't have a bad impact on Bitcoin itself, because it is still scary, to me.

[vapourminer]

I also didn't know Ordinals website can do this. I also found there's Snake game at https://ordinals.com/content/6edf80efbbae537b554340c31496439b57bef65357a57f21cbb547bc6287d7bfi0. But based on it's content type, it looks like you need to convert the game into HTML to make sure it's playable on browser unless you want to extract .exe or .com manually from ordinals transaction.

i went back to the zork ordinal, seems it tries to load a font and save the gamestate to local storage.

i dont like it.

[larry_vw_1955]

I also didn't know Ordinals website can do this. I also found there's Snake game at https://ordinals.com/content/6edf80efbbae537b554340c31496439b57bef65357a57f21cbb547bc6287d7bfi0. But based on it's content type, it looks like you need to convert the game into HTML to make sure it's playable on browser unless you want to extract .exe or .com manually from ordinals transaction.

they even uploaded doom: https://decrypt.co/120459/will-it-run-doom-bitcoin

i tried it but it made my computer run too slow almost grinding it to a halt.