Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.52 as permitted sender)
	client-ip=209.85.219.52; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f52.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CANEZrP2TNb8AjJzO78cdTX72vSVYR06xRR8QN5Lru_u0g_JawA@mail.gmail.com>
References: <CAKaEYhK5ZzP8scbhyzkEU+WdWjwMBDzkgF+SrC-Mdjgo9G9RnA@mail.gmail.com>
	<CACezXZ94oDX1O7y7cgh+HvDj4QiDWmy1NVQ4Ahq=gmzhgmUaHQ@mail.gmail.com>
	<CAKaEYhK4v3mhkGMKDW9g7km+5artBAjpukQdwx17psgdJaqvgA@mail.gmail.com>
	<CAHQs=o4pKBoVO-14dqoq9EoNxq2BNnKE+zmOjLBw+XqJfAp8yA@mail.gmail.com>
	<CAKaEYh+bePsmzM5XU1wpb_SFrTnbKB8LxMvWLLqP4p8KuesuSA@mail.gmail.com>
	<20130401225107.GU65880@giles.gnomon.org.uk>
	<20130401225417.GV65880@giles.gnomon.org.uk>
	<CA+s+GJBLUTfu8q2zE4pJ+HO5u-GweGNKZebV=XRhBe7TCPggPg@mail.gmail.com>
	<CA+8xBpcZtsZ=p30hJtqLTBJPEE3eD=gQ+x6bKy46z0hc8XNB1Q@mail.gmail.com>
	<CAD2Ti2-quRpfARLHw3riFpFihwYy2+R+4AW7Ovxq-W3qkzKptw@mail.gmail.com>
	<CABsx9T1EmYer-85zrEdC-N0uS_nnuGVgz0QcZ+ROrn51uPSNLQ@mail.gmail.com>
	<CAD2Ti2_54CfHS8oy=b3VQTqZMighmjfiaYFEqMB+Xou8Uamr9w@mail.gmail.com>
	<CAAS2fgT06RHBO_0stKQAYLPB39ZAzaCVduFZJROjSzXUP4Db+g@mail.gmail.com>
	<CAD2Ti28bdeGnhVe-i5-R54q6D082BVFjxVLCgvsSAjA+LQx2MA@mail.gmail.com>
	<CANEZrP2TNb8AjJzO78cdTX72vSVYR06xRR8QN5Lru_u0g_JawA@mail.gmail.com>
Date: Thu, 4 Apr 2013 11:04:22 +0100
Message-ID: <CANEZrP2d18OxL_Cu+gmixEmtqd4S=f5iGbPVaj3VKDZXdEymkw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: grarpamp <grarpamp@gmail.com>
Content-Type: multipart/alternative; boundary=089e0122789e3e560904d9861803
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] bitcoin pull requests
Precedence: list

--089e0122789e3e560904d9861803
Content-Type: text/plain; charset=UTF-8

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

--089e0122789e3e560904d9861803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">By the way, I have a download of the Bitcoin-Qt client and=
 signature verification running in a cron job.=C2=A0</div><div class=3D"gma=
il_extra"><br><br><div class=3D"gmail_quote">On Thu, Apr 4, 2013 at 10:11 A=
M, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net" targ=
et=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">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 d=
eveloper going rogue.</div>
<div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Apr 3=
, 2013 at 7:12 PM, grarpamp <span dir=3D"ltr">&lt;<a href=3D"mailto:grarpam=
p@gmail.com" target=3D"_blank">grarpamp@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

&gt; Users will have available multisig addresses which require<br>
&gt; transactions to be signed off by a wallet HSM. (E.g. a keyfob<br>
<br>
Hardware is a good thing. But only if you do the crypto in the<br>
hardware and trust the hardware and its attack models ;) For<br>
instance, the fingerprint readers you see everywhere... many<br>
of them just present the raw fingerprint scan to the host (and<br>
host software), instead of hashing the fingerprint internally and<br>
using that as primitive in crypto exchanges with the host. They<br>
cheaped out and/or didn&#39;t think. So oops, there went both your<br>
security (host replay) and your personal privacy (biometrics),<br>
outside of your control. All with no protection against physical<br>
fingerprint lifting.<br>
<br>
&gt; This doesn&#39;t remove the need to improve repository integrity. ... =
but<br>
&gt; repository integrity is a general problem that is applicable to many<b=
r>
&gt; things (after all, what does it matter if you can&#39;t compromise Bit=
coin<br>
&gt; if you can compromise boost, openssl, or gcc?)<br>
<br>
Yes, that case would matter zero to the end product. However<br>
having a strong repo permits better auditing of the BTC codebase.<br>
That&#39;s a good thing, and eliminates the need to talk chicken and<br>
egg.<br>
<br>
&gt; It&#39;s probably best<br>
&gt; that Bitcoin specalists stay focused on Bitcoin security measures, and=
<br>
&gt; other people interested in repository security come and help out<br>
&gt; improving it. =C2=A0An obvious area of improvement might be oddity<br>
&gt; detection and alerting: =C2=A0It&#39;s weird that I can rewrite histor=
y on<br>
&gt; github, so long as I do it quickly, without anyone noticing.<br>
<br>
If no one is verifying the repo, sure, even entire repos could be<br>
swapped out for seemingly identical ones.<br>
<br>
Many repos do not have any strong internal verification structures<br>
at all, and they run on filesystems that accept bitrot.<br>
Take a look at some OS&#39;s... OpenBSD and FreeBSD, supposedly<br>
the more secure ones out there... both use legacy repos on FFS.<br>
Seems rather ironic in the lol department.<br>
<br>
Thankfully some people out there are finally getting a clue on these<br>
issues, making and learning the tools, converting and migrating<br>
things, working on top down signed build and distribution chain, etc...<br>
so maybe in ten years the opensource world will be much farther<br>
ahead. Or at least have a strong audit trail.<br>
<div><div><br>
---------------------------------------------------------------------------=
---<br>
Minimize network downtime and maximize team effectiveness.<br>
Reduce network management and security costs.Learn how to hire<br>
the most talented Cisco Certified professionals. Visit the<br>
Employer Resources Portal<br>
<a href=3D"http://www.cisco.com/web/learning/employer_resources/index.html"=
 target=3D"_blank">http://www.cisco.com/web/learning/employer_resources/ind=
ex.html</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--089e0122789e3e560904d9861803--