Wladimir [ARCHIVE] on Nostr: 📅 Original date posted:2012-04-04 📝 Original message:Alan, On Wed, Apr 4, 2012 ...
📅 Original date posted:2012-04-04
📝 Original message:Alan,
On Wed, Apr 4, 2012 at 2:01 AM, Alan Reiner <etotheipi at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120404/5909aec1/attachment.html>;
📝 Original message:Alan,
On Wed, Apr 4, 2012 at 2:01 AM, Alan Reiner <etotheipi at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120404/5909aec1/attachment.html>;