Allow editing of Amount field when URL specifies an amount

[Derrick-]

I have run into a few cases in which a URL or QR specifies an amount, but I wanted to send more or less than that amount.

Two current examples are funding my Purse.io wallet, where the system recommends an amount in the QR, but I want to send more (or less) to my Purse wallet depending on my current plans. We are also developing a Bitcoin Enabled Wi-Fi Portal (BEWP) in which a user can pay for wi-fi access with bitcoin; and we would like to suggest an amount in the QR code in the payment portal, but allow the user to send more or less than that depending on his needs.

Please allow editing of the Amount field when an amount is read from a URL or QR code.

Optionally, but less preferable would be a setting that enabled this editing.

[dabura667]

I agree.

Once some guy posted a donation QR with 1 BTC as the amount.

Needless to say, I did not donate. lol

[matiu]

NACK. i think the advantage of QRs with amount is to simplify the user
experience. If it is abused or misued by some their should by contacted by
the payers.
On Jun 29, 2016 9:19 PM, "Dabura667" [email protected] wrote:

I agree.

Once some guy posted a donation QR with 1 BTC as the amount.

Needless to say, I did not donate. lol

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/copay/issues/4519#issuecomment-229527135, or mute
the thread
https://github.com/notifications/unsubscribe/AAGCHFwT7AmbmsolP-dBXxef-0VS9ndkks5qQwuXgaJpZM4JBqxq
.

[dabura667]

I think the way breadwallet does it is good.

1. Scan QR
2. It locks the amount so you can't change it. There is a cancel button to return to the normal sending screen.
3. If you tap the cancel button, it asks "would you like to keep the address in the send to field?" And if you tap yes, you can change the amount.

Simple for someone who uses as intended, but anyone who scans a qr, looks at the amount and immediately exits out is obviously thinking something is wrong with the amount.

But it's not that important.

[Derrick-]

@matiu Allowing to edit the amount allows the merchant, or payee to simplify the user experience. The current limitation impedes my user experience.

Please allow for discussion of this before NACKing it so fast.

[matiu]

Allowing to edit the amount allows the merchant, or payee to simplify the user experience.

I disagree. I think the that the majority of users do not need to edit the amount field of a BIP21 request, and allowing to edit it could lead to unexpected results (for example, if you are paying an invoice).

Sorry about the "fast NACK" I meant to say that I dont agree with this feature, but of course the discussion is welcomed and the issue is open.

Following Bitcoin's doc/developer-notes.md
NACK - Disagree with the code changes/concept. Should be accompanied by an explanation.

[Derrick-]

Thanks for clarifying. I do agree that the majority will not need to edit the amount; certainly I do not need to edit the amount in the vast majority of cases. The trouble is the complete inability to do so in the rare cases in which it's desired or needed.

I believe the user should be allowed to chose the amount of funds they wish to sent while still being able to take advantage of the convenience of a QR code. The alternative for a user which may need to send a different amount is to have to type the address into CoPay or send an address to the phone through a different channel, which is feels to me like a very silly and unnecessary workaround.

I really would like to hear some more discussion on this, I would like to find a way to allow editing without complicating things.

[dabura667]

I think it shouldn't be viewed as "changing the amount"

Rather, if the user cancels the payment, we should offer to leave the address there for them, just in case. The only time a user would back out of a QR payment is if there was an obvious problem (human error etc.) with the amount. Happened to me twice, and obviously the guy didn't carry a printer on him....

However, this should not be the case for BIP70 payment requests, obviously.

[Derrick-]

@dabura667

should not be the case for BIP70 payment requests, obviously.

That's a really excellent distinction and point. On my site we do serve invoices via bip70 (Which incidentally don't work in CoPay due to https://github.com/bitpay/copay/issues/4130 ).

Bip70 is for an invoice. An amount in a payment QR can legitimately be considered a suggestion based on several real-world examples.

I think it shouldn't be viewed as "changing the amount"

It is in fact changing the amount though, regardless of the procedure used to do so.

[dan-da]

should not be the case for BIP70 payment requests, obviously.

Not so obvious. In the real world:

