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 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> Mime-Version: 1.0 (1.0) In-Reply-To: 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 Date: Wed, 2 Apr 2014 00:26:42 +0200 To: Daryl Banttari 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" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 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 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
Hi Daryl

I th= ink the two issues with this are
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.)
2)= unless you are already aware of the  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.



Regards
Chris D'Costa


Sent from my= iPhone

On 1 Apr 2014, at 20:16, Daryl Banttari &l= t;dbanttari@gmail.com> wrote:<= br>
= 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.  It's not WoT, but x509, for all its flaws, works very well i= n 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 a= ssumed there's some reason this hasn't already been implemented, likely base= d in the general disgust around x509.

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

http://www.reddit.com/r/B= itcoinSerious/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 r= eady, 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 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  of the i= mportant properties that the distributed ledger provides.

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.



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<= br> > bitcoin technology secures.
>
> Keys expire or are compromised, and the public ledger needs to reflect<= br> > that.  There is a lot of computer science involved in making sure t= he
> public ledger you see is not an outdated view.  A log-like stream o= f
> 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 on= e 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 decentra= lised ledger of, what we refer to as, "device keys".
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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 ad= dresses
>>> available for others easily to find and verify the ownership ov= er a kind
>>> of WoT. Right now they sign their own addresses and quote them i= n the
>>> forums.
>>> As I pointed out there already the centralized storage in the f= orums is
>>> not secury anyhow and signed messages could be swapped easily w= ith 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 s= ingle
>>> 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 b= y them.
>>>
>>> [0] https://bitcointalk.org/index.php?topic=3D502538
= >>> [1] https://bitcointalk.org/index.php?topic=3D505095
= >>>
>>> ---------------------------------------------------------------= ---------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bi= tcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo= /bitcoin-development
>>
>> -------------------------------------------------------------------= -----------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoi= n-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bit= coin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/

----------------------------------------------------------------------------= --
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develop= ment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-deve= lopment

--------------------= ----------------------------------------------------------
<= /blockquote>
___________________________= ____________________
Bitcoin-development mailing list=
Bitco= in-development@lists.sourceforge.net
https://lists.sour= ceforge.net/lists/listinfo/bitcoin-development
= --Apple-Mail-6C4A8019-0B52-45DA-B377-877DF3F5F161--