Topic: Introducing Hive, a beautiful new wallet for Mac OS X - page 17. (Read 141170 times)

Release 2013110501 codename "The Fifth of November" is now available:

• added Arabic, Chinese Simplified, Czech, Hindi, Korean, Russian, Spanish, Tagalog and Urdu translations
• added LocalBitcoins and Patten applications
• Hive can now handle bitcoin: links on websites
• improved error handling - popup window should now show up if an error occurs while processing blockchain data
• fixed JS API breaking after app page is reloaded

As usual, you can get it from http://grabhive.com or through the Sparkle auto-update system. The latest release can always be downloaded here: https://github.com/hivewallet/hive-osx/releases.

I've talked about it with Andreas before, he knows I'll revisit this topic at some point. I never got a chance to play with the threshold RSA library I got hold of, unfortunately.

Basically the work for Android means:

1) Find a way to reproduce the build. As APKs are just zips, and the contents are just produced by javac which is a very simple and mostly static program, this should not be very hard. Rather than the gitian approach I'd think just locating the parts which vary for some legitimate reason, like timestamps, zeroing them out and then checking the file hashes match would be OK.

2) Test if the RSA threshold library I have really works as advertised (makes ordinary RSA signatures), and if so, check that it's possible to shard an existing key and signing works. I believe it should be possible, but there's no replacement for trying it.

3) If the technology works, get Andreas to shard the key into say 50 pieces with a threshold of, say, 30, and then start the process of making ordinary builds use threshold signing. I imagine Andreas would keep the original key for a while and eventually get rid of it. Probably there'd need to be a new beta app so he can push out new releases to testers without anyone else being involved (currently the Play Store beta system is used).

Good to hear.

I'd be interested to hear other wallet developers respond; Andreas Schildbach's Bitcoin Wallet for Android has auto-update capability.


Yes indeed. It suggests that creating pseudonyms to act as plausibly deniable co-developers has some merit.

In the meantime I'd suggest non-anonymous developers take my advise seriously for their own legal and physical safety.

Changing a library isn't really a great way to seize coins, is it? Even if it were possible to implement that, which it's not, the answer is "only if forced to by a court order" which I assume is true for all software developers.

I think the developer gets hacked scenario is much more likely than physical kidnap or whatever, but as the stakes rise, so does the need for security. In the long run I'd like to see update keys be sent to fully anonymous developers who can't be found by anyone, but still have an established reputation for doing coding and review work. Such people are rare, though. We need Satoshi back

So, for the record, for a "legitimately good reason" would you add code to, say, bitcoinj to take stolen Bitcoins and return them to their original owner?


I agree. That's why my advice is intended to reduce the risk not for users, but to reduce the risk for the people maintaining wallet software. That's why I gave a whole bunch of suggestions for how to better manage that legal risk, above and beyond simple threshold signing, if you do choose to take on that personal risk and make auto-updates possible.

Anyway, government aside, I'd definitely not want to make it possible for some gang to take myself and however many other developers hostage in a co-ordinated attack just to force us to release an update to steal users' coins and quickly make those criminals tens of thousands of dollars if not more. There just isn't much other software out there that makes that kind of criminal act so directly profitable.

Yes, it requires people in multiple jurisdictions. As it happens we have developers spread around the world - one of the benefits of the open source model.

The assumption that no auto updates means better chance of detection is poor. Users run binaries, end of story. If they're having to manually download new versions themselves then a court can easily order you to adjust your server such that the correct binary is served to all users except for people connecting from the IP address known to be used by the guy they want to whack. The user will never even realise because users also don't check signatures themselves.

A good auto update scheme is if anything more robust, because it automates work users SHOULD do but in reality don't. If you have developers in jurisdictions that don't like each other (e.g. Russia and America) then it means if all parties co-operate, the chances that there's a legitimately good reason for it goes up a lot.

Anyway, it's easy to lose sight of the fact that obsolete and buggy versions are a much greater risk to 99.9% of all users than court-ordered software back doors.

1) Requires multiple developers in different jurisdictions.

2) Do you want to get yourself in a situation where your European counter-parts might find themselves unable to ever visit the US again? (or vice-versa) Myself I have family in two jurisdictions, and it's very expensive to avoid passing through the US to visit one of those jurisdictions.

It's better for everyone in this community if can honestly tell courts that any deceptive code snuck into the software we right is almost certainly going to be detected before it reaches the target, or at least after the fact. Not having auto-updates at all is a very effective way of achieving that, and if you must, use all the other measures I suggested.

Speaking of, in addition to my three suggestions, here's a fourth: Have updates happen by downloading the actual source-code to the client and either compiling it locally, or running it directly. (interpreted languages like Python make this really easy) This works particularly well with my suggestion of forcing the fact that an update has happened be made public by publishing that fact in the blockchain - for instance updates could be triggered by publishing a URL and SHA256 hash, making it likely that someone unrelated to the target will get that source-code, notice the court-mandated code, and tell the world. Meanwhile removing this feature will be suspicious in of itself.

That's the point of threshold signing. If the developers are spread across multiple jurisdictions, then the number of people who need to be court-ordered goes up, so a single rogue court or country can't start arbitrarily stealing money.

One nasty issue with auto-update is the unknown, but worrying, legal environment around court-ordered seizures. We've already seen one from of auto-update being used to seize funds when OzCoin was hacked and had 923BTC stolen and deposited in a StrongCoin wallet. The StrongCoin architecture is such that the operators of the service have no access to your private keys, however they were still able to seize the stolen funds themselves because the thief's webbrowser fetched a new copy of the JavaScript sourcecode, in effect auto-updating the software on demand. This modified code recognized the addresses the thief had placed the Bitcoins in, and the next time the thief used their wallet, thus decrypting the secret keys, a transaction was created by the modified code to return the funds to their original owners.

It is believed that StrongCoin did this freely, but we can't be sure - remember that in the the US and other countries courts have the ability to order you to take actions such as the above against your will, and you can be forced to stay remain silent about the fact that you have done so. (e.g. Lavabit)

By adding auto-update features to the their software wallet authors should recognize that they make it more likely for themselves to be forced into these very undesirable situations. You might be forced to lie to your users, even your family members and lawyers. (in the US a NSL court order can prevent you from discussing the fact that you've received such a court order or its contents with your lawyer)

Of course, not having an auto-update feature isn't a perfect solution either: it's easy to imagine being forced to add one so that a later version of your software can use the auto-update feature to recover funds or transaction history.

I wouldn't want to put myself in this situation, so I wouldn't include auto-update functionality at all. But if you do choose to do so anyway, you can mitigate the risk with threshhold signatures requiring the co-operation of multiple developers. You can also make sure that such deception will be at least noticed, especially deception where the modified client is only distributed to a subset of users, by having your software only accept updates if the fact that an update has occurred has been published in the Bitcoin blockchain. Also use deterministic builds, so that an update without corresponding source code is suspicious.

Finally you should take measures to ensure that users of your software can't be identified directly. StrongCoin was found because every StrongCoin transaction includes a small fee paid to the developers, a serious privacy breach. SPV clients however have another problem, which is that they reveal a great deal of version info to their peers, information that encourages entities to sybil the network to collect that information, for instance what was the version string of the SPV node that distributed a transaction. Given this risk wallets should always use a fixed version with the minimum possible information. If this practice does not catch on, use the version strings of other wallet software.

The right way to do auto-update of wallet software is threshold signing (i.e. a bunch of developers audit each others code by watching source control, reproduce each other builds, and cross-sign the binaries). I am not aware of any other apps that do all of these things together - we'd be breaking new ground by implementing it.

Until then I think auto update + being very very careful is better than simply pushing the responsibility onto the user, which is (as pointed out above) unreasonable because they can't tell the difference between a good and bad update.

I am no Bitcoin developper myself and have almost no experience with Mac OS X, so I wish I could be of a better help.

FWIW, Bitcoin-Qt developers seem to prefer using a slower / voluntary update system to reduce the risk of one developer being treatened to push a malicious update. So to some extend, it both protects users and developers (it might make more sense with Bitcoin-Qt due ot its very large users' base). On the other hand, fast updates rollout can be especially useful in emergency cases like the SecureRandom Android bug. Perhaps there's an interesting "in-between" here, to let a certain delay for a malicious update to be denounced before it causes too much damages, while not being too slow and inefficient.. Perhaps Mike have some experience here and can share some thoughts.

All in all, thank you very much for your work on Hive. I think a lot of people were waiting for it, and I'm glad you receive help with translations. I'll keep watching this thread and make a pull req to add Hive on bitcoin.org when it will be appropriate.

Sparkle does allow users to refuse updates, but unless the attacker was especially careless, the average user would never be able to tell the difference between a malicious update and a legitimate one anyway.

The truth is, we need more information. We've read about Evilgrade and other such exploits, but this is by no means an area of expertise of the present team. The benefits of auto-update are very great indeed, so let's figure this out together.


They are not clickable. There was a consideration for them to work as you describe, but then we read the same stuff you probably read and came to the same conclusions.


We couldn't agree more.


Perhaps you are right, but we are probably not going to blaze that particular trail ourselves. We feel that what we have provided is appropriate for the time being, but if patterns and best practices change, we will be right there with all of you.

Thanks for your interest and kind words, blockgenesis!

I would really like a beautiful Mac Os X app like this one to make it on bitcoin.org . Three questions:

Auto-update

Auto-update can be a controversial feature. I expressed the same reservation about Bitcoin Wallet for Android, as efficient update mechanisms can allow one developer to efficiently issue malicious updates ( it can be against their will ). So there's a similar level of trust needed here than with a centralized service.

So I was wondering if Sparkle allows users to refuse updates, or if everything is done in the background without user's consent. If you have some mechanisms that allow updates to be deployed progressively, etc.

In the worst case scenario, a little warning box similar to the one of blockchain.info & electrum could be used, so this isn't a blocking issue.

From addresses

I see that the GUI shows parts of the From: Bitcoin addresses. Are these "clickable"? Generally speaking, the consensus seems to be that allowing users to (easily) see and use "From addresses" doesn't make sense, as users shouldn't be tempted to send money to these addresses (and lose money if these addresses are no longer owned by anyone).

Testing / maturity

Perhaps it would be good to wait until Hive is stable, and has been used by many users for at least one month to be sure the app is working correctly? I think no other app or service on bitcoin.org has been pushed until it had some history behind it.

--

Also as a more general thought, while very friendly, I don't know if "address books" are likely to make sense in the future. In general, reusing addresses is discouraged both for privacy and security reasons. However, concretely, most wallets still have address books and generally are poorly designed to provide a friendly alternative. Perhaps that the future will only be "clickable / scannable / wireless" payment requests, or some kind of "deterministic changing addresses", or maybe some wallets will just keep using address books, I don't know.

vote for Linux 

Yeah, I tend to try and avoid constantly asking the user to make trivial technical decisions like that ... a good question to ask would be "why would I say no to this?". If you're worried about IP addresses and privacy, bear in mind, you don't have any reliable way to force a crash and the user downloaded the software from you anyway.

Yeah that would probably be better!

Rather than being 100% automatic, we were thinking about following Apple's pattern with a button-- "Send this to us". On the other hand, it's probably better for the quality of the software long-term to enforce the sending of logs. We could make it an enabled-by-default option that can be unticked in the preferences?

You definitely want to post such crash reports to your servers automatically.

An interesting proposition by Amir Taaki about merging Electrum, Hive and libbitcoin/obelisk:
https://bitcointalk.org/index.php?topic=322483.0;all