Topic: BIP 0021 usability enhancement for paying tips in restaurant/bar conveniently (Read 2041 times)

I'm all for a tipping extension to the payment protocol, once we actually get it up and running.

different people make different trade-offs, as always. There's not one right solution.

I happen to live in central Europe. E.g. in Germany tipping around 5 to 15% is usual, depending on how happy you were with the service (no strict 15% rule like in US). Similar in many other europ countries, e.g france, czech, slowakia, austria, ...(but not in finland i agree)

yeah, but having it on the screen only if needed would be nicer and avoid "accidental" tipping for normal payments.

The app can toggle Bluetooth on and off. But I keep BT on all the time as do many other people. Computers mean risk. Most users won't want to micromanage that risk, to be frank.

I think it's worth remembering that in large parts of the world tipping is not common because service is included in the price. Integrating tipping is useful in the states, and is less useful in Europe. The simplest implementation doesn't involve any protocol changes at all - just a +10% button on the "send coins" screen of the mobile wallets.

Well, from the fact that BIP 0021 contains "otherparam" and "reqparam" today, I had to assume (and did assume) that it is open for further enhancements. Also the text in today's "BIP 0021" wiki goes along these lines.

If it is (was?) decided to freeze the URI scheme acc. to today's BIP 0021 forever, I propose to mention this in the BIP 0021 wiki, to avoid that people like me spend time to think up and write down things in vain.

I still think that a single simple optional parameter like "&tip=0.08" does not harm and has it's justified benefit in a by now neglected major payment scenario. Indeed I think the scenarios "simple payment w/o tip" and "simple payment with tip" are the only two dominating payment scenarios in everyday's use, and all the rest (incl. humble-bundle multi-output payment scenarios) is and will remain marginal, so the rest of my "wiki discussion" contributions can be rejected if considered yielding endless amendments, I wouldn't object.

All I keep pleading for is that all the major payment scenarios (of which there exist only two!) should be well accounted for by BIP 0021, and currently one of the two is not considered.

But I will not continue this discussion any further if it is not welcome and if my opinion is singular.

Excellent! The payer can pay w/o own internet connection and just sends the signed transaction to the recipient's phone/tablet (via BT/NFC/animated QR codes)! I was thinking along the very same lines recently and came to the conclusion for myself that exactly this is needed (because of scenarios like "roaming", "bad indoor cellphone coverage" or "cellphone network overload").  Glad to read that this is already being conceptualized! (The only drawback in UX is that customer has to activate/deactivate BT before/after the payment manually, unless BT is active all the time, which many users incl. myself don't like for good reasons)

Just a remark: It must be ensured that the customer really connects (via BT) to the correct tablet and not to a "hijacker" who shows me a different payment address. So on top of the MAC address (which could be imitated by a nearby attacker's phone I suppose) also a one-time session key (PIN or so, even better sth. "assymetric") and/or the (main) payment address should be included in this QR code/NFC code that initiates the BT session. But I guess mechanisms like these are already part of the concept.

Why I still stick to my original proposal (not in substitution but in complement to this one, which has my full support):
Some users might be hesitant using BT, given the various BT security breaches that have been reported in the past on various phones. Whenever I switch on my BT, I could be a potential target (need not even be related to Bitcoin) of an attacker exploiting a bug in the BT stack on my phone. And generally, some users might feel uncomfortable establishing any peer-to-peer BT connection to a foreign device: "Maybe that device exploits some vulnerability of the BT bitcoin payment protocol stack implemented on my phone...".

If you only have a normal browser and nothing else then you can't make the payment, you need a wallet, at which point it can register to handle bitcoin URIs. So whilst I understand the appeal of this, I don't think it will have the effect you would think. It also causes problems in other ways, for instance, it's harder to do the Bluetooth trick - which makes a huge UX difference, especially in places like Europe where roaming is far more common. Imagine if you lost internet access anytime you travelled out of state, that's the crappy world we poor Europeans have to live with  (at least until the EU finishes beating up the cell carriers, then it'll just be us in Switzerland that suffer).

I'm all for short QRcodes, but I think we should probably keep them holding bitcoin URIs for now.

No, this stuff goes into the payment protocol, end of story. Extending the URI spec is a non starter for the reasons Jeff explained, it's simply not possible to keep stuffing things into that endlessly.

But don't worry - it can still show up immediately in a restaurant. The way the payment protocol can be used in the tablet/mobile scenario is that the recipient of the money serves the payment request (hopefully signed) via Bluetooth. The BT MAC goes in the QRcode/NFC data so the device knows where to connect. The Android wallet already has a primitive version of this up and running, in the labs section of the settings screen. It also means the payer doesn't require any internet connection at all - all the communication is with the waiter/waitresses device. The delay is hardly noticeable and the user experience is entirely transparent, it doesn't look any different to today (there's no pairing involved because we use unauthenticated sockets).

At the moment the Bluetooth protocol is a custom thing, it's not the payment protocol. Once bitcoinj supports the payment protocol, we'll start transitioning Android users to the newer scheme and then open up a BIP to standardise that.

Of course this only works if the receiver of the funds is using a native app. BitPay will want to produce a native Android app for tablet users anyway, because otherwise the sender of the funds always needs internet access and in many places that's not a given. For example in some restaurants/shops the cell reception isn't so great, and when people travel they won't have roaming access. Actually it'd make sense for them to hire Andreas to do that, if he's so willing. It also has the advantage that merchants could sign the payment requests under their own identity without having to give their SSL private keys to BitPay, which many places won't be willing to do (but putting it into their own PoS systems might be easier to countenance).

My scenario refers to a real-world scenario where the QR code is displayed on a tablet (or large screen smartphone) of the waiter/waitress. So low light is not an issue.

But of course the QR code could also be printed on the paper bill/receipt, maybe better to scan on very sunny days.

I have been experimenting myself with 3 smartphones. The cheapest one was an old&cheap SE Xperia X8 with a low resol. camera WITHOUT autofocus. I was scanning a 160 char QR code on 28x28mm and a 320 char QR code on 36x36mm from 2 different phone screens w/o any problem.

I don't think this solves my problem, see my prev. post.

No, on the contrary. I as a customer and user of the wallet app who scans the QR code of the restaurant's tablet want to arrive at the "send" dialog (incl. tip payment option) immediately after scanning the QR code. I do NOT want to inconveniently go via my browser, click here, tap there, etc. I as a "normal user" want maximum comfort and minimum number of taps.

(see discussion area of bip 0021 wiki for best practice example)

Also, I want a solution that works independently of a central server. If the web server where the URL points to is down I could not make the payment.

See above, even 320 characters no problem even w/o autofocus.

See above, experiments work well. Maybe bitpay's experiments are "biased" because they want people to use their service. Fair enough, I sincerely wish them all success. But I encourage everyone make your own experiments and do not believe unverified statements that might be biased by commercial interests.

See above - well above 200 chars no problem even w/o autofocus.


After all, why not adding an amendment (new *optional* parameters, backwards compatible) to bip 0021 for enabling optimum user experience for THE most frequent "non-simple" brick&mortar payment scenario, which is paying with tips.

The BIP 0021 is about what the user (paying customer) will see on his/her wallet app's GUI immediately (without any annoying extra taps or browser involvement) after scanning the restaurant's tablet's QR code (=bill).

This is about maximizing usability/comfort/user experience (UX).

This is very desireable, especially for a payment scenario as frequent as this.

This cannot be achieved via payment protocol enhancements.

BitPay has been experimenting with QR codes, scanning in low light conditions, etc.

Conclusions:

1) You want the payment protocol.

2) You want your QR code to go to a URL that will display something useful on a normal browser, or a Bitcoin Payment Request if bitcoin-aware.

3) Use a short URL for the payment URL!  Critical for QR codes, in low light conditions.

4) Displays, phones, and shiny cards are sub-optimal for displaying QR codes you expect a phone to read.

5) Printed QR code, containing a short URL, is optimal.  The shorter the URL -- hopefully 60 chars or less! -- the better the QR code error correction.

This is what the payment protocol is for. Additional features should be added there instead.

Because there is a very frequent usecase behind - an everyday's life scenario - paying in restaurants/bars/pubs. Also note that bars/pubs/restaurants are amongst the first brick and mortar businesses that accept bitcoin today, so it would be awesome if tipping were supported neatly! Today tipping is complicated, you have to manually edit the amount to be paid and make your "percentage" calculation... with the proposed enhancement (which is "perfectionized" with the "tip" key in the URN) tipping works like charm.

The tip tag must be specified for maximum user experience - everything is explained illustratively at "https://en.bitcoin.it/wiki/Talk:BIP_0021".

Thanks for the link. First, this describes another usecase than what I had in mind. Here we have two or more equally important output addresses, whereas in above idea (which is the much more frequent use case) the tip is marked as tip in the wallet app, and is something voluntary that can be modified, just read "https://en.bitcoin.it/wiki/Talk:BIP_0021" and everything gets clear.

Secondly, I do not support this exact proposal, because it uses a syntax incompatible to BIP 0021. It deviates from BIP 0021 without need. In that particular "Humble Bundel" multi-output-usecase example, it would be very easy to stay compatible, like this:

Instead of
  bitcoin:eBook+Store/175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W:0.1;Bob+Author/1F4JfsqiDTG7vjnsz5daUrz2yexQGXB8uo:1.9?message=Purchased+eBook
write it this way:
  bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.1&label=eBook+Store&req-addr=1F4JfsqiDTG7vjnsz5daUrz2yexQGXB8uo&amount=1.9&label=Bob+Author&message=Purchased+eBook

Here I use one new parameter key "req-addr" that is compatible with BIP 0021 generic "reqparam".
Moreover, we introduce the following semantical rule for the URN: We allow multiple occurrences of "req-addr", "amount" and "label" keys, and we specify:
The 1st/2nd/3rd/... occurrence of an "amount" or "label" key CORRESPONDS to the 1st/2nd/3rd/... occurrence of an address, whereas the first address comes directly after "bitcoin:" and any further address comes after a "req-addr" key.

Moreover, and this is very important, the new key here is a "req" key, which means, acc. to BIP 0021:
If an older wallet app does not yet understand "req-addr", it will discard the whole URN, thereby avoinding paying only a partial sum.


PS: In the link above some concerns are expressed that even older wallet apps may not correctly discard an URN containing a reqparam, thereby causing "devastating failure mode". This is a general problem of BIP 0021's reqparam, I agree, and this should be "fixed" in BIP 0021 itself quite easily:

The easiest way is to specify that if a URN contains at least one reqparam, then the first characters after "bitcoin:" shall be a "R-" (knowing that any valid BTC address never start with R). Thereby, any "old" wallet will automatically discard the complete URN (because the string after "bitcoin:" is not a valid bitcoin address), whereas any newer wallet app (those who understand what this "R-" means) will also understand the significance of "req-" and will correctly discard any URN that contains at least one unknown "req-" key.

So the URN above now becomes:

  bitcoin:R-175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.1&label=eBook+Store&req-addr=1F4JfsqiDTG7vjnsz5daUrz2yexQGXB8uo&amount=1.9&label=Bob+Author&message=Purchased+eBook

I tried scanning a 268 character string displayed on a 36mm x 36mm area (S3mini) with a rather old Galaxy Ace - no problem at all.

Then I tried 320 characters - no problem either.

Then I did not try any further.

As long as we're talking about URIs containing multiple recipients, why make it specific to tips?

See http://sourceforge.net/mailarchive/message.php?msg_id=30882263 for a more general sendmany URI pattern.

See https://github.com/skeltoac/bitcoin/tree/sendmany for bitcoin-qt patched to support the above pattern.

have you evaluated how well an enhanced qr code would scan using a simple camera?

IMO, we are already pushing limits in usable qr code size, especially in weak lighting conditions

Maybe the right process is to define a new BIP which defines "otherparam" of BIP 0021.

Up to now, useful enhancements identified for "otherparam" are:
 tip=
 tipaddr=

as described in "https://en.bitcoin.it/wiki/Talk:BIP_0021".

Any opinion on this from the wallet developers?
Any further useful ideas for "otherparam"?

Hello Wallet developers and POS solution makers,

hello coinbase, bitpay, blockchain.info, inputs.io, Andreas, Jan, apetersson, etc.

I just want to let you know that I have submitted a proposal for an amendment of BIP 0021 in the "discussion" section of the wiki
https://en.bitcoin.it/wiki/Talk:BIP_0021.

This should make tipping in real-world situations really effortless for the customers. Hope it will be adopted to BIP 0021, and then also to the wallet apps and merchant/POS SW.

Note: I don't know the exact process  of the BIPs, but I assume that since this is a minor downward compatible enhancement, and since extensions of this kinds have anyway be expected in todays description of BIP 0021 ("otherparams"), I assume this change does not require a new BIP but can be incorporated in the existing BIP 0021.