path: root/f0/971805dd4d8709e867c7b3c06214abfb2972d0

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 <chris.dcosta@meek.io>) id 1WV78y-00027V-RV
	for bitcoin-development@lists.sourceforge.net;
	Tue, 01 Apr 2014 22:26:56 +0000
X-ACL-Warn: 
Received: from relay6-d.mail.gandi.net ([217.70.183.198])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1WV78w-0006u6-Bz
	for bitcoin-development@lists.sourceforge.net;
	Tue, 01 Apr 2014 22:26:56 +0000
Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146])
	by relay6-d.mail.gandi.net (Postfix) with ESMTP id 0319BFB882;
	Wed,  2 Apr 2014 00:26:48 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net
Received: from relay6-d.mail.gandi.net ([217.70.183.198])
	by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id u7xxrHpcRY18; Wed,  2 Apr 2014 00:26:45 +0200 (CEST)
X-Originating-IP: 94.224.236.133
Received: from [192.168.1.102] (94-224-236-133.access.telenet.be
	[94.224.236.133]) (Authenticated sender: chris.dcosta@meek.io)
	by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 44338FB881;
	Wed,  2 Apr 2014 00:26:45 +0200 (CEST)
References: <5339418F.1050800@riseup.net>
	<51C10069-5C3B-462A-9184-669ABC6CD9D0@meek.io>
	<CAJHLa0MfV0RnVh1niG4vUGUUvB_Vd8HccTys4bf1ApnwuBUd1g@mail.gmail.com>
	<C818247C-6422-4F55-A324-826EC5C6A455@meek.io>
	<CAHbi5CzOTejUQcaF4Ja45=609A811OvSonE0vXpTuPKSh+5hVA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAHbi5CzOTejUQcaF4Ja45=609A811OvSonE0vXpTuPKSh+5hVA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary=Apple-Mail-6C4A8019-0B52-45DA-B377-877DF3F5F161
Content-Transfer-Encoding: 7bit
Message-Id: <8ACA8DF1-30BF-47F4-92CE-E625F44F687C@meek.io>
X-Mailer: iPhone Mail (11B651)
From: Chris D'Costa <chris.dcosta@meek.io>
Date: Wed, 2 Apr 2014 00:26:42 +0200
To: Daryl Banttari <dbanttari@gmail.com>
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
X-Headers-End: 1WV78w-0006u6-Bz
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] secure assigned bitcoin address directory
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 01 Apr 2014 22:26:57 -0000


--Apple-Mail-6C4A8019-0B52-45DA-B377-877DF3F5F161
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Daryl

I think the two issues with this are
1) pay to addresses are not fixed - ie you can have a different address for e=
ach transaction (which is why BIP70 is necessary to allow per transaction ad=
dresses via https.)
2) unless you are already aware of the  public key of the signature, you do n=
ot know if the signature is made by the person you think it is supposed to b=
e from. See recent concern over fake key for Gavin Andresen. Ie a signature c=
an always be verified with a valid public key, the question is was it the re=
al person's key. That is what WoT tried to resolve with so-called "signing p=
arties", nowadays keys posted to a public forum by a known user, but it's no=
t a standard and not ideal.



Regards

Chris D'Costa


Sent from my iPhone

> On 1 Apr 2014, at 20:16, Daryl Banttari <dbanttari@gmail.com> wrote:
>=20
> I posted some code on Reddit a while back around adding a simple x509 digi=
tal signature to a Bitcoin address URL, since you could gain the benefit of a=
n x.509 authenticated Bitcoin address without having to do a full BIP70 impl=
ementation.  It's not WoT, but x509, for all its flaws, works very well in t=
he real world almost all of the time.
>=20
> For added authentication, one could always wrap the URL with a PGP signatu=
re.
>=20
> After lurking on this list for a while, I assumed there's some reason this=
 hasn't already been implemented, likely based in the general disgust around=
 x509.
>=20
> Anyway, here's my idea (complete with working Java source):
>=20
> http://www.reddit.com/r/BitcoinSerious/comments/1sebj0/proposal_bitcoin_in=
voice_signatures/
>=20
> FWIW.
>=20
> --Daryl
>=20
>=20
>=20
>> On Tue, Apr 1, 2014 at 7:20 AM, Chris D'Costa <chris.dcosta@meek.io> wrot=
e:
>> The code will be available as soon as we are ready, and apologies again f=
or it not being a more meaningful conversation - I did say I hesitated about=
 posting it ;)
>>=20
>> I think it is fair to say that we have not assumed anything about other t=
echnologies, without asking if they can answer all (not just some) of the qu=
estions I raised. I have yet to be convinced that anything existing meets th=
ose requirements, namecoin included, hence why we are looking at creating an=
 alternative (non-coin by the way) but this alternative has some  of the imp=
