Hacker Newsnew | past | comments | ask | show | jobs | submit | mriou's commentslogin

BlockCypher | SF Bay Area (Redwood City) | onsite

We're building a block chain platform. We have web services to make it easy and quick for people to start developing for bitcoin and other cryptocurrencies.

We're seed funded ($3M) and hiring backend engineers. Get on touch with me (matthieu at blockcypher dot com) or our contact email (contact at blockcypher dot com).


To support Urea we mostly had to add support for the X11 hash function and implement the Kimoto Gravity Well algorithm:

http://bitcoin.stackexchange.com/questions/21730/how-does-th...

The rest (port, block reward, etc.) is configured through simple parameters.


It is non-trivial to create and sign a transaction among multiple parties. The point of multisig is that you have several entities, some can be humans, some can be machines, programming languages can be widely different. And no matter what, signatures have to be assembled so someone has created some transaction for you to sign before and there has to be some correlation between the signatures of the different parties.

I've had in mind to add a section on how to verify the hex we return with a few simple rules. Following your feedback, we'll add that soon.

P.S. In case it wasn't clear already, I'm a co-founder and CTO at BlockCypher.


Thanks for the feedback, we will add a section on how to verify it.


Not blindly, you see both the generated transaction and the data to sign, you can validate either or both. And you are completely trusting a server in many other situations.


This is incorrect. You can have servers using multisig too, it increases the overall security of the transactions, especially if the different private keys are stored in different environments (different datacenters, different OS, etc.).

Regarding the blind signature: yes, you can check it and in most cases it's just checking a series of bytes at a given position in an array. One line of code. Building a multisig transaction locally? Good-luck doing that.

Also I've heard many times arguments along the lines of "my security is better than yours, I don't trust you". It's reminiscent of those arguments about cloud providers like AWS, "my outages are better than yours". The point is we are focusing solely on block chain infrastructure: the security, performance,and reliability. It's our expertise. Is it yours?


Also I've heard many times arguments along the lines of "my security is better than yours, I don't trust you". It's reminiscent of those arguments about cloud providers like AWS, "my outages are better than yours".

I guess this is where sufficiently advanced incompetence becomes indistinguishable from malice.

In either case, I strongly advise everyone to refrain from ever using any bitcoin service that you may be involved with.


> Regarding the blind signature: yes, you can check it and in most cases it's just checking a series of bytes at a given position in an array. One line of code. Building a multisig transaction locally? Good-luck doing that.

Code? Better yet include it on your examples.


Will do, thanks a lot for the feedback.


It's much simpler than it sounds, only 7 lines of code in the sample posted. The point is that most people don't want to share their private key or their users' private keys, justifiably so.

The alternative is building the full binary transaction on your end, which involves selecting inputs, generating scripts, worrying about fees, etc. Implementing that is a week's project. Using an API is 5 min.


The alternative is building the full binary transaction on your end, which involves selecting inputs, generating scripts, worrying about fees, etc. Implementing that is a week's project.

Hasn't BitCore already done that?


They have. But only if you're on node.js and you need to run bitcoind yourself. Which means maintaining it, backups, restart scripts, etc. Building the transaction using BitCore isn't really simpler either (see the sample https://github.com/bitpay/bitcore/blob/master/examples/Creat...).

So using BlockCypher's API to do that is much more portable (you have ECDSA signature libs in most PLs) and avoids all the hassles of additional infrastructure.


The full API documentation can be found there:

http://dev.blockcypher.com/

Includes websockets and webhooks to get notified on a variety of blockchain events.


Not sure how well-maintained it is but:

http://www.scalajobz.com/


Our APIs will expand a lot over the coming months. Any feedback on people see as most useful is highly valuable.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: