Payment Protocol: BIP 70, 71, 72
42 messages, 31 Jul to 26 Sep 2013. Started by Gavin Andresen.
Mike Hearn (10), Gavin Andresen (8), Roy Badami (5), Pieter Wuille (5), Andreas Schildbach (3), Melvin Carvalho (2), E willbefull (2), Jeff Garzik (2), +5 more
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
On Wed, Jul 31, 2013 at 04:28:25PM +1000, Gavin Andresen wrote:
Quoted text (5 lines)
> 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
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§ion=7> ]
On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen <gavinandresen@gmail•com>wrote:
Quoted text (32 lines)
> 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 > >
Thanks, Mike!
"PaymentRequest messages larger than 50,000 bytes should be rejected by
Quoted text (4 lines)
> the merchant's server, to mitigate denial-of-service attacks." > > Do you mean "users wallet" here? >
Yes, fixed.
Quoted text (3 lines)
> 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.
Quoted text (3 lines)
> 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
Quoted text (5 lines)
> 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)."
Quoted text (8 lines)
> "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.
Quoted text (5 lines)
> 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."
Quoted text (6 lines)
> > 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."
On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami <roy@gnomon•org•uk> wrote:
Quoted text (6 lines)
> > 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.
On 31 July 2013 13:33, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (17 lines)
> 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
Quoted text (19 lines)
> > 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 >
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:
Quoted text (35 lines)
> 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 >
On Thu, Aug 1, 2013 at 9:30 AM, E willbefull <ewillbefull@gmail•com> wrote:
Quoted text (3 lines)
> 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.
Quoted text (2 lines)
> 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...
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:
Quoted text (23 lines)
> 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 >
On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:
Quoted text (4 lines)
> 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
On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (3 lines)
> 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).
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.
Quoted text (5 lines)
> 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).
On Thu, Aug 08, 2013 at 07:10:05AM +1000, Gavin Andresen wrote:
Quoted text (1 line)
> 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
On Wed, Aug 7, 2013 at 11:17 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (13 lines)
> >> 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.
Quoted text (4 lines)
> 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.
On 08/07/2013 05:10 PM, Gavin Andresen wrote:
Quoted text (5 lines)
> 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
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
On Wed, Aug 7, 2013 at 11:44 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (9 lines)
> >> 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.
Quoted text (2 lines)
> 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.
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:
Quoted text (29 lines)
> 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
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:
Quoted text (45 lines)
> 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 >
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.
Agreed, this looks good to me.
On Thu, Aug 8, 2013 at 2:48 AM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (6 lines)
> 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.
On 08/07/2013 11:10 PM, Gavin Andresen wrote:
Quoted text (3 lines)
> 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.
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
On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson <andreas@petersson•at>wrote:
Quoted text (4 lines)
> 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.
Quoted text (3 lines)
> 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
Quoted text (2 lines)
> (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."
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:
Quoted text (55 lines)
> 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 > >
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:
Quoted text (65 lines)
> 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 >> >> >
On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (4 lines)
> 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.
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:
Quoted text (14 lines)
> 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 >
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:
Quoted text (44 lines)
> 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 >
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:
Quoted text (76 lines)
> 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 >
On 09/25/2013 01:15 PM, Mike Hearn wrote:
Quoted text (1 line)
> 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.
Quoted text (5 lines)
> 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.
Quoted text (104 lines)
> 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 >
On 25 September 2013 13:15, Mike Hearn <mike@plan99•net> wrote:
Quoted text (6 lines)
> 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 ...
Quoted text (101 lines)
> > > > > 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 > >
On Wed, Sep 25, 2013 at 1:33 PM, Andreas Schildbach <andreas@schildbach•de>wrote:
Quoted text (3 lines)
> 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
Quoted text (2 lines)
> HTTPS trust is utterly broken unless you fix it by adding the >
certificate or a fingerprint to the QR code.
Quoted text (1 line)
>
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.
On 09/25/2013 01:45 PM, Mike Hearn wrote:
Quoted text (2 lines)
> 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.
Quoted text (1 line)
> 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.
Quoted text (3 lines)
> 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.
Quoted text (4 lines)
> 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.
Quoted text (2 lines)
> 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.
On Wed, Sep 25, 2013 at 6:28 AM, Andreas Schildbach <andreas@schildbach•de> wrote:
Quoted text (2 lines)
> 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.
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:
Quoted text (47 lines)
> 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
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:
Quoted text (84 lines)
> 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 >
On 09/25/2013 07:35 AM, Melvin Carvalho wrote:
Quoted text (3 lines)
> 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?"
On Wed, Sep 25, 2013 at 01:35:48PM +0200, Melvin Carvalho wrote:
Quoted text (12 lines)
> 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.