From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VALia-0004Fr-AJ for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 15:13:36 +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 1VALiY-0002o3-7X for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 15:13:36 +0000 Received: by mail-ob0-f176.google.com with SMTP id uz19so2188372obc.35 for ; Fri, 16 Aug 2013 08:13:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.61.115 with SMTP id o19mr126931oer.85.1376666008852; Fri, 16 Aug 2013 08:13:28 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.80.165 with HTTP; Fri, 16 Aug 2013 08:13:28 -0700 (PDT) In-Reply-To: References: <20130816140116.GB16201@petertodd.org> <20130816141536.GD16201@petertodd.org> <20130816145912.GA16533@petertodd.org> Date: Fri, 16 Aug 2013 17:13:28 +0200 X-Google-Sender-Auth: eDFGdfybSQ2tdlRhv49x0dqN7CE Message-ID: From: Mike Hearn To: Peter Todd Content-Type: multipart/alternative; boundary=001a1133073e6ece4704e41208e1 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: 1VALiY-0002o3-7X Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:13:36 -0000 --001a1133073e6ece4704e41208e1 Content-Type: text/plain; charset=UTF-8 Oops, hit send too early. 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. > The other nice thing about this approach, besides being stateless on the server side, is that it's up to the client whether or not they present the cookie. So the node can say "if you don't present your cookie I'm going to disconnect you" but when the node has sufficient resources, it'd just not request this and the client remains anonymous. If the client thinks the server is calling its bluff, it can just wait and see if it really does get disconnected and if so, present the cookie up front next time. --001a1133073e6ece4704e41208e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oops, hit send too early.

Besides, priorit= isation isn't very hard. Nodes can just hand clients a signed timestamp= which they remember. When re-connecting, the signed timestamp is handed ba= ck 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 oper= ations, they'd be prioritised lower than checking blocks/broadcasts.

The other nice thing about this approach, besides being st= ateless on the server side, is that it's up to the client whether or no= t they present the cookie. So the node can say "if you don't prese= nt your cookie I'm going to disconnect you" but when the node has = sufficient resources, it'd just not request this and the client remains= anonymous. If the client thinks the server is calling its bluff, it can ju= st wait and see if it really does get disconnected and if so, present the c= ookie up front next time.
--001a1133073e6ece4704e41208e1--