ortant properties that the distributed ledger provides.
>>=20
>> To answer the question about expiry, we're looking at something we'll cal=
l proof-of-life for the device keys. In a nutshell on of the pieces of infor=
mation stored with the device public key will be a last heard from date - a d=
ate which is sent only by the device from time to time. Records that are exp=
ired are devices that have not been heard from for a given period (to be dec=
ided). As the device keys are not related to the Bitcoin keys it will be saf=
e to expire a device key by default. An expired device would require reiniti=
alisation, which would make a new device key set, a new proof of life date a=
nd then the Bitcoin keys (BIP32) can be restored.
>>=20
>>=20
>>=20
>> Regards
>>=20
>> Chris D'Costa
>>=20
>> Sent from my iPhone
>>=20
>> > On 1 Apr 2014, at 13:32, Jeff Garzik <jgarzik@bitpay.com> wrote:
>> >
>> > Re-reading this, even with the most recent message, is still isn't
>> > clear _precisely_ how your technology works, or why it is better than
>> > namecoin.  User profiles (and distributed ledgers) need to reflect the
>> > latest updates, and a stream of updates of over time is precisely what
>> > bitcoin technology secures.
>> >
>> > Keys expire or are compromised, and the public ledger needs to reflect
>> > that.  There is a lot of computer science involved in making sure the
>> > public ledger you see is not an outdated view.  A log-like stream of
>> > changes is not the only way to do things, but other methods need less
>> > hand-wavy details (show the code) before they are well recognized as
>> > useful.
>> >
>> >
>> >
>> >> On Mon, Mar 31, 2014 at 7:14 AM, Chris D'Costa <chris.dcosta@meek.io> w=
rote:
>> >> Security of transmission of person-to-person pay-to addresses is one o=
f the use cases that we are addressing on our hardware wallet.
>> >>
>> >> I have yet to finish the paper but in a nutshell it uses a decentralis=
ed ledger of, what we refer to as, "device keys".
>> >>
>> >> These keys are not related in any way to the Bitcoin keys, (which is w=
hy I'm hesitating about discussing it here) neither do they even attempt to i=
dentify the human owner if the device. But they do have a specific use case a=
nd that is to provide "advanced knowledge" of a publickey that can be used f=
or encrypting a message to an intended recipient, without the requirement fo=
r a third-party CA, and more importantly without prior dialogue. We think it=
 is this that would allow you to communicate a pay-to address to someone wit=
hout seeing them in a secure way.
>> >>
>> >> As I understand it the BlockChain uses "time" bought through proof of w=
ork to establish a version of the truth, we are using time in the reverse se=
nse : advanced knowledge of all pubkeys. Indeed all devices could easily che=
ck their own record to identify problems on the ledger.
>> >>
>> >> There is of course more to this, but I like to refer to the "distribut=
ed ledger of device keys" as the "Web-of-trust re-imagined" although that is=
n't strictly true.
>> >>
>> >> Ok there you have it. The cat is out of the bag, feel free to give fee=
dback, I have to finish the paper, apologies if it is not a topic for this l=
ist.
>> >>
>> >> Regards
>> >>
>> >> Chris D'Costa
>> >>
>> >>
>> >>> On 31 Mar 2014, at 12:21, vv01f <vv01f@riseup.net> wrote:
>> >>>
>> >>> Some users on bitcointalk[0] would like to have their vanity addresse=
s
>> >>> available for others easily to find and verify the ownership over a k=
ind
>> >>> of WoT. Right now they sign their own addresses and quote them in the=

>> >>> forums.
>> >>> As I pointed out there already the centralized storage in the forums i=
s
>> >>> not secury anyhow and signed messages could be swapped easily with th=
e
>> >>> next hack of the forums.
>> >>>
>> >>> Is that use case taken care of in any plans already?
>> >>>
>> >>> I thought about abusing pgp keyservers but that would suit for single=

>> >>> vanity addresses only.
>> >>> It seems webfinger could be part of a solution where servers of a
>> >>> business can tell and proof you if a specific address is owned by the=
m.
>> >>>
>> >>> [0] https://bitcointalk.org/index.php?topic=3D502538
>> >>> [1] https://bitcointalk.org/index.php?topic=3D505095
>> >>>
>> >>> ---------------------------------------------------------------------=
---------
>> >>> _______________________________________________
>> >>> Bitcoin-development mailing list
>> >>> Bitcoin-development@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>
>> >> ----------------------------------------------------------------------=
--------
>> >> _______________________________________________
>> >> Bitcoin-development mailing list
>> >> Bitcoin-development@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>> >
>> >
>> > --
>> > Jeff Garzik
>> > Bitcoin core developer and open source evangelist
>> > BitPay, Inc.      https://bitpay.com/
>>=20
>> -------------------------------------------------------------------------=
-----
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
> --------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--Apple-Mail-6C4A8019-0B52-45DA-B377-877DF3F5F161
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Hi Daryl</div><div><br></div><div>I th=
ink the two issues with this are</div><div>1) pay to addresses are not fixed=
 - ie you can have a different address for each transaction (which is why BI=
P70 is necessary to allow per transaction addresses via https.)</div><div>2)=
 unless you are already aware of the &nbsp;public key of the signature, you d=
o not know if the signature is made by the person you think it is supposed t=
o be from. See recent concern over fake key for Gavin Andresen. Ie a signatu=
re can always be verified with a valid public key, the question is was it th=
e real person's key. That is what WoT tried to resolve with so-called "signi=
ng parties", nowadays keys posted to a public forum by a known user, but it'=
s not a standard and not ideal.</div><div><br></div><div><br><br>Regards<div=
><br><div>Chris D'Costa</div><div><br></div><div><br></div><div>Sent from my=
 iPhone</div></div></div><div><br>On 1 Apr 2014, at 20:16, Daryl Banttari &l=
t;<a href=3D"mailto:dbanttari@gmail.com">dbanttari@gmail.com</a>&gt; wrote:<=
br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div><div><div>=
I posted some code on Reddit a while back around adding a simple x509 digita=
l signature to a Bitcoin address URL, since you could gain the benefit of an=
 x.509 authenticated Bitcoin address without having to do a full BIP70 imple=
mentation.&nbsp; It's not WoT, but x509, for all its flaws, works very well i=
n the real world almost all of the time.<br>

<br></div><div>For added authentication, one could always wrap the URL with a=
 PGP signature.<br></div><div><br>After lurking on this list for a while, I a=
ssumed there's some reason this hasn't already been implemented, likely base=
d in the general disgust around x509.<br>

<br></div><div>Anyway, here's my idea (complete with working Java source):<b=
r></div><div><br></div><a href=3D"http://www.reddit.com/r/BitcoinSerious/com=
ments/1sebj0/proposal_bitcoin_invoice_signatures/">http://www.reddit.com/r/B=
itcoinSerious/comments/1sebj0/proposal_bitcoin_invoice_signatures/</a><br>

</div><br></div><div>FWIW.<br></div><div><br></div>--Daryl<br><div><br></div=
></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
 Apr 1, 2014 at 7:20 AM, Chris D'Costa <span dir=3D"ltr">&lt;<a href=3D"mail=
to:chris.dcosta@meek.io" target=3D"_blank">chris.dcosta@meek.io</a>&gt;</spa=
n> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">The code will be available as soon as we are r=
eady, and apologies again for it not being a more meaningful conversation - I=
 did say I hesitated about posting it ;)<br>


<br>
I think it is fair to say that we have not assumed anything about other tech=
nologies, without asking if they can answer all (not just some) of the quest=
ions I raised. I have yet to be convinced that anything existing meets those=
 requirements, namecoin included, hence why we are looking at creating an al=
ternative (non-coin by the way) but this alternative has some &nbsp;of the i=
mportant properties that the distributed ledger provides.<br>


<br>
To answer the question about expiry, we're looking at something we'll call p=
roof-of-life for the device keys. In a nutshell on of the pieces of informat=
ion stored with the device public key will be a last heard from date - a dat=
e which is sent only by the device from time to time. Records that are expir=
ed are devices that have not been heard from for a given period (to be decid=
ed). As the device keys are not related to the Bitcoin keys it will be safe t=
o expire a device key by default. An expired device would require reinitiali=
sation, which would make a new device key set, a new proof of life date and t=
hen the Bitcoin keys (BIP32) can be restored.<br>


<br>
<br>
<br>
Regards<br>
<br>
Chris D'Costa<br>
<br>
Sent from my iPhone<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On 1 Apr 2014, at 13:32, Jeff Garzik &lt;<a href=3D"mailto:jgarzik@bitp=
ay.com">jgarzik@bitpay.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Re-reading this, even with the most recent message, is still isn't<br>
&gt; clear _precisely_ how your technology works, or why it is better than<b=
r>
&gt; namecoin. &nbsp;User profiles (and distributed ledgers) need to reflect=
 the<br>
