What is your take on Bitcoin Knotz? Bitcoin node and wallet by Luke Dashjr

[Satofan44]

Core developers heard enough complaints. A lot of Open Source creators can hear a lot of things, that they don't want to hear. At some point, they will say: "fine, I wrote the code you wanted, now you can do everything". When they will be responsible for absolutely nothing, then each user will pull the rope in its own direction. And then, the base layer will allow everything, so the minority, that wants only financial transactions, will be forced to build things on top of it, and process only a subset of it. Because the requirements to process everything, will be just too high.

You are just slightly mistaken here. They created code that they want, code which most users do not want. They may think or even believe that it is what most people want, but it is not true. Delusions go deep.

From what I see so far Core will continue to make matters worse and not better. However, I really hope that I am wrong about this.

I think you are right. They will be responsible for nothing, because it will free them from being ever sued by anyone, and even accused of anything. It will make their lifes easier. They will just say in the future: "do what you want, the code from the client will never stop you".

Next limits will be lifted one-by-one.

• OP_RETURN limit? Lifted.
• Standardness limit? Partially lifted in P2WSH, but will be fully lifted at some point, and new upgrades could be made in a different way. It doesn't matter, if all non-standard scripts can be made standard, when they are wrapped in a standard way.
• Fee limit? Lifted a bit, from 1 sat/vB to 0.1 sat/vB, but it may be fully lifted in the future, because why not.
• Block size limit? Lifted from 1 MB to 4 MB, and will be potentially increased into unlimited levels, by future soft-forks or no-forks. Blocks can be always bigger, and unlike Segwit, their bigger size can be optionally checked, instead of being enforced by OP_RETURN inside the coinbase transaction.
• Sigops limit? Lifted from 20k sigops into 80k sigops, but can be increased as well, because it is not enforced on quantum signatures, and they can have just no limit. Then, old nodes will see just some data pushes, and maybe some OP_SUCCESS calls, or other OP_NOPs.
• Proof of Work limit? Hashrate majority can switch to any difficulty they would want to. Timewarp attack is one example, but there are more.
• 21 million coins limit? Zero satoshis is the valid amount, and the Script is enforced by consensus rules. The network have no UTXO set size limit, or UTXO count limit, so it can be spammed with zero satoshis, and a future soft-fork can be applied, which will count them in a different way. Old clients don't have to see new amounts, just like non-Segwit clients don't see any witness data. Which means, that different networks can live on the same chain, and trace the same chain of Proof of Work headers.
• Max block time limit? The block header can store the fake timestamp, and the real one can be calculated from some data pushes somewhere else, for example from the coinbase transaction. Old clients could see constant block reorgs, new clients could see a stable chain. Everyone would upgrade, after seeing that mess.
• SHA-256 message size limit? The old hash function can be wrapped in a new one, in a soft-fork way, just like hardened SHA-1 was built on top of regular SHA-1. There is no need to change it. As long as all old messages will hash to the same thing, and only broken messages will hash to something new, most users will be unaffected, and agree on that patch.

Tell me about a limit, that could never be lifted. Name it. Show me something, which could stand the passage of time.

You can easily gather support for Knotz and other implementations with this kind of messaging. These views and behavior would essentially constitute a betrayal of everything that Bitcoin stands for. How much of it is true is not for me to decide. I'll wait and see. 

[mindrust]

…. I cannot find it now, but I remember reading a bitcointalk post by some "ex core developer", who wrote about future people, shouting "save us", and him, whispering "no"…

Since I have read a similar non-sense comment either in this topic or somewhere else a while ago I have to make a comment. Or maybe I read the exact same post you mentioned, I can’t rememher but either way this comment bothers me.

This ex-dev thinks people are chained to use bitcoin for some reason.

The reality is, if people find bitcoin unusable, too slow or too expensive; they’ll switch to something else. It is because most people don’t keep their life savings in btc anyway. They are not overcommitted or maximalists. They have the freedom to choose. They have done it before.

They might beg only if they were hodling a big chunk of btc which they are having problems with selling but then that means the prices area about to crash irreversibly because everyone wants to exit now but there are not enough buyers to counter the sales. Hence they beg “Save us!”  That scenario would be the end of bitcoin pretty much.

Maybe he is an ex dev now exactly because of his doom and gloom personality, not sure. I don’t think there will he a big issue. A Trillion dollar size asset won’t go down like this because the devs are running away from responsibility imo. We’ll be fine.

[ertil]

They created code that they want, code which most users do not want.

If most users wouldn't want Taproot, then it wouldn't be activated. Because Bitcoin is not ruled by miners.

You can easily gather support for Knotz and other implementations with this kind of messaging.

Oh, so users will take responsibility, that developers don't want to take? Great. This is exactly what we need. You want to filter transactions? Then just do it, because developers won't do any of that.

But later, just don't complain to the developers. Your node, your rules. Then, you can complain only to the person, who wrote the code, if the final outcome will be worse. So, if Luke's code will be bad for any reason, then later complain to him. And if you switch to your own implementation, then you will be able to send complaints only to yourself.

I can’t rememher but either way this comment bothers me.

I found it:

.Because . Its . An . Attack.

Stuffing the blockchain full of unlawfully copied material is an attack, it's probably no accident that they picked the notoriously litigious nintendo as an initial target.

Doubling the UTXO set size with meaningless 'tokens' that have absolutely no purpose is an attack. (people talk about ordinals a lot but by far most of the congestion when I've looked is actually BRC-20)

If the usage were genuine they could save hundreds of millions of dollars in fees just doing it on their own blockchain, or almost any one of a thousand pre-existing ones.

The very same people doing this stuff are BSVers funded by Calvin Ayre.  This isn't speculation or a conspiracy theory, you can simply look them up. They carried out the same attacks on BSV, adding 165 GB to the utxo set in just five days (not the chain! the utxo set!), pushing off every other known non-calvin-controlled/funded node off the network.  At least in Bitcoin it mostly just drives fees up rather than forever destroying the network in days, because robustness to these kind of attacks was considered.  Many people are mistaking the protection *working* (fees go up making the attack astronomically expensive for the attacker) for the problem itself.

Most of you are absolutely fucking idiots. You deserve what you get.

Eventually you will figure it out as one by one your nodes are turned off by DMCA complaints, you get fucking bankrupted by vexatious copyright litigation and other bullshit resulting from attacks on the network that you were happy to pretend were actually good when you thought they could pump the price and you will look up and shout "save us!" and I'll whisper "No."

See? You have an official statement, that nothing will be done, poor users could cry as much as they want, and old coders will do nothing about it.

So, if you want to be safe, then just run your own implementation. Decide, what code you want to run. Read the code. Check it. Change it, if you want to. Fix bugs, and make your own improvements. Your node, your rules. Welcome to the new reality, where developers are responsible for nothing, and it is your job, to decide, what code should be executed.

[mrust_mobile]

This post of gmaxwell looks out of context in my opinion. He is pretty much saying small blocks are a safety measure as the spam gets worse, it also gets more expensive to sustain it. That’s not false.

I don’t fully understand what he is saying in the second part, can nodes be shut down by the gov? Then bitcoin has been dead for decades, in fact, it was never alive to begin with. He must be referring to the shit Calvin Ayre and Craig Wright has been trying to pull by manipulating the justice system. Basically he is saying if they succeed, they will be taking over btc via court orders and guess what, they failed.

I don’t see how this old post of his relates. What do i miss?

[Satofan44]

But later, just don't complain to the developers. Your node, your rules. Then, you can complain only to the person, who wrote the code, if the final outcome will be worse. So, if Luke's code will be bad for any reason, then later complain to him. And if you switch to your own implementation, then you will be able to send complaints only to yourself.

Missing the point again, on purpose? Users want filters on the protocol level, not do whatever you want with your node level. The latter is simply a compensation for the lack of the former.

I found it:

Most of you are absolutely fucking idiots. You deserve what you get.

Eventually you will figure it out as one by one your nodes are turned off by DMCA complaints, you get fucking bankrupted by vexatious copyright litigation and other bullshit resulting from attacks on the network that you were happy to pretend were actually good when you thought they could pump the price and you will look up and shout "save us!" and I'll whisper "No."

See? You have an official statement, that nothing will be done, poor users could cry as much as they want, and old coders will do nothing about it.

So, if you want to be safe, then just run your own implementation. Decide, what code you want to run. Read the code. Check it. Change it, if you want to. Fix bugs, and make your own improvements. Your node, your rules. Welcome to the new reality, where developers are responsible for nothing, and it is your job, to decide, what code should be executed.

I don't get what he wants to say in the last part. It seems like a "I told you so, so you deal with it now" even though nowhere did Core try to provide solutions to prevent these things, so what exactly is his point? Most node operators do not want ordinals or any other data storage, so who is this message targeting? Random ordinals proponents? Lecturing random normies about attack vectors is not gonna get us anywhere, it is a complete waste of time.

I don’t fully understand what he is saying in the second part, can nodes be shut down by the gov? Then bitcoin has been dead for decades, in fact, it was never alive to begin with.

Of course they can, this was always the case. The can approach this via several means, but the most common one would be either to go after the person who is hosting the node or the service provider. How do you think they manage to take down domains with illegal content easily? Why would they not be able to do the same with servers? This is why the node count, distribution and decentralization is precisely very important and this has been emphasized for a very long time. This is the defense vector against even the strongest government in the world. Bitcoin would continue to work even if the managed to shut down 99% of the nodes, which is unrealistic under any scenario.

He must be referring to the shit Calvin Ayre and Craig Wright has been trying to pull by manipulating the justice system. Basically he is saying if they succeed, they will be taking over btc via court orders and guess what, they failed.

Yes but only partially. We don't know where the laws will take us in the future. Even if copyright claims against Bitcoin are complete bullshit that does not mean that they could not happen. A lot of laws and litigation regarding said laws is absolutely retarded. Just look at piracy as a simple example, where they try equate copying bits of information to stealing an actual thing which is completely different as the latter removes something from its owner and the former does not.

If there is a lot of malware, CSAM, copyrighted works in the Bitcoin blockchain moving forward who is to say that the law makers will not use this as a ground to go after Bitcoin? The best way to attack it from a legal standpoint is to go after the node operators or the miners, at least those that can be identified for starters.

I don’t see how this old post of his relates. What do i miss?

It relates to the discussion between him and me, he was trying to find the post which he was referring to. Reread the interactions on the last page.

[wrapperband0lite]

My take, and why I’m running Knots right now

I switched my node to Bitcoin Knots because I’ve found and reproduced a serious operational issue on Bitcoin Core v30.0rc1 related to the OP_RETURN change.

What I showed
- The test showed the op_return is now big enough to include a zipped Malware signature - which AV software detects and quarantines.
- If you enclose a known signature inside a ZIP and embed that ZIP via OP_RETURN, mainstream AV/EDR can quarantine the raw block file (blk*.dat).
- I reproduced this on regtest with Bitcoin Core v30.0rc1; ClamAV flagged the block file itself. That causes I/O errors, stalled nodes, and broken backups/NAS scans.
- It is not code execution, but it is an operator DoS. This will be used by malicious actors to disrupt the Bitcoin system.

Why that affects my choice of Knots
- Knots has stricter policy defaults and anti-junk stance around arbitrary data. That aligns with my goal to reduce on-chain delivery of recognizable containers that AVs scan by default.
- Until Core explicitly addresses the operational impact of increasing OP_RETURN, I prefer Knots’ posture for the node that faces my storage and backup pipeline.
- Basically, running Knots is a protest, it is crazy that Bitcoin Core have instituted this provably dangerous change in op_return size, for no benefit to 99.999% of Bitcoiners

Proof and scripts
Full write-up with Linux and Windows regtest scripts and paste-ready proof:
Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain

[mindrust]

I don’t fully understand what he is saying in the second part, can nodes be shut down by the gov? Then bitcoin has been dead for decades, in fact, it was never alive to begin with.

Of course they can, this was always the case. The can approach this via several means, but the most common one would be either to go after the person who is hosting the node or the service provider. How do you think they manage to take down domains with illegal content easily? Why would they not be able to do the same with servers? This is why the node count, distribution and decentralization is precisely very important and this has been emphasized for a very long time. This is the defense vector against even the strongest government in the world. Bitcoin would continue to work even if the managed to shut down 99% of the nodes, which is unrealistic under any scenario.

He must be referring to the shit Calvin Ayre and Craig Wright has been trying to pull by manipulating the justice system. Basically he is saying if they succeed, they will be taking over btc via court orders and guess what, they failed.

Yes but only partially. We don't know where the laws will take us in the future. Even if copyright claims against Bitcoin are complete bullshit that does not mean that they could not happen. A lot of laws and litigation regarding said laws is absolutely retarded. Just look at piracy as a simple example, where they try equate copying bits of information to stealing an actual thing which is completely different as the latter removes something from its owner and the former does not.

If there is a lot of malware, CSAM, copyrighted works in the Bitcoin blockchain moving forward who is to say that the law makers will not use this as a ground to go after Bitcoin? The best way to attack it from a legal standpoint is to go afteron the node operators or the miners, at least those that can be identified for starters.

I thought bitcoin was above lawmakers and governments. Unkillable, invincible, decentralized...

If they can kill btc just like that, then It wouldn't be wrong to call it a failed experiment.

Still though, they seem to act neutral or friendly-neutral for now since they still let us play with crypto. I'd like to see them going fully hostile against bitcoin or... even better; monero.

Let's see how far they can go and if we'll survive it. Monero already don't have much to lose but it still possesses threat to the governments. Electric chair death penalty for every monero holder, miner and node runner, let's see if anyone still dares to touch it.  

[Satofan44]

I thought bitcoin was above lawmakers and governments. Unkillable, invincible, decentralized...

If they can kill btc just like that, then It wouldn't be wrong to call it a failed experiment.

While I do agree with your sentiment, this is not an argument against doing something. Otherwise why patch anything at all? Every existential bug that we have had should have been left how it is. Because if someone can kill Bitcoin like that, then it is a failed experiment?

Still though, they seem to act neutral or friendly-neutral for now since they still let us play with crypto. I'd like to see them going fully hostile against bitcoin or... even better; monero.

Let's see how far they can go and if we'll survive it. Monero already don't have much to lose but it still possesses threat to the governments. Electric chair death penalty for every monero holder, miner and node runner, let's see if anyone still dares to touch it.  

It doesn't mean that they will succeed in killing it, but they can damage and severely weaken it depending on the specifics of how this plays out. If you are at risk for a CSAM crime if you run a node, would you run one? I would not even run a hidden one, the risk is not worth it.

- Basically, running Knots is a protest, it is crazy that Bitcoin Core have instituted this provably dangerous change in op_return size, for no benefit to 99.999% of Bitcoiners

It is definitely a protest and the last part is interesting of course. A controversial change to benefit 0.001% of users and to appease potential attackers?  

[NotATether]

I thought bitcoin was above lawmakers and governments. Unkillable, invincible, decentralized...

If they can kill btc just like that, then It wouldn't be wrong to call it a failed experiment.

Killing BTC does not mean only banning bitcoin, but also making Bitcoin completely impractical to use for the users who Bitcoin was meant to help.

Fortunately, Ordinals and Runes and stuff like that, these have only done minimal damage to Bitcoin, and many people can still use it for monetary purposes in lieu of all of the spam.

[wrapperband0lite]

Thanks for the thoughtful write-up, d5000.

This only works if the spammer is kind enough to use OP_RETURN or the Taproot/Ordinals method.

If he uses a collection of fake pubkeys (Stampchain ...), then you cannot prevent any data to be stored on your node...

Agreed: fake pubkeys and some witness paths are the widest doors and the most harmful for UTXO and state. My point is narrower and practical: opening OP_RETURN wider creates an additional, reproducible class of incidents that shows up in ops today.

The idea is thus, at least, to nudge the "de facto malicious" spam into OP_RETURN... before they get the idea to use the Stampchain method and we get much higher node operation costs.

The “nudge into OP_RETURN” approach ignores external systems that many operators rely on. Engines carve and scan ZIPs inside large binaries. A 68-byte string is easy to miss, but a valid ZIP is not. Bigger OP_RETURN means easier and more frequent recognisable containers such as ZIPs, nested archives, and multiple signatures, so more engines hit and more nodes are disrupted.

There was a proposal to implement a check that pubkeys must be "real"... Even Luke-Jr seems to have admitted... the additional validation effort wasn't worth it.

Even if Door 1 stays wide, making OP_RETURN larger does not reduce that harm. It simply adds another easy path for AV-trigger payloads and normalises it at the policy level, shifting a real operational cost onto node operators and their backup or gateway tooling.

What I showed (v30.0rc1, regtest) 
Embed a ZIP with a known signature via OP_RETURN and a mainstream AV (ClamAV) will quarantine the raw block file (blk*.dat). That is an operator DoS: I/O errors, stalled nodes, broken backups and NAS scans. This is not code execution; it is concrete, repeatable behaviour.

Why pruning is not a fix 
Pruning is often brought up as a counter, but it does not address this class of incident.

• Pruning removes whole old blocks, not bytes. It does not strip OP_RETURN from blocks you keep. Recent blocks must still be stored and can be quarantined.
• You still download and validate everything once. AV can scan or intercept on write or on access before pruning ever runs.
• Backups and NAS scans run outside Core. They scan archived snapshots and network shares regardless of your prune target, and can quarantine copies even if the live datadir is excluded.
• Many services cannot prune. Archival nodes, indexers, explorers, and some enterprise setups keep full history and will remain exposed.
• UTXO vs history. OP_RETURN is not in the UTXO set, but the bytes live in block files. Pruning changes how many block files you retain, not how AV treats the ones you must keep.

Details, scripts, and paste-ready proof: 
Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain

TL;DR 
Redirecting spam toward OP_RETURN may look cheaper at the protocol level, but it externalises a real operational cost. Before increasing OP_RETURN, that cost should be acknowledged explicitly.

[Wind_FURY]

Although you "could" be right, THAT doesn't guarantee that it has a zero chance of happening. Plus as far as the network is concerned, if it follows the consensus rules, then it should be allowed.

This is not a huge precedent that you are trying to make it out to be. Bitcoin was never intended to be an arbitrary data storage solution. Reinforcing these things is just a return to original intentions.
There will be people who will have other opinions.

Content moderation is very different from economic censorship.

Is that what you want to call it now? OK.

Yes, data storage and financial transactions are entirely different.

But who actually has the authority to "moderate" a decentralized/censorship-resistant network? OR, who gave those people that try to "moderate" it the authority?

Plus most importantly, is the "moderation" actually working/is it actually effective? It would be stupid to support such a move if it isn't, no?

[ertil]

But who actually has the authority to "moderate" a decentralized/censorship-resistant network?

Miners always moderated it. If you have "Alice -> Bob" transaction, and "Alice -> Charlie" transaction, then miners decide, which one should be confirmed.

Also, nodes always moderated it, by enforcing "standardness rules", which also allows upgrading the protocol, without blocking anyone else's coins. When standardness rules will be lifted, then it will be harder to upgrade the protocol.

OR, who gave those people that try to "moderate" it the authority?

They have the authority, because they have a lot of hashrate, so they can produce a lot of Proof of Work. However, if users will be disappointed, then they can always pick a different chain as "valid", and move their coins to the system, which they want to use. And for that reason, miners can decide about a lot of things, but not about everything.

And when it comes to nodes, they can always moderate the traffic. More than that: they can provide different services. There are nodes, which don't relay any transactions at all, but they are still part of the network, because they accept blocks.

Any node can decide, which features are supported, and which are not. For example: P2P marketplace was supported in the past, but it was disabled in early release. The same with poker game, built into the client.

Plus most importantly, is the "moderation" actually working/is it actually effective?

Yes, because if your transaction is mined by a pool with 1% hashrate, and censored by 99% of hashrate majority, then on average, you will wait at least 100 blocks, to see it confirmed.

Also, it is possible to accept a lot of transactions in relay mode, but include only a small subset of that in produced block templates. Because relay rules, and block creation rules, are separated.

It would be stupid to support such a move if it isn't, no?

I think relay rules will be more relaxed, and maybe even non-standard transactions will be relayed in the future. But block inclusion rules should be more strict. Because then, users could send a lot of things over P2P network, and a lot of these things can be used only for communication, related to making batched transactions. And then, users could send hundreds, or even thousands of transactions, and all of them could be relayed. Then, all of that traffic could be collected and processed by nodes. And then, the final, batched version, with the highest fees, could be taken by miners, and confirmed.

Also, P2P batching is actually used in practice, for example in signet faucets: https://mempool.space/signet/tx/2f4ffd821a1d81f27cc2b16c50c7105e8b25585fd0a68a80c70da35a62b99107

See "RBF Timeline", where the same transaction is bumped over and over again, until it is confirmed. In the same way, users could start sending transactions, and bump them by single satoshis each, and finally, it could reach 0.1 sat/vB, 1 sat/vB, 10 sat/vB, or any other meaningful fee rate, and serve many users, while also taking less on-chain bytes, than it would, if people would send it without any batching.

[scottmsul]

The real question is, do we want upcoming "spam," which by the way will be mined with 100% certainty, to be publicly visible throughout the p2p network? Or would you rather you and your peers pretend it doesn't exist and be unaware of a bunch of upcoming transactions, because of a false belief that it somehow makes them less likely to be mined?

I am pretty sure that a large block of users and node operators do not want this spam to be included at all in the chain, in any form. Do we need to do an USAF-style but purely signalling fork to demonstrate this to be true?

UASF stands for "user-activated soft fork", what you're proposing is a chain split and therefore a hard fork. Unless of course this chain were to eventually get more total work and re-org the chain, in which case it would be a soft fork, but that seems unlikely.

I'm not sure how many users and node operators actually care if this "spam" is on the chain or not. Can the spam ever exceed 4MB? No. Is it making it impossible to run a node? No. Is it stopping Bitcoin from working as intended as money? No. Personally I don't really see what the issue is.

I think if the knots folks were to do a chain split as you suggest, even if intended only as a "signalling" fork, it would still be a fork nonetheless. As such it would probably end up developing a name, and a ticker, and a price. Over the long run this price probably would not do so well against BTC, and go the way of bitcoin cash. Critics of knots would likely use this decline in price to claim there is little economic demand for this tightened consensus ruleset. I think Luke and the knots advocates, as crazy as they may seem in other ways, are intelligent enough to understand this game theory. This is why they are avoiding the topic of changing consensus and sticking to relay policy, which is ineffective technically, but seems to be getting traction "socially".

[Satofan44]

The real question is, do we want upcoming "spam," which by the way will be mined with 100% certainty, to be publicly visible throughout the p2p network? Or would you rather you and your peers pretend it doesn't exist and be unaware of a bunch of upcoming transactions, because of a false belief that it somehow makes them less likely to be mined?

I am pretty sure that a large block of users and node operators do not want this spam to be included at all in the chain, in any form. Do we need to do an USAF-style but purely signalling fork to demonstrate this to be true?

UASF stands for "user-activated soft fork", what you're proposing is a chain split and therefore a hard fork. Unless of course this chain were to eventually get more total work and re-org the chain, in which case it would be a soft fork, but that seems unlikely.

A purely signalling fork of the code will not do a chain split.

I'm not sure how many users and node operators actually care if this "spam" is on the chain or not. Can the spam ever exceed 4MB? No. Is it making it impossible to run a node? No. Is it stopping Bitcoin from working as intended as money? No. Personally I don't really see what the issue is.

I have never met anyone with a brain larger than the size of a chickpea that supports Ordinals or various spam data storage attempts. At every serious Bitcoin place where I have spoken to people they were almost always unanimously against it.

I think if the knots folks were to do a chain split as you suggest, even if intended only as a "signalling" fork, it would still be a fork nonetheless. As such it would probably end up developing a name, and a ticker, and a price. Over the long run this price probably would not do so well against BTC, and go the way of bitcoin cash. Critics of knots would likely use this decline in price to claim there is little economic demand for this tightened consensus ruleset. I think Luke and the knots advocates, as crazy as they may seem in other ways, are intelligent enough to understand this game theory. This is why they are avoiding the topic of changing consensus and sticking to relay policy, which is ineffective technically, but seems to be getting traction "socially".

None of that would happen. You don't know what purely signalling means.

But who actually has the authority to "moderate" a decentralized/censorship-resistant network? OR, who gave those people that try to "moderate" it the authority?

If "some entities" didn't "moderate" Bitcoin in many ways, Bitcoin would not exist. How else do you deal with any kind of attack then? Make a simple assumption. For some reason a dust spam attack is again viable and cheap. Someone executes it, the network is being damaged and its usability is heavily impaired. Only by "moderating" can you solve this and return to a state of normalcy, otherwise you have to wait and hope that the attacker stops? There is no other alternative.

Plus most importantly, is the "moderation" actually working/is it actually effective? It would be stupid to support such a move if it isn't, no?

It is not working because those that can implement these things are not interested in implementing them. They work on whatever they want even though they are paid extremely well for working on Bitcoin.  

[scottmsul]

The real question is, do we want upcoming "spam," which by the way will be mined with 100% certainty, to be publicly visible throughout the p2p network? Or would you rather you and your peers pretend it doesn't exist and be unaware of a bunch of upcoming transactions, because of a false belief that it somehow makes them less likely to be mined?

I am pretty sure that a large block of users and node operators do not want this spam to be included at all in the chain, in any form. Do we need to do an USAF-style but purely signalling fork to demonstrate this to be true?

UASF stands for "user-activated soft fork", what you're proposing is a chain split and therefore a hard fork. Unless of course this chain were to eventually get more total work and re-org the chain, in which case it would be a soft fork, but that seems unlikely.

A purely signalling fork of the code will not do a chain split.

Maybe I don't understand what you're saying. I thought you were saying to reject spam from blocks. How would this not cause a chain split???

I'm not sure how many users and node operators actually care if this "spam" is on the chain or not. Can the spam ever exceed 4MB? No. Is it making it impossible to run a node? No. Is it stopping Bitcoin from working as intended as money? No. Personally I don't really see what the issue is.

I have never met anyone with a brain larger than the size of a chickpea that supports Ordinals or various spam data storage attempts. At every serious Bitcoin place where I have spoken to people they were almost always unanimously against it.

I don't think anyone on the Core side of the debate cares much for spam either, just that it's not a big deal, given the blocksize limits and fee market. I also don't see the point in slinging random insults at people who disagree with you. Have I said anything disrespectful towards you?

I think if the knots folks were to do a chain split as you suggest, even if intended only as a "signalling" fork, it would still be a fork nonetheless. As such it would probably end up developing a name, and a ticker, and a price. Over the long run this price probably would not do so well against BTC, and go the way of bitcoin cash. Critics of knots would likely use this decline in price to claim there is little economic demand for this tightened consensus ruleset. I think Luke and the knots advocates, as crazy as they may seem in other ways, are intelligent enough to understand this game theory. This is why they are avoiding the topic of changing consensus and sticking to relay policy, which is ineffective technically, but seems to be getting traction "socially".

None of that would happen. You don't know what purely signalling means.

A fork, even if intended only for signalling, could still send or receive coins by nodes running under that ruleset. Given this, I think a price would naturally emerge over time.

[ertil]

Can the spam ever exceed 4MB? No.

Of course it can. Legacy nodes don't see blocks bigger than 1 MB. Segwit nodes don't see blocks bigger than 4 MB. But it is possible to make yet another soft-fork, where blocks would be unlimited, just like it is in BSV. It is only a matter of getting a hashrate majority on your side. Consensus is not protected from coordinated block size increase in any way, and Segwit can clearly show, how to deploy things like that in practice.

Is it making it impossible to run a node? No.

Not yet. But even today, when the size of the chain takes hundreds of GB, and where synchronizing a node can take weeks, many users decide to not run any node at all, and rely only on SPV wallet, or on block explorers, or even on exchanges, or contracts like CFD, which don't have to touch any real blockchain at all.

And it is very unlikely, that people will massively start running P2P nodes. It is much more likely, that they will pick more centralized solutions, just because they are more convenient. Only when people will start losing money, like it was in 2008, then they will switch to something better, when there will be no other choice.

Is it stopping Bitcoin from working as intended as money? No.

Of course it is. If you have a lot of non-monetary transactions, and they pay higher fees, then they take place of regular transactions. You can confirm this transaction or that transaction, in a given block. You cannot confirm both, if there is not enough room in a block.

Also, if miners would decide, to send self-transfers with 100% transaction fees, then they could block all users from transacting, for arbitrary long period of time. As long as hashrate majority would get these coins back in fees, the protocol would work. And the same could happen, if hashrate majority would decide to produce only empty blocks, but then, it is obvious to everyone, that some attack is ongoing.

Personally I don't really see what the issue is.

It is quite simple: if miners could change their policy, and nodes would follow miners, then it would mean, that miners can lift more and more limits, and nodes would always follow them. Which would turn miners into a position, where they could start making decisions about the protocol.

Because this is a new attack. Earlier, miners followed Bitcoin Core implementation, and what users wanted, to produce the most valuable coin. But now, some mining pools simply make their own rules, and if hashrate majority would follow, then it would cause node operators, and software developers, to lift next limits, and to give miners more power, than they should have.

The border is not yet known. What if miners would decide to activate a soft-fork, which would give them more coins through things like tail supply? Nobody knows yet, but I am pretty sure, that all possible limits will be tested in the future in practice. Some of them may lead to altcoins, many of them may die, or turn out to be irrelevant, but remember: attacks only get stronger. And people know enough, to not repeat the same mistakes, as BCH or BSV did.

Also note, that protocols like Ordinals, are built on top of BTC, instead of having their own chain. Because they know, that attacking the king of crypto, makes their buggy protocols and tokens worth more. So, I expect even more non-monetary transactions on-chain. Bitcoin will become a cloud storage, unless some users will decide to put some protections, and process only a subset of mainnet traffic. Otherwise, people will be spammed, until they give up.

it would still be a fork nonetheless

There is no need to make any forks, to process less transactions, than the main chain is processing. It can be done without any forking.

To get the heaviest chain of block headers, you have to consume only 80-byte block headers. For everything else, you can use ZK proofs, or other things. You are never forced to store the content of transactions in plaintext. The only thing you have to know, is if a given block is valid, or not. And beyond that, you have to store your own transactions. But you don't have to process someone else's transactions, if you don't want to. There is no consensus rule, which would say so.

A fork, even if intended only for signalling, could still send or receive coins by nodes running under that ruleset. Given this, I think a price would naturally emerge over time.

There is no need to "fork" anything. If miners would put "I hate Ordinals" in their coinbase transaction, or tweak some bit in block version, then it would never split the chain. The fork could happen only, if one group of nodes would react to a signal, by marking some block as "invalid". If both groups accept all blocks, then there is no fork, it is then only a meaningless statistics.

[gmaxwell]

https://www.therage.co/leaked-luke-dashjr-bitcoin-hardfork/

This is the sort of thing that anti-censorship and pro-privacy proponents such as myself have been saying is the logical path of filtering proponents.  Filtering doesn't work for its stated goals-- if the the traffic source is willing to pay (which all current 'spam' is quite willing to pay given prevailing feerates) then policy rules don't block it.  The obvious *following step* is invasive centralizing steps like coercing miners to block transactions based on legal threats and deploying trusted-third-party mechanisms to allow editing past blocks.

Slippery slope fallacy is only a fallacy when there is no good reason to believe the progression will continue.  In this case, it will obviously continue because some default policy stuff cannot achieve the stated goals.

Luke's proposals in that article, for whatever it's worth, are exactly what Calvin Ayre and Craig Wright were demanding from Bitcoin developers: changes to allow replacement of transaction content based on trusted signatures or likewise -- and we faced over a billion dollars on account of refusing to implement their backdoors.  Well some developers, Luke did make a public offer to them to implement their changes in exchange for payment-- a fact that burned us a little in the litigation.  To think that others will go along with such things now is simply insane. 

NFT/shitcoin/etc. traffic is lame, but it's clear that its usually fairly well managed by transaction fees through the market for block capacity.  The occasional flare ups and residual traffic are annoying but are the costs of an open system which we should all gladly accept because the alternative is a "bitcoin" that has little reason to exist.

[ertil]

Hardfork

Some people never learn. In case of a hard-fork, everyone knows, what to do. Then, the situation is the same, as it was during BTC and BCH: sell the coin you don't want, and buy the coin you want. Which means, that people can sell Luke-BTCs for BTCs, and move on. It is already tested, there were many Bitcoin copycats, this one won't be anything new, if it would be a hard-fork.

the logical path of filtering proponents

Hard-forks are not serious. If some hard-fork doesn't have 99.9% market support, then it can easily fail. The "logical path" would be to handle a subset of the mainnet traffic, while still working on the same chain. Forcing censorship on everyone is going to hurt censors more, than the rest of the community. It is much better to convince people, to stay on the same chain, and handle only part of it, instead of forcing everyone to prune some data.

Also, the logical consequence is that some people would use Luke-BTCs, to push data inside private keys, and expose them through weak signatures. If that could work on Grin and Monero, then it could work on Luke-BTCs as well. And then, if everyone will see, that spammers can put their data even into Luke-BTCs, then the community will switch back to the original chain. And then, traders will do the rest, by bringing Luke-BTCs value to the similar levels, as BCH and BSV, or even below that.

Another thing is if Luke's chain will not have 51% hashrate support from double-SHA-256 hashers, then it would be ironic, if it would be attacked in a similar way, as CoiledCoin. Because mining Luke-BTCs and selling them for BTCs is something, that does not break any consensus rules. And if Luke-BTCs will be attacked in a similar way, as testnets were, then he will just taste his own medicine, by seeing his chain destroyed, or made unusable in a similar way, as some altcoins, which were attacked by him.

[Wind_FURY]

https://www.therage.co/leaked-luke-dashjr-bitcoin-hardfork/

This is the sort of thing that anti-censorship and pro-privacy proponents such as myself have been saying is the logical path of filtering proponents.  Filtering doesn't work for its stated goals-- if the the traffic source is willing to pay (which all current 'spam' is quite willing to pay given prevailing feerates) then policy rules don't block it.  The obvious *following step* is invasive centralizing steps like coercing miners to block transactions based on legal threats and deploying trusted-third-party mechanisms to allow editing past blocks.

Slippery slope fallacy is only a fallacy when there is no good reason to believe the progression will continue.  In this case, it will obviously continue because some default policy stuff cannot achieve the stated goals.

Luke's proposals in that article, for whatever it's worth, are exactly what Calvin Ayre and Craig Wright were demanding from Bitcoin developers: changes to allow replacement of transaction content based on trusted signatures or likewise -- and we faced over a billion dollars on account of refusing to implement their backdoors.  Well some developers, Luke did make a public offer to them to implement their changes in exchange for payment-- a fact that burned us a little in the litigation.  To think that others will go along with such things now is simply insane. 

NFT/shitcoin/etc. traffic is lame, but it's clear that its usually fairly well managed by transaction fees through the market for block capacity.  The occasional flare ups and residual traffic are annoying but are the costs of an open system which we should all gladly accept because the alternative is a "bitcoin" that has little reason to exist.

I'm starting to believe that all the drama, and the current narrative of the anti-censorship crowd vs. the filter boys might merely be a "Red-Herring" to distract everyone from the actual motivation behind Knots' current move.

- There might be entities out there who want to fork Bitcoin away from the Core Developers. It's probably the same as the situation during 2017 when individuals behind major businesses, exchanges and miners signed the New York Agreement, WHICH they decided to hard fork Bitcoin to 2MB blocks behind closed doors.

[Satofan44]

I'm starting to believe that all the drama, and the current narrative of the anti-censorship crowd vs. the filter boys might merely be a "Red-Herring" to distract everyone from the actual motivation behind Knots' current move.

- There might be entities out there who want to fork Bitcoin away from the Core Developers. It's probably the same as the situation during 2017 when individuals behind major businesses, exchanges and miners signed the New York Agreement, WHICH they decided to hard fork Bitcoin to 2MB blocks behind closed doors.

Maybe, but that just goes deeper into the speculative and tin foil sphere. It is too late for this kind of attack now. The fork wars of 2017 were both a great and a bad thing for us. Now we have experience in dealing with it and given that we have successfully one once already it will be easier to win a second time. A second fork attack that fails would cement the status quo and essentially make this attack non viable for almost forever.