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-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 <gmaxwell@gmail.com>) id 1QcgVh-0000or-IL
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Jul 2011 16:24:05 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.47 as permitted sender)
client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
helo=mail-qw0-f47.google.com;
Received: from mail-qw0-f47.google.com ([209.85.216.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QcgVg-0000zX-QB
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Jul 2011 16:24:05 +0000
Received: by qwh5 with SMTP id 5so2262366qwh.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 01 Jul 2011 09:23:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.98.20 with SMTP id o20mr2618878qcn.216.1309537439218; Fri,
01 Jul 2011 09:23:59 -0700 (PDT)
Received: by 10.229.2.194 with HTTP; Fri, 1 Jul 2011 09:23:59 -0700 (PDT)
In-Reply-To: <BANLkTi=+jZCANpe8Bmh_7e6KNnQZjF35yA@mail.gmail.com>
References: <BANLkTinus7PWNLJi9rEvTtSB93hjLKhFpg@mail.gmail.com>
<BANLkTi=+jZCANpe8Bmh_7e6KNnQZjF35yA@mail.gmail.com>
Date: Fri, 1 Jul 2011 12:23:59 -0400
Message-ID: <BANLkTimiNOynfvQnncUeiRoZm+CG6njjoA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QcgVg-0000zX-QB
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Useful bitcoin patches...
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, 01 Jul 2011 16:24:05 -0000
On Fri, Jul 1, 2011 at 12:03 PM, Christian Decker
<decker.christian@gmail.com> wrote:
> Some appear to be beneficial to everybody.
> Multithreading the RPC will certainly speed up quite a few services and I
> see no downside in adding it. The same is true for Keep-Alive.
The multithreaded RPC stuff will need very aggressive testing to make
sure it doesn't expose race conditions elsewhere in the code.
E.g. you don't want to lose change from a send because some txn called
getnewaddress concurrently and there was a bug. So far the
multithreaded RPC patches have pretty much only been run by miners...
who have a different rpc profile than everyone else.
(and the MT RPC that I've been using only multhreaded getwork=E2=80=A6)
> The Hub mode is good, and I would go a step further and optimize the
> connection logic for all nodes by default.
Gah. No.
The 'hub mode' is not good. We're already low on sockets network wide,
adding a built in DDOS mode flag to bitcoin that makes nodes
aggressively connect to lots of neighbors is a bad idea. People will
ignorantly enable it thinking they are adding resources to the network
when they are really consuming much much more.
I have a big fast node with a higher connection limit and the flood
fixes and I'm currently seeing 596 inbound connections right now. This
suggests the situation is already a lot worse than the rough numbers
using lfnet connection counts suggested.
Miners, concerned with fast block propagation, should manually addnode
each other. We should fix the addnode logic so that it reserve
connection slots for addnoded nodes and tries to keep connecting to
them (or, alternatively, add a peernode flag for that behavior)
currently addnode is oneshot.
There is a lot of room for longer term improvements to the connection
and forwarding logic, and I have a couple interesting ones I'm running
on my nodes, but we don't really have any good way to test and
validate changes, so I'm hesitant to publish them.
|
