diff options
| author | Wladimir <laanwj@gmail.com> | 2012-04-04 08:23:48 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-04-04 06:23:56 +0000 |
| commit | 3c8d947c2ebddcd262fce08b98e4cc8584354d9f (patch) | |
| tree | 8d5f12f36018e980be479aa6daa0f363131dd6b1 | |
| parent | 4ff42b2ff5a1ebf8f04b5a5c2c65b55063632b55 (diff) | |
| download | pi-bitcoindev-3c8d947c2ebddcd262fce08b98e4cc8584354d9f.tar.gz pi-bitcoindev-3c8d947c2ebddcd262fce08b98e4cc8584354d9f.zip | |
Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
| -rw-r--r-- | 93/215c0f8b6b50ac093a7a4391580a2875896217 | 170 |
1 files changed, 170 insertions, 0 deletions
diff --git a/93/215c0f8b6b50ac093a7a4391580a2875896217 b/93/215c0f8b6b50ac093a7a4391580a2875896217 new file mode 100644 index 000000000..44fa77bcf --- /dev/null +++ b/93/215c0f8b6b50ac093a7a4391580a2875896217 @@ -0,0 +1,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-- + + |