[Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

Matt Corallo bitcoin-list at bluematt.me
Tue Dec 31 21:33:54 UTC 2013

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.

Jeremy Spilman <jeremy at 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
>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
>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  
>For example, a well known address on the blockchain corresponds to  
>multi-sig with keys controlled by developers (or whatever key policy
>release team wants to impose). A spend from that address announces a
>release, and includes the expected hash of the file.
>You would probably need some way to handle the different release
>A more rigorous approach could identify all the various releases in
>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
>but I think this would allow trusted automatic update notification, and
>trusted way to deliver the expected hashes. It also might resolve some
>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)
>updates in the UI, 2) providing a button the user could click to verify
>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
>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
>also understand objections to adding an entire BitTorrent stack into a 
>On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike at plan99.net> wrote:
>>> The site was actually moved onto a dedicated server temporarily and
>>> 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
>> 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.
>> 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,
>> that'd be an issue. We could consider hosting downloads on AppEngine
>> >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
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>AppDynamics Pro!
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131231/eaa34c28/attachment.html>

More information about the bitcoin-dev mailing list