Bitcoin Forum

So in the following video you can watch Murch (core dev) explain the core side of the current spam war. I invite you to watch it before you keep reading:

https://www.youtube.com/live/3BFgoQawG7Q

While you watch or listen, I invite you to pay attention to how many times Murch talks about policy, not code. How often he explains what the core policy is, or should be.

It's important to understand that these core devs get on the core team based on their coding skills, not based on their politics or policy skills.

It's important also to understand that bitcoin is decentralized far more than other cryptos. Now when I say decentralized, I don't mean the miners as over 80% of the mining is controlled by just a handful of mining pools.

I don't mean code maintenance either as a handful of core devs decide what should get into 80% of the nodes code.

The only part of bitcoin that is still truly decentralized is the nodes. As there are over 25,000 nodes on the network, operated for free by individual bitcoiners.

The main job of these 25,000 nodes is to ensure that users and miners behave. IE no double spend, you own the coin you spend, miners are being honest, and so on....

Without the nodes, bitcoin would be a highly institutionalized and corporate controlled network. We don't want this.

We don't want the miners to decide what they can mine without consequences. We don't want the core devs to decide how nodes should operate without consequences. What we want is more power to the nodes to keep the network decentralized.

But every time Murch talks about core policy, he is basically telling you how you should operate your node, how you will be told to operate your node.

I don't think cors should emphasize on policy so much. They are coders, not policy enforcers. The devs should be  giving the tools for the nodes to decide policy on our own. Each and everyone of us should be able to decide what is acceptable in a block, and what is not acceptable in a block.

We should be provided with more filter, user configurable filters. Not be forced to apply whatever policy core decided is acceptable.

Join the fight, run a Knots node:
https://bitcoinknots.org/

VS the policy of knots which is whatever Luke wants.

I'll stick with Core since I might want to send my coins someplace one day that Luke disagrees with.

How luke operates: https://bitcointalk.org/index.php?topic=816578.0

-Dave

That's incorrect. Knots allows you to decide for yourself if you want to filter out spam or not. In fact there is a tab included for it. He doesn't tell you to filter anything. He just gives you the tools to decide for yourself what you want to put in your mempool and relay to others.


That would imply that filters are a form of financial censorship.

Filters have been in place since day one. The op_return filter has been in place for 11 years, alongside other filters.

Nobody ever complained about censorship until about 7 months ago when filters suddenly became a form of censorship.

How did that happen? Did the magic smoke escape the filters?

Obviously you aren't being "forced to apply whatever policy core decided is acceptable" as you point out right below that.  Run whatever you want.  Make whatever changes you want, but plenty of people disagree and you may be running the bitcoin knots fork.

I would suggest reading here though because a lot of the FUD going around is just that:
https://groups.google.com/g/bitcoindev?pli=1

Knots is being maintained by mainly Luke who commits to main branch directly. I don't think most Knotzis understand what this mean in terms of security, and it shows. But, to follow the same line of reasoning, you can also configure Core to "filter out spam", if you like. Just run it with "-datacarriersize 83" to revert to the limit enforced by previous versions.

And also, you're not filtering out anything by running either client. Just a reminder that bitcoin is a permissionless network.

what, like how achow wants to disable legacy.. goodluck if you might want to move coins on legacy soon. achow doesnt want people to do that, but achow wants people to move pictures unchallenged forever whilst limiting who and how people can move their sats

achow wants crap data to move into the blockchain unchecked.. learn that achow and his colleagues dont care about bitcoin as a payment system, they only care about their blockstream products being the solution to the flaws they put into bitcoin.

when you learn that core devs dont care about bitcoin you will soon learn to not want to kiss their ass, because they will make it harder to move your coins on bitcoin, even if you kiss their ass..

im not saying luke is the only alternative. im saying we need to actually stop core devs from being the unaccountable monarchy governing bitcoin.

bitcoin is permissioned.. else anyone would be able to move satoshi.N's coins without his permission(signature)
bitcoin is permissioned.. else anyone would be able to edit the blockchain
bitcoin is permissioned.. else anyone would be able to change the rules without anyone else
heck even core have permissions and privileges.. not any rando coder can just merge in new rules into cores release candidate

bitcoin worked best when the rules actually required nodes to check every byte and ensure that the data actually meant something.
but now there are so many by-passes and "assumed valid" loopholes that its not as secure as it was and now we got all the crap data being allowed in unchecked

All that Luke does is adding more user configurable filters. And those filter are more easily configurable. Knots doesn't assume every user knows how to edit conf files.
Coincidentally, the best software wallet out there is Sparrow, which is coded from the ground up by a single guy. Sometimes a single guy can do better coding than a commity. Especially if said commity appears to have been compromised.


Yes, I'm also aware that core is bent on blowing up the filter by setting the default to 100,000 bytes (or 1250x the previous setting). This shows that core has no desire to fight spam, and even go as far as catering to spam by providing them with new use cases while doing nothing about the existing cases.


Until core spamware edition, 99%+ of the op_returns were under 83 bytes. That shows you the filter did it's job very well for over 11 years while keeping the network permissionless money, not permissionless jpegs.

Mining pools are not miners. Pools cannot control anything because miners can always change pools.

You can code your own node implementation, patch Core or Knots, or do what you want.

And how would Bitcoin work without nodes?

Did you use ChatGPT to write a propaganda speech for you?

And that is still true and will always be true.

The mouse will always win against the cat.

(Edited one small remark, don't want to throw more fire in that show.)

You are too kind. I'm no genius, I get by on my looks alone. I just can't figure out why girls laugh when I say that.


Actually, miner is a misnomer as you don't actually mine anything if you are with one of the handful of big pools. You merely sell your hash power to the pool operator and they decide what goes into a block. This is how all the pools operate.

This is an extremely centralizing thing when you realize less than 5 pool operators decide what goes into 80%+ of all blocks.

The only exception is Ocean which allows individual miners to build their own block template aka the miners decide what goes into their blocks.

Other pools centralize hash power, Ocean decentralizes hash power.

Just like core centralizes mempool policy, and Knots decentralizes mempool policy.


Yup, thanks for the tip. I chose to use the client that provides me the most freedom over what I can put in my mempool and relay to others.


Bitcoin could theoretically work with only mining nodes. Albeit it would be a very centralized network. The more nodes we have, the more decentralized we remain.

Forcing nodes to host and distribute illicit data can only have a centralizing effect.


Not a valid question.


It's true if you run a Knots node. If you run a core node, they already decided for you that you should not filter out spam like ordinals, runes, and other useless crap that is not a genuine monetary transaction.


I assume you mean the mouse to be the spammers. That is a very core aligned defeatist ideology.

The op_return filter successfully prevented 99% of the op_returns from sending more than 83 bytes per tx for over 11 years. The cat won for 11 years, until core effectively decided to break the cat.

But you can chose the pool you want and its policy, including Ocean. That was my point.

While there are some that dispute that, I see indeed some value in having a large set of nodes.

And that's exactly why I support the OP_RETURN limit increase, because OP_RETURN makes running nodes less costly in comparison to the spammers alternatively using techniques like OLGA stamps and other fake public key methods.

That's the whole point of the discussion. And that's also why I sometimes am a bit harsh in this discussion: If you haven't understood that point, the whole picture becomes wrong. It's not spam vs. no spam. It's spam vs. more harmful spam, and the more harmful spam is the UTXO set spam.

I know Luke thinks that it makes a difference if you still can interpret illegal content as financial data like it occurs with fake public keys techniques in some (but not all!) cases, but I don't think this makes a legal, and much less a moral difference. See also below: if the spammers use OLGA stamps they can practically force nodes to distribute their spam, because they can't simply prune it.

Illicit data on OLGA stamps is even worse than on OP_RETURN. OP_RETURN data can be ignored once txid/merkle tree are calculated, but if the data is on an OLGA stamp, you cannot, as a node owner, know if it is a valid hash of a P2WSH redeem script, or if it is arbitrary data. You would thus have to keep all these outputs and thus you can't prune the illegal content. The only way would be use some image recognition software but even that can fail if the spammer encode the data. They can encode them with any cryptographic technique, and then publish their key in some forum.

Thus if a spammer really wants to do damage to Bitcoin with his illicit content, he would always use Stampchain/fake public key techniques and first obfuscate the content (so all miners and even the oh-so-selective Knots nodes accept it) and once confirmed, he has his Ha-ha! moment.

No, the cat began to lose as mining pools began to provide services like Mara's Slipstream. This wasn't an issue before as there was no demand for large OPRETURNs as there was practically no NFT market. Ethereum then created the NFT market, but it remained an altcoin issue until the Ordinals wave and the idea to store stuff on the "OG" chain appeared, which was a typical fad. And that fad has fortunately almost ended, with lots of bagholders of worthless BRC-20 shittokens. ::)

A little bit off-topic perhaps, but if you accept that Core has so much influence on bitcoin, that it can literally decide bitcoin, what's the point of being into bitcoin? I'm not into bitcoin, because I trust Core developers. I'm into it, because I know that nobody can decide its fate. It's open, permissionless and censorship-resistant. What client other people are running is very irrelevant to me. Whether they run a mempool policy I disagree with or not, does not render bitcoin any less useful than it previously were for me.

If people like PepeLapiu believe that "default mempool policy" is a decisive factor in bitcoin's future, then why are you involved with it? Ultimately, if it were that easy to "hijack bitcoin", by simply compromising the Bitcoin Core dev team, it would be no different from the traditional financial system.

Looking at https://bitnodes.io/dashboard/90d/ (https://bitnodes.io/dashboard/90d/), it's slightly below 25000 in past 90 days. But FYI, https://luke.dashjr.org/programs/bitcoin/files/charts/software.html (https://luke.dashjr.org/programs/bitcoin/files/charts/software.html) shows current total node running (including one that doesnt accept incoming connection) is about 93500 nodes.


FYI, you can change some TX relay policy on Bitcoin Core. As for available option, visit https://jlopp.github.io/bitcoin-core-config-generator/ (https://jlopp.github.io/bitcoin-core-config-generator/) and check "Transaction Relay" menu.

As you read this, please keep in mind I wrote it with respect and calmness in mind.


And my point was that Ocean and Knots are decentralizing ideas in an increasingly centralized system. We should embrace it, not vilify it.


Anyone who disputes that is advocating for centralization. Do me a favor and smack them up across the head.


What is not getting across here is that the existing spammers are not switching to op_return, and they won't. Even the core devs have admitted that much. Listen to the following video at 24:40 :
https://youtu.be/PQN-ASAR95U

He's just one, other core devs, along with many people on my side have been saying this all along.

When the spammers have 5 pots to shit in, and you provide them with a 6th pot without doing anything about the previous 5 pots, you are just providing them with more pots to shit in.


Imagine for a moment that you secretly were a pro spam dev. Maybe they gave you a trip to Epstein Island and they control you with blackmail. Or any other reason for you to become pro-spam.

Every time people ask you to give them a filter to get rid of the spam, you would tell them you can't do it, and even if you could, you shouldn't.

And after a while, you would find ways to blow up what few existing filters already exist.

Correct?

Well, the obvious problem here is that the pro-spam policy and the harm reduction policy are identical in every way other than in name. And the results are the same: more spam.



Luke's (and mine) position is far more nuanced than that.

- Spam of any kind makes it harder to run a node.

- Spam of any kind constitutes an attack vertor and a useless use case that makes scaling harder.

- Spam of any kind makes bitcoin look like a fucking joke shitcoin. What would you think if your local restaurant had dick pics posted on the restaurant wall?

- Spam of any kind will eventually devolve in illicit spam. Bad actors exist. There is no way to allow only good spam and block out illicit spam.

- Spam that eventually becomes illicit becomes a moral and legal burden we do not need.

- Nobody is censoring anything. They can go shit on the other zillion shitcoins who welcome the spam. We just have to make it hard enough for them to want to go play elsewhere.


I don't care. Existing spammers are not moving to op_return and they won't. Core 30 is creating a new use case for spammers and it's only a question of time before they figure that out and come at us with more spam that fit perfectly the op_return new use case.  
  

And the funny thing about this is that instead of core trying to recognize this as a problem, one of core's own devs - Peter Todd - created a fork of core with all filters removed, over a dozen existing spam filters removed. And he tailored it specifically for spam miners like Mara and F2Pool.

Imagine that. Core does not do anything about it and a dev paid by core helps the spam miners to make spam easier. I couldn't make this shit up if I tried.

Here is a quote from the OpenRelay (spamware) page:




Yes, absolutely, and the first ordinals appeared in late 2023. Had core implemented an ordinal filter on their next release, over 95% of the nodes today would be running that filter.

So I tend to raise an eyebrow when core suddenly pretends to care about UTXO bloat. Because the largest cause of UTXO bloat today comes from ordinals.

And I should say, coding a filter is really easy. Probably can be done with less than 20 lines of code. I'd do it, but I run AHK v1 and Python, not C++. And I'm an amateur at best.

For the most part "Spam" makes it easier to run a node, in particular op_return but generally all kinds make it easier.  Bitmexresearch did a nice scatter plot showing block validation times vs varrious kind of data embedding.  OP_returns dramatically reduce the size of blocks, speeding up their transfer and lowering their storage needed.

I don't want to suggest that that traffic is good: the system has hard resource limits specifically so we don't have to worry about the ability to run nodes.  But it's just not true that it's bad because it makes running a node harder.

Bitcoin already costs tens of thousands of times more than alternatives.  The NFT junkies like Bitcoin *because* it is "hard" for them, as the costs create a limited supply of NFTs, which is essential to increasing their apparent volume.

The restrictions and the whining (free marketing) are the greatest gift anyone could have ever given the NFT idiots.

There is no one paid by core.

You are clearly mentally ill.  Seek treatment before your anxiety disorder and out of control fear causes you to hurt yourself or someone around you.

I'm not vilifying Knots. I think it is good that there are node alternatives. But I will always harshly criticise attempts to influence the public opinion with very doubtful argumentation, omitting crucial points like the dangers of spam waves with fake public key techniques. And I'm being very kind here.

The problem is that you can't do much about several of these 5 pots. You could filter 3 of them with harsh measures like the draft BIP 444, but 2 would be still open (fake public keys and fake private keys (https://www.bitmex.com/blog/the-unstoppable-jpg-in-private-keys)). Then the whole exercise becomes worthless, because these 2 pots are still cheap enough to spam (fake public keys are not even double as expensive as OP_RETURN), and several types of spammers aren't even really cost-sensible, as you can see with the astronomic fees paid for Ordinals and Runes.

I would not be against closing the Taproot witness "hole" for example if other useful Taproot scripts would not be affected _and_ the spammers couldn't win the cat and mouse game by changing their protocol. The problem is that these two requirements are (99% likely) mutually exclusive.

If one of you folks come up with a proposal that (against my expectations) fulfills both requirements, it could have my support ;)

The "more spam" has to be seen, see this post (https://bitcointalk.org/index.php?topic=5563464.msg66037634#msg66037634), there is currently no increase in OP_RETURN activity.

But the problem is that there is no good measure which can be taken where the result is "less spam". Or more precisely: "less incentives for spam". There's no filter that can work if there's still a (cheap enough) option.

There are literally millions (about 1.2 million, to be precise) of Stampchain fake public key NFTs already, which I consider the worst kind of spam. Now let BIP 444 get through. That would mean 3 of the 5 pots you mention above would be closed, but the Stampchain pot is still open. What will NFT guys and other spammers do? Would they simply quit and cry? No! The incentives align now that they will use Stampchain too. Often they have made a business around their spam and thus they won't simply stop. They will simply use another protocol.

Is this simple logic that difficult to understand? I don't get it.

Stampchain (OLGA) would not be stopped by BIP 444, because they use P2WSH ScriptPubKeys with exactly 34 bytes just like most "normal" "financial" scripts.

Yeah, that are all nice points, but the filter ideas would simply miserably fail in attacking them. That is my whole point.

The "not financial data" is an argument I acknowledge to be a nice theory but it fails because practically it makes no difference which protocol the spammers use. There will not be less child abuse because the spammers use Stampchain and not OP_RETURN. So there is no moral difference.

Lol. If you really are concerned about nodes and decentralization, you should definitely care about that point!

Otherwise, I can safely assume that you're not caring about nodes' wellbeing at all, because you're not concerned about their increasing costs due to stampchain-style spam.

Because the filters don't work. LibreRelay is only acknowledging that. LibreRelay is "legal" from Bitcoin protocol's point of view. Nobody can prevent such a fork to be created, i.e. a version with all policy restrictions removed. The spammer themselves can create it and that would be probably worse.

You didn't address the cat and mouse point at all. Because it -- for me, unfortunately, because I don't like the spam -- has no solution. Even making spam significantly more expensive (2x or more cost) would also make Bitcoin less scalable.

If there is a filter that would theoretically really work, keeping in mind SpamStampchain - then I would support it. But there is no such filter.

And we would have then a Stampchain fake public key spam wave with triple the UTXO bloat.

The Taproot method is indeed a major source for UTXO bloat but Stampchain is worse because it relies on unspendable UTXOs, the UTXOs are not only a byproduct. That's not the case with the Taproot-based protocols, they could be used in a way the UTXO bloat is minimized. But I'm not defending Ordinals here.

By the way: The OP_RETURN increase doesn't create new spam "use cases". It's another variant of an existing use case which is simply less harmful that existing variants of that same use case. Even if only 10% protocols switch from Taproot or fake public keys to OP_RETURN there would be already an improvement on node running cost.

if nodes enforced 'dust' limit where by using multiple public keys would equal costing the transactor more (dust limit multiple by public key used)
if nodes enforced rejecting unknown new opcodes in the unconfirmed tx relay/mempool
if nodes enforced small or no op_return
if nodes limited signature/witness space used per UTXO

we would not have this amount of junk on the blockchain

but because:
nodes allow unset opcodes to 'pass' due to 'assumevalid' (with no rule check compliance)
nodes allow one transaction to have upto 4mb of signature/witness space
nodes allow public keys with no dust limit amount
nodes also getting to have large op_return junk data at 0 sat cost..

we see so much junk on the blockchain unchallenged

the whole "softening" of bitcoin rules since 2017 has not helped bitcoin become lean and serve its true purpose of moving sats

I sympathize a bit with this idea.

Just to be sure I understand it correctly: what you propose is that transactions with more outputs (with different pubkeys/pubkeyhashes) would trigger an increase of the dust limit?

I guess the problem is that you would also penalize CoinJoins and similar transactions with lots of outputs and small amounts, but the dust limit is currently worth about 50 cents (Edit: 30 cents if using Segwit), so an increased limit should not be that dramatic.

If instead you mean to punish things like bare multisig (multiple pubkeys per output), then we would have a price structure like OLGA stamps which are indeed more expensive than OP_RETURNs and other methods.

In general this is an idea I could support.

The remaining ideas would not stop Stampchain-style stuff, so they are not suitable to limit spam.

Doesn't make this Bitcoin less upgradeable via soft forks?

That's the consensus limit but nodes normally enforce the 100/400 kB policy limit. Miners however have bypassed that in the past, and that's part of the whole problem. I vaguely remember however some BitVM transactions would need more than 100 kB.

Free beer? Where? ;) I guess you may refer to some transaction where a miner colluded with a NFT user and permitted a zero fee? Or the general 0.2 sat/vbyte fee (well, that's the fee now ...)?

NONE of what i said in the entire previous post was about tx fee.. it was about the per output value


no
im saying that transactions should abide by the output dust limit

im saying currently the 'soft' rules allow users to have outputs(junk destination addresses) with less than 546sats($0.56) per output. meaning people can have loads of outputs without spending much sats
especially when they use op_return with expanded dataspace, it costs them nothing to add alot of junk per output

if each destination address cost atleast 546sats($0.55) then it becomes expensive to have hundreds of junk-public-keys/opreturns as destinations so it costs alot to use destination addresses as junk data(separate cost not part of fee)

..
and the other suggestions is where nodes SHOULD check every byte actually has reason to be in a transaction and if not understood, not relay/accept it
nodes currently dont check nor count every byte they just use the silly bypasses like "assume valid"/"isvalid" crap "soft" rules

nodes should not be relaying let alone allowing into block candidates junk/unchecked data where every byte has not been checked to meet rules of validity
and by this i mean the signature/witness space should actually be fully checked that the signature/witnesses actually are proofs of permission of the UTXO being spent and not just random data being treated as "assume/is-valid"

..
the most silly part is,
i done many interceptions this year where i took some unconfirmed transactions using particular opcodes being relayed, and simply changed the witness data and destination(and changed the value to change tx fee cause a RBF), broadcast it out and seen that transaction get relayed by other nodes and appear in multiple remote 'explorer' sites mempools, meaning many other peoples nodes just passed it and allowed it through unchecked..
(sidenote: i annoyed the initial sender as i seen then quickly do RBF to try to take control of it again)


the whole campaign of "softening" since 2016 has not helped bitcoin
core devs get to force-merge whatever they want and nodes dont reject it. nodes just pass it as "assumevalid/isvalid" meaning nodes dont hold devs accountable.
the whole softening makes devs lives easier to not require hard consensus requirements of node upgrade pre activation of new tx formats.. but the downside is that it allows devs to do things that nodes are not checking for. making the whole decentralised purpose of nodes moot.

nodes should be checking data, especially not just blindly pass new opcodes usage(where nodes dont understand the data). as this is where problems are allowed in and nodes dont get to stop the problems anymore

we need to get back to hard rules, as thats the purpose of rules. whereby devs need to actually properly test use-case scenarios of new formats on testnets properly and thoroughly. actually code things correctly, and do it for the benefit of bitcoin and not their sponsors recruitment plans of other networks(blockstream and such)

full nodes HAD a purpose in regards to securing bitcoin, which has been softened. and this softening needs to be reversed

That is exactly what the Core devs are doing. Ideally they should be sticking to the guidelines outlined in Satoshi's white paper.
But as we all know in the last few years they have strayed farther and further away from the original vision.

And they will continue to stray away with every new arbitrary update until bitcoin is barely recognizable.

Why? They do it because they can, and no one can stop them. The devs have been acting strictly out of self-interest and that
of their crypto lobby sponsors. They have made their intentions perfectly clear. Bitcoin is no longer sound money. And it can no longer
be considered decentralized when a small group of actors possesses nearly total control over it and can change it at will.

It is no longer sound money. From now on bitcoin can be whatever the highest bidder wants it to be.