diff --git a/Docs/README.md b/Docs/README.md index c654b8e..ffcd719 100644 --- a/Docs/README.md +++ b/Docs/README.md @@ -35,7 +35,7 @@ URs allow for the interoperable transmission and storage of a variety of informa 1. [ur:crypto-seed test vectors](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-seed-test-vectors.md) -_We also have a more comprehensive [UR overview page](ur-overview.md) that includes links to research paepers, references, code, and other material of interest primarily to UR developers._ +_We also have a more comprehensive [UR overview page](ur-overview.md) that includes links to research papers, references, code, and other material of interest primarily to UR developers._ ### Technology Overview Video @@ -61,6 +61,6 @@ See [the SmartCustody repo](https://github.com/BlockchainCommons/SmartCustody/bl ## Learning Bitcoin from the Command Line -Learning Bitcoin is our classic course that introduce Bitcoin concepts and programming beginning with Bitcoin Core's command-line tools and its RPC interface. +Learning Bitcoin is our classic course that introduces Bitcoin concepts and programming beginning with Bitcoin Core's command-line tools and its RPC interface. 1. [Learning Bitcoin from the Command Line 2.0](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/README.md) 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. 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 Notes Implementation of Satoshi Labs' SLIP-39.
- Largely deprected due to discovery of round-trip failure with BIP-39. Blockchain Commons projects use bc-sskr instead. + Largely deprecated due to discovery of round-trip failure with BIP-39. Blockchain Commons projects use bc-sskr instead. @@ -266,7 +266,7 @@ _The Crypto Commons libraries are reference implementations, meant to be example ## Third-Party Libraries -Blockchain Commons also uses well-supported libraries from third parties. In particular, we make strong usage of The Elements Project [libwally wallet library](https://github.com/ElementsProject/libwally-core). We are further supporting it with wrappers for [Swift](https://github.com/BlockchainCommons/BCLibwallySwift) and [Java](https://github.com/BlockchainCommons/bc-bclibwally-java). +Blockchain Commons also uses well-supported libraries from third parties. In particular, we make strong use of The Elements Project [libwally wallet library](https://github.com/ElementsProject/libwally-core). We are further supporting it with wrappers for [Swift](https://github.com/BlockchainCommons/BCLibwallySwift) and [Java](https://github.com/BlockchainCommons/bc-bclibwally-java). ## Status - Varied @@ -314,7 +314,7 @@ The following people directly contributed to this repository. You can add your n We want to keep all of our software safe for everyone. If you have discovered a security vulnerability, we appreciate your help in disclosing it to us in a responsible manner. We are unfortunately not able to offer bug bounties at this time. -We do ask that you offer us good faith and use best efforts not to leak information or harm any user, their data, or our developer community. Please give us a reasonable amount of time to fix the issue before you publish it. Do not defraud our users or us in the process of discovery. We promise not to bring legal action against researchers who point out a problem provided they do their best to follow the these guidelines. +We do ask that you offer us good faith and use best efforts not to leak information or harm any user, their data, or our developer community. Please give us a reasonable amount of time to fix the issue before you publish it. Do not defraud our users or us in the process of discovery. We promise not to bring legal action against researchers who point out a problem provided they do their best to follow these guidelines. ### Reporting a Vulnerability