Message-ID: <55A9238C.4050506@bitcoin.co.th>
Date: Fri, 17 Jul 2015 22:47:24 +0700
From: "David Barnes | Bitcoin Co. Ltd." <david.barnes@bitcoin.co.th>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Thomas Kerin <thomas.kerin@gmail.com>
References: <55A867B9.202@bitcoin.co.th>	<CAAmoQf113y=Xd9R+b5yS=d9yo5SAX8+Nrv3gQt-R7Jih0UBOBg@mail.gmail.com>	<55A8C1EF.8050603@bitcoin.co.th>
	<CAHv+tb5B=i9FeCX-NXkTpRE_j8hwam_aWupEA_3xtBH8366sww@mail.gmail.com>
In-Reply-To: <CAHv+tb5B=i9FeCX-NXkTpRE_j8hwam_aWupEA_3xtBH8366sww@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
Precedence: list

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/prin=
t/
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.=20
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.