• invoice amounts are sometimes wrong or are re-negotiated after invoice is issued.
• people sometimes break up payments between multiple payment sources/types. think: split between wallets/apps, or between btc and cash/check/credit card.
• people sometimes pay what they think should actually be owed, regardless of what invoice says.

I think we need to remember that CoPay is the wallet holder's agent, not the invoice creator's.

At a previous client's shop, they adopted a software design policy to assume the user knows what they are doing. In other words, validate and warn, but allow user to override warning any time it won't critically break things. This client found that the policy resulted in:

1. happier users, because the software was more flexible than previous versions.
2. fewer defect reports and enhancement requests, because the software wasn't constantly trying to play nanny to the users and telling them "you can't do that" just because a developer didn't envision a particular use case.

So applying this policy here, the obvious implementation would be to allow the user to edit the amount, but warn them of the consequences, and require an "I understand" acknowledgement. This popup could happen either when focus first goes to the textinput field, or by making the field read-only at first and having a separate button called "Edit amount".

[Derrick-]

@dan-da I think the issue with bip70 requests is that a different amount simply would be rejected via the protocol itself, however your comments do stand strongly with allowing the editing of a simple URL payment link/QR and I think these examples make a strong case for editing.

[dan-da]

If it would be rejected by peer(s) due to protocol then yeah, should be prevented. Ideally with an explanatory message to the user if they try to edit. Of course, I would argue that's a protocol weakness... why not partial/split payments? but that's another battle.

[dan-da]

it appears @Derrick- is correct on that point. from bip70:

transaction: One or more valid, signed Bitcoin transactions that fully pay the PaymentRequest

...

When the merchant's server receives the Payment message, it must determine whether or not the transactions satisfy conditions of payment. If and only if they do, it should broadcast the transaction(s) on the Bitcoin p2p network.

That is a little vague, but a careful reading seems to indicate the merchant should reject if the sum of tx does not "fully" cover the requested amount. Interesting that the case of overpayment is not explicitly detailed. Seems likely to be implementation-specific whether would be rejected or not.

[dabura667]

Modifying BIP70 amounts is just asking for trouble imo.

BIP21 amounts, however, are frequently automatically entered by the generating website.

I frequently see QRs with 1 BTC as the amount, and the person had no idea.

[Derrick-]

"Interesting that the case of overpayment is not explicitly detailed. Seems likely to be implementation-specific whether would be rejected or not."

BIP70 allows inclusion of a refund address, so the server could accept the overpayment and then refund the difference.

I think the take-away from this is that BIP70 is very structured, like for invoices involving a specific amount, while in common practice BIP21 amounts seem to be sometimes used as a suggestion.

My request is only involving BIP21 amounts, and that CoPay allows capturing of the address in a QR code while not absolutely requiring that any amount specified in a such a QR capture be adhered to. Perhaps it would be reasonable in this potential modification to allow the Message or Description of the transaction to be altered as well, allowing a user to add personal notes to those fields.

[tab00]

I'm glad that there is already discussion about this, as I was about to create a new Issue to request this feature.

I've been doing some testing for my app and it's annoying that I can't conveniently test partial payment and over-payment when using the QR code scanner.

Users should be allowed to change how much they want to send to any address. It's up to the merchant's system to decide whether or not the payment was enough.

[tab00]

I've been repeatedly coming across this problem of not being able to easily increase the amount to pay from what was set in the bitcoin URI.

A bitcoin amount to pay can change regularly as the exchange rate between fiat and bitcoin fluctuates. If the user scans a QR code just before the amount is updated, the user may end up making a partial instead of a full payment. The user must then make a subsequent transaction, usually for a very small amount of bitcoin and is presented with a new QR code for this remaining amount. So the user would then scan this new QR code and tries to send. However Copay does not allow to send amounts that are below a minimum value (50 μXBT?). Imagine the frustration!

I know that there are some options for the user in such a situation, such as copying and pasting the QR code (if the QR code is being displayed on the same device as the Copay app), or as a last resort, writing the address and amount manually (I don't think I've ever done that myself). But why not just allow a user to change the amount?

The user should have control of their own bitcoin and send however much he or she wishes. It should be up to the recipient to determine whether or not it was enough.