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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTVDk-0007en-Qq for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 11:45:12 +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 1WTVDi-0004Q6-Sh for bitcoin-development@lists.sourceforge.net; Fri, 28 Mar 2014 11:45:12 +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 1WTVDc-0001VI-Ja; Fri, 28 Mar 2014 12:45:04 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_442A202D-9105-40A7-B809-429540527FD8"; 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:45:03 +0100 Message-Id: <122FC5AD-2117-4CAF-817F-45B00F57D549@bitsofproof.com> References: To: Wladimir X-Mailer: Apple Mail (2.1510) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396007110; 952584a0; 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: 1WTVDi-0004Q6-Sh 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:45:13 -0000 --Apple-Mail=_442A202D-9105-40A7-B809-429540527FD8 Content-Type: multipart/alternative; boundary="Apple-Mail=_E679D78B-D160-4F41-A014-48F69BB53CED" --Apple-Mail=_E679D78B-D160-4F41-A014-48F69BB53CED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: >=20 > On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach = wrote: > I see the problem. >=20 > 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). >=20 > 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. >=20 > Communication between the merchant and buyer would be needed in this = case. >=20 > 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. >=20 > 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. >=20 > Wladimir >=20 > = --------------------------------------------------------------------------= ---- > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --Apple-Mail=_E679D78B-D160-4F41-A014-48F69BB53CED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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,

http://bitsofproof.com

On 28.03.2014, at 12:38, Wladimir <laanwj@gmail.com> = 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-develop= ment mailing list
Bitcoin-developm= ent@lists.sourceforge.net
https://lists.sourceforge.net/lists/listi= nfo/bitcoin-development

= --Apple-Mail=_E679D78B-D160-4F41-A014-48F69BB53CED-- --Apple-Mail=_442A202D-9105-40A7-B809-429540527FD8 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 iQEcBAEBAgAGBQJTNWDAAAoJEPZykcUXcTkc2fUH/2uCZMruCAH2E+BXc5MYOJR7 KeIK2ffpzFeR784xxywVtKJgvHiKIap1tB8oiOwIdsWfNFLVs+zNhs3jtkySHI+7 ly7qMgHZsxARAigahPV1qlbhkztnn5QvzQjGMUZxUC9DcKDgMbxt9kIfF04wzHs0 PFngTtGDur7QlbsQCqhEmK/POU4XyNvunGV6uUFChrqobU4/LYRBtccbHjSN6NmZ FKrgt4fjn8tZQjZEU8DnTXjq4xcJWK4umpwMiu+rBX50EMJ9QsI00HGvLkJijdsv VCxDFmAWzbF06wCDd4DLgEHV0DqvbVXuwlkXaTRzEg0Qc//HteOW03E4jH256B8= =FJrP -----END PGP SIGNATURE----- --Apple-Mail=_442A202D-9105-40A7-B809-429540527FD8--