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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UZOZV-0005x3-U2
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 16:47:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.176 as permitted sender)
client-ip=209.85.214.176; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f176.google.com;
Received: from mail-ob0-f176.google.com ([209.85.214.176])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UZOZU-0005gB-21
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 16:47:29 +0000
Received: by mail-ob0-f176.google.com with SMTP id er7so3265553obc.35
for <bitcoin-development@lists.sourceforge.net>;
Mon, 06 May 2013 09:47:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.40.129 with SMTP id x1mr5755085obk.15.1367858842695;
Mon, 06 May 2013 09:47:22 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Mon, 6 May 2013 09:47:22 -0700 (PDT)
In-Reply-To: <20130506163732.GB5193@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>
Date: Mon, 6 May 2013 18:47:22 +0200
X-Google-Sender-Auth: IQUb8ihUli5J1bN1_xV6MqpLesk
Message-ID: <CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
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 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
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: 1UZOZU-0005gB-21
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 16:47:30 -0000
> Speaking of, off-topic for this discussion, but in the future
> node-to-node communicate should be encrypted and signed
Yes, I'd like to do this. The threat isn't really ISPs which are
mostly trustable (the worst they normally do outside of places like
China is dick about with ads), the big threat is people who use
untrusted WiFi without realising and end up thinking they received
money when actually they were just connected to a hotspot running in
the attackers pocket. I'm rather expecting that kind of thing to
happen in future.
I think we can converge on the best solution with several iterations:
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.
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.
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).
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.
|
