path: root/e8/9cca32493152f1ad3a9676d64d9b713b59281a

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <dbanttari@gmail.com>) id 1WV3Ez-0008NM-Cj
	for bitcoin-development@lists.sourceforge.net;
	Tue, 01 Apr 2014 18:16:53 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.169 as permitted sender)
	client-ip=209.85.214.169; envelope-from=dbanttari@gmail.com;
	helo=mail-ob0-f169.google.com; 
Received: from mail-ob0-f169.google.com ([209.85.214.169])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WV3Ex-00005A-MD
	for bitcoin-development@lists.sourceforge.net;
	Tue, 01 Apr 2014 18:16:53 +0000
Received: by mail-ob0-f169.google.com with SMTP id va2so11552358obc.28
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 01 Apr 2014 11:16:46 -0700 (PDT)
X-Received: by 10.182.28.7 with SMTP id x7mr10302558obg.43.1396376206172; Tue,
	01 Apr 2014 11:16:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.210.130 with HTTP; Tue, 1 Apr 2014 11:16:26 -0700 (PDT)
In-Reply-To: <C818247C-6422-4F55-A324-826EC5C6A455@meek.io>
References: <5339418F.1050800@riseup.net>
	<51C10069-5C3B-462A-9184-669ABC6CD9D0@meek.io>
	<CAJHLa0MfV0RnVh1niG4vUGUUvB_Vd8HccTys4bf1ApnwuBUd1g@mail.gmail.com>
	<C818247C-6422-4F55-A324-826EC5C6A455@meek.io>
From: Daryl Banttari <dbanttari@gmail.com>
Date: Tue, 1 Apr 2014 13:16:26 -0500
Message-ID: <CAHbi5CzOTejUQcaF4Ja45=609A811OvSonE0vXpTuPKSh+5hVA@mail.gmail.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e015380babe0b9904f5ff2bf7
X-Spam-Score: -0.6 (/)
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
	(dbanttari[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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
X-Headers-End: 1WV3Ex-00005A-MD
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 18:16:53 -0000

--089e015380babe0b9904f5ff2bf7
Content-Type: text/plain; charset=ISO-8859-1

I posted some code on Reddit a while back around adding a simple x509
digital 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 implementation.  It's not WoT, but x509, for all its flaws,
works very well in the real world almost all of the time.

For added authentication, one could always wrap the URL with a PGP
signature.

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.

Anyway, here's my idea (complete with working Java source):

http://www.reddit.com/r/BitcoinSerious/comments/1sebj0/proposal_bitcoin_invoice_signatures/

FWIW.

--Daryl



On Tue, Apr 1, 2014 at 7:20 AM, Chris D'Costa <chris.dcosta@meek.io> wrote:

> The code will be available as soon as we are ready, and apologies again
> for it not being a more meaningful conversation - I did say I hesitated
> about posting it ;)
>
> I think it is fair to say that we have not assumed anything about other
> technologies, without asking if they can answer all (not just some) of the
> questions I raised. I have yet to be convinced that anything existing meets
> those requirements, namecoin included, hence why we are looking at creating
> an alternative (non-coin by the way) but this alternative has some  of the
> important properties that the distributed ledger provides.
>
> To answer the question about expiry, we're looking at something we'll call
> proof-of-life for the device keys. In a nutshell on of the pieces of
> information stored with the device public key will be a last heard from
> date - a date which is sent only by the device from time to time. Records
> that are expired are devices that have not been heard from for a given
> period (to be decided). As the device keys are not related to the Bitcoin
> keys it will be safe to expire a device key by default. An expired device
> would require reinitialisation, which would make a new device key set, a
> new proof of life date and then the Bitcoin keys (BIP32) can be restored.
>
>
>
> Regards
>
> Chris D'Costa
>
> Sent from my iPhone
>
> > 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>
> wrote:
> >> Security of transmission of person-to-person pay-to addresses is one of
> 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
> decentralised ledger of, what we refer to as, "device keys".
> >>
> >> These keys are not related in any way to the Bitcoin keys, (which is
> why I'm hesitating about discussing it here) neither do they even attempt
> to identify the human owner if the device. But they do have a specific use
> case and that is to provide "advanced knowledge" of a publickey that can be
> used for encrypting a message to an intended recipient, without the
> requirement for 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 without seeing them in a secure way.
> >>
> >> As I understand it the BlockChain uses "time" bought through proof of
> 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
> check their own record to identify problems on the ledger.
> >>
> >> There is of course more to this, but I like to refer to the
> "distributed ledger of device keys" as the "Web-of-trust re-imagined"
> although that isn't strictly true.
> >>
> >> Ok there you have it. The cat is out of the bag, feel free to give
> feedback, I have to finish the paper, apologies if it is not a topic for
> this list.
> >>
> >> 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 addresses
> >>> available for others easily to find and verify the ownership over a
> kind
> >>> 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 is
> >>> not secury anyhow and signed messages could be swapped easily with the
> >>> 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 them.
> >>>
> >>> [0] https://bitcointalk.org/index.php?topic=502538
> >>> [1] https://bitcointalk.org/index.php?topic=505095
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> _______________________________________________
> >>> 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/
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--089e015380babe0b9904f5ff2bf7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>I posted some code on Reddit a while back a=
round adding a simple x509 digital signature to a Bitcoin address URL, sinc=
e you could gain the benefit of an x.509 authenticated Bitcoin address with=
out having to do a full BIP70 implementation.=A0 It&#39;s not WoT, but x509=
, for all its flaws, works very well in the real world almost all of the ti=
me.<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 assumed there&#39;s some reason this hasn&#39;t already been implemented=
, likely based in the general disgust around x509.<br>

<br></div><div>Anyway, here&#39;s my idea (complete with working Java sourc=
e):<br></div><div><br></div><a href=3D"http://www.reddit.com/r/BitcoinSerio=
us/comments/1sebj0/proposal_bitcoin_invoice_signatures/">http://www.reddit.=
com/r/BitcoinSerious/comments/1sebj0/proposal_bitcoin_invoice_signatures/</=
a><br>

</div><br></div><div>FWIW.<br></div><div><br></div>--Daryl<br><div><br></di=
v></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tu=
e, Apr 1, 2014 at 7:20 AM, Chris D&#39;Costa <span dir=3D"ltr">&lt;<a href=
=3D"mailto:chris.dcosta@meek.io" target=3D"_blank">chris.dcosta@meek.io</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">The code will be available as soon as we are=
 ready, 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 tec=
hnologies, without asking if they can answer all (not just some) of the que=
stions I raised. I have yet to be convinced that anything existing meets th=
ose requirements, namecoin included, hence why we are looking at creating a=
n alternative (non-coin by the way) but this alternative has some =A0of the=
 important properties that the distributed ledger provides.<br>


<br>
To answer the question about expiry, we&#39;re looking at something we&#39;=
ll call proof-of-life for the device keys. In a nutshell on of the pieces o=
f information stored with the device public key will be a last heard from d=
ate - a date which is sent only by the device from time to time. Records th=
at are expired are devices that have not been heard from for a given period=
 (to be decided). As the device keys are not related to the Bitcoin keys it=
 will be safe to expire a device key by default. An expired device would re=
quire reinitialisation, which would make a new device key set, a new proof =
of life date and then the Bitcoin keys (BIP32) can be restored.<br>


<br>
<br>
<br>
Regards<br>
<br>
Chris D&#39;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@bit=
pay.com">jgarzik@bitpay.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Re-reading this, even with the most recent message, is still isn&#39;t=
<br>
&gt; clear _precisely_ how your technology works, or why it is better than<=
br>
&gt; namecoin. =A0User profiles (and distributed ledgers) need to reflect t=
he<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. =A0There is a lot of computer science involved in making sure th=
e<br>
&gt; public ledger you see is not an outdated view. =A0A log-like stream of=
<br>
&gt; changes is not the only way to do things, but other methods need less<=
br>
&gt; hand-wavy details (show the code) before they are well recognized as<b=
r>
&gt; useful.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt; On Mon, Mar 31, 2014 at 7:14 AM, Chris D&#39;Costa &lt;<a href=3D"=
mailto: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 o=
ne 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 decentr=
alised ledger of, what we refer to as, &quot;device keys&quot;.<br>
&gt;&gt;<br>
&gt;&gt; These keys are not related in any way to the Bitcoin keys, (which =
is why I&#39;m hesitating about discussing it here) neither do they even at=
tempt to identify the human owner if the device. But they do have a specifi=
c use case and that is to provide &quot;advanced knowledge&quot; of a publi=
ckey that can be used for encrypting a message to an intended recipient, wi=
thout the requirement for a third-party CA, and more importantly without pr=
ior dialogue. We think 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 &quot;time&quot; bought thr=
ough proof of work to establish a version of the truth, we are using time i=
n the reverse sense : advanced knowledge of all pubkeys. Indeed all devices=
 could easily check 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 &quot;=
distributed ledger of device keys&quot; as the &quot;Web-of-trust re-imagin=
ed&quot; although that isn&#39;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=
 feedback, I have to finish the paper, apologies if it is not a topic for t=
his list.<br>
&gt;&gt;<br>
&gt;&gt; Regards<br>
&gt;&gt;<br>
&gt;&gt; Chris D&#39;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@ri=
seup.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 a=
ddresses<br>
&gt;&gt;&gt; available for others easily to find and verify the ownership o=
ver a kind<br>
&gt;&gt;&gt; of WoT. Right now they sign their own addresses and quote them=
 in the<br>
&gt;&gt;&gt; forums.<br>
&gt;&gt;&gt; As I pointed out there already the centralized storage in the =
forums is<br>
&gt;&gt;&gt; not secury anyhow and signed messages could be swapped easily =
with 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=
 single<br>
&gt;&gt;&gt; vanity addresses only.<br>
&gt;&gt;&gt; It seems webfinger could be part of a solution where servers o=
f a<br>
&gt;&gt;&gt; business can tell and proof you if a specific address is owned=
 by them.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [0] <a href=3D"https://bitcointalk.org/index.php?topic=3D50253=
8" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D502538</a><b=
r>
&gt;&gt;&gt; [1] <a href=3D"https://bitcointalk.org/index.php?topic=3D50509=
5" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D505095</a><b=
r>
&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">B=
itcoin-development@lists.sourceforge.net</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoi=
n-development" target=3D"_blank">https://lists.sourceforge.net/lists/listin=
fo/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">Bitco=
in-development@lists.sourceforge.net</a><br>
&gt;&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/b=
itcoin-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. =A0 =A0 =A0<a href=3D"https://bitpay.com/" target=3D"_bla=
nk">https://bitpay.com/</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@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>

--089e015380babe0b9904f5ff2bf7--