This is my take on how to launch a stealthy 51% attack on bitcoin

Before I get into my idea about a 51% attack, let’s make sure we get how filters work. Picture this: we’ve got red transactions and green transactions. The nodes will filter out the red transactions, treating them as valid for consensus but unwanted. You can think of these red transactions like spam. Your node gets transactions from wallets connected to it, and from other nodes that pass along their transactions. Your filter gets rid of the red ones and keeps the green ones to add to your mempool. Then your node sends out the green transactions to others in the network. Now, let’s think about 3 miners. They’re all mining with a total of 3 Gigahashes. We’ll call them Bob, Steve, and Lisa, and they’re spread out across the network. Bob and Steve mine a block at the same time. But guess what? Bob includes a bunch of red transactions in his block, while Steve only includes green ones. They both start sending their blocks out to the network at the same time. Now, every node has to check out all the transactions in those blocks to ensure they’re valid according to consensus. Some nodes get Steve’s block, and since they already have most of his green transactions in their mempool, those transactions are already verified. So adding the block to their local blockchain is super quick, and they pass it along to others. On the flip side, Bob’s block has a lot of red transactions. The nodes don’t have those in their mempool, so they need to reach out to Bob and ask for those transactions.

An empty block, where there is only the coinbase transaction, propagates even faster. Does it mean, that miners should mark all transactions as red, coinbase transactions as green, and produce empty blocks, because they propagate faster than everything else? It's risky for Bob to make any transactions, because empty blocks will be always faster. And it's risky to transact in a network, where transactions are splitted between green and red, because you never know, if your today's green transaction wouldn't be marked as red tomorrow.

I don't see reason to run Knots for fighting back against threats of 51% attacks. How many Bitcoin confirmations are enough? Bitcoin confirmation risk calculator https://jlopp.github.io/bitcoin-confirmation-risk-calculator/?ref=blog.lopp.net There were times when some Bitcoin mining pools can do 51% attacks but they did not do that. It's because such attacks won't bring any benefit for attackers when people will feel panic and Bitcoin price will crash to hell. https://hal.archives-ouvertes.fr/hal-03610424/document https://petra.isenberg.cc/publications/papers/Tovanich_2020_VAO.pdf

I do. BIP110 will stop some of the spam at the consensus level and bring the op_return limit of 83 bytes to consensus so coretards can't fuck with it again. And BIP110 signals to the network and to the spammers that spam will no longer be tolerated or catered to. First and foremost, I wouldn't trust or read anything that shitcoiner Lopp puts out. And secondly, how many confirmations you need is not the point here. They would benefit. They could shove all the spam they want into their blocks without risking to get an orphaned block. And since they would control more than 50% of the hashrate, they could mine on top of their own blocks faster than the rest of us. And it would go virtually undetected. You could see some clues of their LibreRelay spam cartel, but no direct proof or evidence. They would just look like they have more hash power than they really do. Here are some of the clues that they could be doing this right now: - Over 150 LibreRelay nodes are detected on the network and LibreRelay nodes were designed especially for spam miners. Though I suspect at some point they might start to spoof core or Knots nodes to avoid detection. - During sub-1 sat summer, some of the big pools who tend to put spam in their blocks started to accept sub-1 sat tx's in spite of the fact that the vast majority of nodes were filtering out sub-1 sat tx's. They were/are defying nodes filters and policy for ridiculously small pocket change. - The same big pools who love to shove spam in their blocks appear to always have full blocks by filling them up with op_returns I somehow don't ever see in my own mempool. As if they are spreading those op_returns amongst each other without sharing them with the rest of the network.

Outside of some rare cases, like well under 1% of them my nodes see the transactions that wind up in blocks. There are open source block explorers that will show you this information that are easy to install. If you don't see them but other public ones do it's on your end For the most part my private mempool.space explorer agrees with the public one as to what it saw in the block vs what was in the mempool when the block was found. There are 4000 to 6000 transactions in a full block on average. Some, usually under 5 or 6  will not be seen by your node for many reasons. Other TXs will be manually added. If you are talking anything tech it should be Alice and Bob and then either Carol, Carlos or Charlie. Using Bob, Steve, and Lisa shows that whoever wrote what you quoted does not communicate with programmers or cryptography people on a regular basis. Although there is no RFC or anything else about it over the years it's just became the way it is and if you don't use those people will know that you don't know. -Dave

Interesting! I need to look further into this. I'm no cryptographer, and my message is not directed at cryptographers either. I'm not quoting anyone, I'm using my own knowledge of how bitcoin works. Picking on the names of fictitious people I use, that really shows your bias.

No I was pointing out that if you want to talk about things like this then *not* using Alice / Bob / etc. will cause many people to skip over anything you say after that. The Alice & Bob are standards in encryption, networking, programming, a lot of game theory, and so on.   No different then a lot of things that when you are trying to discuss there are many ways to do it but certain standard terms just show that you actually are trying to discuss it the same way that people who deal with it all day every day talk about it.   Kind of like if you are talking to someone doing graphic design, they will probably pay more attention to you if you when telling them a color you tell them "18-3340 TCX Charisma" instead of "dark purple". Both are correct but one lets the person know that you know Pantone and are talking to them from a point of knowledge. Or at least trying to fake it. On a side note most pools are probably not only propagating using fully public nodes but are also doing it on one of the other relay networks. And they have been doing it for well over a decade. It's just the way it's done. No, you don't have to do it, but not doing it only hurts you so why not do it. -Dave

Just because it's been done for a decade doesn't mean it's a good thing. I know people who have been smoking crack for a decade. Does that make it okay? If you operate outside the p2p network on a side network, you should be treated as an attacker. Those miners running LibreRelay are doing it to deliberately bypass the p2p network and the nodes filters in order to facilitate more spam. This is not okay. Saying it's been done for a long time is nothing but cope. And it's been getting worst, especially for the last 4-5 years since the ordinal attack started. Here is how I see it. To me, it all started with the ordinal attack in 2023. The vofetards refused to do anything about it, claiming that "The fees are the filter" and "wecanC't do anything else". Than Luke Daskjr proposed a filter for ordinals. So spammers complained this was censorship. And what did core do? They changed the definition of datacarriersize intheyirdocumentsation, and rejected the filter based on the new definition, and also claiming they don't merge anything too controversial. That is what started it all. Core was basicallysignallinfg to the spammers that they won't do anything about spam. And they heard the message. Gosh, did they ever hear the message! And most of the nodes schrugged it off.We were told by coretards that the feemarkert will eventually chase them away. Only it never did. Instead, more spam projects get added to bitcoin every day. Now we got ordinals, fake pubkeys, stamps, runestones, rare sats, and the list goes on. I don't waste mental space with that list of crap. What did core do in response to all this? They removed a spam filter. Yup, I shit you not. Instead of tackling the spam problem, they are effectively enabling spam now. And the funny part is that the coretards are trying toclainm that all the dissent against core is just fake nodes, fake bots, loud minority. "We are deliberately turning bitcoin into a dickbutt.jpeg repository and all those who complain about it are fake." Really coretards? Really? Exactly! LibreRelay nodes are effectively running a spam cartel. And in a cartel situation, you are incentivised to join the cartel, or be left out and lose out. That us a problem. We should look to break down the cartel, notfeesd it. So starting with BIP110, we are going to attack the attackers at the consensus level. They want to ignore filters? Fine, let's see if they can ignore consensus.

In the most basic way on any bitcoin node you can do an addnode = x.x.x.x and your node will try to connect to whatever node you tell it to. This allows you to have some preferred peers. So it's still peer to peer but you can pick your peers. However, that was not what I was talking about. What I was talking about was something like this: https://bitcoinfibre.org/ There is / was at least one other similar config for faster block transmit / receive that one of my clients was using for their mining farm & pool server. Honestly they still might be using it lost touch when then moved from here (NY) to Montreal. So anyone running any sort of pool should be connecting to something similar. The issue is most places that sell you bandwidth use LCR for routing, which is fine for most things. But when you need to have certain data move as fast as possible you have to know what you are doing because if you find a block and it gets transmitted to the network using LCR then paraphrasing Bugs Bunny [using that since you are using a character from Warner Brothers as your name] your data packets should have turned left at Albuquerque but they didn't. If you are streaming a Netflix video then having it take a few extra hops between a few extra routers because it saves your bandwidth provider some money is fine. When you are in a race to get your block to other miners having those extra hops can cost you that block. You sure as heck don't want your newly found block just trying to get to other miners by relying on public nodes that can be anywhere doing anything. You want your block to get to other miners nodes as quickly as possible using the fewest possible router hops while also connecting to their nodes or nodes as close to theirs in terms of network speed as possible. -Dave

That makes sense until you realise that the same LibreRelay nodes that do this preferential peering also are maximized to push more spam on the network. In fact it's Peter Todd's public claim that LibreRelay facilitates spam. Only, he's more politically correct and refers to it as "out of band transactions" because of course, it's easier to say than just "spam"

In this way, the whole Lightning Network would be labeled as "attack". So, do you want to see all of that traffic on-chain instead?

What has been described in the OP is not an 51% attack. First, you have already 2 miners with 66% hashrate, not a 40% miner slowly building up to 51%. The 66% cartel is squeezing out the third miner with 33% hashrate - but only because the 33% miner refuses some transactions and thus is a bit slower. Basically this is the way censorship resistance in Bitcoin works And so what you are describing is basically what Core has been saying all the time: filters based on policy do not work. The incentives are always ensuring that those that include all or most consensus compliant transactions can have the easiest time for mining. Those who are trying to censor will be censored (or need more hashrate). Now a little exercise... ... replace the "green" and "red" transactions in your example with "AML compliant" and "not AML compliant" transactions. It would be exactly the same. The "not AML complliant" transactions cannot be censored, and those who try it, have disadvantages at mining due to the compact block mechanism. What Knots wants is thus AMLcoin? Basically what the Knots filters do is the same thing than a miner trying to exclude non-AML compliant transactions ... (btw, that 110 thingy called a BIP by some is something entirely different, it is an evil hard fork enforced with only 55% consensus and has nothing to do with the scenario described in the OP.)

That is a bit different. LN works as a L2 outside of the chain and outside of the network. These miners running LibreRelay are operating a cartel inside the network to escape the policy of the nodes and push as much spam as they can. LN helps scale bitcoin by removing some of the load from the chain. The LibreRelay spam cartel is putting more strain on chain What they are (or might) be doing is the definition of a 51% attack.

Well, if they will succeed, then it will be also used in that way. Because if you can block spammy transactions, and it will work, then you can block any transaction, by using the same methods. And then, the only thing you would need, is to convince people, that "mixing coins is a spam", or "sending coins without AML is a spam", or that anything you want to censor is a spam. Just call it a spam, use the same methods, and voila, you have a great censorship tool, working way beyond "spam", which can be used to block regular payments between users, in exactly the same way. I don't know, maybe Luke should just run a signet instead, and everyone should ask him for permission, to use a coin. Because you never know, maybe when he will see your Script, he will call it a spam, and block it? There should be a table somewhere, like "use cases approved by Knots", to let users know, which use cases won't be blocked. Because otherwise, it is highly subjective, what will be blocked in the future, and what will be allowed. And how people can be sure, that it won't be blocked, when OP_IF can be rejected? Where is a list of all allowed use cases? There should be something like that on Knots pages, because otherwise, you can use something today, and tomorrow, Knots users can block it, and call you a spammer. If there would be such a list somewhere, then users could at least say: "you allowed me to use it in that way, so don't try to block it now".

Disclaimer: I'm not saying this theoretical 51% attack is happening. I'm simply suggesting there are evidence of it happening. With no direct proof of it. Yes, it is a 51% attack, the textbook definition of it. First you need to know that one big pool actually secretly owns several other pools. I don't remember which one owns which ones. The names are not comingtoo me right now. Think about it. A 51% attacker can basically hold back on some of his own blocks and keep mining on his own blocks faster than the rest of the network combined. Only 3 pools with 17% of the hashrare each could team up to create a 51% attack. Or it could be 5 pools with 10.2% of the hashrare each. They could use preferential peering and drop all filters to allow maximum spam. And together, they could agree to with withhold blocks while they mine faster together as a cartel than the rest of the network. This makes absolute no sense. First of all, filtering out some transactions and mining blocks withfewetr transactions will only speed you up, not slow you down. Imagine you mine a full block with 4000 txs in it and 10% of it being stuff the network filters. And I mine a block with only 4 txs in it, or none at all, with 0% of it being filtered our by the nodes. The nodes will propagate my block faster because it's smaller in size, takes less time to propagate as a 1kb block will be sent around the nodes faster than a 4mb block. And the nodes don't need to redownload and re-verify the 10% of transactions they don't have in their mempool. Secondly, the two miners with 66% of hashrate can build on top of their own fork faster than the 33% solo miner. And since their blocks are full of spam and propagates slower, they don't even have to withhold blocks. The nodes are doing it for them by slowing down the propagation speed. So Steve and Bob don't care if it takes hours for the nodes to relay their blocks to Lisa. They almost always will be on the longest chain with the most proof of work. I somewhat agree with this. If my theoretical cartel is in place, they could turn the filters around and mine against the filters, and actually benefit from putting spam in their blocks. The problem here is that the filters could be tantamount to a posted speed limit. When core sees the big miners going over the posted limit, they decide "we might as well remove the posted limit and let everyone speed". BIP110 approach is saying we are going to put speed bumps and force them to slow down by moving the policy at the consensus level. If posted speed limits don't work, speed bumps will. If filters don't work, consensus will. There you go again, framing pro-spam as censorship. Typically shitcoin spammer thing to do. Bitcoin is money. You can buy your dickbutt.jpeg or your pancake with bitcoin. But neither your dickbutt.jpeg nor your pancake belong on Bitcoin. You can express your freedom of religion in your catholic church. But Muslims and Jews stopping you from preaching Jesus in their temples does not amount to depriving you of your freedom of religion. GTFOH. Get lost with that bullshit, trying to make a comparison between fighting spam and AML/KYC censorship. First andformost , good lock trying to convince the 90,000 nodes tobamn non AML compliant txs. If anyone tries to fork bitcoin into AML compliance, the nodes will reject that fork with a reactive fork. And the reactive fork will be the overwhelming winner. Secondly, if AML compliance ever comes to bitcoin, it will be from the pools, as Mara once tried to do, not from the nodes. Get real with that stoopit nonsense. That is how stupidly low the coretards have gotten. When Satoshi was confronted with the idea of Lady Gaga videos on chain, he said: "That's one of the reasons for transaction fees.  There are other things we can do if necessary." If Satoshi said that today, coretards and spammers would claim Sayoshi is a racist and a bigot who wants to censor Lady Gaga's talent.Shameful coretardss.... I can't decide if you are a bad actor or an idiot. Again, when confronted with the idea of Lady Gaga videos on chain, Satoshi said: "That's one of the reasons for transaction fees.  There are other things we can do if necessary." But you try to claim than blocking spam and Lady Gaga videos is the same thing as censoring non AML compliant UTXOs? Get the fuck out of here. The nodes WOULD NEVER GO ALONG WITH THAT NONSENSE. But we all know if that ever happens, it will likely come from the big pools,nort from the 90,000 nodes. But go ahead. Try to do a fork with AML/KYC compliance. See how many nodes will go along with that shit. But fear not, those big spam pools with a legal department will surely sign up for that shit. Only, they know the nodes won't go along with it.

When people don't know, what is spam, and what is not, then there is a problem. Because Knots makes no guarantees, that the scripts, which are not blocked today, won't be blocked tomorrow. You never know, if the list of filters will be expanded, and what else will it include in the future. Which means, that every time, when you want to know, if something is a spam or not, then you have to ask Luke, which is quite centralized way of doing that. There should be at least some website, or some other code, which would tell users "is this transaction spammy?". Because now, they can only guess, how far the current list of filters may be expanded. Are there any use cases, where Knots could safely tell users "you can use it, we won't block it in the future"? Even today, there are nodes, which don't broadcast any transactions, and they can share only blocks. For them, all transactions are red, and only coinbase transactions are green. There are only around 20-30k nodes, which are publicly reachable. Everyone else blocks incoming connections, so it is harder to reach that kind of nodes. Also, it is harder to measure them, and you don't know if there are 90k, 100k, or maybe 80k, because such nodes can connect to you, but you cannot connect to them directly: you have to go through some other, publicly visible node. So, they are not the core of the network, they are on its edge. And even if they filter things, then still: they need a node with incoming connections, to see the rest of the network. And because they heavily depend on that connection, then their filters are completely ignored, if the node with incoming connections is allowing that traffic. The only impact they have, is if someone is reaching the network only through them (which means for example SPV users, connected only to that node for some reason). Of course. But you probably don't want to see filters, based on Proof of Work. This is how coinbase transactions are filtered, and I guess you don't want to expand that filter for users. That kind of attacks are far from being "stealth". Nodes can see chain reorganizations, and they can exactly compare, which block they previously had, and which block they have now. This is what you can get by using "getchaintips" command. Even invalid blocks are saved by nodes.

Were they the ones routing through NYIIX to NETIX back around the beginning of Covid? If so then yes, they are still going strong here. From the gossip around the data center they just added a bunch more miners that they got used from a mine that shut down.

Pepe does not understand how BTC and the internet in general works. Do you think he actually can figure out console commands. Yup, wanted no more then 5 or 6 hops between their routers and the stratum servers. And no stratum servers hosted by AWS / Google / Microsoft / etc. As was said to me, if they can't host their own servers and protect them then we don't need to send hash to your pool. It's amazing that even now in 2026 that people still host their stratum servers on places like Amazon and such. I could kinda maybe sorta see using cloudflare to help with DDOS but putting them someplace else I just don't get. Preferential peering is not what I was talking about / describing but it's kind of an OK term for non technical people to try to understand. But once again LibreRelay is nodes talking to each other. FIBRE and what my old client and at a guess CoreRulezKnotsAreFulez client or at least someone he knows is discussing the route between the nodes / pools. -Dave edit: @CoreRulezKnotsAreFulez anyone from the DC they had here in NY move up there with you? I know there was some talk about people moving but since I was the external hired help they never told me if anyone did.

No, an 51% attack means that a 50+% majority is able to reorg the chain. In your example, the minority miner is a little bit slower due to compact blocks, but that's not the main reason he's "squeezed out". The main reason is that two 66% miners have full liberty to reorg everything they want. The minority miner can be as efficient as he's able to ... he'll always be reorged if the cartel cooperates. Your example would work if we're talking about a 49.9% miner who perhaps would be able to come close to 50% if the remaining 50.1% are a little bit slower due to compact blocks or whatever other network-related delays. But nevertheless, the incentive model always works: Thou shall mine all transactions which are consensus compliant, otherwise you give up a (small) part of your hashrate. If you reach consensus outside of your tiny Lukecoin bubble. And that's a quite big "if". Of course my post was provocative, like all of yours But I only posted an example which is technically identic to yours. Only that in that case, I think even we both agree that the "good ones" are the anti-filters guys. Now if you think filters "should work somewhen", what should Bitcoin protocol incentive? IMO if there is a tiny subset of "censorship" that could be from some point of views framed as "good" (you know that I somewhat agree that spam is bad, at least stuff like BRC-20 and image-based NFTs) but it is technically equivalent to a "bad" censorship effort like AMLcoin? Unfortunately as a protocol designer I'd not incentive that type of filter. I would have perhaps (!) supported a stricter consensus-based ruleset if it was carefully crafted, to not put any useful mechanisms (like LN, inheritance contracts etc.) in danger, and above all: only considered an emergency measure if spam really was ramping up again. But "BIP-110" is kindergarden level programming, sorry.

Only coretards don't know what spam is. The nodes know what spam is and what spam is not. Sure, you can find some edge case that is hard to define as spam or not. Like you could argue that the miner inscription in the coinbase is a form of spam, or is useful. But nobody really has a problem with the coinbase inscription. If you've mined a block, you can definitely say you've earned your very small 50 bytes inscription which would get replaced by random data if you put nothing there. But if you don't know if a Lady Gaga video, dickbutt.jpeg, stamp, or rune is spam or not, you are most definitely a coretard and you want to blow up more spam filters. Can't figure out if a dickbutt.jpeg is spam or not? Maybe you belong on ETF. GTFOH Knots by themselves are completely unable to block any specific kind of script. They simply don't have that power. No single entity in the network has that kind of power. But let's entertain your retarded claim of Knots deciding to block all non-AML compliant scripts tomorrow. Who's going to go along with that retarded idea? You think any significant amount of nodes would go along with it? You think the 90,000 nodes don't know the difference between a dickbutt.jpeg and AML compliant scripts? We do know that Mara and other big pools would happily go along with that AML/KYC nonsense. But nodes would most certainly reject such a ridiculous idea.