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
154
155
156
157
158
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VAMRZ-0003HX-Ud
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Aug 2013 16:00:05 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.78 as permitted sender)
client-ip=62.13.149.78; envelope-from=pete@petertodd.org;
helo=outmail149078.authsmtp.net;
Received: from outmail149078.authsmtp.net ([62.13.149.78])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VAMRY-0001A2-Ru for bitcoin-development@lists.sourceforge.net;
Fri, 16 Aug 2013 16:00:05 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r7GFxuak015529; Fri, 16 Aug 2013 16:59:56 +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 r7GFxpdM015255
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 16 Aug 2013 16:59:54 +0100 (BST)
Date: Fri, 16 Aug 2013 11:59:51 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130816155951.GA16813@petertodd.org>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
<20130816140116.GB16201@petertodd.org>
<20130816141536.GD16201@petertodd.org>
<CAEz79PoK9u9ffJ5jR8yXk8eCFP0Ytk_bno0mpcpM24mt-GGg5w@mail.gmail.com>
<CANEZrP3hHh3k5+ePGbqVeyo3oV=RTy36FA+8MbOZXg3yMqRxAw@mail.gmail.com>
<20130816145912.GA16533@petertodd.org>
<CANEZrP3wzMi3oWcwCt-GEs1cXdNa0mzvso_d3htJxaahiewaYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs"
Content-Disposition: inline
In-Reply-To: <CANEZrP3wzMi3oWcwCt-GEs1cXdNa0mzvso_d3htJxaahiewaYw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e44af920-068c-11e3-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwQUGUATAgsB AmUbWlJeVVR7XGc7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxt2 cFZeBmRydgBEfXs+ ZENlXngVCUB+JBB0
QE5JFWsONnphaTUc TRJdJAZJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMTci RhZNBn03GlYZAn11
flQaDXI7VEIQKVl0 dx1J
X-Authentic-SMTP: 61633532353630.1023: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: 1VAMRY-0001A2-Ru
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
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: Fri, 16 Aug 2013 16:00:06 -0000
--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote:
> On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete@petertodd.org> wrote:
>=20
> > UPNP seems to work well for the reference client. What's the situation
> > there on Android?
> >
>=20
> Not sure - it could be investigated. I think UPNP is an entirely
> userspace-implementable protocol, so in theory it could be done by a
> userspace library (even libminiupnp - java is not a requirement on androi=
d)
Do find out.
> > I leave my phone plugged in and connected via wifi for most of the day;
> > lots of people do that.
> >
>=20
> I suspect you mean "I think lots of people do that". I'm not so sure. We
> could potentially run an experiment in the Android app to measure how many
> users are in a position to contribute back, but just because you have wifi
> doesn't mean you can reconfigure it using UPnP. That helps a lot in home
> networks, but at the office it doesn't help.
Also worth finding out.
> I'm wary of a ton of work being put in to achieve not very much here.
> Satoshi's original vision was always that millions of users were supported
> by 100,000 or so nodes. I don't think that's unreasonable over the long
> term.
Appeal to authority.
Stop bringing up Satoshi's "vision" - our understanding of
crypto-currencies has improved in the 4.5 years since Bitcoin was
released. Satoshi didn't even forsee pool mining, which says a lot about
his economic judgement.
> Besides, prioritisation isn't very hard. Nodes can just hand clients a
> signed timestamp which they remember. When re-connecting, the signed
> timestamp is handed back to the node and it gives priority to those with
> old timestamps. No state is required on the node side. Signing and checki=
ng
> can be passed onto the general ECDSA thread pool that works its way throu=
gh
> pending signature operations, they'd be prioritised lower than checking
> blocks/broadcasts.
Right, so you're giving priority to peers that have been around for
awhile. You've succeeded in forcing attackers to wait a bit.
A) What's the definition of a peer? What stops me from pretending to be
100 peers?
B) Given an attacker willing to wait, what's your plan?
--=20
'peter'[:-1]@petertodd.org
000000000000004a52a297d9ae8ecde2ba62b681cc5a4cfbf7636032fc78e7d0
--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlIOTHcACgkQpEFN739thoz7gQCcCOvhEPAOUn6wAs/VPGu702s6
vFgAn3wRRl/bLKrpJOqSr/VGpyvMxFWq
=38Pt
-----END PGP SIGNATURE-----
--82I3+IH0IqGh5yIs--
|
