1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
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--
|
