From 57e5c874c543af3c16c6b1d93a385fc23aa2d6d6 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 21 Sep 2023 10:07:39 +0200 Subject: [PATCH 1/5] fix typos --- doc/omnij-consensus-tool-manpage.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/omnij-consensus-tool-manpage.adoc b/doc/omnij-consensus-tool-manpage.adoc index 0a661650..8b4e71c7 100644 --- a/doc/omnij-consensus-tool-manpage.adoc +++ b/doc/omnij-consensus-tool-manpage.adoc @@ -80,7 +80,7 @@ Specify an Omni property id Write consensus info to _filename_ *-v*, *-verbose*:: -Verbose (logging) outpu. +Verbose (logging) output. *-x*, *-compare*:: @@ -103,13 +103,13 @@ Perform a consensus comparison Here are some examples. -* Print consensus info for property id 1 (OMNI) from localhost Omni Core. The command will use the information in `bitcion.conf` to find the local server. +* Print consensus info for property id 1 (OMNI) from localhost Omni Core. The command will use the information in `bitcoin.conf` to find the local server. + ------------ $ omnij-consensus-tool -property 1 ------------ -* Save consensus info for property id 1 (OMNI) from localhost Omni Core to a tab-seperate-value file named `omni_balances.tsv`. The command will use the information in `bitcion.conf` to find the local server. +* Save consensus info for property id 1 (OMNI) from localhost Omni Core to a tab-separate-value file named `omni_balances.tsv`. The command will use the information in `bitcoin.conf` to find the local server. + ------------ $ omnij-consensus-tool -property 1 -output omni_balances.tsv From 218e530a253cb0ba468e7d23c0b9424d2a721a3d Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 21 Sep 2023 10:08:51 +0200 Subject: [PATCH 2/5] fix typo --- README.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.adoc b/README.adoc index c638e768..589e70e2 100644 --- a/README.adoc +++ b/README.adoc @@ -308,7 +308,7 @@ The command-line consensus tool, `omnij-consensus-tool` can be built into a nati === Building -Before building you'll need a GraalVM setup on your system. Besides intalling the Graal JDK, you'll need to do the following: +Before building you'll need a GraalVM setup on your system. Besides installing the Graal JDK, you'll need to do the following: 1. Set `GRAAL_HOME` to the `JAVA_HOME` of the GraalVM JDK 2. With the GraalVM active, type `gu install native-image` to install the optional `native-image` tool. From 9eee65e30b2f4630a35c840071924fe019dc3ab1 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 21 Sep 2023 10:10:59 +0200 Subject: [PATCH 3/5] fix typos --- doc/omni-consensus-hashing.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/omni-consensus-hashing.adoc b/doc/omni-consensus-hashing.adoc index e043c65c..5ab5083b 100644 --- a/doc/omni-consensus-hashing.adoc +++ b/doc/omni-consensus-hashing.adoc @@ -35,7 +35,7 @@ It is for these reasons that we propose using a hashing function to create hashe Details forthcoming. -Note that the hash data does not need to be calculate or stored by Omni Core itself, but can be calculated and stored by integration tests and/or Omniwallet. Hashes could be stored in a SQL databases and indexed by block height and currencyID. +Note that the hash data does not need to be calculated or stored by Omni Core itself, but can be calculated and stored by integration tests and/or Omniwallet. Hashes could be stored in a SQL databases and indexed by block height and currencyID. === Defining inputs to the hashes @@ -51,11 +51,11 @@ This is a hash of all consensus data for all currencies in existence at a specif === Currency Delta Consensus Hash -A hash of only the changes to balances of a specific CurrencyID that occurred during the specific block. This has may not be very useful and/or may be difficult to compute. +A hash of only the changes to balances of a specific CurrencyID that occurred during the specific block. This may not be very useful and/or may be difficult to compute. === Block Delta Consensus Hash -A hash of the changes to balances of all currencies that occurred during the specific block. This has may not be very useful and/or may be difficult to compute. +A hash of the changes to balances of all currencies that occurred during the specific block. This may not be very useful and/or may be difficult to compute. == Notes on Hash Algorithms From f31352171bd4277d149c197dba7205ea69ca0099 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 21 Sep 2023 10:11:41 +0200 Subject: [PATCH 4/5] fix typo --- doc/omni-utxo-management.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/omni-utxo-management.adoc b/doc/omni-utxo-management.adoc index 524492eb..38eed1fa 100644 --- a/doc/omni-utxo-management.adoc +++ b/doc/omni-utxo-management.adoc @@ -52,7 +52,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki[BIP-84: Derivatio === SLIP 44 -SatoshiLabs has created the **SLIP** family of specifications for the purpose of creating interoperability between hardware wallets. Since the **BIP** specifications are very Bitcoin-specific and the understandable reluctance of Bitcoin developers to spend time updating their specification documents for "alt coins", the **SLIP** specifications fill this gap and provide practical standards for wallet manufacturers and developers wishing ot support multiple blockchains in a standard matter. +SatoshiLabs has created the **SLIP** family of specifications for the purpose of creating interoperability between hardware wallets. Since the **BIP** specifications are very Bitcoin-specific and the understandable reluctance of Bitcoin developers to spend time updating their specification documents for "alt coins", the **SLIP** specifications fill this gap and provide practical standards for wallet manufacturers and developers wishing to support multiple blockchains in a standard matter. https://github.com/satoshilabs/slips/blob/master/slip-0044.md[SLIP-0044 : Registered coin types for BIP-0044] provides an official registry of BIP 44 coin types for various coins -- _including Omni!_ Omni is listed with coin type *200*. From 391ec7ee9d7fbc572b258642b35b9ed2bbdb7351 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 21 Sep 2023 10:13:18 +0200 Subject: [PATCH 5/5] fix typos --- doc/omnij-test-design-patterns.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/omnij-test-design-patterns.adoc b/doc/omnij-test-design-patterns.adoc index 368a29c4..9c059080 100644 --- a/doc/omnij-test-design-patterns.adoc +++ b/doc/omnij-test-design-patterns.adoc @@ -23,17 +23,17 @@ Although the initial focus was testing, it was always the intention to build gen The core clients are written in pure Java are strongly typed using bitcoinj classes (e.g. Sha256Sum, Address) and use method overloading to create convenience methods with fewer parameters given that Java doesn't support optional parameters. -More detail should be provided here. I've written about this elsewhere (Github Issue comments?) and some of that information should be consoolidated here. +More detail should be provided here. I've written about this elsewhere (Github Issue comments?) and some of that information should be consolidated here. === Test Support Classes -Since all the tests are written in the Spock Framework and we want to support rapid development of expressive, non-verbose tests, most of of the test support code is in Groovy -- with much of it being in Groovy traits and in Spock base classes. +Since all the tests are written in the Spock Framework and we want to support rapid development of expressive, non-verbose tests, most of the test support code is in Groovy -- with much of it being in Groovy traits and in Spock base classes. As use cases beyond testing are discovered for functionality in test support components, it can be refactored into classes that can be used outside of the test framework and even into pure Java classes when we desire to support the largest possible set of run-time environments. == Test Framework Design Patterns -A variety of approaches are made for aggregrating test framework functionality into the Spock integration tests. Each approach has advantages and disadvantages and we have been frequently refactoring the code to maximize readability and to make core functionality reusable within the tests and, when desired, outside the tests. +A variety of approaches are made for aggregating test framework functionality into the Spock integration tests. Each approach has advantages and disadvantages and we have been frequently refactoring the code to maximize readability and to make core functionality reusable within the tests and, when desired, outside the tests. When test support functionality is useful for (upstream) Bitcoin testing, we place it in a subpackage of `com.msgilligan.bitcoin`, when it is Omni specific we place it in a subpackage of `foundation.omni`. @@ -77,7 +77,7 @@ Disadvantage: === RPC Clients -When there is functionality that will be useful to any application communicating with Bitcoin/Omni Core via JSON-RPC that functionality can be placed directly in one of the RPC client implementations. Currently all the RPC clients generally try to limit themselves to 1 RPC call per method and try to keep a 1-to-1 relationship betwen client object methods and JSON-RPC methods. +When there is functionality that will be useful to any application communicating with Bitcoin/Omni Core via JSON-RPC that functionality can be placed directly in one of the RPC client implementations. Currently all the RPC clients generally try to limit themselves to 1 RPC call per method and try to keep a 1-to-1 relationship between client object methods and JSON-RPC methods. (A minor exception to the 1-to-1 rule is the `OmniExtendedClient` which uses client-side transaction generation and the `sendrawtx_MP` method to create and send Omni transactions that are not supported in the current, stable version of Omni Core.)