lechuga

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.

earth and the rest of the inner solar system will be strip-mined for materials to build solar collectors and autonomous robots

we're information

greedo shot first

slightly over the top but awesome.

A somewhat more thorough asking of the same good question: http://www.reddit.com/r/Bitcoin/comments/36e8by/21dotco_a_bi...

I'd like to see this answered in some forum. It's very hard to get a more concrete sense of the vision without it being answered.

Travis sounds exactly like a Disney villain. I bet somehow dead puppies are also involved.

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.

Yes. You can show me a relative corner case. But in most cases you want TCP.

Disagree. In most cases you want TCP. Rarely do applications gracefully deal with loss.

Pursue a career in medicine. That way you can be absolutely sure you're working hard for a reason.

Would you have advised people to use the network during the split?

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.

Been working on this with Adrian for the last 3.5 months. Happy to answer any questions if I can.