From: Mike Hearn <mike@plan99•net>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Andreas Schildbach <andreas@schildbach•de>
Subject: Re: [Bitcoin-development] BIP70 proposed changes
Date: Wed, 19 Feb 2014 16:44:00 +0000 [thread overview]
Message-ID: <CANEZrP1QS1Z0_=-sUjK2H5CkrnuCUsCu5PZhggAvEbW4Y2Y_kA@mail.gmail.com> (raw)
In-Reply-To: <CAJHLa0MGaxJTGPR-bduW36-4Msb348FANqFmw67jqFxq1CLwbw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]
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" <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 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
>
[-- Attachment #2: Type: text/html, Size: 4007 bytes --]
next prev parent reply other threads:[~2014-02-19 16:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 17:31 Andreas Schildbach
2014-02-18 19:14 ` Ryan X. Charles
2014-02-18 20:15 ` Gavin Andresen
2014-02-18 21:40 ` Andreas Schildbach
2014-02-19 14:10 ` Jeff Garzik
2014-02-19 16:44 ` Mike Hearn [this message]
2014-05-06 2:35 ` Odinn Cyberguerrilla
2014-05-06 8:22 ` Alon Muroch
2014-02-18 21:47 ` Peter Todd
2014-02-18 23:41 ` Bernd Jendrissek
2014-02-18 22:02 ` Derber
2014-02-21 15:34 ` Mike Hearn
2014-03-05 10:18 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP1QS1Z0_=-sUjK2H5CkrnuCUsCu5PZhggAvEbW4Y2Y_kA@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox