From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Fri, 1 Jul 2011 12:23:59 -0400 Message-ID: From: Gregory Maxwell To: Christian Decker 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 Subject: Re: [Bitcoin-development] Useful bitcoin patches... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 16:24:05 -0000 On Fri, Jul 1, 2011 at 12:03 PM, Christian Decker 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.