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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CANEZrP3wzMi3oWcwCt-GEs1cXdNa0mzvso_d3htJxaahiewaYw@mail.gmail.com>
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>
Date: Fri, 16 Aug 2013 17:13:28 +0200
Message-ID: <CANEZrP0FOTuaHKeobN-RvWYsUrZQb52FtQWrqjFovWTCfQOrng@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a1133073e6ece4704e41208e1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Precedence: list

--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

<div dir=3D"ltr">Oops, hit send too early.<div><br></div><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Besides, priorit=
isation isn&#39;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&#39;d be prioritised lower than checking blocks/broadcasts.<br=
>
</div></div></div></div></blockquote><div></div></div><br></div><div class=
=3D"gmail_extra">The other nice thing about this approach, besides being st=
ateless on the server side, is that it&#39;s up to the client whether or no=
t they present the cookie. So the node can say &quot;if you don&#39;t prese=
nt your cookie I&#39;m going to disconnect you&quot; but when the node has =
sufficient resources, it&#39;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.</div>
</div>

--001a1133073e6ece4704e41208e1--