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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1Tgekr-0004gF-VP
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Dec 2012 16:56:58 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.177 as permitted sender)
client-ip=209.85.212.177; envelope-from=gavinandresen@gmail.com;
helo=mail-wi0-f177.google.com;
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Tgekq-0006v3-3G
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Dec 2012 16:56:57 +0000
Received: by mail-wi0-f177.google.com with SMTP id hm2so514561wib.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Dec 2012 08:56:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.145.160 with SMTP id p32mr813469wej.44.1354813009967; Thu,
06 Dec 2012 08:56:49 -0800 (PST)
Received: by 10.194.27.136 with HTTP; Thu, 6 Dec 2012 08:56:49 -0800 (PST)
In-Reply-To: <CANEZrP1iS4_MFi2=3Qa4_rSGXe5EK8B0wWy43hXJOeKp-SfpPg@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<20121128233619.GA6368@giles.gnomon.org.uk>
<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
<20121129170713.GD6368@giles.gnomon.org.uk>
<CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com>
<20121129185330.GE6368@giles.gnomon.org.uk>
<CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com>
<CANEZrP2riPBViBqAOWfY9uSQwoEm=gN108JU988XvouMbai1Ug@mail.gmail.com>
<CABsx9T023aw11cq6iiZhT3cgfNYJXr=qG40Fzc7rYZOimJ=62w@mail.gmail.com>
<50C03BDA.6010600@petersson.at>
<CANEZrP1iS4_MFi2=3Qa4_rSGXe5EK8B0wWy43hXJOeKp-SfpPg@mail.gmail.com>
Date: Thu, 6 Dec 2012 11:56:49 -0500
Message-ID: <CABsx9T2UBQXzDPj0zHio+9i0uKNqiPYwL=kYgWKSirXRvckQ4g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=0016e6d647e5323a6704d031fcba
X-Spam-Score: -0.6 (/)
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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Tgekq-0006v3-3G
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
Invoices/Payments/Receipts
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: Thu, 06 Dec 2012 16:56:58 -0000
--0016e6d647e5323a6704d031fcba
Content-Type: text/plain; charset=ISO-8859-1
Spec updated yet again:
https://gist.github.com/4120476
Renamed to PaymentRequest/PaymentACK.
Added a 'network' field ("main" or "test") to PaymentRequest so testnet and
main network (and alterna-chain) payment requests don't get confused.
Updated description of PaymentRequest.outputs:
outputs: one or more outputs where Bitcoins are to be sent. If the sum of
outputs.amount is zero, the customer will be asked how much to pay, and the
bitcoin client may choose any or all of the Outputs (if there are more than
one) for payment. If the sum of outputs.amount is non-zero, then the
customer will be asked to pay the sum, and the payment shall be split among
the Outputs with non-zero amounts (if there are more than one; Outputs with
zero amounts shall be ignored).
-------------
RE: escrow/multisig:
Setting up a multi-person escrow will, I think, need it's own set of
messages. I think we should leave that for a future spec.
Thumbnail sketch: escrow service or participant sends around an
EscrowProposal, gets EscrowProposalACK's with public keys to use, then
sends all participants an EscrowEstablished message with the final multisig
script or address. Escrow gets funded by any/all of the participants, and
then gets spent using the SignedPaymentRequest/Payment/PaymentACK
protocol-- participants will pass around a SignedPaymentRequest and a
partially-signed Payment message for all to approve.
When I say "pass around" I'm not thinking of users copying and pasting,
that would be a terrible user experience; all of that communication needs
to happen automatically behind the scenes. Lets tackle that after we've got
the simpler customer-pays-merchant flow working nicely
(funded-escrow-pays-merchant is a subset of that, anyway).
--
--
Gavin Andresen
--0016e6d647e5323a6704d031fcba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Spec updated yet again:</div><div>=A0=A0<a href=3D"https://gist.github=
.com/4120476">https://gist.github.com/4120476</a></div><div><br></div><div>=
Renamed to PaymentRequest/PaymentACK.</div><div><br></div><div>Added a '=
;network' field ("main" or "test") to PaymentReques=
t so testnet and main network (and alterna-chain) payment requests don'=
t get confused.</div>
<div><br></div><div>Updated description of PaymentRequest.outputs:</div><di=
v><br></div><div><p style=3D"margin:15px 0px;padding:0px;line-height:19.600=
000381469727px;font-family:helvetica,arial,freesans,clean,sans-serif;font-s=
ize:14px;background-color:rgb(255,255,255)">
outputs: one or more outputs where Bitcoins are to be sent. If the sum of o=
utputs.amount is zero, the customer will be asked how much to pay, and the =
bitcoin client may choose any or all of the Outputs (if there are more than=
one) for payment. If the sum of outputs.amount is non-zero, then the custo=
mer will be asked to pay the sum, and the payment shall be split among the =
Outputs with non-zero amounts (if there are more than one; Outputs with zer=
o amounts shall be ignored).</p>
</div><div>-------------</div><div><br></div>RE: escrow/multisig:<div><br><=
/div><div>Setting up a multi-person escrow will, I think, need it's own=
set of messages. I think we should leave that for a future spec.</div>
<div><br></div><div>Thumbnail sketch: =A0escrow service or participant send=
s around an EscrowProposal, gets EscrowProposalACK's with public keys t=
o use, then sends all participants an EscrowEstablished message with the fi=
nal multisig script or address. =A0Escrow gets funded by any/all of the par=
ticipants, and then gets spent using the SignedPaymentRequest/Payment/Payme=
ntACK protocol-- participants will pass around a SignedPaymentRequest and a=
partially-signed Payment message for all to approve.<br>
<br>When I say "pass around" I'm not thinking of users copyin=
g and pasting, that would be a terrible user experience; all of that commun=
ication needs to happen automatically behind the scenes. Lets tackle that a=
fter we've got the simpler customer-pays-merchant flow working nicely (=
funded-escrow-pays-merchant is a subset of that, anyway).<br>
<br>-- <br>--<br>Gavin Andresen<br><br>
</div>
--0016e6d647e5323a6704d031fcba--
|
