1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@cypherspace.org>) id 1W32O4-0002if-7q
for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jan 2014 11:42:28 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.194])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W32O2-0007O9-Fe
for bitcoin-development@lists.sourceforge.net;
Tue, 14 Jan 2014 11:42:28 +0000
Received: from netbook (c107-70.i07-27.onvol.net [92.251.107.70])
by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis)
id 0Md2qI-1Vm3SC2rdC-00ICga; Tue, 14 Jan 2014 06:41:44 -0500
Received: by netbook (Postfix, from userid 1000)
id 499082E035F; Tue, 14 Jan 2014 12:41:37 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000);
Tue, 14 Jan 2014 12:41:34 +0100
Date: Tue, 14 Jan 2014 12:41:34 +0100
From: Adam Back <adam@cypherspace.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140114114134.GA9838@netbook.cypherspace.org>
References: <CAPg+sBhdgVQvumL_r9thLD5wm7UOJx=2DE+01-T58HHdimvpXw@mail.gmail.com>
<lb18l6$nu2$1@ger.gmane.org>
<CAPg+sBji5sFWZ_mDVXKKwkyeGYDbLmvwau457nmntT_NgTT+Sw@mail.gmail.com>
<lb30mu$jjh$1@ger.gmane.org>
<CANEZrP3BeFMLtcThr=Gp5mudbtQeT_dHno1DGQzOg28YKBNkzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CANEZrP3BeFMLtcThr=Gp5mudbtQeT_dHno1DGQzOg28YKBNkzA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:140114:mike@plan99.net::YWbmYLUSmOecpnnO:006rj+
X-Hashcash: 1:20:140114:andreas@schildbach.de::gMa3UfsoNixiQs75:0000000000000000
0000000000000000000000003GiE
X-Hashcash: 1:20:140114:bitcoin-development@lists.sourceforge.net::Bg/Ebjpp1y4ya
77Z:000000000000000000003xYH
X-Hashcash: 1:20:140114:adam@cypherspace.org::fdbFahm5Dh6voQdU:00000000000000000
0000000000000000000000000kUy
X-Provags-ID: V02:K0:FjkNZT/7aM1LTlK6NOF9MyI+6Ywn+FackL8XSze9osm
TTy1Cawi4FpXSOp10dlrArLzfu3Ah3SIQ9rj0M85+ALE9OrJtg
tROvjOeumHWv0wwwRFyV6Z1W0i8MWDwM2yECGS3ngCLaXIYDVc
+bSSLZYSZ2u9MWx+Puu4aPfR0KRetZcpJ2n79jj2SKK95pZlcc
eucl3ail/rWyKamq11KtBy8eYTQJEfSAqlh5LFsmR3CaoTRaLi
U6w0KQ+VoqWcK7+UrBoUT7yITiV9aWVX9m4bULLEpRoWCLk64y
lgDymb2wEkNKuNOEZdvV38g4/dRBU95Fb7tTIS6ftDAyoJtRdF
8/Y/F3sojTaznGjHBR33LMzIAEr1M3sIAGNOZDd5n
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [74.208.4.194 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
X-Headers-End: 1W32O2-0007O9-Fe
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Payment protocol and reliable Payment
messages
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 11:42:28 -0000
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
|
