@@ -68,14 +68,12 @@ revision number.
6868
6969A party to a connection will speak all protocol versions in a range,
7070say 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 `.
7371
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.
7977
8078
8179.. _script hashes :
@@ -138,8 +136,60 @@ block public key.
138136
139137.. _status :
140138
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+ --------------------------------
143193
144194To calculate the `status ` of a :ref: `script hash <script hashes >` (or
145195address):
0 commit comments