diff options
| author | David Barnes | Bitcoin Co. Ltd. <david.barnes@bitcoin.co.th> | 2015-07-17 22:47:24 +0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-17 15:47:34 +0000 |
| commit | 5dec027fbc1eed117ca7fb58c2f43b5d8649a934 (patch) | |
| tree | 306e8e939354a332b0989a6e44e4e45f873a29e6 | |
| parent | 0abd397ed40859898f8f981976676688f974eec8 (diff) | |
| download | pi-bitcoindev-5dec027fbc1eed117ca7fb58c2f43b5d8649a934.tar.gz pi-bitcoindev-5dec027fbc1eed117ca7fb58c2f43b5d8649a934.zip | |
Re: [bitcoin-dev] BIP0074 Draft (Dynamic Rate Lookup)
| -rw-r--r-- | d3/3f20810f78cbc44c8523031ef8661ce4b46931 | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/d3/3f20810f78cbc44c8523031ef8661ce4b46931 b/d3/3f20810f78cbc44c8523031ef8661ce4b46931 new file mode 100644 index 000000000..3d93892f8 --- /dev/null +++ b/d3/3f20810f78cbc44c8523031ef8661ce4b46931 @@ -0,0 +1,192 @@ +Return-Path: <david.barnes@bitcoin.co.th> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 36C7C413 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <david.barnes@bitcoin.co.th>) + 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." <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 +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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. + + |