Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Christophe Biocca]

 But the face-to-face case isn't intrinsically dependent on SSL security, and 
 it's nice not to introduce that attack vector...

If the only concern is to make scan-to-pay work without reliance on
SSL's PKI, it might be better to specify the payment protocol url
*and* the public key used for signing right in the qr code. The wallet
connects to the url, fetches the payment request (maybe over a secure
connection, maybe not, doesn't matter), and verifies the signature
matches the public key from the qr code.

Downsides compared to embedding the entire request:
Payee needs to host/serve requests somewhere online. This introduces
reliability and DoS concerns.
Payer needs an internet connection to fetch the request.

Advantages:
Serve variable payment requests from the same qr code (improving
recipient privacy).
Still no hard dependency on CAs. Even if both CA and DNS are
compromised by an attacker, the worst they can do is Denial of
Service.
Optionally use CAs so that the wallet can attach an identity to who
you're paying by QR code. This partly addresses the problem of the
waiter overwriting the QR code. A non-PKI transaction would simply
show Unknown recipient.
Much smaller QR code (only overhead is the key parameter, and you
could use a boolean param + the address as public key hack Mike
mentionned, for only 4 characters of overhead).
No need for a backward-incompatible bitcoin: scheme

On Mon, Jan 27, 2014 at 3:34 PM, Roy Badami r...@gnomon.org.uk wrote:
 On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
 On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
 andr...@schildbach.de wrote:

  SCAN TO PAY
  For scan-to-pay, the current landscape looks different. I assume at
  least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
  into a QR-code. Nevertheless, I tried to encode a payment request into
  the bitcoin URL. I used my existing work on encoding transactions into
  QR-codes. Steps to encode:

 Really interesting work. When using scan-to-pay, after the payer scans the
 QR code with the protobuf PaymentRequest (not a URL to download the
 PaymentRequest) are they using their own connectivity to submit the
 Payment response?

 If we assume connectivity on the phone, might as well just get a URL from
 the QR code and re-use existing infrastructure for serving that?

 My first thought was likewise.  In the case where the phone needs
 Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?

 I'm assuming that every client will have to support this is any case,
 since it's effectively mandated by the BIP, so why add another mode of
 operation?

 However, PaymentRequest-over-QR-code does seem to me to have one
 rather attractive advantage: the authentication model is orders of
 magnitude simpler and more intuitive for a face-to-face transaction
 than anything else.  You're saying pay the coins to that thing over
 there displaying that QR code.  Which, most of the time, is exactly
 what you want.

 In the web case, it's fine to ignore the case where the URL domain has
 been subverted (and an cert obtained by the attacker) because in that
 case you've lost before you even get to payments (MitM attacker shows
 you a modified web page with different payment details).  But the
 face-to-face case isn't intrinsically dependent on SSL security, and
 it's nice not to introduce that attack vector...

 roy


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP70 message delivery reliability

[Chuck]

I spoke briefly with Peter (sipa). He recommend I forward this post to 
the mailing list for further discussion.

My apologies if this has been discussed before, but I was curious about 
some things re BIP70 message delivery.  In particular, I don't clearly 
see the value of the PaymentACK message.  Allow me to explain...

The current BIP70 workflow designates PaymentACK as the final message in 
a payment exchange. However, it doesn't appear that any mention is made 
of what happens if that delivery fails. I assume that re-delivery is 
left as a detail to the implementation, actually.

For sake of argument, let's assume that PaymentACK is never delivered 
either because of a network outage or a malicious merchant or 
incompatible software between wallets or a bug.  I ask myself: what 
would be necessary for sufficient proof of payment, say, to an arbiter?  
I presume the receipt R=(PaymentRequest,[transactions]) would suffice.  
Am I correct there?

But if the PaymentRequest and broadcasted transactions are enough to 
prove payment, what's the point of the Payment message? The merchant 
never has to verify the Payment message, possibly maliciously ignoring 
it.  In the well-behaved case, I presume the point is to help the 
merchant associate some arbitrary data with the purchase as well as 
provide a refunding address for the customer.  If that's the case, 
couldn't this protocol be slightly improved like so:

Required steps:
1. Customer clicks pay now
2. Merchant sends PaymentRequest/PaymentDetails, which should be signed
3. Customer builds a set of transactions and sends a new 
PaymentApprovalRequest message which includes a refund address and the 
unsigned transactions and their associated fully-signed transaction 
hash, the whole message signed with the private key of the refund address.
4. Merchant responds with PaymentApproved message, signing the 
PaymentApprovalRequest message with the same key from step 2.

Optional steps:
5. The customer can send a Payment message, which is only a set of 
signed transactions.
6. The merchant can respond with a PaymentACK message.

In Step 4, the merchant is acknowledging that if the transactions 
provided PaymentApprovalRequest are broadcast, then payment is complete 
and no other steps are required. Steps 5 and 6 aren't required but are 
considered considerate:)

After step 4, all the merchant needs is to do is watch for the 
transactions that were listed in PaymentApprovalRequest.  The 
(PaymentApproved,[signed transactions]) pair is the customer's proof of 
payment and this proof of payment includes a refund address that the 
merchant has agreed to prior to payment, instead of after.  Step 3  4 
also allow the merchant to verify transactions, providing an extra layer 
of redundancy.  The merchant will also be able to ack on fees, time lock 
(time sensitive purchases?), sequence numbers, etc.

In Step 3, it's critical the customer sign the message with the private 
key of the refund address, so that the merchant can be confident the 
refund address is correct.

In each step along the way until step 5, if a message delivery fails 
nobody is harmed because the purchase is incomplete.

Thoughts?

Chuck

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development