Re: [Bitcoin-development] bitcoin pull requests

[Mike Hearn <mike@plan99.net>]

[-- 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 --]