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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
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 <mh.in.england@gmail.com>) id 1TJ5UC-0005iN-51
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Oct 2012 16:38:20 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TJ5UB-0003Bz-05
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Oct 2012 16:38:20 +0000
Received: by wgbdr1 with SMTP id dr1so3938773wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 02 Oct 2012 09:38:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.86.202 with SMTP id r10mr23112038wiz.12.1349195892790;
Tue, 02 Oct 2012 09:38:12 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.159.131 with HTTP; Tue, 2 Oct 2012 09:38:12 -0700 (PDT)
Date: Tue, 2 Oct 2012 18:38:12 +0200
X-Google-Sender-Auth: ZXyFbB1lHOAYhlhC6MqqyM3cONg
Message-ID: <CANEZrP3aArZV1jCL8OsksGxQO03Cs=CKM_4L3NB1=qGo=GMHdA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1TJ5UB-0003Bz-05
Subject: [Bitcoin-development] Payment protocol thoughts
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, 02 Oct 2012 16:38:20 -0000
I've been thinking about the requirements for a payment protocol
lately. It seems we have consensus that we need one of these. Pieter
has a gist on the topic here: https://gist.github.com/1237788
IMHO we'll want to move away from "send X BTC to address Y" and more
towards "upload to me transactions that send X BTC to outputs
A,B....F,G". In this context by output I mean the obvious
interpretation of script+value.
The reasons are privacy and security. Privacy: you don't want people
to find out if you have an unexpectedly large balance (from the block
chain). Example worst case scenarios
- in a hypothetical Bitcoin-using country, as most people receive
income exactly once a month from their employer, you could potentially
find out other peoples salaries. Drama ensues.
- business partners could find out their counterparty has an
unexpectedly good financial position, messing up negotiations
Security:
- some of the outputs could be in a hot wallet, others in cold
wallets, helping you maintain correct balances between them in real
time
- the outputs can be multi-sig scripts
Wallets would then craft a series of transactions to try and somewhat
balance the size of inputs vs outputs. Because they are separate
transactions and all the keys are fresh, there's no way to link them
together into a single payment, especially not if they're broadcast in
random order with some jitter.
The upside of this is better privacy. The downside is obviously more
transactions and therefore more overhead. In theory the sum of tx
outputs would end up converging to a reasonable "coin size" for the
recipients, eg, businesses might be happy to receive a lot of money in
a single output, individuals less, children or very poor people maybe
much less.
Let's call payment requests invoices. Here is a brainstorm on other
features that may be desirable. I'm not suggesting they're all in v1,
just that we think about them a bit to ensure we don't paint ourselves
into a corner.
- Optional list of {signature, certificate} pairs. SSL certs can be
embedded into the payment request file itself so they can be checked
instantly for wallets that want to show a verified identity, but you
can also provide other certificates issued outside the regular SSL CA
system. For example maybe MtGox issues you a "trusted vendor"
certificate. Maybe the better business bureau issues you a cert, etc.
- Optional expiry time (from sipas gist) so outputs that were never
sent to can be recycled
- Upload target (URI), where to send the created transactions
- Optional message and branding image/icon that a wallet can display
to make the transaction history a bit prettier
- Opaque token that the wallet is supposed to copy into the payment.
The merchant can use to link invoice with payment. It's technically
redundant, the output set would identify the invoice too, as could a
token in the upload target URL, but it may be simpler for some
merchant implementations
- Ability to specify payment amount[s] in terms of other currencies.
If the amount is specified statically it can just be recorded in the
wallet for informational purposes. If there's a URL provided also, it
is an endpoint where quotes can be obtained. This allows merchants to
make long-lived invoices which are protected against FX volatility.
Downside: complicates wallets. Upsides: invoices can be kept around
for longer.
- Web/human-usable URL for the order so users can, eg, send messages
to the merchant specific to an order, post a review of the merchant,
etc
- Support for setting up 2-of-3 dispute mediation. Invoices should be
able to name a list of acceptable mediators and the wallet software
can intersect this with a list of mediators acceptable to the user, to
find one that works best. The whole mechanism by which merchants and
users agree on mediators isn't designed yet but we can at least think
about it now. It may be there's a simple design everyone agrees on
already.
- Support for requesting recurring payments. Eg, I should be able to
provide N sets of M outputs, one set for each payment with a payment
schedule. Wallets can then ensure they run at the appropriate times to
keep up the subscription.
- Suggested tip/service charge. Wallet would give a simple UI to
adjust this up/down by X percentage points
- Request to sign inputs with SIGHASH_ANYONECANPAY, allowing the
payment to be a pledge for an assurance contract
- Ability to specify minimum confirmation level of coins that will be
spent. Some merchants may be OK with you immediately re-spending
unconfirmed coins. Other merchants will care more and might want you
to take on the burden of getting your transactions into the chain.
On the payment upload side:
- An optional signature under a stable user key that lets users
optionally link their payments across merchants. In this way a user
can build cross-market reputation which may help them in future, by
relaxing confirmation requirements or reducing the chance of being
asked to enter dispute mediation. Needs more thought.
- Optionally, an invoice for a refund if the merchant chooses to
refund the money in the absence of dispute mediation.
- A list of Bitcoin transactions that make payments to the outputs
requested in the invoice
- The opaque token provided in the invoice
Re: format. I would (surprise) strongly suggest protocol buffers over
JSON. I cannot think of any justification for using JSON (for
anything) but especially not for data structures that mostly contain
binary data like hashes or keys. Protobufs are easier to work with in
code, have a more efficient encoding, can be printed/parsed from ASCII
if you need to (eg for debugging purposes) and have fewer sharp edges
than JSON does.
|
