Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTVFi-00084P-JL for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 11:47:14 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.47 as permitted sender) client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f47.google.com; Received: from mail-oa0-f47.google.com ([209.85.219.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTVFS-0004YV-J6 for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 11:47:14 +0000 Received: by mail-oa0-f47.google.com with SMTP id i11so5893947oag.6 for ; Fri, 28 Mar 2014 04:46:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.183.24.161 with SMTP id ij1mr6469232obd.33.1396007213220; Fri, 28 Mar 2014 04:46:53 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Fri, 28 Mar 2014 04:46:53 -0700 (PDT) In-Reply-To: <122FC5AD-2117-4CAF-817F-45B00F57D549@bitsofproof.com> References: <122FC5AD-2117-4CAF-817F-45B00F57D549@bitsofproof.com> Date: Fri, 28 Mar 2014 12:46:53 +0100 X-Google-Sender-Auth: 3T4og6jRrLd89ezpHYFX8YtmEJs Message-ID: From: Mike Hearn To: Tamas Blummer Content-Type: multipart/alternative; boundary=001a1134aa020c4d2204f5a9422c X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1WTVFS-0004YV-J6 Cc: Bitcoin Dev , Andreas Schildbach Subject: Re: [Bitcoin-development] BIP 70 refund field 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: Fri, 28 Mar 2014 11:47:14 -0000 --001a1134aa020c4d2204f5a9422c Content-Type: text/plain; charset=UTF-8 I don't want to manage a "business relationship" with every shop I buy something from. That's way too much effort. There can certainly be cases where a more complicated relationship is created by bootstrapping off BIP70, perhaps with an extension, but nailing the ordinary buyer-to-seller relationship seems like a good scope for BIP70 for now. On Fri, Mar 28, 2014 at 12:45 PM, Tamas Blummer wrote: > Yes, you begin to see that the payment protocol, as is has a too narrow > scope of a web cart - customer, and does not even fit that. > > It is not about payment requests but about business relationships. We need > a protocol that deals with that concept instead of individual requests, > so we really get out of the hell of addresses. Business relationships are > terminated by the parties at their own and not bey algorithms and timeouts. > > Regards, > > Tamas Blummer > http://bitsofproof.com > > On 28.03.2014, at 12:38, Wladimir wrote: > > > On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach < > andreas@schildbach.de> wrote: > >> I see the problem. >> >> However, I don't see how PaymentDetails can be an answer. None of the >> fields (other than outputs and network) can be known in advance (at the >> time of the initial payment). >> >> You're probably aiming for an expires field? How would you refund a >> payment after expiry? Note its not your choice wether to refund a >> payment -- it can be ordered by a court years after the payment happened. >> > > Communication between the merchant and buyer would be needed in this case. > > I'd say that would be not unreasonable if something is to be refunded > after a year or more. After all, people may have moved, bank accounts > changed, even outside the bitcoin world. > > It should probably not be accepted to set a very low expiration time for > the refund address, like <3 months, as it's as bad as not providing a > refund address at all and brings back all the pre-BIP70 confusion. > > Wladimir > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a1134aa020c4d2204f5a9422c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't want to manage a "business relationship&q= uot; with every shop I buy something from. That's way too much effort. = There can certainly be cases where a more complicated relationship is creat= ed by bootstrapping off BIP70, perhaps with an extension, but nailing the o= rdinary buyer-to-seller relationship seems like a good scope for BIP70 for = now.


On Fri, Mar 2= 8, 2014 at 12:45 PM, Tamas Blummer <tamas@bitsofproof.com> wrote:
Yes= , you begin to see that the payment protocol, as is has a too narrow scope = of a web cart - customer, and does not even fit that.

It is not about payment requests but about business rel= ationships. We need a protocol that deals with that concept instead of indi= vidual requests,
so we really get out of the hell of addresses. B= usiness relationships are terminated by the parties at their own and not be= y algorithms and timeouts.

Regards,=

Tamas Blummer
http://bitsofproof.com

On 28.03.2014, at 12:38, Wladimir <= laanwj@gmail.com&= gt; wrote:


= On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <= andreas@schildba= ch.de> wrote:
I see the problem.

However, I don't see how PaymentDetails can be an answer. None of the fields (other than outputs and network) can be known in advance (at the
time of the initial payment).

You're probably aiming for an expires field? How would you refund a
payment after expiry? Note its not your choice wether to refund a
payment -- it can be ordered by a court years after the payment happened.

Communication between the merchant and b= uyer would be needed in this case.

I'd say that would= be not unreasonable if something is to be refunded after a year or more. A= fter all, people may have moved, bank accounts changed, even outside the bi= tcoin world.

It should probably not be accepted to set a very low expirat= ion time for the refund address, like <3 months, as it's as bad as n= ot providing a refund address at all and brings back all the pre-BIP70 conf= usion.

Wladimir

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-developme= nt mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


-------------------= -----------------------------------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a1134aa020c4d2204f5a9422c--