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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YIM7e-0006Le-3Q
for bitcoin-development@lists.sourceforge.net;
Mon, 02 Feb 2015 18:53:22 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.176 as permitted sender)
client-ip=209.85.212.176; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f176.google.com;
Received: from mail-wi0-f176.google.com ([209.85.212.176])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YIM7c-00070r-VZ
for bitcoin-development@lists.sourceforge.net;
Mon, 02 Feb 2015 18:53:22 +0000
Received: by mail-wi0-f176.google.com with SMTP id bs8so19110613wib.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 02 Feb 2015 10:53:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.60.77 with SMTP id f13mr45667790wjr.105.1422903194927;
Mon, 02 Feb 2015 10:53:14 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Mon, 2 Feb 2015 10:53:14 -0800 (PST)
In-Reply-To: <05590A33-1802-4C15-91C0-8777ACD8440B@voskuil.org>
References: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com>
<54CE3816.6020505@bitwatch.co>
<68C03646-02E7-43C6-9B73-E4697F3AA5FD@gmail.com>
<05590A33-1802-4C15-91C0-8777ACD8440B@voskuil.org>
Date: Mon, 2 Feb 2015 19:53:14 +0100
X-Google-Sender-Auth: L7m4qfMv1xdj64k3yiMUsYn9a8k
Message-ID: <CANEZrP1QgtJ2urNTVqbscrXaJ=wefUO16GQ=THaSBnLq9QBmeQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=047d7b86db8a7bca9a050e1f7760
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1YIM7c-00070r-VZ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware
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: Mon, 02 Feb 2015 18:53:22 -0000
--047d7b86db8a7bca9a050e1f7760
Content-Type: text/plain; charset=UTF-8
>
> In sending the first-signed transaction to another for second signature,
> how does the first signer authenticate to the second without compromising
> the independence of the two factors?
Not sure what you mean. The idea is the second factor displays the
transaction and the user confirms it matches what they input to the first
factor. Ideally, using BIP70, but I don't know if BA actually uses that
currently.
It's the same model as the TREZOR, except with a desktop app instead of
myTREZOR and a phone instead of a dedicated hardware device.
--047d7b86db8a7bca9a050e1f7760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">In sending the first-signed transaction to anoth=
er for second signature, how does the first signer authenticate to the seco=
nd without compromising the=C2=A0 independence of the two factors?</blockqu=
ote><div><br></div><div>Not sure what you mean. The idea is the second fact=
or displays the transaction and the user confirms it matches what they inpu=
t to the first factor. Ideally, using BIP70, but I don't know if BA act=
ually uses that currently.</div><div><br></div><div>It's the same model=
as the TREZOR, except with a desktop app instead of myTREZOR and a phone i=
nstead of a dedicated hardware device.=C2=A0</div></div></div></div>
--047d7b86db8a7bca9a050e1f7760--
|