&gt; latest updates, and a stream of updates of over time is precisely what<=
br>
&gt; bitcoin technology secures.<br>
&gt;<br>
&gt; Keys expire or are compromised, and the public ledger needs to reflect<=
br>
&gt; that. &nbsp;There is a lot of computer science involved in making sure t=
he<br>
&gt; public ledger you see is not an outdated view. &nbsp;A log-like stream o=
f<br>
&gt; changes is not the only way to do things, but other methods need less<b=
r>
&gt; hand-wavy details (show the code) before they are well recognized as<br=
>
&gt; useful.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt; On Mon, Mar 31, 2014 at 7:14 AM, Chris D'Costa &lt;<a href=3D"mailt=
o:chris.dcosta@meek.io">chris.dcosta@meek.io</a>&gt; wrote:<br>
&gt;&gt; Security of transmission of person-to-person pay-to addresses is on=
e of the use cases that we are addressing on our hardware wallet.<br>
&gt;&gt;<br>
&gt;&gt; I have yet to finish the paper but in a nutshell it uses a decentra=
lised ledger of, what we refer to as, "device keys".<br>
&gt;&gt;<br>
&gt;&gt; These keys are not related in any way to the Bitcoin keys, (which i=
s why I'm hesitating about discussing it here) neither do they even attempt t=
o identify the human owner if the device. But they do have a specific use ca=
se and that is to provide "advanced knowledge" of a publickey that can be us=
ed for encrypting a message to an intended recipient, without the requiremen=
t for a third-party CA, and more importantly without prior dialogue. We thin=
k it is this that would allow you to communicate a pay-to address to someone=
 without seeing them in a secure way.<br>


&gt;&gt;<br>
&gt;&gt; As I understand it the BlockChain uses "time" bought through proof o=
f work to establish a version of the truth, we are using time in the reverse=
 sense : advanced knowledge of all pubkeys. Indeed all devices could easily c=
heck their own record to identify problems on the ledger.<br>


&gt;&gt;<br>
&gt;&gt; There is of course more to this, but I like to refer to the "distri=
buted ledger of device keys" as the "Web-of-trust re-imagined" although that=
 isn't strictly true.<br>
&gt;&gt;<br>
&gt;&gt; Ok there you have it. The cat is out of the bag, feel free to give f=
eedback, I have to finish the paper, apologies if it is not a topic for this=
 list.<br>
&gt;&gt;<br>
&gt;&gt; Regards<br>
&gt;&gt;<br>
&gt;&gt; Chris D'Costa<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; On 31 Mar 2014, at 12:21, vv01f &lt;<a href=3D"mailto:vv01f@ris=
eup.net">vv01f@riseup.net</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Some users on bitcointalk[0] would like to have their vanity ad=
dresses<br>
&gt;&gt;&gt; available for others easily to find and verify the ownership ov=
er a kind<br>
&gt;&gt;&gt; of WoT. Right now they sign their own addresses and quote them i=
n the<br>
&gt;&gt;&gt; forums.<br>
&gt;&gt;&gt; As I pointed out there already the centralized storage in the f=
orums is<br>
&gt;&gt;&gt; not secury anyhow and signed messages could be swapped easily w=
ith the<br>
&gt;&gt;&gt; next hack of the forums.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Is that use case taken care of in any plans already?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I thought about abusing pgp keyservers but that would suit for s=
ingle<br>
&gt;&gt;&gt; vanity addresses only.<br>
&gt;&gt;&gt; It seems webfinger could be part of a solution where servers of=
 a<br>
&gt;&gt;&gt; business can tell and proof you if a specific address is owned b=
y them.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [0] <a href=3D"https://bitcointalk.org/index.php?topic=3D502538=
" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D502538</a><br>=

&gt;&gt;&gt; [1] <a href=3D"https://bitcointalk.org/index.php?topic=3D505095=
" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D505095</a><br>=

&gt;&gt;&gt;<br>
&gt;&gt;&gt; ---------------------------------------------------------------=
---------------<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; Bitcoin-development mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bi=
tcoin-development@lists.sourceforge.net</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin=
-development" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo=
/bitcoin-development</a><br>
&gt;&gt;<br>
&gt;&gt; -------------------------------------------------------------------=
-----------<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Bitcoin-development mailing list<br>
&gt;&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoi=
n-development@lists.sourceforge.net</a><br>
&gt;&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-dev=
elopment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bit=
coin-development</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Jeff Garzik<br>
&gt; Bitcoin core developer and open source evangelist<br>
&gt; BitPay, Inc. &nbsp; &nbsp; &nbsp;<a href=3D"https://bitpay.com/" target=
=3D"_blank">https://bitpay.com/</a><br>
<br>
----------------------------------------------------------------------------=
--<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develop=
ment@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-deve=
lopment</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type=3D"cite"><div><span>--------------------=
----------------------------------------------------------</span><br></div><=
/blockquote><blockquote type=3D"cite"><div><span>___________________________=
____________________</span><br><span>Bitcoin-development mailing list</span>=
<br><span><a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitco=
in-development@lists.sourceforge.net</a></span><br><span><a href=3D"https://=
lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sour=
ceforge.net/lists/listinfo/bitcoin-development</a></span><br></div></blockqu=
ote></body></html>=

--Apple-Mail-6C4A8019-0B52-45DA-B377-877DF3F5F161--