From 170eb3e9fe71b4fd9fb593ccd64f012bf69cf124 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Sat, 4 Feb 2023 17:02:37 +0100 Subject: [PATCH 1/3] Fix: typos Fix: typos --- Docs/ur-1-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Docs/ur-1-overview.md b/Docs/ur-1-overview.md index d25c73a..8ce378d 100644 --- a/Docs/ur-1-overview.md +++ b/Docs/ur-1-overview.md @@ -22,7 +22,7 @@ We are well aware of the dangers of competing standards: However, we believe that the UR specification serves enough real purposes to make the introduction of a new specification worthwhile: -* **It's self-identifying.** We saw different methodologies for transfering keys such as `xpub`, `ypub`, and `zpub` proliferating and thus causing confusion. Worse, they created layer violations by mixing encoding and policy. We wanted to create a specification with more clearly defined layers that could be expandable, yet still self-identify its contents. +* **It's self-identifying.** We saw different methodologies for transferring keys such as `xpub`, `ypub`, and `zpub` proliferating and thus causing confusion. Worse, they created layer violations by mixing encoding and policy. We wanted to create a specification with more clearly defined layers that could be expandable, yet still self-identify its contents. * **It's focused on security.** We're well aware that the transfer of key material between devices is a prime point of vulnerability, and so URs do their best to minimize that danger, ideally by supporting the transmission of those keys (and seeds and other private information) in an airgapped fashion. * **It integrates with QRs.** While QR codes themselves are standard, the data encoded within QR codes is not, resulting in inconsistent usage among developers. We designed URs to resolve these interoperability issues by creating a standardized method for encoding binary data using CBOR and by specifying how to sequence larger binary encoding (as version 40 QR codes max out at 2,953 bytes). * **It focuses on the multisig experience.** We see multisig as the future of Bitcoin, allowing for the creation of independent and resilient cryptocurrency addresses. Previous specifications are locked into the single-sig paradigm, while URs include specifications for a variety of data types crucial to multisig use. @@ -50,7 +50,7 @@ For example: * **Seed:** 59F2293A5BCE7D4DE59E71B4207AC5D2 * **CBOR:** A1015059F2293A5BCE7D4DE59E71B4207AC5D2 * `ur:crypto-seed` is defined as a map which must include the seed and which may include other data such as creation date. - * `A1`represents a map of length 1. + * `A1` represents a map of length 1. * That's major type 5 (for a map), which is represented as `101` in the most significant three bits, plus a length of 1, which is represented as `00001` in the least significant three bits, or overall `0b10100001`, which is `0xA1`. * `01` represents item 1 in the map. * `50` represents a 16-byte byte-string payload. From 92e9ae0c1e355eb1bf320a5030497b2175c21820 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Sat, 4 Feb 2023 17:04:51 +0100 Subject: [PATCH 2/3] Fix: typos Fix: typos --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index ccf3269..873ec5f 100644 --- a/README.md +++ b/README.md @@ -51,7 +51,7 @@ _Blockchain Commons has released a number of kits and CLI tools that exercise th * _Exercises [bc-crypto-base](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-crypto-base) and [bc-bytewords](https://github.com/blockchaincommons/bc-bytewords)._ * **[Keytool](https://github.com/BlockchainCommons/bc-keytool-cli) \(CLI\).** A tool for deriving keys and addresses from seeds. * _Uses [bc-crypto-base](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-crypto-base)._ -* **[LetheKit](https://github.com/BlockchainCommons/bc-lethekit) \(Hardware Kit\).** A do-it-yourself hardware kit for generating and translating seeds in an airgapped manner. Cotains its own version of seedtool built using the Arduino IDE. +* **[LetheKit](https://github.com/BlockchainCommons/bc-lethekit) \(Hardware Kit\).** A do-it-yourself hardware kit for generating and translating seeds in an airgapped manner. Contains its own version of seedtool built using the Arduino IDE. * _LetheKit's Seedtool exercises [bc-crypto-base](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-crypto-base), [bc-bip-39](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-bip-39), [bc-bytewords](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-bytewords), [bc-shamir](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-shamir), [bc-sskr](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-sskr), and [bc-ur](https://github.com/BlockchainCommons/crypto-commons/blob/master/README.md#bc-ur) (the last through a bc-ur-arduino port)._ * **[LifeHashTool](https://github.com/BlockchainCommons/LifeHashTool) \(Swift CLI\).** A tool for generating Lifehash PNGs from the command line. * _LifeHashTool uses [LifeHash](https://github.com/BlockchainCommons/LifeHash)._ @@ -203,7 +203,7 @@ _The Crypto Commons libraries are reference implementations, meant to be example