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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
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 <pete@petertodd.org>) id 1UZP50-0007CH-MN
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 17:20:02 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.161 as permitted sender)
client-ip=62.13.148.161; envelope-from=pete@petertodd.org;
helo=outmail148161.authsmtp.com;
Received: from outmail148161.authsmtp.com ([62.13.148.161])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UZP4u-0007bG-3j for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 17:20:02 +0000
Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233])
by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r46HJmpS063838; Mon, 6 May 2013 18:19:48 +0100 (BST)
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r46HJhTx048787
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 6 May 2013 18:19:45 +0100 (BST)
Date: Mon, 6 May 2013 13:19:43 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130506171943.GA22505@petertodd.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
<20130506161216.GA5193@petertodd.org>
<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
<20130506163732.GB5193@petertodd.org>
<CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC"
Content-Disposition: inline
In-Reply-To: <CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 2641539b-b671-11e2-a49c-0025907707a1
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgQUFVQNAgsB AmUbWlxeUVR7XWU7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxgH fmRGNlFycw1BcHk+ ZEBnWnAVXkJ+dEN+
SxxJR2sBZHphaTUd TRFcflBJcANIexZF bVd/UyIMLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMj8n TBccEC8+WkQJSz97
NxUtKVMABw5RLUwp YxMaVEgGMhQfQgdf A1ovSCFePREZXTct
AA8SW0kSHSYcKQAA
X-Authentic-SMTP: 61633532353630.1021:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UZP4u-0007bG-3j
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
for pruned nodes)
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, 06 May 2013 17:20:02 -0000
--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote:
> Iteration 1) Make it clear in the UI that if the phone is connected to
> WiFi, payments from untrusted people should not be accepted. Currently
> the Android app merely says the money won't be spendable for a few
> minutes. It needs to communicate the "may not exist" aspect more
> clearly. If you're connected via a cell tower, the existing wording is
> fine - it's very unlikely your telco is trying to scam you in a
> person-to-person transaction, traffic is encrypted and 3G+ connections
> authenticate the network so you can't be MITMd except by your telco.
> Assuming you have a good list of IPs, of course.
You mean scam you with a zero-conf transaction that hasn't actually been
broadcast?
You know how I feel about zero-conf.
> Iteration 2) Give nodes keys that appear in addr broadcasts and seed
> data (whether it be via https or otherwise), and have each node keep a
> running hash of all messages sent on a connection so far. Add a new
> protocol message that asks the node to sign the current accumulated
> hash. Not all messages really need to be signed, eg asking for
> signatures of blocks is sort of pointless at high difficulty levels
> because the structures are self proving and a simple watchdog timer
> that looks for unusually slow progress is probably enough. If the
> client keeps the same accumulated hash then when you encounter
> something you care about the accuracy of, you can ask for a signature
> over all traffic so far.
We already depend on OpenSSL, why not just use standard SSL?
Define a per-node compressed pubkey to pass around, and then do whatever
is easiest to get the actual SSL up and running. If we have to use that
pubkey to in-turn sign for a secondary RSA key or whatever due to
compatibility, no big deal.
Define a new service bit SSL and if you connect to a SSL supporting node
switch to SSL within the same TCP connection.
> Iteration 3) Do something about end to end encryption, just delegate
> everything to Tor, or find some other way to obfuscate the origin of a
> transaction (a mini onion network for example).
Obfusication probably isn't the hard part, it's SPV bloom filter privacy
that is the tough one, but probably a problem better handled by Tor.
> Last time I looked, Tor wasn't really usable in library form and
> connecting to hidden services is really slow. So it'd be an issue to
> just re-use it out of the box, I think.
For phone stuff you should work with The Guardian Project - they've
implemented Tor on Android among other things and want to find easier
ways for apps to use it.
--=20
'peter'[:-1]@petertodd.org
000000000000014671272e3a4dd966bb56d4a9a27751b5cd4dc75dc931660cb5
--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlGH5i8ACgkQpEFN739thoyx1gCfUg4H9Fqya4cx9PURSWrn+5dD
MbcAoIGlp0BNtznKD4HiCJwYKqTk/42y
=w4zb
-----END PGP SIGNATURE-----
--wRRV7LY7NUeQGEoC--
|
