summaryrefslogtreecommitdiff
path: root/23/0294b49c7ff7fb75e66662b86a344fe5e0c642
blob: 2f1fc03df69e8e4c052e64cecb358969c7f029d0 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	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 1TgXDS-0004sW-6R
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Dec 2012 08:53:58 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.175 as permitted sender)
	client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f175.google.com; 
Received: from mail-ob0-f175.google.com ([209.85.214.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1TgXDR-0006V9-8g
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Dec 2012 08:53:58 +0000
Received: by mail-ob0-f175.google.com with SMTP id vb8so6248134obc.34
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 06 Dec 2012 00:53:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.171.141 with SMTP id au13mr383078oec.124.1354784031947;
	Thu, 06 Dec 2012 00:53:51 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.128.139 with HTTP; Thu, 6 Dec 2012 00:53:51 -0800 (PST)
Received: by 10.76.128.139 with HTTP; Thu, 6 Dec 2012 00:53:51 -0800 (PST)
In-Reply-To: <50C03BDA.6010600@petersson.at>
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>
Date: Thu, 6 Dec 2012 09:53:51 +0100
X-Google-Sender-Auth: 0z0xHR3zScsgAlQUk3nggVLJY_k
Message-ID: <CANEZrP1iS4_MFi2=3Qa4_rSGXe5EK8B0wWy43hXJOeKp-SfpPg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Petersson <andreas@petersson.at>
Content-Type: multipart/alternative; boundary=bcaec55238c6f8bc3304d02b3ccf
X-Spam-Score: -0.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
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1TgXDR-0006V9-8g
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 08:53:58 -0000

--bcaec55238c6f8bc3304d02b3ccf
Content-Type: text/plain; charset=UTF-8

Escrow/multisig is complicated enough to wait for another day. But
certainly having a payment protocol is an important step towards it
On 6 Dec 2012 07:32, "Andreas Petersson" <andreas@petersson.at> wrote:

> During/before the Payment Request there should be a method to exchange
> the public keys to be able to generate a common multisig address.
> Should this be handled in a different protocol, or be included in this
> spec?
> Or is there a method for the customer to verify that the specified BIP16
> Output contains his address and the one from an escrow service?
>
> --
> Andreas
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--bcaec55238c6f8bc3304d02b3ccf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Escrow/multisig is complicated enough to wait for another da=
y. But certainly having a payment protocol is an important step towards it<=
/p>
<div class=3D"gmail_quote">On 6 Dec 2012 07:32, &quot;Andreas Petersson&quo=
t; &lt;<a href=3D"mailto:andreas@petersson.at">andreas@petersson.at</a>&gt;=
 wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
During/before the Payment Request there should be a method to exchange<br>
the public keys to be able to generate a common multisig address.<br>
Should this be handled in a different protocol, or be included in this<br>
spec?<br>
Or is there a method for the customer to verify that the specified BIP16<br=
>
Output contains his address and the one from an escrow service?<br>
<br>
--<br>
Andreas<br>
<br>
---------------------------------------------------------------------------=
---<br>
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial<br>
Remotely access PCs and mobile devices and provide instant support<br>
Improve your efficiency, and focus on delivering more value-add services<br=
>
Discover what IT Professionals Know. Rescue delivers<br>
<a href=3D"http://p.sf.net/sfu/logmein_12329d2d" target=3D"_blank">http://p=
.sf.net/sfu/logmein_12329d2d</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>

--bcaec55238c6f8bc3304d02b3ccf--