chore: fix a large number of spelling issues
What changed, and why it matters
This commit only fixes spelling mistakes in comments, documentation, debug log messages, and a usage string. There are no code behavior changes, no security fixes, and no functional patches.
No security action needed. Treat as a routine documentation/comment cleanup commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff is a pure typo/spelling correction across 9 files: Python scripts, Markdown/README docs, reStructuredText docs, and a C source comment. No executable logic, parsing, protocol handling, cryptography, or memory management code is modified. The changes are limited to strings that do not affect runtime behavior.
Changed components
Inspect captured patch +11 / −11
diff --git a/components/assets/gen_assets.py b/components/assets/gen_assets.py
index 97b8bf9..0028fab 100644
--- a/components/assets/gen_assets.py
+++ b/components/assets/gen_assets.py
@@ -67,7 +67,7 @@ if __name__ == '__main__':
# Must be passed input json file (eg. downloaded from https://assets.blockstream.info/)
# and the output header/include file to create, for inclusion in assets.c
if len(sys.argv) != 3:
- print('Usage: python', sys.argv[0], '<input json> <ouput file>')
+ print('Usage: python', sys.argv[0], '<input json> <output file>')
sys.exit(1)
input_file = sys.argv[1]
diff --git a/diy/README.md b/diy/README.md
index 3849f1d..783b1ec 100644
--- a/diy/README.md
+++ b/diy/README.md
@@ -171,7 +171,7 @@ _Warning: Doing this cannot be un-done, nor can the signing key that the device
CONFIG_SECURE_FLASH_ENCRYPTION_MODE_RELEASE=y
CONFIG_ESP32_REV_MIN_3=y
-_Depending on the hardare you have selected, you may need to remove the last line that requires a minimum of Rev3 hardware..._
+_Depending on the hardware you have selected, you may need to remove the last line that requires a minimum of Rev3 hardware..._
**Remove**
diff --git a/diy/esp32-cam/README.md b/diy/esp32-cam/README.md
index 9b8f1e4..701cf9d 100644
--- a/diy/esp32-cam/README.md
+++ b/diy/esp32-cam/README.md
@@ -2,7 +2,7 @@
**Note on Programmers and USB/Serial Bridges for ESP32-CAM**
-The ESP32-Cam doesn't have an onboard USB/Serial converter, but is commonly shipped with an ESP32-CAM-MB interface that can simplify programming. Unfortunatly the ESP32-CAM-MB also makes it very difficult to access IO pins, so it's possible to us a different USB/Serial interface. (A CP2104 is a good option as it's low cost, provides both 5v and 3.3v and also allows gives the best compatibility with wallet software)
+The ESP32-Cam doesn't have an onboard USB/Serial converter, but is commonly shipped with an ESP32-CAM-MB interface that can simplify programming. Unfortunately the ESP32-CAM-MB also makes it very difficult to access IO pins, so it's possible to us a different USB/Serial interface. (A CP2104 is a good option as it's low cost, provides both 5v and 3.3v and also allows gives the best compatibility with wallet software)
Once you have flashed the firmware, it's also possible to run the device without any USB/Serial bridge and supplying 5v directly to the ESP32-Cam. (This obviously prevents it being used via USB)
diff --git a/diy/esp32-wrover-cam/README.md b/diy/esp32-wrover-cam/README.md
index 0c38534..f2b2465 100644
--- a/diy/esp32-wrover-cam/README.md
+++ b/diy/esp32-wrover-cam/README.md
@@ -4,7 +4,7 @@
In addition to the 'official' ESP32-WROVER-CAM boards from Freenove, there are also a number of readily available, low cost 'clones'.
-Some of these clones have will have different ports (Freenove with USB-C and cloes with MicroUSB), the camera position is slightly different (Hence why the example 3d printed cases have a rather large camera hole) and they also sometimes have slightly different startup behavior.
+Some of these clones have will have different ports (Freenove with USB-C and close with MicroUSB), the camera position is slightly different (Hence why the example 3d printed cases have a rather large camera hole) and they also sometimes have slightly different startup behavior.
Some clone boards won't boot properly until you press the EN/RST pin after powering up the device. If your board behaves in this way, the simplest solution is to connect the EN/RST pin on your ESP32-WROVER-CAM board to a spare button on your LCD hat. (Pressing this button will then allow you to boot/reset the device at any time)
diff --git a/docs/index.rst b/docs/index.rst
index 879ea2d..1df8c6f 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -12,7 +12,7 @@ Welcome to Jade's RPC documentation!
* All Jade RPC messages are CBOR, roughly based on the format of json-rpc messges.
* The order of named fields inside the messages is unimportant. The order of items in array elements usually is important.
-* In most cases the flow is message-reply-message-reply... the exception is the legacy sign-tx flow where n messages are sent before n replies are recieved.
+* In most cases the flow is message-reply-message-reply... the exception is the legacy sign-tx flow where n messages are sent before n replies are received.
* In some cases there may be a delay between sending a message and a reply being sent, where some physical interaction with the Jade unit is required.
* In general, the types used are string, boolean, uint32/64, and raw byte-strings for binary data.
* Every message contains an `id` field - an arbitrary string up to 16 characters - which is included in the reply.
@@ -63,7 +63,7 @@ get_extended_data request
* 'orig' should be the 'method' of the original request message
* 'seqlen' should be the 'seqlen' in the replies - indicating the total number of message replies which will be required
* 'seqnum' should indicate the next fragment required - it should always be less-than or equal-to the 'seqlen'
-* NOTE: atm 'seqnum' *MUST* indicate the next fragement. ie. ie must be the last received seqnum + 1.
+* NOTE: atm 'seqnum' *MUST* indicate the next fragment. ie. ie must be the last received seqnum + 1.
* NOTE: at the moment these messages are only used for 'sign_psbt' replies, where the full psbt binary may be sufficiently large that it needs to be split over multiple messages. See sign_psbt_request_.
* Use of these messages may increase in future firmware releases.
diff --git a/jadepy/jade.py b/jadepy/jade.py
index 1c8e98f..3240f8f 100644
--- a/jadepy/jade.py
+++ b/jadepy/jade.py
@@ -541,7 +541,7 @@ class JadeAPI:
ack'd by the hw, to notify of upload progress.
Defaults to None, and nothing is called to report upload progress.
extended_replies: bool, optional
- If set Jade may return addtional progress data with each data chunk uploaded, which is
+ If set Jade may return additional progress data with each data chunk uploaded, which is
then passed to any progress callback as above. If not no additional data is returned
or passed.
diff --git a/jadepy/jade_ble.py b/jadepy/jade_ble.py
index 275ed61..c8aee7c 100644
--- a/jadepy/jade_ble.py
+++ b/jadepy/jade_ble.py
@@ -122,11 +122,11 @@ class JadeBleImpl:
f'Serial number: {self.serial_number or "<any>"}')
# Peruse services and characteristics
- # Get the 'handle' of the receiving charactersitic
+ # Get the 'handle' of the receiving characteristic
for service in client.services:
for char in service.characteristics:
if char.uuid == JadeBleImpl.IO_RX_CHAR_UUID:
- logger.debug(f'Found RX characterisitic - handle: {char.handle}')
+ logger.debug(f'Found RX characteristic - handle: {char.handle}')
self.rx_char_handle = char.handle
if 'read' in char.properties:
diff --git a/logo/README.md b/logo/README.md
index c1e7452..459de24 100644
--- a/logo/README.md
+++ b/logo/README.md
@@ -4,7 +4,7 @@
python -c "from zopfli import zlib; import sys; open(sys.argv[2], 'wb').write(zlib.compress(open(sys.argv[1], 'rb').read()))" uncompressed_file.bin compressed_file.bin.gz
```
-# The input file used is the output of GIMP RGB C-Source image dump (file.c) which contains a stucture Picture.
+# The input file used is the output of GIMP RGB C-Source image dump (file.c) which contains a structure Picture.
# Picture contains the following uint32_t width, height, bytes_per_pixel (always set to 2) and then the binary data in a pointer to a uint16_t
# We extracted the binary data into uncompressed_file prepended with a single byte with the width (since it can at most be 240) and then we compressed it with the python above
diff --git a/main/selfcheck.c b/main/selfcheck.c
index 249d026..d50633a 100644
--- a/main/selfcheck.c
+++ b/main/selfcheck.c
@@ -1131,7 +1131,7 @@ static bool test_miniscript_descriptors(void)
}
}
- // Another Liana example - NOTE: resuing placeholder @0
+ // Another Liana example - NOTE: reusing placeholder @0
INIT_DESC(desc, "wsh(or_d(multi(2,@0/<0;1>/*,@1/<0;1>/*),and_v(v:pkh(@0/<2;3>/*),older(65535))))");
ADD_MAP_VAL(desc, "@0",
"[fb5d3ada/48'/1'/0'/2']"
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.