diff options
| author | Mike Hearn <mike@plan99.net> | 2013-08-16 17:13:28 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-08-16 15:13:36 +0000 |
| commit | 6cb6b39cb678689fc9cf49387bc5d78bac7831b1 (patch) | |
| tree | 2fa35a282f63b8b8dbfa8ec414e288d6da7c5cfc | |
| parent | 3a5f0326edda1c0595e71dc65078dda33905aed6 (diff) | |
| download | pi-bitcoindev-6cb6b39cb678689fc9cf49387bc5d78bac7831b1.tar.gz pi-bitcoindev-6cb6b39cb678689fc9cf49387bc5d78bac7831b1.zip | |
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
| -rw-r--r-- | de/0d0827633ddb35ee812eb4f4508c55dc8f1046 | 119 |
1 files changed, 119 insertions, 0 deletions
diff --git a/de/0d0827633ddb35ee812eb4f4508c55dc8f1046 b/de/0d0827633ddb35ee812eb4f4508c55dc8f1046 new file mode 100644 index 000000000..869955b80 --- /dev/null +++ b/de/0d0827633ddb35ee812eb4f4508c55dc8f1046 @@ -0,0 +1,119 @@ +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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <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 +X-Google-Sender-Auth: eDFGdfybSQ2tdlRhv49x0dqN7CE +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 +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 <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: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 + +<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'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.<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'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.</div> +</div> + +--001a1133073e6ece4704e41208e1-- + + |