|
|
|
@ -742,12 +742,15 @@ the connection. On the peer, bloom filters are checked against each
|
|
|
|
|
incoming transaction. The full node checks several parts of the
|
|
|
|
|
transaction against the bloom filter, looking for a match including:
|
|
|
|
|
|
|
|
|
|
* The transaction ID
|
|
|
|
|
* The data components from the scripts of each of the transaction outputs (every key and hash in the script)
|
|
|
|
|
++++
|
|
|
|
|
<ul>
|
|
|
|
|
<li>The transaction ID</li>
|
|
|
|
|
<li>The data components from the scripts of each of the transaction outputs (every key and hash in the script)</li>
|
|
|
|
|
<li class="less_space pagebreak-before">Each of the transaction inputs</li>
|
|
|
|
|
<li>Each of the input signature data components (or witness scripts)</li>
|
|
|
|
|
</ul>
|
|
|
|
|
++++
|
|
|
|
|
|
|
|
|
|
[role="less_space pagebreak-before"]
|
|
|
|
|
* Each of the transaction inputs
|
|
|
|
|
* Each of the input signature data components (or witness scripts)
|
|
|
|
|
|
|
|
|
|
By checking against all these components, bloom filters can be used to
|
|
|
|
|
match public key hashes, scripts, +OP_RETURN+ values, public keys in
|
|
|
|
|