public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Date: Wed, 1 Jan 2014 15:10:05 +0000	[thread overview]
Message-ID: <CANEZrP3DmATBpi_SNS2R98R2Lf3cfuYK3dE_6yCwTL-MgYpHLg@mail.gmail.com> (raw)
In-Reply-To: <op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.net>

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

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 <jeremy@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 <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: Type: text/html, Size: 5246 bytes --]

  parent reply	other threads:[~2014-01-01 15:10 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-08  1:17 [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts? 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
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 [this message]
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=CANEZrP3DmATBpi_SNS2R98R2Lf3cfuYK3dE_6yCwTL-MgYpHLg@mail.gmail.com \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jeremy@taplink.co \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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