[Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

I've turned the preliminary payment protocol spec into three BIPs:

https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages
https://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension

I expect the wallet-side implementation to be pulled into Bitcoin-Qt Real
Soon:
  https://github.com/bitcoin/bitcoin/pull/2539

There is also a reference implementation of server-side code for generating
payment requests in php and C++ :
  https://github.com/gavinandresen/paymentrequest

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1030 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Roy Badami]

On Wed, Jul 31, 2013 at 04:28:25PM +1000, Gavin Andresen wrote:
> I've turned the preliminary payment protocol spec into three BIPs:
> 
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
> https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages
> https://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension


Is it envisaged to be possible/sensible to have a URI that is *only* a
payment request?  i.e. something like the following (although I'm not
sure this is a valid URI):

bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe

roy

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3469 bytes --]

Woo, huzzah :-)

Now the BIP draft is available and we know it all hangs together, I'm
hoping to (re)start implementation work in bitcoinj in the next month or
two. I'm currently trying to figure out which is more important,
deterministic wallets or payment protocol, but I think right now the
payment protocol would be easier to do and would benefit more from a second
implementation. HD wallets have already been shown interoperable.

Comments on BIP 70:

   "PaymentRequest messages larger than 50,000 bytes should be rejected by
the merchant's server, to mitigate denial-of-service attacks."

Do you mean "users wallet" here?

You could note in the motivation section two more motivations:

1) That the protocol can be a foundation on which other features are built
2) That it is required to assist hardware wallets when there is a virus on
the system

Perhaps note in the BIP that the merchant should not assume the
merchant_data field is trustworthy - malicious buyers could rewrite it as
they see fit. Point out that a good way to use this is to serialize server
state, signed by a merchant-only key, in the same way one might use an HTTP
cookie.

   "PaymentDetails.payment_url must be secure against man-in-the-middle
attacks that might alter Payment.refund_to (if using HTTP, it must be
TLS-protected).

This says "must", but what should a client do here if the payment URL is
not HTTPS? I suggest weakening this to "should", as sometimes TLS is
redundant (e.g. if you're sending to a Tor hidden service).

The PaymentACK message contains a copy of Payment, but the BIP doesn't say
what to do with it. I assume this means a client is free to ignore it and
rely on TCP state to figure out the payment/ack connection instead? It may
be worth noting that explicitly.

In the certificates section, you could observe that "validation" means
"verification that it correctly chains to a trusted root authority, where
trusted roots may be obtained from the operating system. If there is no
operating system, the Mozilla root store is recommended".

All the rest LGTM.
[edit<https://en.bitcoin.it/w/index.php?title=BIP_0070&action=edit&section=7>
]


On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> I've turned the preliminary payment protocol spec into three BIPs:
>
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
> https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages
> https://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension
>
> I expect the wallet-side implementation to be pulled into Bitcoin-Qt Real
> Soon:
>   https://github.com/bitcoin/bitcoin/pull/2539
>
> There is also a reference implementation of server-side code for
> generating payment requests in php and C++ :
>   https://github.com/gavinandresen/paymentrequest
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&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: 6881 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

Thanks, Mike!

   "PaymentRequest messages larger than 50,000 bytes should be rejected by
> the merchant's server, to mitigate denial-of-service attacks."
>
> Do you mean "users wallet" here?
>

Yes, fixed.



> You could note in the motivation section two more motivations:
> 1) That the protocol can be a foundation on which other features are built
>

I don't like putting "this is what we think will happen in the future"
types of statements in specifications, so I'm inclined to leave that out.


> 2) That it is required to assist hardware wallets when there is a virus on
> the system
>

Added:

"Resistance from man-in-the-middle attacks that replace a merchant's
bitcoin address with an attacker's address before a transaction is
authorized with a hardware wallet."

Perhaps note in the BIP that the merchant should not assume the
> merchant_data field is trustworthy - malicious buyers could rewrite it as
> they see fit. Point out that a good way to use this is to serialize server
> state, signed by a merchant-only key, in the same way one might use an HTTP
> cookie.
>

Added:

"Note that malicious clients may modify the merchant_data, so should be
authenticated in some way (for example, signed with a merchant-only key)."


>    "PaymentDetails.payment_url must be secure against man-in-the-middle
> attacks that might alter Payment.refund_to (if using HTTP, it must be
> TLS-protected).
>
> This says "must", but what should a client do here if the payment URL is
> not HTTPS? I suggest weakening this to "should", as sometimes TLS is
> redundant (e.g. if you're sending to a Tor hidden service).
>

done.


> The PaymentACK message contains a copy of Payment, but the BIP doesn't say
> what to do with it. I assume this means a client is free to ignore it and
> rely on TCP state to figure out the payment/ack connection instead? It may
> be worth noting that explicitly.
>

Added:

"payment | Copy of the Payment message that triggered this PaymentACK.
Clients may ignore this if they implement another way of associating
Payments with PaymentACKs."


>
> In the certificates section, you could observe that "validation" means
> "verification that it correctly chains to a trusted root authority, where
> trusted roots may be obtained from the operating system. If there is no
> operating system, the Mozilla root store is recommended".
>

Modified that section to say:

"...followed by additional certificates, with each subsequent certificate
being the one used to certify the previous one, up to a trusted root
authority. The recipient must verify the certificate chain according to
[RFC5280] and reject the PaymentRequest if any validation failure occurs.

Trusted root certificates may be obtained from the operating system; if
validation is done on a device without an operating system, the Mozilla
root store<http://www.mozilla.org/projects/security/certs/included/index.html>
is
recommended."

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 6386 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Gavin Andresen]

On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami <roy@gnomon.org.uk> wrote:
>
> Is it envisaged to be possible/sensible to have a URI that is *only* a
> payment request?  i.e. something like the following (although I'm not
> sure this is a valid URI):
>
> bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe

I think we'll want a bitcoin address in there for a long time for
backwards compatibility.

If web browser support for arbitrary MIME types is strong enough (I
haven't tested), then a payment request can be initiated with just an
anchor tag:
  <a href="https://merchant.com/pay.php?3D2a8628fc2fbe"
type="application/bitcoin-paymentrequest">

Doing it that way saves a http round-trip.

--
--
Gavin Andresen

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

On 31 July 2013 13:33, Gavin Andresen <gavinandresen@gmail.com> wrote:

> On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> >
> > Is it envisaged to be possible/sensible to have a URI that is *only* a
> > payment request?  i.e. something like the following (although I'm not
> > sure this is a valid URI):
> >
> > bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe
>
> I think we'll want a bitcoin address in there for a long time for
> backwards compatibility.
>
> If web browser support for arbitrary MIME types is strong enough (I
> haven't tested), then a payment request can be initiated with just an
> anchor tag:
>   <a href="https://merchant.com/pay.php?3D2a8628fc2fbe"
> type="application/bitcoin-paymentrequest">
>

Unless I'm mistaken you cant generally set the "Accept" header on a browser
via a standard href ... one of those annoying quirks


>
> Doing it that way saves a http round-trip.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&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: 2704 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[E willbefull]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

I think it's important to expect PaymentRequest-only bitcoin URIs in the
future. Some types of payments (exotic transactions) may not make sense to
have a single fallback address. Or, a page with a bitcoin URI link may be
relying on a separate service provider to assemble the transaction.


On Wed, Jul 31, 2013 at 5:33 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> >
> > Is it envisaged to be possible/sensible to have a URI that is *only* a
> > payment request?  i.e. something like the following (although I'm not
> > sure this is a valid URI):
> >
> > bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe
>
> I think we'll want a bitcoin address in there for a long time for
> backwards compatibility.
>
> If web browser support for arbitrary MIME types is strong enough (I
> haven't tested), then a payment request can be initiated with just an
> anchor tag:
>   <a href="https://merchant.com/pay.php?3D2a8628fc2fbe"
> type="application/bitcoin-paymentrequest">
>
> Doing it that way saves a http round-trip.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&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: 2708 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Gavin Andresen]

On Thu, Aug 1, 2013 at 9:30 AM, E willbefull <ewillbefull@gmail.com> wrote:
> I think it's important to expect PaymentRequest-only bitcoin URIs in the
> future. Some types of payments (exotic transactions) may not make sense to
> have a single fallback address.

P2SH addresses already support all exotic transactions.

> Or, a page with a bitcoin URI link may be
> relying on a separate service provider to assemble the transaction.

Do you mean assemble the PaymentRequest message?  Because the payment
transaction will always be created by the customer's wallet software.

IF PaymentRequests take over the world and we get 100% wallet software
support, then I'd be happy to write another BIP that says that a
bitcoin: URI can be just bitcoin:?request=http...

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[E willbefull]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

P2SH addresses support exotic transaction outputs, but not all exotic
transactions. This payment protocol can allow for combining multiple
outputs. A PaymentRequest for sending money to multiple parties, for
example, could not fall back to a single address.


On Wed, Jul 31, 2013 at 5:38 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> On Thu, Aug 1, 2013 at 9:30 AM, E willbefull <ewillbefull@gmail.com>
> wrote:
> > I think it's important to expect PaymentRequest-only bitcoin URIs in the
> > future. Some types of payments (exotic transactions) may not make sense
> to
> > have a single fallback address.
>
> P2SH addresses already support all exotic transactions.
>
> > Or, a page with a bitcoin URI link may be
> > relying on a separate service provider to assemble the transaction.
>
> Do you mean assemble the PaymentRequest message?  Because the payment
> transaction will always be created by the customer's wallet software.
>
> IF PaymentRequests take over the world and we get 100% wallet software
> support, then I'd be happy to write another BIP that says that a
> bitcoin: URI can be just bitcoin:?request=http...
>
> --
> --
> Gavin Andresen
>

[-- Attachment #2: Type: text/html, Size: 1721 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Roy Badami]

On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:
> I think it's important to expect PaymentRequest-only bitcoin URIs in the
> future. Some types of payments (exotic transactions) may not make sense to
> have a single fallback address. Or, a page with a bitcoin URI link may be
> relying on a separate service provider to assemble the transaction.

Also:

* There may be a desire to minimize the URL length when used in a QR code

* Some applications might specifically require some of the features of
the payment protocol - e.g. it may be a requirement that a print-media
QR code cannot be used after a cut-off date, or a vendor may have a
specific requirement not to accept payments without a refund address

There are pros and cons, but it's not clear to me that the benefits of
enforced backward compatibility outweigh the benefits of allowing
application designers to innovate as they see fit.

roy

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Pieter Wuille]

On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> I've turned the preliminary payment protocol spec into three BIPs:
>
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages

I don't like the wording for payment_uri "where the payment _may_ be
sent to obtain a paymentACK", or the fact that in the diagram it is
the client wallet broadcasting the transaction to the network.

In my opinion, it should ultimately become the responsibility of the
receiver to get the transaction confirmed. Of course, the sender may
help, and if the transaction does not confirm, no payment took place.
But one of the advantages direct negotiation offers, is that the
sender wallet does not need to remain online anymore to get the
transaction broadcast. I don't think it should be even required that
the sender wallet is connected to the P2P network at all. All they
need to do is construct a satisfactory transaction, and send it to the
merchant who cares about it.

I would suggest the wording, "if a payment_uri is specified, the
wallet application should try - and if necessary, retry - to submit
the transaction there, resulting in a paymentACK from the merchant.
Broadcasting the transaction on the P2P network is optional.". Perhaps
we should even discourage broadcasting before the paymentACK is
obtained, to make sure the merchant received it, together with the
metadata, to decrease the chances of money arriving at a merchant
without metadata (to minimize the cases where manual intervention is
needed).

-- 
Pieter

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Gavin Andresen]

RE: making the bitcoin address in the bitcoin: URI optional:

Ok, I'm convinced, sometimes merchants won't want or need backwards
compatibility and sometimes it won't make sense for them to put an
arbitrary bitcoin: address there.

RE: should the customer's machine not broadcast the transaction:

I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ?  The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.

I'd also like to hear from merchants: any issue with your payment
processing server having "broadcast transaction" functionality?

My biggest worry is that the payment protocol will not get wide
support if it is too hard to implement.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

> I'd like to hear from other wallet implementors. Do you have a notion
> of 'locked inputs' ?  The tricky bit in constructing a transaction but
> not broadcasting it right away is the inputs must be locked, so
> they're not accidentally double-spent.
>

bitcoinj separates the concept of committing a tx to the wallet from
broadcasting it. However by default transactions that weren't seen in the
chain yet will be announced when a new peer is connected to. It'd take
extra code to suppress that, and it's unclear to me why that's useful. I
agree with Pieter that it should be the merchants responsibility to get the
tx out there, but having the client do the broadcast as well can't really
hurt (except perhaps some privacy impact).

[-- Attachment #2: Type: text/html, Size: 1027 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Roy Badami]

On Thu, Aug 08, 2013 at 07:10:05AM +1000, Gavin Andresen wrote:
> RE: should the customer's machine not broadcast the transaction:

If we're going to allow payments to fail without being broadcast (but
where the wallet can't in general prove that the receiver hasn't seen
the transaction) then I would argue that it becomes highly desirable
that the wallet invalidates the transaction at the earliest
opportunity by spending the outputs in a pay-to-self transaction.

Otherwise malicious receivers, or temporary failures, could result in
the user being told that the transfer didn't happen, but then the
coins actually leaving the wallet anyway a short time later.

roy

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Pieter Wuille]

On Wed, Aug 7, 2013 at 11:17 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> I'd like to hear from other wallet implementors. Do you have a notion
>> of 'locked inputs' ?  The tricky bit in constructing a transaction but
>> not broadcasting it right away is the inputs must be locked, so
>> they're not accidentally double-spent.
>
>> bitcoinj separates the concept of committing a tx to the wallet from
> broadcasting it. However by default transactions that weren't seen in the
> chain yet will be announced when a new peer is connected to. It'd take extra
> code to suppress that, and it's unclear to me why that's useful. I agree
> with Pieter that it should be the merchants responsibility to get the tx out
> there, but having the client do the broadcast as well can't really hurt
> (except perhaps some privacy impact).

My concerns here are:
* Making sure wallet applications can function without supporting the
P2P protocol (which drops a huge implementation overhead for simple -
perhaps hardware-based - wallets).
* Making sure the responsibility of confirming transactions is with
the receiver (while the responsibility of creating a confirmable
transaction is with the sender), which again simplifies wallet
implementation.
* Making receiving of metadata reliable, by minimizing cases where a
transaction is accidentally broadcast without the receiver being told
about it. This is perhaps not possible entirely, but it should be
possible to reduce it to a point where the remaining cases can be
dealt with manually. This also means indeed being able to give a
bitcoin URI (or why not just a URL to a payment descriptor?) that does
not contain a static Bitcoin address. I understand the compatibility
concern here, but IMHO we should do all effort to get rid of static
addresses were possible - the public key should be negotiated be
sender and receiver.

I worry about the scenario where some evil hotspot owner observes a
payment request, and later sees a bitcoin P2P transaction crediting
that key, but without payment being sent to the payment_uri (because
he blocked it), thus allowing him to construct a payment message
himself with the request + transaction, and adding his own refund
address or delivery location, or ... To fix problems related to this
completely, we'd need transactions that commit to the payment message,
instead of the other way around. I believe the pay-to-contract scheme
presented by Timo Hanke at the San Jose conference solved this.

-- 
Pieter

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

> My concerns here are:
> * Making sure wallet applications can function without supporting the
> P2P protocol (which drops a huge implementation overhead for simple -
> perhaps hardware-based - wallets)


How would such wallets get transactions into their wallet in the first
place?

The P2P protocol is really the simplest part of implementing a wallet, IMO.

I don't really have a strong opinion either way, but doing more work to
prevent transactions being announced to the network feels weird.

[-- Attachment #2: Type: text/html, Size: 792 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

On 08/07/2013 05:10 PM, Gavin Andresen wrote:
> I'd like to hear from other wallet implementors. Do you have a notion
> of 'locked inputs' ?  The tricky bit in constructing a transaction but
> not broadcasting it right away is the inputs must be locked, so
> they're not accidentally double-spent.
>
I have avoided any notion of locking inputs in Armory for offline
wallets.  The underlying concept of why a seemingly-random amount of
funds are inaccessible at a given time is so non-intuitive and difficult
to explain to a non-expert, that I haven't even tried to deal with it.
   Luckily, most users do one operation at a time, so it's not a real a
problem.  But as more businesses have started to use Armory, it /will/
become a problem that will need to be addressed /somehow/.

I have considered at least "marking" inputs to indicate to the user that
the transaction they are creating may not be valid unless all previous
transactions have been broadcast.  The user will not necessarily
understand why, but they might easily comprehend the solution (and
perhaps a button that says "Forget all previously created transactions
that haven't been broadcast.  Press this button if there are no
transactions waiting to be broadcast"). 

Even if the user somewhat understands the concepts behind locking, you
easily end up with a mess of some coins being locked and rejecting
transaction creation somewhat randomly, especially when they create
transactions that they later decide not to execute.  And you have to
give the user a way to manually unlock the outputs which they wouldn't
know to use because it's so non-intuitive.  I'd much rather say "either
do one transaction at a time, or bundle payments into a single
multi-output transaction.  Or risk invalid transactions that have to be
re-created and signed."

-Alan



[-- Attachment #2: Type: text/html, Size: 2364 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Roy Badami]

Very brief comment on BIP 72:

I wonder if there should be some discussion included in the
specification as to how the BIP 21 amount, message and label
parameters should be processed when the payment protocol is used.

Presumably amount should be completely ignored?  But is the total
amount requestd by the PaymentRequest required to match the amount
parameter (when present)?  Is the client permitted to complain if they
don't?

And what about message?  Presumably the memo from PaymentDetails
should take precedence, but if it's not present, and message is?

I think this is an area perhaps more suited to SHOULDs and MAYs rather
than MUSTs, but it is probably worthy of mention...

roy

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Pieter Wuille]

On Wed, Aug 7, 2013 at 11:44 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> My concerns here are:
>> * Making sure wallet applications can function without supporting the
>> P2P protocol (which drops a huge implementation overhead for simple -
>> perhaps hardware-based - wallets)
>
>
> How would such wallets get transactions into their wallet in the first
> place?

By connecting to some other client, presumably. Have a small hardware
client that is able to do payments via NFC/QR/... directly with a
merchant, and can get 'recharged' by connecting with your desktop
client, for example. Maybe too futuristic to be a concern, but it
nicely illustrates how doing direct sender-to-receiver negotiation can
help decoupling tasks.

> I don't really have a strong opinion either way, but doing more work to
> prevent transactions being announced to the network feels weird.

Ok.

-- 
Pieter

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Pieter Wuille]

I see payment URIs rather as a replacement for bitcoin: URI rather
than an extension. It solves everything they did in a much cleaner
way, Given that bitcoin: have gotten some traction, we probably want
to reuse the moniker, but replace the rest entirely. In other words,
if a request is specified, nothing else should be.

There is just no useful way to combine them either - payments
generalize destinations to arbitrary scripts, messages are handled
inline, amounts are defined inline. And if you want to rely on the
payment infrastructure to work, you cannot risk people using the
old-style static address in the URI.



On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> Very brief comment on BIP 72:
>
> I wonder if there should be some discussion included in the
> specification as to how the BIP 21 amount, message and label
> parameters should be processed when the payment protocol is used.
>
> Presumably amount should be completely ignored?  But is the total
> amount requestd by the PaymentRequest required to match the amount
> parameter (when present)?  Is the client permitted to complain if they
> don't?
>
> And what about message?  Presumably the memo from PaymentDetails
> should take precedence, but if it's not present, and message is?
>
> I think this is an area perhaps more suited to SHOULDs and MAYs rather
> than MUSTs, but it is probably worthy of mention...
>
> roy
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Roy Badami]

But the reality is that in many applications you need to provide a
single URL.

Consider existing point-of-sale systems that display QR codes for the
user to scan.  They live within the limitations of existing bitcoin
URLs, but would no doubt benefit from the payments protocol.

It's not realistic for the terminal operator in a retail establishment
to have to select which protocol will be used before generating the QR
code - so the effect of your proposal is to require lowest common
denominator and effectively prevent such systems from using the
payments protocol (at least until it is sufficiently ubiquitous that
they feel happy to simply require its use).

roy

On Wed, Aug 07, 2013 at 11:54:44PM +0200, Pieter Wuille wrote:
> I see payment URIs rather as a replacement for bitcoin: URI rather
> than an extension. It solves everything they did in a much cleaner
> way, Given that bitcoin: have gotten some traction, we probably want
> to reuse the moniker, but replace the rest entirely. In other words,
> if a request is specified, nothing else should be.
> 
> There is just no useful way to combine them either - payments
> generalize destinations to arbitrary scripts, messages are handled
> inline, amounts are defined inline. And if you want to rely on the
> payment infrastructure to work, you cannot risk people using the
> old-style static address in the URI.
> 
> 
> 
> On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> > Very brief comment on BIP 72:
> >
> > I wonder if there should be some discussion included in the
> > specification as to how the BIP 21 amount, message and label
> > parameters should be processed when the payment protocol is used.
> >
> > Presumably amount should be completely ignored?  But is the total
> > amount requestd by the PaymentRequest required to match the amount
> > parameter (when present)?  Is the client permitted to complain if they
> > don't?
> >
> > And what about message?  Presumably the memo from PaymentDetails
> > should take precedence, but if it's not present, and message is?
> >
> > I think this is an area perhaps more suited to SHOULDs and MAYs rather
> > than MUSTs, but it is probably worthy of mention...
> >
> > roy
> >
> > ------------------------------------------------------------------------------
> > Get 100% visibility into Java/.NET code with AppDynamics Lite!
> > It's a free troubleshooting tool designed for production.
> > Get down to code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Gavin Andresen]

I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so
the bitcoin address is optional:

"If the "request" parameter is provided and backwards compatibility is
not required, then the bitcoin address portion of the URI may be
omitted (the URI will be of the form: bitcoin:?request=... )."

The spec already said what should happen if both request and
address/amount/etc were given:

"it should ignore the bitcoin address/amount/label/message in the URI
and instead fetch a PaymentRequest message and then follow the payment
protocol"

I think this gives us a smooth, clear upgrade path.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 31 bytes --]

Agreed, this looks good to me.

[-- Attachment #2: Type: text/html, Size: 52 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Pieter Wuille]

On Thu, Aug 8, 2013 at 2:48 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so
> the bitcoin address is optional:
>
> "If the "request" parameter is provided and backwards compatibility is
> not required, then the bitcoin address portion of the URI may be
> omitted (the URI will be of the form: bitcoin:?request=... )."

Sounds good.

I'd still like to see some effort to avoid losing metadata and
reducing the responsibilities of the sender.

I see there's an implementation difficulty in avoiding to broadcast a
transaction, but for example, if a payment_uri is specified, and it
cannot be contacted (at all), the transaction should fail. As soon as
you manage to connect, and have at least attempted to submit the
transaction, the merchant may have received it, and you want to mark
the coins spent, so store it after that point. But without such
protection we'll likely see a unnecessary payments happening without
metadata, when the payment server cannot be contacted for some reason.

Also, the receiver most certainly needs a P2P implementation (and
probably a strongly validating one) to verify incoming transactions,
so having him broadcast it shouldn't be hard. I don't think the client
should be required to stay online to broadcast at all, after a
paymentACK is received. The transaction arrived safely at that point.

-- 
Pieter

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Jouke Hofman]

On 08/07/2013 11:10 PM, Gavin Andresen wrote:
> I'd also like to hear from merchants: any issue with your payment
> processing server having "broadcast transaction" functionality?
> 

On the contrary, we would prefer to broadcast the transaction ourselves.

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Andreas Petersson]

I was just reviewing the integration work to integrate the Payment
Protocol into our products. Is there any notion of a standardized
invoice serialisation? If i pay for two Burgers and one Club Mate, how
would my Bitcoin Wallet be able to know that? Right now, i would simply
put that into "memo" and come up with my own serialisation mechanism.

Second, is there a way to communicate acceptance levels of TX
(unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?

-Andreas

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson <andreas@petersson.at>wrote:

> I was just reviewing the integration work to integrate the Payment
> Protocol into our products. Is there any notion of a standardized
> invoice serialisation? If i pay for two Burgers and one Club Mate, how
> would my Bitcoin Wallet be able to know that?


No. There are XML-based (shudder) standards for electronic invoicing that
include all sorts of bells and whistles; the PaymentDetails message could
easily encapsulate one of them in an 'invoice' field extension. Or we could
reinvent the wheel and come up with our own, but I'd rather use an existing
standard (or maybe a subset of an existing standard).

I didn't want to wade into that swamp for the 1.0 version of the payment
protocol.


> Right now, i would simply
> put that into "memo" and come up with my own serialisation mechanism.
>

"Two Burgers, one Club Mate" seems pretty user-friendly.

Second, is there a way to communicate acceptance levels of TX
> (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?
>

No, because the Payment->PaymentACK communication round-trip is done in
one, non-persistent http request-response round-trip.

I don't think we want to allow merchants to push messages to the wallet
(wouldn't take long for merchants to use the opportunity to push annoying
advertising at me, I think), and I don't think we want wallets to poll the
merchant. Although maybe a payment protocol version 2.0 feature could be a
PaymentACK extension that says "ask me how the transaction is going at THIS
URL in THIS many minutes."

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 2397 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]

I think the confidence of the tx is not really the users concern anyway.
They wrote it so they know it's valid. If the merchant disagrees for some
reason then the user can find out, out of band when the goods/services are
not delivered.


On Tue, Aug 20, 2013 at 1:19 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson <andreas@petersson.at>wrote:
>
>> I was just reviewing the integration work to integrate the Payment
>> Protocol into our products. Is there any notion of a standardized
>> invoice serialisation? If i pay for two Burgers and one Club Mate, how
>> would my Bitcoin Wallet be able to know that?
>
>
> No. There are XML-based (shudder) standards for electronic invoicing that
> include all sorts of bells and whistles; the PaymentDetails message could
> easily encapsulate one of them in an 'invoice' field extension. Or we could
> reinvent the wheel and come up with our own, but I'd rather use an existing
> standard (or maybe a subset of an existing standard).
>
> I didn't want to wade into that swamp for the 1.0 version of the payment
> protocol.
>
>
>> Right now, i would simply
>> put that into "memo" and come up with my own serialisation mechanism.
>>
>
> "Two Burgers, one Club Mate" seems pretty user-friendly.
>
> Second, is there a way to communicate acceptance levels of TX
>> (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?
>>
>
> No, because the Payment->PaymentACK communication round-trip is done in
> one, non-persistent http request-response round-trip.
>
> I don't think we want to allow merchants to push messages to the wallet
> (wouldn't take long for merchants to use the opportunity to push annoying
> advertising at me, I think), and I don't think we want wallets to poll the
> merchant. Although maybe a payment protocol version 2.0 feature could be a
> PaymentACK extension that says "ask me how the transaction is going at THIS
> URL in THIS many minutes."
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&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: 4081 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]

BTW, on the "make qrcodes more scannable" front -- is it too late to change
BIP 72 so the new param is just "r" instead of "request"? Every byte helps
when it comes to qrcodes ...


On Tue, Aug 20, 2013 at 12:05 PM, Mike Hearn <mike@plan99.net> wrote:

> I think the confidence of the tx is not really the users concern anyway.
> They wrote it so they know it's valid. If the merchant disagrees for some
> reason then the user can find out, out of band when the goods/services are
> not delivered.
>
>
> On Tue, Aug 20, 2013 at 1:19 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
>
>> On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson <andreas@petersson.at>wrote:
>>
>>> I was just reviewing the integration work to integrate the Payment
>>> Protocol into our products. Is there any notion of a standardized
>>> invoice serialisation? If i pay for two Burgers and one Club Mate, how
>>> would my Bitcoin Wallet be able to know that?
>>
>>
>> No. There are XML-based (shudder) standards for electronic invoicing that
>> include all sorts of bells and whistles; the PaymentDetails message could
>> easily encapsulate one of them in an 'invoice' field extension. Or we could
>> reinvent the wheel and come up with our own, but I'd rather use an existing
>> standard (or maybe a subset of an existing standard).
>>
>> I didn't want to wade into that swamp for the 1.0 version of the payment
>> protocol.
>>
>>
>>> Right now, i would simply
>>> put that into "memo" and come up with my own serialisation mechanism.
>>>
>>
>> "Two Burgers, one Club Mate" seems pretty user-friendly.
>>
>>  Second, is there a way to communicate acceptance levels of TX
>>> (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?
>>>
>>
>> No, because the Payment->PaymentACK communication round-trip is done in
>> one, non-persistent http request-response round-trip.
>>
>> I don't think we want to allow merchants to push messages to the wallet
>> (wouldn't take long for merchants to use the opportunity to push annoying
>> advertising at me, I think), and I don't think we want wallets to poll the
>> merchant. Although maybe a payment protocol version 2.0 feature could be a
>> PaymentACK extension that says "ask me how the transaction is going at THIS
>> URL in THIS many minutes."
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> ------------------------------------------------------------------------------
>> Introducing Performance Central, a new site from SourceForge and
>> AppDynamics. Performance Central is your source for news, insights,
>> analysis and resources for efficient Application Performance Management.
>> Visit us today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&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: 4722 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net> wrote:

> BTW, on the "make qrcodes more scannable" front -- is it too late to
> change BIP 72 so the new param is just "r" instead of "request"? Every byte
> helps when it comes to qrcodes ...
>

Not too late, assuming there are no objections. Smaller QR codes is a very
good reason to change it.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 760 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

We could also say that if protocol part (https://) is missing, it's implied
automatically. So just:

bitcoin:1abc........?r=bob.com/r/aZgR

I think that's about as small as possible without re-using the pubkey as a
token in the url.


On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> BTW, on the "make qrcodes more scannable" front -- is it too late to
>> change BIP 72 so the new param is just "r" instead of "request"? Every byte
>> helps when it comes to qrcodes ...
>>
>
> Not too late, assuming there are no objections. Smaller QR codes is a very
> good reason to change it.
>
> --
> --
> Gavin Andresen
>

[-- Attachment #2: Type: text/html, Size: 1639 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Andreas Schildbach]

While it's good to save space, I'm at the moment not convinced that
taking a de-route via an URL is a good idea to begin with.

The main problem is trust. If you scan a QR code from a foreign phone,
you trust that that phone is owned by the one you want to send money to.
By adding the HTTP request that trust is voided.

As soon as there is a BIP70 implementation, I will begin playing with
putting the payment request directly into the QR code.


On 09/25/2013 11:27 AM, Mike Hearn wrote:
> We could also say that if protocol part (https://) is missing, it's
> implied automatically. So just:
> 
> bitcoin:1abc........?r=bob.com/r/aZgR <http://bob.com/r/aZgR>
> 
> I think that's about as small as possible without re-using the pubkey as
> a token in the url.
> 
> 
> On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen <gavinandresen@gmail.com
> <mailto:gavinandresen@gmail.com>> wrote:
> 
>     On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net
>     <mailto:mike@plan99.net>> wrote:
> 
>         BTW, on the "make qrcodes more scannable" front -- is it too
>         late to change BIP 72 so the new param is just "r" instead of
>         "request"? Every byte helps when it comes to qrcodes ...
> 
> 
>     Not too late, assuming there are no objections. Smaller QR codes is
>     a very good reason to change it.
>      
>     -- 
>     --
>     Gavin Andresen
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3187 bytes --]

It won't fit. But I don't see the logic. A URI contains instructions for
making a payment. If that instruction is "pay to this address" or "download
this file and do what you find there", it's no different unless there's
potential for a MITM attack. If the request URL is HTTPS or a secured
Bluetooth connection then there's no such possibility.




On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> While it's good to save space, I'm at the moment not convinced that
> taking a de-route via an URL is a good idea to begin with.
>
> The main problem is trust. If you scan a QR code from a foreign phone,
> you trust that that phone is owned by the one you want to send money to.
> By adding the HTTP request that trust is voided.
>
> As soon as there is a BIP70 implementation, I will begin playing with
> putting the payment request directly into the QR code.
>
>
> On 09/25/2013 11:27 AM, Mike Hearn wrote:
> > We could also say that if protocol part (https://) is missing, it's
> > implied automatically. So just:
> >
> > bitcoin:1abc........?r=bob.com/r/aZgR <http://bob.com/r/aZgR>
> >
> > I think that's about as small as possible without re-using the pubkey as
> > a token in the url.
> >
> >
> > On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen <gavinandresen@gmail.com
> > <mailto:gavinandresen@gmail.com>> wrote:
> >
> >     On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net
> >     <mailto:mike@plan99.net>> wrote:
> >
> >         BTW, on the "make qrcodes more scannable" front -- is it too
> >         late to change BIP 72 so the new param is just "r" instead of
> >         "request"? Every byte helps when it comes to qrcodes ...
> >
> >
> >     Not too late, assuming there are no objections. Smaller QR codes is
> >     a very good reason to change it.
> >
> >     --
> >     --
> >     Gavin Andresen
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&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: 4969 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Andreas Schildbach]

On 09/25/2013 01:15 PM, Mike Hearn wrote:

> It won't fit.

Why do you think that? Of course, I would skip the certificate, as its
unnecessary if you see your partner in person.

> But I don't see the logic. A URI contains instructions for
> making a payment. If that instruction is "pay to this address" or
> "download this file and do what you find there", it's no different
> unless there's potential for a MITM attack. If the request URL is HTTPS
> or a secured Bluetooth connection then there's no such possibility.

HTTPS trust is utterly broken unless you fix it by adding the
certificate or a fingerprint to the QR code. Bluetooth is not present in
every case, e.g. QR codes scanned from the web. (Also, we currently
don't have a concept of allowing both. The receiver forces you to either
use BT or HTTP.)

So yes, MITM is what I'm worrying about. When I'm scanning a QR code
from a phone, you don't have that problem (unless sophisticated optical
attacks emerge). Also, the HTTP request can fail and/or be slow, making
the whole payment process more difficult than necessary.


> On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach
> <andreas@schildbach.de <mailto:andreas@schildbach.de>> wrote:
> 
>     While it's good to save space, I'm at the moment not convinced that
>     taking a de-route via an URL is a good idea to begin with.
> 
>     The main problem is trust. If you scan a QR code from a foreign phone,
>     you trust that that phone is owned by the one you want to send money to.
>     By adding the HTTP request that trust is voided.
> 
>     As soon as there is a BIP70 implementation, I will begin playing with
>     putting the payment request directly into the QR code.
> 
> 
>     On 09/25/2013 11:27 AM, Mike Hearn wrote:
>     > We could also say that if protocol part (https://) is missing, it's
>     > implied automatically. So just:
>     >
>     > bitcoin:1abc........?r=bob.com/r/aZgR <http://bob.com/r/aZgR>
>     <http://bob.com/r/aZgR>
>     >
>     > I think that's about as small as possible without re-using the
>     pubkey as
>     > a token in the url.
>     >
>     >
>     > On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen
>     <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>
>     > <mailto:gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>>>
>     wrote:
>     >
>     >     On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net
>     <mailto:mike@plan99.net>
>     >     <mailto:mike@plan99.net <mailto:mike@plan99.net>>> wrote:
>     >
>     >         BTW, on the "make qrcodes more scannable" front -- is it too
>     >         late to change BIP 72 so the new param is just "r" instead of
>     >         "request"? Every byte helps when it comes to qrcodes ...
>     >
>     >
>     >     Not too late, assuming there are no objections. Smaller QR
>     codes is
>     >     a very good reason to change it.
>     >
>     >     --
>     >     --
>     >     Gavin Andresen
>     >
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > October Webinars: Code for Performance
>     > Free Intel webinars can help you accelerate application performance.
>     > Explore tips for MPI, OpenMP, advanced profiling, and more. Get
>     the most from
>     > the latest Intel processors and coprocessors. See abstracts and
>     register >
>     >
>     http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>     >
>     >
>     >
>     > _______________________________________________
>     > Bitcoin-development mailing list
>     > Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>     >
> 
> 
> 
>     ------------------------------------------------------------------------------
>     October Webinars: Code for Performance
>     Free Intel webinars can help you accelerate application performance.
>     Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>     most from
>     the latest Intel processors and coprocessors. See abstracts and
>     register >
>     http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 4186 bytes --]

On 25 September 2013 13:15, Mike Hearn <mike@plan99.net> wrote:

> It won't fit. But I don't see the logic. A URI contains instructions for
> making a payment. If that instruction is "pay to this address" or "download
> this file and do what you find there", it's no different unless there's
> potential for a MITM attack. If the request URL is HTTPS or a secured
> Bluetooth connection then there's no such possibility.
>

It depends on the attacker.  I think a large entity such as a govt or big
to medium size corporation *may* be able to MITM https, of course the
incentive to do so is probably not there ...


>
>
>
>
> On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach <
> andreas@schildbach.de> wrote:
>
>> While it's good to save space, I'm at the moment not convinced that
>> taking a de-route via an URL is a good idea to begin with.
>>
>> The main problem is trust. If you scan a QR code from a foreign phone,
>> you trust that that phone is owned by the one you want to send money to.
>> By adding the HTTP request that trust is voided.
>>
>> As soon as there is a BIP70 implementation, I will begin playing with
>> putting the payment request directly into the QR code.
>>
>>
>> On 09/25/2013 11:27 AM, Mike Hearn wrote:
>> > We could also say that if protocol part (https://) is missing, it's
>> > implied automatically. So just:
>> >
>> > bitcoin:1abc........?r=bob.com/r/aZgR <http://bob.com/r/aZgR>
>> >
>> > I think that's about as small as possible without re-using the pubkey as
>> > a token in the url.
>> >
>> >
>> > On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen <
>> gavinandresen@gmail.com
>> > <mailto:gavinandresen@gmail.com>> wrote:
>> >
>> >     On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net
>> >     <mailto:mike@plan99.net>> wrote:
>> >
>> >         BTW, on the "make qrcodes more scannable" front -- is it too
>> >         late to change BIP 72 so the new param is just "r" instead of
>> >         "request"? Every byte helps when it comes to qrcodes ...
>> >
>> >
>> >     Not too late, assuming there are no objections. Smaller QR codes is
>> >     a very good reason to change it.
>> >
>> >     --
>> >     --
>> >     Gavin Andresen
>> >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > October Webinars: Code for Performance
>> > Free Intel webinars can help you accelerate application performance.
>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>> most from
>> > the latest Intel processors and coprocessors. See abstracts and
>> register >
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>> >
>> >
>> >
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&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: 6682 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On Wed, Sep 25, 2013 at 1:33 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> Why do you think that? Of course, I would skip the certificate, as its
> unnecessary if you see your partner in person.
>

OK, it might fit if you don't use any of the features the protocol provides
:) You can try it here:

https://bitcoincore.org/~gavin/createpaymentrequest.php


> HTTPS trust is utterly broken unless you fix it by adding the
>
certificate or a fingerprint to the QR code.
>

It's not "utterly broken", that's over-dramatic. It's just the best that
can be done with todays technology. I wrote about the SSL PKI and how it's
being upgraded here:

https://bitcointalk.org/index.php?topic=300809.0

If you're thinking about governments and so on subverting CA's, then there
is a plan for handling that (outside the Bitcoin world) called certificate
transparency which is being implemented now.

Now when you are getting a QR code from the web, it's already being served
over HTTPS. So if you're up against an attacker who can break a CA in order
to steal your money, then you already lose, the QRcode itself as MITMd.

In the Bluetooth case we might have to keep the address around and use it
to do ECDHE or something like that. The current BT support doesn't need
that because it's just blasting out a tx, the entire protocol is write
only. Once it's reading data as well then it'll need a custom security
layer.

[-- Attachment #2: Type: text/html, Size: 2657 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Andreas Schildbach]

On 09/25/2013 01:45 PM, Mike Hearn wrote:

> OK, it might fit if you don't use any of the features the protocol
> provides :)

Now you're dver-dramaticing (-:

I'm just skipping one feature which I think is useless for QR codes
scanned in person.

> You can try it here:

Thanks. A typical request would be around 60 bytes, which should produce
an URL with around 100 chars. That should be fine for scanning, but I
will experiment.

> If you're thinking about governments and so on subverting CA's, then
> there is a plan for handling that (outside the Bitcoin world) called
> certificate transparency which is being implemented now.

Good to hear. Let's see if it gets momentum.

> Now when you are getting a QR code from the web, it's already being
> served over HTTPS. So if you're up against an attacker who can break a
> CA in order to steal your money, then you already lose, the QRcode
> itself as MITMd.

Sure. I was talking about QR codes scanned in person.

> In the Bluetooth case we might have to keep the address around and use
> it to do ECDHE or something like that.

Yeah, will look at that as soon as we're implementing the payment
protocol fully.

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Jeff Garzik]

On Wed, Sep 25, 2013 at 6:28 AM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> As soon as there is a BIP70 implementation, I will begin playing with
> putting the payment request directly into the QR code.

You may test with Bitcoin-QT right now.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Jeff Garzik]

BitPay experimented with QR codes in low light, restaurant and other
conditions.  QR codes become difficult to use even at 100 chars.

On the merchant side, we prefer a short URL that speaks payment
protocol if visited via bitcoin client, but will gracefully work if
scanned by a phone with zero bitcoin support -- you will simply be
redirected to a BitPay invoice page for a normal browser.



On Wed, Sep 25, 2013 at 7:59 AM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> On 09/25/2013 01:45 PM, Mike Hearn wrote:
>
>> OK, it might fit if you don't use any of the features the protocol
>> provides :)
>
> Now you're dver-dramaticing (-:
>
> I'm just skipping one feature which I think is useless for QR codes
> scanned in person.
>
>> You can try it here:
>
> Thanks. A typical request would be around 60 bytes, which should produce
> an URL with around 100 chars. That should be fine for scanning, but I
> will experiment.
>
>> If you're thinking about governments and so on subverting CA's, then
>> there is a plan for handling that (outside the Bitcoin world) called
>> certificate transparency which is being implemented now.
>
> Good to hear. Let's see if it gets momentum.
>
>> Now when you are getting a QR code from the web, it's already being
>> served over HTTPS. So if you're up against an attacker who can break a
>> CA in order to steal your money, then you already lose, the QRcode
>> itself as MITMd.
>
> Sure. I was talking about QR codes scanned in person.
>
>> In the Bluetooth case we might have to keep the address around and use
>> it to do ECDHE or something like that.
>
> Yeah, will look at that as soon as we're implementing the payment
> protocol fully.
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4005 bytes --]

Low light shouldn't be an issue for QRcodes generated by phones. They have
backlit screens that should always be bright enough. I can see how it might
be an issue for printed codes.

If your phone has no Bitcoin app installed then being redirected to an
invoice page is pretty useless, you still won't be able to pay the bill no
matter what (where do you get the money from?). If they are just raw HTTP
URLs then it means the effect of scanning a QRcode with a standalone
scanner app is different to scanning it inside the wallet, which is unlike
all other uses of QRcodes I know of. So I'm not really convinced by that UX
yet. Perhaps we can thrash it out in Amsterdam. Right now I'm thinking
QRcodes should always contain bitcoin URIs.


On Wed, Sep 25, 2013 at 4:31 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> BitPay experimented with QR codes in low light, restaurant and other
> conditions.  QR codes become difficult to use even at 100 chars.
>
> On the merchant side, we prefer a short URL that speaks payment
> protocol if visited via bitcoin client, but will gracefully work if
> scanned by a phone with zero bitcoin support -- you will simply be
> redirected to a BitPay invoice page for a normal browser.
>
>
>
> On Wed, Sep 25, 2013 at 7:59 AM, Andreas Schildbach
> <andreas@schildbach.de> wrote:
> > On 09/25/2013 01:45 PM, Mike Hearn wrote:
> >
> >> OK, it might fit if you don't use any of the features the protocol
> >> provides :)
> >
> > Now you're dver-dramaticing (-:
> >
> > I'm just skipping one feature which I think is useless for QR codes
> > scanned in person.
> >
> >> You can try it here:
> >
> > Thanks. A typical request would be around 60 bytes, which should produce
> > an URL with around 100 chars. That should be fine for scanning, but I
> > will experiment.
> >
> >> If you're thinking about governments and so on subverting CA's, then
> >> there is a plan for handling that (outside the Bitcoin world) called
> >> certificate transparency which is being implemented now.
> >
> > Good to hear. Let's see if it gets momentum.
> >
> >> Now when you are getting a QR code from the web, it's already being
> >> served over HTTPS. So if you're up against an attacker who can break a
> >> CA in order to steal your money, then you already lose, the QRcode
> >> itself as MITMd.
> >
> > Sure. I was talking about QR codes scanned in person.
> >
> >> In the Bluetooth case we might have to keep the address around and use
> >> it to do ECDHE or something like that.
> >
> > Yeah, will look at that as soon as we're implementing the payment
> > protocol fully.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&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: 5561 bytes --]

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/25/2013 07:35 AM, Melvin Carvalho wrote:

> It depends on the attacker.  I think a large entity such as a govt
> or big to medium size corporation *may* be able to MITM https, of
> course the incentive to do so is probably not there ...

DLP (data loss prevention) products usually have MITM capability, to
make sure that proprietary information isn't being exfiltrated.  Also,
some companies have full packet capture policies.  The technology is
out there and people buy and use it.  Whether or not they're going to
care about Bitcoin URIs in the short term, I don't know.

Some of the companies documented here have such products:

http://bluecabinet.info/wiki/Blue_cabinet#List_of_companies

You are correct in that the incentive to carry out MITM attacks in
this use case may not be there.  However, detecting transactions may
be more useful to an attacker than meddling with them.

- -- 
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

"Shiloh?  Is your name Shiloh?  Can I talk to you?"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJDC30ACgkQO9j/K4B7F8FungCgyQtkyiQIekhlv1/Nqdd/JAIV
3EgAoKW8wTOI11lEq0ieOsRiQmnkM9w6
=W50W
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Wed, Sep 25, 2013 at 01:35:48PM +0200, Melvin Carvalho wrote:
> On 25 September 2013 13:15, Mike Hearn <mike@plan99.net> wrote:
> 
> > It won't fit. But I don't see the logic. A URI contains instructions for
> > making a payment. If that instruction is "pay to this address" or "download
> > this file and do what you find there", it's no different unless there's
> > potential for a MITM attack. If the request URL is HTTPS or a secured
> > Bluetooth connection then there's no such possibility.
> >
> 
> It depends on the attacker.  I think a large entity such as a govt or big
> to medium size corporation *may* be able to MITM https, of course the
> incentive to do so is probably not there ...

...until the Bitcoin payment protocol showed up and let anyone with the
ability to MITM https turn that ability into untraceable cash.

I won't be at all surprised if one of the most valuable things to come
out of the payment protocol using the SSL PKI infrastructure is to give
us a good understanding of exactly how it's broken, and to give everyone
involved good reasons to fix it.

Even if the flaws of SSL PKI were exploited as a way to harm bitcoin by
governments and other large players - and SSL PKI remained unfixed - I'd
much rather have that solid evidence that it was broken than not.

-- 
'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]