revcbh

Nope, although PartTimeLegend is obviously quite disgruntled for some reason I've never entirely been clear on. Nobody was removed from the project on GitHub for over a year after there was last active development. We only took people off of it when some started acting in a disruptive or aggressive manner. Anyone that still wanted to work on that project (buttercoin/buttercoin) was invited to let us know and we would give them access or transfer the repo to them.

That repo was the initial open source attempt at a better trade engine in node. It suffered from too-many-cooks syndrome after being started as an announce-first project. There was no clear direction, some people wanted it to be a distributed market, etc. After a couple of months, we thought it would be best to start from scratch with a small team on a focused implementation in Scala. That's available at http://github.com/buttercoin/engine.

The other contentious point was bitcoins that were donated. We posted a couple of times over the course of the year that anyone who had donated should get in touch with us to have their coins returned as the original project looked dead. Nobody contacted us, so we decided the best course of action was to simply return the coins to the address they came from. That irritated a couple of people, but I still think it was the right thing to do, especially as the person who had originally collected donations had left and there was no clear governance setup for their use.

The original impetus for the project was to create a more robust and secure way for people to access bitcoin liquidity. Specifically in the US, since that's where people seemed to be having the hardest time getting money in and out of other platforms. In that respect we've succeeding. We're also still committed to open sourcing as much as we can and will continue to expand the buttercoin/engine repo.

Good catch, thanks.

Yep. That fee is still competitive even if you're just buying and holding, but we're geared more towards traders.

We're working with our partners to improve the cost structure so that we don't have to charge deposit fees.

I'm one of the founders/CTO.

Our main difference from Coinbase is that we have an order book and real-time trading. Coinbase is great for people that want to buy some bitcoin at a fixed price and don't mind waiting a few days to get them. We focus more on businesses and traders that need to buy and sell bitcoin in real time. Adding USD is also very fast with us, usually 1 or 2 days. I think that's slightly faster then Coinbase, or was last I checked (unless you add a credit card for instant buy with lower limits). It doesn't matter as much in Coinbase's model, since they're fronting cash to lock in a price.

Ha! I wish ChangeTip supported HN.

Yeah, that's basically the idea, probably using some multi-sig protocol. It will never be as fast as our internal ledger though, since I think we'd need to wait for at least one confirmation before funding the trade.

We have been audited by independent security professionals and will continue to undergo frequent security testing (both code reviews and adversarial testing). I'll try to make the results of that more public, since you obviously shouldn't just take my word for it.

To protect against losses we're working to get insurance for deposits setup, but it's not in place yet. We're also looking at the possibility of letting people maintain custody of their coins if they don't need realtime trading. Proof-of-reserve is also planned soon to guarantee that all accounts are fully funded.

Right now, the vast majority of coins we control are in cold-storage wallets that require 4+ people to access, with most of the rest in cold-storage wallets that require 2 people to access. Only a very small amount is in a hot wallet. We're working with a partner to add custodial multi-sig to our hot wallet (and maybe cold wallets) so that even if someone compromises our machine, there's an external signatory which will be able to prevent transactions from processing.

You're right to be cautious. Even though I keep most of my bitcoins on Buttercoin, in general I wouldn't recommend that anyone use a centralized service for long-term storage. We know that people will do that though, so our security has to be up to par. Hopefully the features we roll out over the next 3-6 months will create enough transparency that you can trust us.

1) Compared to exchanges like Bitstamp, we have US banking relationships and can fund accounts via bank transfer in 1-3 days. Generally, wiring funds internationally is much slower and more expensive.

Compared to brokers like Coinbase or Circle, we have an order book, so traders can quickly adjust their positions.

2) We're working on insurance for held coins and the ability for customers to maintain full custody of their coins (possibly at the cost of slower trade completion times).

Paul started the effort to build an open source trade engine and had buttercoin.com lying around. We joined up with him a couple of days after he announced the idea and started working on it. Cedric and I already had an interview lined up for YC, but we all thought it was a good enough idea to add Paul and change the idea we were applying with.

