Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WAR1x-0004iQ-GF for bitcoin-development@lists.sourceforge.net; Mon, 03 Feb 2014 21:26:13 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WAR1u-0004rs-8m for bitcoin-development@lists.sourceforge.net; Mon, 03 Feb 2014 21:26:13 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WAR1n-0004UG-Dv for bitcoin-development@lists.sourceforge.net; Mon, 03 Feb 2014 22:26:03 +0100 Received: from e179068188.adsl.alicedsl.de ([85.179.68.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Feb 2014 22:26:03 +0100 Received: from andreas by e179068188.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Feb 2014 22:26:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Mon, 03 Feb 2014 22:25:53 +0100 Message-ID: References: <5kemthp1y7py3inyyquy78cf.1391459458968@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: e179068188.adsl.alicedsl.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <5kemthp1y7py3inyyquy78cf.1391459458968@email.android.com> X-Spam-Score: -0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 SPF_PASS SPF: sender matches SPF record -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WAR1u-0004rs-8m Subject: Re: [Bitcoin-development] BIP70: Canceling Payments X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:26:13 -0000 Have a look at my post "Payment Protocol for Face-to-face payments". In short: I implemented BIP70 using combinations of either QR-code or NFC plus Bluetooth. You can download a working preview app from: https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11 On 02/03/2014 09:30 PM, Tim Tuxworth Founder Go-taxi.biz wrote: > Is BIP70 limited to http only? > > What about face to face scenarios, or realtime like ticket sales or > gambling, and socket and/or bluetooth type connections? > > Tim Tuxworth > Founder Go-Taxi.biz > > > -------- Original message -------- > From: Christophe Biocca > Date:2014/02/03 10:49 AM (GMT-08:00) > To: Tim Tuxworth > Cc: bitcoin-development@lists.sourceforge.net > Subject: Re: [Bitcoin-development] BIP70: Canceling Payments > > Over http, the merchant doesn't have the ability to reach out to the > consumer's bitcoin wallet on their own. So sending "Cancel Payment > Request" to the user is impossible. > > If the customer doesn't want to send, nothing ever needs to happen. So > sending a "Reject Payment Request" to the merchant is useless. > > The unhappy path scenario with Payment Requests (customer paid, but > for whatever reason that payment is no longer valid) can be simply > solved in 1 of 2 ways: > > If the merchant realizes the mistake, they can refund the money. > If the customer realizes the problem, they can contact the merchant, > provide the signed request, and ask the merchant to return the funds. > > What isn't covered? > > On Mon, Feb 3, 2014 at 1:08 PM, Tim Tuxworth wrote: >> The process described in BIP70 might be ok for a simple "happy path" >> scenario, but what if things don't work so smoothly. I'm not talking >> here about technical issues, but _very common_ business scenarios such as: >> >> e.g. Merchant cancels request before payment is sent, such as when:- >> - the merchant realizes that they charged the wrong amount >> - the merchant realizes that they send the payment request to the wrong >> customer >> ... >> >> e.g. the Merchant or Customer decides to cancel the transaction after >> the payment request is sent because:- >> - the customer decides to pay by some other mechanism like cash or >> credit/debit >> - the customer doesn't have sufficient funds and decides not to purchase >> - the customer changes their mind and decides not to purchase >> ... >> >> It strikes me that a "Cancel Payment Request" message is required >> and a "Reject Payment Request" may also be required (or maybe use the >> same message for both). >> >> Tim Tuxworth >> >> > ------------------------------------------------------------------------------ >> Managing the Performance of Cloud-Based Applications >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >