Merge OmniLayer#1288: Change version to 0.12.0.1

Pull request description: This pull request updates the version to 0.12.0.1, so we can better see a difference to the already created, but outdated, binaries. # Conflicts: # configure.ac # src/counoscore/test/version_tests.cpp
CounosH · Sep 27, 2023 · 70681ad · 70681ad
1 parent f36e9e3
commit 70681ad
Show file tree

Hide file tree

Showing 5 changed files with 102 additions and 7 deletions.
diff --git a/configure.ac b/configure.ac
@@ -11,7 +11,7 @@ define(_COPYRIGHT_HOLDERS_SUBSTITUTION,[[CounosH Core]])
 define(_COUNOSCORE_VERSION_MAJOR, 0)
 define(_COUNOSCORE_VERSION_MINOR, 12)
 define(_COUNOSCORE_VERSION_PATCH, 0)
-define(_COUNOSCORE_VERSION_BUILD, 0)
+define(_COUNOSCORE_VERSION_BUILD, 1)
 define(_COUNOSCORE_VERSION_RC, 0)
 AC_INIT([CounosH Core],m4_join([.], _CLIENT_VERSION_MAJOR, _CLIENT_VERSION_MINOR, _CLIENT_VERSION_REVISION, m4_if(_CLIENT_VERSION_BUILD, [0], [], _CLIENT_VERSION_BUILD))m4_if(_CLIENT_VERSION_RC, [0], [], [rc]_CLIENT_VERSION_RC),[https://github.com/counosh/counosh/issues],[counosh],[https://counoshcore.org/])
 AC_CONFIG_SRCDIR([src/validation.cpp])

diff --git a/src/counoscore/test/version_tests.cpp b/src/counoscore/test/version_tests.cpp
@@ -23,18 +23,18 @@ BOOST_AUTO_TEST_CASE(version_comparison)
 
 BOOST_AUTO_TEST_CASE(version_string)
 {
-    BOOST_CHECK_EQUAL(CounosCoreVersion(), "0.12.0");
+    BOOST_CHECK_EQUAL(CounosCoreVersion(), "0.12.1");
 }
 
 BOOST_AUTO_TEST_CASE(version_number)
 {
-    BOOST_CHECK_EQUAL(COUNOSCORE_VERSION, 120000000);
+    BOOST_CHECK_EQUAL(COUNOSCORE_VERSION, 120000001);
 }
 
 BOOST_AUTO_TEST_CASE(config_package_version)
 {
     // the package version is used in the file names:
-    BOOST_CHECK_EQUAL(PACKAGE_VERSION, "0.12.0");
+    BOOST_CHECK_EQUAL(PACKAGE_VERSION, "0.12.0.1");
 }
 
 

diff --git a/src/omnicore/doc/release-notes.md b/src/omnicore/doc/release-notes.md
@@ -70,7 +70,7 @@ Please note, this transaction type is not available on mainnet until after its a
 
 **What's new?**
 
-A new transaction type 7 is introduced to transfer multiple tokens of one property id to multiple receivers. [Check out this link for a more detailed view.](https://gist.github.com/dexX7/1138fd1ea084a9db56798e9bce50d0ef)
+A new transaction type 7 is introduced to transfer multiple tokens of one property id to multiple receivers. [Check out this link for a more detailed view.](https://github.com/OmniLayer/omnicore/blob/develop/src/omnicore/doc/send-to-many.md)
 
 Two new RPCs were added to facilitate the new feature:
 
@@ -274,9 +274,11 @@ The following list includes relevant pull requests merged into this release:
 - [#1271 Update release notes for 0.12](https://github.com/OmniLayer/omnicore/pull/1271)
 - [#1285 Add option to skip storing state of earlier blocks during sync](https://github.com/OmniLayer/omnicore/pull/1285)
 - [#1271 Extend release notes for 0.12](https://github.com/OmniLayer/omnicore/pull/1286)
+- [#1287 NFT db records optimizations](https://github.com/OmniLayer/omnicore/pull/1287)
+- [#1288 Change version to 0.12.0.1](https://github.com/OmniLayer/omnicore/pull/1288)
 
 
 Credits
 =======
 
-Thanks to everyone who contributed to this release, especially to Peter Bushnell, Sean Gilligan and Marv Schneider.
+Thanks to everyone who contributed to this release, especially to Sean Gilligan, Marv Schneider and Antoniy Shumanov.
diff --git a/src/omnicore/doc/send-to-many.md.md b/src/omnicore/doc/send-to-many.md.md
@@ -0,0 +1,93 @@
+# Send-to-Many transactions
+
+A new transaction structure allows to include multiple transfers in one transaction.
+
+The payload of this new transaction type includes one token identifier, which defines the tokens to send. It also includes a list of receiver -> amount mappings to specify, which receiver receives how many tokens. Receivers are specified by actual Bitcoin transaction outputs, which are referenced in the payload. One or more receivers can be defined.
+
+The new transaction type has `7` as identifier.
+
+The payload structure may look like this:
+
+```
+[transaction version] [transaction type] [token identifier to send] [number of outputs following] [receiver output #] [amount to send] ( [output # of receiver] [amount to send] ... )
+```
+
+## Example: only one receiver
+
+In the following example, only one receiver is defined, basically mirroring the behavior or regular simple sends.
+
+1.0 Omni are sent to the address specified in output 1.
+
+A single transfer command has the following structure:
+
+| **Field**                | **Type**            | **Value**           |
+| ------------------------ | ------------------- | ------------------- |
+| Transaction version      | Transaction version | 0                   |
+| Transaction type         | Transaction type    | 7 (= Send-to-Many)  |
+| Token identifier to send | Token identifier    | 1 (= Omni)          |
+| Number of outputs        | Integer-one byte    | 1                   |
+| Receiver output #        | Integer-one byte    | 1 (= vout 1)        |
+| Amount to send           | Number of tokens    | 1 0000 0000 (= 1.0) |
+
+Actual payload:
+
+```
+0000 0007 00000001 01 01 0000000005f5e100
+```
+
+## Example: three receivers
+
+Let's imagine a transaction with one input and six outputs. One output for the payload and three outputs for token receivers. Bitcoin values are omitted in this example, but we simply assume the amount of incoming coins is enough to cover the whole transaction. There is another output, which is not relevant for us, and one for change.
+
+![visualized](https://i.imgur.com/ok6dD91.png)
+
+The first input has tokens associated with it:
+
+| **Input Index** | **Token identifier**         | **Token amount**          |
+| ----------------| ---------------------------- | ------------------------- |
+| 0               | 31 (USDT)                    |  100 0000 0000 (=  100.0) |
+
+The outputs of the transaction are as follows:
+
+| **Output Index** | **Script type**                   |
+| -----------------| --------------------------------- |
+| 0                | Payload with commands             |
+| 1                | Pay-to-pubkey-hash (recipient 1)  |
+| 2                | Pay-to-pubkey-hash (recipient 2)  |
+| 3                | Pay-to-pubkey-hash (not relevant) |
+| 4                | Pay-to-script-hash (recipient 3)  |
+| 5                | Pay-to-pubkey-hash (our change)   |
+
+The first output of the transaction contains the payload with the following data:
+
+| **Field**                | **Type**            | **Value**             |
+| ------------------------ | ------------------- | --------------------- |
+| Transaction version      | Transaction version | 0                     |
+| Transaction type         | Transaction type    | 7 (= Send-to-Many)    |
+| Token identifier to send | Token identifier    | 31 (= USDT )          |
+| Number of outputs        | Integer-one byte    | 3                     |
+| Receiver output #        | Integer-one byte    | 1 (= vout 1)          |
+| Amount to send           | Number of tokens    | 20 0000 0000 (= 20.0) |
+| Receiver output #        | Integer-one byte    | 2 (= vout 2)          |
+| Amount to send           | Number of tokens    | 15 0000 0000 (= 15.0) |
+| Receiver output #        | Integer-one byte    | 4 (= vout 4)          |
+| Amount to send           | Number of tokens    | 30 0000 0000 (= 30.0) |
+
+Actual payload:
+
+```
+0000 0007 0000001f 03 01 0000000077359400 02 0000000059682f00 04 00000000b2d05e00
+```
+
+20.0 USDT are transferred to the transaction output with index 1, 15.0 USDT to the output with index 2 and 30.0 USDT are transferred to the output with index 4. Given that the sender had a balance of 100.0 USDT, there is a leftover of 35.0 USDT, which were not moved and still belong to the sender.
+
+## Notes and remarks
+
+- The transaction fails, if there are not enough tokens for all transfers.
+- The transaction fails, if any output references an invalid destination or a destination, which isn't considered as valid destination in terms of the Omni Layer protocol.
+- It does not chance anything about Omni Layer's balanced based approach.
+- The order of output mappings is not strictly in order. You may first define a send to output #3, then to output #0.
+- When constructing the transaction, be careful about the placement of change addresses. If it is inserted randomly, it may affect the mapping.
+- Other Omni Layer rules apply, in particular: only the first transaction input specified how many tokens are there to send.
+- This is not "send-from-many".
+- It is possible to construct a valid transaction with no receiver.
diff --git a/src/omnicore/version.h b/src/omnicore/version.h
@@ -21,7 +21,7 @@
 #define OMNICORE_VERSION_PATCH       0
 
 // Non-public build number/revision (usually zero)
-#define OMNICORE_VERSION_BUILD       0
+#define OMNICORE_VERSION_BUILD       1
 
 #endif // HAVE_CONFIG_H