Unfortunately things didn't work out and the original open source effort died off when we decided to start with a fresh implementation. We just recently release the engine we're using (with some minor tweaks) under an MIT license here: https://github.com/buttercoin/engine. We'll be backporting a bit more functionality until we can actually run it in production.

Paul left after a couple of months and hasn't been involved with the project for about a year and a half. None of the design or code is based on the original open source effort which he started. We're not trying to hide history, he just doesn't want people thinking he's associated with it anymore.

Ha, I'll have to try that. Does it use our icon even if you just navigate to HN directly?

Oops, that's a bug with how we're using Angular. Thanks for pointing it out!

It has to do with banking and regulation. Adding new regions takes a lot of time and effort to get right, but we're working on it.

Yeah, we're working to expand coverage and bank relationships outside of the US. I can't give any specific timeline, but it's one of our highest priorities.

Thanks for pointing that out. I'll try to make it more clear.

We're finally open for anyone to signup, so we're celebrating with free trading. Please write bots, we've got a pretty good API.

The open source re-release of the engine is also back up for anyone that wants to play with it: https://github.com/buttercoin/engine

This is code derived from the Buttercoin.com codebase for performing order matching. It's MIT licensed and written in Scala.

We're starting to let people in from the wait list. If you're interested in playing with our API send us a mail at hello@buttercoin.com

In many cases, Docker can be treated like a more lightweight Vagrant. One important benefit I get is more efficient use of machine resources. Running 5-10 fully virtualized Vagrant instances on my laptop hurts. Running the same number of Docker containers is trivial.

The ability to version your images and easily build on them is nice too.

Yep. The only really-real difference is compile time checking.

Let's use circles and rectangels to motivate some analysis. In Haskell you might define:

  data Point = Point { x :: Float, y :: Float }
    deriving(Generic)
  data Shape =
    Circle { center :: Point, radius :: Float }
    | Rectangle { topLeft :: Point, bottomRight :: Point }
      deriving(Generic)

In C# you could similarly define

  class Point {
    public float _x, _y;
    public Point(float x, float y) {
      _x = x;
      _y = y;
    }
  }

  interface Shape {}
  class Circle {
    public Point _center;
    public float _radius;
    public Circle(Point center, float radius) {
      _center = center
      _radius = radius
    }
  }
  // etc, for Rectangle ...

Let's start from the C# end of things. Let's say we want to do some tests on random Shapes and that we want to get an instance of a random shape by calling Generate.random<Shape>(). There are a couple of different ways to do this. We could explicitly define a RandomShapeFactory and a RandomPointFactory and then wire those up into the Generate class. Maybe we could use reflection to dynamically generate instances of Points and Shapes from their definitions at runtime. It would probably end up looking like some combination of the two.

Haskell doesn't let you magically generate random instances of Shape. The cool thing it gives is the "deriving(Generic)" part. Effectively, this causes the compiler to generate a description of Point and the Shape-Circle-Rectangle set of types. In many ways, it's like C#'s reflection. The QuickCheck library uses this reflection-like definition to generate random instances.

The core functionality isn't very different, but Haskell's approach has a number of advantages. Most importantly, it's type-checked at compile-time. In the C# version, I could call Generate.random<Cat> and the code would blow up at run-time, whereas we would just get a compiler error in Haskell. The other major advantage in this case is the reduction of boiler-plate. There's no need to register factory instances inside of some singleton object at startup, the type system can infer which Generic components are needed where.

C# and Haskell are both turning complete, so you can do anything in either language. Haskell makes certain types of programming more enjoyable by reducing boiler-plate and preventing annoying runtime errors.

EDIT - code formatting

We don't have state-by-state licenses since we're structured as a service provider. We partner with existing licensed institutions in various countries.

Yes, but there's a limit to the number of jobs posted there and it's currently full.

I really like Haskell, but I'd settle for Rust.