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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Tgffs-0001ya-RM
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Dec 2012 17:55:56 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.47 as permitted sender)
client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f47.google.com;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Tgffr-0001lk-W3
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Dec 2012 17:55:52 +0000
Received: by mail-oa0-f47.google.com with SMTP id h1so7038612oag.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Dec 2012 09:55:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.172.164 with SMTP id bd4mr1025059oec.51.1354816546635; Thu,
06 Dec 2012 09:55:46 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.128.139 with HTTP; Thu, 6 Dec 2012 09:55:46 -0800 (PST)
In-Reply-To: <CABsx9T2UBQXzDPj0zHio+9i0uKNqiPYwL=kYgWKSirXRvckQ4g@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>
<CABsx9T2UBQXzDPj0zHio+9i0uKNqiPYwL=kYgWKSirXRvckQ4g@mail.gmail.com>
Date: Thu, 6 Dec 2012 18:55:46 +0100
X-Google-Sender-Auth: SfPgBITUEyA_KxjzpD2so-i7_io
Message-ID: <CANEZrP2VLsh0mi=saQ0ZOnjVijUHoqEMxTG3LHcaCb2Ua-f-gQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
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: 1Tgffr-0001lk-W3
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 17:55:57 -0000
Re: the newest spec. Rather than make the signature over the
"concatenation of", why not just make it a signature over the
serialized protobuf minus the signature field (as I did in my demo
code). Otherwise it seems like we'd need more code than really
necessary. We can state explicitly tags must be ordered if you want,
even though all implementations should do that already.
> 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.
Yeah, that sounds reasonable. Not that we should really design it now,
but let's use the term "mediation" rather than "escrow", which has
connotations of depositing funds with the escrow service.
I think it's best to see the existing payment messages as structures
that'll get filled out with more features over time. So rather than
have a separate EscrowProposal message, you would integrate it with
payment requests. Older clients that don't understand mediation would
just ignore the extra data they don't recognize.
message PaymentRequest {
....
// One per mediator acceptable to the seller.
repeated MediationProposal mediation_data = 10;
}
message MediationProposal {
required SignedMediatorIdentity identity = 2;
// Opaque bytes that the mediator can be asked to turn into a human
readable description
// of how disputes will be mediated. The merchant sets this to
describe whatever policy it
// is willing to go along with, so policies may be arbitrarily complicated.
required bytes policy = 3;
}
message SignedMediatorIdentity {
required MediatorIdentity identity = 1;
// If the identity data is signed ...
optional string pki_type = 2;
optional bytes pki_data = 3;
optional bytes pki_signature = 4;
}
message MediatorIdentity {
// Name of the mediator to be displayed to the user.
required string friendly_name = 1;
// PNG image that can be used to represent the mediator to the user.
optional bytes logo = 2;
// Some text shown to the user under the name explaining the
mediators policies, why they should be chosen, etc.
optional string blurb = 3;
// An HTTP URL where a mediator can be reached to do things like
prove ownership of pubkeys, initiate the protocols, etc.
required string contact_url = 4;
}
... etc ....
So the user experience would be that when a payment request is received:
- older clients ignore the mediation_data field and do a direct
payment as normal
- newer clients ask the user to pick a mediator (if they want to) and
if mediation is requested, the PaymentRequest is then discarded and
the next step of the mediation protocol begins.
The old request has to be discarded because the outputs would have
been written on the assumption of no mediation being in use (for
backwards compatibility).
Anyway, though I'm awfully guilty, let's not get off track. Just that
this is how I imagined new payment features being done - as new
extensions to the payment protocol, which would be a living document
amended by BIPs.
|
