> If development were primarily about choice the developers ought to instead just ship a copy of GCC: there tada, you get all the choices, write your own node. :)
/u/nullc
Jokes aside, it's a good post.
https://old.reddit.com/r/Bitcoin/comments/1kab15o/bitcoin_cores_github_mods_have_been_banning_users/mpou6xb/
Login to reply
Replies (5)
It is a good point. I tend to favour the abstract. But very often it's the constraints that define the nature of the system. I think that's why it took Satoshi many years to finish the first public version of bitcoin.
Hi,I've got some exciting news for you,I can teach you how to turn your $300 into $9500 in just 4hours investing Bitcoin mining without interrupting your daily activities.
DM ME HOW FOR MORE INFO: ๐
WHATSAPP: +1 (818)ย 463โ4473
Email:
christineduff300@gmail.com
Telegram Username: christine4219
So is this point from a followup:
> Sometimes developers have left in options to silence disputes from people in the sense of "look if there is an option it will have no effect because virtually no one will set it, and the people committed to this argument can feel that they won, that they did something, but it's really just a placebo". It's expedient but arguably it's not particularly respectful. Especially in a case like this where even if virtually everyone set the option it still wouldn't have the intended effect.
Interesting idea, could stimulate people to use Stratum v2 / DATUM without having to run a fork of Bitcoin Core:
> While discussing this here it does occur to me that there is a different line of compromise which might make more sense-- Bitcoin Core conflates relay policy and mining policy. The historical reason for this is that they should match or vaguely bad things happen. But in case where there is a dispute over policy it makes more sense for mining to be the more restrictive of the two, because the negative effects largely come from miners including txn nodes weren't expecting. So maybe it would make sense to change the option to be one that only changed mining policy. At least as mining policy it has a real effect (assuming you're mining!) -- I'm not sure, this is just an off the cuff thought.
Though this also sounds like an implementation headache, and it's still ultimately a placebo. Since this would only be used by tiny miners, the thing they don't like will go in the next block.
From that same thread: https://www.reddit.com/r/Bitcoin/comments/1kab15o/comment/mprj4tv/?context=3
The most effective way to encourage significant censorship by all miners is to credibly threaten them with reorgs if they include bad things. Needless to say, that would set terrible precedent and probably be the actual end of Bitcoin.
If you're going to reorg a block because its content is evil, or just doesn't obey your favorite new soft fork rules, please put its hash in a coinbase OP_RETURN of your alternative block.
That proves you saw the block but chose not to accept it. As opposed to just having missed it, as with a typical stale block.
Call it a Bad Uncle block?
You could even do this with weak blocks (reduced proof of work) if all you have is a BitAxe.
View quoted note →