pull down to refresh
850 sats \ 5 replies \ @anon 27 Feb \ on: AJ Towns censoring on Delving Bitcoin to cover Bitcoin Core backdoors ? bitcoin
At the risk of being horribly cliche, it sounds like Nostr probably fixes this.
Also as a humble pleb I have no idea wtf is going except that I'm not upgrading my node anytime in the near future until this dust is settled and may even revert back 1-2 versions.
Can anyone provide a left side of the bell curve explanation and steel man both sides please?
reply
so perhaps the solution is to upgrade to non-core implementations that remove the bugs while maintaining security fixes.
The WHOLE point of this post is that OP argues core devs are creating backdoors for exploits.
reply
If you don't trust the development process then your only options are to run old software or manually audit the codebase. I don't think running old software will protect you from malicious code injection. This attack vector doesn't work by stealing your coins directly, instead it weakens trust in the whole bitcoin ecosystem and crashing the price. It doesn't matter what node software you run when your bitcoin buys you less goods and services than it used to.
As for actual long-term fixes to this problem you should look into libbitcoinkernel, it will enable a plurality of consensus compatible bitcoin node implementations.
reply
yes all points that make sense.
that things like libbitcoinkernel or p2p stack could benefit from longer-term security backport would be a good thing. however in terms of bitcoin core codebase modularization we’re not there yet.
reply
Nostr probably improves this.
I think we’re still years (half-decade ?) ahead of dev experience matching what is offered by GH, assuming Nostr moves in the good direction (which I hope so!).
Also as a humble pleb I have no idea wtf is going except that I'm not upgrading my node anytime in the near future until this dust is settled and may even revert back 1-2 versions.
Spend more time becoming more technical by yourself. Don’t trust the devs on the face value of their technical statements. Always verify. When you have established developers disagreeing among themselves in the public, spend even more time verifying their statements.
reply