That seems overly complicated, there's no need for the Bitcoin protocol to be involved. Deterministic builds with threshold signed updates are a problem the entire crypto community is now interested in solving - any solution should be generic. Really all you need is an update engine that allows a CHECKMULTISIG type approach. When the update engine is not under our control, i.e. on Android, Shoup style RSA threshold signatures can potentially work (though I must admit, I have never found time to play with the implementation I have for that algorithm). On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman wrote: > I didn't know about the dedicated server meltdown, it wasn't any of my > infra. Anyway, my previous offer still stands. > > One less 'security theater' approach would be if we could provide > forward-validation of updates using the blockchain. It's always going to be > up to the user the first time they install the wallet to verify the > provenance of the binaries/source. From that point forward, we could make > it easier if the wallet could detect updates and prove they were valid. > > This could be as simple as hard-coding a public key into the client and > checking a signature on the new binaries. But it could also be more > interesting... > > For example, a well known address on the blockchain corresponds to > multi-sig with keys controlled by developers (or whatever key policy the > release team wants to impose). A spend from that address announces a new > release, and includes the expected hash of the file. > > You would probably need some way to handle the different release targets. > A more rigorous approach could identify all the various releases in terms > of a BIP32 xpubkey whose branches would correspond to the different release > trains and platform builds. Spends from a node announce the release and the > expected hash. > > This provides zero benefit if the wallet software is already compromised, > but I think this would allow trusted automatic update notification, and a > trusted way to deliver the expected hashes. It also might resolve some of > the consternation around when a release is truly "released", if that's > really a problem. > > I'm not sure how far along the slope you would want to go; 1) announcing > updates in the UI, 2) providing a button the user could click to verify a > binary matches its expected hash, 3) click to download and verify the > upgrade matches the expected hash, 4) click to upgrade > > Formalizing the release process around a set of privkeys (or split shares > of keys) may raise its own set of questions. > > For the download itself, I've heard the advocates of announcing > availability on the blockchain leading to a BitTorrent magnet link, but I > also understand objections to adding an entire BitTorrent stack into a > wallet. > > On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn wrote: > > The site was actually moved onto a dedicated server temporarily and it >> melted down under the load. I wouldn't call that no progress. >> > > Oh, it did? When was that? I must have missed this excitement :) > > Any idea how much load it had? > > Perhaps I wasn't clear on the point I was making Drak's threat model >> is not improved in the slightest by SSL. It would be improved by >> increasing the use of signature checking, e.g. by making it easier. >> > > Well, that depends. If you watch Applebaums talk he is pushing TLS pretty > hard, and saying that based on the access to the source docs some of their > MITM attacks can't beat TLS. It appears that they have the capability to do > bulk MITM and rewrite of downloads as Drak says but *not* when TLS is > present, that would force more targeted attacks. So to me that implies that > TLS does raise the bar and is worth doing. > > However if we can't find a server that won't melt under the load, then > that'd be an issue. We could consider hosting downloads on AppEngine or > something else that can handle both high load and TLS. > > > > >