From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y9a7e-0007Hy-Js for bitcoin-development@lists.sourceforge.net; Fri, 09 Jan 2015 14:01:06 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f53.google.com; Received: from mail-wg0-f53.google.com ([74.125.82.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y9a7d-0005kI-OD for bitcoin-development@lists.sourceforge.net; Fri, 09 Jan 2015 14:01:06 +0000 Received: by mail-wg0-f53.google.com with SMTP id x13so8262733wgg.12 for ; Fri, 09 Jan 2015 06:00:59 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.82.98 with SMTP id h2mr5420507wiy.7.1420812059253; Fri, 09 Jan 2015 06:00:59 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Fri, 9 Jan 2015 06:00:59 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Jan 2015 15:00:59 +0100 X-Google-Sender-Auth: zkvVHyvavhvaOz3s9Iqate5ziv8 Message-ID: From: Mike Hearn To: 21E14 <21xe14@gmail.com> Content-Type: multipart/alternative; boundary=f46d044283ec15c18d050c3896bf X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Y9a7d-0005kI-OD Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] A look back and a look forward X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:01:06 -0000 --f46d044283ec15c18d050c3896bf Content-Type: text/plain; charset=UTF-8 > > This needn't be so, once an optional identity layer, modeled after the > Internet itself, is provided, as proposed in late August of last year on > this mailing list > I think the observation about Target vs Bitcoin exchanges is a sharp one, but I'm not sure how your proposal helps. You say it's an optional identity layer, but obviously any thief is going to opt out of being identified. For things like the Bitstamp hack, it's not clear how identity can help, because they were already doing KYC for all their customers. To take that further at the protocol level would require* all* transactions to have attached identity info, and that isn't going to happen - it wouldn't be Bitcoin, at that point. I think that long term, it's probably possible to defend private keys adequately, even for large sums of money (maybe not bitstamp-large but we'll see). You can have very minimalist secure hardware that would have some additional policies on top, like refusing to sign transactions without an identity proof of who controls the target address. Very tight hot wallets that risk analyse the instructions they're receiving have been proposed years ago. No such hardware presently exists, but that's mostly because implementations always lag behind a long way behind ideas rather than any fundamental technical bottleneck. Perhaps the Bitstamp event will finally spur development of such things forward. --f46d044283ec15c18d050c3896bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This needn't be so, once an= optional identity layer, modeled after the Internet itself, is provided, a= s proposed in late August of last year on this mailing list

I think the observation about Target vs Bitcoin exch= anges is a sharp one, but I'm not sure how your proposal helps. You say= it's an optional identity layer, but obviously any thief is going to o= pt out of being identified.

For things like the Bi= tstamp hack, it's not clear how identity can help, because they were al= ready doing KYC for all their customers. To take that further at the protoc= ol level would require=C2=A0all=C2=A0transactions to have attached i= dentity info, and that isn't going to happen - it wouldn't be Bitco= in, at that point.

I think that long term, it'= s probably possible to defend private keys adequately, even for large sums = of money (maybe not bitstamp-large but we'll see). You can have very mi= nimalist secure hardware that would have some additional policies on top, l= ike refusing to sign transactions without an identity proof of who controls= the target address. Very tight hot wallets that risk analyse the instructi= ons they're receiving have been proposed years ago.=C2=A0
No such hardware presently exists, but that's mostly becaus= e implementations always lag behind a long way behind ideas rather than any= fundamental technical bottleneck. Perhaps the Bitstamp event will finally = spur development of such things forward.
--f46d044283ec15c18d050c3896bf--