From: Mike Hearn <mike@plan99.net>
To: grarpamp <grarpamp@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] bitcoin pull requests
Date: Thu, 4 Apr 2013 10:11:15 +0100 [thread overview]
Message-ID: <CANEZrP2TNb8AjJzO78cdTX72vSVYR06xRR8QN5Lru_u0g_JawA@mail.gmail.com> (raw)
In-Reply-To: <CAD2Ti28bdeGnhVe-i5-R54q6D082BVFjxVLCgvsSAjA+LQx2MA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3246 bytes --]
My general hope/vague plan for bitcoinj based wallets is to get them all on
to automatic updates with threshold signatures. Combined with regular
audits of the initial downloads for new users, that should give a pretty
safe result that is immune to a developer going rogue.
On Wed, Apr 3, 2013 at 7:12 PM, grarpamp <grarpamp@gmail.com> wrote:
> > Users will have available multisig addresses which require
> > transactions to be signed off by a wallet HSM. (E.g. a keyfob
>
> Hardware is a good thing. But only if you do the crypto in the
> hardware and trust the hardware and its attack models ;) For
> instance, the fingerprint readers you see everywhere... many
> of them just present the raw fingerprint scan to the host (and
> host software), instead of hashing the fingerprint internally and
> using that as primitive in crypto exchanges with the host. They
> cheaped out and/or didn't think. So oops, there went both your
> security (host replay) and your personal privacy (biometrics),
> outside of your control. All with no protection against physical
> fingerprint lifting.
>
> > This doesn't remove the need to improve repository integrity. ... but
> > repository integrity is a general problem that is applicable to many
> > things (after all, what does it matter if you can't compromise Bitcoin
> > if you can compromise boost, openssl, or gcc?)
>
> Yes, that case would matter zero to the end product. However
> having a strong repo permits better auditing of the BTC codebase.
> That's a good thing, and eliminates the need to talk chicken and
> egg.
>
> > It's probably best
> > that Bitcoin specalists stay focused on Bitcoin security measures, and
> > other people interested in repository security come and help out
> > improving it. An obvious area of improvement might be oddity
> > detection and alerting: It's weird that I can rewrite history on
> > github, so long as I do it quickly, without anyone noticing.
>
> If no one is verifying the repo, sure, even entire repos could be
> swapped out for seemingly identical ones.
>
> Many repos do not have any strong internal verification structures
> at all, and they run on filesystems that accept bitrot.
> Take a look at some OS's... OpenBSD and FreeBSD, supposedly
> the more secure ones out there... both use legacy repos on FFS.
> Seems rather ironic in the lol department.
>
> Thankfully some people out there are finally getting a clue on these
> issues, making and learning the tools, converting and migrating
> things, working on top down signed build and distribution chain, etc...
> so maybe in ten years the opensource world will be much farther
> ahead. Or at least have a strong audit trail.
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 4084 bytes --]
next prev parent reply other threads:[~2013-04-04 9:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-01 8:26 [Bitcoin-development] bitcoin pull requests Melvin Carvalho
2013-04-01 18:28 ` Petr Praus
2013-04-01 21:52 ` Melvin Carvalho
2013-04-01 22:10 ` Will
2013-04-01 22:27 ` Melvin Carvalho
2013-04-01 22:51 ` Roy Badami
2013-04-01 22:54 ` Roy Badami
2013-04-03 3:41 ` Wladimir
2013-04-03 3:51 ` Jeff Garzik
2013-04-03 15:52 ` grarpamp
2013-04-03 16:05 ` Gavin Andresen
2013-04-03 16:23 ` grarpamp
[not found] ` <CAAS2fgT06RHBO_0stKQAYLPB39ZAzaCVduFZJROjSzXUP4Db+g@mail.gmail.com>
2013-04-03 18:12 ` grarpamp
2013-04-04 9:11 ` Mike Hearn [this message]
2013-04-04 10:04 ` Mike Hearn
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=CANEZrP2TNb8AjJzO78cdTX72vSVYR06xRR8QN5Lru_u0g_JawA@mail.gmail.com \
--to=mike@plan99.net \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=grarpamp@gmail.com \
/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