@@ -68,14 +68,12 @@ revision number.
68
68
69
69
A party to a connection will speak all protocol versions in a range,
70
70
say from `protocol_min ` to `protocol_max `, which may be the same.
71
- When a connection is made, both client and server must initially
72
- assume the protocol to use is their own `protocol_min `.
73
71
74
- The client should send a :func: `server.version ` RPC call as early as
75
- possible in order to negotiate the precise protocol version; see its
76
- description for more detail. All responses received in the stream
77
- from and including the server's response to this call will use its
78
- negotiated protocol version.
72
+ The client must send a :func: `server.version ` RPC call as the first
73
+ message on the wire, in order to negotiate the precise protocol
74
+ version; see its description for more detail.
75
+ All responses received in the stream from and including the server's
76
+ response to this call will use its negotiated protocol version.
79
77
80
78
81
79
.. _script hashes :
@@ -138,8 +136,60 @@ block public key.
138
136
139
137
.. _status :
140
138
141
- Status
142
- ------
139
+ Status (protocol 1.5 and later)
140
+ -------------------------------
141
+
142
+ To calculate the `status ` of a :ref: `script hash <script hashes >` (or
143
+ address):
144
+
145
+ 1. Consider all transactions touching the script hash (both those spending
146
+ from it, and those funding it), both confirmed and unconfirmed (in mempool).
147
+
148
+ 2. Order confirmed transactions by increasing height (and position in the
149
+ block if there are more than one in a block).
150
+
151
+ 3. For mempool transactions, we define **height ** to be ``-1 `` if the
152
+ transaction has at least one unconfirmed input, and ``0 `` if all inputs are
153
+ confirmed.
154
+
155
+ 4. Order mempool transactions by ``(-height, tx_hash) ``, that is,
156
+ ``0 `` height txs come before ``-1 `` height txs, and secondarily the
157
+ txid (in network byteorder) is used to arrive at a canonical ordering.
158
+
159
+ 5. For each confirmed tx, form a bytearray: ``tx_hash+height ``, where:
160
+
161
+ * ``tx_hash `` is the 32-byte transaction hash in network byteorder
162
+ (reverse of human display endianness)
163
+
164
+ * ``height `` is the height of the block the tx is included in,
165
+ serialised as 8-bytes, little-endian, signed (two's complement)
166
+
167
+ 6. For each mempool tx, form a bytearray: ``tx_hash+height+fee ``, where:
168
+
169
+ * ``tx_hash `` is the 32-byte transaction hash in network byteorder
170
+ (reverse of human display endianness)
171
+
172
+ * ``height `` is either ``0 `` or ``-1 ``, as defined above,
173
+ serialised as 8-bytes, little-endian, signed (two's complement)
174
+
175
+ * ``fee `` is the transaction fee in minimum coin units (satoshis),
176
+ serialised as 8-bytes, little-endian, unsigned
177
+
178
+ 7. The :dfn: `status ` of the script hash is defined by the following recursion:
179
+
180
+ * ``status_0 `` is 32 zero bytes
181
+
182
+ * ``status_n `` is calculated as ``sha256(status_(n-1) + tx_n) ``
183
+
184
+ That is, for a script hash with an empty history, the status is ``status_0 ``.
185
+ If the history contains ``n `` txs, the status is ``status_n ``. The ``tx_n ``
186
+ series consists of, first the confirmed txs touching the script hash,
187
+ followed by the mempool txs touching it; formatted as described above, as
188
+ bytearrays of length 40 or 48.
189
+
190
+
191
+ Old Status (before protocol 1.5)
192
+ --------------------------------
143
193
144
194
To calculate the `status ` of a :ref: `script hash <script hashes >` (or
145
195
address):
0 commit comments