From 0f79a6232b3fb87f538411d24b95710b13b27d75 Mon Sep 17 00:00:00 2001
From: claylock <claylock@oreilly.com>
Date: Thu, 26 Oct 2023 19:33:05 +0000
Subject: [PATCH] Edited ch10_network.adoc with Atlas code editor

---
 ch10_network.adoc | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/ch10_network.adoc b/ch10_network.adoc
index 5ecf8ac4..f9090670 100644
--- a/ch10_network.adoc
+++ b/ch10_network.adoc
@@ -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