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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <zgenjix@yahoo.com>) id 1RAVWS-0008TZ-5h
for bitcoin-development@lists.sourceforge.net;
Sun, 02 Oct 2011 23:32:40 +0000
X-ACL-Warn:
Received: from nm8-vm1.bullet.mail.ne1.yahoo.com ([98.138.91.65])
by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1RAVWR-0007xc-6t for bitcoin-development@lists.sourceforge.net;
Sun, 02 Oct 2011 23:32:40 +0000
Received: from [98.138.90.55] by nm8.bullet.mail.ne1.yahoo.com with NNFMP;
02 Oct 2011 23:32:34 -0000
Received: from [98.138.89.245] by tm8.bullet.mail.ne1.yahoo.com with NNFMP;
02 Oct 2011 23:32:34 -0000
Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP;
02 Oct 2011 23:32:34 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 27483.69650.bm@omp1059.mail.ne1.yahoo.com
Received: (qmail 405 invoked by uid 60001); 2 Oct 2011 23:32:34 -0000
X-YMail-OSG: U1WUqVMVM1mVl6v7MDegpPy7FxXHC3cc8TRfxEwDptqejIw
2zk8mbkj7OVq6szUAJt2Cd9xy_R6hFoYKTzlEBm_fp2PGNnsA59GKYeMZ5Ur
uXHNnD.PKe02CvGg7ISGvxsEiCZEc5dsd333E9NjRSs2N7eGeg6RE3r.VJ.w
tDXgc4PThsk1UKbuo46zihRRqO8rosskfPdcgdOsVBoXWZz57K7Znd8EdR5h
gFs9eVTLZ.uqHE_dbFDOGBpk9ME3nEBiOQzi_uxd3mnaai7Yb7OwDwFpOERc
a0RT_vaNVpw_DSDYQFJ3MY5zA9b1S0mtzRtUf.6cwoTZNDkd7cpTjVN1MtgA
TkaqjP7wEN7hzjsna_fUWhwumvDr5YhfkRM7g0Xj720RgXRyvLCeN7rOrJpk
NtonHMG5w7WYZaPjyXXKaY.ZyvdYfGJW62SR1yAgT0niF2J0TZbLl0_tWX.A Z
Received: from [92.20.125.123] by web121015.mail.ne1.yahoo.com via HTTP;
Sun, 02 Oct 2011 16:32:33 PDT
X-Mailer: YahooMailWebService/0.8.114.317681
Message-ID: <1317598353.90764.YahooMailNeo@web121015.mail.ne1.yahoo.com>
Date: Sun, 2 Oct 2011 16:32:33 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [98.138.91.65 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(zgenjix[at]yahoo.com)
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1RAVWR-0007xc-6t
Subject: [Bitcoin-development] My thoughts on DoS code
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>
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: Sun, 02 Oct 2011 23:32:40 -0000
Hey,
The Zen of Python is relevant here: http://www.python.org/dev/peps/pep-0020/
"In the face of ambiguity, refuse the temptation to guess."
If a node incorrectly implements the standard then it should be shunned immediately. Not only is this more secure, but it will ensure long term compatibility between different implementations. Gavin argues that being a bit lenient makes it easier for people working on other implementations.
I'd argue the opposite being the only person that's working on a full node implementation. Lucky I know my way around the code, so I don't have to guess. But if I did not things would be much harder. Imagine you're trying to interact with this protocol and then randomly it will suddenly disconnect you because of accumulated errors that have been building up.
Everything should be strict, explicit, unambiguous and loud.
I propose a new message type: "error" Payload is a uint64_t error_code and var_str reason.
Before disconnecting a node you can send it an error message. The error_code is the main class of error- i.e version_sent_twice. Reason is just an implementation specific string that can add context.
Other possible fields:
uint8_t seriousness (debug, info, warning, error, fatal)
uint8_t action_taken (disconnect, blacklist, .etc)
|
