Minor nit re: Rails legacy. IMO a major reason it was so popular was because of Ruby. It's certainly not the right hammer for every nail but the syntax is one of the best to work with ever. Whenever I can find a project where writing a little Ruby makes sense I use it. Because I enjoy it :)
While it's useful to me and dominates what I code in atm, I don't necessarily like writing Go. Better than C/C++, sure, but I wouldn't go so far as to say I enjoy it.
I'm intimately familiar with cases where you actually would prefer to use UDP. My point is most of the time these cases aren't what you're dealing with.
In addition to reliability, TCP provides congestion control which provides approximate fairness of bandwidth utilization per connection. Fairness here meaning given a limited pipe of size W each connection gets a W/N slice of the pipe's available bandwidth. I don't know that I'd like to live on an internet where every hipster made their own decision about how to handle congestion control, see also congestive collapse.
Currently we're saving every block we see. And if we find an orphan's parent which is on the main chain we try to connect them both. We aren't doing anything to explicitly avoid them.
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.
The only instances of it we having running are the ones listed in the blog post (and just perhaps a Litecoin version that we're trying to get to sync.) They are in no way currently integrated with the web site.
That's completely fair. Consensus systems are very difficult to (re-)implement correctly but I would argue there is value in doing so. There is also great risk and we appreciate that.
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.
While it's useful to me and dominates what I code in atm, I don't necessarily like writing Go. Better than C/C++, sure, but I wouldn't go so far as to say I enjoy it.