Removing OP_return limits seems like a huge mistake

[BayAreaCoins]

This whole thing is bringing back memories of Satoshi Dice.  People, especially of the more Karen-esque type, were apoplectic about it but (after a time) I came to think of it as a net positive thing because A) it's wasn't a problem _due to system utilization at the time_, and B) it was a really great vehicle to induce discussion and development.

In my recent research, I've run across new-to-me faces and philosophies.  That Uzi Wartharmer guy, for instance.  Seems in a lot of ways the Erik Voorhees of the time.  It actually seems to me that under the surface he is one of Bitcoin's more valuable contributors and perhaps deep down, a genuine 'patriot'.  At the very least, he's pretty clued in from a system engineering level, and also pretty funny.  Yes, he's clearly a degenerate spammer as well.  I don't see them as mutually exclusive, but that's just me.

It probably feels like Erik Voorhee because he is also involved in at least the financing of Citrea. Peter Thiel also is pounding butt in this arena as well, he's known for using his funds ethically and openly.  Sarcasm. (I like Peter, but he's a lil greassssyyyyy.)  Source: https://x.com/0x_orkun/status/1851996482020479126

Satoshi Dice is a big part of the reason Dooglus built Just-Dice.com and centralized the dicing because the on-chain spam was bothering Doog. (as I understand and remember)

JD basically took over SD in basically one week.

Dooglus is a fucking legend.  

I have a love/hate for spam, Doog and I have butt heads over onchain small transactions in the past. Considering I'm a faucet owner and I used to do everything on chain for a period of time.  I've been rather "dusty" in my time here.

Doog uses a command in his wallet to ignore transactions he deems as dust, and it keeps him from dealing with a wallet bloating due to a service like me basically DDOSing him with worthless coins credited to his website for playing.  (Again, this happened ~7 year ago, it's hard to remember the details of what he did/does to counter spam)

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

Still searching and no luck.  Everything is "coming soon" that I can see thus far.

[gmaxwell]

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

https://bitcointalk.org/index.php?topic=5539943.msg65360500#msg65360500

https://www.blog.citrea.xyz/announcing-citrea-series-a-round/

https://www.crunchbase.com/organization/citrea?__cf_chl_tk=s6MXndaBfxqcylwLvv9ED7b5xdQHwxdbHXd1tpqOxm8-1747255016-1.0.1.1-6yQYI.PcobO6exlmhwH0g_SNY38_ZRTBqaFfmwvygHE

Lopp isn't a regular contributor to core and has no more influence than any other internet rando in what gets merged-- a fact you should have been aware of given that it was explicitly pointed out to you earlier in the thread.  And no one has yet come up with a way that this *benefits* citrea-- their stuff just uses fake outputs in these rare exception-case transactions so they don't need opreturn, they only came up because someone noticed that they'd cause less harm to the utxo set if they could use it.   Also the question was about *ordinals*, but thanks for both demonstrating my point and showing that you're not bothering to read the discussion you're responding to.

[BayAreaCoins]

And no one has yet come up with a way that this *benefits* citrea-- their stuff just uses fake outputs in these rare exception-case transactions so they don't need opreturn, they only came up because someone noticed that they'd cause less harm to the utxo set if they could use it.  

Seems like a pretty big benefit to not have to use their work around and just go straight to goal... right?

Less code & BS the better?  (This likely is a reason to remove OP_return as well, perhaps?)

Also the question was about *ordinals*, but thanks for both demonstrating my point and showing that you're not bothering to read the discussion you're responding to.

The original post is about OP_Return.  I think the question relates to my reply.  If you think I'm offtopic, just report my post to a forum mod...

You are either ignorant or a liar, and I think both are unacceptable for a person in your position.

And what "position" is that?

O wait, being a forum mod in this very section is one of your positions, isn't it! . Well fuck me! (lol). Seems like you, me, and everyone else should have known at least one answer to your own weird question. Which is why I eye-rolled you.  

I hate to say this, but your personal pokes at me kinda show how hard your trying to gaslight in this subject for "whatever reason".  I support this, ram this unwanted shitcoin like spam down their throats and show them what the "creators intended".

I maybe stoked to be able to wrap a certain coin and permissionlessly list it on DeFI "easier". It's going to be pretty fun to test on the mainnet.



"By one's own hand"


Go write some code dude.  Actions speak louder than words.

I'm over here trying to use the Citrea "work around" on any of the https://citrea.xyz/ecosystem they have listed and thus far... it feels like the North Korea grocery store scene in The Interview.

Edit:  It seems I found one that works. https://conft.app/wallet/citrea_testnet/0x5f8f7a5edd6867f4322c43f82c8632f4b36e677e/launched

[d5000]

Seems like a pretty big benefit to not have to use their work around and just go straight to goal... right?

Stuffing data into fake outputs seems to be quite straightforward for me. There are already mature tools to use (since at least 2023). Probably they wouldn't even need own code nor maintenance.

If they (and others) use OP_RETURN instead, the main benefit is for the full nodes who don't need to store that data forever in the UTXO set. And for those using SwiftSync who also don't have to care for these UTXOs.

Win-win for everybody, perhaps?

The only guys that lose are those miners who currently benefit from direct fee payments to them from NFTers to bypass standardness settings ... and I do not even think they lose "that" much, because their main income probably is oversized images stuffed into witnesses, not OP_RETURN.

And the only "possible" danger I see is that as someone mentioned earlier a new fad could emerge with OP_RETURN NFTs. That's why I think it would not be the worst idea to first increase the limit a bit (to 200-500 bytes, enough for L2s, but not enough for NFTs) and then if no collateral effects are detected, in a few months up to a year, lift the limit completely.

[nutildah]

This is kind of interesting. About 7 hours ago, Mara mined a block with a single transaction in it, containing 2 OP_RETURN outputs. They paid a fee of 0.061 BTC ($6,313) to occupy the entire block, about 999 kb of data. Apparently its an advertisement for a new protocol that uses OP_RETURN. The message is somewhat interesting (moreso than the jpeg in the other output) and worth a read, but I won't mention it so as not to help them advertise here.

[ABCbits]

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

Since you mentioned Stampchain many times, i decided to re-read it's specification[1]. The base overhead is just 1 input and other parts of TX, while overhead of each P2MS is roughly 1/3 size of P2MS output itself. So if Ordinal become invalid or non-standard, i can agree Stampchain become more attractive for those who want to store more than 80 bytes of arbitrary data at a time.

This is kind of interesting. About 7 hours ago, Mara mined a block with a single transaction in it, containing 2 OP_RETURN outputs. They paid a fee of 0.061 BTC ($6,313) to occupy the entire block, about 999 kb of data. Apparently its an advertisement for a new protocol that uses OP_RETURN. The message is somewhat interesting (moreso than the jpeg in the other output) and worth a read, but I won't mention it so as not to help them advertise here.

It seems their Slipstream service keep gaining popularity. Paying 0.061 BTC ($6,313) to store almost 1MB is very expensive for average people, but it's definitely not expensive enough to discourage certain group of people to add arbitrary data on Bitcoin blockchain.

[1] https://github.com/stampchain-io/stamps_sdk/blob/main/docs/src20specs.md

[stwenhao]

How does a full node distinguish a "fake" public key from a "real" public key?

It does not. You compress and simplify all kind of data, whatever it is. The first level of simplification is having only the UTXO set, instead of storing the full chain, which is already implemented as pruning. The second step you can do, is to simply compress things, which are made out of repeated data. And then, when you will still have the UTXO set, which would be too bloated, then you can simplify it further, by not storing the entire UTXO set, but only a proof, that a certain output exists.

Imagine that "txid:vout" is your header, and "scriptPubKey" is your data. Currently, if you use pruning, then you store everything from the UTXO set. But: if there will be a lot of spam, up to the point, where the coin will no longer be usable, then you can switch into a different model, where you don't store "scriptPubKey" in your node, but only a simplified proof, that it is there, and it has a given form (for example by storing some kind of hash of it, or other kind of proof).

Which means, that the first step is to encourage people, to put their data behind commitments (to make more room for payments). But if they will still spam the network to the point of being unusable, then we can switch to a different approach: processing a subset of the UTXO set, which is known to be easy-to-process. Then, you can have usable node, where you can still transact, and all other users will be stuck in a spammed network. And then, other users will have an incentive to implement the same changes, just to unblock their nodes.

As I said before: your node, your choice. If the community will spam the UTXO set with hard-to-spend-but-valid public keys, then existing nodes can stay in a spammed network, and the real users, who care about Bitcoin as the payment system, can switch into some simplified nodes, which will allow them to use it again as a payment system. There are many things, that can be done, and which were mentioned here and there (like Scanners), but the current level of spam simply not yet reached levels, where people would care to implement that kind of protections.

By the way: if you wonder, why some solutions are not yet there, then think about it as "anger-driven development". If you make some people angry with the current system (like Satoshi was in 2007), then you can trigger them to write some code, and make it real. But as long as the trigger is not yet there, then people will peacefully use the current thing, because they are not forced, to move humans forward. And the same is true with spamming: there are some ideas, and they will fly as just brainstormed concepts, as long as nobody will make a serious flood, where some developers will be angry enough, to code more protections (first just for themselves, and later it will spread, if regular users will be mad, and start looking for solutions).

[BayAreaCoins]

This is kind of interesting. About 7 hours ago, Mara mined a block with a single transaction in it, containing 2 OP_RETURN outputs. They paid a fee of 0.061 BTC ($6,313) to occupy the entire block, about 999 kb of data. Apparently its an advertisement for a new protocol that uses OP_RETURN. The message is somewhat interesting (moreso than the jpeg in the other output) and worth a read, but I won't mention it so as not to help them advertise here.

Here is their link without clicking

[d5000]

And then, when you will still have the UTXO set, which would be too bloated, then you can simplify it further, by not storing the entire UTXO set, but only a proof, that a certain output exists.

You must still store the proof for each "fake address" output, and that is my point

If OP_RETURN was used, you can still ignore it, and you don't need any proof.

[...] processing a subset of the UTXO set, which is known to be easy-to-process.

How can this be done? I still can't imagine a strategy here to detect "easy to process" UTXOs. Maybe you refer to script whitelisting, what Luke-Jr proposed? But it would still be possible to stuff data into outputs which look like "legit" payments.

(like Scanners)

What are these scanners? Would be interesting to know (scanners is a too generic word to simply google it ...) Something like Token Sniffer, maybe?

Regarding anger-driven development, it may be possible that this would then indeed lead to the solution Todd outlined to detect unspendable keys, which would cripple Bitcoin seriously. And that's what we should avoid, I think...

BTW, this "Non standard token" is hilarious. Exactly what we need: more incentives for miners to offer process non-standard txes for bribes. (The PR would fix a big part of this problem.)

[tvbcof]

...
Regarding anger-driven development, it may be possible that this would then indeed lead to the solution Todd outlined to detect unspendable keys, which would cripple Bitcoin seriously. And that's what we should avoid, I think...

BTW, this "Non standard token" is hilarious. Exactly what we need: more incentives for miners to offer process non-standard txes for bribes. (The PR would fix a big part of this problem.)

If one or more of the various 'fixes' to the extra-destructive spam problems were rolled out, it would actually be quite handy to have an 'escape valve' (e.g., OP_RETURN).  If anyone is actually making money by spamming, they would potentially NOT become a desperate cornered beast if they could potentially just switch over.

Similarly, if the user-base chose to apply their 'fuck with them' budget (filters, preferences, out-of-band rewards, etc) it would probably be cheaper and more effective to do so when the offenders have a practical escape route.

The fact that Bitcoin is on the winning side by realizing a relatively high 'bang for the buck' when people use OP_RETURN is something of an icing on the cake in a environments as described above.

My thoughts on the matter.

[aphetor]

I just wanted to post my thoughts somewhere and share a relevant anecdote from bitcoin++ last week.

I see the motivations against removing the datacarriersize limit as two-fold:

1. “Arbitrary data is not money and bitcoin definitely is money. The extent to which bitcoin [blockspace] can be used as not money is the extent to which it’s bad at being money because they’re competing over the same resources.” (Mechanic)

2. Noderunner’s right to choose what transactions they may or may not want to relay, i.e. “not on my lawn.”

Regarding point 1, the question to me is what exactly constitutes <arbitrary data>? All data that is not directly related to spending coins? Should all arbitrary data be considered spam? Isn’t spam subjective?

I heard Luke Dashjr’s respond to this last question, “No, there’s an objective difference. Bitcoin’s design allows miners to include up to 95 bytes per block of arbitrary data in the coinbase. That is completely different from spam which is encoding this arbitrary data to look like something it is not to deceive nodes into accepting it. If you submit a JPEG as a transaction it will be rejected by every single node. You have to obfuscate it and make it look like something it’s not to make it accepted.”

Regarding point 2, given that Bitcoin Core is the default client used by the vast majority of nodes on the network, removing the datacarriersize limit, would make it more difficult for Core nodes to *easily* limit the size of the op_return field. I take Greg Maxwell’s point here that there is some “serf thinking” involved in that Bitcoin Core does not give you these rights. The Bitcoin Core client is an open source tool that you can choose to patch, fork, and modify as you see fit. I think the defenders of the op_return limit are interested in the *ease* with which someone can make a decision in one way or another. In any case, I’ll leave my conclusions below my story below which I think is a nice illustration of the debate.

There was a project called GarbageMan presented at the bitcoin++ hackathon that forks a Knots node to impersonate a Libre Relay node by setting the node’s service bit to signal to other Libre Relay nodes that it is also part of the Libre Relay network (bit number 29). These Knots nodes, pretending to be Libre Relay nodes, prioritized Libre connections as their preferred peers. This way the “Garbage Men” could infiltrate the Libre Relay network to intercept transactions the Knots nodes consider spam, and throw them away. (Prez: https://www.youtube.com/live/cLLpmbg4KKk?feature=shared&t=2277)

This was an awesome project and clearly a fun jab at Peter Todd, who was one of the judges, the creator of the Libre Relay project, and also who opened the original PR to remove the datacarriersize limit.

Peter Todd’s argument was that filters would be ineffective on the mempool because you could just use services like Libre Relay to get around those filters. GarbageMan is a strike back that filters could be deployed to attack the Libre Relay network as well.

A couple presentations later, another project called MemCooler implemented a parallel straight-to-miner relay (a la Slipstream) over Nostr. Miners announce themselves on Nostr, where transactors can look up, select, and pay specific miners to mine their transactions. (Prez: https://www.youtube.com/live/cLLpmbg4KKk?feature=shared&t=3005)

During the Q&A, Peter Todd asked, “why not do an option that just broadcasts the transaction on Nostr and say hey [miners] please go mine it?”
“Uhmm I guess there is no reason not to do that.” Smile, “Just turn Nostr into the mempool.” Peter Todd, responded emphatically, “Sounds good to me!” then roared, “Let’s go fight GarbageMan!”
(Peter Todd’s Question: https://www.youtube.com/live/cLLpmbg4KKk?feature=shared&t=3344)

I’ve read a lot of Gmaxwell’s thinking on this debate from this forum and on reddit, and I think a lot of this boils down to the fact that Bitcoin is built to be censorship resistant. I totally get that policies express preferences in what transactions are relayed and this can increase friction for those transactions, but I don’t think it’s Core’s job to tool for that. I think the way this has played out with Knots forking Core, keeping consensus rules the same, but adding more options around filtering is a perfectly reasonable outcome. Why not have more clients? I understand that if a lot of people end up using clients that have significant changes around peer-to-peer networking and consensus rules, cough btcd, then that would be problematic, but I don’t think the answer to that problem is that we should resign from running modified, patched, forked or alternative clients…

Finally, if the real issue here is the spam, It seems the only way to definitively filter or block this would be through consensus rules changes or through centralized or homogenized block template creation. If block template creation is more distributed then you’re more likely to have people who mine non-standard transactions and it’s more difficult to gain a majority of mining nodes to only accept block templates of certain characteristics.

Bitcoin’s blockspace is a free market. I think people can and will express their political positions through their nodes, but that it is not Bitcoin Core’s job to outfit them with those tools.

bitcoin++ livestreams:

Day 1
Main Stage: https://www.youtube.com/watch?v=EKQvDfmQkt8
Poolin Stage: https://www.youtube.com/watch?v=nUQlBxWwlaU
Workshop Stage: https://www.youtube.com/watch?v=J9bRVIXOhm0

Day 2
Main Stage: https://www.youtube.com/watch?v=rsMujxqgHeQ
Poolin Stage: https://www.youtube.com/watch?v=F2p_V0svDTo
Workshop Stage: https://www.youtube.com/watch?v=pv429hE3r3U

Day 3
Hackathon Presentations: https://www.youtube.com/watch?v=cLLpmbg4KKk

[gmaxwell]

I just wanted to post my thoughts somewhere and share a relevant anecdote from bitcoin++ last week.

Thanks for your comments!

Regarding point 1, the question to me is what exactly constitutes <arbitrary data>? All data that is not directly related to spending coins? Should all arbitrary data be considered spam? Isn’t spam subjective?

I heard Luke Dashjr’s respond to this last question, “No, there’s an objective difference. Bitcoin’s design allows miners to include up to 95 bytes per block of arbitrary data in the coinbase. That is completely different from spam which is encoding this arbitrary data to look like something it is not to deceive nodes into accepting it. If you submit a JPEG as a transaction it will be rejected by every single node. You have to obfuscate it and make it look like something it’s not to make it accepted.”

That really to me sounds more like luke-jr justifying his historical practice of putting bible quotes and other bitcoin-irrelevant material in blocks.  I don't think it really answers anything.   There are many fields in Bitcoin -- like the entire content of the output scripts of a transaction that the consensus rules don't do anything with, just like the consensus rules don't do anything with the scriptsig of a coinbase transaction (the '95 bytes' the reply refers to).   I've seen no indication that the anti-spam contingent is okay with stuffing arbitrary data into *those* fields.   And it's probably worth remembering the the history of Bitcoin "anti-spam" started with Satoshi dice an "on chain gambling site" (really probably a money laundering operation (see the first and second MTGOX hacker indictment, and dooglus' forensic accounting), but it at least pretended to be a gambling site-- history may not repeat but it rhymes).  Luke created, ran, and distributed patches that blacklisted their addresses and even put the patches into the gentoo distribution of the Bitcoin software, not just his own knots.  

So even if we go back to the very start of anti-spam in bitcoin we can see that it has always hinged on a subjective judgement of the users activity.   The Bitcoin project (now called core) has always eschewed that sort of thinking and tried very hard to make any restriction as content neutral as possible-- even when, or especially when, the contributors didn't like the usage.

At the same time that answer also strikes on why filtering efforts are pretty doomed-- he starts by assuming that the user is willing to disguise their activity as something it isn't.  But that same willingness is why it can't be blocked, or at least the portion of "spam" that really is disguised.

I think in general the term spam is a poor fit. With email spam you win so long as you don't see it, it doesn't matter if your computer sees it or your ISPs computer sees it.  And all this stuff in bitcoin that gets called spam is never seen by anyone who doesn't want it, so by the email definition bitcoin has (almost) no spam.  There is ONE thing in Bitcoin that is very much like email spam:  Dusting.  And yet dusting wouldn't fit in the definition above, as it's not disguised as something it isn't.  It's a payment, just one that you don't want and probably causes you more harm than good.   There is a fair amount of dusting, it seldom generates much complaint. There are things that can be done to deal with it (e.g. wallets not showing the small payments)-- but it seems there isn't much interest in trying.   So I think there is an issue, sure, but spam isn't the right word.

Similarly, op_return traffic isn't disguised. But clearly no one is arguing that it is definitionally impossible for OP_RETURN material to be spam.

I think the thing people are actually mad about today is shitcoin issuance and the fact that people are willing to burn up Bitcoin's capacity on tokens whose value is essentially independent of Bitcoin.  But none of the anti-spam stuff really addresses that, and to the extent that the shitcoin stuff is made more valuable by limited supply, it might even make it worse.

Regarding point 2, given that Bitcoin Core is the default client used by the vast majority of nodes on the network, removing the datacarriersize limit, would make it more difficult for Core nodes to *easily* limit the size of the op_return field. I take Greg Maxwell’s point here that there is some “serf thinking” involved in that Bitcoin Core does not give you these rights. The Bitcoin Core client is an open source tool that you can choose to patch, fork, and modify as you see fit. I think the defenders of the op_return limit are interested in the *ease* with which someone can make a decision in one way or another. In any case, I’ll leave my conclusions below my story below which I think is a nice illustration of the debate.

I'd agree except for the fact that isolated participants setting that setting don't actually have any beneficial effect to themselves.  I don't think the easy of an ineffectual choice is a relevant development criteria.  There is a real cost to users and developers in having more options, and the software shouldn't offer knobs that essentially don't work.    In any case, at least for now it looks like the knob is staying.

There was a project called GarbageMan presented at the bitcoin++ hackathon that forks a Knots node to impersonate a Libre Relay node by setting the node’s service bit to signal to other Libre Relay nodes that it is also part of the Libre Relay network (bit number 29). These Knots nodes, pretending to be Libre Relay nodes, prioritized Libre connections as their preferred peers. This way the “Garbage Men” could infiltrate the Libre Relay network to intercept transactions the Knots nodes consider spam, and throw them away. (Prez: https://www.youtube.com/live/cLLpmbg4KKk?feature=shared&t=2277)

This was an awesome project and clearly a fun jab at Peter Todd, who was one of the judges, the creator of the Libre Relay project, and also who opened the original PR to remove the datacarriersize limit.

I mean it's a sybil attack and probably a CFAA violation, though obviously no one is going to be pressing charges over it.  If anyone cared about it, it's easy to bypass, by simply observing the peers behavior and banning peers that are clearly filtering transactions or going farther and periodically asking peers how much the next block is worth, fetching it if they have something more valuable, and banning them if they can't deliver.

Bitcoin Core already does this for blocks-- basically testing the peers accept the chain they're on, and disconnecting ones that don't and also by slowly probing the entire network to make sure no one has a better chain.   This was implemented because of a similar "pretend to be compatible" behavior put into segwit2x as part of an effort to force nodes into accepting a hardfork by surrounding them and denying them access to a chain they were compatible with.

Librerelay itself mostly seems to be performance art, pointing out that censorship is substantially undermined by even a small amount of parties being willing to route around it.  The point really isn't defeated by an attempt to undermine librerelays rather minimal and half-hearted efforts... and you got to kinda wonder what people are thinking there?  Because while Librerelays point is that censorship is ineffective, the counter's argument is that they can make it effective by trying harder.  Is that really where we are? With supposed Bitcoiners arguing that censorship is effective and cooking up better roadmaps for trying it?

Bleh.

(And sure, I'm aware of the position that the filtering isn't censorship due to some value judgement over the usage, but the tools and methods are the same...)

Peter Todd’s argument was that filters would be ineffective on the mempool because you could just use services like Libre Relay to get around those filters. GarbageMan is a strike back that filters could be deployed to attack the Libre Relay network as well.

Of course, fixing librerelay to punt the sybil attackers takes some code and Peter Todd is not likely to waste too much time on his performance art... But the more fundamental point is that you can (and today the 'spammers' largely do) just give the transactions directly to large miners.  This is just horrible for mining centralization, and at least librerelay was a little corrective pressure against direct miner relationships.

I'm very saddened that people's thinking has become so distorted and in favor of blocking stuff that they don't like that they're cheering what is effectively a sybil attack against an effort that bypasses blocking to avoid creating direct miner relationships.  I'm really glad that Petertodd is a good sport and views that sort of thing as just another interesting challenge.

Finally, if the real issue here is the spam, It seems the only way to definitively filter or block this would be through consensus rules changes or through centralized or homogenized block template creation. If block template creation is more distributed then you’re more likely to have people who mine non-standard transactions and it’s more difficult to gain a majority of mining nodes to only accept block templates of certain characteristics.

Indeed.

Bitcoin’s blockspace is a free market. I think people can and will express their political positions through their nodes, but that it is not Bitcoin Core’s job to outfit them with those tools.

Bitcoin nodes are all about making a statement about what Bitcoin is by literally defining it via their consensus rules.  During the whole blocksize war drama there were a lot of people who just didn't get that.
Part of why they didn't get it is that they were focused on another truth:  When it comes to what Bitcoin does *within those rules* those nodes have little to no influence unless they are mining, and even if mining they have the power to permit without the power to refuse.  The power to refuse comes only from a supermajority hashpower and/or consensus rules. And this is a point that I think today's hyper-bitcoin anti-spam advocates are missing.

The situation would be different, perhaps, if the anti-spam army were proposing consensus rules-- but so far they haven't, and that is no shock because there isn't any rule consensus or otherwise that blocks traffic that doesn't need consensus enforcement and is willing to change its appearance (well not any short of radical changes that would cause massive functionality loss).   They stick instead to policy rules, which at least allow for a perpetual ineffectual game of cat and mouse.  One I think might provide for full employment for filter authors and filter evaders, but be no good for the rest of us.

[mikeywith]

Everyone's freaking out about "spam" on Bitcoin again, like we haven't been through this a hundred times already. Let's go over the so-called "solutions" people keep throwing around like they're going to save the day:

Consensus changes? Not happening, we hardly made it out alive in the last one.

Node-level policies? Congratulations, you've successfully told your node not to forward transactions. Meanwhile, the miners -- the people who actually write to the blockchain -- couldn't care less (except for Luke's pool that lost his miners' dozen BTC for censoring Ordinals' transactions because Ordinals are bad for BTC but writing scriptures on it is good:.)

Relay layer filtering like Libre Relay Bitcoin Knots? cool, now you can filter transactions that still make it to miners anyway.

Block template/miners? ya sure thing, miners would be more than happy to ignore high-paying transactions just because you don't like them.

The harsh reality is: you can't stop people from using Bitcoin in dumb ways if they're willing to pay. Bitcoin is permissionless. That's the whole point. So if someone wants to spend $500 to attach their 30th birthday photo into the blockchain using a fake script, the miners are happy to take their money.

Some folks would rather pretend their personal node is Bitcoin's gatekeeper. "On my dead mempool!", while miners laugh and take the money anyway.

It's like this:
You've got a bunch of sugar-high kids jumping on your living room couch every night, you can't kick them out (they live here, sorry), so your options are:

A- Yell at them all night until your throat's sore

B-Just move the damn couch into their room and enjoy your movie in peace.

In general, I think the proposal is reasonable -- maybe except for removing -datacarrier and -datacarriersize. Those give node operators the basic freedom to decide what kind of junk they're willing to relay. If someone wants to filter nonsense from their node, why take that option away?

Also, when blocksize increase anyway?

Edited, thanks for the correction.

[gmaxwell]

Relay layer filtering like Libre Relay? cool, now you can filter transactions that still make it to miners anyway.

Minor point of correction:  Libre Relay is a thing that eliminates almost all the relay restrictions (I think it only keeps the forward compatibility rules that reduce the risk of consensus changes causing forks, and some anti-DOS attack stuff).  The example I think you want is knots.

If someone wants to filter nonsense from their node, why take that option away?

The proposal that removes the option has been dropped for now, but to answer the question: Because it doesn't actually filter the nonsense from their nodes so long as miners are mining it-- they'll be forced to take it once its mined to stay in consensus.  So it just doesn't work.  And why preserve an option that doesn't even work?  Because every option means more code to maintain, combinatoric blow up in testing complexity (as every combination of settings ought to be tested), users wasting their time figuring out how they should or shouldn't set it,  -- and in this case some collateral harm for the little the setting actually does (e.g. slowing block propagation).

The software is inherently opinionated.  It's authors are trying to publish what is in their view the best way to make something the works, if they weren't the could just give you a copy of GCC and tell you to have fun.   In some cases different users have different needs (like maybe you don't have enough bandwidth to relay transactions and want to be blocks only)  or in some cases the best decision may be unclear or might rapidly change... so in those cases options are well justified.  In this case it doesn't seem so (e.g. there have now been a couple years of people screaming at miners to stop bypassing standardness rules and yet the practice seems to be increasing),  but also there is no particular reason to rush removing it.   If it turned out there was some bad effect of the change, it could be reversed and keeping the knob around for now makes that a little faster and easier.  But at least as far as is known now, other than appeasing apparently confused opinions and precaution there doesn't seem to be much reason to keep it.

[stwenhao]

What are these scanners?

This is one of the concepts, which is flying somewhere around Silent Payments: if you want to find a given payment, you use a given key, to scan the blockchain, and find matching transactions. The basic use of that is somewhat similar to how "view key" in Monero works.

However, if such Scanners will be widely deployed, then it could have more consequences, than just that. Because you don't have to scan the chain only to find your transactions: you can also use similar methods, to analyze it deeper, and see, which use cases are the most popular ones. Which means, that if you will have more advanced scanning criterias, then you can for example also estimate the spendability or the complexity of a given UTXO.

Which means, that not only you can use Scanners to find your payments, like a needle in a haystack. You can also introduce some optimizations, which would allow you to process the chain, and identify bottlenecks, or see, where are regular payments, and where are data pushes. In general, by having a wide collection of Scanners, you would have quite impressive chain analyzing tool.

And then, if you will know in practice, which coins are likely to be processed soon, and which coins will be spent after many years or never, then you can optimize the way of storing your data, based on that.

But: as you can probably see, Silent Payments are not yet popular enough, to really push Scanners forward, and see that kind of implementations. Nobody deployed any advanced scanning criterias yet, and it won't happen soon, because many people are focused on other things, so all of that is still only theory (maybe checked on some regtest-like networks, but still not deployed anywhere).

[mikeywith]

Because it doesn't actually filter the nonsense from their nodes so long as miners are mining it-- they'll be forced to take it once its mined to stay in consensus.  So it just doesn't work.

I completely understand the distinction. However, If I don't want to help relay someone's garbage transactions, I should absolutely have the option to block them from my node's mempool. However, if those transactions manage to reach a miner's node and get included in a block, my node is obligated to accept that block to stay in consensus.

These are node policy settings, not consensus rules, so it's up to each node operator to decide what they want to relay or not. Ultimately, the miners' nodes are the ones that really matter here -- and they'll most certainly relax their limits to maximize fee revenue.

That said, everyone has the right to protest by making the relay of such data less efficient. By enforcing their own relay policies, non-miner nodes can slow down the spread of unwanted transactions -- not to actually stop them, of course, but more to get that warm fuzzy feeling of "I'm doing my part for the network."

Furthermore, I tend to believe that this kind of data exists largely due to a lack of real economic competition on the blockchain. In the grand scheme of things, hardly anyone actually spends BTC, so spamming is relatively cheap. Fast forward a few decades, and that kind of behavior, along with even small-value transactions, will likely become economically unviable. Trends like BRC-20 are short-lived by nature. I also think a lot of this isn’t done purely to spam; people are often just experimenting or having fun. Paying real, scarce BTC just to "spam" isn't something a normal person would do. If I inscribe my photo on the most robust blockchain out there, sure, that might be a fun experiment --but I'm not paying $5 every day just to keep doing it.

[Peter Todd]

Minor point of correction:  Libre Relay is a thing that eliminates almost all the relay restrictions (I think it only keeps the forward compatibility rules that reduce the risk of consensus changes causing forks, and some anti-DOS attack stuff).

Correction to your correction: Libre Relay only (at the moment) eliminates two of Bitcoin Core's relay restrictions: the OP_Return limits and the restriction on using taproot annexes. And for the latter, Libre Relay adds a new set of standardness rules, requiring non-empty annexes to start with 0x00 for forward compatibility, and requiring all inputs to have an annex if any input does (this prevents transaction pinning). Libre Relay at the moment doesn't even relay dust outputs, and I haven't changed the rules on V3/TRUC transactions (which also prevent transaction pinning). Libre Relay also keeps Core's (mild) limits on taproot witness scripts. I may remove those in the future. But only if I can convince myself I'm not opening up any DoS attacks.

Libre Relay also has a primitive replace-by-fee-rate implementation. But that's just a pet project of mine, unrelated to this discussion. Interestingly, that RBFR implementation is theoretically somewhat vulnerable to certain kinds of expensive DoS attacks. So far no-one has hated Libre Relay enough to actually attack it that way.

Overall Bitcoin Core is actually already pretty close to relaying all consensus-valid transactions with actual economic demand. I've only removed some remaining "paternalism" to prove a point - as you correctly observe above, Libre Relay is, to a degree, a piece of performance art rather than a serious attempt to fork Core.

That said, you're also not wrong: since Bitcoin Core is pretty close to relaying all consensus-valid transactions, you can argue that Libre Relay eliminates almost all the relay restrictions other than forward compatibility and anti-DoS stuff.

[BayAreaCoins]

Peter, what's the bonus on that "W"? (Congrats, I guess[ish], kind of, but this shit is shitcoinery to the fifth degree. I'm with it, though.)

(really probably a money laundering operation, but it at least pretended to be a gambling site

 

Can you justify that claim? ...

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

^

I'm of the dice crowd, naturally.  *sigh*

Seems like a big accusation, and I'm not aware of them being found guilty on any formal charges.  Source?

(Regardless, but I once remember Dooglus saying it was easier for him to build his own centralized dice site to combat on-chain SD spam than it was to go through the Bitcoin reviews and such.  That's a huge reason why SD spam came to a crawl.  Back then SD transactions were being cheered on by a lot of people for transaction fees [same argument, different year].)

Bitcoin Core does not rush changes.

eh...  lol

[nutildah]

spamtoshi made $2400 to first create Libre Relay: https://x.com/lightcoin/status/1733257392668766494

By a guy from Alpen Labs who want to run stablecoins and shitcoins on Bitcoin. Pathetic, a lot of them are invested in this crap startup.

What's the problem? Its an alternative bitcoin client for people that want to do transactions Core can't do, without forking the network. Nobody has to use it, and you won't catch anyone here saying you should use it. Pretty sure he's allowed to do what he wants. There have been shitcoins on Bitcoin for over a decade now; not to mention Tether first got started on Bitcoin.

[d5000]

That said, everyone has the right to protest by making the relay of such data less efficient. By enforcing their own relay policies, non-miner nodes can slow down the spread of unwanted transactions -- not to actually stop them, of course, but more to get that warm fuzzy feeling of "I'm doing my part for the network."

I think the question of "keeping the datacarriersize knob or not" boils down to an evaluation of different possible effects:

- Spam [1] cost: If a significant percentage of nodes use the datacarriersize knob, then spammers (particularly those with a time-sensitive plan, e.g. a NFT on a certain block height) may be incentived to bribe [2] miners directly, increasing their cost. The crucial question here would be, how high is the average cost of this effect?
- Centralization risk due to direct miner bribing: Big miners and pools can increase their income due to direct bribing. This can increase the difficulty and price solo miners and not-that-profitable miners at small pools out of the mining game (may be a small effect, but it probably exists). [Edited, see here.]
- Social consensus: It may be helping to deter spam that nodes "protest" against it, making spammers "feel bad". I believe this however to be weak against financially profitable spam schemes. An indication that this could work would be for example a spam project which has reduced their data footprint due to user claims, or used commitments, or even other blockchains.
- Block propagation. Slower if the nodes have many different policy settings (as far as I understand it).
- Development cost. Higher if the knob stays there.

Some of these effects seem to be possible to be measured, so this could be an idea to move the discussion forward in a constructive way (I'm not following the PR discussion so that may have been mentioned there, but I think it's not a bad idea to list these effects here in simple language for those joining the discussion.).

Regarding development cost, a "compromise" could look like this: Core removes the knobs, but links to a patch or a patched version which is maintained by another team (and only contains these changes). Of course this would only solve this point, and the effects on the remaining points would still have to be evaluated.


[1] Yes I have read gmaxwell's comment on it, but I'm just using the popular term for it, as the effects on the user experience is a bit similar.
[2] Idem.