public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Date: Fri, 16 Aug 2013 17:13:28 +0200	[thread overview]
Message-ID: <CANEZrP0FOTuaHKeobN-RvWYsUrZQb52FtQWrqjFovWTCfQOrng@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3wzMi3oWcwCt-GEs1cXdNa0mzvso_d3htJxaahiewaYw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1386 bytes --]

  reply	other threads:[~2013-08-16 15:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-16  1:00 [Bitcoin-development] Gavin's post-0.9 TODO list Gavin Andresen
2013-08-16  4:06 ` Melvin Carvalho
2013-08-16 12:11 ` Mike Hearn
2013-08-16 12:24   ` Mike Hearn
2013-08-16 13:41     ` Warren Togami Jr.
2013-08-16 13:46       ` Mike Hearn
2013-08-16 13:53         ` Warren Togami Jr.
2013-08-16 14:06       ` Peter Todd
2013-08-16 14:56       ` Gregory Maxwell
2013-08-16 14:01     ` Peter Todd
2013-08-16 14:15       ` Peter Todd
2013-08-16 14:27         ` Warren Togami Jr.
2013-08-16 14:36           ` Mike Hearn
2013-08-16 14:59             ` Peter Todd
2013-08-16 15:06               ` Warren Togami Jr.
2013-08-16 15:11               ` Mike Hearn
2013-08-16 15:13                 ` Mike Hearn [this message]
2013-08-16 15:59                 ` Peter Todd
2013-08-17  0:08             ` Warren Togami Jr.
2013-08-17 12:35               ` Mike Hearn
2013-08-17 13:41                 ` Jeff Garzik
2013-08-19  3:09         ` John Dillon
2013-08-19  3:17           ` Peter Todd
2013-08-19  5:00             ` John Dillon
2013-08-19  5:34               ` John Dillon
2013-08-19  5:11           ` Mark Friedenbach
2013-08-19  9:16           ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANEZrP0FOTuaHKeobN-RvWYsUrZQb52FtQWrqjFovWTCfQOrng@mail.gmail.com \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox