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 11:04:22 +0100 [thread overview]
Message-ID: <CANEZrP2d18OxL_Cu+gmixEmtqd4S=f5iGbPVaj3VKDZXdEymkw@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP2TNb8AjJzO78cdTX72vSVYR06xRR8QN5Lru_u0g_JawA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]
By the way, I have a download of the Bitcoin-Qt client and signature
verification running in a cron job.
On Thu, Apr 4, 2013 at 10:11 AM, Mike Hearn <mike@plan99•net> wrote:
> 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: 4600 bytes --]
prev parent reply other threads:[~2013-04-04 10:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-01 8:26 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
2013-04-04 10:04 ` Mike Hearn [this message]
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='CANEZrP2d18OxL_Cu+gmixEmtqd4S=f5iGbPVaj3VKDZXdEymkw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=grarpamp@gmail$(echo .)com \
/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