From: Adam Back <adam@cypherspace•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Andreas Schildbach <andreas@schildbach•de>
Subject: Re: [Bitcoin-development] Payment protocol and reliable Payment messages
Date: Tue, 14 Jan 2014 12:41:34 +0100 [thread overview]
Message-ID: <20140114114134.GA9838@netbook.cypherspace.org> (raw)
In-Reply-To: <CANEZrP3BeFMLtcThr=Gp5mudbtQeT_dHno1DGQzOg28YKBNkzA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-01-14 11:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 16:43 Pieter Wuille
2014-01-13 17:44 ` Andreas Schildbach
2014-01-13 17:56 ` Pieter Wuille
2014-01-13 22:24 ` Andreas Schildbach
2014-01-14 9:40 ` Andreas Schildbach
2014-01-14 10:45 ` Mike Hearn
2014-01-14 11:01 ` Andreas Schildbach
2014-01-14 11:41 ` Adam Back [this message]
2014-01-14 13:18 ` Adam Back
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140114114134.GA9838@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox