Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-14 Thread Adam Back
Maybe even pay to (address derived from) contract hash has a hole: it assumes the merchant cashes the funds (or cashes then reimburses via the refund address). There is another rational (though abusive) move for the merchant: let the buyers funds sit in limbo. Then the buyer has the onus to go in

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-14 Thread Adam Back
He's probably thinking of fair advertising rules. There are regulations motivated by consumer protection/advertising standards (prevents merchant listing attractive prices in media, and then when consumer goes to pay the merchant says "oh actually that doesnt include X and Y, and the minimum price

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-14 Thread Andreas Schildbach
On 01/14/2014 11:45 AM, Mike Hearn wrote: > Imagine you get a good offer (payment request) from a merchant. You > would like to accept that offer, however the merchant has changed his > mind. > > > Usually if the merchant has not delivered, then at that point it's not a > problem and

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-14 Thread Mike Hearn
> > Imagine you get a good offer (payment request) from a merchant. You > would like to accept that offer, however the merchant has changed his > mind. Usually if the merchant has not delivered, then at that point it's not a problem and he is allowed to change his mind. It's only if they change t

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-14 Thread Andreas Schildbach
On 01/13/2014 06:56 PM, Pieter Wuille wrote: > I want to avoid the case where a transaction confirms, but the > associated payment is not delivered. If there is a reasonable chance > that this case occurs in normal operation, it means the payment > transmission cannot be relied upon. I was thinki

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-13 Thread Andreas Schildbach
Thanks for the explanation. On 01/13/2014 06:56 PM, Pieter Wuille wrote: >> As for you proposal, just be aware I'd like to use the payment protocol >> for face to face payments as well. That meant payment request via NFC or >> QR, payment message and payment confirmations via Bluetooth. I think i

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-13 Thread Pieter Wuille
On Mon, Jan 13, 2014 at 6:44 PM, Andreas Schildbach wrote: > On 01/13/2014 05:43 PM, Pieter Wuille wrote: > >> As an optimization (and I believe this is what Mike plans to implement >> in BitcoinJ), if a payment_url is present, it should be encouraged to >> only send the payment there, and not bro

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-13 Thread Andreas Schildbach
On 01/13/2014 05:43 PM, Pieter Wuille wrote: > As an optimization (and I believe this is what Mike plans to implement > in BitcoinJ), if a payment_url is present, it should be encouraged to > only send the payment there, and not broadcast the transaction at all > on the P2P network (minimizing the

[Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-13 Thread Pieter Wuille
Hi all, while thinking about what use cases the stealth addresses covers, in particular in addition to the payment protocol, I found it useful to bring this up again. currently, BIP70 says for "payment_url": Secure (usually https) location where a Payment message (see below) may be sent to obtain