Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal

[Mike Hearn]

Hi Mark,

This is very similar to a proposal I made some time ago:


https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04053.html

I think the outlines of a design are clear - my proposal and yours don't I
think differ substantially. Someone needs to make it happen though.
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal

[Mark van Cuijk]

Good to see that it has been discussed, but I see the idea has been postponed. 
I agree our proposals don’t differ substantially. Besides naming, I think the 
differences are the algorithms that are used for signing the extended 
certificate / mandate by the merchant and the way backwards compatibility is 
handled.

Also taking into consideration the replies on your proposal, I think the 
following decisions are most important to be made when we make a step back:

What party/system do we want to rely on to verify the identity of the merchant? 
Options I’ve seen:
- X.509  CAs
- Payment Processors (PP)
- PGP/Bitcoin-based

Which “PKI" do we want to use to identify the merchant (related to the previous 
question)?
- X.509 certificate
- Merchant identifier
- Twitter handle

Which “PKI” do we want to use to authenticate the PP?
- X.509 certificate
- Extended certificate

My personal opinion:

I’d prefer to stick to the X.509 system for identification of the merchant, 
even though the system is not perfect. In the case of a webshop transaction, a 
customer probably already relies on the X.509 system to authenticate the 
identity of the merchant during the shopping session (HTTPS) in his browser 
when he transmits his personal data like his address. I’d prefer not to add a 
competing identification system a customer also needs to rely on, unless that 
system brings objective improvements and can also be used in the HTTPS session.

I do like the idea coined by Mike that a PP can issue non-SSL certificates for 
the purpose of merchant identification, as long as a customer is free to 
determine whether he trusts the PP for this purpose.

Regarding the choice of how to authenticate the PP, I’m a bit undetermined. 
Disregarding backward compatibility, I think the extended certificate system 
proposed by Mike is cleaner. However, I don’t like the concept of requiring two 
separate signatures for old and new clients. Taking backward compatibility in 
mind, I tend to prefer my proposal.

/Mark

On 27 Jul 2014, at 21:31 , Mike Hearn  wrote:

> Hi Mark,
> 
> This is very similar to a proposal I made some time ago:
> 
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04053.html
> 
> I think the outlines of a design are clear - my proposal and yours don't I 
> think differ substantially. Someone needs to make it happen though.
> 
> 

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal

[Mike Hearn]

On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk  wrote:

> Good to see that it has been discussed, but I see the idea has been
> postponed.
>

I'm not sure postponed is the right word. It wasn't in v1, but many useful
things weren't. It's more like, a bunch of people have to do work to
upgrade this and at the moment they're all busy with other things.


> I do like the idea coined by Mike that a PP can issue non-SSL certificates
> for the purpose of merchant identification, as long as a customer is free
> to determine whether he trusts the PP for this purpose.
>

I don't think I proposed this exactly? It's the other way around - a
merchant issues an extension cert to allow the PP to act on their behalf.


> Regarding the choice of how to authenticate the PP, I’m a bit
> undetermined. Disregarding backward compatibility, I think the extended
> certificate system proposed by Mike is cleaner. However, I don’t like the
> concept of requiring two separate signatures for old and new clients.
> Taking backward compatibility in mind, I tend to prefer my proposal.
>

I'm not sure I understand. Your proposal also has two signatures. Indeed it
must because delegation of authority requires a signature, but old clients
won't understand it.
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal

[Mark van Cuijk]

On 28 Jul 2014, at 14:46 , Mike Hearn  wrote:

> I do like the idea coined by Mike that a PP can issue non-SSL certificates 
> for the purpose of merchant identification, as long as a customer is free to 
> determine whether he trusts the PP for this purpose.
> 
> I don't think I proposed this exactly? It's the other way around - a merchant 
> issues an extension cert to allow the PP to act on their behalf.

I referred to your idea in 
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html
 which is indeed not the proposal itself.

> Regarding the choice of how to authenticate the PP, I’m a bit undetermined. 
> Disregarding backward compatibility, I think the extended certificate system 
> proposed by Mike is cleaner. However, I don’t like the concept of requiring 
> two separate signatures for old and new clients. Taking backward 
> compatibility in mind, I tend to prefer my proposal.
> 
> I'm not sure I understand. Your proposal also has two signatures. Indeed it 
> must because delegation of authority requires a signature, but old clients 
> won't understand it.

I’ll rephrase what I intended to say. In your proposal two signatures need to 
be computed over the payment request data, one with the key related to the 
X.509 certificate (for backwards compatibility) and one with the ECDSA public 
key. On my proposal only one signature needs to be computed over the payment 
request data using the former key, the same way it happens now.

Indeed there is another signature, which is to authenticate the payment 
delegation. If you take it into account in the signature count, then your 
proposal has three signatures.

/Mark--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal

[Mike Hearn]

>
> I referred to your idea in
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html
> 
>  which
> is indeed not the proposal itself.
>

Right, gotcha. Had forgotten about that.

Indeed there is another signature, which is to authenticate the payment
> delegation. If you take it into account in the signature count, then your
> proposal has three signatures.
>

Yes, I see now, you are right. A mandate type system is probably simpler
indeed.

So what now? To be honest my next priority with BIP70 was to formalise the
extensions process, I've been dragging my feet over that because I'm
working on other things. And then after that to knock some heads together
over at BitPay/Coinbase and get them to put useful text in the memo field
instead of random numbers. Baby steps 
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal

[Mark van Cuijk]

On 28 Jul 2014, at 15:32 , Mike Hearn  wrote:

> So what now? To be honest my next priority with BIP70 was to formalise the 
> extensions process, I've been dragging my feet over that because I'm working 
> on other things. And then after that to knock some heads together over at 
> BitPay/Coinbase and get them to put useful text in the memo field instead of 
> random numbers. Baby steps 

I can probably pick up writing the proposal.

However, I’m not sure what process to follow. Should I format the proposal as a 
new BIP or should it become part of BIP.70? How does the extensions process 
you’re working on going to describe the process?
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal

[Mike Hearn]

That would definitely be a new BIP.

But firstly it'd make sense to implement it and make sure that the payment
processors intend to use it. Like I said, I wasn't very successful so far
in getting them to make useful memo fields. I'm hoping that once wallets
start actually recording and displaying the memo in their transactions list
that will change.


On Wed, Jul 30, 2014 at 9:54 AM, Mark van Cuijk  wrote:

> On 28 Jul 2014, at 15:32 , Mike Hearn  wrote:
>
> > So what now? To be honest my next priority with BIP70 was to formalise
> the extensions process, I've been dragging my feet over that because I'm
> working on other things. And then after that to knock some heads together
> over at BitPay/Coinbase and get them to put useful text in the memo field
> instead of random numbers. Baby steps 
>
> I can probably pick up writing the proposal.
>
> However, I’m not sure what process to follow. Should I format the proposal
> as a new BIP or should it become part of BIP.70? How does the extensions
> process you’re working on going to describe the process?
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development