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
|
<pre>
BIP: 61
Layer: Peer Services
Title: Reject P2P message
Author: Gavin Andresen <gavinandresen@gmail.com>
Comments-Summary: Controversial; some recommendation, and some discouragement
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061
Status: Final
Type: Standards Track
Created: 2014-06-18
</pre>
==Abstract==
This BIP describes a new message type for the Bitcoin peer-to-peer network.
==Motivation==
Giving peers feedback about why their blocks or transactions are rejected, or
why they are being banned for not following the protocol helps
interoperability between different implementations.
It also gives SPV (simplified payment verification) clients a hint that something
may be wrong when their transactions are rejected due to insufficient priority
or fees.
==Specification==
Data types in this specification are as described at https://en.bitcoin.it/wiki/Protocol_specification
===reject===
One new message type "reject" is introduced. It is sent directly to a peer in response to a "version", "tx" or "block" message.
For example, the message flow between two peers for a relayed transaction that is rejected for some reason would be:
--> inv
<-- getdata
--> tx
<-- reject
All implementations of the P2P protocol version 70,002 and later should support the reject message.
====common payload====
Every reject message begins with the following fields. Some messages append extra, message-specific data.
{|
| Field Size || Name || Data type || Comments
|-
| variable || response-to-msg || var_str || Message that triggered the reject
|-
| 1 || reject-code || uint8_t || 0x01 through 0x4f (see below)
|-
| variable || reason || var_string || Human-readable message for debugging
|}
The human-readable string is intended only for debugging purposes; in particular, different implementations may
use different strings. The string should not be shown to users or used for anything besides diagnosing
interoperability problems.
The following reject code categories are used; in the descriptions below, "server" is the peer generating
the reject message, "client" is the peer that will receive the message.
{|
| Range || Category
|-
| 0x01-0x0f || Protocol syntax errors
|-
| 0x10-0x1f || Protocol semantic errors
|-
| 0x40-0x4f || Server policy rule
|}
==== rejection codes common to all message types ====
{|
| Code || Description
|-
| 0x01 || Message could not be decoded
|}
==== reject version codes ====
Codes generated during the initial connection process in response to a "version" message:
{|
| Code || Description
|-
| 0x11 || Client is an obsolete, unsupported version
|-
| 0x12 || Duplicate version message received
|}
==== reject tx payload, codes ====
Transaction rejection messages extend the basic message with the transaction id hash:
{|
| Field Size || Name || Data type || Comments
|-
| 32 || hash || char[32] || transaction that is rejected
|}
The following codes are used:
{|
| Code || Description
|-
| 0x10 || Transaction is invalid for some reason (invalid signature, output value greater than input, etc.)
|-
| 0x12 || An input is already spent
|-
| 0x40 || Not mined/relayed because it is "non-standard" (type or version unknown by the server)
|-
| 0x41 || One or more output amounts are below the 'dust' threshold
|-
| 0x42 || Transaction does not have enough fee/priority to be relayed or mined
|}
==== payload, reject block ====
Block rejection messages extend the basic message with the block header hash:
{|
| Field Size || Name || Data type || Comments
|-
| 32 || hash || char[32] || block (hash of block header) that is rejected
|}
Rejection codes:
{|
| code || description
|-
| 0x10 || Block is invalid for some reason (invalid proof-of-work, invalid signature, etc)
|-
| 0x11 || Block's version is no longer supported
|-
| 0x43 || Inconsistent with a compiled-in checkpoint
|}
Note: blocks that are not part of the server's idea of the current best chain, but are otherwise valid, should not trigger reject messages.
== Compatibility ==
The reject message is backwards-compatible; older peers that do not recognize the reject message will ignore it.
== Implementation notes ==
Implementors must consider what happens if an attacker either sends them
reject messages for valid transactions/blocks or sends them random
reject messages, and should beware of possible denial-of-service attacks.
For example, notifying the user of every reject message received
would make it trivial for an attacker to mount an annoy-the-user attack.
Even merely writing every reject message to a debugging log could make
an implementation vulnerable to a fill-up-the-users-disk attack.
|
