From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGAFk-0006AZ-1W for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 16:44:08 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.177 as permitted sender) client-ip=209.85.214.177; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f177.google.com; Received: from mail-ob0-f177.google.com ([209.85.214.177]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGAFi-0007nI-MK for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 16:44:07 +0000 Received: by mail-ob0-f177.google.com with SMTP id wp18so688363obc.36 for ; Wed, 19 Feb 2014 08:44:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.122.133 with SMTP id ls5mr8068261obb.52.1392828241187; Wed, 19 Feb 2014 08:44:01 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Wed, 19 Feb 2014 08:44:00 -0800 (PST) Received: by 10.76.71.231 with HTTP; Wed, 19 Feb 2014 08:44:00 -0800 (PST) In-Reply-To: References: <5303B110.70603@bitpay.com> Date: Wed, 19 Feb 2014 16:44:00 +0000 X-Google-Sender-Auth: TeX6gQbhXh7U6vybNjm465jv54I Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a1134a7e48c99ac04f2c51871 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 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 X-Headers-End: 1WGAFi-0007nI-MK Cc: Bitcoin Dev , Andreas Schildbach Subject: Re: [Bitcoin-development] BIP70 proposed changes 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: Wed, 19 Feb 2014 16:44:08 -0000 --001a1134a7e48c99ac04f2c51871 Content-Type: text/plain; charset=UTF-8 Thanks for the feedback guys! I would also like to understand the problems you've been having with certificates in node.js. FYI the CA cert is *not* supposed to be included, this matches what the code in Bitcoin Core and bitcoinj expects. It may be that Bitcoin Core accepts a redundant CA cert being provided, but if so that'd fall in the category of openssl being generous. If there are issues here, it sounds like an issue with node and not the spec. I'm not even sure why it would matter - certs are just byte arrays so if node can sign a hash with a private key, the rest should be easy. With regards to the PKI I'd appreciate it if we don't go around that circle again. Please remember one of the primary goals of all of this is to show to the user on their hardware wallet a meaningful name. Almost all merchants on the Internet already went through the process of associating a public key with their name, using X.509. Whilst for now your payment requests will have to be signed as BitPay, this isn't ideal for the longer term and I'd like to design a protocol extension to allow merchants to delegate their signature authority to you. In this way they would be able to sign a secondary key with their own ssl key as part of the enrolment process, and after that you could sign payment requests on their behalf. Kind of like a Bitcoin specific subcert (and there would be no reason to use X.509 format for that). Re: feedback url. How is this different to a result code in PaymentAck which already caused much debate? Surely we want a payment to either work out boy work and for that decision to be made immediately? Your invoice page switches to a completed state once you see a tx be broadcast so that's the "done" state today even if there are caveats. I'd like to see a status code added to PaymentAck so receivers can reject payments if they are bad in some way. On 19 Feb 2014 19:41, "Jeff Garzik" wrote: > On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach > wrote: > > On 02/18/2014 08:14 PM, Ryan X. Charles wrote: > >> BitPay is working on a new standard > >> based on bitcoin-like addresses for authentication. It would be great if > >> we could work with the community to establish a complete, decentralized > >> authentication protocol. > > > > Sounds interesting, let us know as soon as you have anything. > > SINs. See https://en.bitcoin.it/wiki/Identity_protocol_v1 > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a1134a7e48c99ac04f2c51871 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for the feedback guys!

I would also like to understand the problems you've been= having with certificates in node.js. FYI the CA cert is *not* supposed to = be included, this matches what the code in Bitcoin Core and bitcoinj expect= s. It may be that Bitcoin Core accepts a redundant CA cert being provided, = but if so that'd fall in the category of openssl being generous. If the= re are issues here, it sounds like an issue with node and not the spec. I&#= 39;m not even sure why it would matter - certs are just byte arrays so if n= ode can sign a hash with a private key, the rest should be easy.

With regards to the PKI I'd appreciate it if we don'= t go around that circle again. Please remember one of the primary goals of = all of this is to show to the user on their hardware wallet a meaningful na= me. Almost all merchants on the Internet already went through the process o= f associating a public key with their name, using X.509.

Whilst for now your payment requests will have to be signed = as BitPay, this isn't ideal for the longer term and I'd like to des= ign a protocol extension to allow merchants to delegate their signature aut= hority to you. In this way they would be able to sign a secondary key with = their own ssl key as part of the enrolment process, and after that you coul= d sign payment requests on their behalf. Kind of like a Bitcoin=C2=A0 speci= fic subcert (and there would be no reason to use X.509 format for that).

Re: feedback url. How is this different to a result code in = PaymentAck which already caused much debate? Surely we want a payment to ei= ther work out boy work and for that decision to be made immediately? Your i= nvoice page switches to a completed state once you see a tx be broadcast so= that's the "done" state today even if there are caveats. I&#= 39;d like to see a status code added to PaymentAck so receivers can reject = payments if they are bad in some way.

On 19 Feb 2014 19:41, "Jeff Garzik" &l= t;jgarzik@bitpay.com> wrote:
On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach
<andreas@schildbach.de> = wrote:
> On 02/18/2014 08:14 PM, Ryan X. Charles wrote:
>> BitPay is working on a new standard
>> based on bitcoin-like addresses for authentication. It would be gr= eat if
>> we could work with the community to establish a complete, decentra= lized
>> authentication protocol.
>
> Sounds interesting, let us know as soon as you have anything.

SINs. =C2=A0See https://en.bitcoin.it/wiki/Identity_protocol_v1

--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/

---------------------------------------------------------------------------= ---
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D121054471&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--001a1134a7e48c99ac04f2c51871--