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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
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 1Vb5yY-0005nx-CG
for bitcoin-development@lists.sourceforge.net;
Tue, 29 Oct 2013 09:52:38 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.169 as permitted sender)
client-ip=209.85.214.169; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f169.google.com;
Received: from mail-ob0-f169.google.com ([209.85.214.169])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vb5yW-0003dI-Js
for bitcoin-development@lists.sourceforge.net;
Tue, 29 Oct 2013 09:52:38 +0000
Received: by mail-ob0-f169.google.com with SMTP id uz6so5007535obc.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 29 Oct 2013 02:52:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.36.133 with SMTP id q5mr1527602oej.63.1383040351168; Tue,
29 Oct 2013 02:52:31 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Tue, 29 Oct 2013 02:52:31 -0700 (PDT)
In-Reply-To: <CABsx9T3p6KFc8FiOgBwLtQsmkETE_iUbMhO47pS7J3hi3a9_4w@mail.gmail.com>
References: <274a1888-276c-4aa6-a818-68f548fbe0fa@me.com>
<9DCDB8F6-E3B2-426B-A41E-087E66B3821A@gmail.com>
<526B45DB.2030200@jerviss.org>
<CABsx9T2OMA_u=S9yUh2j78QDuCDUorYctktuixjwAjqc6neW=Q@mail.gmail.com>
<526DD18A.7060201@jerviss.org> <l4lajm$3ga$1@ger.gmane.org>
<CAAS2fgSuL4f9Sdg2CyK-EuCKK04gD98zHDoKFyTg_Fp_cNiz=A@mail.gmail.com>
<CABsx9T3p6KFc8FiOgBwLtQsmkETE_iUbMhO47pS7J3hi3a9_4w@mail.gmail.com>
Date: Tue, 29 Oct 2013 10:52:31 +0100
X-Google-Sender-Auth: YBYhROAlUablJs_McsGMlV5vpyk
Message-ID: <CANEZrP1teOnb=Gt_Nybh0jfQopK06Ps34Hy73OxOpHwuz-iZig@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=089e01293f10d76ff604e9de2c08
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
-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: 1Vb5yW-0003dI-Js
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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: Tue, 29 Oct 2013 09:52:38 -0000
--089e01293f10d76ff604e9de2c08
Content-Type: text/plain; charset=UTF-8
For tx reject, should there be a code for "unknown version"? That is,
tx.nVersion > bestKnownVersion == reject? In that case 0x40 would become
"non-standard transaction type". I think "unknown transaction type" is a
bit vague. Or do we want new tx messages to always be backwards compatible?
0x42 and 0x43 seems a bit similar to me. The sender knows what fee was paid
(presumably). If free transactions and fee-paying transactions end up
having a unified ranking applied, then distinguishing between them in the
reject message won't make much sense.
For block 0x11 again shall there be a separate code for "block is from the
future"? We don't want to lose the nVersion field to people just using it
for nonsense, so does it make sense to reject blocks that claim to be v2 or
v3?
On Tue, Oct 29, 2013 at 6:37 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
>
> Thanks for the feedback, everybody, gist updated:
> https://gist.github.com/gavinandresen/7079034
>
> Categories are:
>
> 0x01-0x0f Protocol syntax errors0x10-0x1f Protocol semantic errors0x40-0x4fServer
> policy rule
> <https://gist.github.com/gavinandresen/7079034#rejection-codes-common-to-all-message-types>
>
> RE: why not a varint: because we're never ever going to run out of reject
> codes. Eight are defined right now, if we ever defined eight more I'd be
> surprised.
>
> RE: why not use HTTP codes directly: because we'd be fitting round pegs
> into square holes.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e01293f10d76ff604e9de2c08
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">For tx reject, should there be a code for "unknown ve=
rsion"? That is, tx.nVersion > bestKnownVersion =3D=3D reject? In t=
hat case 0x40 would become "non-standard transaction type". I thi=
nk "unknown transaction type" is a bit vague. Or do we want new t=
x messages to always be backwards compatible?<div>
<br></div><div>0x42 and 0x43 seems a bit similar to me. The sender knows wh=
at fee was paid (presumably). If free transactions and fee-paying transacti=
ons end up having a unified ranking applied, then distinguishing between th=
em in the reject message won't make much sense.</div>
<div><br></div><div>For block 0x11 again shall there be a separate code for=
"block is from the future"? We don't want to lose the nVersi=
on field to people just using it for nonsense, so does it make sense to rej=
ect blocks that claim to be v2 or v3?</div>
<div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div=
class=3D"gmail_quote">On Tue, Oct 29, 2013 at 6:37 AM, Gavin Andresen <spa=
n dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_bla=
nk">gavinandresen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>Thanks for t=
he feedback, everybody, gist updated:<div>=C2=A0=C2=A0<a href=3D"https://gi=
st.github.com/gavinandresen/7079034" target=3D"_blank">https://gist.github.=
com/gavinandresen/7079034</a></div>
<div><br></div><div>Categories are:</div>
<div><br></div><div><table style=3D"line-height:25px;border-spacing:0px;bor=
der-collapse:collapse;overflow:auto;width:724px;font-size:15px;font-family:=
Helvetica,arial,freesans,clean,sans-serif;display:block;margin:15px 0px">
<tbody><tr style=3D"border-top-width:1px;border-top-style:solid;border-top-=
color:rgb(204,204,204);background-color:rgb(248,248,248)"><td style=3D"bord=
er:1px solid rgb(221,221,221);padding:6px 13px">0x01-0x0f</td><td style=3D"=
border:1px solid rgb(221,221,221);padding:6px 13px">
Protocol syntax errors</td></tr><tr style=3D"border-top-width:1px;border-to=
p-style:solid;border-top-color:rgb(204,204,204)"><td style=3D"border:1px so=
lid rgb(221,221,221);padding:6px 13px">0x10-0x1f</td><td style=3D"border:1p=
x solid rgb(221,221,221);padding:6px 13px">
Protocol semantic errors</td></tr><tr style=3D"border-top-width:1px;border-=
top-style:solid;border-top-color:rgb(204,204,204);background-color:rgb(248,=
248,248)"><td style=3D"border:1px solid rgb(221,221,221);padding:6px 13px">
0x40-0x4f</td><td style=3D"border:1px solid rgb(221,221,221);padding:6px 13=
px">Server policy rule<br></td></tr></tbody></table><h4 style=3D"line-heigh=
t:1.7;font-size:1.2em;font-family:Helvetica,arial,freesans,clean,sans-serif=
;margin:1em 0px 15px;padding:0px">
<a name=3D"14202b7cb90c3677_rejection-codes-common-to-all-message-types" hr=
ef=3D"https://gist.github.com/gavinandresen/7079034#rejection-codes-common-=
to-all-message-types" style=3D"color:rgb(65,131,196);text-decoration:none;d=
isplay:block;padding-left:30px" target=3D"_blank"><span></span></a></h4>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">RE: w=
hy not a varint: =C2=A0because we're never ever going to run out of rej=
ect codes. =C2=A0Eight are defined right now, if we ever defined eight more=
I'd be surprised.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">RE: why not=
use HTTP codes directly: because we'd be fitting round pegs into squar=
e holes.<span class=3D"HOEnZb"><font color=3D"#888888"><br><br>-- <br>--<br=
>Gavin Andresen<br>
</font></span></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Android is increasing in popularity, but the open development platform that=
<br>
developers love is also attractive to malware creators. Download this white=
<br>
paper to learn more about secure code signing practices that can help keep<=
br>
Android apps secure.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D65839951&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D65839951&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--089e01293f10d76ff604e9de2c08--
|
