From f8e15fa51ffc2ce5ca6db854bfc636057938755e Mon Sep 17 00:00:00 2001
From: claylock <claylock@oreilly.com>
Date: Fri, 27 Oct 2023 12:36:10 +0000
Subject: [PATCH] Edited ch05_wallets.adoc with Atlas code editor

---
 ch05_wallets.adoc | 37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc
index 58fcbe22..443633c0 100644
--- a/ch05_wallets.adoc
+++ b/ch05_wallets.adoc
@@ -817,6 +817,25 @@ another purpose--it allows the introduction of a passphrase that
 serves as an additional security factor protecting the seed, as we will
 describe in more detail in <<recovery_passphrase>>.
 
+[TIP]
+====
+The key-stretching function, with its 2,048 rounds of hashing, makes it
+slightly harder to brute-force attack the recovery code using software.
+Special-purpose hardware is not significantly affected.  For an attacker
+who needs to guess a user's entire recovery code, the length of the code
+(128 bits at a minimum) provides more than sufficient security.  But for
+cases where an attacker might learn a small part of the user's code,
+key-stretching adds some security by slowing down how fast an attacker
+can check different recovery code combinations.  BIP39's parameters were
+considered weak by modern standards even when it was first published
+almost a decade ago, although that's likely a consequence of being
+designed for compatibility with hardware signing devices with low-powered
+CPUs.  Some alternatives to BIP39 use stronger key-stretching
+parameters, such as Aezeed's 32,768 rounds of hashing using the more
+complex Scrypt algorithm, although they may not be as convenient to run
+on hardware signing devices.
+====
+
 The process described in steps 7 through 9 continues from the process
 described previously in <<generating_recovery_words>>:
 
@@ -842,24 +861,6 @@ described previously in <<generating_recovery_words>>:
 .From recovery code to seed
 image::images/mbc3_0505.png["From recovery code to seed"]
 
-[TIP]
-====
-The key-stretching function, with its 2,048 rounds of hashing, makes it
-slightly harder to brute-force attack the recovery code using software.
-Special-purpose hardware is not significantly affected.  For an attacker
-who needs to guess a user's entire recovery code, the length of the code
-(128 bits at a minimum) provides more than sufficient security.  But for
-cases where an attacker might learn a small part of the user's code,
-key-stretching adds some security by slowing down how fast an attacker
-can check different recovery code combinations.  BIP39's parameters were
-considered weak by modern standards even when it was first published
-almost a decade ago, although that's likely a consequence of being
-designed for compatibility with hardware signing devices with low-powered
-CPUs.  Some alternatives to BIP39 use stronger key-stretching
-parameters, such as Aezeed's 32,768 rounds of hashing using the more
-complex Scrypt algorithm, although they may not be as convenient to run
-on hardware signing devices.
-====
 
 Tables pass:[<a data-type="xref" href="#bip39_128_no_pass"
 data-xrefstyle="select: labelnumber">#bip39_128_no_pass</a>],