Removing OP_return limits seems like a huge mistake

[d5000]

Are you talking about public keys with a proof of knowledge of the private key (i.e. a signature) ?
While you can set some output bits by grinding, that would not a little bit less, but MUCH less.

Seems you're correct, I've re-read the relevant part of the mailing list discussion and here Peter Todd argues that it would make the "fake public keys" approach about 6-7 times more expensive regarding fees. But the downside is that according to another post by Sjors Provoost, here, the sizes of the output scripts would increase "dramatically":

To stop that, you'd have to introduce a rule that only allows spendable public keys to be put on chain. Afaik, the only way to do that is to require a signature. That would dramatically increase the size of all output scripts.

So, to deter spam, we would have more bytes in the blockchain, even in normal "financial" BTC transactions  Basically we would be spamming all the time, only to control that only the "correct" data is published.

(Shower thought: could these signatures perhaps eventually be pruned? Edit: What I mean here - in some altcoins there are "temporary" data fields and transaction types which "expire" at a certain block height so they don't need to be downloaded in the IBD after a certain height has been reached. I guess they are not directly hashed for the tx hash/txid -- otherwise they would always be needed --, but a short hash of it.)

I would not be against such measures if they are well thought out, but making all transactions bigger doesn't look to me that it makes sense.

Ordinals and similar protocols typically come and go like other kinds of fads. They depend on other factors like the current size of the NFT market, and it's possible that NFTs are eventually seen as an outdated concept. I have seen that there are now again more BRC-20 (Ordinals tokens) transactions on the blockchain, but that is probably because they're now using 1 sat/vbyte phases to simply "try out things". Once they see that there's not even profit anymore with that method, also this wave will probably die out.

[tvbcof]

...

For various of the on-chain transactions I perform, I would prefer they be processed by non-commercial mining operations (especially in light of the above.)  Assuming some sort of a trustworthy coordination platform, would it be practical to pay minimal or no fee, but instead pay a relatively large sum to an address which would be distributed to the kind of miners which I prefer (e.g., people running bitaxe like devices in their homes and coordinating with processor)?  Are such efforts underway or functional?

I don't think such thing is possible, unless you only share your TX with those non-commercial miners and wait for them to mine a block and include your TX manually.

I don't see a danger in the transactions being picked up (or mined) by generally dis-favored miners since there is little reason for them to do so, and if they for some reason did, great.

For a lot of (but not all of) the on-chain transactions I perform, it really doesn't matter to me how fast they are mined (within reason.)  Or even if they fail completely in some recoverable way.  It's been a philosophy of mine since the GPU days that profitability is always going to approach zero so, in financial terms, it's as effective and a lot less work to just purchase BTC.  Participating in the system (mining, node operation, etc) would be to me a thing to do as/when the system needs it.  As larger pools take over and engage in practices I don't like, that is the time to get active.

As mentioned, if mining trends toward zero profitability, and one is only competing on such things as energy costs, suplementation from other sources becomes a big or dominant factor in profitability.  It's why they will mine trash into the blockchain so it seems...and such has been predicted since the early days.  The basis for my(*) idea is to do the same form of supplementation and in favor of miners who are doing things I agree.  Esp, being independent and autonomous.  One of them would certainly includes applying filter sets which I agree with.  Call it 'fighting fire with fire'.

From my recent research, it seems like mempool coherence is one of the things which 'core' would like to work toward, and for understandable reasons.  My(*) 'games' (which include increased use of filter sets) would probably fuck that up.  This is lamentable, but in my mind kind of in the same category as the pragmatic arguments they are making about aspects of the OP_RETURN limits.

* I doubt that they are 'my' ideas and they are very basic and obvious even if they are.  It is the case, though, that I have held some of them for a long time, and some of them account for my rather unusual views that it's OK if on-chain fees are super high and there are subtle advantages of having the system be 'inefficient', slow, and unpredictable.

There's also limitation regarding those miner joining mining pool, where AFAIK most of them owned by for-profit company.

For my part, I would tend to prefer to foster solo miners (who maintain their own blockchains and mempools.)  To the extent that they formed a 'pool', it would not really be in the same category as most.  The service itself need not be non-profit.  It would mostly just needs to have high quality transparency to give users and miners the confidence to use it.

[gmaxwell]

Are you talking about public keys with a proof of knowledge of the private key (i.e. a signature) ?
While you can set some output bits by grinding, that would not a little bit less, but MUCH less.

Seems you're correct, I've re-read the relevant part of the mailing list discussion and here Peter Todd argues that it would make the "fake public keys" approach about 6-7 times more expensive regarding fees. But the downside is that according to another post by Sjors Provoost, here, the sizes of the output scripts would increase "dramatically":

To stop that, you'd have to introduce a rule that only allows spendable public keys to be put on chain. Afaik, the only way to do that is to require a signature. That would dramatically increase the size of all output scripts.

The prove-its-a-pubkey signature itself can carry data,  if you know the 'private key'  you can completely recover the nonce.  (or vice versa, e.g. a predictable nonce in the signature lets you recover the data hidden in the 'valid' public key).   So in that case you've just moved the storage from one place to another.  Of course the storage is prunable, but so is op_return and witness data.  The 'proof of key' data would be presumably MORE prunable but this starts to feel like hair splitting to me.  I have suggested some more elaborate ways of proving keyness that require massive slowdowns, switch to a far sketchier bilinear group, but which eliminate the signature side channel... but they still do nothing for 'real key' storage.   The work used to grind real keys is also conserved, unless address reuse is banned.

I think tromp underestimates the amount of data you can store directly in 'real' keys without using the proof sidechannel, if you don't mind the receiver having to be somewhat computationally expensive (such as requiring the resources of a fast desktop class machine to keep up with the chain) you can store on the order of 64-bits per output in the key (by DL solving the keys), 8 or more bits in amount LSB.  If you don't mind building up a large stash of coins in your wallet you can store several bits per input in the form of what coins you select and what orders you select them, and so on.   So at best you increase the attackers fee cost by a modest constant factor.   It's not nothing but the cost it comes with in terms of reduced functionality and overhead are considerable.   If they stopped the abuse completely *maybe* you could justify-- but like, say the threat that someone will embed illegal information in order to harass node operators is not going to be meaningfully stopped by making it 5x more costly because they could only store 9 bytes per 40 bytes of output data.

If that 5x increase were 'free' then sure, but you get that only after maybe doubling the amount of data needed to relay txn/blocks, doubling the validation costs, doubling the size of addresses,  and radically handicapping the utility of Bitcoin.  Had Satoshi thought that way payment channels likely wouldn't have been possible (one could try to carve them in since we know about them, but you can't reliably carve in stuff we don't know about).  Besides, a great many people bought in to Bitcoin as programmable money, taking that away is a non-starter particular if it's "we can make some abuse a bit more expensive, without even blocking it".  Bitcoin has already made storing data quite expensive, which already sheds the cost sensitive portion of the traffic.  It's a reasonable assumption that what remains not particularly cost sensitive.

[d5000]

Thanks @gmaxwell for that explanation, really interesting.

I wonder if even on chains like Grin it was possible to store (much) more data than in this experiment, taking into account the possibility to store data in "real" keys, at least with miner cooperation (driven by financial incentives). I don't have enough knowledge about Grin however, and as there a big part of the transactions are pruned it may be indeed much more difficult.

Read about proposals like SwiftSync: https://groups.google.com/g/bitcoindev/c/FpSWUxItXQs

Very interesting link! However I think it would also not be able to cope with the "data on fake addresses spam" problem. I guess just these unspendable UTXOs would delay syncing, and from what I have understood about the matter, without additional data (like a signature) it wouldn't be possible to prove that an UTXO is unspendable. Correct me if I'm wrong

[tromp]

If that 5x increase were 'free' then sure, but you get that only after maybe doubling the amount of data needed to relay txn/blocks, doubling the validation costs, doubling the size of addresses,  and radically handicapping the utility of Bitcoin.

This spam resistance is free in Mimblewimble chains, where amounts are hidden inside Pedersen commitments and their nonnegativity, as well as knowledge of blinding factor, is proved with a rangeproof, while all spent outputs are automatically pruned along with their rangeproof.

Had Satoshi thought that way payment channels likely wouldn't have been possible

Payment channels are perfectly possible on Mimblewimble despite lacking any scripts, thanks to the magic of scriptless scripts.

I wonder if even on chains like Grin it was possible to store (much) more data than in this experiment

That experiment effectively stored a NEGATIVE amount of data in Mimblewimble transactions. In order to locate each 2.5 bytes of data, the extraction needs to know the ID of every kernel in which data was stored, and their correct order. The data extracting program [1] uses 70 bytes of source code to locate each 2.5 bytes of data.

This shows the huge challenge of storing data on a Mimblewimble chain that destroys all ordering information of outputs and kernels in a block.

[1] https://github.com/NicolasFlamel1/MimbleWimble-Coin-Arbitrary-Data-Storage/blob/master/main.py

[MeGold666]

This would need to be fixed at the protocol level to make it impossible

If that's the case, then I wonder, when Monero will fix it: https://mordinals.gitbook.io/handbook/how-does-it-work

Are there any plans to ban Ordinals from Monero?

The only resistant chain I know of is Grin, because users cannot control, how their data pushes will be represented on-chain, so they will be shuffled in the process, which will make them useless.

It has already been fixed by limiting the size of the tx_extra field to 32 bytes (if I remember correctly), I think it has discouraged spammers.
I could only find 2 years old mordinals through Mordinals explorer.

Of course, there will always be the possibility to encrypt data in fields that are not designed for it, even in the transaction amount itself.

In Bitcoin, with its fixed block size, the problem is more severe and impacts regular users who just want to transact, resulting in higher fees and longer queues to be included in a block.

This would need to be fixed at the protocol level to make it impossible - and we all know nothing will be done.
From what I've read on GitHub, there is a solution for it, but people argue it shouldn't be implemented, and every discussion on the topic is eventually closed.

Can you share discussion link which makes it impossible, including misuse of address and public key to store arbitrary data?

*Possible* - I don't know if it fixed all the possibilities, but it certainly addressed the main one that was being abused.

https://github.com/bitcoin/bitcoin/issues/29187

Their conclusion to the exploited protocol hole:

This CVE is disputed. The large majority of contributors to this project disagree this is indeed a security vulnerability. I personally believe the CVE system is being abused in this case.

I believe this issue should be closed. There is no point in keeping it open.

 

Some of these "contributors" who refuse to fix the issue have been found to be connected to Ordinals, making money either directly or indirectly by forcing users to adopt their Layer 2 "solutions."

[ABCbits]

This would need to be fixed at the protocol level to make it impossible - and we all know nothing will be done.
From what I've read on GitHub, there is a solution for it, but people argue it shouldn't be implemented, and every discussion on the topic is eventually closed.

Can you share discussion link which makes it impossible, including misuse of address and public key to store arbitrary data?

*Possible* - I don't know if it fixed all the possibilities, but it certainly addressed the main one that was being abused.

https://github.com/bitcoin/bitcoin/issues/29187
--snip--

That link primarily talks about stopping OP_FALSE OP_IF ... OP_ENDIF used by Ordinals. The other mentioned solutions doesn't stop most other method to add arbitrary data, which mentioned on this thread multiple times.

[Wind_FURY]

is there an actual roadmap proposed in how to filter those transactions?

No, there are only some ideas, related to dropping historical data. Which means, that no matter if something is a real payment, or some kind of data push, it can be stripped in a similar way. And then, transaction makers are mostly unaffected, because usually they care only about the final destination of their coins, while data pushers will cry, when they will find out, that less and less nodes are willing to share their pushed data, when they start providing proofs, instead of sharing original data pushes.

If there's no concrete plan, then the other parts of your post that were not bolded, DOES NOT matter.

Almost every block is full of low quality images:

https://mempool.space/

https://ordiscan.com/blocks

And some people are still arguing that everything is OK. 😄

I believe no one is saying that it's "OK", but what can you actually do? They paid the fees and didn't break any rules.

The network is open and permissionless, by the way.

¯\_(ツ)_/¯

Filtering transactions by miners equals censorship and I doubt any miner would filter this out when they pay big fees for this junk to be included.

Congrats, now you know how everything in the network actually sticks together.

[ibminer]

~
That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

That's one of the reasons for transaction fees.  There are other things we can do if necessary.

This may be slightly off-topic and going back to a different time period here, but I am curious if Satoshi ever elaborated (privately or publicly) on the "There are other things we can do if necessary" comment here?

[d5000]

That experiment effectively stored a NEGATIVE amount of data in Mimblewimble transactions. In order to locate each 2.5 bytes of data, the extraction needs to know the ID of every kernel in which data was stored, and their correct order. The data extracting program [1] uses 70 bytes of source code to locate each 2.5 bytes of data.

Yes, I knew about that. That's why I'd be interested if there were attempts which were successful in the sense that non-negative storage was achieved, even if it was expensive.

I wonder however: couldn't be the same techniques to use for "scriptless scripts" also work for data storage?

*Possible* - I don't know if it fixed all the possibilities, but it certainly addressed the main one that was being abused.

Please do your homework and read either this thread or the mailing list discussion (at least the first message there). One has to repeat and repeat things like a parrot it seems As ABCbits already wrote the main problem is that besides from OP_RETURN there are more harmful ways to store data. The way you mentioned (Taproot witness abuse) is only slightly more harmful than OP_RETURN, but the remaining case, fake public keys, is the real problem -- if we had a real spam wave with these techniques, this could become a serious problem for decentralization due to UTXO set bloating.

BTW thanks @uint512_t for the nice analogy:

[...] breaking into computers or spamming protocols is as bad as breaking into other people's houses.

Let's say we stay with this comparison: your node resources are your "house" and those "breaking in" are the data spammers. In our analogy, they are intruders which use your house for their benefit as a storage deposit. Now let's see how the different methods affect your house:

1) In the case of OP_RETURN, the intruders break in into your house and deposit a big thing like a grand piano in a place where you can ignore it, like your cellar. Of course it's annoying that you now have less space there. But it doesn't get in the way that much and you can remove it after a couple of days (=pruning), and if technology advanced a bit more (=alternative blockchain storage methods), you could remove it almost instantly.

2) In the case of "fake public keys", the intruders also store a piano of ~ the same size in your house, but they put it in your living room where you can't ignore it. Not only that: they also place a smaller upright piano into your kitchen (the UTXO set). You can remove the grand piano in the living room after some days like in the OP_RETURN method (=pruning). But the piano in the kitchen will be there forever, getting constantly in the way when you want to cook.

3) In the case of the Taproot exploit, it's a bit like a lottery. If the intruders are professional "piano spammers" the situation is similar as with OP_RETURN. But many aren't that professional. So they may also leave a piano in your kitchen (if they create dust outputs with their transaction).

Now the big problem: You can filter methods 1 and 3 (sort of), but not method 2, which is the most annoying one.

If the (armed) intruders are knocking on your door, wouldn't you beg them to use method 1 or 3, so at least you can use your kitchen in peace? That's what the devs would be doing if they remove the OP_RETURN limit.

[stwenhao]

I would use my arms to defend myself

The problem with this approach is that they can cooperate with those, who installed keys to your doors, so they can install the piano anyway. And then, you can try to find a better home, or change keys to your house (while also forcing all of your neighbours to do the same thing).

Or, speaking without analogies: spammers can still cooperate with miners, and use as inefficient methods as they want. And then, you can change the coin, or 51% attack it, and reorg the spam.

If there's no concrete plan, then the other parts of your post that were not bolded, DOES NOT matter.

Well, in the past I thought, that many people want to have a coin, which works as a payment system. But now I know, that many people want to spam the chain, and see no problem with that (including some developers). And in that case, I am not the one to save those, who want to hurt themselves in the long-term scenario. Then they deserve it, and they should use today's methods of spamming, because they are far from the worst, what can be done.

So, if the community want to have a spamchain, instead of blockchain, then it is their choice. You can still improve your node, and be somewhat resistant to the spam, if you really want. And the rest of the users, who want to process the spam, should be left, where they currently are, because then, it will be easier to remove it all at once, if spammers will commit to some bad design decisions, and build some protocols on top of that.

To sum up: there is a plan for non-spammers, who want to have a payment system. For everyone else, there is spamchain. You, as a user, can run any software you want. It is your choice.

[d5000]

I would use my arms to defend myself

I somewhat expected this answer and was about to write about that but I thought it was too trivial, but in hindsight I should have mentioned it.

So in my example, you simply do not have ways to defend against method 2. Period.

The only way to really defend is to drastically change the transaction format, to something like Grin's. This would come with a lot of side effects.

To sum up: there is a plan for non-spammers, who want to have a payment system. For everyone else, there is spamchain. You, as a user, can run any software you want. It is your choice.

Which is your plan, run Knots?

Again, you would then incentive the more harmful spam, the "fake public keys" spam.

[stwenhao]

but never any ideas on how to defend a computer

I already told you how: https://groups.google.com/g/bitcoindev/c/FpSWUxItXQs

Nothing is enforced. That kind of things will be optional. As long as you want to have a full archival node, and store everything, including a lot of spam, then you will just run the official version, with the default settings.

And if you will need to have some spam-resistant node, then you will use a different version, which will be compatible, while also rejecting spam, or at least not storing it permanently (or even not downloading the spam at all, and processing some proofs instead). Your node, your choice.

So, do you have a full node? Do you have a problem, to sync it here and now? Because guess what: people are lazy. As long as nodes are not crashing, as long as disks are big enough, and as long as node operators are not sued, because of broadcasting copyrighted material, and as long as nodes can verify the chain faster, than it is made, then nobody cares. People will start to care about spam, and fix things, when they will be directly affected (and many users from forums or exchanges won't be affected at all, because they already use SPV wallets, or they have many altcoins, and they don't care about Bitcoin as a payment system, but care more about blockchain as a solution for all problems in the world).

So, are you affected here and now, to introduce some solutions? If you are, then you can help to discuss or build some of them. But they won't be globally enforced, because the majority wants to have a spamchain, so the spam-resistant version won't be enforced on everyone, as long as spammers have enough resources to keep spamming, and cooperate with spamming mining pools.

Edit:

Again, you would then incentive the more harmful spam, the "fake public keys" spam.

You don't have to download, store, or otherwise process some data, if you don't want to. You can process it once, and then forget about it, and only keep some lightweight proofs on your side. Or: if your security model allows for that, you can just download the proof from another node, and don't bother with downloading the original data at all.

Which is your plan, run Knots?

No, I would stick with the original node, but I want to run it in a more lightweight version. In the past, I had some full nodes. I even had some pruned nodes. But now, I think about setting it up differently, because it seems to be more and more risky, to process all of that spam, and distribute it everywhere in a P2P way.

Also note, that the official client won't force you to use it in the default way. You can do many things. Your node trusts the data you fill it with. Which means, that you can still use a lot of functionalities of Bitcoin Core, without storing the full chain, or even without having the full UTXO database. But does it mean, that everyone should do the same? Definitely not, it is only a path for those, who care about resources, and want to control them better.

[tromp]

That experiment effectively stored a NEGATIVE amount of data in Mimblewimble transactions. In order to locate each 2.5 bytes of data, the extraction needs to know the ID of every kernel in which data was stored, and their correct order. The data extracting program [1] uses 70 bytes of source code to locate each 2.5 bytes of data.

Yes, I knew about that. That's why I'd be interested if there were attempts which were successful in the sense that non-negative storage was achieved, even if it was expensive.

Not only have there been no successful attempts that I know of, I'm having trouble thinking of a good way to do so. But I am curious to see if other people can come up with one.

As a way of encouragement, let me offer a $100 reward for any scheme to store (10KB + X) of arbitrary data on a pure Mimblewimble chain using at most 100KB of total transaction size + X extraction data size, with extraction running fast and not revealing keys that allow the pruning of stored data. This corresponds to a >= 10% storage utilization rate.

The reason for quantifying extraction data is to make sure the scheme can scale up by chaining, for instance to storing (100KB + X) of arbitrary data by using at most 1000KB of total tx size (the basis for calculating fees) plus the same X extraction data size.

I'll double the reward for an actual demonstration on Grin testnet or mainnet.

I wonder however: couldn't be the same techniques to use for "scriptless scripts" also work for data storage?

There's several ingredients to scriptless scripts. One is the flexibilty of Schnorr signatures for uses like multiparty signatures or threshold signatures. Or for use as adaptor signatures, which relate on-chain signature scalars to off-chain signature scalars. With 3rd parties having no access to the latter, I fail to see how this can provide for any on-chain storage. Another ingredient is kernel locktimes, which provide around 24 bits of storage for chosing arbitrary lock times in the past. Which is only about 3% of the kernel size, so still rather limited.

[MeGold666]

*Possible* - I don't know if it fixed all the possibilities, but it certainly addressed the main one that was being abused.

Please do your homework and read either this thread or the mailing list discussion (at least the first message there). One has to repeat and repeat things like a parrot it seems As ABCbits already wrote the main problem is that besides from OP_RETURN there are more harmful ways to store data. The way you mentioned (Taproot witness abuse) is only slightly more harmful than OP_RETURN, but the remaining case, fake public keys, is the real problem -- if we had a real spam wave with these techniques, this could become a serious problem for decentralization due to UTXO set bloating.

Calm down, my friend. I'm just intrigued that, even though there is obvious exploitation and a known fix for one of the ways the network can be is spammed, some people are still against taking any action because - you know - it's "permissionless":

The network is open and permissionless, by the way.

¯\_(ツ)_/¯

...so we should allow whatever spammers want to do with the network, as long as they pay the fees.

I think the real problem here is not finding a solution - because, as we can see, they are not being applied - but the broken consensus around updating the protocol and priorities of what Bitcoin was supposed to be - Digital Cash, and not Digital WhateverYouWant...  

I have a feeling it's all due to the fear of a falling block reward and insufficient network fees to cover expenses, so they don't want to remove any source of revenue - even if it comes from abuse.





Meanwhile, the Bitcoin code looks like Swiss cheese...

[NickofTime]

I'm not tech savvy enough to make an opinion on the changes to OP_RETURN, but I do see a problem with the way these changes are being approached. Peter Todd's pull request was revived precisely after Citrea's whitepaper release which indicates a need for at least 144 bytes on OP_RETURN. [page 18 https://citrea.xyz/clementine_whitepaper.pdf] And Mr Todd himself mentioned Citrea as one of the reasons for the PR revival. So it's difficult to say anymore if the motivation for the changes came from Citrea or for the benefit of Bitcoin. And if it came from Citrea, why is a private company working on L2 tech putting its nose in base layer development?

[tvbcof]

I'm not tech savvy enough to make an opinion on the changes to OP_RETURN, but I do see a problem with the way these changes are being approached. Peter Todd's pull request was revived precisely after Citrea's whitepaper release which indicates a need for at least 144 bytes on OP_RETURN. [page 18 https://citrea.xyz/clementine_whitepaper.pdf] And Mr Todd himself mentioned Citrea as one of the reasons for the PR revival. So it's difficult to say anymore if the motivation for the changes came from Citrea or for the benefit of Bitcoin. And if it came from Citrea, why is a private company working on L2 tech putting its nose in base layer development?

Seems to me that in order to have an L2 of any form, you must 'put your nose in the base layer', informationally, development-wise, 'spiritually', etc.  Since I have long considered L2's to be what will make Bitcoin itself viable, that doesn't offend me a lot.

From a user perspective, I intend to support L2s which are designed with the intent of being a net benefit for Bitcoin and dis-favor (if not attack) those which are not.  I do not have an opinion of Citrea because I've not studied it.

[d5000]

You don't have to download, store, or otherwise process some data, if you don't want to. You can process it once, and then forget about it, and only keep some lightweight proofs on your side. Or: if your security model allows for that, you can just download the proof from another node, and don't bother with downloading the original data at all.

I agree that a different IBD/storage solution would be the probably part of the solution. But the problem remains: How does a full node distinguish a "fake" public key from a "real" public key?

AFAIK SwiftSync (I have only read the OP of the SwiftSync mailing list discussion and the Delving Bitcoin OP, so I may be wrong) only checks for already spent UTXOs, so it would never see anything in the "fake public keys" which they could ignore. Instead, the more fake public keys exist, the less efficient SwiftSync would be.

Relevant quote from Delving Bitcoin:

The idea is to only ever add coins to the UTXO set if we know that they will still be unspent at a certain block height N.

Source: https://delvingbitcoin.org/t/swiftsync-speeding-up-ibd-with-pre-generated-hints-poc/1562

I'm just intrigued that, even though there is obvious exploitation and a known fix for one of the ways the network can be is spammed, [...]

Exactly, there's a fix for one of the ways. But this way is not the most harmful one. Highly likely that if Ordinals got "closed" by such a filter like the one in Knots, the NFT crowd would switch to Stampchain, and then we would have a "real" spam problem.

So what's the point of "fixing" a script with a quite questionable method (a heuristic filter which only matches an exact combination of opcodes) if then the problem could get even worse, even if spam halves (measured in kB/block) as a consequence of the "switch" to Stampchain, 50% of the spam on Stampchain-like "fake public keys" would be probably still more resource-demanding to full nodes in the long run (and worse -- it increases with time!) than the current Ordinals data volume.

Your conclusion about Bitcoin consensus thus is simply wrong. Over & Out ;P

I'm not tech savvy enough to make an opinion on the changes to OP_RETURN, but I do see a problem with the way these changes are being approached. Peter Todd's pull request was revived precisely after Citrea's whitepaper release which indicates a need for at least 144 bytes on OP_RETURN.

Citrea was indeed what started the discussion in the developer mailing list. Just because their "workaround" around the OP_RETURN limit is currently spamming the UTXO set with "fake public keys" in their transactions (although on a very small scale compared to Ordinals Stampchain). The idea was to nudge them to use OP_RETURN instead (removing the limits), which would be less resource-hungry for full nodes.

That's the whole "Citrea issue". Building a "Core corruption story" around that is quite lame, I think.

And thus I'm very disappointed from those developers who are now fueling this anti-Core shitstorm. Because they should know better.

[BayAreaCoins]

I do not have an opinion of Citrea because I've not studied it.

I've bridged 10 Testnet over into "cBTC"... which just feels like an ETH altcoin.  I don't mind it, but I won't us it on mainnet.  I think Bitcoin is scaleable in centralized systems much more efficiently and it's cheaper for the user (or at least me).  Been there, done that.  Cool, go for it, but not for me.

All of the services attached to Citrea seem to be open source stuff and none of it is actually turned on.  Everything is "coming soon"... thus far, I haven't actually found a way to try to blowup some of these NFT's or other various potentially large spam items ass out of the water using their testnet work.  (I've possibly just not found it yet, I'm still searching.  It should be obvious on the blockchain when I find something I can abuse.)

Has anyone else had any luck using Citrea bridged Bitcoins to create spam?  If so, I'd really appreciate a link to a working app.  Thanks!

Citrea was indeed what started the discussion in the developer mailing list. Just because their "workaround" around the OP_RETURN limit is currently spamming the UTXO set with "fake public keys" in their transactions (although on a very small scale compared to Ordinals Stampchain). The idea was to nudge them to use OP_RETURN instead (removing the limits), which would be less resource-hungry for full nodes.

That's the whole "Citrea issue". Building a "Core corruption story" around that is quite lame, I think.

And thus I'm very disappointed from those developers who are now fueling this anti-Core shitstorm. Because they should know better.

You realize that Bitcoin Contributors helped beat the system and then said "hey look, we can beat the system, we should change it anyways!" All while getting "$15 million dollars" too!  They also rekt Testnet 3, or tried. (which I get no one cares about this, and I don't either, but it is still interesting).

I mean, whatever, but I feel like there should be good enough disclosure so that a person like GMaxwell knows why a proposal made it across his desk.  Esp if it is changes that could potentially hit all of us that choose to continue to support Bitcoin Core. *shrug*. Truthfully, ethics are none of my business, I'm certainly not a leader in that field, and I'm not a fan of rules either.  It still feels kinda gay.

[gmaxwell]

Some of these "contributors" who refuse to fix the issue have been found to be connected to Ordinals, making money either directly or indirectly by forcing users to adopt their Layer 2 "solutions."

Can you justify that claim? Which contributors? in what sense are they contributors? How are they making money from it?

If you can't you should withdraw the accusation-- because it's extraordinarily toxic to the public discussion for people to state this sort of thing as fact and not even justify it so that anyone can check it.  In the past I've found comments like this form turn out to be nonsense, like they just point to idle speculation, or to a "contributor" who one time in 2014 submitted a couple documentation fixes and has no particular sway over anything being merged.

It also just fails on its face because many many people who have absolutely no financial ties to anything "crypto" except for the value of their own coins do not support blocking the transactions.  And it also fails on its face because in Bitcoin's 16 years of life I'm not aware of the project actively blocking *any* form of transaction that was actively in use[1], so doing so would be a radical departure from past history.


[1] the nearest thing I can think of to an exception was the TX malleability patch requiring LowS signatures, and a big factor in the decision to do that was that it was possible to run modified nodes that converted all blocked transactions to acceptable ones without the user's intervention, and Matt and I did that for a couple years.  Otherwise all policy filtering I can think of has always been of transactions that weren't commonly in use or which were already filtered out by other reasons.