Toshi – An Open Source Bitcoin Node for Developers
blog.coinbase.com
blog.coinbase.com
The next problem is that they are still using EventMachine. Still think I'm a crazy person? Oh look, it's like I'm a well-received field expert on this topic or something http://www.slideshare.net/mobile/KyleDrake/hybrid-concurrenc...
Incase anyone's interested in being a developer at Coinbase, I'll save you some time: they're more interested in pedigree and whiteboard puzzles than science and code. Most disrespectful interview I have ever had in my 13 years of coding, and probably ever will have.
We haven't run any issues with using EventMachine yet, but will consider other alternatives here if the need arises.
Indeed, there are a few maintainers on EM, for the sole purpose of preventing it from breaking every single time the ruby team releases an update, because if it broke, it would cause a problem with legacy code in the ruby space. If the EM maintainers walked away, Coinbase would be stuck on an old version of ruby until they themselves patched EM to solve it. EventMachine is not something people should be basing new projects on, especially projects that involve money.
Tony Arcieri wrote nio4r (https://github.com/celluloid/nio4r), which solves this problem in a far better way, and then used it to implement cellluloid-io (https://github.com/celluloid/celluloid-io), which doesn't choke ruby's ability to do concurrent IO using it's internal threading mechanism. Combined with JRuby, you get even more than concurrent IO here like with MRI, you can also get real threading, which is important in a space where CPUs aren't getting faster, they're getting more parallel. Node.js has the same problem, but unlike Ruby/EM, JavaScript is actually designed to be async, so at least everything is designed to expect it.
Because Sinatra (like all non-EM ruby code) uses the threading style for concurrency, as soon as you start running EventMachine, everything will block for a single request, even if it's slow IO bound. You can demonstrate this very easily by putting this into the code:
get '/blocking' do sleep(10) end
get '/notblocking' do 'ok' end
Hit /blocking with curl, and then hit /nonblocking with a second curl command. The second request is blocked until the first one completes. Now try the same thing without eventmachine, and it serves the second request concurrently without a problem. That's what you lose in this exchange, and it's a big thing to lose. I'm using sleep here, but the same blocking will occur for database queries, remote cache hits, HTTPS requests (to get things like, say, the exchange rate), everything involving IO.
The only way to get around this problem and still use ruby synchronously is to resort to crazy hacks, including a fairly popular project I created a while ago called sinatra-synchrony (https://github.com/kyledrake/sinatra-synchrony), which wraps async code using fibers. But in order for that to work, every library you're using has to support it, so this path would require a massive refactor of the entire ruby ecosystem, and that's simply not going to happen. It's also incredibly difficult to debug, and there's a lot of bugs with EM - sometimes things would just lock up or segfault, or ruby would spit out an error stack that had nothing to do with the actual exception that occurred.
I tried very politely to explain this problem to Coinbase about two years ago during an interview, and their reaction was to ask about my college degree, give me a bunch of weird whiteboard problems that had nothing to do with actual programming, and then show me the door, one day after I helped fix all of their client libraries when they switched SSL CA providers and didn't even realize it, and then provided a pull request to coinbase-ruby providing concurrency support using this very same threading mechanism, on the two-hour flight there (proof: https://github.com/coinbase/coinbase-ruby/pull/6)
Are you being fair to Coinbase? There are two sides to every story.
But if this is true at face value, then it's disappointing to hear that a YC startup would care at all about a degree or about whiteboard problems, of all things.
If a company cares about what a programming candidate can do, then caring about a degree or whiteboard problems is caring about the wrong thing. Thought experiment: How much better or worse would YC's results be if they had candidates solve whiteboard problems during the interview? (Admittedly, YC cares about degrees though.)
Yes, it is like being interviewed for making a time machine, you show a working time machine and they continue to ask you questions about physics...
Also, people screw it up big time, often it's totally random. Maybe they ate a bad sandwich for lunch and didn't enjoy the interview as a result. Facebook famously turned down WhatsApp co-founder Brian Acton back in 2009, even though they went on to acquire his company for 19 Billion 5 years later.[1] Talk about making lemonade from lemons.
I think all you can do with these things is use it as a pause to think about how you can do better, and if you can't think of anything just chalk it up as a random event, like a bird crapping on your windshield.
A good HR manager will be tracking "fit" by rejection and skin colour, gender and university.
That said, coinbase etc should be looking at the technology used - but we should not. In the same way we do not look at multi national banks by their tech stack but by their regulatory regiemes, their liability to asset ratio and so on
In other words, if bitcoin is going to take it's place amount the worlds currencies, it will be handled by things we think of as banks with asset backing and more. Probably gaming companies and telcos.
This time we took a slightly different approach. Whenever possible, we directly ported the validation code from bitcoind. Granted, the script runner is the most fragile part and for that we are relying on bitcoin-ruby which does not directly port it from bitcoind.
While we are passing Matt Corallo's brilliant test suite, it is not currently recommended that anyone use Toshi in production for the purpose of managing bitcoin. And if you are going to run it in your environment we highly suggest running it behind trusted bitcoind nodes. There are many pieces still missing -- like all of the DoS penalty code. We currently have the demo running in the wild for the very purpose of giving helpful people the opportunity to break it.
Does Coinbase use Toshi in production?
What did you guys go with as a policy for handling or avoiding orphan blocks...
If you're referring to side chain blocks (which some people refer to as orphan blocks) we'll extend them to be the main chain should they win or leave them forever marked as side chain blocks. We aren't doing anything to explicitly avoid these either.
User agent: Toshi:0.1.0