* [Bitcoin-development] Signature Blocks and URI Sign Requests
@ 2012-04-02 20:55 Alan Reiner
2012-04-03 0:44 ` Luke-Jr
2012-04-03 18:46 ` Gavin Andresen
0 siblings, 2 replies; 12+ messages in thread
From: Alan Reiner @ 2012-04-02 20:55 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4759 bytes --]
I would like to propose two things that are closely related. I will
start making BIPS if there's positive feedback. Sorry it's so long, but
I felt both should be in the same email...
_*(1) Signature Blocks* -- A more-robust, versatile, message-signing
exchange_
Satoshi client 0.6.0 introduced message signing, but I've been fairly
unimpressed with the implementation. Strictly speaking, it works, but
it's really not intended for "regular users." There is no indication of
what message was signed or what address signed it. Key recovery works
for the computers processing it, but the user has no idea what this
chunk of random data is. They don't even know if the message they
thought they signed is what's in the signature (along the lines of the
copy&paste virus, the message could be switched out without the user
noticing).
I have implemented Signature Blocks
<https://bitcointalk.org/index.php?topic=56424.msg776163#msg776163> in
Armory (as of v0.55), which is a fully-functional expansion on the
idea. Along the lines of BIP 10, a signature block is a human-readable
chunk of data that immediately identifies the address and the message
that are being signed. It is easily copy&pasted via email or text
files, and is fairly compact for visual identification. Click the link
above to see an example signature block and an Armory screenshot of the
UI (which needs improvement, but still usable). The verification
process will include:
-- Check that the public key (included or recovered) matches the address
field.
-- Verify that the signature matches the included message for this
public key
-- The message is properly formatted with a standardized character set
and escape/replacement scheme for things like newlines or double-quotes.
gmaxwell already pointed out that key recovery makes the "Public Key"
field pointless. Okay fine -- I just don't have key recovery
implemented yet in Armory, and when I do I can ditch that field (or
simply make it optional). The point is to create a versatile,
human-readable standardized form, much like the BIP 0010
signature-collection scheme <https://en.bitcoin.it/wiki/BIP_0010>.
_*(2) Sign-Message URI scheme***-- Request signed messages from users
using URIs_
I had the idea that for certain services, the first funding address
could be used to identify the owner of an account, and all account
maintenance (such as cashouts) be done through signed messages with this
address. For instance, the user would need both a login password *and*
a signed message in order to make a withdrawal or purchase:
("Please withdraw 12.3 BTC from acct 1828349132 to address
1Hfr3jk2093f")_signed_by_A
This gives the service the ability to use two separate factors to
authenticate the request (username&password *and* access to unencrypted
wallet). This /could/ work with manual signature blocks alone... but
it's too many steps for regular users. However, I think it's workable
if we expand bitcoin URIs to include "Signature Requests".
The URI scheme would add a few parameters to the scheme, and would have
to have further replacement rules to make sure that messages are handled
properly. The general CONOPs would be (*Con*cept of *Op*eration*s*):
-- User navigates to "Withdraw funds" on webpage
-- Webpage has you fill in the details: from-account, to-address,
withdrawal amount
-- Webpage produces a clickable URI link that loads all the
information into your client, including addr-reqd-for-sig
-- Client asks for confirmation and passphrase (if necessary) then
produces a signature (and sig block if necessary)
-- URI may include reply-to field that tells it where to send the
siganture when it's ready
So the extra tags that would be needed would probably be:
"*requestSig*=True":
Flag to identify that this is a signing request URI
"*sigNeeded*=1Qjf3392k31h"
The address that needs to sign the message
"*message*=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f"
Some encoding of the message that can be parsed the
same way on all systems
"*replyurl*=http://requestor.com/sig_replies.asp?"
(Optional) After signing, application will submit the
signature to the replyurl
The reply url could be simply an http URL which will use bitcoin URI
syntax, with the fields above copied. Therefore, to complete the above
request, the application handling the request will simply send an HTTP
request to:
http://requestor.com/sig_replies.asp?*sigNeeded*=1Qjf3392k31h&*message*=...&*signature*=1fb1893ac193...&*replySig*=True
Any thoughts? (I have no doubts that there are :) )
-Alan
[-- Attachment #2: Type: text/html, Size: 6489 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-02 20:55 [Bitcoin-development] Signature Blocks and URI Sign Requests Alan Reiner
@ 2012-04-03 0:44 ` Luke-Jr
2012-04-03 18:46 ` Gavin Andresen
1 sibling, 0 replies; 12+ messages in thread
From: Luke-Jr @ 2012-04-03 0:44 UTC (permalink / raw)
To: bitcoin-development
On Monday, April 02, 2012 4:55:03 PM Alan Reiner wrote:
> Any thoughts? (I have no doubts that there are :) )
IMO, the sign-request URI should be an extension on the existing bitcoin: URI
scheme; this way, sigNeeded can be omitted to imply "sign with a sending
address".
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-02 20:55 [Bitcoin-development] Signature Blocks and URI Sign Requests Alan Reiner
2012-04-03 0:44 ` Luke-Jr
@ 2012-04-03 18:46 ` Gavin Andresen
2012-04-03 18:55 ` Luke-Jr
2012-04-03 20:51 ` Alan Reiner
1 sibling, 2 replies; 12+ messages in thread
From: Gavin Andresen @ 2012-04-03 18:46 UTC (permalink / raw)
To: Alan Reiner; +Cc: Bitcoin Dev
RE: signature blocks and BIP 10:
We should avoid reinventing the wheel, if we can. I think we should
extend existing standards whenever possible.
So: could we encode signature blocks or BIP-10 transactions using
S/MIME ? Or is there a more appropriate "sign a message" standard we
could/should use?
You're glossing over little details like what character encoding is
used for the message, but I'd rather leverage all the work already
done by the IETF to nail down all those little details rather then
re-discover them and come up with our own solutions.
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-03 18:46 ` Gavin Andresen
@ 2012-04-03 18:55 ` Luke-Jr
2012-04-03 19:42 ` Wladimir
2012-04-03 20:51 ` Alan Reiner
1 sibling, 1 reply; 12+ messages in thread
From: Luke-Jr @ 2012-04-03 18:55 UTC (permalink / raw)
To: bitcoin-development
On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
> We should avoid reinventing the wheel, if we can. I think we should
> extend existing standards whenever possible.
I wonder if it's possible to make sigs compatible with PGP/EC ?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-03 18:55 ` Luke-Jr
@ 2012-04-03 19:42 ` Wladimir
2012-04-03 20:04 ` Peter Vessenes
0 siblings, 1 reply; 12+ messages in thread
From: Wladimir @ 2012-04-03 19:42 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke@dashjr•org> wrote:
> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
> > We should avoid reinventing the wheel, if we can. I think we should
> > extend existing standards whenever possible.
>
> I wonder if it's possible to make sigs compatible with PGP/EC ?
>
Or we could take a step back, further into "don't reinvent the wheel"
territory. Why not simply make use of PGP(/EC) to sign and verify messages?
It has many advantages, like an already existing web-of-trust and keyserver
infrastructure.
I still feel like this is sign message stuff is dragging the kitchen sink
into Bitcoin. It's fine for logging into a website, what you use it for,
but anything that approaches signing email (such as S/MIME implementations
and handling different character encodings) is going too far IMO.
Wladimir
[-- Attachment #2: Type: text/html, Size: 1179 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-03 19:42 ` Wladimir
@ 2012-04-03 20:04 ` Peter Vessenes
2012-04-03 21:12 ` Alan Reiner
0 siblings, 1 reply; 12+ messages in thread
From: Peter Vessenes @ 2012-04-03 20:04 UTC (permalink / raw)
To: Wladimir; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]
I don't think it's minimally invasive to layer PGP's web of trust on top of
Bitcoin, in fact, the opposite.
From a certain angle, bitcoin exists as a sort of answer / alternate
solution to the web of trust. Digital cash with an existing web of trust in
place was a working concept in the mid-1990s, courtesy of David Chaum, I
believe.
I totally agree on the kitchen sink concern; I would personally like to see
something like a one-year required discussion period on all non-security
changes proposed to the blockchain protocol. We know almost nothing about
how bitcoin will be used over the next 20 years; I believe it's a mistake
to bulk up the protocol too rapidly right now.
There's a famous phrase from the founder of Lotus about Lotus' engineering
process: "add lightness." The equivalent for protocol design might be "add
simplicity." I'd like to see us adding simplicity for now, getting a core
set of tests together for alternate implementations like libbitcoin, and
thinking hard about the dangers of cruft over a 10+ year period when it
comes to a technology which will necessarily include a complete history of
every crufty decision embodied in transaction histories.
Peter
On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj@gmail•com> wrote:
>
> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke@dashjr•org> wrote:
>
>> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
>> > We should avoid reinventing the wheel, if we can. I think we should
>> > extend existing standards whenever possible.
>>
>> I wonder if it's possible to make sigs compatible with PGP/EC ?
>>
>
> Or we could take a step back, further into "don't reinvent the wheel"
> territory. Why not simply make use of PGP(/EC) to sign and verify messages?
> It has many advantages, like an already existing web-of-trust and keyserver
> infrastructure.
>
> I still feel like this is sign message stuff is dragging the kitchen sink
> into Bitcoin. It's fine for logging into a website, what you use it for,
> but anything that approaches signing email (such as S/MIME implementations
> and handling different character encodings) is going too far IMO.
>
> Wladimir
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
[-- Attachment #2: Type: text/html, Size: 3796 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-03 18:46 ` Gavin Andresen
2012-04-03 18:55 ` Luke-Jr
@ 2012-04-03 20:51 ` Alan Reiner
1 sibling, 0 replies; 12+ messages in thread
From: Alan Reiner @ 2012-04-03 20:51 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
On 04/03/2012 02:46 PM, Gavin Andresen wrote:
> RE: signature blocks and BIP 10:
>
> We should avoid reinventing the wheel, if we can. I think we should
> extend existing standards whenever possible.
>
> So: could we encode signature blocks or BIP-10 transactions using
> S/MIME ? Or is there a more appropriate "sign a message" standard we
> could/should use?
>
> You're glossing over little details like what character encoding is
> used for the message, but I'd rather leverage all the work already
> done by the IETF to nail down all those little details rather then
> re-discover them and come up with our own solutions.
>
I'm glossing over details because I actually have no experience dealing
with character encodings, or the implementation specifics of existing
solutions (PGP or S/MIME). That's why I'm emailing this list: I want
to figure this stuff out, and at the same time try to converge on
something that is efficient and can be interoperable between Armory and
the Satoshi client (wallets, signature collection, sig blocks).
I don't go into these things solely to reinvent stuff. My primary
motivation for both ideas I have pitched so far (BIP 0010 and the sig
blocks) is the versatility. I like the encoding-independent, visual
compactness of PGP ASCII-armored text blocks, but I don't like their
opaqueness. PGP vs my signature blocks basically look the same to a
casual user, but even a moderately-knowledgeable user can appreciate the
human-readable components of it. You can visually identify if
signatures are missing from sig-collection packet, or see that you
signed with the wrong address without having to load an external program.
But that isn't a critical requirement, it's just my personal
preference. I'm fine with existing systems if it sidesteps a lot of
problems and there's easy interface to it. But, I don't want to have
another BSDDB-wallet situation where we end up with 10x more capability
than we need, and pay for it with 10x the complexity (at least in this
case, using PGP is an existing crypto/security-sensitive technology). I
have made "simplicity" one of my goals in Armory.
Alternatively, we could change the discussion to a requirements
discussion, to first figure out what we need in order to address
multi-signature collection, etc. Then evaluate competing ideas based on
their qualities relative to the requirements.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-03 20:04 ` Peter Vessenes
@ 2012-04-03 21:12 ` Alan Reiner
2012-04-03 23:37 ` Mike Koss
0 siblings, 1 reply; 12+ messages in thread
From: Alan Reiner @ 2012-04-03 21:12 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 3921 bytes --]
Just to clarify, I'm not proposing anything to the protocol itself.
Simply that some applications might benefit from users being to sign
messages with existing Bitcoin identities, and what can we do to
accommodate that (out of band)? It's not a high priority, but I think
it's potentially useful, and most codebases already have everything they
need in place to implement it.
On 04/03/2012 04:04 PM, Peter Vessenes wrote:
> I don't think it's minimally invasive to layer PGP's web of trust on
> top of Bitcoin, in fact, the opposite.
>
> From a certain angle, bitcoin exists as a sort of answer / alternate
> solution to the web of trust. Digital cash with an existing web of
> trust in place was a working concept in the mid-1990s, courtesy of
> David Chaum, I believe.
>
> I totally agree on the kitchen sink concern; I would personally like
> to see something like a one-year required discussion period on all
> non-security changes proposed to the blockchain protocol. We know
> almost nothing about how bitcoin will be used over the next 20 years;
> I believe it's a mistake to bulk up the protocol too rapidly right now.
>
> There's a famous phrase from the founder of Lotus about Lotus'
> engineering process: "add lightness." The equivalent for protocol
> design might be "add simplicity." I'd like to see us adding simplicity
> for now, getting a core set of tests together for alternate
> implementations like libbitcoin, and thinking hard about the dangers
> of cruft over a 10+ year period when it comes to a technology which
> will necessarily include a complete history of every crufty decision
> embodied in transaction histories.
>
> Peter
>
>
> On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj@gmail•com
> <mailto:laanwj@gmail•com>> wrote:
>
>
> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke@dashjr•org
> <mailto:luke@dashjr•org>> wrote:
>
> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
> > We should avoid reinventing the wheel, if we can. I think we
> should
> > extend existing standards whenever possible.
>
> I wonder if it's possible to make sigs compatible with PGP/EC ?
>
>
> Or we could take a step back, further into "don't reinvent the
> wheel" territory. Why not simply make use of PGP(/EC) to sign and
> verify messages? It has many advantages, like an already existing
> web-of-trust and keyserver infrastructure.
>
> I still feel like this is sign message stuff is dragging the
> kitchen sink into Bitcoin. It's fine for logging into a website,
> what you use it for, but anything that approaches signing email
> (such as S/MIME implementations and handling different character
> encodings) is going too far IMO.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists•sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
>
> Peter J. Vessenes
> CEO, CoinLab
> M: 206.595.9839
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 6907 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-03 21:12 ` Alan Reiner
@ 2012-04-03 23:37 ` Mike Koss
2012-04-04 0:01 ` Alan Reiner
0 siblings, 1 reply; 12+ messages in thread
From: Mike Koss @ 2012-04-03 23:37 UTC (permalink / raw)
To: Alan Reiner; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5250 bytes --]
Alan, I'm coming in late to the conversation - do I understand that BIP 010
does not propose any changes to the protocol - but just an intermediate
data format that other clients might use to collect the need key material
to sign a multi-signature block?
If so - one might ask what the role of BIP's are if they actually do not
impact the protocol?
If there is any encapsulated data format that is expected to be interpreted
by clients - I'd call that a "protocol change"; but I take it in this
instance that you will transmit these signature block out of band from the
client ... yet they would have to be parsed and converted into a
Transaction Script once collected by SOME client? Would we expect the
standard client do so?
Sorry if this has been discussed before - I'm trying to understand the
proposal.
On Tue, Apr 3, 2012 at 2:12 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> **
> Just to clarify, I'm not proposing anything to the protocol itself.
> Simply that some applications might benefit from users being to sign
> messages with existing Bitcoin identities, and what can we do to
> accommodate that (out of band)? It's not a high priority, but I think it's
> potentially useful, and most codebases already have everything they need in
> place to implement it.
>
>
>
> On 04/03/2012 04:04 PM, Peter Vessenes wrote:
>
> I don't think it's minimally invasive to layer PGP's web of trust on top
> of Bitcoin, in fact, the opposite.
>
> From a certain angle, bitcoin exists as a sort of answer / alternate
> solution to the web of trust. Digital cash with an existing web of trust in
> place was a working concept in the mid-1990s, courtesy of David Chaum, I
> believe.
>
> I totally agree on the kitchen sink concern; I would personally like to
> see something like a one-year required discussion period on all
> non-security changes proposed to the blockchain protocol. We know almost
> nothing about how bitcoin will be used over the next 20 years; I believe
> it's a mistake to bulk up the protocol too rapidly right now.
>
> There's a famous phrase from the founder of Lotus about Lotus'
> engineering process: "add lightness." The equivalent for protocol design
> might be "add simplicity." I'd like to see us adding simplicity for now,
> getting a core set of tests together for alternate implementations like
> libbitcoin, and thinking hard about the dangers of cruft over a 10+ year
> period when it comes to a technology which will necessarily include a
> complete history of every crufty decision embodied in transaction histories.
>
> Peter
>
>
> On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj@gmail•com> wrote:
>
>>
>> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke@dashjr•org> wrote:
>>
>>> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
>>> > We should avoid reinventing the wheel, if we can. I think we should
>>> > extend existing standards whenever possible.
>>>
>>> I wonder if it's possible to make sigs compatible with PGP/EC ?
>>>
>>
>> Or we could take a step back, further into "don't reinvent the wheel"
>> territory. Why not simply make use of PGP(/EC) to sign and verify messages?
>> It has many advantages, like an already existing web-of-trust and keyserver
>> infrastructure.
>>
>> I still feel like this is sign message stuff is dragging the kitchen sink
>> into Bitcoin. It's fine for logging into a website, what you use it for,
>> but anything that approaches signing email (such as S/MIME implementations
>> and handling different character encodings) is going too far IMO.
>>
>> Wladimir
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
>
> Peter J. Vessenes
> CEO, CoinLab
> M: 206.595.9839
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.http://p.sf.net/sfu/Boundary-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists•sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
[-- Attachment #2: Type: text/html, Size: 8779 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-03 23:37 ` Mike Koss
@ 2012-04-04 0:01 ` Alan Reiner
2012-04-04 6:23 ` Wladimir
0 siblings, 1 reply; 12+ messages in thread
From: Alan Reiner @ 2012-04-04 0:01 UTC (permalink / raw)
To: Mike Koss; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 7517 bytes --]
Mike,
You make an excellent point. Neither of these proposals impact the
protocol itself. I hadn't considered that. But I think it's a
critically important problem to solve (signature blocks, not so much,
but it could piggy back on the same solution). So the mailing list is
a good place to discuss this, but it maybe it shouldn't be labeled as a
BIP. I'll leave that up to the others (arguably, the URI scheme is not
a protocol change, either, but was still a BIP).
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).
I think we need to supply a solution to this existing problem before
everyone starts solving it on their own and fragmenting the market. No
one has to use the solution we come up with -- but I believe it's a
problem for which most developers will take any solution that is easy to
exchange, size-efficient and promised to be interoperable (if for no
other reason than the Satoshi client uses it).
-Alan
On 04/03/2012 07:37 PM, Mike Koss wrote:
> Alan, I'm coming in late to the conversation - do I understand that
> BIP 010 does not propose any changes to the protocol - but just an
> intermediate data format that other clients might use to collect the
> need key material to sign a multi-signature block?
>
> If so - one might ask what the role of BIP's are if they actually do
> not impact the protocol?
>
> If there is any encapsulated data format that is expected to be
> interpreted by clients - I'd call that a "protocol change"; but I take
> it in this instance that you will transmit these signature block out
> of band from the client ... yet they would have to be parsed and
> converted into a Transaction Script once collected by SOME client?
> Would we expect the standard client do so?
>
> Sorry if this has been discussed before - I'm trying to understand the
> proposal.
>
>
> On Tue, Apr 3, 2012 at 2:12 PM, Alan Reiner <etotheipi@gmail•com
> <mailto:etotheipi@gmail•com>> wrote:
>
> Just to clarify, I'm not proposing anything to the protocol
> itself. Simply that some applications might benefit from users
> being to sign messages with existing Bitcoin identities, and what
> can we do to accommodate that (out of band)? It's not a high
> priority, but I think it's potentially useful, and most codebases
> already have everything they need in place to implement it.
>
>
>
> On 04/03/2012 04:04 PM, Peter Vessenes wrote:
>> I don't think it's minimally invasive to layer PGP's web of trust
>> on top of Bitcoin, in fact, the opposite.
>>
>> From a certain angle, bitcoin exists as a sort of answer /
>> alternate solution to the web of trust. Digital cash with an
>> existing web of trust in place was a working concept in the
>> mid-1990s, courtesy of David Chaum, I believe.
>>
>> I totally agree on the kitchen sink concern; I would personally
>> like to see something like a one-year required discussion period
>> on all non-security changes proposed to the blockchain protocol.
>> We know almost nothing about how bitcoin will be used over the
>> next 20 years; I believe it's a mistake to bulk up the protocol
>> too rapidly right now.
>>
>> There's a famous phrase from the founder of Lotus about Lotus'
>> engineering process: "add lightness." The equivalent for protocol
>> design might be "add simplicity." I'd like to see us adding
>> simplicity for now, getting a core set of tests together for
>> alternate implementations like libbitcoin, and thinking hard
>> about the dangers of cruft over a 10+ year period when it comes
>> to a technology which will necessarily include a complete history
>> of every crufty decision embodied in transaction histories.
>>
>> Peter
>>
>>
>> On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj@gmail•com
>> <mailto:laanwj@gmail•com>> wrote:
>>
>>
>> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke@dashjr•org
>> <mailto:luke@dashjr•org>> wrote:
>>
>> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
>> > We should avoid reinventing the wheel, if we can. I
>> think we should
>> > extend existing standards whenever possible.
>>
>> I wonder if it's possible to make sigs compatible with
>> PGP/EC ?
>>
>>
>> Or we could take a step back, further into "don't reinvent
>> the wheel" territory. Why not simply make use of PGP(/EC) to
>> sign and verify messages? It has many advantages, like an
>> already existing web-of-trust and keyserver infrastructure.
>>
>> I still feel like this is sign message stuff is dragging the
>> kitchen sink into Bitcoin. It's fine for logging into a
>> website, what you use it for, but anything that approaches
>> signing email (such as S/MIME implementations and handling
>> different character encodings) is going too far IMO.
>>
>> Wladimir
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> <mailto:Bitcoin-development@lists•sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> --
>>
>> Peter J. Vessenes
>> CEO, CoinLab
>> M: 206.595.9839 <tel:206.595.9839>
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net <mailto:Bitcoin-development@lists•sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists•sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
> Mike Koss
> CTO, CoinLab
> (425) 246-7701 (m)
>
> A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you
> need to know about Bitcoins.
>
[-- Attachment #2: Type: text/html, Size: 14388 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-04 0:01 ` Alan Reiner
@ 2012-04-04 6:23 ` Wladimir
2012-04-04 8:35 ` Michael Grønager
0 siblings, 1 reply; 12+ messages in thread
From: Wladimir @ 2012-04-04 6:23 UTC (permalink / raw)
To: Alan Reiner; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2600 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
2012-04-04 6:23 ` Wladimir
@ 2012-04-04 8:35 ` Michael Grønager
0 siblings, 0 replies; 12+ messages in thread
From: Michael Grønager @ 2012-04-04 8:35 UTC (permalink / raw)
To: Alan Reiner; +Cc: Bitcoin Dev
Hi Alan,
I am using an approach similar to your proposal in a service I am developing. I have, however, chosen to sign using the following scheme:
1. take sha512 of document (=hash512)
2. take ripemd160 of hash512
3. create 512 bit data structure, where the first 352bits are '0', and the rest is the ripemd160 of our hash512
4. sign it with the key
This procedure prevents an evil site from fooling you to sign a transaction spending your own coins. So bottom like never sign a full sha512 with a key for any other purpose than a transaction. (The above could easily well have been implemented as just truncating the hash512 to 256 bits, feel free to propose the optimal scheme).
/M
On 04/04/2012, at 08:23, Wladimir wrote:
> 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.
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-04-04 8:35 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-02 20:55 [Bitcoin-development] Signature Blocks and URI Sign Requests Alan Reiner
2012-04-03 0:44 ` Luke-Jr
2012-04-03 18:46 ` Gavin Andresen
2012-04-03 18:55 ` Luke-Jr
2012-04-03 19:42 ` Wladimir
2012-04-03 20:04 ` Peter Vessenes
2012-04-03 21:12 ` Alan Reiner
2012-04-03 23:37 ` Mike Koss
2012-04-04 0:01 ` Alan Reiner
2012-04-04 6:23 ` Wladimir
2012-04-04 8:35 ` Michael Grønager
2012-04-03 20:51 ` Alan Reiner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox