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
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
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
>
> 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
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
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
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
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
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
9 matches
Mail list logo
