From 122171a55af6028db9f7fe51ccf28783c9ff9a09 Mon Sep 17 00:00:00 2001 From: clenser Date: Thu, 19 Oct 2023 00:32:56 +0000 Subject: [PATCH] Edited ch06_transactions.adoc with Atlas code editor --- ch06_transactions.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch06_transactions.adoc b/ch06_transactions.adoc index 4b1e1943..eb87fcd2 100644 --- a/ch06_transactions.adoc +++ b/ch06_transactions.adoc @@ -148,7 +148,7 @@ Service (DoS) attacks that we'll discuss((("transactions", "version of", startre === Extended Marker and Flag -The next two fields((("transactions", "extended serialization format")))((("extended serialization format"))) of the example serialized transaction were added as +The next two fields((("transactions", "extended serialization format")))((("extended serialization format")))((("BIP144 extended serialization format"))) of the example serialized transaction were added as part of the segregated witness (segwit) soft fork change to Bitcoin's consensus rules. The rules were changed according to BIPs 141 and 143, but the _extended serialization format_ is defined in BIP144. @@ -163,7 +163,7 @@ be present. This is compatible with the original version of Bitcoin's transaction serialization format, now called _legacy serialization_. For details, see <>. -In legacy serialization, the marker byte would have been interpreted as +In ((("transactions", "legacy serialization")))((("legacy serialization")))legacy serialization, the marker byte would have been interpreted as the number of inputs (zero). A transaction can't have zero inputs, so the marker signals to modern programs that extended serialization is being used. The flag field provides a similar signal and also