From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 36C7C413 for ; Fri, 17 Jul 2015 15:47:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from bitcoin.co.th (support.bitcoin.co.th [162.213.249.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 41F6E112 for ; Fri, 17 Jul 2015 15:47:31 +0000 (UTC) Received: from node-n84.pool-101-108.dynamic.totbb.net ([101.108.117.148]:12358 helo=[192.168.1.174]) by server1.advancedstyle.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZG7rD-0007iY-Rc; Fri, 17 Jul 2015 11:47:28 -0400 Message-ID: <55A9238C.4050506@bitcoin.co.th> Date: Fri, 17 Jul 2015 22:47:24 +0700 From: "David Barnes | Bitcoin Co. Ltd." 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 References: <55A867B9.202@bitcoin.co.th> <55A8C1EF.8050603@bitcoin.co.th> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.advancedstyle.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bitcoin.co.th X-Get-Message-Sender-Via: server1.advancedstyle.com: authenticated_id: david.barnes@bitcoin.co.th X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 15:47:34 -0000 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.