Furthermore, a year is a really silly measurement of time for how long learning something will take. If you have some background knowledge in the field, then most individual blind spots can be cleared up in a month or two of full time study. It took me about 2 months from not knowing how Bitcoin worked to implementing my own cryptocurrency with a novel PoW approach. This stuff isn't that hard.
Totally agreed. Just because you're an expert, that doesn't absolve you from having to make your case.
But the same is true of anyone else, and that necessarily excludes non-experts who will not be able to make their case effectively.
That is the crux of why this is a huge deal, and Linus changing the Linux scheduling algorithm is not a huge deal. People are afraid that Bitcoin is going to break, or meet an obstacle that prevents them from making massive ROI on their speculation, and they have a lot of stake in the game in protecting Bitcoin.
> It took me about 2 months from not knowing how Bitcoin worked to implementing my own cryptocurrency with a novel PoW approach.
"It took me about 2 months from not knowing how cryptographic hashing worked to implementing my own hash with a novel sponge function."
The hard part is not making a cryptocurrency that works when people use it normally. The hard part is making a cryptocurrency that works when people around the world can profit tens of millions of dollars by breaking the cryptocurrency (either abusing the mining, spending coins that don't belong to them, DoS'ing competing miners, etc.)
I don't know which cryptocurrency you made (I tried to look it up via your HN profile, but didn't find anything), but if you get it peer reviewed I imagine that experts will quickly be able to find a reason or two for why it is either broken or uninteresting.
Anyone can make a cryptosystem that they themselves cannot break. Bitcoin is among the most complex and cutting edge cryptosystem we have today. Even in the past few months, several important and severe flaws in Bitcoin have been discovered and fixed.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015...
https://www.reddit.com/r/bitcoin_devlist/comments/3bsw60/upc...
Decisions as seemly small as updating the blocksize limit are enormously nuanced. It changes the entire game theory behind the mining, affects how people will be running validation nodes, and requires a strong understanding of how blocks propagate around the world, and what a nice 'average' block looks like vs. a block that was made maliciously.
> better follow it up with links to a list of the academic papers that one would need to get up to speed
This is a very difficult thing to do, especially because Bitcoin is so new. Much of the important discussion that has happened resides only in mailing lists, blog posts, irc logs, github issues, and forum posts.
But here is a good set of papers to get started:
http://diyhpl.us/~bryan/papers2/bitcoin/
A smaller, more focused list:
It will also help if you read the full #bitcoin-wizards log, dating back to around 2013 I believe. There you will find lots of highly technical discussion with links to more discussion and research papers. It's probably got the highest signal to noise ratio of any public discussion.
Even the normal political problems that governments concern themselves with typically have technical aspects as well as their social values aspects, and while democracy can hopefully allow us to take many different peoples ideas of what constitutes the good life into account, we don't expect them all to have a complete understanding of the technical aspects of each decision.
It's quite possible that random guys might have relevant things to say about the values that inform the block size discussion even if they don't understand the details of the technical discussion.
Why not? As an end-user your opinion is very important, you're the one that has to live with the detached decisions that Linus makes regarding the scheduler.
Task scheduling is deeply complicated. Optimising for one set of cases hurts others, so it's an exercise in hard tradeoffs. It also has deep knock.on effects in other parts of the system.
I do not have the expertise to make proper judgements regarding choices in that space. The breadth of knowledge and experience required greatly outstrips my own.
Moreover its a space where subjective experience is the worst possible measure. So my gut feeling as a user is utterly useless in making appropriate technical choices in the space.
I'm pretty sure giving people the time of day is an admirable trait and can teach you many things regardless of their expertise. It's after the fact that you disregard the cruft.
It's like the Republican debates for me, I can't seem to find any common ground with these candidates but then I find a few nuggets that I do like (such as Jeb Bush's funding of crisis birth centers and increasing the adoption rates in Florida through better funding and education for adoption centers. Even if I'm pro choice I think those are good ideas). Of course, the Republican debates are two to three hours long so it's very thankful they're not very often and you need to find the balance so that you're not just wasting your time.
I think it's fair to say that there is no black and white answer to this issue and you really have to go on a case by case basis to maximise your use of the information contained in the people around you.
I wouldn't expect Linus to listen to my opinions about the Linux task scheduler.
Why should the Bitcoin community listen to some random guy's unsupported opinions about block size? This isn't about politics or being nice and listening to everyone. This is about making a massively technical choice and it better be made based on solid technical reasoning, not on a desire to be happy and inclusive.