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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1SFJdL-0002uF-UQ
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Apr 2012 06:23:56 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.175 as permitted sender)
client-ip=209.85.213.175; envelope-from=laanwj@gmail.com;
helo=mail-yx0-f175.google.com;
Received: from mail-yx0-f175.google.com ([209.85.213.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SFJdJ-0000O2-OZ
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Apr 2012 06:23:55 +0000
Received: by yenm3 with SMTP id m3so259151yen.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Apr 2012 23:23:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.125.4 with SMTP id c4mr4250464ann.52.1333520628300; Tue,
03 Apr 2012 23:23:48 -0700 (PDT)
Received: by 10.236.175.103 with HTTP; Tue, 3 Apr 2012 23:23:48 -0700 (PDT)
In-Reply-To: <4F7B8F46.8060706@gmail.com>
References: <4F7A1227.7070306@gmail.com>
<CABsx9T3MQzJ5gN5xTZ9y5d-og11=mB86cM3ZP4S-fhjs1U+20g@mail.gmail.com>
<201204031455.42265.luke@dashjr.org>
<CA+s+GJCKcOky=Kfa9cNaEnpO0Lj4Va8a8N=-OZSoXLoO8aUGgQ@mail.gmail.com>
<CAMGNxUujVx0taTh+QR1WFBMKGWcxF-CvCMPwVFWirQ=XyZtquA@mail.gmail.com>
<4F7B67D6.7090101@gmail.com>
<CAErK2CjSEvhuHt-fdu-jTL6A9sL9NEXZQM6fUxSz9bxeTxHoAQ@mail.gmail.com>
<4F7B8F46.8060706@gmail.com>
Date: Wed, 4 Apr 2012 08:23:48 +0200
Message-ID: <CA+s+GJBFYNZjOzRJd19wZ29h-uKqaVNx-RhnsgGpRAMg-nRgZw@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=001636ed6bda59bbb504bcd477d4
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
(laanwj[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: 1SFJdJ-0000O2-OZ
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
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: Wed, 04 Apr 2012 06:23:56 -0000
--001636ed6bda59bbb504bcd477d4
Content-Type: text/plain; charset=UTF-8
Alan,
On Wed, Apr 4, 2012 at 2:01 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> **
> There is all this fanfare around P2SH and how multi-sig is the solution to
> all these security problems, but how the hell do you use it? I believe
> that BIP 10 (or successor) is *critical *to the success of multi-sig,
> because the greatest barrier to using multi-sig will be the ability to
> actually execute them in less than 14 steps. And if every client
> implements it differently, there's even less chance it will be used
> (assuming the userbase reaches any level of client diversity).
>
That is a laudable goal.
So your proposal is about signing "Preformatted messages from sites" to
make financial transactions more secure, not arbitrary user-to-user
messages such as email. That really restricts the scope, which is good.
In this case there is no use for S/MIME, which deals with encoding/signing
multipart mail messages. And no need to deal with MIME headers, html, or
embedded images, and such. And we can simply require one character
encoding, no need to support hundreds.
The "request signing" bitcoin URL makes sense in my eyes. Less copy/pasting
is good. Do mind that there is usually a URL size limit (depending on the
browser) so this cannot be used for long messages/contracts. A possible
solution would be to make an option to pass the address where the message
can be retrieved (and maybe also where the signature must be sent, to save
a copy-paste back?).
Looking at existing solutions, the only other "sign request" that I know of
is the CSR (https://en.wikipedia.org/wiki/Certificate_signing_request) but
the functionality and goal is very different.
It'd be useful (and IMO most important) to write down some use-cases in
which this makes P2SH easier and less involved. How many steps can be
eliminated of the 14?
Wladimir
BTW: we also still need a BIP to define URL signing / authentication
itself.
--001636ed6bda59bbb504bcd477d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Alan,<br><br><div class=3D"gmail_quote">On Wed, Apr 4, 2012 at 2:01 AM, Ala=
n Reiner <span dir=3D"ltr"><<a href=3D"mailto:etotheipi@gmail.com" targe=
t=3D"_blank">etotheipi@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<u></u>
=20
=20
=20
<div bgcolor=3D"#ffffff" text=3D"#000000">There is all this fanfare aroun=
d P2SH and how multi-sig is the
solution to all these security problems, but how the hell do you use
it?=C2=A0 I believe that BIP 10 (or successor) is <b>critical<i> </i></=
b>to
the success of multi-sig, because the greatest barrier to using
multi-sig will be the ability to actually execute them in less than
14 steps.=C2=A0 And if every client implements it differently, there=
9;s
even less chance it will be used (assuming the userbase reaches any
level of client diversity).=C2=A0=C2=A0 <br></div></blockquote><div><br=
></div><div>That is a=C2=A0laudable=C2=A0goal.=C2=A0</div><div><br></div><d=
iv>So=C2=A0your proposal is about signing "Preformatted messages from =
sites" to make financial transactions more secure, not arbitrary user-=
to-user messages such as email. That really restricts the scope, which is g=
ood.</div>
<div><br></div><div>In this case there is no use for S/MIME, which deals wi=
th encoding/signing multipart mail messages. And=C2=A0no need to deal with =
MIME headers, html, or embedded images, and such. And we can simply require=
one character encoding, no need to support hundreds.</div>
<div><br></div><div>The "request signing" bitcoin URL makes sense=
in my eyes. Less copy/pasting is good. Do mind that there is usually a URL=
size limit (depending on the browser) so this cannot be used for long mess=
ages/contracts. A possible solution would be to make an option to pass the =
address where the message can be retrieved (and maybe also where the signat=
ure must be sent, to save a copy-paste back?).</div>
<div><br></div><div>Looking at existing solutions, the only other "sig=
n request" that I know of is the CSR (<a href=3D"https://en.wikipedia.=
org/wiki/Certificate_signing_request">https://en.wikipedia.org/wiki/Certifi=
cate_signing_request</a>) but the functionality and goal is very different.=
</div>
<div><br></div><div>It'd be useful (and IMO most important) to write do=
wn some use-cases in which this makes P2SH easier and less involved. How ma=
ny steps can be eliminated of the 14?</div><div><br></div><div>Wladimir</di=
v>
<div>BTW: we also still need a BIP to define URL signing / authentication i=
tself.=C2=A0</div><div><br></div></div>
--001636ed6bda59bbb504bcd477d4--
|
