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.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-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