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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1SFAhF-00050H-0O
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Apr 2012 20:51:21 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.46 as permitted sender)
client-ip=209.85.216.46; envelope-from=etotheipi@gmail.com;
helo=mail-qa0-f46.google.com;
Received: from mail-qa0-f46.google.com ([209.85.216.46])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SFAhE-0001le-CH
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Apr 2012 20:51:20 +0000
Received: by qatm19 with SMTP id m19so3194465qat.12
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Apr 2012 13:51:15 -0700 (PDT)
Received: by 10.224.9.75 with SMTP id k11mr19107263qak.17.1333486274982;
Tue, 03 Apr 2012 13:51:14 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id dv7sm41310202qab.15.2012.04.03.13.51.13
(version=SSLv3 cipher=OTHER); Tue, 03 Apr 2012 13:51:13 -0700 (PDT)
Message-ID: <4F7B62C6.6010007@gmail.com>
Date: Tue, 03 Apr 2012 16:51:18 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Gavin Andresen <gavinandresen@gmail.com>
References: <4F7A1227.7070306@gmail.com>
<CABsx9T3MQzJ5gN5xTZ9y5d-og11=mB86cM3ZP4S-fhjs1U+20g@mail.gmail.com>
In-Reply-To: <CABsx9T3MQzJ5gN5xTZ9y5d-og11=mB86cM3ZP4S-fhjs1U+20g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SFAhE-0001le-CH
Cc: Bitcoin Dev <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: Tue, 03 Apr 2012 20:51:21 -0000
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.
|
