pull down to refresh
0 sats \ 10 replies \ @88b0c423eb 3 Oct \ on: Which Fork will you Sell and/or Keep? Bitcoin Knots vs Bitcoin Core bitcoin
I wonder what will happen to LN in that scenario.
reply
I know and agree about knots fork being a psyop, still a fork (more likely from core) is still possible.
reply
What core is doing isn't a fork. It is backwards compatible.
Someone who runs Core 29 or 29.1 for example has to do 'nothing' and everything is forwards/backwards compatible.
Knots on the other hand by activating an anti-spam hard fork, is changing consensus rules and creating their own fork. That is the point of the write-up and what I was trying to address. Core is not proposing a fork
reply
reply
true
reply
My post as the 'op' wasn't related to the Lukejr article. I'm not sure that article is credible or relevant...
But I do think there will be a fork eventually otherwise how will the concerns of the Knots enthusiasts be addressed or satisfied?
Clearly to them (which is totally their choice) running Core isn't acceptable, and neither is the spam. Spam isn't going to be 100% solved under core v30... and it isn't solved now either.
So a serious, meaningful solution needs to be found which invalidates such spam in blocks itself and if that invalidates 'core' blocks then it's a hard fork.
What am I missing?
reply
You are focusing on the spam problem too much.
There are many ways we can filter and fight it, but nothing is going to work or even matter if the core devs have control over Bitcoin that allows them to push unwanted changes whenever they want.
The solutions to the technical questions will be solved more easily after this current political/philosophical debate about the proper role of Core dev maintainers.
reply
You're missing core devs with their ego not fixing a but since version 25 and calling it a feature: https://nvd.nist.gov/vuln/detail/CVE-2023-50428
While the devs from knots fixed it.
reply
Question - how did the fix in Knots come about?
Was it through limiting the size of Witness scripts? or simply targeting the op_if op_endif combination for [non]relay?
My research on this at the time... was that most Core developers thought the arbitrary data combination could easily be replicated with other opcodes, slightly changed, and repeated or reproduced ever so slightly different.
So it would be like 'whack a mole' because the exact scripts could be changed slightly again and again and filtering each time would do more harm than good.
Today, the reason for not 'filtering' is that the 90% threshold would never be met... and filtering inscriptions today would harm the mempool, fee estimation, and be ineffective regardless a net negative.
So it has not been changed.
The other explanations I've read is that larger witness 'blobs' aren't economic... the NFTs or jpegs are DoS attacks noone is really buying them. Attackers will change or alter their attack ever so slightly... because they don't care about the arbitrary data ITSELF, just attacking Bitcoin noone is buying monkey jpegs.
Which I also think is true.
reply
reply