First of all, I think extensions like this need to go to the BIP7x (payment protocol) family of BIPs. BIP21 (Bitcoin URIs) are already too big and the industry is migrating to BIP70.
The idea of specifying the amount in local currency is not new and has been discussed before. I think the conclusion was always as long as conversion rates cannot be determined in a decentralized & reliable way, how would you deal with payer and payee disagreeing about the rate? What about fraud, e.g. a MITM injecting their own desired rate? At the very least I'd say it's tricky.
The "one QR code per price category" usecase is based on trust anyway – why not just up the address and let the user enter the local amount?
Topic: BIP-0021 possible extensions (Read 1188 times)
Thanks for your support!
In the list of accepted exchangeproviders a fallback would indeed be a good idea.
Hope some other people will chime in on how to proceed.
Do I add a pull request for BIP 21 or write it up somewhere else and try to convince wallet makers?
In the list of accepted exchangeproviders a fallback would indeed be a good idea.
Hope some other people will chime in on how to proceed.
Do I add a pull request for BIP 21 or write it up somewhere else and try to convince wallet makers?
Very good idea, I like it!
Maybe some fallback exchangeprovider would be senseful, in case the given url is outdated or unreachable.
Maybe some fallback exchangeprovider would be senseful, in case the given url is outdated or unreachable.
Hi all,
There are some bitcoin use-cases where I can't find a solution other than having some addendum to BIP 21.
This post is just to see if I'm missing something and whether these use cases merit a BIP 21 change or best practice addendum.
Use cases:
- merchant prints a QR code on his invoice with the exact amount in EUR/USD/...
- a club bar wants to print 3 QR codes for its 3 kinds of drinks (beer,cola,water=2 euro, wine=3 euro, ...)
Note: these use cases can also be solved by a link on the invoice and a smartphone/pc in the club bar, but sometimes a printed QR is more convenient.
Proposal:
Add these elements to the query component: fiatvalue, fiatcurr, exchangeprovider
=> can be done without changing BIP 21 by using req-fiatvalue, req-fiatcurr, req-exchangeprovider
Example:
The merchant can print a QR code with his bitcoin address, fiatvalue=50.35, fiatcurr=EUR, exchangeprovider=bitcoinaverage.com
His client can scan this the same day or many weeks later, and if his/her wallet has support it will calculate the required bitcoin amount using the bitcoinaverage.com exchange price.
On exchangeproviders:
The exchangeprovider might be considered redundant but this could be handy for payment processors so they can use their own.
To prevent arbitrary urls a list of accepted providers might be added to the BIP, or managed seperately as is done by satoshilabs for BIP 44.
Let me know what you think and please be kind
There are some bitcoin use-cases where I can't find a solution other than having some addendum to BIP 21.
This post is just to see if I'm missing something and whether these use cases merit a BIP 21 change or best practice addendum.
Use cases:
- merchant prints a QR code on his invoice with the exact amount in EUR/USD/...
- a club bar wants to print 3 QR codes for its 3 kinds of drinks (beer,cola,water=2 euro, wine=3 euro, ...)
Note: these use cases can also be solved by a link on the invoice and a smartphone/pc in the club bar, but sometimes a printed QR is more convenient.
Proposal:
Add these elements to the query component: fiatvalue, fiatcurr, exchangeprovider
=> can be done without changing BIP 21 by using req-fiatvalue, req-fiatcurr, req-exchangeprovider
Example:
The merchant can print a QR code with his bitcoin address, fiatvalue=50.35, fiatcurr=EUR, exchangeprovider=bitcoinaverage.com
His client can scan this the same day or many weeks later, and if his/her wallet has support it will calculate the required bitcoin amount using the bitcoinaverage.com exchange price.
On exchangeproviders:
The exchangeprovider might be considered redundant but this could be handy for payment processors so they can use their own.
To prevent arbitrary urls a list of accepted providers might be added to the BIP, or managed seperately as is done by satoshilabs for BIP 44.
Let me know what you think and please be kind
Jump to: