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

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

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


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

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]

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://bitcointalksearch.org/topic/m.18046048

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

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

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

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.

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

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

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

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.

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

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

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

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.

so why dont they do that? it would solve the problem of illegal materials on the blockchain. the only issue i can see is the filtering service would need to get paid because it uses either computing resources or human resources or both. so it might result in people having to pay a higher fee for their monkey to get into the blockchain but why not? you want to inscribe a monkey then pay for the overhead...

but can't miners be anonymous if that's the case then i'm not sure how they could be held accountable. i've heard that big mining pools and farms are not anonymous but maybe that's by their own choosing. if they got scared of being prosecuted maybe they would just go underground. and try and stay more anonymous. bitcoin doesn't store ip addresses of who mined the block...and they can always use a vpn or something anyway. so i don't see how you could force miners to do anything. if they really didn't want to.

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

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

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

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

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

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

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

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

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

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

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

no its not

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