Nick Szabo weighs in, recommends Knots over Core v30

[mindrust]

https://x.com/NickSzabo4/status/1980891636197740733

Interesting developments. Just when we thought Luke became a train wreck after J-Lopp wiped the floors with him, he receives help from one of the OG's of bitcoin. (some still believe Nick Szabo is Satoshi Nakamoto btw.)

I thought running Knots wasn't going to make a difference. What's with this NS guy? Don't he know that?

a- it makes a difference and that's why he recommends it
b- ns is full of shit and he doesn't know crap about this

Place your bets.

[BlackHatCoiner]

I miss the days when bitcoiners were all about anarchy and resisting government intervention with free software. We used to write code to evade government. Now our concern is how hostile governments will be with Core 30.

Someone with a background in the law, please explain to me what difference does it make whether the material you propagate is continuous, or split in different chunks? Because that's the core of the issue, as far as I can tell. Arbitrary data could already be included in a host variety of ways, and in fact it already is cheaper to do in chunks than in OP_RETURN, as you get segwit discount.

[alani123]

What had caused Nick Szabo to abandon BTC in the first place? I don't recall.

I found a New Yorker article saying back in 2015 he opposed bitcoin XT's block size expansion. This was a favourite proposed solution back then.
https://www.newyorker.com/business/currency/inside-the-fight-over-bitcoins-future

[Cricktor]

I don't care if this is the "real" Nick Szabo or just someone who managed to get the worth-a-shit "verified" indicator at some (a)social media platform. Anyway, that's not the main topic here.

No idea why this Nick shills Knots. Knots may refuse to accept and/or relay transactions that don't fit in its view of Bitcoin purity, but Knots still has to accept valid blocks and those can still contain stuff that Knots otherwise won't let into its mempool.

I get the argument when there were a whole lot more Knots nodes, that undesired content might have a hard time to reach miner's mempools. But frankly does anybody want to have a large majority of nodes to be run by Knots, a node software maintained basically by one dude who is in one way or another quite "special" (I could use other words, but lets play nice.)

Sorry... I pass! Doesn't make sense to me to promote Knots as the Bitcoin savior. Laughable!

[Ambatman]

I thought running Knots wasn't going to make a difference. What's with this NS guy? Don't he know that?

a- it makes a difference and that's why he recommends it
b- ns is full of shit and he doesn't know crap about this

Place your bets.

It makes a difference in limiting spam that comes as a result of OP Return and some level of fake Pubkeys.
If it's not relayed by nodes it wouldn't be seen by miners except they are presented to the miner directly.
But the issue is spammers adapt.They can use fake Pubkeys in Taproot output by taking advantage of the flexibility of taproot.


In the end wouldn't change anything once a miner choose to add it to a block
They would be validated and stored as it doesn't go against the consensus rule.

[Satofan44]

You mean Nick Szabo, the Ethereum advisor? Why should anyone listen to him? It is time to stop the appealing to authority figures. The shitcoin that he supports has even fewer limits and even more CSAM data in it. He has no point here.

a- it makes a difference and that's why he recommends it
b- ns is full of shit and he doesn't know crap about this

Reread the threads on OP_RETURN, starting with this one https://bitcointalk.org/index.php?topic=5559215 and then this one https://bitcointalk.org/index.php?topic=5562256.0. It makes zero difference if you run Knots or not.

If it's not relayed by nodes it wouldn't be seen by miners except they are presented to the miner directly.
But the issue is spammers adapt.They can use fake Pubkeys in Taproot output by taking advantage of the flexibility of taproot.

The relay of transactions is not an argument at all, the other side is just retarded. Miners already offer public tools where you can directly submit these transactions and there are private channels for submission too. If I can do this, a motivated attacker can do it as well.

Someone with a background in the law, please explain to me what difference does it make whether the material you propagate is continuous, or split in different chunks? Because that's the core of the issue, as far as I can tell. Arbitrary data could already be included in a host variety of ways, and in fact it already is cheaper to do in chunks than in OP_RETURN, as you get segwit discount.

This would be a very dumb argument. The data is not stored in a way that is readable by default, or easily readable. So whether it is continuous or in chunks, you have to really want to read it in the right way to be able to see it. It is not like I can just open my blocks folder and the CSAM data and malware is staring me in the face. However, they sure like to exaggerate like this is the case.

Furthermore, chunks vs continuous is a pretty stupid argument. The implication from this is that all a pedophile needs to do is split his content locally into chunks and the issue stops right then and there? No more arrests then, they found a solution.

I miss the days when bitcoiners were all about anarchy and resisting government intervention with free software. We used to write code to evade government. Now our concern is how hostile governments will be with Core 30.

When every idiot and his grandma has an opinion on the physics of a quantum computer this is what you get. This is also a case example of why decentralized governance is a very bad style of governing. Luckily in the case of Bitcoin the governance style is pretty vague and as such it is very difficult to subvert.

[alani123]

I don't care if this is the "real" Nick Szabo or just someone who managed to get the worth-a-shit "verified" indicator at some (a)social media platform. Anyway, that's not the main topic here.

No idea why this Nick shills Knots. Knots may refuse to accept and/or relay transactions that don't fit in its view of Bitcoin purity, but Knots still has to accept valid blocks and those can still contain stuff that Knots otherwise won't let into its mempool.

I get the argument when there were a whole lot more Knots nodes, that undesired content might have a hard time to reach miner's mempools. But frankly does anybody want to have a large majority of nodes to be run by Knots, a node software maintained basically by one dude who is in one way or another quite "special" (I could use other words, but lets play nice.)

Sorry... I pass! Doesn't make sense to me to promote Knots as the Bitcoin savior. Laughable!

Running a different kind of node other than Core is just symbolic.
In 2015 there were several types of non-core nodes spun up, with many even supporting a hard-fork enabled block-size increase. Of course miners kept mining based on rules they knew the majority of other MINERS would accept.

If you're running a non mining node, your politics don't really have an impact. Hell even rules set out by developers don't really matter. Because if miners chose to ignore a certain Core rule it means the users will just have to accept it. And what if you run a node that outright refuses to accept blocks with inscriptions and "arbitrary data" when miners are ok to put these in blocks and accept to build on such blocks? You'll be alone. These days miners have their own permission network of nodes anyway. They don't really care to peer with you for better propagation because big pools network with each other and even run "boosters" for transactions they'll be paid to put in their blocks.

That's why Luke created OCEAN, a pool where the proposed rules for mining blocks exclude inscriptions, ordinals and anything he perceives as arbitrary data.
If you want to disobey bitcoin Core rules, you don't just need to showcase your power in nodes, you need to show you're capable of changing things in terms of hashrate.

[stwenhao]

What's with this NS guy?

Nothing Special, nothing new. It is just his opinion. So, as usual, you don't have to follow his recommendations, when it comes to the client you should run. But also, as usual, people like that often raise some valid points, and even if you decide, that you should run Core, then you should look at his arguments in the way they are.

Running a node where one cannot selectively delete unacceptable content without wider functional disruption

There are two issues here: first, running Knots does not allow you to remove more block or transaction data, than Core, without causing the same disruption (try to do Initial Blockchain Download from another Knots node, that is pruned). And second: there are pruned Core nodes, that "selectively delete unacceptable content", by discarding everything below 288 last blocks, and not relaying that to the network at all.

Nodes on blockchains that (...) discourage arbitrary content, are far less risky to run than nodes on blockchains that encourage arbitrary content.

Again, at least two problems here: first, that Knots does not "discourage arbitrary content". It would do so, if it would be hard, or impossible, to download past transactions with JPEGs in plaintext. As long as they are needed for IBD, Knots is not better here than Core. And second, that OP_RETURN is way better, than doing for example 1-of-460 multisig, which is non-standard, but which would be accepted by all Knots nodes, if some mining pool would decide to include it: https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/nRDyiy6LAAAJ

a- it makes a difference and that's why he recommends it
b- ns is full of shit and he doesn't know crap about this

Rather "b" than "a", but there are some points worth considering. For example "pruning". And "doing IBD, without having all transactions in plaintext". As long as IBD in Knots requires getting all spammy transactions, their filters have no effect. If they don't understand it, then it is their problem.

what difference does it make whether the material you propagate is continuous, or split in different chunks?

There is no difference, because you can make it continuous, by just spending coins from bc1sw50qgdz25j, and start making continuous 4 MB data pushes. What then?

Because that's the core of the issue, as far as I can tell.

It is not, because of the above. Check it on regtest, if you are not convinced, that making continuous data pushes is consensus-valid, which means, that even if it is non-standard now, some mining pools may start accepting it at any moment. And then, the block size limit is the only limit, that will block the chunks from being bigger than 4 MB.

Arbitrary data could already be included in a host variety of ways, and in fact it already is cheaper to do in chunks than in OP_RETURN, as you get segwit discount.

The method above is the cheapest, because you have a Segwit discount, and you have a single chunk. It is only a matter of time, as some spammy mining pools will get there.

[BlackHatCoiner]

a- it makes a difference and that's why he recommends it
b- ns is full of shit and he doesn't know crap about this

Rather "b" than "a"

I always liked Nick Szabo. He seemed so on-point and full of wisdom on most of the text I've read from him. It's hard to believe that he's been bribed to promote Knots. He does not and did not ever have a business with Luke, if I recall right.

It is not, because of the above.

I mean it is the core of the issue, from the perspective of the law. I think Szabo's position is that nodes do not carry the same legal responsibility if they're actively supporting the propagation of such material by running software that openly accepts it. However, pre-30 nodes also "support" that propagation, as they will accept valid blocks with the material. Therefore, I'm really not sure what the point in his statement is. Somehow that software legality is a "spectrum"?

bc1sw50qgdz25j

How can you spend coins from this address?

[stwenhao]

How can you spend coins from this address?

They are unconditionally valid. Coins from future Segwit versions are spendable now. Future soft-forks can say for example: "only coins meeting these conditions can be spent". So, today, you can just spend them like bc1pfeessrawgf. However, if you include any witness stack push, then it will also be valid. It may be non-standard, but valid.

And also, that's why every soft-fork has some "confiscatory surface", because maybe, someone, somewhere, used addresses like that, for some unknown purpose. However, this is why standardness rules are there: to assume, that users made only standard transactions, and to allow for the future soft-forks to invalidate "unconditional coin spends" into "you need to satisfy these rules" spends. Then, old nodes assume these coins are valid, and new nodes enforce new restrictions on top of that.

I wonder, if I should include some regtest example, or if you want to take your time, and figure it out.

Edit: Spammers will get there soon anyway, so let's go:

Code:

decodescript 51024e73
{
  "asm": "1 29518",
  "desc": "addr(bcrt1pfeesnyr2tx)#swxgse0y",
  "address": "bcrt1pfeesnyr2tx",
  "type": "anchor"
}
generatetoaddress 101 bcrt1pfeesnyr2tx
getblockhash 1
64eb7b553c2c9a90da481dff88921bbb984af6cb65dc97e73c46ab888beaf062
getblock 64eb7b553c2c9a90da481dff88921bbb984af6cb65dc97e73c46ab888beaf062 0
0000002006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f1468870ca9ffacda7d96cc69cafdc7caa0516a91e9dfabd8ca382587d7fc1c7a7648fd68ffff7f200000000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff025100ffffffff0200f2052a010000000451024e730000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
decoderawtransaction 020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff025100ffffffff0200f2052a010000000451024e730000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
{
  "txid": "7a1cfcd7872538cad8abdfe9916a51a0cac7fdca69cc967ddaacffa90c876814",
  "hash": "bba85f0720f61c93f494a14f0de6cfb45005674ba3c5bbdca28763964e438b4f",
  "version": 2,
  "size": 149,
  "vsize": 122,
  "weight": 488,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "5100",
      "txinwitness": [
        "0000000000000000000000000000000000000000000000000000000000000000"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 50.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "1 29518",
        "desc": "addr(bcrt1pfeesnyr2tx)#swxgse0y",
        "hex": "51024e73",
        "address": "bcrt1pfeesnyr2tx",
        "type": "anchor"
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
        "desc": "raw(6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9)#cav96mf3",
        "hex": "6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
        "type": "nulldata"
      }
    }
  ]
}
decodescript 6002751e
{
  "asm": "16 7797",
  "desc": "addr(bcrt1sw50qt2uwha)#vsrunpvu",
  "address": "bcrt1sw50qt2uwha",
  "type": "witness_unknown"
}
createrawtransaction '[{"txid":"7a1cfcd7872538cad8abdfe9916a51a0cac7fdca69cc967ddaacffa90c876814","vout":0}]' '[{"bcrt1sw50qt2uwha":0.00001922},{"bcrt1pfeesnyr2tx":49.99998000}]' 0 true
02000000011468870ca9ffacda7d96cc69cafdc7caa0516a91e9dfabd8ca382587d7fc1c7a0000000000fdffffff028207000000000000046002751e7eea052a010000000451024e7300000000
sendrawtransaction 02000000011468870ca9ffacda7d96cc69cafdc7caa0516a91e9dfabd8ca382587d7fc1c7a0000000000fdffffff028207000000000000046002751e30ea052a010000000451024e7300000000
ee5baa4fbb01ef4fb207426d9e36b879262037d177742aa17e229b6b9468e1e6
decoderawtransaction 02000000011468870ca9ffacda7d96cc69cafdc7caa0516a91e9dfabd8ca382587d7fc1c7a0000000000fdffffff028207000000000000046002751e30ea052a010000000451024e7300000000
{
  "txid": "ee5baa4fbb01ef4fb207426d9e36b879262037d177742aa17e229b6b9468e1e6",
  "hash": "ee5baa4fbb01ef4fb207426d9e36b879262037d177742aa17e229b6b9468e1e6",
  "version": 2,
  "size": 77,
  "vsize": 77,
  "weight": 308,
  "locktime": 0,
  "vin": [
    {
      "txid": "7a1cfcd7872538cad8abdfe9916a51a0cac7fdca69cc967ddaacffa90c876814",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 0.00001922,
      "n": 0,
      "scriptPubKey": {
        "asm": "16 7797",
        "desc": "addr(bcrt1sw50qt2uwha)#vsrunpvu",
        "hex": "6002751e",
        "address": "bcrt1sw50qt2uwha",
        "type": "witness_unknown"
      }
    },
    {
      "value": 49.99998000,
      "n": 1,
      "scriptPubKey": {
        "asm": "1 29518",
        "desc": "addr(bcrt1pfeesnyr2tx)#swxgse0y",
        "hex": "51024e73",
        "address": "bcrt1pfeesnyr2tx",
        "type": "anchor"
      }
    }
  ]
}
createrawtransaction '[{"txid":"ee5baa4fbb01ef4fb207426d9e36b879262037d177742aa17e229b6b9468e1e6","vout":0},{"txid":"ee5baa4fbb01ef4fb207426d9e36b879262037d177742aa17e229b6b9468e1e6","vout":1}]' '[{"bcrt1pfeesnyr2tx":49.99999895}]' 0 true
0200000002e6e168946b9b227ea12a7477d137202679b8369e6d4207b24fef01bb4faa5bee0000000000fdffffffe6e168946b9b227ea12a7477d137202679b8369e6d4207b24fef01bb4faa5bee0100000000fdffffff0197f1052a010000000451024e7300000000
sendrawtransaction 0200000002e6e168946b9b227ea12a7477d137202679b8369e6d4207b24fef01bb4faa5bee0000000000fdffffffe6e168946b9b227ea12a7477d137202679b8369e6d4207b24fef01bb4faa5bee0100000000fdffffff0197f1052a010000000451024e7300000000
bad-txns-nonstandard-inputs (code -26)

As you can see, spending it is non-standard, if you try to send it to your regtest node. However, let's include things directly into a block:

Code:

generateblock "bcrt1pfeesnyr2tx" '["02000000011468870ca9ffacda7d96cc69cafdc7caa0516a91e9dfabd8ca382587d7fc1c7a0000000000fdffffff028207000000000000046002751e30ea052a010000000451024e7300000000","0200000002e6e168946b9b227ea12a7477d137202679b8369e6d4207b24fef01bb4faa5bee0000000000fdffffffe6e168946b9b227ea12a7477d137202679b8369e6d4207b24fef01bb4faa5bee0100000000fdffffff0197f1052a010000000451024e7300000000"]'
{
  "hash": "7ba21327b9c453557d8be7a366e49e8c6437ef67416e704a032c110b7e270c0f"
}
getblock 7ba21327b9c453557d8be7a366e49e8c6437ef67416e704a032c110b7e270c0f 0
00000020a148c67a9905012b97d43cc0d35079d1969002257f97476897cfac60c4b69227082bb2c6b2fdc4618f73e8ed30cf2d91585f40e3df06d29e749cad6a697afc20ca4afd68ffff7f200000000003020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03016600ffffffff0200f2052a010000000451024e730000000000000000266a24aa21a9ed0b029cfb6c326612cf9b7d3c22132e28afcac0717a4bbd9288762b11525c4ab2012000000000000000000000000000000000000000000000000000000000000000000000000002000000011468870ca9ffacda7d96cc69cafdc7caa0516a91e9dfabd8ca382587d7fc1c7a0000000000fdffffff028207000000000000046002751e30ea052a010000000451024e73000000000200000002e6e168946b9b227ea12a7477d137202679b8369e6d4207b24fef01bb4faa5bee0000000000fdffffffe6e168946b9b227ea12a7477d137202679b8369e6d4207b24fef01bb4faa5bee0100000000fdffffff0197f1052a010000000451024e7300000000

See? It is valid. You don't have to sign anything, you can just include that UTXO, and move it unconditionally. Of course, if you include any witness data, for example nearly-4-MB-data-push, then it will be also valid as well. But I am not a spammer, so I will leave it as an exercise for the reader. Real spammers will get there anyway, and as long as miners like MARA still block many non-standard transactions, it will still take some effort. But in general, I think it is inevitable, so I can post examples like that, because moving these coins without any witness stack can help to clear some UTXOs anyway, if someone won't attach any witness into that.

[Quickseller]

I don't care if this is the "real" Nick Szabo or just someone who managed to get the worth-a-shit "verified" indicator at some (a)social media platform. Anyway, that's not the main topic here

I'm not sure if that is him or not. But nowadays, the blue 'verified' checkmark means whoever is behind the account is paying for a 'premium' subscription service, and for most platforms, the user's identity has not been verified, although there are rules against impersonating people.

I haven't been following the 'knots' debate closely, so I don't know all the details. It seems like the core/knots debate primarily stems from what default settings to use on your full node. Bitcoin knots, by default will not accept certain valid transactions into its mempool, and will not rely these transactions. Knots will, however, accepts blocks that contain these valid transactions. In practice, it seems like someone running bitcoin knots will potentially have to validate more transactions for each block they receive, which, at the margin, I think is not optimal. I think it makes little sense to reject transactions in your mempool that are likely to be included in a block in the near future.

I think if there are many nodes that engage in this practice, the risk of accepting 0/unconfirmed transactoin goes up because you may be aware of a conflicting transaction if one depends on a transaction that is rejected by knots nodes. It is already risky to accept unconfirmed transactions, but there is no need to make this even riskier.

eta/ this is not a technical argument, but there is strong precedent, in the US at least, for operators of bitcoin full nodes. The specifics are off topic here, but I don't think potential legal liability is a valid argument to delete arbitrary data.

[alani123]

This certainly is the real Nick Szabo to me. He was always vocal about his opinions at times he viewed as crucial. Although his opinions clearly changed.

Yes he was silent on BTC politics for a very long time but then again people change. Szabo is over 60 now, and by the lookss of his tweets also very vocal about politics, which he usually wasn't vocal about at all.

[ABCbits]

If it's not relayed by nodes it wouldn't be seen by miners except they are presented to the miner directly.
But the issue is spammers adapt.They can use fake Pubkeys in Taproot output by taking advantage of the flexibility of taproot.

The relay of transactions is not an argument at all, the other side is just retarded. Miners already offer public tools where you can directly submit these transactions and there are private channels for submission too. If I can do this, a motivated attacker can do it as well.

Fair point. But IMO it's worth to mention that,
1. Argument of node wouldn't rely such unconfirmed transaction works if majority use Knots or other full node software with similar behavior.
2. Currently only some miner/mining pool offer to include non-standard TX at additional cost.

[Satofan44]

If it's not relayed by nodes it wouldn't be seen by miners except they are presented to the miner directly.
But the issue is spammers adapt.They can use fake Pubkeys in Taproot output by taking advantage of the flexibility of taproot.

The relay of transactions is not an argument at all, the other side is just retarded. Miners already offer public tools where you can directly submit these transactions and there are private channels for submission too. If I can do this, a motivated attacker can do it as well.

Fair point. But IMO it's worth to mention that,
1. Argument of node wouldn't rely such unconfirmed transaction works if majority use Knots or other full node software with similar behavior.
2. Currently only some miner/mining pool offer to include non-standard TX at additional cost.

It is worth mentioning that the argument does not work, otherwise no.   If 100% of nodes ran Knots, it would still not prevent this. I could submit the transactions to the miners instead. Anyway, there is a 0% chance that under any circumstances all nodes would run Knots. What matters are consensus rules, and they say that this is valid.   In any case we can always fall back to other methods so even a complete consensus removal of OP_RETURN would not do anything. As I said elsewhere, if the filterboys side continues to be stubborn and annoying in their depravity then someone will start putting all kinds of illegal content actively just to prove that they are stupid.

At that point they would have just played themselves. To make it worse, if I was such a person I would do it both in OP_RETURN and in other ways that are unprunable so that they have to store the content forever. If a potential attacker is reading, take a note.  

[headingnorth]

Good for Nick Szabo

Only the Core-tards somehow believe that filtering arbitrary garbage from the network is somehow a form of censorship.

That is something I will never understand. These are not bitcoiners. These are clowns who want to turn bitcoin
into any other random shitcoin like dogecoin, pepecoin, fartcoin, clowncoin, bozocoin etc so they can be free to
upload their pixelated cat, clown and monkey jpegs, spam, malware, pump and dump scams, porn or worse.

When Craig Wright is rejoicing this latest release you know something is very wrong.

[PepeLapiu]

It's worth mentioning that the argument does not work, otherwise no.   If 100% of nodes ran Knots, it would still not prevent this. I could submit the transactions to the miners instead.

You are basically saying that filters don't work because you can go straight to the miner. But you either don't understand how filters work, or you conveniently stop at contacting the miner directly, as if that was the final step of confirming your transaction. It's not. You need to figure out how filters work.

Filters could never stop all of the spam because that would be censorship. And the bitcoin nodes are not capable of censorship, no matter how many filters are stacked up.

Filters are meant to be a PITA for spammers and spam miners. They are meant to deincintivise spam. Not censor it.

Anyway, there is a 0% chance that under any circumstances all nodes would run Knots.

We don't need all the nodes to run Knots. But the more of us run Knots, the more of a pain in the butt we become to spammers. I would rather work towards fighting spam.than do nothing about it and pray that it's somehow going to go away by itself by some magical force.

What matters are consensus rules, and they say that this is valid.

No need to get a bulldozer to swat flies. Filters and Knots will grow over time as core gradually fades away and spammers will gradually be chased out of the space. We will never stomp out all of them but we can gradually work towards making it harder for them.

You need to see my thread on how filters work.

In any case we can always fall back to other methods so even a complete consensus removal of OP_RETURN would not do anything. As I said elsewhere, if the filterboys side continues to be stubborn and annoying in their depravity then someone will start putting all kinds of illegal content actively just to prove that they are stupid.

This is extremely disingenuous. We are sounding the alarm that the course we are currently on could end up very badly with all sort of filth getting on chain. And you try to blame us for the changes that core is doing?

We did nothing for way too long. And the spam only keeps getting worst year after year. It's only a certainty that it's going to end badly if nobody does anything about the situation. I hope we can save bitcoin before it's too late.

You are correct in saying that filters are more effective if we all use them. But that is an admittion of sort that core is part of the problem when they refuse to fight spam in any way.

I hope that core will eventually realize they need to change their attitude towards spam, or they will keep losing support and nodes.....

[stwenhao]

And the bitcoin nodes are not capable of censorship, no matter how many filters are stacked up.

All pruned nodes censor everything, that has more than 288 confirmations. And they are not forking the network for some reason. I wonder, why suddenly some people think, that a soft-fork is needed for something, that pruned nodes can do, without any forks at all.

Also, there are nodes, which relay no transactions at all, only blocks. Then, they censor everything equally.

I would rather work towards fighting spam.than do nothing about it and pray that it's somehow going to go away by itself by some magical force.

Then think about doing Initial Blockchain Download, without downloading spammy transactions in plaintext. Because otherwise, the chain will always be spammed.

Even if you assume, that 100% of nodes will run Knots, then still: users will simply store their data inside their private keys. And that would be worse, because then, censoring some public keys will be more difficult, if they will be obfuscated.

No need to get a bulldozer to swat flies.

Do you support the soft-fork? Because it is "a bulldozer", if you compare it to no-forks, which could use ZK-proofs, and handle things in a similar way, as existing pruned nodes are doing it here and now.

And you try to blame us for the changes that core is doing?

If someone can make door locks better, and destroy all walls in the process, then yes, users have a right to complain, that their doors are useless, if there is no "inside", and if all they can see, is just some military-grade doors, not detached to any walls at all, standing still, in the middle of nowhere, behind destroyed walls.

We did nothing for way too long.

And now, instead of doing nothing, some real payments from presigned multisig transactions, will be consensus-blocked for a year, leading Knots nodes to be potentially forked into an altcoin. Great, it is only comparable with a quantum confiscation ideas.

Also, do you want to buy 100 "knotoshis" per "coretoshi"? Because if Knots will go for a soft-fork, then they will end up in a similar way, as BCH, so the community will be splitted again, and the total supply will double again, from 21 to 42 millions. I wonder, if "knots vs core" pair should be listed somewhere, to see, what whales are going to support.

[Quickseller]

And the bitcoin nodes are not capable of censorship, no matter how many filters are stacked up.

All pruned nodes censor everything, that has more than 288 confirmations. And they are not forking the network for some reason. I wonder, why suddenly some people think, that a soft-fork is needed for something, that pruned nodes can do, without any forks at all.

Pruned nodes do not censor anything. They are unable to assist with (most of) the downloading of the blockchain when a node first starts up.

Also, there are nodes, which relay no transactions at all, only blocks. Then, they censor everything equally.

That is not quite the same thing as what knots does. Someone connecting to a knots node might not know they are not going to receive all valid transactions that are likely to be confirmed in a block from that node.

[stwenhao]

They are unable to assist with (most of) the downloading of the blockchain when a node first starts up.

They are unable to do that now, but they could in the future, if there would exist some implementation, based on ZK-proofs, or other similar things. And that would be much better solution, than making any soft-forks or hard-forks, which are currently discussed. Which is why I am surprised, that the discussion is pushed into forks, where none are needed.

[Quickseller]

They are unable to assist with (most of) the downloading of the blockchain when a node first starts up.

They are unable to do that now, but they could in the future, if there would exist some implementation, based on ZK-proofs, or other similar things. And that would be much better solution, than making any soft-forks or hard-forks, which are currently discussed. Which is why I am surprised, that the discussion is pushed into forks, where none are needed.

Bitcoin does not currently use zero-knowledge proofs. And I am not aware of how this could possibly be implemented without a hard fork.