From: "Jeremy Spilman" <jeremy@taplink•co>
To: "Gregory Maxwell" <gmaxwell@gmail•com>, "Mike Hearn" <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Date: Tue, 31 Dec 2013 13:25:40 -0800 [thread overview]
Message-ID: <op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.net> (raw)
In-Reply-To: <CANEZrP1mdJNa7ADkUXTGDNKMSCROjGAVbMXZXxodxCz1LFDzZw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]
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 <mike@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.
[-- Attachment #2.1: Type: text/html, Size: 4217 bytes --]
next prev parent reply other threads:[~2013-12-31 21:26 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-08 1:17 Saïvann Carignan
2013-12-08 3:38 ` Odinn Cyberguerrilla
2013-12-08 9:03 ` Saïvann Carignan
2013-12-08 12:37 ` Luke-Jr
2013-12-08 19:16 ` Drak
2013-12-08 19:25 ` Gregory Maxwell
2013-12-08 20:28 ` Mike Hearn
2013-12-08 20:40 ` Gregory Maxwell
2013-12-08 20:51 ` Drak
2013-12-08 21:01 ` Luke-Jr
2013-12-08 21:11 ` Drak
2013-12-08 23:51 ` theymos
2013-12-09 0:06 ` Taylor Gerring
2013-12-09 6:29 ` Jeremy Spilman
2013-12-09 10:54 ` Roy Badami
2013-12-10 9:18 ` Odinn Cyberguerrilla
2013-12-08 21:09 ` Gregory Maxwell
2013-12-08 21:16 ` Saïvann Carignan
2013-12-08 21:58 ` Roy Badami
2013-12-08 23:03 ` Mike Hearn
2013-12-09 5:32 ` Jeff Garzik
2013-12-08 22:44 ` Gavin Andresen
2013-12-08 23:48 ` Saïvann Carignan
2013-12-08 23:18 ` Luke-Jr
2013-12-08 23:29 ` Patrick
2013-12-08 21:46 ` Mark Friedenbach
2013-12-08 20:40 ` Drak
2013-12-08 20:50 ` Gregory Maxwell
2013-12-08 21:07 ` Drak
2013-12-08 21:14 ` Gregory Maxwell
2013-12-08 22:27 ` Robert McKay
2013-12-12 20:51 ` Adam Back
2013-12-31 13:39 ` Drak
2013-12-31 13:48 ` Gregory Maxwell
2013-12-31 13:59 ` Mike Hearn
2013-12-31 14:18 ` Gregory Maxwell
2013-12-31 14:23 ` Mike Hearn
2013-12-31 21:25 ` Jeremy Spilman [this message]
2013-12-31 21:33 ` Matt Corallo
2014-01-01 10:02 ` Jeremy Spilman
2014-01-01 11:37 ` Wladimir
2014-01-01 15:10 ` Mike Hearn
2014-01-01 22:15 ` Mike Hearn
2014-01-02 19:49 ` Jorge Timón
2013-12-31 14:05 ` Benjamin Cordes
2014-01-03 5:45 ` Troy Benjegerdes
2014-01-03 9:59 ` Drak
2014-01-03 11:22 ` Tier Nolan
2014-01-03 13:09 ` Adam Back
2014-01-03 17:38 ` Troy Benjegerdes
2014-01-03 18:21 ` Jorge Timón
2014-01-04 1:43 ` Troy Benjegerdes
2013-12-08 10:00 ` Drak
2013-12-08 12:39 ` Luke-Jr
2013-12-08 16:51 ` Gregory Maxwell
2013-12-08 16:08 ` Wladimir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.net \
--to=jeremy@taplink$(echo .)co \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox