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

[takuma sato]

Dave's opinion.
Anyone running code by Luke Jr. is risking their funds and computer security since he has proven he has poor OpSec:
https://bitcointalk.org/index.php?topic=5432665.0

If you read how it seems to have happened, and how long it took him to notice you would not ever trust him with software that you run.

No way you believe he was actually hacked. That was an obvious "boating incident" exit. In any case, the code is open source. If you are trusting Bitcoin Knots, you are trusting Bitcoin Core since a lot of it is forked, with interesting features added. Again, open source software, plus peer reviewed with gpg signatures of people putting their reputation on the line.

It might be a boating accident but it is not "obvious" unless you show us your proof. You can say it looks like a boating accident but you can't say "It is a boating accident", that's unless you show us your proof. What you or DaveF (or anyone else including me for that matter) believes is irrelevant. If the judge says he was hacked, then he was hacked. If you know something we don't, go inform the police so they can push charges on him for tax evasion which is the most serious crime in the US.

Since you are making up facts based on assumptions, here is another one:

Do you think Luke is dumb enough to risk life sentence over this? To avoid paying taxes? Which btw triggers only when he spends or sells his coins since there is no wealth tax in the US?

I have not looked at the case in detail, im giving a personal opinion on a piece of news and im just saying as a general rule of thumb how it's hard to believe someone with the technical expertise of Luke would get hacked. I mean maybe he was actually hosting private keys in a public computer. In any case, who cares, it's none of my business. What we are discussing here is, how the blockchain will get spammed with trash.

[Satofan44]

We are only here because of the dismissive behavior of Bitcoin Core. Had they behaved better and communicated more properly, Knotz would have stayed irrelevant.

Just to ask: what communication tips would you give to "Bitcoin Core"?

The issue was debated in the mailing list, and points were made in favour and against the change. The points against it were mostly misunderstandings and debunked. The aggressive behavior was mostly on the side of the opponents of the change.

The person who proposed the change first (Antoine Poinsot) wrote a blog post explaining his motivation for the change. Maybe he shouldn't have used the word "drama" at this stage, but in general the blog post stays in the technical realm so I don't think it's really "fueling the drama" in the debate.

I am by no means the type of communicator that would be qualified for the type of communication/communication expertise that is necessary but I will give you my thoughts anyway. The mailing list is a place for developers and highly technical users. Many people who run nodes are neither which is the result of policies strongly encouraged by Core (and which is a good thing). Therefore, I do not consider the mailing list discussions as "communication". As the debate continued and kind of turned into "drama" I got more and more the impression that the other side is just being slandered. In a "you're just stupid" or "you're paid/malicious" actor way. Excellent communication tactic isn't it? Insult the people that keep the network safe and secure for free because they have concerns/fears about changes.

I understand getting tired explaining the basics or debunking some arguments with random users that I consider elementary school level at this point (such as Bitcoin has no intrinsic value/it is a bubble/it's a ponzi/pyramid scheme etc.). We're an old network and those debates are largely pointless now and a huge time loss for valuable contributors. That said, firstly it should be noted that node operators are neither random users nor are they getting any direct rewards for what they are doing. You can argue that the value appreciation of Bitcoin is their reward, but that is just a dismissive argument that is supposed to justify a lack of gratitude towards them. We always need more node operators, so treat them nicely.   Secondly, that we found ourselves in this situation at all (discussions/concerns turned into drama with increasing dismissal) is a sign of a failure of the initial communication.

For sure communication could be improved, but how? Should Core have a blog, for example? A YT/TikTok channel? Joke aside: I think the big problem is here "who should be in charge", i.e. who represents "Core".

What I think is that indeed someone could have written an ELI5 or so detailing really in layman's terms why this change does not open the door for more data because no cheaper nor more convenient data publication option is given, it only tries to nudge the spam into a less harmful method (Edit: and "closing the door" isn't possible without extreme changes which need much more than standardness policy changes).

Perhaps something like an official blog/newsletter with graphics could be nice and it would not even consume a lot of time for the writer/editor since it would only need to be used sporadically (compared to a blog that has weekly or even daily posts). A post that addresses this particular case should ignore all drama and actors. It should have a clear explanation of HOW things were BEFORE, WHAT actually CHANGES, and a FAQ-style analysis of common worries/concerns and perhaps even a section addressing worst case scenarios as potential outcomes of this change (technical, legal, node operators, etc.) - those that Bitcoin Core members consider possible.

For less controversial changes without so much drama it would be even easier to draft the posts. What is Core working on? What are the current thoughts on scalability? What concerns do we currently have regarding the network? What are the current or medium term priorities? We should not expect people to read mailing list discussions. How many users have the time for that or how many are able to accurately draw conclusions from the posts which they read there? It is a very tiny minority. An occasional post for a group consisting of laymen and low-to-medium technical people would go a long way! Engagement is what they call it these days since you mention YT/TikTok.  

(I agree with you that Luke's personality is not relevant here. His earlier blacklisting attempts however are a sign that his approach to "censorship resistance" could be considered a bit "unique", though.)

Sure, it does have some relevance if we want to strictly debate whether Knotz is the right thing to use. However, my observations here on the social side of things is that people will flock to any alternative if they are pushed into a corner. This kind of communication issues are essentially pushing people into a democrats vs. republicans split, where users will either entrench themselves behind their choices (and dismiss everything from the other side) or they will make radical switches out of desperation. Nothing is good about this and we should not foster more division, but instead look for ways to mitigate causes to encourage better cohesion and collaboration in the future.

(For the reference, I have never run anything other than Bitcoin Core as my node - yet).

[d5000]

As the debate continued and kind of turned into "drama" I got more and more the impression that the other side is just being slandered. In a "you're just stupid" or "you're paid/malicious" actor way. Excellent communication tactic isn't it? Insult the people that keep the network safe and secure for free because they have concerns/fears about changes.

I got the impression that the debate was peaceful until Peter Todd and Antoine Poinsot were accused of corruption because they cited examples like Citrea which could switch from the "fake public key" method (which is more harmful/costly to nodes!) to "OP_RETURN" with that change, but they were accused of getting paid by Citrea and others.

Devs are not communication professionals, and I can understand that if you're insulted that way, you will react accordingly and your posts will become a bit harsher.

Critics of the change who do understand the situation more in detail, like Luke-jr, should have intervened as they really should know better, I think, but they continued to fuel the drama, perhaps because they felt the "sentiment" was benefitting their position in the debate even with the "elementary school arguments" which came from random people on social media.

I think it was a clear concession and sign of goodwill to the node owners to keep the datacarriersize parameter in the code, even if this erased some of the advantages of the OP_RETURN limits changes (such as simpler/easier to maintain code, and less variance in the relay policies).

But anyway, I would also love such a blog like you proposed, with FAQs for every major proposed change. It's not clear to me if there's human resources for that. But perhaps this thread can serve as an inspiration? I think Core would definitely benefit.

However, my observations here on the social side of things is that people will flock to any alternative if they are pushed into a corner. This kind of communication issues are essentially pushing people into a democrats vs. republicans split, where users will either entrench themselves behind their choices (and dismiss everything from the other side) or they will make radical switches out of desperation. Nothing is good about this and we should not foster more division, but instead look for ways to mitigate causes to encourage better cohesion and collaboration in the future.

Agree here, but as I wrote above, the drama was fueled also by the opponents of the change, from quite early on. I know this drama isn't that new, it may have started already when OP_RETURN was introduced (2014?), but it's got much more heated since the Ordinals wave in 2023. That hasn't helped here, both sides already were a bit angered.

[Wind_FURY]

In the context of Bitcoin, if you do "censor" them through filters, what would that do? The filter boys will still get bypassed.

You're right, but I'm starting to think they're coming from a place of "everybody should do what we're doing." They want Core to become Knots, basically.

The potential problem with the "filter boys" is, their attempts might not stop with dick pics and fart sounds. Potentially, it's merely the beginning. Because if more and more people are convinced that filtering is "good", then there might be a sub-group of people within the filter boys who might start to convince everyone to filter financial transactions that they don't like.

 ¯\_(ツ)_/¯

[Satofan44]

The potential problem with the "filter boys" is, their attempts might stop with dick pics and fart sounds. Potentially, it's merely the beginning. Because if more and more people are convinced that filtering is "good", then there might be a sub-group of people within the filter boys who might start to convince everyone to filter financial transactions that they don't like.

No, that is a false equivalence and slippery slope fallacy. Just because I don't want Bitcoin to be a lite version of Ethereum, that does not mean that I would ever allow any censoring of financial transactions. Content moderation is very different from economic censorship.

I got the impression that the debate was peaceful until Peter Todd and Antoine Poinsot were accused of corruption because they cited examples like Citrea which could switch from the "fake public key" method (which is more harmful/costly to nodes!) to "OP_RETURN" with that change, but they were accused of getting paid by Citrea and others.

I am not sure when it took a turn for the worse, I saw this situation for the first time pretty late. I will take your word for it.

Devs are not communication professionals, and I can understand that if you're insulted that way, you will react accordingly and your posts will become a bit harsher.

Understandable but also not. They want people to have high opsec, to stay cautious, fight for decentralization, question things and people, stay vigilant but not when it is directed at them. This is also a sign of the situation "king in the high castle" forming. How can I as an outsider be sure that Todd is not compromised for example? Just because he's Peter Todd and because of his history here? If we resort to appeals to authority for defense, the battle is already lost. Instead, such vigilance and scrutiny should be welcomed by them. Some users will have malicious intent and that is to be expected, but we should not treat everyone else as if they had malicious motives too. The healthy attitude is to understand that at any point any Core developer including Mr. Luke-jr could get compromised or could already be compromised. For an average outsider it is hard to tell which is the case, and we should not treat outsiders with insults just because they are pointing fingers at our colleagues.

Critics of the change who do understand the situation more in detail, like Luke-jr, should have intervened as they really should know better, I think, but they continued to fuel the drama, perhaps because they felt the "sentiment" was benefitting their position in the debate even with the "elementary school arguments" which came from random people on social media.

I think Luke-jr has been a Core outsider for a long time now and thus his loyalty is limited if he has any left at all. Because of that people are likely to take advantage of this situation for their own motivations.

I think it was a clear concession and sign of goodwill to the node owners to keep the datacarriersize parameter in the code, even if this erased some of the advantages of the OP_RETURN limits changes (such as simpler/easier to maintain code, and less variance in the relay policies).

I agree that it is a sign of goodwill, but it was also communicated poorly. Instead of "we listened to your concerns, so we decided it is worth keeping this option so that node operators have more choice" I got more "fuck you for making us concede to keeping this option" vibe. Perhaps I am wrong and I missed some communication regarding this decision, I will happily accept being wrong in this case. However, if I have missed it so have other people too.

But anyway, I would also love such a blog like you proposed, with FAQs for every major proposed change. It's not clear to me if there's human resources for that. But perhaps this thread can serve as an inspiration? I think Core would definitely benefit.

The problem is that Bitcoin Core is essentially unapproachable for most people. I will give a personal example, and please avoid misunderstanding as I am not trying to scrutinize him but rather simply give an example. I have contacted gmaxwell to kingly give some input on a quantum BIP thread here on the forum should he have some time. I have neither received a reply via PM nor has there been a response to any such thread. How can any outsider volunteer for this? To make the situation more difficult, you can't just let anyone do this. At the very least it requires a passive blessing from Core and some active help via individual conversations with developers (otherwise the writer may get things wrong). This already indicates that the person likely needs an somewhat established reputation to even have a chance to do something like this, which reduces the number of potential people to a tiny minority.

To engage a wider amount of people posts could be done via Github PRs. This would severely limit the opportunity for malicious behavior and less reputable or even anonymous people without any reputation could contribute to the editing process. That said, this still needs some sort of blessing and involvement by Core in some way. Posted on the website of Bitcoin Core perhaps? I don't know, but what I do know is that without their involvement it goes nowhere. It would be akin to someone random starting a podcast talking about future changes that are coming to Bitcoin Core. Good, but how is this a communication by Bitcoin Core contributors?  



A post from Reddit today. This is not good. Even if all the nodes are fake, this can slowly and steadily trick people into running Knots for the wrong reasons.

Node runners just don't want to use Core 30 and relay spam and explicit ilegal underaged images. They want to strictly relay monetary data as intended since its inception, not bloat the network with useless garbage.
https://www.reddit.com/r/Bitcoin/comments/1nhhscu/comment/nec2bxo/

Communication has completely failed, the understanding that this is already possible is simply not there. Unless someone is strongly astroturfing that whole thread, the situation seems pretty bad.

[DaveF]

Dave's opinion.
Anyone running any code by Luke Jr. is pro censorship / anti crypto.
He has attacked and killed coins he does not like: https://bitcointalk.org/index.php?topic=56675.0

If a coin can be 51%'d then sooner or later someone would do it. That sends a message and proves BTC value, which we should protect.

Dave's opinion.
Anyone running code by Luke Jr. is risking their funds and computer security since he has proven he has poor OpSec:
https://bitcointalk.org/index.php?topic=5432665.0

If you read how it seems to have happened, and how long it took him to notice you would not ever trust him with software that you run.

No way you believe he was actually hacked. That was an obvious "boating incident" exit. In any case, the code is open source. If you are trusting Bitcoin Knots, you are trusting Bitcoin Core since a lot of it is forked, with interesting features added. Again, open source software, plus peer reviewed with gpg signatures of people putting their reputation on the line.

Not sure where you are in the world, but here in the US you can get an Optiplex 3050 Micro PC Core with a i7-6700T & 32GB of RAM for under $150 and a decent 2TB drive for under $125. Will sync a node from scratch in a minimal amount of time. As in fire it up in the office when you leave work Friday and it's done when you come in Monday morning. Picked the 6th gen 3050 since you can get on open source BIOS and disable IME very simply on that unit. You can get other machines that are newer / faster but takes more "know how" to put in an open source BIOS


-Dave

A lot of people depend on laptops and a lot of them are older hardware. If you had an old thinkpad laying around, you could turn it into a hardened node and if you had 2 you could have a good airgap device as well. Well the point is, most of this software is old, but it had no problem dealing with the initial block download, not anymore. Is dog coins in the bitcoin blockchain worth this result? exactly.

At this point the hardware I mentioned is 9+ years old and and can sync fine. If you are going to run your node on hardware older then that, then that's up to you. But if you want to push a 9+ year old laptop to do it it will. Not sure why, as I said you are paying a premium for the Optiplex 3050 you can get an i5-7200u laptop with 8GB ram and no drive for under $50 and an 1TB SSD for about the same. But you probably can't install an open source firmware on it the way you can the OptiPlex.

As for the hack or "boating incident" exit. That means he is either incompetent (as I think) or a criminal trying to get around tax law.
Either way not a good look for someone who is working on software that has peoples money running though it.

Yes, he is only making minor changes, but they are still changes and we don't know how well they were tested.

Either way, I'm not running it.

-Dave

[theymos]

I did some chain-searching, and I found that back in May somebody inserted a contiguous 961KB image into the block chain using OP_RETURN. If you have an unpruned Bitcoin Core (or Knots) node, you can retrieve the image (~SFW) using this command:

Code:

bitcoin-cli getrawtransaction b47eba144b4b9e9ee4e99f1db2081986f5ac59a7944780125e8c3360fec659c7 \
2 00000000000000000001475040e4cc63a0b580a81ccab1fe19e9f98b8bdb678a \
|grep '"asm"'| egrep -o 'ffd8ff[a-f0-9]{1000,}' |tail -n1 | xxd -r -p >out.jpg

The existence of this image should hopefully dispel the notion that 30.0 will allow something that isn't already allowed: here somebody did exactly the sort of thing that people are worried about, long before Bitcoin Core 30.0 is released. Even if 100% of non-miner nodes were running Knots, that wouldn't have stopped this person. Even if 99% of miners were running Knots, that wouldn't have stopped this person. You'd need 100% of miners or a softfork.

I don't entirely agree with the change in 30.0, but it's a small change which doesn't actually do that much. It's not that far off from removing code which says:
if transaction contains spammy data
    send the transaction-sender a strongly-worded letter telling them to knock it off
Yes, most of us don't like the spammy data, but neither Bitcoin Core <30 nor Knots prevents the spammy data. Actually preventing the spammy data would require a softfork, and to prevent it in a way which doesn't just push people to extremely-harmful obfuscation-as-keys would require an especially complicated softfork which nobody has designed yet.

[achow101]

A post from Reddit today. This is not good. Even if all the nodes are fake, this can slowly and steadily trick people into running Knots for the wrong reasons.

I suspect the reason it appears to be such a significant proportion is because Luke pulled in the change which makes NAT port forwarding (natpmp) on by default. This has been off by default on Core for quite a while since it was problematic, but will be on by default for v30. So the node numbers for knots are likely disproportionately high as new knots nodes are likely to be accepting inbounds and therefore show up on statistics like this one.

[Wind_FURY]

The potential problem with the "filter boys" is, their attempts might stop with dick pics and fart sounds. Potentially, it's merely the beginning. Because if more and more people are convinced that filtering is "good", then there might be a sub-group of people within the filter boys who might start to convince everyone to filter financial transactions that they don't like.

No, that is a false equivalence and slippery slope fallacy. Just because I don't want Bitcoin to be a lite version of Ethereum, that does not mean that I would ever allow any censoring of financial transactions.

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.

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.

 

[mrust_mobile]

Take a look on the bright side, if bitcoin fails as a p2p payment system we can rebrand it into p2p decentralized image hosting service.

Bitimage - Peer to peer image hosting service

Decentralized, no government can take it down. Unstoppable pron pics.

Yummy.

[Satofan44]

Yes, most of us don't like the spammy data, but neither Bitcoin Core <30 nor Knots prevents the spammy data. Actually preventing the spammy data would require a softfork, and to prevent it in a way which doesn't just push people to extremely-harmful obfuscation-as-keys would require an especially complicated softfork which nobody has designed yet.

The consensus is to just give up? I am still not happy about how the ordinals thing was treated. The hole that made it possible should have been closed as soon as it was discovered, no debate was needed.

I suspect the reason it appears to be such a significant proportion is because Luke pulled in the change which makes NAT port forwarding (natpmp) on by default. This has been off by default on Core for quite a while since it was problematic, but will be on by default for v30. So the node numbers for knots are likely disproportionately high as new knots nodes are likely to be accepting inbounds and therefore show up on statistics like this one.

Thanks for this information, I was not aware of it. It will be interesting to see how the numbers change with the new Core version, perhaps they will change a bit more slowly as some people will refuse to make this update. No thoughts on the sub discussion within this topic regarding communication issues or potential improvements for the future?

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.

[DaveF]

...

I suspect the reason it appears to be such a significant proportion is because Luke pulled in the change which makes NAT port forwarding (natpmp) on by default. This has been off by default on Core for quite a while since it was problematic, but will be on by default for v30. So the node numbers for knots are likely disproportionately high as new knots nodes are likely to be accepting inbounds and therefore show up on statistics like this one.

Thanks for this information, I was not aware of it. It will be interesting to see how the numbers change with the new Core version, perhaps they will change a bit more slowly as some people will refuse to make this update. No thoughts on the sub discussion within this topic regarding communication issues or potential improvements for the future?
...

I would open up an new topic about it.
It's not that big a deal IMO but some people may be caught unaware if they have not been following the discussions.

Which does beg the question, how many people actually read the release notes and comments? How many times have things like this happened, and then you have to go and point out that it was in the readme file.

-Dave

[scottmsul]

I think people on the Knots side have a technical framing of the debate that I feel needs to be pushed back on. There's a misunderstanding that the sole purpose of relaying transactions is to help them get mined, and therefore relaying is done only to help the sender. Under this framing, it's obvious why people would run knots - why would anyone want their node to be a free resource for helping those dirty spammers?

While this framing isn't entirely untrue, it doesn't give a complete picture. People underestimate how easily information spreads. When someone sends a "spam" transaction with a competitive fee rate, at this point in Bitcoin's maturity, it will find its way to a miner with 100% certainty. Whether your node sees it or relays it is irrelevant. The only question is: do you want to be aware of this upcoming transaction?

I think a more accurate framing is that storing spam in your node is good for you, the node runner, as it gives you a more complete picture of the network. You know more about the upcoming transactions, you get a more precise fee rate, you validate blocks more quickly, etc.

But even if you should want your node to know about spam, why would you still bother to relay it?

Here's why - because it's not about helping the sender, but rather helping the other node runners. By relaying "spam" you're helping the other node runners by giving them a more complete picture of the network too!

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?

[ertil]

The consensus is to just give up?

Exactly. If you run the official software, then it is not going to stop any spam. Even if you run Knots, then their client will still send old blocks with JPEGs.

I am still not happy about how the ordinals thing was treated.

Then, enable pruning of the UTXO set. If some P2P node will ask you about transaction 0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae, then your node can reply "I don't have it, sorry". You don't have to store that data, if you don't want to. And then, it is all about providing a proof, that the blockchain is correct, without revealing the content of such transactions (which technically can be done by ZK proofs, or other ways).

The hole that made it possible should have been closed as soon as it was discovered, no debate was needed.

But you know, that "closing the hole" would require reorging the chain, and removing that transaction from it? If SHA-256 will be broken, then we could start a new chain in a way, where old nodes would see the same UTXOs as today, but where the history behind it would be fully pruned. But we are not yet there. Now, you can only block it on your own side, and convince others to do the same.

Yes, data storage and financial transactions are entirely different.

Also because when it comes to the financial transactions, they can be pruned. And then, if Alice owns 1 BTC, it does not matter, what Bob owned before, or if Charlie was there, as long as each history pruning is covered by hashrate majority (which then means, that changing it would require more power, than producing a new 1 BTC from scratch).

[Satofan44]

The consensus is to just give up?

Exactly. If you run the official software, then it is not going to stop any spam. Even if you run Knots, then their client will still send old blocks with JPEGs.

That does not seem like a healthy way to approach existing problems and neither does it sound like Core is listening to anybody but itself.

The hole that made it possible should have been closed as soon as it was discovered, no debate was needed.

But you know, that "closing the hole" would require reorging the chain, and removing that transaction from it? If SHA-256 will be broken, then we could start a new chain in a way, where old nodes would see the same UTXOs as today, but where the history behind it would be fully pruned. But we are not yet there. Now, you can only block it on your own side, and convince others to do the same.

Why would you need to reorg it? Just close it moving forward, or are you saying that there is no way of closing the hole without destroying the existing UTXOs that used it?

Yes, data storage and financial transactions are entirely different.

Also because when it comes to the financial transactions, they can be pruned. And then, if Alice owns 1 BTC, it does not matter, what Bob owned before, or if Charlie was there, as long as each history pruning is covered by hashrate majority (which then means, that changing it would require more power, than producing a new 1 BTC from scratch).

Please don't encourage these ideas, it will quickly sound like one of those we've "solved" decentralization and have 1 million TPS altcoins.  

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?

[ertil]

Why would you need to reorg it?

Because this is the only way, to "delete" something "permanently" from the blockchain. If you have CRUD model, where things are Created, Read, Updated, and Deleted, then block reorg is the only "delete" operation.

Just close it moving forward

You need a soft-fork, to "close it moving forward", because all coinbase transactions are "non-standard" (because users cannot send them directly, they are present in the blocks, and handled only implicitly by the protocol).

or are you saying that there is no way of closing the hole without destroying the existing UTXOs that used it?

As long as you won't make it invalid, by creating a soft-fork, you will need to synchronize data from blocks, mined by those, who will ignore your relay rules.

Please don't encourage these ideas

Why not? This is where censorship leads. If you don't want to remove anything from the history, then you will have to process more and more data, no matter if blocks will be filled with financial transactions or not. If we would have a constant stream of 4 MB financial-only transactions, with just public keys and signatures, and absolutely nothing else, then there would be nothing to filter, and the problem would still be there. Because data can be transmitted inside private keys. One public key, and one signature, will then allow you to share 64 bytes in a safe way, if you just XOR it by chunks, taken out of any deterministic wallet. Then, data will still be transmitted, and you will have just around 96 bytes of data, to express 64 bytes of payload, so after bypassing all filters, this encoding will use every 3 MB block, to share 2 MB of data, and nobody would know, if there are real transactions, or just cloud storage.

The only way to solve that problem, is to improve Initial Blockchain Download. Otherwise, you can still have 3 MB blocks, used to store 2 MB of any data, and they could bypass any filters, because they would use real, spendable public keys, and real, valid signatures.

we've "solved" decentralization and have 1 million TPS altcoins

We don't need any "1 million TPS altcoins", because Bitcoin itself can enforce Proof of Work inside scripts, which means, that "1 million TPS sidechain" is possible here and now.

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.

Let's say, that you have a password "Satofan44", and you want to push any 64 byte data chunk to the blockchain. Here is how you can do that:

Code:

SHA-256("Satofan44")=db8b315ef5e4d2c336dfb7993e2f9bd00dfba02a0943796674e5115cb67b28c6
counter=0000000000000000000000000000000000000000000000000000000000000000
counter2=0000000000000000000000000000000000000000000000000000000000000001
key=SHA-256(db8b315ef5e4d2c336dfb7993e2f9bd00dfba02a0943796674e5115cb67b28c60000000000000000000000000000000000000000000000000000000000000000)=f579b035c06d6246542f1036bf42e6d8e1abe41c3d1148c762fc6e644d1fa785
key2=SHA-256(db8b315ef5e4d2c336dfb7993e2f9bd00dfba02a0943796674e5115cb67b28c60000000000000000000000000000000000000000000000000000000000000001)=174c00a2669ccf159b55be16a57d526eb9f663d91dba4cdcd2a885326d1b8d5e
data=badc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0dedbadc0ded
data2=da7aba5eda7aba5eda7aba5eda7aba5eda7aba5eda7aba5eda7aba5eda7aba5e
xored=data^key
xored2=data2^key2
d=xored=4fa5bdd87ab16fabeef31ddb059eeb355b77e9f187cd452ad8206389f7c3aa68
k=xored2=cd36bafcbce6754b412f04487f07e830638cd987c7c0f68208d23f6cb7613700
Q=d*G=03D0DAA7FDB3608399ACC59DB895F57292646DA37E3286421067E5A0F4B315C6E9
R=k*G=028A64ED6033F07D74A77900DA4EA2FECEC402119C08F3B8EF813D82E69918D0F5

Then, you send a transaction, where your public key is set to 03D0DAA7FDB3608399ACC59DB895F57292646DA37E3286421067E5A0F4B315C6E9, and your R-value is set to 028A64ED6033F07D74A77900DA4EA2FECEC402119C08F3B8EF813D82E69918D0F5. How do you want to make a filter, which would stop it, without stopping other financial transactions?

Do we need to do an USAF-style but purely signalling fork to demonstrate this to be true?

Good luck. Even if you activate it, then 3 MB blocks could still store 2 MB of data. What then? It would only make the situation worse, because spammers could share keys like db8b315ef5e4d2c336dfb7993e2f9bd00dfba02a0943796674e5115cb67b28c6 between themselves, and then they will process 2 MB blocks, while the rest of the nodes will process 3 MB blocks.

[Satofan44]

Why would you need to reorg it?

Because this is the only way, to "delete" something "permanently" from the blockchain. If you have CRUD model, where things are Created, Read, Updated, and Deleted, then block reorg is the only "delete" operation.

You need a soft-fork, to "close it moving forward", because all coinbase transactions are "non-standard" (because users cannot send them directly, they are present in the blocks, and handled only implicitly by the protocol).

Then you misunderstood my intentions. There is nothing that needs to be deleted from the post. The hole must be closed for the future transactions, preventing more Ordinals and similar derivatives. What happened in the past is no longer relevant.

Please don't encourage these ideas

Why not? This is where censorship leads. If you don't want to remove anything from the history, then you will have to process more and more data, no matter if blocks will be filled with financial transactions or not. If we would have a constant stream of 4 MB financial-only transactions, with just public keys and signatures, and absolutely nothing else, then there would be nothing to filter, and the problem would still be there. Because data can be transmitted inside private keys. One public key, and one signature, will then allow you to share 64 bytes in a safe way, if you just XOR it by chunks, taken out of any deterministic wallet. Then, data will still be transmitted, and you will have just around 96 bytes of data, to express 64 bytes of payload, so after bypassing all filters, this encoding will use every 3 MB block, to share 2 MB of data, and nobody would know, if there are real transactions, or just cloud storage.

The only way to solve that problem, is to improve Initial Blockchain Download. Otherwise, you can still have 3 MB blocks, used to store 2 MB of any data, and they could bypass any filters, because they would use real, spendable public keys, and real, valid signatures.

Are you a developer or an engineer? This is the same kind of flawed thinking that comes up commonly by this type of people, a very deep flaw in an usually very useful brain. If you can't solve every and all instances of something, then don't try to solve or improve it at all. Imagine if we applied that thinking to natural disasters like floods.  

The case against stopping some data storage techniques and methods because we can't stop all of them is very weak. A non argument really. Do you have any other arguments against it? It is clear that a large block of Bitcoiners wants this and by trying to suppress their desire for solutions to the problem things can only become worse. That is all that must be understood. Now be a good boy and invest that beautiful brain into finding workable solutions instead.

Imagine a future scenario. A large block of nodes is now using alternative Bitcoin implementations because of the continued lack of listening to the users and node operators. These implementations could be subpar in terms of quality compared to Bitcoin Core and later lead to a large fork or even hacks through security exploits. At least temporary massive financial damage and damage to Bitcoin's reputation. Why? All because the leading developers couldn't get off of their high horse, spend some time down on Earth and listen to the users for a change? That there is even a tiny chance of this happening already indicates that the current power balance has denigrated and requires a fix.

Who are Bitcoin Core developers supposed to be working for anyways? Themselves, the Bitcoin users or the paycheck sponsors?

[ertil]

Are you a developer or an engineer?

I don't know, because some people call me "Software Engineer", while others call me "Software Developer". I would say just "programmer", because it doesn't matter that much.

If you can't solve every and all instances of something, then don't try to solve or improve it at all.

You can try to solve some instances of the problem. But if you don't solve it entirely, then the end result will be just worse. People will bypass your filters, and then, you will no longer know, how much spam is there. In the current situation, you can easily detect the spam, and say: "ok, here is some spam, I can ignore it in my node". If you put next filters on top of the current network, and if your model will be enforced by the hashrate majority, then people will still put data in the blockchain, but they will just use worse ways, where the actual signature verification process is triggered, and where you have real OP_CHECKSIGs or their equivalent to process.

All scripts under P2WSH could use: "<pubkeyData32_chunk> OP_CHECKSIGVERIFY <pubkeyData32_chunk2> OP_CHECKSIGVERIFY ... <pubkeyData32_chunkN> OP_CHECKSIG". What then? Would a block, filled entirely with huge fake multisigs like that would be better or worse, than the current block content? What is easier to filter? 1 MB of OP_RETURN, 4 MB of witness data, or this "OP_CHECKSIGVERIFY OP_CHECKSIGVERIFY ... OP_CHECKSIG" multisig monster, consuming a single sigop per OP_CHECKSIG?

So, I would say primum non nocere. If you cannot make the situation better, then at least don't make it worse, than it currently is. Filtering existing spam is easy. Forcing users to switch to worse models is a bad idea. And if filters will work, then there will be incentive to play this cat-and-mouse game, and make it much more serious, than it currently is.

Do you have any other arguments against it?

Yes. You don't have to enforce filters on all users, to make them effective. You can just make "payment-only" network, on top of the current consensus, and just process a subset of the mainnet traffic. There is no need to download all blocks and transactions. Filters will work, when new nodes won't have to process spammy transactions during Initial Blockchain Download. If you block things only on relay level, then it is just a short-term fix. Later, spammers will push you the same data through Slipstream, so if MARA will have for example 1% hashrate, then you will have a spammy block every 100 blocks on average.

And then, by improving Initial Blockchain Download, you can discourage users from storing any kind of data in the blockchain, in any way. Then, users will have to keep storing their transactions locally, if they will want to spend them. As long as you download, and process the whole blockchain, and you serve all blocks to all users, willing to synchronize their nodes from scratch, the problem will remain unsolved.

So, why do you want to apply "relay fix", where "IBD fix" can be done, and really improve the situation? Why do you want to apply "1% fix", if you can apply "10% fix"? And that "1% fix", if it will be popular, will put you in a future, where only "20% fix" will help, because "10% fix" will no longer be effective, if people will start to seriously abuse the protocol. The only barrier, which is stopping us now, is that people don't have the knowledge and skills, to really abuse the rules. But if you encourage them to do so, then they will get there sooner, than they should, so that better ideas would no longer work as well, as they could today.

Now be a good boy and invest that beautiful brain into finding workable solutions instead.

Workable solution is to make IBD really fast, no matter what kind of data is stored on-chain. Workable solution is where every user has to prove, that the UTXO exists, before spending it. And workable solution is where nodes can process, what they want, and where unused coins are never processed by anyone, as long as some user won't push a proof, which would make them alive again (and pay the cost of revealing that proof).

Introducing filters is not a "workable solution". It is just delaying the inevitable spam, that will hit us later, with a stronger force, than it would, if it would be addressed correctly.

Why? All because the leading developers couldn't get off of their high horse, spend some time down on Earth and listen to the users for a change?

In the future, developers won't listen to the users, because they will be responsible for absolutely nothing. We no longer live in times, where Core could introduce filters, and they would be enforced by every node. We live in times, where everyone can abuse the chain in a lot of ways, and the only stopping thing is the difficulty of writing some working implementation. Many holes are not exploited today, only because people don't read the code. But if they would start reading, what the consensus really allows, instead of using silly OP_RETURNs, or storing data inside witness, then we would have much bigger problems.

So please, don't encourage spammers to read things more carefully. The current level of spam is easier to filter, than things, which spammers would switch to, if they would discover them. So, don't make them easier to discover, at least for now. And don't break simple "OP_FALSE OP_IF ... OP_ENDIF" filters (and ZK-proofs, that could be built on top of them), which could work great today, but won't work, if you soft-fork into a chain, where it would be forbidden.

Who are Bitcoin Core developers supposed to be working for anyways?

Nobody. They are still here, just because they can. But many of them can leave the project, and let it collapse, be endlessly spammed, and allow all kind of crappy solutions, that are not yet there, but could be introduced.

Themselves, the Bitcoin users or the paycheck sponsors?

It doesn't matter, because when all limits will be lifted, then they will be responsible for absolutely nothing, and every change could be pushed on-chain. And then, better have the client prepared, which would process a subset of the Bitcoin traffic, because otherwise, you will flood in the upcoming spam. And then, your filters won't save you from being spammed, when people would flood the network with six blocks per second (because nothing stops the hashrate majority from doing so; and you don't want to encourage hashrate majority to support the spammers more, than they are currently willing to).

[Satofan44]

So, I would say primum non nocere. If you cannot make the situation better, then at least don't make it worse, than it currently is. Filtering existing spam is easy. Forcing users to switch to worse models is a bad idea. And if filters will work, then there will be incentive to play this cat-and-mouse game, and make it much more serious, than it currently is.

Taproot made everything worse. Instead of admitting the error and correcting it, the debate is being run into any possible direction except admission of wrongdoing. Ordinals should never have been a thing, the refusal to patch the exploit was a telltale sign of mistakes to come.

Yes. You don't have to enforce filters on all users, to make them effective. You can just make "payment-only" network, on top of the current consensus, and just process a subset of the mainnet traffic. There is no need to download all blocks and transactions.

Sounds good, except that most users don't want this. It sounds like one of those circlejerk ideas where developers pat each other on the back for solutions that nobody wants. Decentralized and widely used sidechain any day now, probably a bit after I get my 5 year away fusion reactor.  

Themselves, the Bitcoin users or the paycheck sponsors?

It doesn't matter, because when all limits will be lifted, then they will be responsible for absolutely nothing, and every change could be pushed on-chain. And then, better have the client prepared, which would process a subset of the Bitcoin traffic, because otherwise, you will flood in the upcoming spam. And then, your filters won't save you from being spammed, when people would flood the network with six blocks per second (because nothing stops the hashrate majority from doing so; and you don't want to encourage hashrate majority to support the spammers more, than they are currently willing to).

That is a terrible idea and will definitely lead to a massive move away from Core and make it irrelevant. I hope that the most influential individuals over there do not share this view. Pursuing technological idealism to destroy social coherence. Genius. Most users do not want what you have described in your well written post! We had a good thing going, but the lack of social education seems to worsen the situation.

The situation with Knotz is just a precursor of what is to come. 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.
You still don't get it. People do not want this. Technological arguments against imperfect filters will not change their minds. This is where the lack of social education comes into play and instead of addressing the issues developers tend to waste time on excuses why not to address them. Most operators would welcome an imperfect solution. I'd bet on it. I think I have repeated this enough times. Either you understand it or you don't, enough time has been spent on it. You shall see. 

[ertil]

Taproot made everything worse.

Wait until you see, how the same things, which are done from Taproot now, can be repeated on P2WSH. Spammers will consume a couple of bytes more, but the end result will be pretty much the same. The only thing which stops them, is their lack of skills.

Instead of admitting the error and correcting it, the debate is being run into any possible direction except admission of wrongdoing.

Because that was the goal: to make future soft-forks possible, without going through the regular procedure. To activate new things with OP_SUCCESS, without any kind of "miner signalling" or "miner voting", or "activated by BIP-N". We no longer need it, that goal was achieved. Next soft-forks will be no-forks. It is a natural way of starting from hard-forks, switching to soft-forks as a better replacement, and then going further into no-forks, as an even better replacement.

Ordinals should never have been a thing

They can be launched on P2WSH as well. Does it mean, that Segwit was also a mistake? Ordinals could be introduced on top of pure P2PK, without any Script. Only skills stop the spammers, from using them in that way, as I already demonstrated you, why it is the case. Spammers didn't succeed, when they tried to bring Ordinals to Grin, but it is possible. Their knowledge and skills is their limitation.

the refusal to patch the exploit was a telltale sign of mistakes to come

It was just a natural consequence of lifting next limits. And there are even more limits to be lifted in the future. Nobody will like it, but it will happen anyway. Because the end goal is to not improve the situation, but to make it worse. To no longer be responsible for anything. To activate and deactivate things on-the-fly. This is what developers want, and that goal is in progress, step-by-step.

Sounds good, except that most users don't want this.

They will not have any better choice, if next mainnet limits will be lifted. And there is no sign of stopping to lift limits. Each new soft-fork lifts more limits, than it introduces, so it is inevitable, that the mainnet will be spammed, by activating features, that nobody wants to use.

That is a terrible idea and will definitely lead to a massive move away from Core and make it irrelevant.

This is inevitable, and they know about it. 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". Now, some people use Core, some people use other clients like Knots. Statistics can be fake of course, but there is definitely more than one implementation, which is widely used. In the future, I don't think Core will be used by more than 50% of users, maybe even it won't be used by the majority of the users.

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.

If you look at BTC dominance, it sometimes was below 50%. I guess future Core usage will start bouncing as well, and people may even think, that most of the users still use Core, where it wouldn't be true. People can make modifications, without changing the User Agent, if being detected as a "non-Core user" will be a sin. Without Proof of Work, any User Agent strings are worthless, and can be easily faked by anyone, who knows, how to make a similar change for a web browser.

Most users do not want what you have described in your well written post!

They may dislike it, but they are definitely not prepared for such scenarios. I also don't like the future, where Bitcoin is always wrapped in KYC/AML, but this is what is going to happen, at least in Europe, because nobody stopped it, and nobody plans to. And I don't like the future, where mainnet is bouncing between being mainnet, and regtest, but it can also happen.

So, just prepare for the worst, because "skill barrier" is the only barrier we now have.

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.