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.
Topic: On Ordinals: Where do you stand? - page 27. (Read 9119 times)
~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?
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.
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 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
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
*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".
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
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
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
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.
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);
}
}
What about this filter? https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
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.
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);
}
}
}
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);
}
This means you won't relay these spam transactions and won't contribute to this attack as a full node.
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
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.
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
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
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".
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
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.
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.
Quote from: franky1
normal transactions without these crap memes can be auto added using algo's.. where its the crap memes that can be delayed by several blocks if a honest mining pool wants to keep the blockchain clean of illicit material
again mining pools have the capability to audit transactions. and ignoring such capability is ignorance. and not a defence in court.
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. again mining pools have the capability to audit transactions. and ignoring such capability is ignorance. and not a defence in court.
Quote
For the time being I'm downgrading to 0.21.0.
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...
"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 don't think this kind of criminal group (illegal porn uploaders) had any advantage publishing content on the "expensive" Bitcoin.
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.
you got people that might upload their junk to everywhere they can find. no stopping at just one blockchain for them!
But again, if Bitcoin is under these blockchains, they would have to pay a high fee.so you're saying instead of going straight into the mempool they have to go first to some type of staging node that all the transactions get visually checked [...] that would require a change to how bitcoin works.
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 probably farthest thing from federated/centralized Bitcoin side-chain. I know it rely on Bitcoin merge mining for it's security, but i don't know how decentralized is it.
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.
Jump to: