Thanks for your comments!


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.

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.

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

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.


Indeed.


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.

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.

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.

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.

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.

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


 


^

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


eh...  lol

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.

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.

I think this is the only noticeable effect, and yes, your understanding is 100% correct. Different policy settings cause an overall public network performance degradation. If you don't store X data in your mempool, then when you receive a block that includes X, you'll still need to verify it -- meaning you’ll have to download it anyway, but only on demand. That’s very different from having it already downloaded and propagated a dozen times. It’s like a torrent client forcing you to download and seed the entire network, including files you may never need.

Mind you, this propagation delay won’t affect most miners, since they will certainly relax their settings. And more importantly, mining pools don't rely on the regular P2P network (the one you and I use) to relay blocks between them. They mostly use protocols like FIBRE, which are obviously much faster than using the public network.


More transactions in blocks = more profit for every miner, no exceptions. If a bribed pool drops a standard transaction to make room for an OP_RETURN transaction, that standard transaction doesn’t just vanish -- another miner will pick it up. So the overall mining revenue increases with more transactions, regardless of type.

Now, since spammers may be forced to reach out directly to mining pools, those pools will likely charge them more. And honestly, isn’t that a good thing? Don’t we want spammers to be paying higher fees so they eventually get tired and give up?

And let's not forget: miners are also part of the community. Individual miners can pressure pools to reflect their preferences -- like saying "don’t include those trash transactions or I’m leaving your pool." That’s already happening with Ordinals.

You would think a pool like Luke’s Ocean, which bans all sorts of transactions (and as a result earns less, ignoring variance and fees), would be irrelevant by now. But nope -- they've managed to gather nearly 6 EH of hashrate and are still growing!. That tells you there are plenty of miners who don’t want their hashpower used to mine what they consider spam.

In the broader context, virtually no one mines BTC entirely solo anymore. Solo miners now use solo mining pools like CK and ViaBTC. These pools are well-connected and have excellent propagation capabilities, so I don't think we need to worry about "mining pools." In fact, mining pools must be well-connected not just to fetch those transactions but to avoid losing entire blocks.

Again, even for the few solo gamblers out there, they only hit a block once in a blue moon--almost never--so we shouldn't include them in the equation.

As for direct reach to miners, this is an "extra" service that some pools provide while others don't, and it's really independent of pool size. ViaBTC, for example, offers transaction acceleration for non-RBF transactions (the reason I stopped using them was because they failed to explain where the money goes), while other much larger pools don't do that--probably for the same reason. Once you start including transactions that are not in the "default" getblocktemplate, you have no way to prove to your users that you're not ripping them off.

So, the majority of those spam transactions (similar to the current situation of purged transactions) will have to face their fate until they find their way into a block, and all pools have almost equal opportunity to reach wallets and app wallets that first propagate those transactions.

Furthermore, the whole concept of "small miners" simply doesn't exist in any meaningful scale anymore. 80% of blocks are mined by only six pools, and 90% of blocks are mined by the top nine pools. None of these are small, and we certainly shouldn't be worrying about them--at least, not more than we have to worry about the little guy running his node on limited bandwidth who can't afford to be relaying all those transactions.

As for Ocean, last I checked, I believe they were using the Knots template, which filters out inscriptions and limits OP_RETURN data to 42 bytes. I believe the reasoning behind 42 bytes is that it should fit data commitments, which are 32 bytes. Not sure what the remaining 10 is for--maybe for a 10-byte identifier or just a random number Luke pulled while reading the Bible, which he inscribed into the very blockchain he's now trying to keep clean.

Obviously, this method, while effective, isn't perfect since:

1-It could filter other "legit transactions."

2-Some spam can still make it in.

But in general, it does the job.