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).
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.
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?
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.
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.
Banks are made of a mess of different systems. Some are locally ACID, but overall reconciliation and compensation are what keeps it all together.
Regardless, this has little to do with banking. The systems are too widely different to be compared productively. The only conclusion you can get from this (marketing) story is that when you have an eventually consistent system, you will need occasional distributed locking. Cassandra often comes in pair with ZooKeeper.
The other conclusion is that no matter how trivial they sound, distributed transactional systems are far from trivial.
I'd be curious to have your perspective on the risks of relying on 3rd party infrastructure. That 3rd party can't really try to feed wrong blocks or transactions, it would ruin its business. Then from a practical standpoint, the only attack it can run is a Sybil attack which, when not spending any transaction, can't result in double-spends. So what do you see as a problem relying on 3rd party infra for Bitcoin development?
I'm really glad Andreas is writing this book, should be a great way for more developers to get involved. Crypto-currencies are unfortunately still a little too arcane and books like these help maturation.
> you can still feel pretty safe with 0 confirmations if you're monitoring the
> bitcoin network for double-spend attempts over the average network propagation time
The above is much easier said than done. First, you're assuming you can have a good enough coverage of the network which is hard to assess. You need to do a constant topology analysis to see how well-connected you are. Second, you need to ask a chosen set of peers for all the transactions they have in their pool. And wait until they all reply. Third, you need to be pretty good at normalizing against malleability on all those transactions.
After doing all of this, the scheme is still not bulletproof. The blockchain exists for a reason.
And it happened even only with bitcoin-core. Anyhow the 50/50% scenario across implementations is unlikely to happen if everyone seeing a new one cries forking wolf.
I do empathize with the need of solutions for today though. I was just thinking about tomorrow.
I've heard that argument many times and all it does is reinforce the idea that no other implementation can work. And how you end-up with an implementation mono-culture. Forks of a single block happen regularly, it can be dealt with. A production system can detect a fork and check the reference implementation's behavior, preventing any longer fork.
The *coin ecosystem need more than one implementation, a single codebase can't cater to all uses. I should know, I'm an Apache member.
All great changes, especially BIP 70 and the fixes on transaction malleability and relaying. I'm unconvinced the efforts to make bitcoind (now Bitcoin Core Server) a "border router" are well-spent however. Software that's optimized for server deployment and larger clusters is fundamentally different from what you would run on your desktop. I personally think that Bitcoin Core should focus on the protocol and extensions to be a good reference implementation, easy to deploy in all environments.
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).