Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
So I looked into gitian, the first thing I noticed was the hashes that people were signing, for example: https://github.com/bitcoin/gitian.sigs/blob/master/0.8.6-win32/gavinandresen/bitcoin-build.assert don't match the hash of the file 'bitcoin-0.8.6-win32-setup.exe' actually hosted by sourceforce. That was a bit alarming at first, but I talked to BlueMatt and maaku on IRC and the difference is due to Gavin Authenticode signing the executable for windows. BlueMatt asked if someone could implement in gitian-downloader a way to strip off the signature so that we could get back to the raw binary with a hash that matches what everyone is producing from gitian. I found: http://blog.didierstevens.com/programs/disitool/ which is a Python script which can strip the signature nicely, but the hashes still don't match. I couldn't find a gitian build of 0.8.6 so I built my own, and after verifying the hash for v0.8.6 was '49547ff9...' as expected I looked at the hex diff between that and the sig-stripped .exe from sourceforge, and the only two differences are: - At offset D8 the stripped file has '5D E2 B2' versus 'F9 F4 00' in the gitian build - The sig-stripped file has an extra byte '00' at the end I started to look at the file spec for windows PE files and quickly thought better of it. Maybe someone better informed can chime in on what those three bytes at offset D8 specify. I'm not sure if we want to patch the signature onto the gitian build, or strip the signature off of the Gavin-signed build, but something of the sort is necessary if you want get gitian-downloader to match the official distro (for Windows at least). In any case, I think wallet users want to know when an upgrade is available, and ability to click an 'update' button get a binary they can trust. It's not a problem unique to bitcoind, deterministic builds are awesome, but I don't think fully solve it. Thanks, Jeremy On Tue, 31 Dec 2013 13:33:54 -0800, Matt Corallo bitcoin-l...@bluematt.me wrote: We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
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 jer...@taplink.co 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 m...@plan99.net 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. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Happy new year!
Same here. I feel incredibly lucky to know some of you, and to be able to contribute in some small way to what this is ultimately becoming. It's been an amazing ride, and I'm pretty sure that 2014 is going to totally blow our minds. -wendell hivewallet.com | twitter.com/hivewallet | pgp: B7179FA88C498718 On Jan 1, 2014, at 1:33 PM, Mike Hearn wrote: Bitcoin had an incredible year in 2013, and I very much enjoyed working with and meeting you all. I'm very much looking forward to some of the upgrades coming in 2014. Though a lot happened in the general community, last year was kind of quiet with respect to the core software. I'm hoping this year we can pick up the pace a little. Cheers! -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Oh, it did? When was that? I must have missed this excitement :) I would be very interested to learn more about this. It seems the steady state load on the site is not very high: https://github.com/bitcoin/bitcoin.org/pull/287 (Saivann ran Google Analytics on the site for a little while to get traffic figures). Peak of 10 visitors per second, assume a 10x blowup on resources, that's only ~100 reqs/sec steady state, that shouldn't strain any kind of reasonable server. So perhaps the specs of the dedicated server were not what you might imagine. Perhaps we should move the site over to Jeremy's hosting? It shouldn't be very expensive to serve outside of major press cycles. Once that is done, perhaps we can find/blag some SSL-protected file hosting. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
