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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VALgk-00049k-L1
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Aug 2013 15:11:42 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.53 as permitted sender)
client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f53.google.com;
Received: from mail-oa0-f53.google.com ([209.85.219.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VALgi-0006ov-V5
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Aug 2013 15:11:42 +0000
Received: by mail-oa0-f53.google.com with SMTP id k18so2350569oag.40
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Aug 2013 08:11:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.60.194 with SMTP id j2mr1709427obr.2.1376665895602; Fri,
16 Aug 2013 08:11:35 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.80.165 with HTTP; Fri, 16 Aug 2013 08:11:35 -0700 (PDT)
In-Reply-To: <20130816145912.GA16533@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>
Date: Fri, 16 Aug 2013 17:11:35 +0200
X-Google-Sender-Auth: M9vncR2bO1EQxpGoMykHPp7IR9E
Message-ID: <CANEZrP3wzMi3oWcwCt-GEs1cXdNa0mzvso_d3htJxaahiewaYw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e01633baaae915204e41201bf
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: 1VALgi-0006ov-V5
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 15:11:42 -0000
--089e01633baaae915204e41201bf
Content-Type: text/plain; charset=UTF-8
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete@petertodd.org> wrote:
> UPNP seems to work well for the reference client. What's the situation
> there on Android?
>
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 android)
> I leave my phone plugged in and connected via wifi for most of the day;
> lots of people do that.
>
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.
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.
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 checking
can be passed onto the general ECDSA thread pool that works its way through
pending signature operations, they'd be prioritised lower than checking
blocks/broadcasts.
--089e01633baaae915204e41201bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <span dir=3D"l=
tr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petert=
odd.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">UPNP seems to work well for the reference client. What's the =
situation</span><br>
</div>
there on Android?<br></blockquote><div><br></div><div>Not sure - it could b=
e investigated. I think UPNP is an entirely userspace-implementable protoco=
l, so in theory it could be done by a userspace library (even libminiupnp -=
java is not a requirement on android)</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">I leave my phone plugged in=
and connected via wifi for most of the day;<br>
lots of people do that.<br></blockquote><div><br></div><div>I suspect you m=
ean "I think lots of people do that". I'm not so sure. We cou=
ld potentially run an experiment in the Android app to measure how many use=
rs are in a position to contribute back, but just because you have wifi doe=
sn't mean you can reconfigure it using UPnP. That helps a lot in home n=
etworks, but at the office it doesn't help.</div>
<div><br></div><div>I'm wary of a ton of work being put in to achieve n=
ot very much here. Satoshi's original vision was always that millions o=
f users were supported by 100,000 or so nodes. I don't think that's=
unreasonable over the long term.</div>
<div><br></div><div>Besides, prioritisation isn't very hard. Nodes can =
just hand clients a signed timestamp which they remember. When re-connectin=
g, 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 checking can be passed onto the general ECDSA thread pool that works it=
s way through pending signature operations, they'd be prioritised lower=
than checking blocks/broadcasts.</div>
<div><br></div></div></div></div>
--089e01633baaae915204e41201bf--
|
