From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTVMu-0004b8-E9 for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 11:54:40 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WTVMs-0004tM-R2 for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 11:54:40 +0000 Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WTVMm-0005qY-7M; Fri, 28 Mar 2014 12:54:32 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_8A4B42C9-835F-4BDB-B229-24145D17DD00"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tamas Blummer In-Reply-To: Date: Fri, 28 Mar 2014 12:54:31 +0100 Message-Id: <48ED312A-A1F9-4081-9718-04DD45804313@bitsofproof.com> References: <122FC5AD-2117-4CAF-817F-45B00F57D549@bitsofproof.com> To: Mike Hearn X-Mailer: Apple Mail (2.1510) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396007678; 4b99dd73; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WTVMs-0004tM-R2 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:54:40 -0000 --Apple-Mail=_8A4B42C9-835F-4BDB-B229-24145D17DD00 Content-Type: multipart/alternative; boundary="Apple-Mail=_473D6C0C-3216-4D5F-BA33-4E151542DF27" --Apple-Mail=_473D6C0C-3216-4D5F-BA33-4E151542DF27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28.03.2014, at 12:46, Mike Hearn wrote: > 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. >=20 It is not more effort than an auto remembered call-in phone number. You = delete if you do not care. The difference however is that it would be a = clean protocol for repeated payments in both directions for whatever = reason, where "refund" is and "payment" are not special compared to "1st = installment", "overpayed back" or "tip" or whatever extra charge arises = later. >=20 > 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. >=20 > 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. >=20 > Regards, >=20 > Tamas Blummer > http://bitsofproof.com > istinfo/bitcoin-development >=20 >=20 --Apple-Mail=_473D6C0C-3216-4D5F-BA33-4E151542DF27 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On 28.03.2014, at 12:46, Mike Hearn <mike@plan99.net> wrote:

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.


It is not more effort than an auto remembered call-in phone number. You delete if you do not care. The difference however is that it would be a clean protocol for repeated payments in both directions for whatever reason, where "refund" is and "payment" are not special compared to "1st installment", "overpayed back" or "tip"  or whatever extra charge arises later.



On Fri, Mar 28, 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 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
istinfo/bitcoin-development



--Apple-Mail=_473D6C0C-3216-4D5F-BA33-4E151542DF27-- --Apple-Mail=_8A4B42C9-835F-4BDB-B229-24145D17DD00 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTNWL3AAoJEPZykcUXcTkcov0H/3hadG/ZWZMxbKP0G/WHbgEZ K7nhSwRTJK+JzEDVb2SqmpjWuMpjniYEU6YlfFC5FQzzPFrjGQlPTrN0t2y/43Lm ALsJgqc38zSrIqG0hUMASjFxydhB+IBy+egQQiULiXh4Gmr3d8VAB1vT2Ijw/xZX YmhVxPaCMrPtb4p3kAXHdwpytEF2fbWwQW981kS9t24XGQIXKyfK/RRkd3p4S2TX lrkzUFNKfNpDS9NnFl1YT1zySBIfgMXUQpPwnF8GSSG6muECU+fQXLZpJNDM43o6 2lLW5Eudc+hHsV7hjtThLY0pSVqXEFo9X7YCRZBQrVw1uIshgFOzs9dGpE3DuBY= =DNk6 -----END PGP SIGNATURE----- --Apple-Mail=_8A4B42C9-835F-4BDB-B229-24145D17DD00--