Re: [Bitcoin-development] Payment protocol and reliable Payment messages
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 into disupte, maybe the seller is anonymous, in another country, or the cost of dispute resolution more than the value lost, and anyway its not very smart-contract like. It might be better if the buyer has time-stamped evidence of having sent the funds to the merchant, and evidence of non-collection of funds by the merchant (by omission from the block chain). Adam -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
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 is 10% more" after the user has already partly committed to the purchase. Ryanair, an airline near and dear to Europeans ;) is infamous for aggressive use of such tactics. Or worse systematic abuse of "sorry that was a pricing mistake". In trading situations its even more important, you're facing a dynamic price, and revocable bids after acceptance but before payment allow system gaming. There were court cases about such things and trading systems gamed. So I think this is the use case to consider. Payment request is an offer, payment message is an acceptance, transaction broadcast is settlment. After acceptance the asker must not be allowed to retract ther ask. Going back to Pieter's comment it seems there are two approaches: i) send payment message to merchant, merchant broadcasts tx to network to claim funds; ii) user broadcasts tx, and sends payment message to merchant. In case i) the user is relying on the merchant in terms of retraction, for many use-cases that doesnt matter, or consumer law says they can do that in some places. Though transferable proof the merchant is systematically retracting advertised offers could be indirectly useful as it maybe evidence of unfair trading, which can result in censure for the merchant! In case ii) I think Andreas has a point. Maybe the way to do that is to also bind the transaction to the payment message. Eg include the hash of the payment message in the tx (circular ref may have to use multisig approach?), or as Timo Hanke's paper where the offer/acceptance contact hash is bound to the address (ie the address paid is Q'=H(Q+H(contract)G). Adam On Tue, Jan 14, 2014 at 11:45:59AM +0100, 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 he is allowed to change his mind. It's only if they > change their mind *after* you pay that it's a problem, right? >-- >CenturyLink Cloud: The Leader in Enterprise Cloud Services. >Learn Why More Businesses Are Choosing CenturyLink Cloud For >Critical Workloads, Development Environments & Everything In Between. >Get a Quote or Start a Free Trial Today. >http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
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 he is allowed to change his mind. It's only if they change > their mind *after* you pay that it's a problem, right? It was my understanding of the spec that a payment request is legally binding one side for the specified amount of time. Basically I offer you to sell you these 10 eggs (described in the memo) for this amount if you accept until this time. I have even signed this so you can know its me who made you the offer. If you accept (by paying), the contract is valid and there should be nothing I can do about it (except for extreme cases which are covered by law already). Actually what good is the payment request if its not binding? Why do we have an expiry time in the message? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
> > 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 their mind *after* you pay that it's a problem, right? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
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 thinking about this some more. Generally I think you have a point. However, there is one case I'm worried about. 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. If you don't broadcast the payment to the blockchain, you won't have a chance to accept and legally bind the offer. The merchant will silently discard your payment messages. At some point, you will involve a judge. If you can present the payment request and the payment from the block chain, you're in a much better position than if you just present a request but no confirmed payment. I think in some cases you might want to broadcast your txn to the P2P network, even if the payment messages get lost. What do you think? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
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 it >> can be done by putting a Bluetooth mac address into the payment_url. > > I'm aware. What issues do you see? Looks good so far. Just wanted to keep you aware (-: -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
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 broadcast the transaction at all >> on the P2P network (minimizing the risk that the transaction confirms >> without the payment being received; it can't be guaranteed however). 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. On the other hand, if the payment gets sent, but the transaction is not broadcasted, it can be broadcasted by the receiver (who has much more reason to do so; he wants to spend his money). > > Can you explain what the problem is here? The payment message can be > transmitted after the payment has been received through the P2P network. > Am I missing something? So, yes, sending on the P2P network is fine, as long as everything is done to get the payment delivered. Not broadcasting on P2P is just an optimization that makes failures of not getting the transaction out and not getting the payment delivered coincide better. I say just optimization, as you can't rely on the fact that if the payment fails, the transaction will also fail (the merchant may be malicious, make the submission of the payment fail, but broadcast the transaction anyway), so wallets must still be able to deal with this. Nonetheless, I think it can increase the reliability of "payment being received for otherwise confirming transactions". > > Furthermore, if we give up the robustness of the P2P network, we will > likely end up with more failed payments. There is so much that can go > wrong when trying to connect via HTTP (proxies etc.), Bluetooth > endpoints can go away, etc. At least we should provide fallback > payment_url's in this case. That's a different issue. I'm very aware that payments over HTTP can fail. The point is that I prefer the entire transaction to fail in that case, instead, and focus on making the payment submission more reliable. > > 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 it > can be done by putting a Bluetooth mac address into the payment_url. I'm aware. What issues do you see? -- Pieter -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol and reliable Payment messages
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 risk that the transaction confirms > without the payment being received; it can't be guaranteed however). Can you explain what the problem is here? The payment message can be transmitted after the payment has been received through the P2P network. Am I missing something? Furthermore, if we give up the robustness of the P2P network, we will likely end up with more failed payments. There is so much that can go wrong when trying to connect via HTTP (proxies etc.), Bluetooth endpoints can go away, etc. At least we should provide fallback payment_url's in this case. 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 it can be done by putting a Bluetooth mac address into the payment_url. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Payment protocol and reliable Payment messages
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 a PaymentACK. The fact that this is optional makes the "memo" and "refund" and "merchant_data" fields in the Payment message useless, as merchants cannot rely on it, thus need to provide an alternative, thus nobody would have a use for trying to use the in-Payment versions. If we truly want the use of this Payment being sent be optional, I'd vote to get rid of these and just send the transaction. In particular in the case of more anonymous senders, if the Payment message isn't sent, it may result in funds being transferred without a way to know who to refund it to if something goes wrong. That would be a pity. I think having bi-directional communication in the protocol is one of the nicest things the payment protocol can add. I would prefer to at least formulate it in the BIP as "location where a Payment message must be attempted to be sent to". In case it fails, it should probably be stored in the client and retried later. 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 risk that the transaction confirms without the payment being received; it can't be guaranteed however). -- Pieter -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
