From c6da22abda5130ecd7fc4a8ba6a3d50d7bdd6827 Mon Sep 17 00:00:00 2001 From: Erica <51093313+Horusfeathers@users.noreply.github.com> Date: Thu, 30 Jul 2020 13:33:23 -0700 Subject: [PATCH 01/61] Update 01-install.rst --- docs/introduction/01-install.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/introduction/01-install.rst b/docs/introduction/01-install.rst index 29b5af4..d89f2b5 100644 --- a/docs/introduction/01-install.rst +++ b/docs/introduction/01-install.rst @@ -1,13 +1,13 @@ .. _install-sidechain-sdk-tutorial: ######################## -Installing Sidechain SDK +Installing the Sidechain SDK ######################## We'll get started by setting up our environment. ******************* -Supported platforms +Supported Platforms ******************* Sidechains-SDK is available and tested on Linux and Windows (64bit). @@ -60,9 +60,9 @@ Installing on Linux OS: .. image:: /images/intellij.png :alt: IntelliJ - 6. In the IDE, you can now go to File and Open the root directory of the project repository, “\Sidechains-SDK”. The pom.xml file, the Maven’s Project Object Model XML file that contains all the project configuration details should be automatically imported by the IDE. Otherwise, you can just open it. - 7. Keep reading this tutorial, and start playing with the code. You will find some sidechain examples in the “examples/simpleapp” directory, that you can customize, start from there! When you are ready to run your standalone sidechain, you can install Maven (link). - 8. To produce your specific sidechain jar files, you can change directory to the repository root and run the “mvn package” command. + 6. In the IDE, you can now go to File and Open the root directory of the project repository, “\Sidechains-SDK”. The pom.xml file - the Maven Project Object Model XML file that contains all the project configuration details - should be automatically imported by the IDE. Otherwise, you can just open it. + 7. Keep reading this tutorial, and start playing with the code. You will find some sidechain examples in the “examples/simpleapp” directory that you can customize. Start from there! When you are ready to run your own sidechain, you can install Maven (link). + 8. To produce your specific sidechain jar files, you can change the directory to the repository root and run the “mvn package” command. ************************* @@ -71,14 +71,14 @@ Sidechain SDK Components: As a result of step 8, three jar files will be generated: - * **sdk/target/Sidechains-SDK-0.2.0.jar** - the main SDK jar file, that contains all the necessary classes and components; - * **tools/sctool/target/Sidechains-SDK-ScBootstrappingTools-0.2.0.jar** - executable bootstrap tool. It is used to create the configuration of the new Sidechain. You can find all available commands and examples of usage here + * **sdk/target/Sidechains-SDK-0.2.0.jar** - The main SDK jar file that contains all the necessary classes and components + * **tools/sctool/target/Sidechains-SDK-ScBootstrappingTools-0.2.0.jar** - An executable bootstrap tool. It is used to create the configuration of the new Sidechain. You can find all available commands and examples of usage here .. code:: Bash examples/simpleapp/mc_sc_workflow_example.md file; - * **examples/simpleapp/target/Sidechains-SDK-simpleapp-0.2.0.jar** - in contains a Sidechain application example. You can find more details in the examples/simpleapp/readme.md file. + * **examples/simpleapp/target/Sidechains-SDK-simpleapp-0.2.0.jar** - in contains a sidechain application example. You can find more details in the examples/simpleapp/readme.md file. From f8d833141425b5523576f77e0bb1913d9ab4d5d8 Mon Sep 17 00:00:00 2001 From: zennermac <38428285+zennermac@users.noreply.github.com> Date: Thu, 30 Jul 2020 21:33:43 +0100 Subject: [PATCH 02/61] Update 07-Sidechain-SDK-extension.rst --- docs/introduction/07-Sidechain-SDK-extension.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 02c771c..99f1a32 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -172,7 +172,8 @@ That base class provide next data by default: If the box type is a Coin-Box then this value is required and will contain data such as coin value. In the case of a Non-Coin box this value would only be used in custom logic and cannot be null. Typically we would set this value to 1. So the creation of new Custom Box Data will be created in following way: -``public class CustomBoxData extends AbstractNoncedBoxData`` +:: + public class CustomBoxData extends AbstractNoncedBoxData The new custom box data class requires the following: From 3a405e4e6638a0217fdedd0de5cbab16d3158332 Mon Sep 17 00:00:00 2001 From: zennermac <38428285+zennermac@users.noreply.github.com> Date: Thu, 30 Jul 2020 21:45:50 +0100 Subject: [PATCH 03/61] Update 07-Sidechain-SDK-extension.rst --- docs/introduction/07-Sidechain-SDK-extension.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 99f1a32..9a62914 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -179,7 +179,11 @@ The new custom box data class requires the following: 1. Custom data definition * Custom data itself - * Hash of all added custom data shall be returned in ``public byte[] customFieldsHash()`` method, otherwise custom data will not be “protected”, i.e. some malicious actor could change custom data during transaction creation. + * Hash of all added custom data shall be returned in + :: + public byte[] customFieldsHash() + + method, otherwise custom data will not be “protected”, i.e. some malicious actor could change custom data during transaction creation. 2. Serialization definition * Serialization to bytes shall be provided by Custom Box Data by overriding and implementing the method ```public byte[] bytes()```. That method will serialize the proposition, value and any added custom data. From afe8b5c59e78655cbb3dc1773b8e9736a07b1a3b Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 21:53:42 +0100 Subject: [PATCH 04/61] Custom Box Data class creation --- .../07-Sidechain-SDK-extension.rst | 21 +++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 9a62914..efd9d26 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -186,12 +186,25 @@ The new custom box data class requires the following: method, otherwise custom data will not be “protected”, i.e. some malicious actor could change custom data during transaction creation. 2. Serialization definition - * Serialization to bytes shall be provided by Custom Box Data by overriding and implementing the method ```public byte[] bytes()```. That method will serialize the proposition, value and any added custom data. - * Additionally definition of Custom Box Data id for serialization by overriding ```public byte boxDataTypeId()``` method, please check the serialization chapter for more information about using ids. - * Override ```public NoncedBoxDataSerializer serializer()``` method with proper **Custom Box Data serializer**. Parsing Custom Box Data from bytes could be defined in that class as well, please refer to the serialization section for more information about it + * Serialization to bytes shall be provided by Custom Box Data by overriding and implementing the method + :: + public byte[] bytes() + + That method will serialize the proposition, value and any added custom data. + * Additionally definition of Custom Box Data id for serialization by overriding + :: + public byte boxDataTypeId() + + method, please check the serialization chapter for more information about using ids. + * Override + :: + public NoncedBoxDataSerializer serializer() + method with proper **Custom Box Data serializer**. Parsing Custom Box Data from bytes could be defined in that class as well, please refer to the serialization section for more information about it 3. Custom Box creation - * Any Box Data class shall provide the way how to create a new Box for a given nonce. For that purpose override the method ```public CustomBox getBox(long nonce)```. + * Any Box Data class shall provide the way how to create a new Box for a given nonce. For that purpose override the method + :: + public CustomBox getBox(long nonce) Custom Box Data Serializer class creation From 4e454aed4b89f0a166456caa9292e945a3e64798 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 21:57:27 +0100 Subject: [PATCH 05/61] Custom Box Data Serializer class creation --- .../07-Sidechain-SDK-extension.rst | 25 +++++++++---------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index efd9d26..a87ffdf 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -213,30 +213,29 @@ Custom Box Data Serializer class creation The SDK provides a base class for Custom Box Data Serializer NoncedBoxDataSerializer where D is type of serialized Custom Box Data So creation of a Custom Box Data Serializer can be done in following way: - :: - public class CustomBoxDataSerializer implements NoncedBoxDataSerializer + public class CustomBoxDataSerializer implements NoncedBoxDataSerializer That new Custom Box Data Serializer require's the following: - 1. Definition of function for writing Custom Box Data into the Scorex Writer by implementation of ``public void serialize(CustomBoxData boxData, Writer writer)`` method. + 1. Definition of function for writing Custom Box Data into the Scorex Writer by implementation of following method + :: + public void serialize(CustomBoxData boxData, Writer writer) 2. Definition of function for reading Custom Box Data from Scorex Reader by implementation of function public CustomBoxData parse(Reader reader) 3. Class shall be converted to singleton, for example it can be done in following way: + :: + private static final CustomBoxDataSerializer serializer = new CustomBoxDataSerializer(); -:: - - private static final CustomBoxDataSerializer serializer = new CustomBoxDataSerializer(); - - private CustomBoxDataSerializer() { - super(); - } + private CustomBoxDataSerializer() { + super(); + } - public static CustomBoxDataSerializer getSerializer() { - return serializer; - } + public static CustomBoxDataSerializer getSerializer() { + return serializer; + } Custom Box class creation ######################### From 4f598d0bbfe06f2a5600ef873ecc4e043e4693be Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:01:25 +0100 Subject: [PATCH 06/61] Revert "Custom Box Data Serializer class creation" This reverts commit 4e454aed4b89f0a166456caa9292e945a3e64798. --- .../07-Sidechain-SDK-extension.rst | 25 ++++++++++--------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index a87ffdf..efd9d26 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -213,29 +213,30 @@ Custom Box Data Serializer class creation The SDK provides a base class for Custom Box Data Serializer NoncedBoxDataSerializer where D is type of serialized Custom Box Data So creation of a Custom Box Data Serializer can be done in following way: + :: - public class CustomBoxDataSerializer implements NoncedBoxDataSerializer + public class CustomBoxDataSerializer implements NoncedBoxDataSerializer That new Custom Box Data Serializer require's the following: - 1. Definition of function for writing Custom Box Data into the Scorex Writer by implementation of following method - :: - public void serialize(CustomBoxData boxData, Writer writer) + 1. Definition of function for writing Custom Box Data into the Scorex Writer by implementation of ``public void serialize(CustomBoxData boxData, Writer writer)`` method. 2. Definition of function for reading Custom Box Data from Scorex Reader by implementation of function public CustomBoxData parse(Reader reader) 3. Class shall be converted to singleton, for example it can be done in following way: - :: - private static final CustomBoxDataSerializer serializer = new CustomBoxDataSerializer(); - private CustomBoxDataSerializer() { - super(); - } +:: + + private static final CustomBoxDataSerializer serializer = new CustomBoxDataSerializer(); - public static CustomBoxDataSerializer getSerializer() { - return serializer; - } + private CustomBoxDataSerializer() { + super(); + } + + public static CustomBoxDataSerializer getSerializer() { + return serializer; + } Custom Box class creation ######################### From 58fe8081be8a8b43aec96a88a36de6951c916724 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:03:40 +0100 Subject: [PATCH 07/61] Custom Box Data Serializer class creation --- docs/introduction/07-Sidechain-SDK-extension.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index efd9d26..99f9b11 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -219,7 +219,9 @@ So creation of a Custom Box Data Serializer can be done in following way: That new Custom Box Data Serializer require's the following: - 1. Definition of function for writing Custom Box Data into the Scorex Writer by implementation of ``public void serialize(CustomBoxData boxData, Writer writer)`` method. + 1. Definition of function for writing Custom Box Data into the Scorex Writer by implementation of the following method. + :: + public void serialize(CustomBoxData boxData, Writer writer) 2. Definition of function for reading Custom Box Data from Scorex Reader by implementation of function public CustomBoxData parse(Reader reader) From 53790595efd30b1ead966bc685f00e8288c26943 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:08:10 +0100 Subject: [PATCH 08/61] Custom Box Data Serializer class creation too many indents --- docs/introduction/07-Sidechain-SDK-extension.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 99f9b11..a7755b5 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -213,9 +213,8 @@ Custom Box Data Serializer class creation The SDK provides a base class for Custom Box Data Serializer NoncedBoxDataSerializer where D is type of serialized Custom Box Data So creation of a Custom Box Data Serializer can be done in following way: - :: - public class CustomBoxDataSerializer implements NoncedBoxDataSerializer + public class CustomBoxDataSerializer implements NoncedBoxDataSerializer That new Custom Box Data Serializer require's the following: From c91b50db8e5ffa18fa3aa6e659eb57832bc98bc2 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:10:32 +0100 Subject: [PATCH 09/61] Custom Box Data Serializer class creation setp 3 missing code block --- docs/introduction/07-Sidechain-SDK-extension.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index a7755b5..6e4dd5b 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -222,8 +222,9 @@ That new Custom Box Data Serializer require's the following: :: public void serialize(CustomBoxData boxData, Writer writer) - 2. Definition of function for reading Custom Box Data from Scorex Reader -by implementation of function public CustomBoxData parse(Reader reader) + 2. Definition of function for reading Custom Box Data from Scorex Readervby implementation of the function + :: + public CustomBoxData parse(Reader reader) 3. Class shall be converted to singleton, for example it can be done in following way: @@ -232,11 +233,11 @@ by implementation of function public CustomBoxData parse(Reader reader) private static final CustomBoxDataSerializer serializer = new CustomBoxDataSerializer(); private CustomBoxDataSerializer() { - super(); + super(); } public static CustomBoxDataSerializer getSerializer() { - return serializer; + return serializer; } Custom Box class creation From 2b88cb1693231e32cbccdef7c639fc40b1370d2b Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:13:00 +0100 Subject: [PATCH 10/61] Custom Box Data Serializer class creation setp 3 fixing indents --- .../07-Sidechain-SDK-extension.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 6e4dd5b..24e9361 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -228,17 +228,17 @@ That new Custom Box Data Serializer require's the following: 3. Class shall be converted to singleton, for example it can be done in following way: -:: - - private static final CustomBoxDataSerializer serializer = new CustomBoxDataSerializer(); + :: + + private static final CustomBoxDataSerializer serializer = new CustomBoxDataSerializer(); - private CustomBoxDataSerializer() { - super(); - } + private CustomBoxDataSerializer() { + super(); + } - public static CustomBoxDataSerializer getSerializer() { - return serializer; - } + public static CustomBoxDataSerializer getSerializer() { + return serializer; + } Custom Box class creation ######################### From 226ab2cabec827853b81cd72c86c04b64b9fcac6 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:23:48 +0100 Subject: [PATCH 11/61] Custom Box class creation --- .../07-Sidechain-SDK-extension.rst | 34 ++++++++++++++----- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 24e9361..4c20f39 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -243,23 +243,39 @@ That new Custom Box Data Serializer require's the following: Custom Box class creation ######################### -The SDK provides base class for creation of a Custom Box: +The SDK provides a base class for creation of a Custom Box: +:: + public class CustomBox extends AbstractNoncedBox + +As parameters for **AbstractNoncedBox** three template parameters shall be provided: +- Proposition type for the box, for common purposes. PublicKey25519Proposition could be used as it used in regular boxes + :: + P extends Proposition -:code:`public class CustomBox extends AbstractNoncedBox` +- Definition of type for Box Data which contains all custom data for a new custom box + :: + BD extends AbstractNoncedBoxData -As a parameters for **AbstractNoncedBox** three template parameters shall be provided: -``P extends Proposition``- Proposition type for the box, for common purposes -PublicKey25519Proposition could be used as it used in regular boxes -``BD extends AbstractNoncedBoxData`` -- Definition of type for Box Data which contains all custom data for new custom box -``B extends AbstractNoncedBox`` -- Definition of type for Box itself, required for description inside of new Custom Box data. +- Definition of type for Box itself, required for description inside of new Custom Box data. + :: + B extends AbstractNoncedBox The Custom Box itself require's implementation of following functionality: 1. Serialization definition * Box itself shall provide the way to be serialized into bytes, thus method ``public byte[] bytes()`` shall be implemented - * Method ``public static CarBox parseBytes(byte[] bytes)`` for creation of a new Car Box object from bytes, - * Providing box type id by implementation of method ``public byte boxTypeId()`` which return custom box type id. And, finally, proper serializer for the Custom Box shall be returned by implementation of method ``public BoxSerializer serializer()`` + * Method for creation of a new Car Box object from bytes + :: + public static CarBox parseBytes(byte[] bytes) + + * Providing box type id by implementation of the following method which return's a custom box type id + :: + public byte boxTypeId() + + And, finally, aserializer for the Custom Box shall be returned by implementation of the following method + :: + public BoxSerializer serializer() Custom Box Serializer Class ########################### From fe4c4ee185cbdc55b641cd12c2655b898a94fbc3 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:29:52 +0100 Subject: [PATCH 12/61] test for java syntax --- docs/introduction/07-Sidechain-SDK-extension.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 4c20f39..da678bb 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -223,7 +223,7 @@ That new Custom Box Data Serializer require's the following: public void serialize(CustomBoxData boxData, Writer writer) 2. Definition of function for reading Custom Box Data from Scorex Readervby implementation of the function - :: + .. code::java public CustomBoxData parse(Reader reader) 3. Class shall be converted to singleton, for example it can be done in following way: From 955d5e7828c9534cf7a73134f8ce5467cc7fdcad Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:31:45 +0100 Subject: [PATCH 13/61] test for java syntax --- docs/introduction/07-Sidechain-SDK-extension.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index da678bb..f3c02e1 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -224,7 +224,7 @@ That new Custom Box Data Serializer require's the following: 2. Definition of function for reading Custom Box Data from Scorex Readervby implementation of the function .. code::java - public CustomBoxData parse(Reader reader) + public CustomBoxData parse(Reader reader) 3. Class shall be converted to singleton, for example it can be done in following way: From 3118ac04a7a05e8d52213020a051c0ce16b8fcf9 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 22:55:49 +0100 Subject: [PATCH 14/61] Custom Box Serializer Class --- .../07-Sidechain-SDK-extension.rst | 26 +++++++++++++------ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index f3c02e1..8316c59 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -260,7 +260,7 @@ As parameters for **AbstractNoncedBox** three template parameters shall be provi :: B extends AbstractNoncedBox -The Custom Box itself require's implementation of following functionality: +The Custom Box itself requires implementation of following functionality: 1. Serialization definition @@ -273,22 +273,32 @@ The Custom Box itself require's implementation of following functionality: :: public byte boxTypeId() - And, finally, aserializer for the Custom Box shall be returned by implementation of the following method + And, finally, a serializer for the Custom Box shall be returned by implementation of the following method :: public BoxSerializer serializer() Custom Box Serializer Class ########################### -The SDK provides base class for ``Custom Box Serializer -BoxSerializer`` where B is type of serialized Custom Box -So creation of **Custom Box Serializer** can be done in next way: - ``public class CustomBoxSerializer implements NoncedBoxSerializer`` +The SDK provides base class for a custom box serializer below, where B is type of serialized Custom Box +:: + Custom Box Serializer BoxSerializer + +So creation of **Custom Box Serializer** can be done in the following way: +:: + public class CustomBoxSerializer implements NoncedBoxSerializer + The new Custom Box Serializer requires the following: - 1. Definition of method for writing *Custom Box* into the Scorex Writer by implementation of ```public void serialize(CustomBox box, Writer writer)``` method. + 1. Definition of method for writing *Custom Box* into the Scorex Writer by implementation of the following. + :: + public void serialize(CustomBox box, Writer writer) + 2. Definition of method for reading *Custom Box* from Scorex Reader -by implementation of method ```public CustomBox parse(Reader reader) ``` + by implementation of the following + :: + public CustomBox parse(Reader reader) + 3. Class shall be converted to singleton, for example it could be done in following way: :: From 78296b0fe004f3dcdff2ccbc519b6f89700f317f Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 23:01:06 +0100 Subject: [PATCH 15/61] Custom Box Serializer Class creation --- docs/introduction/07-Sidechain-SDK-extension.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 8316c59..8848794 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -224,6 +224,7 @@ That new Custom Box Data Serializer require's the following: 2. Definition of function for reading Custom Box Data from Scorex Readervby implementation of the function .. code::java + public CustomBoxData parse(Reader reader) 3. Class shall be converted to singleton, for example it can be done in following way: @@ -283,7 +284,7 @@ Custom Box Serializer Class The SDK provides base class for a custom box serializer below, where B is type of serialized Custom Box :: Custom Box Serializer BoxSerializer - + So creation of **Custom Box Serializer** can be done in the following way: :: public class CustomBoxSerializer implements NoncedBoxSerializer From 7f9d6f6b5ddc84983126f580a0d941b1eb8e9e36 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 23:02:46 +0100 Subject: [PATCH 16/61] Custom Box Serializer Class creation 2 --- docs/introduction/07-Sidechain-SDK-extension.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 8848794..4335ca9 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -223,8 +223,8 @@ That new Custom Box Data Serializer require's the following: public void serialize(CustomBoxData boxData, Writer writer) 2. Definition of function for reading Custom Box Data from Scorex Readervby implementation of the function - .. code::java - + .. code:: java + public CustomBoxData parse(Reader reader) 3. Class shall be converted to singleton, for example it can be done in following way: From bf64003756294dbf540450fcf217c8eace55db34 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 23:07:19 +0100 Subject: [PATCH 17/61] Transaction extension --- docs/introduction/07-Sidechain-SDK-extension.rst | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 4335ca9..f08863d 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -222,10 +222,9 @@ That new Custom Box Data Serializer require's the following: :: public void serialize(CustomBoxData boxData, Writer writer) - 2. Definition of function for reading Custom Box Data from Scorex Readervby implementation of the function - .. code:: java - - public CustomBoxData parse(Reader reader) + 2. Definition of function for reading Custom Box Data from Scorex Reader by implementation of the function + :: + public CustomBoxData parse(Reader reader) 3. Class shall be converted to singleton, for example it can be done in following way: @@ -323,7 +322,12 @@ A Coin box is created and extended as a usual non-coin box, only one additional Transaction extension ##################### -Transaction in the SDK is represented by ```public abstract class BoxTransaction

> extends Transaction``` class. That class provides access to data like which boxes will be created, unlockers for input boxes, fee, etc. SDK developer could add custom transaction check by implementing *custom ApplicationState* +Transaction in the SDK is represented by the following class. +:: + public abstract class BoxTransaction

> + +This class provides access to data such as which boxes will be created, unlockers for input boxes, fee, etc. +SDK developer could add custom transaction check by implementing *custom ApplicationState* ApplicationState and Wallet ########################### From 03c5530702e8a49b1b9364522d3b91d4b99a9375 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 23:14:09 +0100 Subject: [PATCH 18/61] started on application state --- .../07-Sidechain-SDK-extension.rst | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index f08863d..920b3e1 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -1,5 +1,5 @@ ======================= -Sidechain SDK extension +Sidechains SDK extension ======================= @@ -322,7 +322,7 @@ A Coin box is created and extended as a usual non-coin box, only one additional Transaction extension ##################### -Transaction in the SDK is represented by the following class. +A transaction in the SDK is represented by the following class. :: public abstract class BoxTransaction

> @@ -332,19 +332,19 @@ SDK developer could add custom transaction check by implementing *custom Applica ApplicationState and Wallet ########################### - ApplicationState: +ApplicationState: - :: - - interface ApplicationState { - boolean validate(SidechainStateReader stateReader, SidechainBlock block); +:: - boolean validate(SidechainStateReader stateReader, BoxTransaction> transaction); + interface ApplicationState { + boolean validate(SidechainStateReader stateReader, SidechainBlock block); - Try onApplyChanges(SidechainStateReader stateReader, byte[] version, List> newBoxes, List boxIdsToRemove); + boolean validate(SidechainStateReader stateReader, BoxTransaction> transaction); - Try onRollback(byte[] version); - } + Try onApplyChanges(SidechainStateReader stateReader, byte[] version, List> newBoxes, List boxIdsToRemove); + + Try onRollback(byte[] version); + } For example, the custom application may have the possibility to tokenize cars by creation of Box entries - let’s call them CarBox. Each CarBox token should represent a unique car by having a unique *VIN* (Vehicle Identification Number). To do this Sidechain developer may define ApplicationState to store the list of actual VINs and reject transactions with CarBox tokens with VIN already existing in the system. From c672c996bde0cb23e0b0a7a829eb3b8c3108e433 Mon Sep 17 00:00:00 2001 From: zennermac Date: Thu, 30 Jul 2020 23:43:31 +0100 Subject: [PATCH 19/61] fixed mainchain refs where needed --- docs/index.rst | 2 +- docs/introduction/03-Cross-chain-transfer-protocol.rst | 10 +++++----- docs/introduction/04-Latus-Consensus.rst | 4 ++-- docs/introduction/06-Base-App.rst | 7 ++++--- docs/introduction/07-Sidechain-SDK-extension.rst | 9 ++++++--- 5 files changed, 18 insertions(+), 14 deletions(-) diff --git a/docs/index.rst b/docs/index.rst index e4eed58..5420abe 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -7,7 +7,7 @@ Overview ******** Horizen Sidechain SDK allows developers developers to quickly spin-up their own blockchain, customize business -logic depending on use case, maintain interoperability with the Mainchain native token (which acts as the medium of +logic depending on use case, maintain interoperability with the mainchain native token (which acts as the medium of exchange between the whole ecosystem). Sidechain SDK offers out-of-the-box support for the common features you'd expect diff --git a/docs/introduction/03-Cross-chain-transfer-protocol.rst b/docs/introduction/03-Cross-chain-transfer-protocol.rst index bbf3198..82f5cc8 100644 --- a/docs/introduction/03-Cross-chain-transfer-protocol.rst +++ b/docs/introduction/03-Cross-chain-transfer-protocol.rst @@ -2,14 +2,14 @@ The Cross-Chain Transfer Protocol ********************************* -The Cross-Chain Transfer Protocol (“CCTP”) defines the communication between the mainchain and sidechain(s). It is a 2-way peg protocol that allows sending coins from Mainchain to a Sidechain, and vice versa. +The Cross-Chain Transfer Protocol (“CCTP”) defines the communication between the mainchain and sidechain(s). It is a 2-way peg protocol that allows sending coins from mainchain to a sidechain, and vice versa. At a high level, it defines two basic operations: * **Forward Transfer** * **Backward Transfer** -While all Sidechains know and follow the Mainchain, which is an established and stable reality, Mainchain needs to be made aware of the existence of every sidechain. So, Sidechains first must be declared in Mainchain. +While all Sidechains know and follow the mainchain, which is an established and stable reality, mainchain needs to be made aware of the existence of every sidechain. So, Sidechains first must be declared in the mainchain. We can declare a new Sidechain by using the following RPC command: @@ -32,15 +32,15 @@ As a consequence of the sidechain declaration command, a unique sidechain id wil Forward Transfer ================ -A forward transfer sends coins from the mainchain to a sidechain. The Horizen mainchain supports a “Forward Transfer” transaction type, that specifies the sidechain destination (sidechain id and receiver address) and the amounts of ZEN coins to be sent. From a mainchain perspective, the transferred coins are destroyed, they are only represented in the total balance of that particular sidechain. +A forward transfer sends coins from the mainchain to a sidechain. The Horizen Mainchain supports a “Forward Transfer” transaction type, that specifies the sidechain destination (sidechain id and receiver address) and the amounts of ZEN coins to be sent. From a mainchain perspective, the transferred coins are destroyed, they are only represented in the total balance of that particular sidechain. On the Sidechain side, the SDK provides all the functionalities that support Forward Transfers, so that a transferred amount is “converted” into a new Sidechain Box. Backward Transfer ================= A backward transfer moves coins back from a sidechain to a mainchain destination. -A Backward Transfer is initiated by a **Withdrawal Request** which is a sidechain transaction issued by the coin owners. The request specifies the mainchain destination, and the amount. More precisely, the withdrawal request owner will create a WithdrawalRequestBox that destroys the specified amount of coins in a sidechain. This is not enough to move those coins back to the mainchain though: we need to wait the end of the withdrawal epoch, when all the coins specified in that epoch’s Withdrawal Requests are listed in a single Certificate, that is the propagated to the Mainchain. -The Certificate includes a succinct cryptographic proof that the rules associated with the declared verifying key have been respected. Certificates are processed by Mainchain consensus, which recreates the coins as specified by the certificate, only checking that the proof verifies, and that the coins received by a sidechain are not more than the amount sent to it. +A Backward Transfer is initiated by a **Withdrawal Request** which is a sidechain transaction issued by the coin owners. The request specifies the mainchain destination, and the amount. More precisely, the withdrawal request owner will create a WithdrawalRequestBox that destroys the specified amount of coins in a sidechain. This is not enough to move those coins back to the mainchain though: we need to wait the end of the withdrawal epoch, when all the coins specified in that epoch’s Withdrawal Requests are listed in a single Certificate, that is the propagated to the mainchain. +The Certificate includes a succinct cryptographic proof that the rules associated with the declared verifying key have been respected. Certificates are processed by the mainchain consensus, which recreates the coins as specified by the certificate, only checking that the proof verifies, and that the coins received by a sidechain are not more than the amount sent to it. Summary ======= diff --git a/docs/introduction/04-Latus-Consensus.rst b/docs/introduction/04-Latus-Consensus.rst index 1788dcb..77a3e8a 100644 --- a/docs/introduction/04-Latus-Consensus.rst +++ b/docs/introduction/04-Latus-Consensus.rst @@ -15,9 +15,9 @@ A slot leader eligible for a certain slot, that decides to create and propagate Forgers are also entitled and incentivized to include sidechain transactions and mainchain synchronization data into Sidechain Blocks. A limited amount of mainchain block data is added to sidechain blocks, in such a way that all the mainchain transactions that refer to a particular sidechain are included in that sidechain, that a reference to each mainchain block is present in all sidechains, and that enough information is published in a sidechain such that any sidechain node is able to validate the mainchain block references without the need for a direct connection to the mainchain itself. Please note, the forger will need its own direct connection to mainchain nodes, to have a source of mainchain blocks data. -The connection between Mainchain and Sidechain nodes is established via a websocket interface provided by the mainchain node. +The connection between the mainchain and sidechain nodes is established via a websocket interface provided by the mainchain node. -The Latus consensus, including MainchainBlock synchronization and all forging logic and functionality, is implemented out-of-the-box by the SDK Core, and developers do not need to make any change to this. The forging process can be fully managed through the API interface provided by the SDK (see the next topic). +The Latus consensus, including mainchain block synchronization, forging logic and functionality, is implemented out-of-the-box by the core SDK, and developers do not need to make any changes to this. The forging process can be fully managed through the API interface provided by the SDK (see the next topic). Default Latus consensus parameters ================================== diff --git a/docs/introduction/06-Base-App.rst b/docs/introduction/06-Base-App.rst index 9460af3..6123086 100644 --- a/docs/introduction/06-Base-App.rst +++ b/docs/introduction/06-Base-App.rst @@ -60,8 +60,9 @@ Every box has its own unique boxId (do not be confused with box type id which is The following Coin-Box types are provided by SDK: * **RegularBox** -- contains ZEN coins * **ForgerBox** -- contains ZEN coins are used for forging - * **WithdrawalRequestBox** -- contain ZEN coins are used to backward transfer, i.e. move coins back to the mainchain -An SDK developer can declare his own Boxes, please refer to SDK extension section. + * **WithdrawalRequestBox** -- contain ZEN coins are used to backward transfer, i.e. move coins back to the mainchain. + +An SDK developer can declare custom Boxes, please refer to SDK extension section. Transactions ************ @@ -69,7 +70,7 @@ Transactions There are two basic transactions: `MC2SCAggregatedTransaction `_ and `SidechainCoreTransaction `_. -An MC2SCAggregatedTransaction is the implementation of Forward Transfer and can be only added as a part of the MainchainBlock reference data during synchronization with Mainchain. +An MC2SCAggregatedTransaction is the implementation of Forward Transfer and can be only added as a part of the mainchain block reference data during synchronization with mainchain. When a Forger is going to produce a sidechain block and a new mainchain block appears, the forger will recreate that mainchain block as a reference that will contain sidechain related data. So, if some Forward Transfer exists in the mainchain block, it will be included into the MC2SCAggregatedTransaction and added as a part of the reference. The SidechainCoreTransaction is the transaction, which can be created by anyone to send coins inside a sidechain, create forging stakes or perform withdrawal requests diff --git a/docs/introduction/07-Sidechain-SDK-extension.rst b/docs/introduction/07-Sidechain-SDK-extension.rst index 920b3e1..f95bc0f 100644 --- a/docs/introduction/07-Sidechain-SDK-extension.rst +++ b/docs/introduction/07-Sidechain-SDK-extension.rst @@ -1,6 +1,6 @@ -======================= +======================== Sidechains SDK extension -======================= +======================== Data serialization @@ -14,6 +14,7 @@ CustomData are the following: For CustomData :: Implement BytesSerializable interface + i.e. :: functions byte[] bytes() @@ -264,7 +265,9 @@ The Custom Box itself requires implementation of following functionality: 1. Serialization definition - * Box itself shall provide the way to be serialized into bytes, thus method ``public byte[] bytes()`` shall be implemented + * The box itself provides the way to be serialized into bytes, thus method + :: + public byte[] bytes()`` shall be implemented * Method for creation of a new Car Box object from bytes :: public static CarBox parseBytes(byte[] bytes) From 71a94a41f6ecc15bdc2cf8b864656aca47208ada Mon Sep 17 00:00:00 2001 From: Erica <51093313+Horusfeathers@users.noreply.github.com> Date: Thu, 6 Aug 2020 08:34:40 -0700 Subject: [PATCH 20/61] Update conf.py --- docs/conf.py | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/conf.py b/docs/conf.py index 44ca0a0..cafbe7a 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -20,12 +20,12 @@ # documentation root, use os.path.abspath to make it absolute, like shown here. #sys.path.insert(0, os.path.abspath('.')) -# -- General configuration ------------------------------------------------ +# -- General Configuration ------------------------------------------------ # If your documentation needs a minimal Sphinx version, state it here. #needs_sphinx = '1.0' -# Add any Sphinx extension module names here, as strings. They can be +# Add any Sphinx extension module names here as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = [ @@ -45,7 +45,7 @@ # The encoding of source files. #source_encoding = 'utf-8-sig' -# The master toctree document. +# The master doctree document. master_doc = 'index' # General information about the project. @@ -75,7 +75,7 @@ # directories to ignore when looking for source files. exclude_patterns = ['_build'] -# The reST default role (used for this markup: `text`) to use for all +# The RST default role (used for this markup: `text`) to use for all # documents. #default_role = None @@ -106,8 +106,8 @@ # a list of builtin themes. html_theme = 'default' -# Theme options are theme-specific and customize the look and feel of a theme -# further. For a list of options available for each theme, see the +# Theme options are theme-specific and customize the look and feel of a theme. +# For a list of options available for each theme, see the # documentation. #html_theme_options = {} @@ -127,7 +127,7 @@ html_logo = 'images/Horizen_UBD_white.svg' # The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 +# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 # pixels large. html_favicon = 'images/Horizen_favicon_32x32.png' @@ -197,7 +197,7 @@ htmlhelp_basename = 'Horizen Sidechains SDK' -# -- Options for LaTeX output --------------------------------------------- +# -- Options for LaTeX Output --------------------------------------------- latex_elements = { # The paper size ('letterpaper' or 'a4paper'). @@ -239,7 +239,7 @@ #latex_domain_indices = True -# -- Options for manual page output --------------------------------------- +# -- Options for Manual Page Output --------------------------------------- # One entry per manual page. List of tuples # (source start file, name, description, authors, manual section). @@ -252,7 +252,7 @@ #man_show_urls = False -# -- Options for Texinfo output ------------------------------------------- +# -- Options for Texinfo Output ------------------------------------------- # Grouping the document tree into Texinfo files. List of tuples # (source start file, target name, title, author, From 346e0c69d26edb34d68cde393d1c8d677974e629 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Thu, 6 Aug 2020 19:27:33 +0100 Subject: [PATCH 21/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 8578056..3101fa9 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -14,6 +14,43 @@ identification number, model, production year, color (etc)... A car owner should be able to prove their ownership of the cars without disclosing information about their identity. We also want users to sell and buy cars, with ZEN coins. +User stories: +************* + +1 +**Q: I want to add my car to a Car Registry Sidechain.** + +A: Create a new Car Entry Box, that contains car identification information (Unique can identifier, VIN, manufactures, model, year, registration number) and certificate. Proposition in this box is my public key in this Sidechain. When I create box Sidechain should check car identification information and certificate to be unique in this Sidechain. + +2 +**Q: I want to create sell order to sell my car using Car Registry Sidechain.** + +A: I create a new Car Sell Order Box, that contains the price in coins and information from the Car Entry Box. So cars can exist in the Sidechain as a Car Entry Box or as a Car Sell Order, but not both at same time. Also this box contain the buyer’s public key. When I create a sell order Sidechain should check if there is no other active sell order with this Car Entry Box. Current Sell Order consists of the same information that consists in the Car Entry Box plus description. + +3 +**Q: I want to see all available Sell orders in Sidechain** + +A: Have additional storage, which is managed by ApplicationState and stores all Car Sell Orders. All these orders can be retrieved using new HTTP API call. + + +4 +**Q: I want to accept a sell order and buy the car.** + +A: By accepting sell order I create new transaction in the Sidechain, that creates new Car Entry Box with my public key as proposition and transfers coins amount from me to previous car owner. + +5 +**Q: I want to cancel my Car Sell Order.** + +A: I create new transaction, that contains Car Sell Order as input and Car Entry Box with my public key as proposition as output. + +6. +**Q: I want to see my car entry boxes and car sell orders related to me (both created by me and proposed to me).** + +A: Implement new storage that will be managed by the application state to store this information. Implement a new HTTP API, that contains a new method to get this information. + +So, the starting point of the development process is the data representation. A car is an example of a non-coin box because it represents some entity, but not money. Another example of a non-coin box is a car which is selling. We need another box for a selling car because a common car box doesn't have additional data like sale price, seller proposition address etc. For the money representation standard Regular Box is used (Regular box is coin box), that box is provided by SDK. Besides new entities CarBox and CarSellOrder we also need to define a way for creating/destroying those new entities. For that purpose new transactions shall be defined: transaction for creating new car, transaction which move CarBox to CarSellOrder, transaction which declare car selling, i.e. moving CarSellOrder to the new CarBox. All created transactions are not put into the memory pool automatically, so a raw transaction in hex representation shall be put by /transaction/sendTransaction API request. In summary we will add next car boxes and transactions: + + So, the starting point of the development process is the data representation. A car is an example of a non-coin box because it represents an entity, but not money. Another example of a non-coin box is a car which is being sold. We need another box for a selling a car because a common car box doesn't have additional data like sale price, seller proposition address etc. For the money representation a standard Regular Box is used (Regular box is coin box), that box is provided by SDK. Besides new entities CarBox From 42ea5ee9adfd24b30ce73f2bfceb54e5da711a93 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Thu, 6 Aug 2020 19:30:57 +0100 Subject: [PATCH 22/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 67 +++++++------------ 1 file changed, 26 insertions(+), 41 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 3101fa9..6bea88b 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -60,47 +60,32 @@ memory pool automatically, so a raw transaction in hex representation by added b transactions: Entities: - -+------------------+-----------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ -| Entity name | Entity description | Entity fields | -+==================+=========================================================================================+=============================================================================================+ -| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | -+------------------+-----------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ -| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car | -| | | year -- vehicle year production | -| | | model -- car model | -| | | color -- car color | -| | | description -- car description | -+------------------+-----------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ -| CarSellOrder | Box which contains car sell order data, which could be stored and operated in Sidechain | boxData -- contains car sell order data | -+------------------+-----------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ -| CarSellOrderData | Description of the car which are in sell status | sellerProposition -- seller proposition, i.e. receiver of money for sold car. | -| | | vin -- selling car vin | -+------------------+-----------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ - -Transactions which allow to perform next boxes transitions - -+------------------------------+--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| Transaction name | Input parameters | Input parameters purpose | Output boxes | Output boxes purpose | -+==============================+==============================================================+===========================================================================================================================================+====================+=====================================================================================================================+ -| Car creation transaction | Regular Box | For paying fee | Car Box | Wanted new Car Box | -| +--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| | Fee value | How much fee will be paid for the transaction | Regular Box | Change for fee | -| +--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| | Car proposition | Owner car proposition as PublicKey25519Proposition | | | -| +--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| | Vehicle identification number and any other car related data | Identification of the new car | | | -+------------------------------+--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| Car sell Order transaction | Car Box | Box which identifies a car for selling, initial car box will be opened and no longer is valid, thus in any case new Car Box shall be created | Car sell order Box | Representation of car in sell state, also contains additional information like seller coin box proposition address | -| +--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| | Seller proposition for coin box | Where money will be sent to | | | -+------------------------------+--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| Car buying order transaction | Car sell order Box | Identify car for selling, contains seller coin box proposition address | Car box | New owner car box, with buyer proposition address | -| +--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| | Payment regular box id | Id of box with money | Regular Box | New coin box which could be opened by seller which contains coins for selling car | -| +--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ -| | buyerProposition | Buyer proposition where money shall be sent | | | -+------------------------------+--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------+ ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Entity name | Entity description | Entity fields | ++=====================+=======================================================================================================================================================================================================================+=====================================================================================================================================================================================================================+ +| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car | +| | | year -- vehicle year production | +| | | model -- car model | +| | | color -- car color | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderBox | Box which contains car sell order data, which could be stored and operated in Sidechain. | boxData -- contains car sell order data | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderBoxData | Description of the car which is in sell status. That box data contains a special type of proposition SellOrderProposition. That proposition allows us to spent the box in two different ways: by seller and by buyer | vin -- vehicle identification number which contains unique identification number of the car | +| | | year -- vehicle year production | +| | | model -- car model | +| | | color -- car color | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderInfo | Information about car’s selling as well as proof of a current car owner. Used in transaction processing. | carBoxToOpen -- car box for start selling | +| | | proof -- proof for open initial car box | +| | | price -- selling price | +| | | buyerProposition -- current implementation expect to have the specific buyer which had been found off chain. Thus during creation of car sell order we already know buyer and shall put his future car proposition | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarBuyOrderInfo | Data required for buying a car or recall a car sell order. Used in transaction processing. | carSellOrderBoxToOpen -- Car sell order box to be open | +| | | proof -- specific proof of type SellOrderSpendingProof | +| | | for confirming buying of the car or recall car sell order | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Car registry implementation *************************** From 43bbe7e53003917c30960132153c686c81634c5d Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Thu, 6 Aug 2020 19:32:26 +0100 Subject: [PATCH 23/61] Update 08-Car-registry-tutorial.rst From 7329da247b3eaba4156c5b07ee8db1aa8b98c20f Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Thu, 6 Aug 2020 19:33:04 +0100 Subject: [PATCH 24/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 35 +++++-------------- 1 file changed, 9 insertions(+), 26 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 6bea88b..bf8ae10 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -60,32 +60,15 @@ memory pool automatically, so a raw transaction in hex representation by added b transactions: Entities: -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Entity name | Entity description | Entity fields | -+=====================+=======================================================================================================================================================================================================================+=====================================================================================================================================================================================================================+ -| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car | -| | | year -- vehicle year production | -| | | model -- car model | -| | | color -- car color | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarSellOrderBox | Box which contains car sell order data, which could be stored and operated in Sidechain. | boxData -- contains car sell order data | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarSellOrderBoxData | Description of the car which is in sell status. That box data contains a special type of proposition SellOrderProposition. That proposition allows us to spent the box in two different ways: by seller and by buyer | vin -- vehicle identification number which contains unique identification number of the car | -| | | year -- vehicle year production | -| | | model -- car model | -| | | color -- car color | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarSellOrderInfo | Information about car’s selling as well as proof of a current car owner. Used in transaction processing. | carBoxToOpen -- car box for start selling | -| | | proof -- proof for open initial car box | -| | | price -- selling price | -| | | buyerProposition -- current implementation expect to have the specific buyer which had been found off chain. Thus during creation of car sell order we already know buyer and shall put his future car proposition | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarBuyOrderInfo | Data required for buying a car or recall a car sell order. Used in transaction processing. | carSellOrderBoxToOpen -- Car sell order box to be open | -| | | proof -- specific proof of type SellOrderSpendingProof | -| | | for confirming buying of the car or recall car sell order | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Entity name | Entity description | Entity fields | +|--------------------- |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | +| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car year -- vehicle year production model -- car model color -- car color | +| CarSellOrderBox | Box which contains car sell order data, which could be stored and operated in Sidechain. | boxData -- contains car sell order data | +| CarSellOrderBoxData | Description of the car which is in sell status. That box data contains a special type of proposition SellOrderProposition. That proposition allows us to spent the box in two different ways: by seller and by buyer | vin -- vehicle identification number which contains unique identification number of the car year -- vehicle year production model -- car model color -- car color | +| CarSellOrderInfo | Information about car’s selling as well as proof of a current car owner. Used in transaction processing. | carBoxToOpen -- car box for start selling proof -- proof for open initial car box price -- selling price buyerProposition -- current implementation expect to have the specific buyer which had been found off chain. Thus during creation of car sell order we already know buyer and shall put his future car proposition | +| CarBuyOrderInfo | Data required for buying a car or recall a car sell order. Used in transaction processing. | carSellOrderBoxToOpen -- Car sell order box to be open proof -- specific proof of type SellOrderSpendingProof for confirming buying of the car or recall car sell order | + Car registry implementation *************************** From 722b87ecb267e843a960d44374c97c0d4ce273e9 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Thu, 6 Aug 2020 19:33:53 +0100 Subject: [PATCH 25/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 34 ++++++++++++++----- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index bf8ae10..3d12378 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -60,14 +60,32 @@ memory pool automatically, so a raw transaction in hex representation by added b transactions: Entities: -| Entity name | Entity description | Entity fields | -|--------------------- |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | -| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car year -- vehicle year production model -- car model color -- car color | -| CarSellOrderBox | Box which contains car sell order data, which could be stored and operated in Sidechain. | boxData -- contains car sell order data | -| CarSellOrderBoxData | Description of the car which is in sell status. That box data contains a special type of proposition SellOrderProposition. That proposition allows us to spent the box in two different ways: by seller and by buyer | vin -- vehicle identification number which contains unique identification number of the car year -- vehicle year production model -- car model color -- car color | -| CarSellOrderInfo | Information about car’s selling as well as proof of a current car owner. Used in transaction processing. | carBoxToOpen -- car box for start selling proof -- proof for open initial car box price -- selling price buyerProposition -- current implementation expect to have the specific buyer which had been found off chain. Thus during creation of car sell order we already know buyer and shall put his future car proposition | -| CarBuyOrderInfo | Data required for buying a car or recall a car sell order. Used in transaction processing. | carSellOrderBoxToOpen -- Car sell order box to be open proof -- specific proof of type SellOrderSpendingProof for confirming buying of the car or recall car sell order | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Entity name | Entity description | Entity fields | ++=====================+=======================================================================================================================================================================================================================+=====================================================================================================================================================================================================================+ +| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car | +| | | year -- vehicle year production | +| | | model -- car model | +| | | color -- car color | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderBox | Box which contains car sell order data, which could be stored and operated in Sidechain. | boxData -- contains car sell order data | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderBoxData | Description of the car which is in sell status. That box data contains a special type of proposition SellOrderProposition. That proposition allows us to spent the box in two different ways: by seller and by buyer | vin -- vehicle identification number which contains unique identification number of the car | +| | | year -- vehicle year production | +| | | model -- car model | +| | | color -- car color | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderInfo | Information about car’s selling as well as proof of a current car owner. Used in transaction processing. | carBoxToOpen -- car box for start selling | +| | | proof -- proof for open initial car box | +| | | price -- selling price | +| | | buyerProposition -- current implementation expect to have the specific buyer which had been found off chain. Thus during creation of car sell order we already know buyer and shall put his future car proposition | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarBuyOrderInfo | Data required for buying a car or recall a car sell order. Used in transaction processing. | carSellOrderBoxToOpen -- Car sell order box to be open | +| | | proof -- specific proof of type SellOrderSpendingProof | +| | | for confirming buying of the car or recall car sell order | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | carSellOrderBoxToOpen -- Car sell order box to be open proof -- specific proof of type SellOrderSpendingProof for confirming buying of the car or recall car sell order | Car registry implementation From 355411cef5f1a6777a28e699a79bde4a88f2a702 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 03:02:43 +0100 Subject: [PATCH 26/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 28 +------------------ 1 file changed, 1 insertion(+), 27 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 3d12378..0a86eb9 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -59,33 +59,7 @@ transaction which move CarBox to CarSellOrder, transaction which declares a car memory pool automatically, so a raw transaction in hex representation by added by creating a /transaction/sendTransaction API request. In summary we will add next car boxes and transactions: -Entities: -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Entity name | Entity description | Entity fields | -+=====================+=======================================================================================================================================================================================================================+=====================================================================================================================================================================================================================+ -| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car | -| | | year -- vehicle year production | -| | | model -- car model | -| | | color -- car color | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarSellOrderBox | Box which contains car sell order data, which could be stored and operated in Sidechain. | boxData -- contains car sell order data | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarSellOrderBoxData | Description of the car which is in sell status. That box data contains a special type of proposition SellOrderProposition. That proposition allows us to spent the box in two different ways: by seller and by buyer | vin -- vehicle identification number which contains unique identification number of the car | -| | | year -- vehicle year production | -| | | model -- car model | -| | | color -- car color | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarSellOrderInfo | Information about car’s selling as well as proof of a current car owner. Used in transaction processing. | carBoxToOpen -- car box for start selling | -| | | proof -- proof for open initial car box | -| | | price -- selling price | -| | | buyerProposition -- current implementation expect to have the specific buyer which had been found off chain. Thus during creation of car sell order we already know buyer and shall put his future car proposition | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| CarBuyOrderInfo | Data required for buying a car or recall a car sell order. Used in transaction processing. | carSellOrderBoxToOpen -- Car sell order box to be open | -| | | proof -- specific proof of type SellOrderSpendingProof | -| | | for confirming buying of the car or recall car sell order | -+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | carSellOrderBoxToOpen -- Car sell order box to be open proof -- specific proof of type SellOrderSpendingProof for confirming buying of the car or recall car sell order | +TBD ADD TABLE Car registry implementation From 69e2e7aaca17cc25096c4d82945a9b17e6876a41 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:37:01 +0100 Subject: [PATCH 27/61] Update index.rst --- docs/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/index.rst b/docs/index.rst index 5420abe..5cbe6f9 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -6,7 +6,7 @@ Horizen Sidechains SDK Documentation Overview ******** -Horizen Sidechain SDK allows developers developers to quickly spin-up their own blockchain, customize business +Horizen Sidechain SDK allows developers to quickly spin-up their own blockchain, customize business logic depending on use case, maintain interoperability with the mainchain native token (which acts as the medium of exchange between the whole ecosystem). From 01d7fa06ff46be8ee1a4eaaee3820fdf1ee6c2ec Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:46:14 +0100 Subject: [PATCH 28/61] Update 01-install.rst --- docs/introduction/01-install.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/introduction/01-install.rst b/docs/introduction/01-install.rst index d89f2b5..5d0d849 100644 --- a/docs/introduction/01-install.rst +++ b/docs/introduction/01-install.rst @@ -76,7 +76,7 @@ As a result of step 8, three jar files will be generated: .. code:: Bash - examples/simpleapp/mc_sc_workflow_example.md file; + examples/simpleapp/mc_sc_workflow_example.md; * **examples/simpleapp/target/Sidechains-SDK-simpleapp-0.2.0.jar** - in contains a sidechain application example. You can find more details in the examples/simpleapp/readme.md file. From 7bac49bb93bdc6d10081f628146dac8382016191 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:47:57 +0100 Subject: [PATCH 29/61] Update 02-blockchain-representation.rst --- docs/introduction/02-blockchain-representation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/introduction/02-blockchain-representation.rst b/docs/introduction/02-blockchain-representation.rst index 365285d..dde08ef 100644 --- a/docs/introduction/02-blockchain-representation.rst +++ b/docs/introduction/02-blockchain-representation.rst @@ -11,7 +11,7 @@ Concept of a BOX **************** A box generalizes the concept of Bitcoin’s UTXOs. -A box is a cryptographic object that can be was created with some secret keys. This box can be opened(spent) by the owner of those secret keys. Once opened by the owner of the secret keys the box may not be opened again. +A box is a cryptographic object that can be created with some secret keys. This box can be open \ (spent) by the owner of those secret keys. Once opened by the owner of the secret keys the box may not be opened again. Node Main elements & intro to a "NodeView" ****************************************** From 5b503a53ad2ef34afdc450fe36a3778fade8d2c3 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:52:58 +0100 Subject: [PATCH 30/61] Update 01-install.rst --- docs/introduction/01-install.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/introduction/01-install.rst b/docs/introduction/01-install.rst index 5d0d849..3604567 100644 --- a/docs/introduction/01-install.rst +++ b/docs/introduction/01-install.rst @@ -24,14 +24,14 @@ Horizen Sidechain SDK requires Java 8 or newer (Java 11 recommended), Scala 2.1 Installing on Windows OS: ************************* - 1. Install Java JDK version 11 (link) - 2. Install Scala 2.12.10+ (link) - 3. Install Git (link) + 1. Install Java JDK version 11 (`link `_) + 2. Install Scala 2.12.10+ (`link `) + 3. Install Git (`link `) 4. Clone the Sidechains-SDK git repository .. code:: Bash - git clone git@github.com:ZencashOfficial/Sidechains-SDK.git + git clone git@github.com:HorizenOfficial/Sidechains-SDK.git 5. As IDE, please install and use IntelliJ IDEA Community Edition (link) In the IDE, please also install the Intellij Scala plugin: in the Settings->Plugins tab, select it from the marketplace: @@ -46,9 +46,9 @@ Installing on Windows OS: Installing on Linux OS: *********************** - 1. Install Java JDK version 11 (link) - 2. Install Scala 2.12.10+ (link) - 3. Install Git (link) + 1. Install Java JDK version 11 (`link `_) + 2. Install Scala 2.12.10+ (`link `) + 3. Install Git (`link `) 4. Clone the Sidechains-SDK git repository .. code:: Bash From 62bb073b4c3252e6e7d17685e0543746645cae67 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:53:51 +0100 Subject: [PATCH 31/61] Update 01-install.rst --- docs/introduction/01-install.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/introduction/01-install.rst b/docs/introduction/01-install.rst index 3604567..2d5aa3a 100644 --- a/docs/introduction/01-install.rst +++ b/docs/introduction/01-install.rst @@ -25,8 +25,8 @@ Installing on Windows OS: ************************* 1. Install Java JDK version 11 (`link `_) - 2. Install Scala 2.12.10+ (`link `) - 3. Install Git (`link `) + 2. Install Scala 2.12.10+ (`_link `) + 3. Install Git (`_link `) 4. Clone the Sidechains-SDK git repository .. code:: Bash @@ -47,8 +47,8 @@ Installing on Linux OS: *********************** 1. Install Java JDK version 11 (`link `_) - 2. Install Scala 2.12.10+ (`link `) - 3. Install Git (`link `) + 2. Install Scala 2.12.10+ (`_link `) + 3. Install Git (`_link `) 4. Clone the Sidechains-SDK git repository .. code:: Bash From 31f13421c231f148f1857c111f34598a64e3dea5 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:54:51 +0100 Subject: [PATCH 32/61] Update 01-install.rst --- docs/introduction/01-install.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/introduction/01-install.rst b/docs/introduction/01-install.rst index 2d5aa3a..3604567 100644 --- a/docs/introduction/01-install.rst +++ b/docs/introduction/01-install.rst @@ -25,8 +25,8 @@ Installing on Windows OS: ************************* 1. Install Java JDK version 11 (`link `_) - 2. Install Scala 2.12.10+ (`_link `) - 3. Install Git (`_link `) + 2. Install Scala 2.12.10+ (`link `) + 3. Install Git (`link `) 4. Clone the Sidechains-SDK git repository .. code:: Bash @@ -47,8 +47,8 @@ Installing on Linux OS: *********************** 1. Install Java JDK version 11 (`link `_) - 2. Install Scala 2.12.10+ (`_link `) - 3. Install Git (`_link `) + 2. Install Scala 2.12.10+ (`link `) + 3. Install Git (`link `) 4. Clone the Sidechains-SDK git repository .. code:: Bash From 941692e7ecb24fbc5d088ce2dcf612369071c489 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:57:00 +0100 Subject: [PATCH 33/61] Update 01-install.rst --- docs/introduction/01-install.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/introduction/01-install.rst b/docs/introduction/01-install.rst index 3604567..4003813 100644 --- a/docs/introduction/01-install.rst +++ b/docs/introduction/01-install.rst @@ -25,8 +25,8 @@ Installing on Windows OS: ************************* 1. Install Java JDK version 11 (`link `_) - 2. Install Scala 2.12.10+ (`link `) - 3. Install Git (`link `) + 2. Install Scala 2.12.10+ (`link `_) + 3. Install Git (`link `_) 4. Clone the Sidechains-SDK git repository .. code:: Bash @@ -47,8 +47,8 @@ Installing on Linux OS: *********************** 1. Install Java JDK version 11 (`link `_) - 2. Install Scala 2.12.10+ (`link `) - 3. Install Git (`link `) + 2. Install Scala 2.12.10+ (`link `_) + 3. Install Git (`link `_) 4. Clone the Sidechains-SDK git repository .. code:: Bash From 6bee4d955ac3520f68a5aa4b6cab73a98f37508c Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:57:53 +0100 Subject: [PATCH 34/61] Update 05-Node-communication.rst --- docs/introduction/05-Node-communication.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/introduction/05-Node-communication.rst b/docs/introduction/05-Node-communication.rst index a51a0aa..f10c2cc 100644 --- a/docs/introduction/05-Node-communication.rst +++ b/docs/introduction/05-Node-communication.rst @@ -6,7 +6,7 @@ Communication between a user and a sidechain node is supported out of the box v The API configuration can be found in the sidechain configuration file. -For example see the restApi section of the following file for the SimpleApp. +For example see the restApi section of the following file for the SimpleApp: .. code:: bash @@ -15,7 +15,7 @@ For example see the restApi section of the following file for the SimpleApp. The available options are: -bindAddress -- “IP:port” address for sending HTTP request,e.g. "127.0.0.1:9085" +bindAddress -- “IP:port” address for sending HTTP request, e.g. "127.0.0.1:9085" api-key-hash -- Authentication header must be a string that hashes to the field "api-key-hash" specified in each SC node conf file. Auth header could be empty If no api-key-hash is specified From 1e02e79c8f67824b238b7250da29365c6095e263 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 08:58:19 +0100 Subject: [PATCH 35/61] Update 02-blockchain-representation.rst --- docs/introduction/02-blockchain-representation.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/introduction/02-blockchain-representation.rst b/docs/introduction/02-blockchain-representation.rst index dde08ef..8dbfd21 100644 --- a/docs/introduction/02-blockchain-representation.rst +++ b/docs/introduction/02-blockchain-representation.rst @@ -25,8 +25,7 @@ Node Main elements & intro to a "NodeView" * **Wallet** * The “Wallet” has two main functionalities: 1. It holds the Secret keys that belong to that specific Node. - 2. It keeps track of objects that are of interest to this specific node, e.g. received coins (output boxes whose secret keys are known by the node) and views of them (e.g. balances). - + 2. It keeps track of objects that are of interest to this specific node, e.g. received coins (output boxes whose secret keys are known by the node) and views of them (e.g. balances). * **Memory Pool** * The “Memory pool” is a list of transactions that are known to the node but have not made it to a Sidechain block yet. From f953e4e9f1efad1bddc2feed6efe540e5c8f63f9 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:00:47 +0100 Subject: [PATCH 36/61] Update 06-Base-App.rst --- docs/introduction/06-Base-App.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/introduction/06-Base-App.rst b/docs/introduction/06-Base-App.rst index 6123086..2fb66e3 100644 --- a/docs/introduction/06-Base-App.rst +++ b/docs/introduction/06-Base-App.rst @@ -2,17 +2,18 @@ Base App ======== -SidechainsSDK provides to the developers an out of the box implementation of the Latus Consensus Protocol and the Crosschain Transfer Protocol. +Sidechain SDK provides to the developers an out of the box implementation of the Latus Consensus Protocol and the Crosschain Transfer Protocol. Additionally to this, the SDK provides basic transactions, network layer, data storage and node configuration, as well as entry points for any custom extension. Secret / Proof / Proposition **************************** -* **Secret / Proof / Proposition** - SDK uses its own terms for secret key / public key / signed message and provides various types of them. +* **Sidechain SDK** uses its own terms for secret key / public key / signed message and provides various types of them. * **Secret** - Private key * **Proof** - Signed message -* SDK provides implementations for Secret / Proof / Proposition + +* SDK provides the following implementations for Secret / Proof / Proposition * Curve 25519 - PrivateKey25519 @@ -38,7 +39,7 @@ that represents some coins, i.e. that holds an intrinsic defined value. As an ex some kind of smart contract. In particular, any box could be logically split in two parts: Box and BoxData (box data is included in the box). The Box itself represents the entity in the blockchain, i.e. all operations like create/open etc. are performed on boxes. Box data contains information about the entity like value, proposition address and any custom data. -Every box has its own unique boxId (do not be confused with box type id which is used for serialization). That box id is calculated for each box by next function: +Every box has its own unique boxId (not be confused with box type id which is used for serialization). That box id is calculated for each box by next function: :: From 98960ef2327f99cbd8c568ba1a506fdae1d163ff Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:31:48 +0100 Subject: [PATCH 37/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 35 ++++++++++--------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 0a86eb9..b4d2618 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -8,7 +8,7 @@ Car Registry App high level overview The Car Registry app is an example of a sidechain that implements specific custom data and logic. The purpose of the application is to manage a simplified service that keeps records of existing cars and their owners. It’s simplified as sidechain users will be able to register cars by simply paying a transaction fee, while in a real world scenario, the ability to create a car will be bound by the presentation of a certificate signed by the Department of Motor Vehicles or analogous authority, or some other consensus -mechanism that guarantees that the car really exists in the real world and it’s owned by a user with a given public key. +mechanism that guarantees that the car exists in the real world and it’s owned by a user with a given public key. Accepting that in our example cars will just show up in sidechain, we want to build an application that can store information that identifies a specific car, such as vehicle identification number, model, production year, color (etc)... A car owner should be able to prove their ownership of the cars without disclosing information about their identity. We also want users to sell and buy cars, @@ -20,47 +20,48 @@ User stories: 1 **Q: I want to add my car to a Car Registry Sidechain.** -A: Create a new Car Entry Box, that contains car identification information (Unique can identifier, VIN, manufactures, model, year, registration number) and certificate. Proposition in this box is my public key in this Sidechain. When I create box Sidechain should check car identification information and certificate to be unique in this Sidechain. +*A:* Create a new Car Entry Box, that contains car identification information (Unique can identifier, VIN, manufactures, model, year, registration number), and certificate. Proposition in this box is my public key in this Sidechain. When I create box Sidechain should check car identification information and certificate to be unique in this Sidechain. 2 **Q: I want to create sell order to sell my car using Car Registry Sidechain.** -A: I create a new Car Sell Order Box, that contains the price in coins and information from the Car Entry Box. So cars can exist in the Sidechain as a Car Entry Box or as a Car Sell Order, but not both at same time. Also this box contain the buyer’s public key. When I create a sell order Sidechain should check if there is no other active sell order with this Car Entry Box. Current Sell Order consists of the same information that consists in the Car Entry Box plus description. +*A:* I create a new Car Sell Order Box, that contains the price in coins and information from the Car Entry Box. So cars can exist in the Sidechain as a Car Entry Box or as a Car Sell Order, but not both at the same time. Also, this box contains the buyer’s public key. When I create a sell order Sidechain should check if there is no other active sell order with this Car Entry Box. Current Sell Order consists of the same information that consists of the Car Entry Box plus description. 3 **Q: I want to see all available Sell orders in Sidechain** -A: Have additional storage, which is managed by ApplicationState and stores all Car Sell Orders. All these orders can be retrieved using new HTTP API call. +*A:* Have additional storage, which is managed by ApplicationState and stores all Car Sell Orders. All these orders can be retrieved using the new HTTP API call. 4 **Q: I want to accept a sell order and buy the car.** -A: By accepting sell order I create new transaction in the Sidechain, that creates new Car Entry Box with my public key as proposition and transfers coins amount from me to previous car owner. +*A:* By accepting sell order I create a new transaction in the Sidechain, which creates a new Car Entry Box with my public key as proposition and transfers coins amount from me to the previous car owner. 5 **Q: I want to cancel my Car Sell Order.** -A: I create new transaction, that contains Car Sell Order as input and Car Entry Box with my public key as proposition as output. +*A:* I create a new transaction, that contains Car Sell Order as input and Car Entry Box with my public key as proposition as output. 6. **Q: I want to see my car entry boxes and car sell orders related to me (both created by me and proposed to me).** -A: Implement new storage that will be managed by the application state to store this information. Implement a new HTTP API, that contains a new method to get this information. +*A:* Implement new storage that will be managed by the application state to store this information. Implement a new HTTP API, that contains a new method to get this information. -So, the starting point of the development process is the data representation. A car is an example of a non-coin box because it represents some entity, but not money. Another example of a non-coin box is a car which is selling. We need another box for a selling car because a common car box doesn't have additional data like sale price, seller proposition address etc. For the money representation standard Regular Box is used (Regular box is coin box), that box is provided by SDK. Besides new entities CarBox and CarSellOrder we also need to define a way for creating/destroying those new entities. For that purpose new transactions shall be defined: transaction for creating new car, transaction which move CarBox to CarSellOrder, transaction which declare car selling, i.e. moving CarSellOrder to the new CarBox. All created transactions are not put into the memory pool automatically, so a raw transaction in hex representation shall be put by /transaction/sendTransaction API request. In summary we will add next car boxes and transactions: - - -So, the starting point of the development process is the data representation. A car is an example of a non-coin box because it represents an entity, but not money. -Another example of a non-coin box is a car which is being sold. We need another box for a selling a car because a common car box doesn't have additional data like sale price, -seller proposition address etc. For the money representation a standard Regular Box is used (Regular box is coin box), that box is provided by SDK. Besides new entities CarBox -and CarSellOrder we also need to define a way for creating/destroying those new entities. For that purpose new transactions can be defined: transaction for creating new car, -transaction which move CarBox to CarSellOrder, transaction which declares a car sale, i.e. moving CarSellOrder to the new CarBox. All created transactions are not put into the -memory pool automatically, so a raw transaction in hex representation by added by creating a /transaction/sendTransaction API request. In summary we will add next car boxes and -transactions: +So, the starting point of the development process is the data representation. A car is an example of a non-coin box because it represents some entity, but not money. Another example of a non-coin box is a car that is selling. We need another box for a selling car because a common car box doesn't have additional data like sale price, seller proposition address, etc. For the money representation standard Regular Box is used (Regular box is coin box), that box is provided by SDK. Besides new entities CarBox and CarSellOrder we also need to define a way for creating/destroying those new entities. For that purpose new transactions shall be defined: transaction for creating a new car, transaction which moves CarBox to CarSellOrder, transaction which declares car selling, i.e. moving CarSellOrder to the new CarBox. All created transactions are not put into the memory pool automatically, so a raw transaction in hex representation shall be put by /transaction/sendTransaction API request. In summary, we will add the next car boxes and transactions: TBD ADD TABLE ++-------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ +| Entity name | Entity description | Entity fields | ++=============+==================================================================================+=============================================================================================+ +| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | ++-------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ +| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car | +| | | year -- vehicle year production | +| | | model -- car model | +| | | color -- car color | ++-------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ Car registry implementation *************************** From 964446607ca6b63067d3d2db6698d04762cfb9ef Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:32:46 +0100 Subject: [PATCH 38/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 38 +++++++++++++------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index b4d2618..f8fbee4 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -50,18 +50,32 @@ User stories: So, the starting point of the development process is the data representation. A car is an example of a non-coin box because it represents some entity, but not money. Another example of a non-coin box is a car that is selling. We need another box for a selling car because a common car box doesn't have additional data like sale price, seller proposition address, etc. For the money representation standard Regular Box is used (Regular box is coin box), that box is provided by SDK. Besides new entities CarBox and CarSellOrder we also need to define a way for creating/destroying those new entities. For that purpose new transactions shall be defined: transaction for creating a new car, transaction which moves CarBox to CarSellOrder, transaction which declares car selling, i.e. moving CarSellOrder to the new CarBox. All created transactions are not put into the memory pool automatically, so a raw transaction in hex representation shall be put by /transaction/sendTransaction API request. In summary, we will add the next car boxes and transactions: -TBD ADD TABLE - -+-------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ -| Entity name | Entity description | Entity fields | -+=============+==================================================================================+=============================================================================================+ -| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | -+-------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ -| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car | -| | | year -- vehicle year production | -| | | model -- car model | -| | | color -- car color | -+-------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+ ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Entity name | Entity description | Entity fields | ++=====================+=======================================================================================================================================================================================================================+=====================================================================================================================================================================================================================+ +| CarBox | Box which contains car box data, which could be stored and operated in Sidechain | boxData -- contains car box data | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarBoxData | Description of the car by using defined properties | vin -- vehicle identification number which contains unique identification number of the car | +| | | year -- vehicle year production | +| | | model -- car model | +| | | color -- car color | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderBox | Box which contains car sell order data, which could be stored and operated in Sidechain. | boxData -- contains car sell order data | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderBoxData | Description of the car which is in sell status. That box data contains a special type of proposition SellOrderProposition. That proposition allows us to spent the box in two different ways: by seller and by buyer | vin -- vehicle identification number which contains unique identification number of the car | +| | | year -- vehicle year production | +| | | model -- car model | +| | | color -- car color | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarSellOrderInfo | Information about car’s selling as well as proof of a current car owner. Used in transaction processing. | carBoxToOpen -- car box for start selling | +| | | proof -- proof for open initial car box | +| | | price -- selling price | +| | | buyerProposition -- current implementation expect to have the specific buyer which had been found off chain. Thus during creation of car sell order we already know buyer and shall put his future car proposition | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| CarBuyOrderInfo | Data required for buying a car or recall a car sell order. Used in transaction processing. | carSellOrderBoxToOpen -- Car sell order box to be open | +| | | proof -- specific proof of type SellOrderSpendingProof | +| | | for confirming buying of the car or recall car sell order | ++---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Car registry implementation *************************** From 87f9f7f130c1940bcc8eaf2de1ed0b979d511896 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:41:29 +0100 Subject: [PATCH 39/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 343 +----------------- 1 file changed, 5 insertions(+), 338 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index f8fbee4..50f4cc0 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -77,347 +77,14 @@ So, the starting point of the development process is the data representation. A | | | for confirming buying of the car or recall car sell order | +---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -Car registry implementation -*************************** - -First of all we need to define new boxes. -As described before, a Car Box is a non-coin box. As defined before we need Car Box Data class as well for describing custom data. So we need to define CarBox and CarBoxData as separate classes for setting proper way to serialization/deserialization. - -So overall next classes will be created: - - :: - - public class CarBox extends AbstractNoncedBox - - :: - - public class CarBoxSerializer implements BoxSerializer - - :: - - public class CarBoxData extends AbstractNoncedBoxData - - :: - - public class CarSellOrder extends AbstractNoncedBox - - :: - - public class CarSellOrderSerializer implements BoxSerializer - - :: - - public class CarSellOrderData extends AbstractNoncedBoxData - - :: - - public class CarSellOrderDataSerializer implements NoncedBoxDataSerializer - - -Implementation of CarBoxData -**************************** - - CarBoxData is implemented according to the description from “Custom Box Data Creation” chapter as public class CarBoxData extends AbstractNoncedBoxData with custom data as: - - :: - - private final BigInteger vin; - private final int year; - private final String model; - private final String color; - private final String description; - - public byte[] bytes() { - return Bytes.concat( - proposition().bytes(), - Longs.toByteArray(value()), - Ints.toByteArray(year), - Ints.toByteArray(model.getBytes().length), - model.getBytes(), - Ints.toByteArray(color.getBytes().length), - color.getBytes(), - Ints.toByteArray(description.getBytes().length), - description.getBytes(), - vin.toByteArray() - ); - } - -1. Serialization is implemented by the SDK developer, as described before, shall include proposition and value into serialization. Ordering is not important. -2. CarBoxData shall have a value parameter as a Scorex limitation, but in our business logic CarBoxData does not use that data at all because each car is unique and doesn't have any inherent value. Thus value is hidden, i.e. value is not present in the constructor parameter and just set by default to “1” in the class constructor. -3. public byte[] customFieldsHash() shall be implemented because we introduce some new custom data. - -Implementation of CarBoxDataSerializer -************************************** - -CarBoxDataSerializer is implemented according to the description from “Custom Box Data Serializer Creation” chapter as -public class CarBoxDataSerializer implements NoncedBoxDataSerializer. - -Implementation of CarBox -************************ - -CarBox is implemented according to the description from “Custom Box Class creation” chapter as -public class CarBox extends AbstractNoncedBox -Few comments about implementation: - - 1. A long nonce whould be included as a part of serialization, thus serialization is implemented in next way: - - :: - public byte[] bytes() - { - return Bytes.concat( - Longs.toByteArray(nonce), - CarBoxDataSerializer.getSerializer().toBytes(boxData) - ); - } - - - 2. CarBox defines it's own unique id by implementation of the function public byte boxTypeId(). Similar function is defined in CarBoxData but it is a different id despite value returned in CarBox and CarBoxData is the same. - - -Implementation of CarBoxSerializer -********************************** - -CarBoxSerializer is implemented according to the description from “Custom Box Data Serializer Creation” chapter as -public class CarBoxSerializer implements BoxSerializer. - - -Implementation of CarSellOrderData -********************************** - -CarSellOrderData is implemented according description from “Custom Box Data Creation” chapter as public class CarSellOrderData extends AbstractNoncedBoxData with custom data as: -private final PublicKey25519Proposition sellerProposition; -private final BigInteger vin; - -Comments about implementation: - 1. Proposition and value shall be included in serialization as it done in CarBoxData - 2. Id of that box data shall different than in CarBoxData - - -Implementation of CarSellOrderDataSerializer -******************************************** - -CarSellOrderDataSerializer is implemented according to the description from “Custom Box Data Serializer Creation” chapter as -public class CarSellOrderDataSerializer implements NoncedBoxDataSerializer. - - -Implementation of CarSellOrder +Special proposition and proof: ****************************** -CarSellorder is implemented according to description from “Custom Box Class creation” chapter as -public class CarSellOrder extends AbstractNoncedBox - - -Extend API by creating new transactions Car creation transaction and Car sell Order transaction -*********************************************************************************************** - -For our purpose we need to define two transaction's, a Car creation transaction and a Car sell Order transaction according to the custom API extensionas below: - -a) Create a new class CarApi which extends ApplicationApiGroup class, add that new class to Route by it in SimpleAppModule, like described in Custom API manual. In our case it is done in CarRegistryAppModule by - - * Creating customApiGroups as a list of custom API Groups: - * List customApiGroups = new ArrayList<>(); - * Adding created CarApi into customApiGroups: - customApiGroups.add(new CarApi()); - * Binding that custom api group via dependency injection: - :: - - bind(new TypeLiteral> () {}) - .annotatedWith(Names.named("CustomApiGroups")) - .toInstance(customApiGroups); - -b) Define Car creation transaction. - - 1. Defining request class/JSON request body - As input for the transaction we expect: - Regular box id as input for paying fee; - Fee value; - Proposition address which will be recognized as a Car Proposition; - Vehicle identification number of car. So next request class shall be created: - - :: - - public static class CreateCarBoxRequest { - private BigInteger vin; - private int year; - private String model; - private String color; - private String description; - private PublicKey25519Proposition carProposition; - - private int fee; - private String boxId; - - public BigInteger getVin() { - return vin; - } - - public void setVin(String vin) { - this.vin = new BigInteger(vin); - } - - - public int getYear() { - return year; - } - - public void setYear(int year) { - this.year = year; - } - - public String getModel() { - return model; - } - - public void setModel(String model) { - this.model = model; - } - - public String getColor() { - return color; - } - - public void setColor(String color) { - this.color = color; - } - - public String getDescription() { - return description; - } - - public void setDescription(String description) { - this.description = description; - } - - public PublicKey25519Proposition getCarProposition() { - return carProposition; - } - - public void setCarProposition(String propositionHexBytes) { - byte[] propositionBytes = BytesUtils.fromHexString(propositionHexBytes); - carProposition = new PublicKey25519Proposition(propositionBytes); - } - - - public int getFee() { - return fee; - } - - public void setFee(int fee) { - this.fee = fee; - } - - public String getBoxId() { - return boxId; - } - - public void setBoxId(String boxId) { - this.boxId = boxId; - } - } - -Request class should have appropriate setters and getters for all class members, also class members' names define structure for related JSON structure according to the jackson library so JSON structure is expected: - - :: - - { - "vin": "30124", - “year”: 1984, - “model”: “Lamborghini”“ color”: ”deep black”“ description”: ”best car in the world” "carProposition": "a5b10622d70f094b7276e04608d97c7c699c8700164f78e16fe5e8082f4bb2ac", - "fee": 1, - "boxId": "d59f80b39d24716b4c9a54cfed4bff8e6f76597a7b11761d0d8b7b27ddf8bd3c" - } - -Points to note: setter input parameter could have different type than set class member, it allow's us to do all necessary conversation in setters; byte data is represented initially as a hex string, which converted to bytes by BytesUtils.fromHexString() function. - -2. Define response for Car creation transaction. The result of transaction shall be defined by implementing SuccessResponse interface with class members which will be returned as API response, all members should have properly settters and getters, also response class shall have proper annotation @JsonView(Views.Default.class) thus jackson library is able correctly represent response class in JSON format. In our case we expect to return transaction bytes, so response class is next: - - :: - - @JsonView(Views.Default.class) - class CarResponse implements SuccessResponse { - private final String createCarTxBytes; - - public CarResponse(String createCarTxBytes) { - this.createCarTxBytes = createCarTxBytes; - } - - public String carTxBytes() { - return createCarTxBytes; - } - - public String getCreateCarTxBytes() { - return createCarTxBytes; - } - } - -3. Define Car creation transaction - - :: - - private ApiResponse createCar(SidechainNodeView view, CreateCarBoxRequest ent) - -As a first parameter we pass reference to SidechainNodeView, second reference is previously defined class on step 1 for representation of JSON request. -During transaction creation we need to do next: - - * check is input box secret is present in our wallet at all - * check if enough coins are stored in that box to pay fee - * calculate fee for change - * create RegularBoxData for change for fee - * create new CarBoxData according JSON request data - * create inputs from input box and outputs RegularBoxData for change and new CarBoxData - * calculate additional data like timestamp - * get list of fake proof which are required to build message to be signed: List fakeProofs = Collections.nCopies(inputIds.size(), null); - * build transaction bytes to be signed instead of real proof put some fake proof into from the previous step. For transaction creation a special factory shall be used. Access to that factory could be achieved by call getSidechainCoreTransactionFactory()function: - SidechainCoreTransaction unsignedTransaction = - getSidechainCoreTransactionFactory().create(inputIds, outputs, fakeProofs, ent.fee, timestamp); - byte[] messageToSign = unsignedTransaction.messageToSign(); - * create proof by sign transaction by private key of input box - * create new transaction - * add to the CarResponse created transaction bytes - -4. Define request for Car sell order transaction CreateCarSellOrderRequest similar as it was done for Car creation transaction request - -5. Define response for Car sell order transaction CreateCarSellOrderResponce as it was done for Car creation transaction response - -6. Define Car Sell order transaction - private ApiResponse createCarSellOrder(SidechainNodeView view, CreateCarSellOrderRequest ent) - Required actions are similar as it was done for Create Car transaction, but we don’t need to worry about fee, i.e. fee is set as 0. Main idea is a moving Car Box into CarSellOrderBox - -7. Define Car sell order response -As a result of Car sell order we want to get hex byte representation of that transaction - -8. Define request class for accepting Car Sell Order Transaction, with input: -String carSellOrderId; -String paymentRegularBoxId; -PublicKey25519Proposition buyerProposition; - -9. Define response class for CarSellOrder transaction -Response shall contains hex representation of transaction bytes, thus response class are next: - - :: - - @JsonView(Views.Default.class) - class AcceptCarSellOrderResponce implements SuccessResponse { - private final String acceptedCarSellOrderTxBytes; - - public AcceptCarSellOrderResponce(String acceptedCarSellOrderTxBytes) { - this.acceptedCarSellOrderTxBytes = acceptedCarSellOrderTxBytes; - } - - public String acceptedCarSellOrderTxBytes() { - return acceptedCarSellOrderTxBytes; - } - - public String getAcceptedCarSellOrderTxBytes() { - return acceptedCarSellOrderTxBytes; - } - } - -10. Create AcceptCarSellorder transaction - - - + **a)** SellOrderProposition Standard proposition only contains one public key, i.e. only one specific secret key could open that proposition. + However, for a sell order we need a way to open and spend the box in two different ways, so we need to specify a additional proposition/proof. + SellOrderProposition contains two public keys: ownerPublicKeyBytes and buyerPublicKeyBytes. So theseller or buyer private keys could open that proposition. + SellOrderSpendingProof that proof allows us to open and spend CarSellOrderBox in two different ways: open by buyer and thus buy the car or open by seller and thus recall car sell order. Such proof creation requires two different API calls but as a result, for both cases, we will have the same type of transaction with the same proof type. From c754a264ab22bd5c2ce357de947077df34186002 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:44:48 +0100 Subject: [PATCH 40/61] Update 06-Base-App.rst --- docs/introduction/06-Base-App.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/introduction/06-Base-App.rst b/docs/introduction/06-Base-App.rst index 2fb66e3..6025664 100644 --- a/docs/introduction/06-Base-App.rst +++ b/docs/introduction/06-Base-App.rst @@ -19,10 +19,12 @@ Secret / Proof / Proposition - PrivateKey25519 - PublicKey25519Proposition - Signature25519 + * VRF based on ginger-lib - VrfSecretKey - VrfPublicKey - VrfProof + * Schnorr based on ginger-lib - SchnorrSecret - SchnorrPropostion From 8a4fa3aa116dfcce00349fe30c69dc3a799d1919 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:50:42 +0100 Subject: [PATCH 41/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 50f4cc0..aaf845a 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -80,11 +80,12 @@ So, the starting point of the development process is the data representation. A Special proposition and proof: ****************************** - **a)** SellOrderProposition Standard proposition only contains one public key, i.e. only one specific secret key could open that proposition. + a) **SellOrderProposition** Standard proposition only contains one public key, i.e. only one specific secret key could open that proposition. However, for a sell order we need a way to open and spend the box in two different ways, so we need to specify a additional proposition/proof. - SellOrderProposition contains two public keys: ownerPublicKeyBytes and buyerPublicKeyBytes. So theseller or buyer private keys could open that proposition. + SellOrderProposition contains two public keys: ```ownerPublicKeyBytes``` and ```buyerPublicKeyBytes```. So the seller or buyer private keys could open that proposition. - SellOrderSpendingProof that proof allows us to open and spend CarSellOrderBox in two different ways: open by buyer and thus buy the car or open by seller and thus recall car sell order. Such proof creation requires two different API calls but as a result, for both cases, we will have the same type of transaction with the same proof type. + b) **SellOrderSpendingProof** The proof that allows us to open and spend ```CarSellOrderBox``` in two different ways: opened by the buyer and thus buy the car or opened by the seller and thus recall car sell order. + Such proof creation requires two different API calls but as a result, in both cases, we will have the same type of transaction with the same proof type. From 3f3c77356a38551711a3b898525f2126053a40d6 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:51:11 +0100 Subject: [PATCH 42/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index aaf845a..bbd55c5 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -84,8 +84,7 @@ Special proposition and proof: However, for a sell order we need a way to open and spend the box in two different ways, so we need to specify a additional proposition/proof. SellOrderProposition contains two public keys: ```ownerPublicKeyBytes``` and ```buyerPublicKeyBytes```. So the seller or buyer private keys could open that proposition. - b) **SellOrderSpendingProof** The proof that allows us to open and spend ```CarSellOrderBox``` in two different ways: opened by the buyer and thus buy the car or opened by the seller and thus recall car sell order. - Such proof creation requires two different API calls but as a result, in both cases, we will have the same type of transaction with the same proof type. + b) **SellOrderSpendingProof** The proof that allows us to open and spend ```CarSellOrderBox``` in two different ways: opened by the buyer and thus buy the car or opened by the seller and thus recall car sell order. Such proof creation requires two different API calls but as a result, in both cases, we will have the same type of transaction with the same proof type. From 20adc8db954b9f6f77b89ecb5a47f80150864026 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:52:19 +0100 Subject: [PATCH 43/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index bbd55c5..8fa98d6 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -82,9 +82,9 @@ Special proposition and proof: a) **SellOrderProposition** Standard proposition only contains one public key, i.e. only one specific secret key could open that proposition. However, for a sell order we need a way to open and spend the box in two different ways, so we need to specify a additional proposition/proof. - SellOrderProposition contains two public keys: ```ownerPublicKeyBytes``` and ```buyerPublicKeyBytes```. So the seller or buyer private keys could open that proposition. + SellOrderProposition contains two public keys: ``ownerPublicKeyBytes`` and ``buyerPublicKeyBytes``. So the seller or buyer private keys could open that proposition. - b) **SellOrderSpendingProof** The proof that allows us to open and spend ```CarSellOrderBox``` in two different ways: opened by the buyer and thus buy the car or opened by the seller and thus recall car sell order. Such proof creation requires two different API calls but as a result, in both cases, we will have the same type of transaction with the same proof type. + b) **SellOrderSpendingProof** The proof that allows us to open and spend ``CarSellOrderBox`` in two different ways: opened by the buyer and thus buy the car or opened by the seller and thus recall car sell order. Such proof creation requires two different API calls but as a result, in both cases, we will have the same type of transaction with the same proof type. From 923a7094bb857cef126cc921aa50d73c2d6804d6 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 09:59:28 +0100 Subject: [PATCH 44/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 8fa98d6..a16d9fb 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -87,6 +87,23 @@ Special proposition and proof: b) **SellOrderSpendingProof** The proof that allows us to open and spend ``CarSellOrderBox`` in two different ways: opened by the buyer and thus buy the car or opened by the seller and thus recall car sell order. Such proof creation requires two different API calls but as a result, in both cases, we will have the same type of transaction with the same proof type. +Transactions: +************* + + a) **AbstractRegularTransaction** base custom transaction, all other custom transactions extend this base transaction. + + *Input parameters are:* + + ``inputRegularBoxIds`` - list of regular boxes for payments like fee and car buying + ``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in ``inputRegularBoxIds`` + ``outputRegularBoxesData`` - list of output regular boxes, used as the change from paying a fee, as well as a new regular box for payment for the car. + ``fee`` - transaction fee + ``timestamp`` - transaction timestamp + + *Output boxes:* + + Regular Boxes created by change or car payment + From f629c58101bd55b709448b87a59310b49f600944 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:00:07 +0100 Subject: [PATCH 45/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index a16d9fb..88d3fc0 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -83,7 +83,7 @@ Special proposition and proof: a) **SellOrderProposition** Standard proposition only contains one public key, i.e. only one specific secret key could open that proposition. However, for a sell order we need a way to open and spend the box in two different ways, so we need to specify a additional proposition/proof. SellOrderProposition contains two public keys: ``ownerPublicKeyBytes`` and ``buyerPublicKeyBytes``. So the seller or buyer private keys could open that proposition. - +| b) **SellOrderSpendingProof** The proof that allows us to open and spend ``CarSellOrderBox`` in two different ways: opened by the buyer and thus buy the car or opened by the seller and thus recall car sell order. Such proof creation requires two different API calls but as a result, in both cases, we will have the same type of transaction with the same proof type. From 20c776ddd1e15cf7eeb07a1b7084e2c10a242015 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:00:52 +0100 Subject: [PATCH 46/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 88d3fc0..d5b68ce 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -83,7 +83,7 @@ Special proposition and proof: a) **SellOrderProposition** Standard proposition only contains one public key, i.e. only one specific secret key could open that proposition. However, for a sell order we need a way to open and spend the box in two different ways, so we need to specify a additional proposition/proof. SellOrderProposition contains two public keys: ``ownerPublicKeyBytes`` and ``buyerPublicKeyBytes``. So the seller or buyer private keys could open that proposition. -| + | b) **SellOrderSpendingProof** The proof that allows us to open and spend ``CarSellOrderBox`` in two different ways: opened by the buyer and thus buy the car or opened by the seller and thus recall car sell order. Such proof creation requires two different API calls but as a result, in both cases, we will have the same type of transaction with the same proof type. From 8ecb1ad9ec129dc8b37ef4ad6f5f17b07c744163 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:01:50 +0100 Subject: [PATCH 47/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index d5b68ce..9c70c61 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -95,9 +95,13 @@ Transactions: *Input parameters are:* ``inputRegularBoxIds`` - list of regular boxes for payments like fee and car buying + ``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in ``inputRegularBoxIds`` + ``outputRegularBoxesData`` - list of output regular boxes, used as the change from paying a fee, as well as a new regular box for payment for the car. + ``fee`` - transaction fee + ``timestamp`` - transaction timestamp *Output boxes:* From f3ed9b253762404d3daed781c8e824e7250516d5 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:06:09 +0100 Subject: [PATCH 48/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 9c70c61..cd93c86 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -3,7 +3,7 @@ Car Registry Tutorial ==================================== Car Registry App high level overview -************************************ +#################################### The Car Registry app is an example of a sidechain that implements specific custom data and logic. The purpose of the application is to manage a simplified service that keeps records of existing cars and their owners. It’s simplified as sidechain users will be able to register cars by simply paying a transaction fee, while in a real world scenario, @@ -15,7 +15,7 @@ A car owner should be able to prove their ownership of the cars without disclosi with ZEN coins. User stories: -************* +############# 1 **Q: I want to add my car to a Car Registry Sidechain.** @@ -78,7 +78,7 @@ So, the starting point of the development process is the data representation. A +---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Special proposition and proof: -****************************** +############################## a) **SellOrderProposition** Standard proposition only contains one public key, i.e. only one specific secret key could open that proposition. However, for a sell order we need a way to open and spend the box in two different ways, so we need to specify a additional proposition/proof. @@ -88,20 +88,16 @@ Special proposition and proof: Transactions: -************* +############# a) **AbstractRegularTransaction** base custom transaction, all other custom transactions extend this base transaction. *Input parameters are:* ``inputRegularBoxIds`` - list of regular boxes for payments like fee and car buying - ``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in ``inputRegularBoxIds`` - ``outputRegularBoxesData`` - list of output regular boxes, used as the change from paying a fee, as well as a new regular box for payment for the car. - ``fee`` - transaction fee - ``timestamp`` - transaction timestamp *Output boxes:* From 47a4f51d709373d79a6591e44208f7dace524cba Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:07:07 +0100 Subject: [PATCH 49/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index cd93c86..6e4a66e 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -90,8 +90,9 @@ Special proposition and proof: Transactions: ############# - a) **AbstractRegularTransaction** base custom transaction, all other custom transactions extend this base transaction. - +AbstractRegularTransaction base custom transaction, all other custom transactions extend this base transaction. +************************** + *Input parameters are:* ``inputRegularBoxIds`` - list of regular boxes for payments like fee and car buying From 2db709a8a478c6882e05c752a5c45b3635d15cc9 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:08:31 +0100 Subject: [PATCH 50/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 6e4a66e..25cd170 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -90,9 +90,11 @@ Special proposition and proof: Transactions: ############# -AbstractRegularTransaction base custom transaction, all other custom transactions extend this base transaction. +AbstractRegularTransaction ************************** +Base custom transaction, all other custom transactions extend this base transaction. + *Input parameters are:* ``inputRegularBoxIds`` - list of regular boxes for payments like fee and car buying @@ -105,7 +107,9 @@ AbstractRegularTransaction base custom transaction, all other custom transaction Regular Boxes created by change or car payment +CarDeclarationTransaction +************************* - +Transaction for declaring a car in the Sidechain, this transaction extends ``AbstractRegularTransaction`` thus some base functionality already is implemented. From 183daebd1449c1b153167cbe5537a99ead2462dd Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:15:07 +0100 Subject: [PATCH 51/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 25cd170..1c5b31f 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -104,7 +104,7 @@ Base custom transaction, all other custom transactions extend this base transact ``timestamp`` - transaction timestamp *Output boxes:* - + Regular Boxes created by change or car payment CarDeclarationTransaction @@ -112,4 +112,17 @@ CarDeclarationTransaction Transaction for declaring a car in the Sidechain, this transaction extends ``AbstractRegularTransaction`` thus some base functionality already is implemented. + *Input parameters are:* + + ``inputRegularBoxIds`` -- list of regular boxes for payments like fee and car buying + ``inputRegularBoxProofs`` -- appropriate list of proofs for box opening for each regular box in inputRegularBoxIds + ``outputRegularBoxesData`` -- list of output regular boxes, used as change from paying a fee, as well as a new regular box for car payment. + ``fee`` -- transaction fee + ``timestamp`` -- transaction timestamp + ``outputCarBoxData`` -- box data which contains information about a new car. + + *Output boxes:* + + New CarBox with new declared car + From d290c98ce3c804ed6837505b6d7d6a610ffb7cdb Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:20:29 +0100 Subject: [PATCH 52/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 1c5b31f..c7d6eda 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -125,4 +125,26 @@ Transaction for declaring a car in the Sidechain, this transaction extends ``Abs New CarBox with new declared car +SellCarTransaction +****************** + +Transaction for starting selling of the car. + + *Input parameters are:* + + ``inputRegularBoxIds`` - list of regular boxes for payments like fee and car buying + ``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in inputRegularBoxIds + ``outputRegularBoxesData`` - list of output regular boxes, used as change from paying fee, as well as new regular box for payment for car. + ``fee`` -- transaction fee + ``timestamp`` - transaction timestamp + ``carSellOrderInfo`` - information about car selling, including such information as car description and specific proposition ``SellOrderProposition``. + + *Output boxes:* + + CarSellOrderBox which represents the car to be sold, that box could be opened by the initial car owner or specified buyer in case if buyer buys that car. + +BuyCarTransaction +***************** + +This transaction allows us to buy a car or recall a car sell order. From e97177c400aa8120aa9762c6519775883b537510 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:27:09 +0100 Subject: [PATCH 53/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index c7d6eda..7e23b28 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -148,3 +148,19 @@ BuyCarTransaction This transaction allows us to buy a car or recall a car sell order. + *Input parameters are:* + + ``inputRegularBoxIds`` - list of regular boxes for payments like fee and purchasing the car + ``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in inputRegularBoxIds + ``outputRegularBoxesData`` - list of output regular boxes, used as change from paying fee, as well as a new regular box for payment for the car. + ``fee`` - transaction fee + ``timestamp`` - transaction timestamp + ``carBuyOrderInfo`` - information for buy car or recall car sell order. + + *Output boxes:* + + Two possible outputs are possible. In the case of buying car: new CarBox with new owner, new Regular box with a value declared in carBuyOrderInfo for former owner of the Car. + +Car registry implementation +########################### + From 91ddb63e3b90cbc97068ac4ba9b247243fe15bc2 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:30:11 +0100 Subject: [PATCH 54/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 7e23b28..416ba39 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -164,3 +164,8 @@ This transaction allows us to buy a car or recall a car sell order. Car registry implementation ########################### +First of all we need to define new boxes. +As described before, a Car Box is a non-coin box. As defined before we need Car Box Data class as well for describing custom data. So we need to define CarBox and CarBoxData as separate classes for setting proper way to serialization/deserialization. + +Implementation of CarBoxData: +***************************** From 39d690cc302dc6c7a4b8a1e4d570a2ad72de1e3b Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:31:27 +0100 Subject: [PATCH 55/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 416ba39..fdecb20 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -150,12 +150,12 @@ This transaction allows us to buy a car or recall a car sell order. *Input parameters are:* - ``inputRegularBoxIds`` - list of regular boxes for payments like fee and purchasing the car - ``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in inputRegularBoxIds - ``outputRegularBoxesData`` - list of output regular boxes, used as change from paying fee, as well as a new regular box for payment for the car. - ``fee`` - transaction fee - ``timestamp`` - transaction timestamp - ``carBuyOrderInfo`` - information for buy car or recall car sell order. + |``inputRegularBoxIds`` - list of regular boxes for payments like fee and purchasing the car + |``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in inputRegularBoxIds + |``outputRegularBoxesData`` - list of output regular boxes, used as change from paying fee, as well as a new regular box for payment for the car. + |``fee`` - transaction fee + |``timestamp`` - transaction timestamp + |``carBuyOrderInfo`` - information for buy car or recall car sell order. *Output boxes:* From dc8f979c70dcd0d3f00009781e6a7b01e83a8ece Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:33:24 +0100 Subject: [PATCH 56/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index fdecb20..f3fdec6 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -150,12 +150,12 @@ This transaction allows us to buy a car or recall a car sell order. *Input parameters are:* - |``inputRegularBoxIds`` - list of regular boxes for payments like fee and purchasing the car - |``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in inputRegularBoxIds - |``outputRegularBoxesData`` - list of output regular boxes, used as change from paying fee, as well as a new regular box for payment for the car. - |``fee`` - transaction fee - |``timestamp`` - transaction timestamp - |``carBuyOrderInfo`` - information for buy car or recall car sell order. + ``inputRegularBoxIds`` - list of regular boxes for payments like fee and purchasing the car + ``inputRegularBoxProofs`` - appropriate list of proofs for box opening for each regular box in inputRegularBoxIds + ``outputRegularBoxesData`` - list of output regular boxes, used as change from paying fee, as well as a new regular box for payment for the car. + ``fee`` - transaction fee + ``timestamp`` - transaction timestamp + ``carBuyOrderInfo`` - information for buy car or recall car sell order. *Output boxes:* @@ -169,3 +169,9 @@ As described before, a Car Box is a non-coin box. As defined before we need Car Implementation of CarBoxData: ***************************** + +CarBoxData is implemented according description from “Custom Box Data Creation” chapter as ``public class CarBoxData extends AbstractNoncedBoxData`` with custom data as: + private final BigInteger vin; + private final int year; + private final String model; + private final String color; From b8ca8613f0dfb7cdd601796158cc0935226c5596 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:39:11 +0100 Subject: [PATCH 57/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 20 ++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index f3fdec6..223502b 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -170,8 +170,18 @@ As described before, a Car Box is a non-coin box. As defined before we need Car Implementation of CarBoxData: ***************************** -CarBoxData is implemented according description from “Custom Box Data Creation” chapter as ``public class CarBoxData extends AbstractNoncedBoxData`` with custom data as: - private final BigInteger vin; - private final int year; - private final String model; - private final String color; +CarBoxData is implemented according description from ``Custom Box Data Creation`` section as ``public class CarBoxData extends AbstractNoncedBoxData`` with custom data as: + + :: + private final BigInteger vin; + private final int year; + private final String model; + private final String color; + +Few comments about implementation: + + 1. Special marker ``@JsonView(Views.Default.class)`` are used during class declaration, that annotation allows SDK core do proper JSON serialization. + 2. Serialization is implemented in ``public byte[] bytes()`` method as well as parsing implemented in ``public static CarBoxData parseBytes(byte[] bytes)`` method. SDK developer, as described before, shall include the proposition and value into serialization/deserialization. Order doesn't matter. + 3. ``CarBoxData`` shall have a value parameter as a Scorex limitation, but in our business logic CarBoxData does not use that data at all because each car is unique and doesn't have any inherent value. Thus value is hidden, i.e. value is not present in the constructor parameter and just set by default to “1” in the class constructor. + 4. ``public byte[] customFieldsHash()`` shall be implemented because we introduce some new custom data. + From e814ead44d871602905d0a853c23eabe405793af Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:42:41 +0100 Subject: [PATCH 58/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 223502b..a0665b2 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -184,4 +184,10 @@ Few comments about implementation: 2. Serialization is implemented in ``public byte[] bytes()`` method as well as parsing implemented in ``public static CarBoxData parseBytes(byte[] bytes)`` method. SDK developer, as described before, shall include the proposition and value into serialization/deserialization. Order doesn't matter. 3. ``CarBoxData`` shall have a value parameter as a Scorex limitation, but in our business logic CarBoxData does not use that data at all because each car is unique and doesn't have any inherent value. Thus value is hidden, i.e. value is not present in the constructor parameter and just set by default to “1” in the class constructor. 4. ``public byte[] customFieldsHash()`` shall be implemented because we introduce some new custom data. + +Implementation of CarBoxDataSerializer: +*************************************** + +``CarBoxDataSerializer`` is implemented according to the description from ``Custom Box Data Serializer Creation`` section as ``public class CarBoxDataSerializer implements NoncedBoxDataSerializer``. Nothing special to note about. + From 3797f9d558b0b482ac78265f150334b1205baab9 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:47:38 +0100 Subject: [PATCH 59/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 24 ++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index a0665b2..e49fccb 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -190,4 +190,26 @@ Implementation of CarBoxDataSerializer: ``CarBoxDataSerializer`` is implemented according to the description from ``Custom Box Data Serializer Creation`` section as ``public class CarBoxDataSerializer implements NoncedBoxDataSerializer``. Nothing special to note about. - +Implementation of CarBox: +************************* + + ``CarBox`` is implemented according to description from ``Custom Box Class creation`` section as ``public class CarBox extends AbstractNoncedBox`` + +Few comments about implementation: + + 1. As a serialization part SDK developer shall include ``long nonce`` as a part of serialization, thus serialization is implemented in the following way: + + :: + public byte[] bytes() + { + return Bytes.concat( + Longs.toByteArray(nonce), + CarBoxDataSerializer.getSerializer().toBytes(boxData) + ); + } + + 2. ``CarBox`` defines his own unique id by implementation of the function ``public byte boxTypeId()``. Similar function is defined in ``CarBoxData`` but it is a different ids despite value returned in ``CarBox`` and ``CarBoxData`` is the same. + + + + From 47f4c21cc0e009d4df32dbe3b951a46bfba56443 Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 10:58:45 +0100 Subject: [PATCH 60/61] Update 08-Car-registry-tutorial.rst --- .../introduction/08-Car-registry-tutorial.rst | 276 ++++++++++++++++++ 1 file changed, 276 insertions(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index e49fccb..84049b9 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -210,6 +210,282 @@ Few comments about implementation: 2. ``CarBox`` defines his own unique id by implementation of the function ``public byte boxTypeId()``. Similar function is defined in ``CarBoxData`` but it is a different ids despite value returned in ``CarBox`` and ``CarBoxData`` is the same. +Implementation of CarBoxSerializer: +*********************************** + +CarBoxSerializer is implemented according to the description from “Custom Box Data Serializer Creation” section as +``public class CarBoxSerializer implements BoxSerializer``. Nothing special to note about. + +Implementation of SellOrderProposition +************************************** + +``SellOrderProposition`` implemented as ``public final class SellOrderProposition implements ProofOfKnowledgeProposition`` +Nothing special about implementation besides the fact that that proposition contains two public keys, thus that proposition could be opened by two different keys. + +Implementation of SellOrderPropositionSerializer +************************************************ + +``SellOrderPropositionSerializer`` implemented as ``public final class SellOrderPropositionSerializer implements PropositionSerializer`` +Nothing special about implementation + +Implementation of SellOrderSpendingProof +**************************************** + +``SellOrderSpendingProof implemented as extends AbstractSignature25519`` + +Few comments about implementation: Information about proof type is defined by the result of method boolean isSeller(). For example an implementation of method isValid uses that flag: + + :: + + public boolean isValid(SellOrderProposition proposition, byte[] message) { + if(isSeller) { + // Car seller wants to discard selling. + return Ed25519.verify(signatureBytes, message, proposition.getOwnerPublicKeyBytes()); + } else { + // Specific buyer wants to buy the car. + return Ed25519.verify(signatureBytes, message, proposition.getBuyerPublicKeyBytes()); + } + } + + +Implementation of CarSellOrderBoxData +************************************* + +CarSellOrderBoxData is implemented according description from “Custom Box Data Creation” chapter as public class CarSellOrderData extends AbstractNoncedBoxData with custom data as: +private final String vin; +private final int year; +private final String model; +private final String color; + + +Few comments about implementation: +Proposition and value shall be included in serialization as it done in CarBoxData +Id of that box data could be different than in CarBoxData +CarSellOrderBoxData uses custom proposition type, thus proposition field have SellOrderProposition type + + + + +Implementation of CarSellOrderBoxDataSerializer +*********************************************** + +CarSellOrderDataSerializer is implemented according to the description from “Custom Box Data Serializer Creation” chapter as +public class CarSellOrderBoxDataSerializer implements NoncedBoxDataSerializer. +Nothing special to note about. + + +Implementation of CarSellOrderBox +********************************* + +CarSellorder is implemented according to description from “Custom Box Class creation” chapter as +public final class CarSellOrderBox extends AbstractNoncedBox + +Nothing special about implementation. + + + +AbstractRegularTransaction +************************** + +AbstractRegularTransaction is implemented as public abstract class AbstractRegularTransaction extends SidechainTransaction> + +Basic functionality is implemented for building required unlockers for input Regular boxes as well as returning a list of output Regular boxes according to input parameter outputRegularBoxesData. Also basic transaction semantic validity is checked here. + + +CarDeclarationTransaction +************************* + +CarDeclarationTransaction extends previously declared AbstractRegularTransaction in next way: public final class CarDeclarationTransaction extends AbstractRegularTransaction +newBoxes() -- new box with newly created car shall be added as well, thus that function shall be overridden as well for adding new CarBox additional to regular boxes. + +SellCarTransaction +****************** + +SellCarTransaction extends previously declared AbstractRegularTransaction in next way: public final class SellCarTransaction extends AbstractRegularTransaction +Similar to CarDeclarationTransaction, newBoxes() function shall also return a new specific box. In our case that new box is CarSellOrderBox. Also due we have specific box to open (CarBox), we also need to add unlocker for CarBox, so unlocker for that CarBox had been added in public List> unlockers() + +BuyCarTransaction +***************** + +Few comments about implementation: +During creation of unlockers in function unlockers() we need to also create a specific unlocker for opening a car sell order. Another newBoxes() function has a bit specific implementation. That function forces to create a new RegularBox as payment for a car in case the car has been sold. Anyway, a new Car box also shall be created according to information in carBuyOrderInfo. + +Extend API: +*********** + + Create a new class CarApi which extends ApplicationApiGroup class, add that new class to Route by it in SimpleAppModule, like described in Custom API manual. In our case it is done in CarRegistryAppModule by +Creating customApiGroups as a list of custom API Groups: +List customApiGroups = new ArrayList<>(); + +Adding created CarApi into customApiGroups: + customApiGroups.add(new CarApi()); + +Binding that custom api group via dependency injection: +bind(new TypeLiteral> () {}) + .annotatedWith(Names.named("CustomApiGroups")) + .toInstance(customApiGroups); + + +Define Car creation transaction. +Defining request class/JSON request body +As input for the transaction we expected: +Regular box id as input for paying fee; +Fee value; +Proposition address which will be recognized as a Car Proposition; +Vehicle identification number of car. So next request class shall be created: +public class CreateCarBoxRequest { + public String vin; + public int year; + public String model; + public String color; + public String proposition; // hex representation of public key proposition + public long fee; + + + // Setters to let Akka jackson JSON library to automatically deserialize the request body. + + public void setVin(String vin) { + this.vin = vin; + } + + public void setYear(int year) { + this.year = year; + } + + public void setModel(String model) { + this.model = model; + } + + public void setColor(String color) { + this.color = color; + } + + public void setProposition(String proposition) { + this.proposition = proposition; + } + + public void setFee(long fee) { + this.fee = fee; + } +} + + +Request class shall have appropriate setters and getters for all class members, also class members' names define structure for related JSON structure according jackson library so next JSON structure is expected to be set: +{ + "vin":"30124", + “year”:1984, + “model”: “Lamborghini” + “color”:”deep black” +"carProposition":"a5b10622d70f094b7276e04608d97c7c699c8700164f78e16fe5e8082f4bb2ac", + "fee": 1, + "boxId": "d59f80b39d24716b4c9a54cfed4bff8e6f76597a7b11761d0d8b7b27ddf8bd3c" +} +Few interesting moments: setter’s input parameter could have differ type than set class member, it’s allow us to do all necessary conversation in setters. + +Define response for Car creation transaction, result of transaction shall be defined by implementing SuccessResponse interface with class members which shall be returned as API response, all members shall have properly set getters, also response class shall have proper annotation @JsonView(Views.Default.class) thus jackson library is able correctly represent response class in JSON format. In our case we expect to return transaction bytes, so response class is next: + +@JsonView(Views.Default.class) +class TxResponse implements SuccessResponse { + public String transactionBytes; + + public TxResponse(String transactionBytes) { + this.transactionBytes = transactionBytes; + } +} + + +Define Car creation transaction itself +private ApiResponse createCar(SidechainNodeView view, CreateCarBoxRequest ent) + +As a first parameter we pass reference to SidechainNodeView, second reference is previously defined class on step 1 for representation of JSON request. + + + + + + + +C. Define request for Car sell order transaction CreateCarSellOrderRequest similar as it was done for Car creation transaction request +Define request class for Car sell order transaction CreateCarSellOrderRequest as it was done for Car creation transaction request: +public class CreateCarSellOrderRequest { + public String carBoxId; // hex representation of box id + public String buyerProposition; // hex representation of public key proposition + public long sellPrice; + public long fee; + + // Setters to let Akka jackson JSON library to automatically deserialize the request body. + + public void setCarBoxId(String carBoxId) { + this.carBoxId = carBoxId; + } + + public void setBuyerProposition(String buyerProposition) { + this.buyerProposition = buyerProposition; + } + + public void setSellPrice(long sellPrice) { + this.sellPrice = sellPrice; + } + + public void setFee(int fee) { + this.fee = fee; + } +} + + + +Define Car Sell order transaction itself +private ApiResponse createCarSellOrder(SidechainNodeView view, CreateCarSellOrderRequest ent) +Required actions are similar as it was done for Create Car transaction. Main idea is a moving Car Box into CarSellOrderBox + +Define Car sell order response +As a result of Car sell order we could still use TxResponse + + + +D. Create AcceptCarSellorder transaction +Specify request as +public class SpendCarSellOrderRequest { + public String carSellOrderId; // hex representation of box id + public long fee; + + // Setters to let Akka jackson JSON library to automatically deserialize the request body. + + public void setCarSellOrderId(String carSellOrderId) { + this.carSellOrderId = carSellOrderId; + } + + public void setFee(long fee) { + this.fee = fee; + } +} +Specify acceptCarSellOrder transaction itself +As a result we still could use TxResponse class +Important part is creation proof for BuyCarTransaction, because we accept car buying then we shall form proof with defining that we buy car: + SellOrderSpendingProof buyerProof = new SellOrderSpendingProof( + buyerSecretOption.get().sign(messageToSign).bytes(), + isSeller +); +Where isSeller is false. + +E. Create cancelCarSellOrder transaction +Specify cancel request as +public class SpendCarSellOrderRequest { + public String carSellOrderId; // hex representation of box id + public long fee; + + // Setters to let Akka jackson JSON library to automatically deserialize the request body. + + public void setCarSellOrderId(String carSellOrderId) { + this.carSellOrderId = carSellOrderId; + } + + public void setFee(long fee) { + this.fee = fee; + } +} +Specify transaction itself. Because we recall our sell order then isSeller parameter during transaction creation is set to false. + From 0ba2894aa1148760a1dbe2542a2913826e9a26cf Mon Sep 17 00:00:00 2001 From: Gustavo Fialho Date: Fri, 7 Aug 2020 11:02:08 +0100 Subject: [PATCH 61/61] Update 08-Car-registry-tutorial.rst --- docs/introduction/08-Car-registry-tutorial.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/introduction/08-Car-registry-tutorial.rst b/docs/introduction/08-Car-registry-tutorial.rst index 84049b9..25e5b47 100644 --- a/docs/introduction/08-Car-registry-tutorial.rst +++ b/docs/introduction/08-Car-registry-tutorial.rst @@ -173,6 +173,7 @@ Implementation of CarBoxData: CarBoxData is implemented according description from ``Custom Box Data Creation`` section as ``public class CarBoxData extends AbstractNoncedBoxData`` with custom data as: :: + private final BigInteger vin; private final int year; private final String model;