Is Bitcoin security worth $1B? | Hacker News Reader

Is Bitcoin security worth $1B?

blockcypher.com

42 pointsmriou31 comments

> Multiple signature (multisig) transactions would have prevented all of it.

Yeah, no, there's still a need for hot wallets which can be spent automatically by a server and these were basically the only ones stolen. You actually have to keep the keys separate for it to make a difference.

Also their api is borderline retarded. The server passes back a hash to sign and the client is just supposed to blindly sign it. Sure I suppose it could check it but then why wouldn't you just build it locally.

It is kind of ironic that people who are using a currency dependent on the security of crypto operations created an API that commits a fundamental mistake: trusting the data you receive.

You don't have to trust our data - you can check it against the multitude of block explorers available in the market. However, if you use blockchain.info to check, be aware that they do not support pay-to-script transactions and will not show the transaction until it's confirmed. And you can easily check the received data.

The security of our APIs lies in the fact we don't store private keys - the user signs their own transaction.

the user signs their own transaction.

If I understand it right then that is a lie.

In reality you ask the user to sign a transaction that you create for him.

This is extremely dangerous for the user (pretty close to signing a blank cheque) and I don't like how you try to downplay this flaw.

Your API is broken by design and puts anyone who is naive enough to use it at great risk. You should take it offline.

Seems more like signing a check someone else filled out for you. You can still verify the amount and refuse if it's wrong. Or am I wrong? Doesn't the transaction have to include all the relevant details before it's signed?

Yes, technically the transaction body does include all details.

However, decoding and verifying a complex transaction takes about the same amount of work as generating it yourself to begin with...

Their documentation clearly expects you to blindly sign whatever tx they make up for you. There's not a word on verifying the transaction locally before signing it.

http://dev.blockcypher.com/#signing_sending

I see, that is disconcerting. Though it doesn't seem to be an issue with the multisig transaction api specifically. The single signatory api implies a certain amount trust that they'll produce the correct transaction as well.

I agree that that trust should be more explicitly explained.

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

Indeed, you are correct.

I don't understand multisig well, but isn't the point that 2 or more people sign a transaction to cooperate on an address? You claim BlockCypher is asking the user to sign a transaction they created for him, but from what I understand that has to happen with multisig to work. There has to be a common destination everyone agrees on to fund - someone has to create that destination and the rules governing it.

From their documentation it appears Catheryne's comment is accurate regarding the user signing their own transaction: "Sign the returned hex string and post it with the transaction to txs/send. The multisig address is now funded." I'd have to sign my own transaction in my own wallet to fund a third wallet that was multisig enabled.

Can you clarify why you think they are lying and why you think it is so dangerous that you think they should take down their site? That's a fairly big claim from someone and I think it requires a bit more explaining to do before you go all nuclear on them. It's justified if true, but that would need to be established.

Disclaimer: I know Catheryne via the Bitcoin meetup in SF, which I attend regularly.

From what I see their API attempts to decouple two things that can not be decoupled; the creation and the signing of transactions (whether they are multisig or not).

I'm not even sure what benefit that is supposed to bring, but apparently they believe it is easier for developers to use a remote JSON API instead of a local bitcoin library[1] to generate transaction payloads.

The problem is that it is not trivial to inspect and verify the payload before signing it. It is an opaque hex-string. In order to verify that it contains what you want it to contain you need the same machinery that you'd use to create the transaction yourself in first place.

So if you choose to verify the transactions they make up for you before signing them then you could just as well generate the payload yourself.

If you don't verify the transactions they make up for you (which is what their documentation seems to expect) then you put your wallet at the mercy of whoever controls their servers. That is a very bad idea!

Meanwhile, creating and signing bitcoin transactions entirely in your own code, without talking to any remote party, isn't very hard to begin with. Mature libraries and toolkits exist.

Here's how to create a multisig transaction using the sx toolkit: http://sx.dyne.org/multisig.html

[1] http://libbitcoin.dyne.org/

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.

Thank you for the detailed answer. It would appear wording/code that shows how to validate the transaction is in order.

> Yeah, no, there's still a need for hot wallets which can be spent automatically by a server and these were basically the only ones stolen.

The point is that you don't need a hot wallet if you support multisig - the coins never go to the service provider, they stay in the users wallet.

Depends on what you're trying to do. If you want to run an exchange, the exchange needs full access to keys. Unless it's an exchange running on a smart contract on distributed oracles ( http://orisi.org ) :)

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?

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.

Yes, multi-signature transactions can greatly improve security. But this idea of using a third party to write your transactions for you is a very, very bad idea. It introduces an additional point of failure for security: someone can break into their server, and make it start generating transactions that send coins somewhere other than where you said.

Writing software that uses this API would be negligence.

Someone can also break into your servers and manipulate your transactions. It's our business to run a secure and reliable service. Bitcoin infrastructure is fairly complex and so the probably that you'll miss something are pretty high. Isn't it better to focus on your own business rather that spend all your time and money building and maintaining the backend piece?

Then release/sell a library. Don't expect Bitcoin users (who, especially the early adopters, are almost tautologically more likely to distrust centralized services). Library code can be audited, and guaranteed to do what it advertizes.

> Someone can also break into your servers and manipulate your transactions. It's our business to run a secure and reliable service

And now they have two servers they can break into?

Reminder: For anything but toy apps you do not want to relay your interactions with the blockchain through a third party.

To be clear really relaying transactions through a server is probably fine. The problem with this one is the api let's the server generate the transaction and the client just blindly signs it. You are completely trusting the server in this scenario.

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.

Because of the amount of real money invested, I would (somewhat jokingly) say that securing Bitcoins is a business more valuable than Bitcoin itself.

We already spend a total of $15 million dollars per day in energy costs[1] making secure transactions in Bitcoin, so I think in a way we're already spending more than $5 billion on Bitcoin security.

[1]: http://www.forbes.com/sites/timworstall/2013/12/03/fascinati...

I ran the numbers on newer mining rigs a few weeks ago and came up with a PH/s needing about 1 semi tractor trailer engine to run. The network is currently doing about 130PH/s, so that's about 130 semis engines running. Not anything to sneeze about, but also definitely not $15M a day.

A quick read of the title left me rather confused: Are they seriously asking the question "Is Bitcoin worth 1฿?"

A tautology indeed. Only upon reading the article itself did I realize I misread the title: I had both skipped over the word "security", and misinterpreted the B as the Bitcoin symbol, rather than an abbreviation for a billion.

prime numbers worth 1 billion....?

Reply on news.ycombinator.com