* [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
@ 2015-07-17 2:26 David Barnes | Bitcoin Co. Ltd.
[not found] ` <CADu7o8OAicbtXwkxbsN=joirurBKt2ta-XwMYY622pUjR+drZQ@mail.gmail.com>
[not found] ` <CAAmoQf113y=Xd9R+b5yS=d9yo5SAX8+Nrv3gQt-R7Jih0UBOBg@mail.gmail.com>
0 siblings, 2 replies; 6+ messages in thread
From: David Barnes | Bitcoin Co. Ltd. @ 2015-07-17 2:26 UTC (permalink / raw)
To: bitcoin-dev
Please take a look at my BIP0074 draft proposal (this is my first one so
may be incorrectly formatted)
https://github.com/bitcoincoltd/bips/blob/master/bip-0074.mediawiki
This proposal will make it possible for a simpler form of Bitcoin
payment at physical shop locations.
Currently when making a Bitcoin payment at a shop the merchant needs to
have an app of some kind so that they can calculate the amount of
bitcoins you need to pay them to cover your purchase (of for example:
$9.99).
The problem is that many employees are not properly trained on the
Bitcoin app, or the owner is the one with the app and he is often not
there. When visiting "Bitcoin Accepting" estabishments you will often
run into this problem. The businesses often don't get enough Bitcoin
business to warrant training sessions or dedicate hardware to run the app.
A simpler way to accept payments would be for the merchant to have a
fixed QR code, and no app at all. However a printed QR code can't
calculate any exchange rates, and so it would be up to the customer to
choose how much to pay.
This can be result in some problems as the customer may be using their
default wallet exchange rates, or their preferred international
exchange. While the merchant may be actually using a local exchange or
service to exchange the coins to local currency, and there may be some
discrepancy between what the customer thinks the rate should be and what
the merchant thinks the rate should be.
Enter BIP0074, so that the merchant can specify which exchange rates
they are using, and the customer and then look up the rates from this
source and pay according to these rates.
David Barnes
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
[not found] ` <CADu7o8OAicbtXwkxbsN=joirurBKt2ta-XwMYY622pUjR+drZQ@mail.gmail.com>
@ 2015-07-17 3:30 ` David Barnes | Bitcoin Co. Ltd.
0 siblings, 0 replies; 6+ messages in thread
From: David Barnes | Bitcoin Co. Ltd. @ 2015-07-17 3:30 UTC (permalink / raw)
To: Paul Rabahy; +Cc: bitcoin-dev
There are a number of services that offer Bitcoin payment notification
via SMS.
If the cashier only has a dumb-phone (or smart phone without Bitcoin
app) they can receive notification of the payment...all without any need
for an app or internet access.
I envision that their dynamic rate provider will also be offer the SMS
notification service; but independent services are also available.
David Barnes
On 7/17/2015 10:21 AM, Paul Rabahy wrote:
> The biggest hole I see in this scheme is how does the cashier verify
> that the payment has been made successfully? If both the cashier and
> the customer need to scan this new QR code, how is that any better
> than just the cashier scanning the QR code and showing the customer an
> aggregate QR code.
>
> I understand wanting to make IRL bitcoin purchases easier, but I do
> not believe that this proposal will actually help.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
[not found] ` <CAAmoQf113y=Xd9R+b5yS=d9yo5SAX8+Nrv3gQt-R7Jih0UBOBg@mail.gmail.com>
@ 2015-07-17 8:50 ` David Barnes | Bitcoin Co. Ltd.
2015-07-17 12:24 ` Matt Whitlock
[not found] ` <CAHv+tb5B=i9FeCX-NXkTpRE_j8hwam_aWupEA_3xtBH8366sww@mail.gmail.com>
0 siblings, 2 replies; 6+ messages in thread
From: David Barnes | Bitcoin Co. Ltd. @ 2015-07-17 8:50 UTC (permalink / raw)
To: Micha Bailey; +Cc: bitcoin-dev
I picked up the next available number myself, but can be changed to
anything, the 74 is unimportant to the proposal.
David Barnes
On 7/17/2015 2:54 PM, Micha Bailey wrote:
> Did Greg assign this number? He didn't do it here on the ML. You're
> not supposed to use arbitrary numbers, certainly not numbers that are
> close/similar to ones already assigned.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
2015-07-17 8:50 ` David Barnes | Bitcoin Co. Ltd.
@ 2015-07-17 12:24 ` Matt Whitlock
2015-07-17 12:40 ` David Barnes | Bitcoin Co. Ltd.
[not found] ` <CAHv+tb5B=i9FeCX-NXkTpRE_j8hwam_aWupEA_3xtBH8366sww@mail.gmail.com>
1 sibling, 1 reply; 6+ messages in thread
From: Matt Whitlock @ 2015-07-17 12:24 UTC (permalink / raw)
To: David Barnes | Bitcoin Co. Ltd.; +Cc: bitcoin-dev
You should rename your file to something like "bip-draft-dynamic-rate-lookup". Using an arbitrary BIP number will cause confusion when that BIP number is actually assigned later.
On Friday, 17 July 2015, at 3:50 pm, David Barnes | Bitcoin Co. Ltd. via bitcoin-dev wrote:
> I picked up the next available number myself, but can be changed to
> anything, the 74 is unimportant to the proposal.
>
> David Barnes
>
> On 7/17/2015 2:54 PM, Micha Bailey wrote:
> > Did Greg assign this number? He didn't do it here on the ML. You're
> > not supposed to use arbitrary numbers, certainly not numbers that are
> > close/similar to ones already assigned.
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
2015-07-17 12:24 ` Matt Whitlock
@ 2015-07-17 12:40 ` David Barnes | Bitcoin Co. Ltd.
0 siblings, 0 replies; 6+ messages in thread
From: David Barnes | Bitcoin Co. Ltd. @ 2015-07-17 12:40 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/html, Size: 902 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
[not found] ` <CAHv+tb5B=i9FeCX-NXkTpRE_j8hwam_aWupEA_3xtBH8366sww@mail.gmail.com>
@ 2015-07-17 15:47 ` David Barnes | Bitcoin Co. Ltd.
0 siblings, 0 replies; 6+ messages in thread
From: David Barnes | Bitcoin Co. Ltd. @ 2015-07-17 15:47 UTC (permalink / raw)
To: Thomas Kerin; +Cc: bitcoin-dev
Thomas,
Let me answer your questions below; but let me give you a little preface
about how I envision the full cycle working.
My company has setup a service here: https://coinpay.in.th/services/print/
The service will work as follows:
- Merchants print out a QR code with address (and hopefully a DRL URL too)
- When customers wish to pay Bitcoin they scan the QR code pay the
amount the merchant tells them (such as "This kebab is 235 Thai Baht")
- Merchant / Staff instantly receive an SMS that payment is received
But currently the customers wallet does not have DRL, so will not give
the exact same exchange rate that we are giving the merchant, so that
the amount the merchant receives will not be the exact 235 Thai Baht
that they requested, but maybe 225, or 242.24 etc...as the customers is
currently picking any exchange basically out of thin air.
With this BIP it would allow the customer's wallet to know the exact
rate that merchant is receiving, therefore when the merchant requests
"235 Thai Baht" they actually receive exactly 235 Thai Baht.
But why do this? Apps work fine; smart phones are fine, merchants are
currently fine.
In my experience (running a merchant service, and exchange in Thailand
for 2 years and hosting 80+ Bitcoin meetup events) currently merchants
are not fine. Almost everyone I meet at the meetups has been traveling
around looking for places to pay Bitcoin, only to find that when the ask
for the bill "the own (aka the only guy in the place interested in
Bitcoin) is not here".
Pushing the angle of trying to get the merchants to properly train their
staff, or have a dedicated Bitcoin accepting phone/tablet is making
almost no progress, so we can trying to tackle the problem from a
different angle and come up with something that requires no training,
and no owner (Bitcoin interested guy) to be there.
But for it to work really seamlessly the merchant and customer need to
be on the same page with regards to the exchange rating being used.
And now to answer your questions:
> (0) Stores don't usually have any control of their exchange rate.
> Normally they rely on a service provider to do that, who decides the
> Bitcoin amount. This by design side-steps customers being able to
> enter a dollar amount (they get a BTC amount), or staff wondering how
> much bitcoin to charge (because they enter a dollar amount).
This BIP assumes that the staff do not have any app. They are just
ringing up the customer in their standard POS and telling the customer
the fiat amount they must pay.
Also assumes that the merchant is going to be moving the coins to a
service or exchange to convert so need to use the rates from that
service/exchange.
> (1) "A simpler way to accept payments would be for the merchant to
> have a fixed QR code, and no app at all."
>
> But then, how do they know that a payment took place at all? Trust
> that the buyers app isn't showing a screenshot with the stores
> [static] address, that the buyer may know from a previous encounter?
>
In the service we are running there will be an SMS notification sent to
the staff. There are also a number of services that provide SMS
notification upon Bitcoin transactions to a specific address.
But also in some cases they may just be willing to trust the customer;
especially for small food items, or repeat customers etc...
> (2) I suppose a DRP is required also provide historic access to
> pricing data? I don't see any mention of this in the BIP, but it
> appears necessary to allow the merchant to reconcile payments whenever
> they get online.
>
> (This could be a service each DRP provides - "we'll log all
> transactions to your stores offline address, and show you the supposed
> value according to us at this time". Without something like this, the
> merchant will end up using Blockchain.info who have their OWN exchange
> rates, compounding the issue)
>
Yes the DRP may provide historical rates. Or in the case of our service
an order is created in our system and rate is saved at the moment the
unconfirmed Bitcoin transaction is received.
But this is outside the scope of this BIP, which is simply to lookup the
current spot rate the DRP is offering.
> (3) You're certainly right that requesting dollar amounts from
> customers leads to problems, but, assuming an offline store (no app,
> or no Internet perhaps), how can they be certain that the payment went
> through, or that it was paid at the correct amount?
With our service the merchant will receive an SMS that payment is been
completed, and the amount of the payment (in the fiat currency)
But this is outside the scope of the actual BIP as the merchant is free
to use whatever method they want to get notified of a payment.
> I'm curious what use case you have that warrants such a setup? It
> seems to lead to difficulties for the merchant:
>
> (i) identifying the origin of a payment.
This is somewhat outside of the scope of the BIP, but within our service
it would be quite easy for them to match up orders in our system with
receipts from their POS seeing as an order is received in our system at
the first moment the unconfirmed transaction appears. And with DRL it
should match the exact fiat amount they requested.
> (ii) identifying what payment went missing, from months ago.
I'm unclear why a payment would go missing, unless you are referring to
double spends, or Bitcoin transactions sent with insufficient fees? In
this case our service would provide a warning that the transaction was
unlikely to confirm.
> (iii) what if the transaction took a day to confirm. (The exchange
> rate can change in the time between the customer /sending/ the funds,
> and the funds actually /confirming /and being recorded at the DRP's
> rate for that time. Ie, DRP notices a payment on the merchants
> address. The market rate now sees this as $47.39, even though it was
> originally sent for 50$ by the payer)
In the case of our service the rate is locked at the moment of the
unconfirmed transaction, so not an issue.
> My main issue is that each of these problems would go away if
> merchants just had an internet connection, which seems a must to use
> bitcoin.
>
It's not so much an issue with not having internet, it's more the issue
of not being properly trained on how to use the apps/internet. And even
with training the staff are easily going to forget if they don't see a
Bitcoin customer for several weeks at a time.
This is based on a lot of first hand experience and feedback from
Bitcoin customers and merchants...based on other stories I hear from
people trying to pay with Bitcoin at physical locations I don't think
this issue is isolated to Thailand only.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-07-17 15:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-17 2:26 [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup) David Barnes | Bitcoin Co. Ltd.
[not found] ` <CADu7o8OAicbtXwkxbsN=joirurBKt2ta-XwMYY622pUjR+drZQ@mail.gmail.com>
2015-07-17 3:30 ` David Barnes | Bitcoin Co. Ltd.
[not found] ` <CAAmoQf113y=Xd9R+b5yS=d9yo5SAX8+Nrv3gQt-R7Jih0UBOBg@mail.gmail.com>
2015-07-17 8:50 ` David Barnes | Bitcoin Co. Ltd.
2015-07-17 12:24 ` Matt Whitlock
2015-07-17 12:40 ` David Barnes | Bitcoin Co. Ltd.
[not found] ` <CAHv+tb5B=i9FeCX-NXkTpRE_j8hwam_aWupEA_3xtBH8366sww@mail.gmail.com>
2015-07-17 15:47 ` David Barnes | Bitcoin Co. Ltd.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox