Topic: Expect the Orginals game to get even bigger - actual games - page 2. (Read 874 times)

Imagine that you are an attacker. Start regtest. Set it in pruned mode. Try to spam. See, what is kept by another node, and what is pruned. Note that "blocks" directory is pruned, but "chainstate" is not. And note that consuming a single input, and producing a lot of outputs, has the same feerate, as some another transaction, which will consume a lot of inputs, and produce a single output. Which means, that "UTXO consumers" are not rewarded, even though they make running pruned nodes easier. And note that "UTXO producers" are not punished, even though they can just produce UTXOs out of thin air, without any limits, and then never spend them. And also note that the number of UTXOs can be bigger than the number of satoshis in circulation.

I agree. Encryption won't help there, because all that is needed, is just using weak encryption key, or just using a simple XOR, and pretending that something is "encrypted" sufficiently. Which means, that to discourage people to store their data on-chain, they should receive a clear message, that nodes are not going to serve those data, and all they will do, is to make sure that signatures and public keys are correct, and not much more beyond that.

By the way: Bitcoin is not about storing data forever. It is about double-spending problem. And if some coin was created, then moved between many people, and then 100% of that was turned into fees, then that history can be safely pruned, because if a coinbase transaction, which collected those fees, is good enough to be spent, then everything below that is now rock-solid, and will never be reorged anyway (and also, the same transaction flow can then be recreated from any other fees, so the chain of signatures starts with the coinbase transaction, and ends, when the coin is sent as fees).

I get it. The gamble is whether this conservative approach of not doing anything prevails on the long term. It is as much a problem as a feature. But, to not go off-topic, I believe this will not pass. No sane miner would accept working on a chain that censors this type of transaction.

Pruned nodes keep the UTXO set, but you can't inject arbitrary data there, like Ordinals. So, how can you store as much data as non-pruned nodes?

Not a lawyer, but distributing illegal material encrypted sounds illegal. What if you post your private key publicly? Encrypted isn't local.

If you put it on the blockchain in plain text then it becomes accessible by everyone, which i suppose is illegal based on what you posted above.

Maybe you can encrypt the content using your private key, this way nobody else can retrieve the content of the file you inscribed.

And then, as a node operator, you would only worry about your country's law (assuming your node sits there too).


Well making attacks more costly is indeed better than doing nothing, but the kind of attack we talking about here does not require redundancy, an attacker would only need one transaction to "infect" the blockchain and then take you to court, so if it costs $10 or $1000 when done only once, it won't make any difference.

For other attacks that depend on frequency, this indeed would help reduce them, we just need to evaluate what could be broken along the way of doing it.

But don't you agree it's better than doing nothing?


Do you refer to ZeroSync (https://zerosync.org/)?


IIRC ZKP on Zcash used to create private/anonymous TX rather than UTXO set.

It is technically possible, but nobody proposed it yet. Note that you need:

1. Some kind of formal proposal, like BIP.
2. Source code with changes, and creating a Pull Request.
3. Some code for testing, that all of this is "safe enough to be added".
4. If a soft-fork, then an activation method, and showing support by mining pools.
5. Reaching consensus, and getting enough ACKs, to get it merged.

This is a long path, and it usually takes months, if not years. But yes, it is possible.

And note that it is more likely, that the whole work will be there, but won't be merged. Which means, that you can spend a lot of time on creating something (for example zero knowledge proofs), and people can say "no, it won't be merged". Then, you can get some criticism of things, that you should fix before trying again.

And one of those points could be: "users will use signatures and public keys to spam anyway". If your proposal cannot stop it, then it won't be merged.

So, you can "improve" it, and say "using ZKP is mandatory". And then, someone will point out, that "old, timelocked transactions, which are valid today, will be invalid, when your code will be merged". What then?

Another point to address is "mining pools won't accept your proposal, because it will lower their profits". And then, like it or not, your proposal can be covered with not enough Proof of Work, which means, that it cannot be a soft-fork. What then?

And because all of that, I think "the fix" should be a no-fork, applied on the level of Initial Blockchain Download, without touching consensus at all. Then, it would be 100% voluntary, but if it will be propagated sufficiently, then people will install and use it, when their nodes will be taken down by DMCA complaints.

But the most likely outcome is that nobody will propose anything, which means, that you are left with, what we have today. Which is again: not that much beyond pruning.

re: In the US at least, legality of storing/archiving copyrighted content, in this case vintage Nintendo games, per established case law and quoted from the decrypt article:The catch there is what constitutes a 'backup copy stored by legal owners of the original (and previously purchased) content" and the legality of said 'backup copy' being viewable and/or playable by anyone - not just the legal owner of said previously purchased content?

For those interested in how this interactive variant of Ordinals works using the SNES emulator here is the process used by pizzaninjas

While I applaud the archiving of otherwise ephemeral digital content and acknowledge the need for it (just talk to folks that purchased movies from several streaming sites that later shut down), using the BTC blockchain to do it is just wrong. There has to be another way to create immutable & public digital content libraries that use tokens for DRM control and a widely distributed blockchain...

All that said, as a miner do I like the fees being generated? Hell yes and come the 1/2ing those fees will probably often be close to or exceeding the block rewards.

As an occasional user of BTC so far when transferring coin I have yet to pay what I would consider an excessive fee to have a tx confirmed in less than 1 day. The catch there is, 'excessive fee' compared to what? Late summer of last year I moved several BTC from an online exchange to my hardware wallet for less than $100 and 1st confirmation was within a couple hours. For the last payout from Kanopool 7 days ago to the PPLNS users of the pool Kano used a near-zero fee to distribute the rewards from the pool wallet and it still was confirmed within a few hours. Go fig.

Ja using BTC for lots of <$50 tx's is no longer viable but when the ocassional tx is worth several $k and more - still cheaper and faster than a wire transfer.

This isn't going to cut it if you want to protect BTC from illegal content, making something more expensive doesn't stop an attacker from doing it, especially if they need to do it only once.


What about using Zero Knowledge Proof to make pruning the UTXO set possible? I recall reading about something like that in the past. I mean, my node would keep only block headers and UTXO commitments, and your node would provide a valid ZKP that certain parts of the UTXO set that I am checking are valid. I think Zcash operates in a similar manner.


In another thread discussion about the "ban of Ordinals," I did mention that contrary to what many people believe, changing any part of the code is like playing with fire. Anyone with enough real-world application experience would always be hesitant when applying any fix to anything. There is a reason why many billion-dollar companies still use old code that could be optimized. Some people think it's a matter of adding a simple if statement that would automatically ban all BRC-20 transactions without damaging anything.

Lawmaking is difficult in the real world, and so is in BTC. You try to fix something, like making transactions cheaper for the good lads, and you end up making potential attacks like flooding the UTXO set easier and cheaper. There is a huge fundamental issue with BTC, and that is its security is directly related to its value. The higher the value, the more difficult it is to attack, whether that is in terms of 51% attacks, spamming, or UTXO set flooding.

Because all limits are successfully bypassed, one-by-one. And UTXO set has no consensus-enforced limit. Which means, that if it is possible to abuse pruned nodes, and to make them store as much data as non-pruned ones need today, then someone will do that.

This is one thing. Another is history:

1. Block size limit: set to 1 MB. Reached.
2. Witness size limit: set to 4 MB. Reached.
3. Sigops limit: set to 20,000 (and for witness, increased to 80,000). Reached.

In progress:

1. Time limit: around 0x7fffffff in 2038, and 0xffffffff in 2106. The first one would cause some issues, because nodes cast types between signed and unsigned integers, between 32 and 64 bits. So, even in 2038, there would be some problems, even if those values could work well until 2106. You can always set your system clock to 2040, and see if your regtest node is affected or not.
2. UTXO limit: unlimited, enforced only by the physical specification of most nodes. Will be abused, sooner or later. And then, some limit will be introduced, or it will be abused further, if community will be too lazy to "fix" it.

There are more to-be-reached limits. But we are not there yet, to discuss them properly, because each "fix" and each consensus change, can dramatically change the situation, and stop some attacks, or make other attacks easier. It just depends, if something will be changed, and it depends on how exactly it will be changed. Devil is in the details, and I can guess, what will happen, but I cannot be 100% sure about that. But of course, by writing some code, and testing some scenarios, you can figure it out.

Well, this is the way to stop the attack, because it is too late to stop it in other ways. But you should think about it more widely: I would rather see a soft-fork, which would allow regular users to join their transactions, than a soft-fork, which would explicitly block Ordinals. Because if you "censor" anything, it will have some bright and dark sides. So, it is more clever to do, what the network should do: to prefer payments over Ordinals. And "making regular payments cheaper" is not the same thing as "blocking Ordinals explicitly as a protocol rule".

However, if nothing will be done, then all you can do, is to discourage people to use Ordinals. And if you want to do so, then what you can do with officially released software? Not that much beyond pruning, I guess.

There was a discussion, when the attack started (but not about soft-fork, because then, it was not that serious as today). And there were no decisions to block anything, which means, that status quo is preserved. For many different reasons. Also, because if you want to change something, you have to propose it, and reach consensus. And for simple fixes, like "blocking relay for Ordinals", they were rejected, and not merged into Bitcoin Core, which means, that this proposal was unsuccessful.

And today, there are consequences. Some of them are good, and some of them are bad. The good thing is that some attackers focused on Ordinals, which means, that they can be "censored" in the same simple way, as long time ago, when the attack started. And it is a good thing to keep it like that, to then throw everything away at once, using the same new rules. But of course, there are bad things, like "UTXO flood", which are going to happen in the future, which means, the "fix" will have to address both issues at once: spamming with data, and spamming with UTXOs, at the same time (or it will be insufficient, and will not stop the attack).

Note that "status quo" is the default. Which means, that everything works without any changes, unless you successfully propose something, write a code, write some tests, get it accepted, and then get it merged. The path to change consensus rules is much harder, than the path to fix typos in translations.

But, why will it happen anyway? Do you mean that it is simply possible to happen given enough incentive?

I see. So you're arguing for softfork. I don't watch the mailing list lately, I think since the Linux foundation announced they will be shutting down their mailing servers. If I recall right, you were active in bitcoin-dev, so let me ask you, is there discussion about implementing a softfork for this very purpose? I mean serious consideration, not just beating the air.

No, it will happen anyway, even if you don't "censor" any transaction. It depends if UTXO-level batching will be there or not. If it will be there, then many UTXOs can be summarized into single ones. But if not, then the network will be flooded, and pruned nodes will suffer from that attack. Which means, the "fix" for Ordinals should also "fix" that issue, and its consequences. In other case, the situation would be only worse.

There are better ways to attack the network, but I don't want to help the attackers by publicly revealing those ways. Also because some of them cannot be used, as long as some "fixes" for Ordinals are not yet applied.

Every soft-fork causes that. It would be no worse, but in what other way you want to upgrade the network? The current software is not resistant to Ordinals attack, which means, that any patch will cause a potential split. But if Proof of Work will follow, then no split will happen (or rather: every split would be called an altcoin, because those users would use hard-fork to stop the "patch").

If something is needed for consensus, it will be processed. It is only about ignoring OP_NOPs. And also, "potentially genuine, non-Ordinal content" can be standardized. And then, standardized transactions could be batched.

Because of double SHA-256, you can just keep the result of a single SHA-256, and validate it in the same way, as OP_CHECKDATASIG would work. Also, you can apply any kind of zero-knowledge proof, which means, if that would be shorter than the data inside Ordinals, then you can replace it in that way.

Another thing is that you only have to verify the chain of signatures, to the nearest coinbase transaction. Everything below that, was turned into fees, which means, the same transactions could be re-created on any other compatible chain, out of different fees. And if a given coinbase transaction is "sufficiently confirmed to be spent", then everything below that also is.

And if you have all coinbase transactions, and all "coin flows", then you can be sure, that no coins were produced out of thin air. You don't need historical "everything turned into fees" transactions to prove that the chain of signatures is valid. And it can be a standard procedure to "turn coins into fees, claim them in the coinbase transaction, and restart the chain of signatures", just to compress it further, when needed.

That is probably what's going to happen if you attempt to censor Ordinals. The Ordinal users will find another loophole, and flooding the UTXO set is their last resort.

That is actually an interest approach. However:

- That will split the network in terms of clients, similar as to how anti-segwit and segwit nodes operate separately (e.g., anti-segwit nodes ignore witness).
- Everything inside OP_NOP will be ignored, including potentially genuine, non-Ordinal content.

Also, how can you verify the signature hash if you don't have the full message?

For example UTXO flood. And of course, there are worse things than UTXO flood, but some bugs are not yet disclosed, and there is no reason to reveal them now, if nobody is affected yet (because we don't have UTXO-based Initial Blockchain Download yet, and some attacks can be applied only if you apply some "fix" on Ordinals, and each attack vector is dependent on your exact "patch").

Why? Nobody stops you from having that data, and storing them on your drive. The problem is when you serve those data to the users. Which means, if you have full node for yourself, and pruned node for the outside world, then you are safe from DMCA complaints, because then you don't serve those Ordinals.

It is only true, as long as Initial Blockchain Download requires downloading everything. But it doesn't have to be the case. It is possible to check only signatures for Ordinals, and skip their data entirely. They are just huge OP_NOPs. But if you can verify signature hash, then you don't have to store signature data.

Of course, if you use only pruned node, then there are some disadvantages. But if you have only pruned node, exposed to the public, and there is some full node behind it, then you can handle everything fine. Because the strength of Ordinals lies in the assumption, that their data will always be available, no matter what. And the key to stop that attack, is to break that assumption. And how to break that assumption? By stopping serving that data, and by implementing Initial Blockchain Download in another, simplified way.

And of course, there could be better ways to deal with Ordinals. But as long as nothing is done, to stop that attack, then pruning is the only widely-deployed option, that you can safely use. At least for publicly-exposed nodes, because of course, you can still have a full node for your personal use. But making it public is now more risky, than it was, so I guess more people will do that, if no other solution will be deployed.

Like what?

This sounds like a really bad idea. First things first, my full node only serves them bandwidth-wise. It does not act as their Ordinal explorer. If I don't serve them bandwidth-wise, someone else will, probably mining pools or just people who would rather buy a good Internet connection and a terabyte drive than their 1000th Ordinal.

Secondly, suspending my node's access to the blockchain for the sake of the Ordinals sounds like an actual defeat. Pruning comes with disadvantages on an individual level and we all know about it.

Literally true and is hypocritical just to see some members of this forum being supportive of this trash, claiming bitcoin is for everyone and everyone has what they want to do with it, were as this is far from what was written in the white paper and Satoshi spoke about this here on btt :https://bitcointalksearch.org/topic/m.28917 while if you speak about this some will say bitcoin is bigger than Satoshi now, like are you all not ashamed, after speaking is Bitcoin or Bitcoin and now have more from using it for your daily transactions, the altcoin you critise one time is what you use now and some still have the full courage to say Ethereum has a larger number of individuals using it for transactions than bitcoin, where as we already know that Blockchain is flooded by dev mainly creating scam tokens and NFTs and  victims of these scam.

The fact is that they don't actually care much about Bitcoin except from making more money, as long as nothing affects this, then they see Bitcoin as just fine and OK even after all they have spoken about altcoins and CEX, they are not ashamed to run to them (hypocrite). I guess Bitcoin is for everyone to them doesn't include those that use it for small transactions

We can also severely penalize storing arbitrary data on the blockchain by making witness data starting with OP_FALSE OP_IF taxable as standard OP_RETURN bytes.

Luke-jr tried to merge the commit, but failed because there was too much bickering on the Github issue. Also the commit didn't even work anyway (it failed its Continuous Integration tests).

Of course. For example, altcoins like Grin, are resistant to those attacks by design. If you have only public keys and signatures, then that kind of chain is resistant. And if public keys and signatures are combined, and finally you have just a block with one huge transaction saying "consume all of those M inputs, and produce all of those N outputs", then there is no room for that kind of attack, because transaction data would be stripped during Initial Blockchain Download anyway.

Just read the whitepaper "7. Reclaiming Disk Space". Imagine that it is applied on the level of Initial Blockchain Download. Imagine that the chain of signatures is checked only to the nearest coinbase transaction, and everything else is confirmed by Proof of Work. It can be done, we are just not there yet.

Of course, it is possible to introduce UTXO size limit, in the same way as block size limit was introduced. And to have a fully-functioning chain, a single UTXO is all you need, to build a working sidechain, and just move it forward from time to time.

Of course it is possible, if you stop serving that kind of data from your node. Which means, you can serve signatures, and stop on that. Signatures are correct, so you can move forward. If you want to get more data, then run your own node. And if you think that people will post data inside signatures, then note that signatures can be combined. So, if you can join transactions, then that kind of chain is resistant to inserting data. Because then, you can just cover batched transaction with enough Proof of Work, as a part of consensus rules, and move forward, without caring that some data was lost in the process. And to preserve some proofs, you can always commit pruned data into batched version, to keep normal users unaffected.

This is what could be worse than Ordinals. And this will happen in the future, unless some UTXO limits will be introduced (for example: maximum N new UTXOs per block, or: consume M UTXOs to create N UTXOs, or: transaction fee, based on the number of UTXOs consumed and produced, or anything like that).

Edit: You can argue, that it is possible to flood the network, just by putting data in unspendable public keys. But again, it is possible to prevent that with Pedersen Commitments. For example:
And then, imagine an attacker, flooding the network with " " entries. First, that attacker will quickly run out of money. Second, all of those transactions will be joined into some "rct", flying on-chain, from which it would be possible to take "a" coins, by using "x" key. That means, you can attach and detach any set of keys and amounts, from that kind of address. The only missing part is introducing some new sighashes on Taproot, and allowing users to spend those coins in this way, and making sure the design is "cryptographically secure".

So yes, it is possible, but just nobody implemented it yet.

I completely agree. But I think once illegal stuff is pushed on to the Bitcoin blockchain (if it has not been, already) then the community and especially devs will be under much heavier pressure. I think that will be the point during which finally some progress will be made towards ending the entire madness called ordinals.

I am actually surprised that this whole issue managed to hang on to life for almost a year now. I would have really thought that the situation would be fixed by now. I guess people view Bitcoin more of a storage of value than a method of transaction. Otherwise people would be fighting much more actively against higher transaction fees...

 

not that true for scrypt.  but for other coins very true.bitmain has always pushed dollars per watts and that any coin will do..

My goal if to have Sha-256/scrypt/gpu and switch on and off to what ever works best.

because I am thinking they are shoving us that way.

do I like this no but do I see it yes.

But is it even technically possible to prevent such an attack on Bitcoin? I am not talking about witness data or OP-RETURN, but speaking of the UTXO set where even pruning is not an option. This "exploit" has been there since the inception of BTC. It's impossible to stop people from putting ALL types of data that we don't want. Of course, it gets easier and cheaper with the current implementation, but what has changed in that regard?

From an attacker's standpoint, wouldn't it be cheaper to just insert illegal or copyright content into the UTXO set and spend all these millions that are otherwise going to the miners in suing wallets and exchanges, forcing them to shut down their nodes?

Also, to what extent is such an attack even feasible? Where I live, by law, I am only obliged not to sell illegal content. If my PC was searched by the authorities and they found some copyright violation, there is nothing they can do to me. It's perfectly legal as long as I am not making money out of it. I can put some cracked software on a pen drive and send it to anyone, and I would still be operating within the legal boundaries of the law. Many countries don't deal with copyrights the way the U.S. deals with it. Is it feasible for Nintendo to go after everyone who runs a full node? Do the attackers really think they stand a chance to kill BTC taking that route?

I personally don't think that is doable. I also don't think that Ordinals/BRC-20 are an attack "by design". It's possible that the attack is a probable byproduct, but the main purpose is profit. I think calling them scammers would fit more than calling them attackers (speaking of the devs behind all of this nonsense NFTs/Ordinals/BRC-20 on all platforms), and they feed off the greed that many people think they can sell the scam to someone else at a higher price sometime in the future.


I believe the reason why other algorithms have a better earning ratio in terms of both power and cost is the fact that a tight equilibrium is hard to reach on them. Simply put, not enough investors trust those coins. In contrast, with BTC, it's the exact opposite. If your $1,000 investment in a BTC ASIC miner makes you $100 a month in profit, you know it would take way too long for that $100 to turn into 0. On the other hand, if that same $1,000 investment makes you $200 a month on another algorithm, you know that it won't take too long to get to $0. It's basically the higher the risk, the greater the reward. I think of mining altcoins as bond class B and BTC as bond class AA. The former is likely to net you more profit but is also more likely to make you lose more.

because this is to crush btc maxers

basically this is all about  power into wealth..

so if you only care about wealth per dollar and you mine you will switch to other pow coins.

just look at LTC/DOGE vs BTC. what is harder to attack via flooding with data

 So if you want all your pow to  be BTC it is tough risk