P2P Network — Bitcoin

FlowCards: A Declarative Framework for Development of Ergo dApps

FlowCards: A Declarative Framework for Development of Ergo dApps
Introduction
ErgoScript is the smart contract language used by the Ergo blockchain. While it has concise syntax adopted from Scala/Kotlin, it still may seem confusing at first because conceptually ErgoScript is quite different compared to conventional languages which we all know and love. This is because Ergo is a UTXO based blockchain, whereas smart contracts are traditionally associated with account based systems like Ethereum. However, Ergo's transaction model has many advantages over the account based model and with the right approach it can even be significantly easier to develop Ergo contracts than to write and debug Solidity code.
Below we will cover the key aspects of the Ergo contract model which makes it different:
Paradigm
The account model of Ethereum is imperative. This means that the typical task of sending coins from Alice to Bob requires changing the balances in storage as a series of operations. Ergo's UTXO based programming model on the other hand is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain (not changes to be made in the storage state as result of the contract execution).
Scalability
In the account model of Ethereum both storage changes and validity checks are performed on-chain during code execution. In contrast, Ergo transactions are created off-chain and only validation checks are performed on-chain thus reducing the amount of operations performed by every node on the network. In addition, due to immutability of the transaction graph, various optimization strategies are possible to improve throughput of transactions per second in the network. Light verifying nodes are also possible thus further facilitating scalability and accessibility of the network.
Shared state
The account-based model is reliant on shared mutable state which is known to lead to complex semantics (and subtle million dollar bugs) in the context of concurrent/ distributed computation. Ergo's model is based on an immutable graph of transactions. This approach, inherited from Bitcoin, plays well with the concurrent and distributed nature of blockchains and facilitates light trustless clients.
Expressive Power
Ethereum advocated execution of a turing-complete language on the blockchain. It theoretically promised unlimited potential, however in practice severe limitations came to light from excessive blockchain bloat, subtle multi-million dollar bugs, gas costs which limit contract complexity, and other such problems. Ergo on the flip side extends UTXO to enable turing-completeness while limiting the complexity of the ErgoScript language itself. The same expressive power is achieved in a different and more semantically sound way.
With the all of the above points, it should be clear that there are a lot of benefits to the model Ergo is using. In the rest of this article I will introduce you to the concept of FlowCards - a dApp developer component which allows for designing complex Ergo contracts in a declarative and visual way.
From Imperative to Declarative
In the imperative programming model of Ethereum a transaction is a sequence of operations executed by the Ethereum VM. The following Solidity function implements a transfer of tokens from sender to receiver . The transaction starts when sender calls this function on an instance of a contract and ends when the function returns.
// Sends an amount of existing coins from any caller to an address function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); } 
The function first checks the pre-conditions, then updates the storage (i.e. balances) and finally publishes the post-condition as the Sent event. The gas which is consumed by the transaction is sent to the miner as a reward for executing this transaction.
Unlike Ethereum, a transaction in Ergo is a data structure holding a list of input coins which it spends and a list of output coins which it creates preserving the total balances of ERGs and tokens (in which Ergo is similar to Bitcoin).
Turning back to the example above, since Ergo natively supports tokens, therefore for this specific example of sending tokens we don't need to write any code in ErgoScript. Instead we need to create the ‘send’ transaction shown in the following figure, which describes the same token transfer but declaratively.
https://preview.redd.it/id5kjdgn9tv41.png?width=1348&format=png&auto=webp&s=31b937d7ad0af4afe94f4d023e8c90c97c8aed2e
The picture visually describes the following steps, which the network user needs to perform:
  1. Select unspent sender's boxes, containing in total tB >= amount of tokens and B >= txFee + minErg ERGs.
  2. Create an output target box which is protected by the receiver public key with minErg ERGs and amount of T tokens.
  3. Create one fee output protected by the minerFee contract with txFee ERGs.
  4. Create one change output protected by the sender public key, containing B - minErg - txFee ERGs and tB - amount of T tokens.
  5. Create a new transaction, sign it using the sender's secret key and send to the Ergo network.
What is important to understand here is that all of these steps are preformed off-chain (for example using Appkit Transaction API) by the user's application. Ergo network nodes don't need to repeat this transaction creation process, they only need to validate the already formed transaction. ErgoScript contracts are stored in the inputs of the transaction and check spending conditions. The node executes the contracts on-chain when the transaction is validated. The transaction is valid if all of the conditions are satisfied.
Thus, in Ethereum when we “send amount from sender to recipient” we are literally editing balances and updating the storage with a concrete set of commands. This happens on-chain and thus a new transaction is also created on-chain as the result of this process.
In Ergo (as in Bitcoin) transactions are created off-chain and the network nodes only verify them. The effects of the transaction on the blockchain state is that input coins (or Boxes in Ergo's parlance) are removed and output boxes are added to the UTXO set.
In the example above we don't use an ErgoScript contract but instead assume a signature check is used as the spending pre-condition. However in more complex application scenarios we of course need to use ErgoScript which is what we are going to discuss next.
From Changing State to Checking Context
In the send function example we first checked the pre-condition (require(amount <= balances[msg.sender],...) ) and then changed the state (i.e. update balances balances[msg.sender] -= amount ). This is typical in Ethereum transactions. Before we change anything we need to check if it is valid to do so.
In Ergo, as we discussed previously, the state (i.e. UTXO set of boxes) is changed implicitly when a valid transaction is included in a block. Thus we only need to check the pre-conditions before the transaction can be added to the block. This is what ErgoScript contracts do.
It is not possible to “change the state” in ErgoScript because it is a language to check pre-conditions for spending coins. ErgoScript is a purely functional language without side effects that operates on immutable data values. This means all the inputs, outputs and other transaction parameters available in a script are immutable. This, among other things, makes ErgoScript a very simple language that is easy to learn and safe to use. Similar to Bitcoin, each input box contains a script, which should return the true value in order to 1) allow spending of the box (i.e. removing from the UTXO set) and 2) adding the transaction to the block.
If we are being pedantic, it is therefore incorrect (strictly speaking) to think of ErgoScript as the language of Ergo contracts, because it is the language of propositions (logical predicates, formulas, etc.) which protect boxes from “illegal” spending. Unlike Bitcoin, in Ergo the whole transaction and a part of the current blockchain context is available to every script. Therefore each script may check which outputs are created by the transaction, their ERG and token amounts (we will use this capability in our example DEX contracts), current block number etc.
In ErgoScript you define the conditions of whether changes (i.e. coin spending) are allowed to happen in a given context. This is in contrast to programming the changes imperatively in the code of a contract.
While Ergo's transaction model unlocks a whole range of applications like (DEX, DeFi Apps, LETS, etc), designing contracts as pre-conditions for coin spending (or guarding scripts) directly is not intuitive. In the next sections we will consider a useful graphical notation to design contracts declaratively using FlowCard Diagrams, which is a visual representation of executable components (FlowCards).
FlowCards aim to radically simplify dApp development on the Ergo platform by providing a high-level declarative language, execution runtime, storage format and a graphical notation.
We will start with a high level of diagrams and go down to FlowCard specification.
FlowCard Diagrams
The idea behind FlowCard diagrams is based on the following observations: 1) An Ergo box is immutable and can only be spent in the transaction which uses it as an input. 2) We therefore can draw a flow of boxes through transactions, so that boxes flowing in to the transaction are spent and those flowing out are created and added to the UTXO. 3) A transaction from this perspective is simply a transformer of old boxes to the new ones preserving the balances of ERGs and tokens involved.
The following figure shows the main elements of the Ergo transaction we've already seen previously (now under the name of FlowCard Diagram).
https://preview.redd.it/9kcxl11o9tv41.png?width=1304&format=png&auto=webp&s=378a7f50769292ca94de35ff597dc1a44af56d14
There is a strictly defined meaning (semantics) behind every element of the diagram, so that the diagram is a visual representation (or a view) of the underlying executable component (called FlowCard).
The FlowCard can be used as a reusable component of an Ergo dApp to create and initiate the transaction on the Ergo blockchain. We will discuss this in the coming sections.
Now let's look at the individual pieces of the FlowCard diagram one by one.
  1. Name and Parameters
Each flow card is given a name and a list of typed parameters. This is similar to a template with parameters. In the above figure we can see the Send flow card which has five parameters. The parameters are used in the specification.
  1. Contract Wallet
This is a key element of the flow card. Every box has a guarding script. Often it is the script that checks a signature against a public key. This script is trivial in ErgoScript and is defined like the def pk(pubkey: Address) = { pubkey } template where pubkey is a parameter of the type Address . In the figure, the script template is applied to the parameter pk(sender) and thus a concrete wallet contract is obtained. Therefore pk(sender) and pk(receiver) yield different scripts and represent different wallets on the diagram, even though they use the same template.
Contract Wallet contains a set of all UTXO boxes which have a given script derived from the given script template using flow card parameters. For example, in the figure, the template is pk and parameter pubkey is substituted with the `sender’ flow card parameter.
  1. Contract
Even though a contract is a property of a box, on the diagram we group the boxes by their contracts, therefore it looks like the boxes belong to the contracts, rather than the contracts belong to the boxes. In the example, we have three instantiated contracts pk(sender) , pk(receiver) and minerFee . Note, that pk(sender) is the instantiation of the pk template with the concrete parameter sender and minerFee is the instantiation of the pre-defined contract which protects the miner reward boxes.
  1. Box name
In the diagram we can give each box a name. Besides readability of the diagram, we also use the name as a synonym of a more complex indexed access to the box in the contract. For example, change is the name of the box, which can also be used in the ErgoScript conditions instead of OUTPUTS(2) . We also use box names to associate spending conditions with the boxes.
  1. Boxes in the wallet
In the diagram, we show boxes (darker rectangles) as belonging to the contract wallets (lighter rectangles). Each such box rectangle is connected with a grey transaction rectangle by either orange or green arrows or both. An output box (with an incoming green arrow) may include many lines of text where each line specifies a condition which should be checked as part of the transaction. The first line specifies the condition on the amount of ERG which should be placed in the box. Other lines may take one of the following forms:
  1. amount: TOKEN - the box should contain the given amount of the given TOKEN
  2. R == value - the box should contain the given value of the given register R
  3. boxName ? condition - the box named boxName should check condition in its script.
We discuss these conditions in the sections below.
  1. Amount of ERGs in the box
Each box should store a minimum amount of ERGs. This is checked when the creating transaction is validated. In the diagram the amount of ERGs is always shown as the first line (e.g. B: ERG or B - minErg - txFee ). The value type ascription B: ERG is optional and may be used for readability. When the value is given as a formula, then this formula should be respected by the transaction which creates the box.
It is important to understand that variables like amount and txFee are not named properties of the boxes. They are parameters of the whole diagram and representing some amounts. Or put it another way, they are shared parameters between transactions (e.g. Sell Order and Swap transactions from DEX example below share the tAmt parameter). So the same name is tied to the same value throughout the diagram (this is where the tooling would help a lot). However, when it comes to on-chain validation of those values, only explicit conditions which are marked with ? are transformed to ErgoScript. At the same time, all other conditions are ensured off-chain during transaction building (for example in an application using Appkit API) and transaction validation when it is added to the blockchain.
  1. Amount of T token
A box can store values of many tokens. The tokens on the diagram are named and a value variable may be associated with the token T using value: T expression. The value may be given by formula. If the formula is prefixed with a box name like boxName ? formula , then it is should also be checked in the guarding script of the boxName box. This additional specification is very convenient because 1) it allows to validate the visual design automatically, and 2) the conditions specified in the boxes of a diagram are enough to synthesize the necessary guarding scripts. (more about this below at “From Diagrams To ErgoScript Contracts”)
  1. Tx Inputs
Inputs are connected to the corresponding transaction by orange arrows. An input arrow may have a label of the following forms:
  1. [email protected] - optional name with an index i.e. [email protected] or u/2 . This is a property of the target endpoint of the arrow. The name is used in conditions of related boxes and the index is the position of the corresponding box in the INPUTS collection of the transaction.
  2. !action - is a property of the source of the arrow and gives a name for an alternative spending path of the box (we will see this in DEX example)
Because of alternative spending paths, a box may have many outgoing orange arrows, in which case they should be labeled with different actions.
  1. Transaction
A transaction spends input boxes and creates output boxes. The input boxes are given by the orange arrows and the labels are expected to put inputs at the right indexes in INPUTS collection. The output boxes are given by the green arrows. Each transaction should preserve a strict balance of ERG values (sum of inputs == sum of outputs) and for each token the sum of inputs >= the sum of outputs. The design diagram requires an explicit specification of the ERG and token values for all of the output boxes to avoid implicit errors and ensure better readability.
  1. Tx Outputs
Outputs are connected to the corresponding transaction by green arrows. An output arrow may have a label of the following [email protected] , where an optional name is accompanied with an index i.e. [email protected] or u/2 . This is a property of the source endpoint of the arrow. The name is used in conditions of the related boxes and the index is the position of the corresponding box in the OUTPUTS collection of the transaction.
Example: Decentralized Exchange (DEX)
Now let's use the above described notation to design a FlowCard for a DEX dApp. It is simple enough yet also illustrates all of the key features of FlowCard diagrams which we've introduced in the previous section.
The dApp scenario is shown in the figure below: There are three participants (buyer, seller and DEX) of the DEX dApp and five different transaction types, which are created by participants. The buyer wants to swap ergAmt of ERGs for tAmt of TID tokens (or vice versa, the seller wants to sell TID tokens for ERGs, who sends the order first doesn't matter). Both the buyer and the seller can cancel their orders any time. The DEX off-chain matching service can find matching orders and create the Swap transaction to complete the exchange.
The following diagram fully (and formally) specifies all of the five transactions that must be created off-chain by the DEX dApp. It also specifies all of the spending conditions that should be verified on-chain.

https://preview.redd.it/fnt5f4qp9tv41.png?width=1614&format=png&auto=webp&s=34f145f9a6d622454906857e645def2faba057bd
Let's discuss the FlowCard diagram and the logic of each transaction in details:
Buy Order Transaction
A buyer creates a Buy Order transaction. The transaction spends E amount of ERGs (which we will write E: ERG ) from one or more boxes in the pk(buyer) wallet. The transaction creates a bid box with ergAmt: ERG protected by the buyOrder script. The buyOrder script is synthesized from the specification (see below at “From Diagrams To ErgoScript Contracts”) either manually or automatically by a tool. Even though we don't need to define the buyOrder script explicitly during designing, at run time the bid box should contain the buyOrder script as the guarding proposition (which checks the box spending conditions), otherwise the conditions specified in the diagram will not be checked.
The change box is created to make the input and output sums of the transaction balanced. The transaction fee box is omitted because it can be added automatically by the tools. In practice, however, the designer can add the fee box explicitly to the a diagram. It covers the cases of more complex transactions (like Swap) where there are many ways to pay the transaction fee.
Cancel Buy, Cancel Sell Transactions
At any time, the buyer can cancel the order by sending CancelBuy transaction. The transaction should satisfy the guarding buyOrder contract which protects the bid box. As you can see on the diagram, both the Cancel and the Swap transactions can spend the bid box. When a box has spending alternatives (or spending paths) then each alternative is identified by a unique name prefixed with ! (!cancel and !swap for the bid box). Each alternative path has specific spending conditions. In our example, when the Cancel Buy transaction spends the bid box the ?buyer condition should be satisfied, which we read as “the signature for the buyer address should be presented in the transaction”. Therefore, only buyer can cancel the buy order. This “signature” condition is only required for the !cancel alternative spending path and not required for !swap .
Sell Order Transaction
The Sell Order transaction is similar to the BuyOrder in that it deals with tokens in addition to ERGs. The transaction spends E: ERG and T: TID tokens from seller's wallet (specified as pk(seller) contract). The two outputs are ask and change . The change is a standard box to balance transaction. The ask box keeps tAmt: TID tokens for the exchange and minErg: ERG - the minimum amount of ERGs required in every box.
Swap Transaction
This is a key transaction in the DEX dApp scenario. The transaction has several spending conditions on the input boxes and those conditions are included in the buyOrder and sellOrder scripts (which are verified when the transaction is added to the blockchain). However, on the diagram those conditions are not specified in the bid and ask boxes, they are instead defined in the output boxes of the transaction.
This is a convention for improved usability because most of the conditions relate to the properties of the output boxes. We could specify those properties in the bid box, but then we would have to use more complex expressions.
Let's consider the output created by the arrow labeled with [email protected] . This label tells us that the output is at the index 0 in the OUTPUTS collection of the transaction and that in the diagram we can refer to this box by the buyerOut name. Thus we can label both the box itself and the arrow to give the box a name.
The conditions shown in the buyerOut box have the form bid ? condition , which means they should be verified on-chain in order to spend the bid box. The conditions have the following meaning:
  • tAmt: TID requires the box to have tAmt amount of TID token
  • R4 == bid.id requires R4 register in the box to be equal to id of the bid box.
  • script == buyer requires the buyerOut box to have the script of the wallet where it is located on the diagram, i.e. pk(buyer)
Similar properties are added to the sellerOut box, which is specified to be at index 1 and the name is given to it using the label on the box itself, rather than on the arrow.
The Swap transaction spends two boxes bid and ask using the !swap spending path on both, however unlike !cancel the conditions on the path are not specified. This is where the bid ? and ask ? prefixes come into play. They are used so that the conditions listed in the buyerOut and sellerOut boxes are moved to the !swap spending path of the bid and ask boxes correspondingly.
If you look at the conditions of the output boxes, you will see that they exactly specify the swap of values between seller's and buyer's wallets. The buyer gets the necessary amount of TID token and seller gets the corresponding amount of ERGs. The Swap transaction is created when there are two matching boxes with buyOrder and sellOrder contracts.
From Diagrams To ErgoScript Contracts
What is interesting about FlowCard specifications is that we can use them to automatically generate the necessary ErgoTree scripts. With the appropriate tooling support this can be done automatically, but with the lack of thereof, it can be done manually. Thus, the FlowCard allows us to capture and visually represent all of the design choices and semantic details of an Ergo dApp.
What we are going to do next is to mechanically create the buyOrder contract from the information given in the DEX flow card.
Recall that each script is a proposition (boolean valued expression) which should evaluate to true to allow spending of the box. When we have many conditions to be met at the same time we can combine them in a logical formula using the AND binary operation, and if we have alternatives (not necessarily exclusive) we can put them into the OR operation.
The buyOrder box has the alternative spending paths !cancel and !swap . Thus the ErgoScript code should have OR operation with two arguments - one for each spending path.
/** buyOrder contract */ { val cancelCondition = {} val swapCondition = {} cancelCondition || swapCondition } 
The formula for the cancelCondition expression is given in the !cancel spending path of the buyOrder box. We can directly include it in the script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = {} cancelCondition || swapCondition } 
For the !swap spending path of the buyOrder box the conditions are specified in the buyerOut output box of the Swap transaction. If we simply include them in the swapCondition then we get a syntactically incorrect script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = { tAmt: TID && R4 == bid.id && @contract } cancelCondition || swapCondition } 
We can however translate the conditions from the diagram syntax to ErgoScript expressions using the following simple rules
  1. [email protected] ==> val buyerOut = OUTPUTS(0)
  2. tAmt: TID ==> tid._2 == tAmt where tid = buyerOut.tokens(TID)
  3. R4 == bid.id ==> R4 == SELF.id where R4 = buyerOut.R4[Coll[Byte]].get
  4. script == buyer ==> buyerOut.propositionBytes == buyer.propBytes
Note, in the diagram TID represents a token id, but ErgoScript doesn't have access to the tokens by the ids so we cannot write tokens.getByKey(TID) . For this reason, when the diagram is translated into ErgoScript, TID becomes a named constant of the index in tokens collection of the box. The concrete value of the constant is assigned when the BuyOrder transaction with the buyOrder box is created. The correspondence and consistency between the actual tokenId, the TID constant and the actual tokens of the buyerOut box is ensured by the off-chain application code, which is completely possible since all of the transactions are created by the application using FlowCard as a guiding specification. This may sound too complicated, but this is part of the translation from diagram specification to actual executable application code, most of which can be automated.
After the transformation we can obtain a correct script which checks all the required preconditions for spending the buyOrder box.
/** buyOrder contract */ def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long) { val cancelCondition: SigmaProp = { buyer } // verify buyer's sig (ProveDlog) val swapCondition = OUTPUTS.size > 0 && { // securing OUTPUTS access val buyerOut = OUTPUTS(0) // from [email protected] buyerOut.tokens.size > TID && { // securing tokens access val tid = buyerOut.tokens(TID) val regR4 = buyerOut.R4[Coll[Byte]] regR4.isDefined && { // securing R4 access val R4 = regR4.get tid._2 == tAmt && // from tAmt: TID R4 == SELF.id && // from R4 == bid.id buyerOut.propositionBytes == buyer.propBytes // from script == buyer } } } cancelCondition || swapCondition } 
A similar script for the sellOrder box can be obtained using the same translation rules. With the help of the tooling the code of contracts can be mechanically generated from the diagram specification.
Conclusions
Declarative programming models have already won the battle against imperative programming in many application domains like Big Data, Stream Processing, Deep Learning, Databases, etc. Ergo is pioneering the declarative model of dApp development as a better and safer alternative to the now popular imperative model of smart contracts.
The concept of FlowCard shifts the focus from writing ErgoScript contracts to the overall flow of values (hence the name), in such a way, that ErgoScript can always be generated from them. You will never need to look at the ErgoScript code once the tooling is in place.
Here are the possible next steps for future work:
  1. Storage format for FlowCard Spec and the corresponding EIP standardized file format (Json/XML/Protobuf). This will allow various tools (Diagram Editor, Runtime, dApps etc) to create and use *.flowcard files.
  2. FlowCard Viewer, which can generate the diagrams from *.flowcard files.
  3. FlowCard Runtime, which can run *.flowcard files, create and send transactions to Ergo network.
  4. FlowCard Designer Tool, which can simplify development of complex diagrams . This will make designing and validation of Ergo contracts a pleasant experience, more like drawing rather than coding. In addition, the correctness of the whole dApp scenario can be verified and controlled by the tooling.
submitted by Guilty_Pea to CryptoCurrencies [link] [comments]

FlowCards: A Declarative Framework for Development of Ergo dApps

FlowCards: A Declarative Framework for Development of Ergo dApps
Introduction
ErgoScript is the smart contract language used by the Ergo blockchain. While it has concise syntax adopted from Scala/Kotlin, it still may seem confusing at first because conceptually ErgoScript is quite different compared to conventional languages which we all know and love. This is because Ergo is a UTXO based blockchain, whereas smart contracts are traditionally associated with account based systems like Ethereum. However, Ergo's transaction model has many advantages over the account based model and with the right approach it can even be significantly easier to develop Ergo contracts than to write and debug Solidity code.
Below we will cover the key aspects of the Ergo contract model which makes it different:
Paradigm
The account model of Ethereum is imperative. This means that the typical task of sending coins from Alice to Bob requires changing the balances in storage as a series of operations. Ergo's UTXO based programming model on the other hand is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain (not changes to be made in the storage state as result of the contract execution).
Scalability
In the account model of Ethereum both storage changes and validity checks are performed on-chain during code execution. In contrast, Ergo transactions are created off-chain and only validation checks are performed on-chain thus reducing the amount of operations performed by every node on the network. In addition, due to immutability of the transaction graph, various optimization strategies are possible to improve throughput of transactions per second in the network. Light verifying nodes are also possible thus further facilitating scalability and accessibility of the network.
Shared state
The account-based model is reliant on shared mutable state which is known to lead to complex semantics (and subtle million dollar bugs) in the context of concurrent/ distributed computation. Ergo's model is based on an immutable graph of transactions. This approach, inherited from Bitcoin, plays well with the concurrent and distributed nature of blockchains and facilitates light trustless clients.
Expressive Power
Ethereum advocated execution of a turing-complete language on the blockchain. It theoretically promised unlimited potential, however in practice severe limitations came to light from excessive blockchain bloat, subtle multi-million dollar bugs, gas costs which limit contract complexity, and other such problems. Ergo on the flip side extends UTXO to enable turing-completeness while limiting the complexity of the ErgoScript language itself. The same expressive power is achieved in a different and more semantically sound way.
With the all of the above points, it should be clear that there are a lot of benefits to the model Ergo is using. In the rest of this article I will introduce you to the concept of FlowCards - a dApp developer component which allows for designing complex Ergo contracts in a declarative and visual way.

From Imperative to Declarative

In the imperative programming model of Ethereum a transaction is a sequence of operations executed by the Ethereum VM. The following Solidity function implements a transfer of tokens from sender to receiver . The transaction starts when sender calls this function on an instance of a contract and ends when the function returns.
// Sends an amount of existing coins from any caller to an address function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); } 
The function first checks the pre-conditions, then updates the storage (i.e. balances) and finally publishes the post-condition as the Sent event. The gas which is consumed by the transaction is sent to the miner as a reward for executing this transaction.
Unlike Ethereum, a transaction in Ergo is a data structure holding a list of input coins which it spends and a list of output coins which it creates preserving the total balances of ERGs and tokens (in which Ergo is similar to Bitcoin).
Turning back to the example above, since Ergo natively supports tokens, therefore for this specific example of sending tokens we don't need to write any code in ErgoScript. Instead we need to create the ‘send’ transaction shown in the following figure, which describes the same token transfer but declaratively.
https://preview.redd.it/sxs3kesvrsv41.png?width=1348&format=png&auto=webp&s=582382bc26912ff79114d831d937d94b6988e69f
The picture visually describes the following steps, which the network user needs to perform:
  1. Select unspent sender's boxes, containing in total tB >= amount of tokens and B >= txFee + minErg ERGs.
  2. Create an output target box which is protected by the receiver public key with minErg ERGs and amount of T tokens.
  3. Create one fee output protected by the minerFee contract with txFee ERGs.
  4. Create one change output protected by the sender public key, containing B - minErg - txFee ERGs and tB - amount of T tokens.
  5. Create a new transaction, sign it using the sender's secret key and send to the Ergo network.
What is important to understand here is that all of these steps are preformed off-chain (for example using Appkit Transaction API) by the user's application. Ergo network nodes don't need to repeat this transaction creation process, they only need to validate the already formed transaction. ErgoScript contracts are stored in the inputs of the transaction and check spending conditions. The node executes the contracts on-chain when the transaction is validated. The transaction is valid if all of the conditions are satisfied.
Thus, in Ethereum when we “send amount from sender to recipient” we are literally editing balances and updating the storage with a concrete set of commands. This happens on-chain and thus a new transaction is also created on-chain as the result of this process.
In Ergo (as in Bitcoin) transactions are created off-chain and the network nodes only verify them. The effects of the transaction on the blockchain state is that input coins (or Boxes in Ergo's parlance) are removed and output boxes are added to the UTXO set.
In the example above we don't use an ErgoScript contract but instead assume a signature check is used as the spending pre-condition. However in more complex application scenarios we of course need to use ErgoScript which is what we are going to discuss next.

From Changing State to Checking Context

In the send function example we first checked the pre-condition (require(amount <= balances[msg.sender],...) ) and then changed the state (i.e. update balances balances[msg.sender] -= amount ). This is typical in Ethereum transactions. Before we change anything we need to check if it is valid to do so.
In Ergo, as we discussed previously, the state (i.e. UTXO set of boxes) is changed implicitly when a valid transaction is included in a block. Thus we only need to check the pre-conditions before the transaction can be added to the block. This is what ErgoScript contracts do.
It is not possible to “change the state” in ErgoScript because it is a language to check pre-conditions for spending coins. ErgoScript is a purely functional language without side effects that operates on immutable data values. This means all the inputs, outputs and other transaction parameters available in a script are immutable. This, among other things, makes ErgoScript a very simple language that is easy to learn and safe to use. Similar to Bitcoin, each input box contains a script, which should return the true value in order to 1) allow spending of the box (i.e. removing from the UTXO set) and 2) adding the transaction to the block.
If we are being pedantic, it is therefore incorrect (strictly speaking) to think of ErgoScript as the language of Ergo contracts, because it is the language of propositions (logical predicates, formulas, etc.) which protect boxes from “illegal” spending. Unlike Bitcoin, in Ergo the whole transaction and a part of the current blockchain context is available to every script. Therefore each script may check which outputs are created by the transaction, their ERG and token amounts (we will use this capability in our example DEX contracts), current block number etc.
In ErgoScript you define the conditions of whether changes (i.e. coin spending) are allowed to happen in a given context. This is in contrast to programming the changes imperatively in the code of a contract.
While Ergo's transaction model unlocks a whole range of applications like (DEX, DeFi Apps, LETS, etc), designing contracts as pre-conditions for coin spending (or guarding scripts) directly is not intuitive. In the next sections we will consider a useful graphical notation to design contracts declaratively using FlowCard Diagrams, which is a visual representation of executable components (FlowCards).
FlowCards aim to radically simplify dApp development on the Ergo platform by providing a high-level declarative language, execution runtime, storage format and a graphical notation.
We will start with a high level of diagrams and go down to FlowCard specification.

FlowCard Diagrams

The idea behind FlowCard diagrams is based on the following observations: 1) An Ergo box is immutable and can only be spent in the transaction which uses it as an input. 2) We therefore can draw a flow of boxes through transactions, so that boxes flowing in to the transaction are spent and those flowing out are created and added to the UTXO. 3) A transaction from this perspective is simply a transformer of old boxes to the new ones preserving the balances of ERGs and tokens involved.
The following figure shows the main elements of the Ergo transaction we've already seen previously (now under the name of FlowCard Diagram).
https://preview.redd.it/06aqkcd1ssv41.png?width=1304&format=png&auto=webp&s=106eda730e0526919aabd5af9596b97e45b69777
There is a strictly defined meaning (semantics) behind every element of the diagram, so that the diagram is a visual representation (or a view) of the underlying executable component (called FlowCard).
The FlowCard can be used as a reusable component of an Ergo dApp to create and initiate the transaction on the Ergo blockchain. We will discuss this in the coming sections.
Now let's look at the individual pieces of the FlowCard diagram one by one.
1. Name and Parameters
Each flow card is given a name and a list of typed parameters. This is similar to a template with parameters. In the above figure we can see the Send flow card which has five parameters. The parameters are used in the specification.
2. Contract Wallet
This is a key element of the flow card. Every box has a guarding script. Often it is the script that checks a signature against a public key. This script is trivial in ErgoScript and is defined like the def pk(pubkey: Address) = { pubkey } template where pubkey is a parameter of the type Address . In the figure, the script template is applied to the parameter pk(sender) and thus a concrete wallet contract is obtained. Therefore pk(sender) and pk(receiver) yield different scripts and represent different wallets on the diagram, even though they use the same template.
Contract Wallet contains a set of all UTXO boxes which have a given script derived from the given script template using flow card parameters. For example, in the figure, the template is pk and parameter pubkey is substituted with the `sender’ flow card parameter.
3. Contract
Even though a contract is a property of a box, on the diagram we group the boxes by their contracts, therefore it looks like the boxes belong to the contracts, rather than the contracts belong to the boxes. In the example, we have three instantiated contracts pk(sender) , pk(receiver) and minerFee . Note, that pk(sender) is the instantiation of the pk template with the concrete parameter sender and minerFee is the instantiation of the pre-defined contract which protects the miner reward boxes.
4. Box name
In the diagram we can give each box a name. Besides readability of the diagram, we also use the name as a synonym of a more complex indexed access to the box in the contract. For example, change is the name of the box, which can also be used in the ErgoScript conditions instead of OUTPUTS(2) . We also use box names to associate spending conditions with the boxes.
5. Boxes in the wallet
In the diagram, we show boxes (darker rectangles) as belonging to the contract wallets (lighter rectangles). Each such box rectangle is connected with a grey transaction rectangle by either orange or green arrows or both. An output box (with an incoming green arrow) may include many lines of text where each line specifies a condition which should be checked as part of the transaction. The first line specifies the condition on the amount of ERG which should be placed in the box. Other lines may take one of the following forms:
  1. amount: TOKEN - the box should contain the given amount of the given TOKEN
  2. R == value - the box should contain the given value of the given register R
  3. boxName ? condition - the box named boxName should check condition in its script.
We discuss these conditions in the sections below.
6. Amount of ERGs in the box
Each box should store a minimum amount of ERGs. This is checked when the creating transaction is validated. In the diagram the amount of ERGs is always shown as the first line (e.g. B: ERG or B - minErg - txFee ). The value type ascription B: ERG is optional and may be used for readability. When the value is given as a formula, then this formula should be respected by the transaction which creates the box.
It is important to understand that variables like amount and txFee are not named properties of the boxes. They are parameters of the whole diagram and representing some amounts. Or put it another way, they are shared parameters between transactions (e.g. Sell Order and Swap transactions from DEX example below share the tAmt parameter). So the same name is tied to the same value throughout the diagram (this is where the tooling would help a lot). However, when it comes to on-chain validation of those values, only explicit conditions which are marked with ? are transformed to ErgoScript. At the same time, all other conditions are ensured off-chain during transaction building (for example in an application using Appkit API) and transaction validation when it is added to the blockchain.
7. Amount of T token
A box can store values of many tokens. The tokens on the diagram are named and a value variable may be associated with the token T using value: T expression. The value may be given by formula. If the formula is prefixed with a box name like boxName ? formula , then it is should also be checked in the guarding script of the boxName box. This additional specification is very convenient because 1) it allows to validate the visual design automatically, and 2) the conditions specified in the boxes of a diagram are enough to synthesize the necessary guarding scripts. (more about this below at “From Diagrams To ErgoScript Contracts”)
8. Tx Inputs
Inputs are connected to the corresponding transaction by orange arrows. An input arrow may have a label of the following forms:
  1. [email protected] - optional name with an index i.e. [email protected] or u/2 . This is a property of the target endpoint of the arrow. The name is used in conditions of related boxes and the index is the position of the corresponding box in the INPUTS collection of the transaction.
  2. !action - is a property of the source of the arrow and gives a name for an alternative spending path of the box (we will see this in DEX example)
Because of alternative spending paths, a box may have many outgoing orange arrows, in which case they should be labeled with different actions.
9. Transaction
A transaction spends input boxes and creates output boxes. The input boxes are given by the orange arrows and the labels are expected to put inputs at the right indexes in INPUTS collection. The output boxes are given by the green arrows. Each transaction should preserve a strict balance of ERG values (sum of inputs == sum of outputs) and for each token the sum of inputs >= the sum of outputs. The design diagram requires an explicit specification of the ERG and token values for all of the output boxes to avoid implicit errors and ensure better readability.
10. Tx Outputs
Outputs are connected to the corresponding transaction by green arrows. An output arrow may have a label of the following [email protected] , where an optional name is accompanied with an index i.e. [email protected] or u/2 . This is a property of the source endpoint of the arrow. The name is used in conditions of the related boxes and the index is the position of the corresponding box in the OUTPUTS collection of the transaction.

Example: Decentralized Exchange (DEX)

Now let's use the above described notation to design a FlowCard for a DEX dApp. It is simple enough yet also illustrates all of the key features of FlowCard diagrams which we've introduced in the previous section.
The dApp scenario is shown in the figure below: There are three participants (buyer, seller and DEX) of the DEX dApp and five different transaction types, which are created by participants. The buyer wants to swap ergAmt of ERGs for tAmt of TID tokens (or vice versa, the seller wants to sell TID tokens for ERGs, who sends the order first doesn't matter). Both the buyer and the seller can cancel their orders any time. The DEX off-chain matching service can find matching orders and create the Swap transaction to complete the exchange.
The following diagram fully (and formally) specifies all of the five transactions that must be created off-chain by the DEX dApp. It also specifies all of the spending conditions that should be verified on-chain.

https://preview.redd.it/piogz0v9ssv41.png?width=1614&format=png&auto=webp&s=e1b503a635ad3d138ef91e2f0c3b726e78958646
Let's discuss the FlowCard diagram and the logic of each transaction in details:
Buy Order Transaction
A buyer creates a Buy Order transaction. The transaction spends E amount of ERGs (which we will write E: ERG ) from one or more boxes in the pk(buyer) wallet. The transaction creates a bid box with ergAmt: ERG protected by the buyOrder script. The buyOrder script is synthesized from the specification (see below at “From Diagrams To ErgoScript Contracts”) either manually or automatically by a tool. Even though we don't need to define the buyOrder script explicitly during designing, at run time the bid box should contain the buyOrder script as the guarding proposition (which checks the box spending conditions), otherwise the conditions specified in the diagram will not be checked.
The change box is created to make the input and output sums of the transaction balanced. The transaction fee box is omitted because it can be added automatically by the tools. In practice, however, the designer can add the fee box explicitly to the a diagram. It covers the cases of more complex transactions (like Swap) where there are many ways to pay the transaction fee.
Cancel Buy, Cancel Sell Transactions
At any time, the buyer can cancel the order by sending CancelBuy transaction. The transaction should satisfy the guarding buyOrder contract which protects the bid box. As you can see on the diagram, both the Cancel and the Swap transactions can spend the bid box. When a box has spending alternatives (or spending paths) then each alternative is identified by a unique name prefixed with ! (!cancel and !swap for the bid box). Each alternative path has specific spending conditions. In our example, when the Cancel Buy transaction spends the bid box the ?buyer condition should be satisfied, which we read as “the signature for the buyer address should be presented in the transaction”. Therefore, only buyer can cancel the buy order. This “signature” condition is only required for the !cancel alternative spending path and not required for !swap .
Sell Order Transaction
The Sell Order transaction is similar to the BuyOrder in that it deals with tokens in addition to ERGs. The transaction spends E: ERG and T: TID tokens from seller's wallet (specified as pk(seller) contract). The two outputs are ask and change . The change is a standard box to balance transaction. The ask box keeps tAmt: TID tokens for the exchange and minErg: ERG - the minimum amount of ERGs required in every box.
Swap Transaction
This is a key transaction in the DEX dApp scenario. The transaction has several spending conditions on the input boxes and those conditions are included in the buyOrder and sellOrder scripts (which are verified when the transaction is added to the blockchain). However, on the diagram those conditions are not specified in the bid and ask boxes, they are instead defined in the output boxes of the transaction.
This is a convention for improved usability because most of the conditions relate to the properties of the output boxes. We could specify those properties in the bid box, but then we would have to use more complex expressions.
Let's consider the output created by the arrow labeled with [email protected] . This label tells us that the output is at the index 0 in the OUTPUTS collection of the transaction and that in the diagram we can refer to this box by the buyerOut name. Thus we can label both the box itself and the arrow to give the box a name.
The conditions shown in the buyerOut box have the form bid ? condition , which means they should be verified on-chain in order to spend the bid box. The conditions have the following meaning:
  • tAmt: TID requires the box to have tAmt amount of TID token
  • R4 == bid.id requires R4 register in the box to be equal to id of the bid box.
  • script == buyer requires the buyerOut box to have the script of the wallet where it is located on the diagram, i.e. pk(buyer)
Similar properties are added to the sellerOut box, which is specified to be at index 1 and the name is given to it using the label on the box itself, rather than on the arrow.
The Swap transaction spends two boxes bid and ask using the !swap spending path on both, however unlike !cancel the conditions on the path are not specified. This is where the bid ? and ask ? prefixes come into play. They are used so that the conditions listed in the buyerOut and sellerOut boxes are moved to the !swap spending path of the bid and ask boxes correspondingly.
If you look at the conditions of the output boxes, you will see that they exactly specify the swap of values between seller's and buyer's wallets. The buyer gets the necessary amount of TID token and seller gets the corresponding amount of ERGs. The Swap transaction is created when there are two matching boxes with buyOrder and sellOrder contracts.

From Diagrams To ErgoScript Contracts

What is interesting about FlowCard specifications is that we can use them to automatically generate the necessary ErgoTree scripts. With the appropriate tooling support this can be done automatically, but with the lack of thereof, it can be done manually. Thus, the FlowCard allows us to capture and visually represent all of the design choices and semantic details of an Ergo dApp.
What we are going to do next is to mechanically create the buyOrder contract from the information given in the DEX flow card.
Recall that each script is a proposition (boolean valued expression) which should evaluate to true to allow spending of the box. When we have many conditions to be met at the same time we can combine them in a logical formula using the AND binary operation, and if we have alternatives (not necessarily exclusive) we can put them into the OR operation.
The buyOrder box has the alternative spending paths !cancel and !swap . Thus the ErgoScript code should have OR operation with two arguments - one for each spending path.
/** buyOrder contract */ { val cancelCondition = {} val swapCondition = {} cancelCondition || swapCondition } 
The formula for the cancelCondition expression is given in the !cancel spending path of the buyOrder box. We can directly include it in the script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = {} cancelCondition || swapCondition } 
For the !swap spending path of the buyOrder box the conditions are specified in the buyerOut output box of the Swap transaction. If we simply include them in the swapCondition then we get a syntactically incorrect script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = { tAmt: TID && R4 == bid.id && @contract } cancelCondition || swapCondition } 
We can however translate the conditions from the diagram syntax to ErgoScript expressions using the following simple rules
  1. [email protected] ==> val buyerOut = OUTPUTS(0)
  2. tAmt: TID ==> tid._2 == tAmt where tid = buyerOut.tokens(TID)
  3. R4 == bid.id ==> R4 == SELF.id where R4 = buyerOut.R4[Coll[Byte]].get
  4. script == buyer ==> buyerOut.propositionBytes == buyer.propBytes
Note, in the diagram TID represents a token id, but ErgoScript doesn't have access to the tokens by the ids so we cannot write tokens.getByKey(TID) . For this reason, when the diagram is translated into ErgoScript, TID becomes a named constant of the index in tokens collection of the box. The concrete value of the constant is assigned when the BuyOrder transaction with the buyOrder box is created. The correspondence and consistency between the actual tokenId, the TID constant and the actual tokens of the buyerOut box is ensured by the off-chain application code, which is completely possible since all of the transactions are created by the application using FlowCard as a guiding specification. This may sound too complicated, but this is part of the translation from diagram specification to actual executable application code, most of which can be automated.
After the transformation we can obtain a correct script which checks all the required preconditions for spending the buyOrder box.
/** buyOrder contract */ def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long) { val cancelCondition: SigmaProp = { buyer } // verify buyer's sig (ProveDlog) val swapCondition = OUTPUTS.size > 0 && { // securing OUTPUTS access val buyerOut = OUTPUTS(0) // from [email protected] buyerOut.tokens.size > TID && { // securing tokens access val tid = buyerOut.tokens(TID) val regR4 = buyerOut.R4[Coll[Byte]] regR4.isDefined && { // securing R4 access val R4 = regR4.get tid._2 == tAmt && // from tAmt: TID R4 == SELF.id && // from R4 == bid.id buyerOut.propositionBytes == buyer.propBytes // from script == buyer } } } cancelCondition || swapCondition } 
A similar script for the sellOrder box can be obtained using the same translation rules. With the help of the tooling the code of contracts can be mechanically generated from the diagram specification.

Conclusions

Declarative programming models have already won the battle against imperative programming in many application domains like Big Data, Stream Processing, Deep Learning, Databases, etc. Ergo is pioneering the declarative model of dApp development as a better and safer alternative to the now popular imperative model of smart contracts.
The concept of FlowCard shifts the focus from writing ErgoScript contracts to the overall flow of values (hence the name), in such a way, that ErgoScript can always be generated from them. You will never need to look at the ErgoScript code once the tooling is in place.
Here are the possible next steps for future work:
  1. Storage format for FlowCard Spec and the corresponding EIP standardized file format (Json/XML/Protobuf). This will allow various tools (Diagram Editor, Runtime, dApps etc) to create and use *.flowcard files.
  2. FlowCard Viewer, which can generate the diagrams from *.flowcard files.
  3. FlowCard Runtime, which can run *.flowcard files, create and send transactions to Ergo network.
  4. FlowCard Designer Tool, which can simplify development of complex diagrams . This will make designing and validation of Ergo contracts a pleasant experience, more like drawing rather than coding. In addition, the correctness of the whole dApp scenario can be verified and controlled by the tooling.
submitted by eleanorcwhite to btc [link] [comments]

Tutorial: How to receive Bitcoin donations on your Street Art works. This tutorial explains in 3 steps how to receive Bitcoin donations on your street art works:

Tutorial: How to receive Bitcoin donations on your Street Art works. This tutorial explains in 3 steps how to receive Bitcoin donations on your street art works:


Step 1 — Creating a Bitcoin Portfolio
First, it is necessary to create your wallet , which will generate your reception address (the equivalent of a bank account that belongs to you).
Thanks to this receiving address, you will be able to receive transactions in your wallet.
The Coinomiwallet is one of the easiest to use , available on Android, iOS, Windows, MacOS and Linux.
You are free to use any other wallet: Samurai Wallet , Spot , Electrum … Make sure that the wallet you choose is recognized and trusted because hacks , phishing and scams are commonplace in the world cryptocurrencies.
Download the application .

Once installed, click on “Create new wallet”.

The wallet will generate you your recovery phrase (or “Seed”, which is the private key of your wallet) which is most often a suite of 24 words.

Write down your recovery phrase by hand on a sheet of paper and keep it in a safe place (be careful to keep it private, anyone who owns this sentence becomes the owner of your funds).


Confirm to the wallet that you have correctly noted the recovery phrase and choose a password .
2nd step — Create your QR code visual
From your wallet, you need to generate your QR code of the receiving address .
Go to “Bitcoin BTC” in the wallet.

Click “Receive” (if indicated, choose a reception address “Compatibility” rather than “Default” or “Legacy”).


Bitcoin receive address example1F4bwjr74bmcXwRu53Jh27JRRCWHHd4yrz
You can now retrieve the QR code with a screenshot and save the receiving address .
To put this QR code on your works, there are 2 methods; a very simple and accessible to all (printing on paper and collage) and the second is a little more complicated (cutting stencil) but more durable:
  • The easiest way is to print the QR code on paper with the mention “Bitcoin donations” at the top and your Bitcoin receipt address at the bottom and paste it into your work.

Download this template and add your QR code and receiving address (as above). Check that the address shown corresponds to the QR code by scanning it with a smartphone.
Optional: It is recommended to add your website (or social networks) to allow people to validate that this is your Bitcoin address (and not that of a person posing as you). Of course, this same Bitcoin receiving address must appear on the front page of your site (and in your social networks profile) to allow donors to verify that the funds will be received by you.
Once the sheet is printed, you can paste it on your next street artwork. Prefer flat and smooth surfaces for better adhesion of the poster. We must make sure that it fits in with the signature of the work so that we understand that the gifts are for you.


- The second method is to create a QR code stencil and use a spray bomb to put it in your work.
There are 2 possible cutting techniques: A manual technique that requires some basic DIY. The second technique is to prepare the visual Photoshop and Illustator then to call a provider who will cut the stencil for you.
1st technique — Manual: To make yourself the stencil, you will need a rigid sheet, a cutting support, a cutting scalpel, Masking Tape, a black felt pen, a clamp and a thin square grid.
To make the QR code stencil by hand, see this tutorial .


Once the stencil of QR code is made, make a stencil with the mention “Donate Bitcoin” and add it to the first stencil to understand that this is your Bitcoin reception address. You can write it yourself or use this template (below) that you can print and overlay your rigid sheet.


Once your stencil is ready (“Donate Bitcoin” + QR code), you can put it on your next work with a black paint spray. Prefer flat, smooth and clear surfaces for a better readability of the QR code. We must make sure that the stencil is integrated into the signature of the work to understand that the gifts are for you.
2nd technique — Stencil cutting by a provider: To create a QR code stencil, it is imperative that all the background of the visual is connected to allow cutting of the stencil, for this, it is necessary to go to a site that generates QR compatible stencil code like qrcode-zebra.com


Once on the site, choose the “Text” tab and paste your Bitcoin receipt address and click on “Generate QR code”. Your QR code will appear, but the design will not be the right one. There are a few changes to make. In the “Choose patterns” tab on the left, click on the first pattern (which looks like a square grid), then in “Choose eyes”, click on the first box (the basic square “eyes”). Then, in “Set colors”, choose the color black.
Optional: if you wish to add your logo or signature, you can add it in “Add logo”. The file should be as simple as possible, in black with transparent background that connects (compatible with a stencil cut).
Now that the QR code is ready, you can retrieve it with a screenshot or click on “Dowload PNG” and give your email address to receive the QR code as a PNG file.
Then, on Photoshop, it is necessary to couple the grid of your QR code with this model so that the mention “Donations in Bitcoin” and the 3 “Eyes” square of the QR are compatible for a stencil cut. Use overlapping layers and erase old “eyes”.


Finally, download this special stencil typography and use it to enter your Bitcoin receipt address used on your QR code. Check that the address shown corresponds to the QR code by scanning it with a smartphone.
It is strongly recommended to also add your website (or social networks) to allow people to validate that this is your Bitcoin address (and not that of a person posing as you). Of course, this same Bitcoin receiving address must appear on the front page of your site (and in your social networks profile) to allow donors to verify that the funds will be received by you.
Once the visual is ready and fully compatible for stencil cutting, you can vectorize it in Illustrator and save it in EPS or AI format.
Last step, send this file to a provider who makes stencil cutting.
It’s up to you to choose the provider that best suits your location, price and time. Choose a format that suits your job. For large frescoes, larger formats (A2) are preferable, and for smaller works, smaller sizes (A4).

Once you receive the stencil, you can affix it to your next work with a black paint spray. Prefer flat, smooth and clear surfaces for a better readability of the QR code. We must make sure that it fits in with the signature of the work so that we understand that the gifts are for you.


3 — Last step, communicate.
Let all those who follow your work know that they can now support you financially by sending you Bitcoin donations on your Street Art works. You can use the means you have available, your contacts, your website, your social networks …
To help beginners, here is a tutorial that explains how to buy Bitcoin.
To track the transactions you receive, you can open your wallet regularly to see your balance.
To receive a notification when you receive a donation, you can use your Wallet to track transactions at an address of your choice.
The public can also see your balance received on your address thanks to blockchain explorers.
Here is the balance of a donation address: 3Pboy9ucGEdQUHNu2rrC6RGq4jouRc4Grb
If you receive a lot of donations, it is a good opportunity to communicate on the amount received.
Good luck and good creation!
FAQ
Why use Bitcoin?
The money you receive is 100% in your possession because you are the sole owner of your private key (recovery phrase, or “Seed”), unlike other centralized means of payment (Banks, Paypal, Ulule, Patreon. ..), Bitcoin happens totally of intermediary of confidence.
How do I use Bitcoin?
Thanks to your wallet you create a private key and a public address. The private key (recovery phrase, or “Seed”) is a bit like the key to your digital vault that you need to keep only for yourself. The public address is your RIB to receive transactions, you can share it publicly without problem.
How do I exchange my bitcoins for USD?
You can at any time send your bitcoins on an exchange online ( Coinbase …) to convert them into currency (Euro, Dollar …). You need to create an account on one of these exchange exchanges, convert your funds into the desired currency and then make a transfer to your bank account.
A faster solution may be to use a centralized service provider that offers a Bitcoin wallet connected to a credit card to spend your bitcoins directly ( Wirex , Coinbase …).
This article is not sponsored by the portfolios and companies mentioned.
You can tip me here !


Btc adress :1F4bwjr74bmcXwRu53Jh27JRRCWHHd4yrz
Have a nice day and many donations ;)
From ; https://medium.com/@freetokencryptobounty/tutorial-how-to-receive-bitcoin-donations-on-your-street-art-works-22e05dd06889
Thanks to https://www.pboy-art.com
submitted by Freetokenairdrop to btc [link] [comments]

Great interview questions for bitcoin engineers

From here...
https://bitcointalk.org/index.php?topic=5006583.0
Questions. Chapter 1: Introduction 1. What are the main Bitcoin terms? 2. What is a Bitcoin address? 3. What is a Bitcoin transaction? 4. What is a Bitcoin block? 5. What is a Bitcoin blockchain? 6. What is a Bitcoin transaction ledger? 7. What is a Bitcoin system? What is a bitcoin (cryptocurrency)? How are they different? 8. What is a full Bitcoin stack? 9. What are two types of issues that digital money have to address? 10. What is a “double-spend” problem? 11. What is a distributed computing problem? What is the other name of this problem? 12. What is an election? 13. What is a consensus? 14. What is the name of the main algorithm that brings the bitcoin network to the consensus? 15. What are the different types of bitcoin clients? What is the difference between these clients? Which client offers the most flexibility? Which client offers the least flexibility? Which client is the most and least secure? 16. What is a bitcoin wallet? 17. What is a confirmed transaction and what is an unconfirmed transaction? Chapter 2: How Bitcoin works. 1. What is the best way to understand transactions in the Bitcoin network? 2. What is a transaction? What does it contain? What is the similarity of a transaction to a double entry ledger? What does input correspond to? What does output correspond to? 3. What are the typical transactions in the bitcoin network? Could you please name three of such transactions and give examples of each type of the transaction? 4. What is a QR and how it is used in the Bitcoin network? Are there different types of QRs? If so, what are the different types? Which type is more informational? What kind of information does it provide? 5. What is SPV? What does this procedure check and what type of clients of the Bitcoin network usually use this procedure? Chapter 3: The Bitcoin client. 1. How to download and install the Core Bitcoin client? 2. What is the best way to test the API available for the Core Bitcoin client without actually programming? What is the interface called? 3. What are the major areas of operations in the Bitcoin client? What can we do with the client? 4. What are the available operations for the Bitcoin addresses? 5. What are the available read operations for the Bitcoin transactions? How is a transaction encoded in the Bitcoin network? What is a raw transaction and what is a decoded transaction? 6. If I want to get information about a transaction that is not related to any address in my own wallet, do I need to change anything in the Bitcoin client configuration? If yes, which option do I need to modify? 7. What are the available read operation for the Bitcoin blocks? 8. What are the available operations for the creation of the transactions in the Bitcoin network? 9. How do you normally need to address the unspent output from the previous transaction in order to use it as an input for a new transaction? 10. What is the mandatory operation after creating a new transaction and before sending this new transaction to the network? What state does the wallet have to be in order to perform this operation? 11. Is the transaction ID immutable (TXID)? If not why, if yes, why and when? 12. What does signing a transaction mean? 13. What are the other options for Bitcoin clients? Are there any libraries that are written for some specific languages? What types of clients do these libraries implement? Chapter 4: Keys, Addresses and Wallets. 1. What is a PKC? When it was developed? What are the main mathematical foundations or functions that PKC is using? 2. What is ECC? Could you please provide the formula of the EC? What is the p and what is the Fp? What are the defined operations in ECC? What is a “point to infinity”? 3. What is a Bitcoin wallet? Does this wallet contain coins? If not, what does it contain then? 4. What is a BIP? What it is used for? 5. What is an encrypted private key? Why would we want to encrypt private keys? 6. What is a paper wallet? What kind of storage it is an example of? 7. What is a nondeterministic wallet? Is it a good wallet or a bad wallet? Could you justify? 8. What is a deterministic wallet? 9. What is an HD wallet? 10. How many keys are needed for one in and out transaction? What is a key pair? Which keys are in the key pair? 11. How many keys are stored in a wallet? 12. How does a public key gets created in Bitcoin? What is a “generator point”? 13. Could you please show on a picture how ECC multiplication is done? 14. How does a private key gets created in Bitcoin? What we should be aware of when creating a new private key? What is CSPRNG? What kind of input should this function be getting? 15. What is a WIF? What is WIF-Compressed? 16. What is Base58 encoding and what is Base58Check encoding? How it is different from Base64 encoding? Which characters are used in Base58? Why Base58Check was invented? What kind of problems does it solve? How is Base58Check encoding is created from Base58 encoding? 17. How can Bitcoin addresses be encoded? Which different encodings are used? Which key is used for the address creation? How is the address created? How this key is used and what is the used formula? 18. Can we visually distinguish between different keys in Base58Check format? If yes, how are they different from each other? What kind of prefixes are used? Could you please provide information about used prefixes for each type of the key? 19. What is an index in HD wallets? How many siblings can exist for a parent in an HD wallet? 20. What is the depth limitation for an HD wallet key hierarchy? 21. What are the main two advantages of an HD wallet comparing to the nondeterministic wallets? 22. What are the risks of non-hardened keys creation in an HD wallet? Could you please describe each of them? 23. What is a chain code in HD wallets? How many different chain code types there are? 24. What is the mnemonic code words? What are they used for? 25. What is a seed in an HD wallet? Is there any other name for it? 26. What is an extended key? How long is it and which parts does it consist of? 27. What is P2SH address? What function are P2SH addresses normally used for? Is that correct to call P2SH address a multi-sig address? Which BIP suggested using P2SH addresses? 28. What is a WIF-compressed private key? Is there such a thing as a compressed private key? Is there such a thing as a compressed public key? 29. What is a vanity address? 30. What is a vanity pool? 31. What is a P2PKH address? What is the prefix for the P2PKH address? 32. How does the owner prove that he is the real owner of some address? What does he have to represent to the network to prove the ownership? Why a perpetrator cannot copy this information and reuse it in the next transactions? 33. What is the rule for using funds that are secured by a cold storage wallet? How many times you can send to the address that is protected by the private key stored in a cold storage? How many times can you send funds from the address that is protected by the private key stored in a cold storage? Chapter 5: Transactions. 1. What is a transaction in Bitcoin? Why is it the most important operation in the Bitcoin ecosystem? 2. What is UTXO? What is one of the important rules of the UTXO? 3. Which language is used to write scripts in Bitcoin ecosystem? What are the features of this language? Which language does it look like? What are the limitations of this language? 4. What is the structure of a transaction? What does transaction consists of? 5. What are the standard transactions in Bitcoin? How many standard transactions there are (as of 2014)? 6. What is a “locking script” and what is an “unlocking script”? What is inside these scripts for a usual operation of P2PKH? What is a signature? Could you please describe in details how locking and unlocking scripts work and draw the necessary diagrams? 7. What is a transaction fee? What does the transaction fee depend on? 8. If you are manually creating transactions, what should you be very careful about? 9. Could you please provide a real life scenario when you might need a P2SH payment and operation? 10. What is the Script operation that is used to store in the blockchain some important data? Is it a good practice? Explain your answer. Chapter 6: The Bitcoin Network. 1. What is the network used in Bitcoin? What is it called? What is the abbreviation? What is the difference between this network architecture and the other network architectures? Could you please describe another network architecture and compare the Bitcoin network and the other network architectures? 2. What is a Bitcoin network? What is an extended Bitcoin network? What is the difference between those two networks? What are the other protocols used in the extended Bitcoin network? Why are these new protocols used? Can you give an example of one such protocol? What is it called? 3. What are the main functions of a bitcoin node? How many of them there are? Could you please name and describe each of them? Which functions are mandatory? 4. What is a full node in the Bitcoin network? What does it do and how does it differ from the other nodes? 5. What is a lightweight node in the Bitcoin network? What is another name of the lightweight node? How lightweight node checks transactions? 6. What are the main problems in the SPV process? What does SPV stand for? How does SPV work and what does it rely on? 7. What is a Sybil attack? 8. What is a transaction pool? Where are transaction pools stored in a Bitcoin network client? What are the two different transaction pools usually available in implementations? 9. What is the main Bitcoin client used in the network? What is the official name of the client and what is an unofficial name of this client? 10. What is UTXO pool? Do all clients keep this pool? Where is it stored? How does it differ from the transaction pools? 11. What is a Bloom filter? Why are Bloom filters used in the Bitcoin network? Were they originally used in the initial SW or were they introduced with a specific BIP? Chapter 7: The Blockchain. 1. What is a blockchain? 2. What is a block hash? Is it really a block hash or is it a hash of something else? 3. What is included in the block? What kind of information? 4. How many parents can one block have? 5. How many children can one block have? Is it a temporary or permanent state of the blockchain? What is the name of this state of the blockchain? 6. What is a Merkle tree? Why does Bitcoin network use Merkle trees? What is the advantage of using Merkle trees? What is the other name of the Merkle tree? What kind of form must this tree have? 7. How are blocks identified in the blockchain? What are the two commonly used identities? Are these identities stored in the blockchain? 8. What is the average size of one transaction? How many transactions are normally in one block? What is the size of a block header? 9. What kind of information do SPV nodes download? How much space do they save by that comparing to what they would need if they had to download the whole blockchain? 10. What is a usual representation of a blockchain? 11. What is a genesis block? Do clients download this block and if yes – where from? What is the number of the genesis block? 12. What is a Merkle root? What is a Merkle path? Chapter 8: Mining and Consensus. 1. What is the main purpose of mining? Is it to get the new coins for the miners? Alternatively, it is something else? Is mining the right or good term to describe the process? 2. What is PoW algorithm? 3. What are the two main incentives for miners to participate in the Bitcoin network? What is the current main incentive and will it be changed in the future? 4. Is the money supply in the Bitcoin network diminishing? If so, what is the diminishing rate? What was the original Bitcoin supply rate and how is it changed over time? Is the diminishing rate time related or rather block related? 5. What is the maximum number of Bitcoins available in the network after all the Bitcoins have been mined? When will all the Bitcoins be mined? 6. What is a decentralized consensus? What is a usual setup to clear transactions? What does a clearinghouse do? 7. What is deflationary money? Are they good or bad usually? What is the bad example of deflationary spiral? 8. What is an emergent consensus? What is the feature of emergent consensus? How does it differ from a usual consensus? What are the main processes out of which this emergent decentralized consensus becomes true? 9. Could you please describe the process of Independent Transaction Verification? What is the list of criteria that are checked against a newly received transaction? Where can these rules be checked? Can they be changed over time? If yes, why would they be changed? 10. Does mining node have to be a full node? If not, what are the other options for a node that is not full to be a mining node? 11. What is a candidate block? What types of nodes in the Bitcoin network create candidate blocks? What is a memory pool? Is there any other name of the memory pool? What are the transactions kept in this memory pool? 12. How are transactions added to the candidate block? How does a candidate block become a valid block? 13. What is the minimum value in the Bitcoin network? What is it called and what is the value? Are there any alternative names? 14. What is the age of the UTXO? 15. How is the priority of a transaction is calculated? What is the exact formula? What are the units of each contributing member? When is a transaction considered to be old? Can low priority transactions carry a zero fee? Will they be processed in this case? 16. How much size in each block is reserved for high priority transactions? How are transactions prioritized for the remaining space? 17. Do transactions expire in Bitcoin? Can transactions disappear in the Bitcoin network? If yes, could you please describe such scenario? 18. What is a generation transaction? Does it have another name? If it does, what is the other name of the transaction? What is the position of the generation transaction in the block? Does it have an input? Is the input usual UTXO? If not – what is the input called? How many outputs there are for the generation transaction? 19. What is the Coinbase data? What is it currently used for? 20. What is little-endian and big-endian formats? Could you please give an example of both? 21. How is the block header constructed? Which fields are calculated and added to the block header? Could you please describe the steps for calculation of the block header fields? 22. What is a mantissa-exponent encoding? How is this encoding used in the Bitcoin network? What is the difficulty target? What is the actual process of mining? What kind of mathematical calculation is executed to conduct mining? 23. Which hash function is used in the Bitcoin mining process? 24. Could you describe the PoW algorithm? What features of the hash function does it depend on? What is the other name of the hash function? What is a nonce? How can we increase the difficulty of the PoW calculation? What do we need to change and how do we need to change this parameter? 25. What is difficulty bits notation? Could you please describe in details how it works? What is the formula for the difficulty notation? 26. Why is difficulty adjustable? Who adjusts it and how exactly? Where is the adjustment made? On which node? How many blocks are taken into consideration to predict the next block issuance rate? What is the change limitation? Does the target difficulty depend on the number of transactions? 27. How is a new block propagated in the network? What kind of verification does each node do? What is the list of criteria for the new block? What kind of process ensures that the miners do not cheat? 28. How does a process of block assembly work? What are the sets of blocks each full node have? Could you please describe these sets of blocks? 29. What is a secondary chain? What does each node do to check this chain and perhaps to promote it to the primary chain? Could you please describe an example when a fork occurs and what happens? 30. How quickly forks are resolved most of the time? Within how many new block periods? 31. Why the next block is generated within 10 minutes from the previous? What is this compromise about? What do designers of the Bitcoin network thought about when implementing this rule? 32. What is a hashing race? How did Bitcoin hashing capacity has changed within years from inception? What kind of hardware devices were initially used and how did the HW utilization evolved? What kind of hardware is used now to do mining? How has the network difficulty improved? 33. What is the size of the field that stores nonce in the block header? What is the limitation and problem of the nonce? Why was an extra nonce created? Was there any intermediate solution? If yes, what was the solution? What are the limitations of the solution? 34. What is the exact solution for the extra nonce? Where does the new space come from? How much space is currently used and what is the range of the extra nonce now? 35. What is a mining pool? Why was it created? How are normally such pools operated? Do they pay regularly to the pool participants? Where are newly created Bitcoins distributed? To which address? How do mining pools make money? How do the mining pools calculate the participation? How are shares earned calculated? 36. What is a managed pool? How is the owner of the pool called? Do pool members need to run full nodes? Explain why or why not? 37. What are the most famous protocols used to coordinate pool activities? What is a block template? How is it used? 38. What is the limitation of a centralized pool? Is there any alternative? If yes, what is it? How is it called? How does it work? 39. What is a consensus attack? What is the main assumption of the Bitcoin network? What can be the targets of the consensus attacks? What can these attacks do and what they cannot do? How much overall capacity of the network do you have to control to exercise a consensus attack? Chapter 9: Alternative Chains, Currencies and Applications. 1. What is the name of alternative coins? Are they built on top of the Bitcoin network? What are examples of them? Is there any alternative approach? Could you please describe some alternatives? 2. Are there any alternatives to the PoW algorithm? If yes – what are the alternatives? Could you please name two or three? 3. What is the operation of the Script language that is used to store a metadata in Bitcoin blockchain? 4. What is a coloured coin? Could you please explain how it is created and how it works? Do you need any special SW to manage coloured coins? 5. What is the difference between alt coins and alt chains? What is a Litecoin? What are the major differences between the Bitcoin and Litecoin? Why so many alt coins have been created? What are they usually based on? 6. What is Scrypt? Where is it used and how is it different from the original algorithm from which it has been created? 7. What is a demurrage currency? Could you please give an example of one blockchain and crypto currency that is demurrage? 8. What is a good example of an alternative algorithm to PoW? What is it called and how is it different from the PoW? Why the alternatives to Bitcoin PoW have been created? What is the main reason for this? What is dual-purpose PoW algorithms? Why have they been created? 9. Is Bitcoin “anonymous” currency? Is it difficult to trace transactions and understand someone’s spending habits? 10. What is Ethereum? What kind of currency does it use? What is the difference from Bitcoin? Chapter 10: Bitcoin security. 1. What is the main approach of Bitcoin security? 2. What are two common mistakes made by newcomers to the world of Bitcoin? 3. What is a root of trust in traditional security settings? What is a root of trust in Bitcoin network? How should you assess security of your system? 4. What is a cold storage and paper wallet? 5. What is a hardware wallet? How is it better than storing private keys on your computer or your smart phone?
submitted by 5tu to BitcoinTechnology [link] [comments]

Looking for a developer of Bitcoin POS terminal

A while ago we started on a development of a bitcoin POS terminal, however the development stalled because the developer went missing. I'm looking for someone to continue the work or start from scratch. I believe in open source and will be financing the development for the benefit of the crypto/Bitcoin ecosystem.
In light of open source and transparency, here is the full idea/plan for anyone to build. If this is something you would like to do, let's do it together.
This was made before the development stalled:
https://play.google.com/store/apps/details?id=at.bitpocket.pos
https://github.com/getbitpocket/bitpocket-mobile-app
This software was to be installed onto an android POS terminal bundled with a thermal printer, such as one of these:
https://www.aliexpress.com/item/PDA-POS-Handheld-device-Pos-terminal-built-in-thermal-bluetooth-printer-58mm-wifi-Android-Rugged-PDA/32905823954.html
https://www.aliexpress.com/item/Android-7-Mini-POS-Thermal-Printer-Barcode-Scanner-Handheld-POS-Terminal-Pos-PDA-Built-in-58mm/32922911878.html
The above mentioned Bitpocket app has almost all the required functionality except it needed to be ported onto the POS device and there were some minor bug fixes and functionality to be added.
This is how the POS terminal is supposed to work:
  1. idiot proof with the least amount of clicks required to operate. Right from the start the only thing the terminal operator (waiter, sales clerk) can do is input the price and click "request" or "reset"
  2. a QR code along with the basic info (price in fiat, price in BTC and bitcoin wallet address in text format) is displayed on screen
  3. when payment is received (zero confirmations is OK - considered successfully paid), a paid screen is displayed and that's the end of it. With the click of a OK button, the screen returns back to main page
The terminal has a pin protected settings area which only the business owner can access. There one can set the following:
- the wallet's XPUB / YPUB or ZPUB key (no private keys, ever). The terminal generates a fresh receiving address based on the XPUB/YPUB key for each transaction
- fiat currency selection
- setting to display the Bitcoin price in BTC (mBTC or bits)
- commission or discount setting (percentage to add or subtract from the total amount, rounded by two decimals - example: 3.75%)
- merchant name (text area where the operator owner can define the name of the business and optionally add a phone number, email, address, whatever. If they want just company name to be displayed on the receipt, they will add just that in this field)
- POS terminal ID (unit name)
- change pin code setting
- change XPUB/YPUB key
- reset all data
- setting for the template for the printed receipt paper. Probably a text-area which supports variables (sub setting: number of copies to print - ie, one for the customer, 2nd for the cash register)
Then there is the "account" area where the terminal operator can review history transactions
These are the changes to be made to the existing Bitpocket app (or equivalent new build):
  1. Port the app to the hardware POS terminal and make it work with the embedded printer
  2. A the moment it supports only XPUB. Add support for YPUB (and maybe ZPUB too). Move the XPUB/YPUB/ZPUB setting from the "account" are to the settings area
  3. Rename the "account" area to "Transactions" and make the sub-menu available to the POS operator without a PIN code. This is so that the shop clerk can review the transactions
  4. The transactions log should somehow be made available to the business owner, so that they can monitor the sales live. We need to come up with an easy way to allow the business owner remote access to the logs
  5. add POS terminal ID (unit name) to the settings area. This is in case a business is using multiple terminals, multiple stores, mulitple restaurants, etc. All of the units will show up in the same logs. POS ID is to be used to easily organize the logs
  6. template for the printed receipt page. Text area which supports variables, like for example: {text.merchant.name} Time: {text.time} Price: {text.fiat.amount} {text.fiat.currency} Crypto: {text.crypto.amount} {text.crypto.currency} Destination: {text.destination.address} Transaction ID: {text.transaction.id}. Templating/variables are necessary because things may change and different parts of the world have different regulation, etc.
  7. Lightning support would be great and will probably become necessary during the next bull run. For now we can do it without lightning to speed things up
Monetizing on this project:
I envision two ways of making money from this project while at the same time promoting adoption:
  1. Business owners who are incapable of doing it themselves outright buy the POS terminal bundled with the POS software and pay a premium price to a reseller who is capable of finding and putting together this open source project and the POS terminal off of alibaba / aliexpress) and then showing the business owner how it's done. In this case the business owner would own the private keys counterpart of the XPUB/YPUB/ZPUB and be able to do whatever he wants with the earned bitcoin.
  2. A company would act as a clearing house and help business owners who are otherwise not willing to hold Bitcoin. In this case the clearing house would own the POS terminals, the private keys to the wallets and all the bitcoin would go directly into the clearing house's wallet where it can be dealt with as the clearing house sees fit. The clearing house would owe/pay the business owner in fiat in agreed intervals. The clearing house would have sole access to the POS terminal's settings, while the business owner can see the sales history. Anyone brave enough can be a clearing house for his local community - take on a few small shops/bakeries or something bigger if you can afford it and have the cash liquidity. The commission setting in the POS terminal is for this purpose. Take on a few shops, stick Bitcoin accepted stickers on it and let's advance adoption.
Payment for this project development:
So I don't go through a similar experience as before where the project stalled after I sent a few devices and printers to the developer, I propose depositing the full agreed upon project cost to a reputable escrow service. The developer would buy his own POS terminal unit for testing - this unit will be refunded for at the completion of the project (money included in the total escrow sum). We can agree on the total cost privately.
submitted by besnadlesen to Jobs4Bitcoins [link] [comments]

What is Finatch?

ABOUT FINATCH Finatch is a private Blockchain Technology Company which aim's at revolutrionizing the Blockchain Technology industry.
Looking at the lack of stable, fast and reliable decentralized crypto exchanges which causes inconviniences to crypto traders in the space. We have come up with the solution to the problems faced by decentralized exchanges.
There are basically two different types of exchanges: Centralized and Decentralized exchanges. We will focus on the Deentralized exchange system. We have a strong belief that Decentralized based crypto exchanges will be bigger than Centralized based crypto exchanges in the nearest future, because Blockchain is all about Decentralization.
They will play an evermore role in the world of finance, and we call this FINATCH EXCHANGE. FINATCH EXCHANGE Finatch Exchange is a Decntralized crypto exchange, which is run and powered by the Finatch Smart Contract Blockchain. Problems Poor technical architecture in Decentralized exchanges There are a good number of exchanges set up by professionals who have little or no experience in finance or in operating an exchange. They often take the easiest route to get the system up and running. While this may work well in the beginning, as traffic grows, the system will not be able to handle the increased load. Exchange systems need to be engineered from the ground up with security, efficiency, speed, and scalability in mind. This often slows down the initial development, but is critical for long-term success.
Our team has decades of combined experience building and maintaining world class financial systems that shape the economy. We understand how these systems are built from the ground up. Slow Smart Contract confirmation time Deployment of Smart contract on the blockchain takes time and causes inconveniences becauses of the poorly built blockchain, this results in a bad user experience in decentralized crypto exchanges.
Our team has designed a new and capable type of Blockchain that speeds up confirmation time for smart contratcts, making the platform user friendly and smooth. Insecured Platform There are hundreds of exchanges that went down due to being hacked.
Finatch is built to top notch quality, audited, and penetration tested. We have experience building financial systems to the highest security standards and strive to ensure security first. Poor market liquidity Professional traders and normal users are significantly affected by this. Having a shallow orderbook means high slippage when trading, which is very expensive for traders.
Finatch’s team have been in both the finance and crypto industry for many years. The team has worked on and operated a number of exchanges, and have accumulated a large network of partners in this space. These partners will be key in bootstrapping the exchange. Poor customer service Traders are a different breed when it comes to users. Understanding the trader mentality is vital for running a successful exchange. Money is literally on-the-line. Many exchange service trades as if they were running a social media site. A 3-second delay in seeing your friends’ status update would hardly be noticed, but on an exchange, the same would be unacceptable, resulting in a torrent of user complaints.
In additional to the technology stack, Finatch is built with service in mind. Finatch shares and supports responsibilities across the entire staff and company. When a trader has a problem, they get an answer directly from someone who knows the system and not someone reading from a script. Limited access to decentralized services There are few existing decentralized exchanges with close to good user interface and lacks quick and reasonable smart contract transaction fees, causing slow platorm functioning.
Our team has designed a new and capable type of Blockchain that speeds up confirmation time for smart contratcts, making the platform user friendly and smooth. Poor internationalization and language support Blockchains have no borders. Most exchanges focus only on one language or one country.
Our international multi-lingual team has extensive working experience in North America, Europe, Asia and Africa and we are able to smoothly support the global market. Lack of transparency All trading activities should be decentralized and open to the general public to insure trust and transparency in trades. Centralized crypto exchanges lack this quality.
Finatch runs on a Decentralized crypto platform where all trading activities are transparent.
Finatch is a Crypto Decentralized crypto exchange that has the feel and look of Centralized Crypto exchange but with more convinience And extra Blockchain Security Layer. An Exchange where you own your private keys.
Finatch exchange is a huge decentralized trading exchange platform equipped with various sub-platform, trading tools and secure decentralized wallet.
Finatch exchange consists of various sub platforms to choose from, this changes the trading experience namely: 1. Binary Platform: Fin vault platform, FinBox platform 2. Finatch trading tools: Finatch exchange have the best trading tools ready for traders on all our trading platform, taking trading experience to the next level. You can choose from our multiple trading tools the one that suits your trading skills. 3.Andriod and iOs Mobile Trading Application. MATCHING ENGINE With our Unique Smart Contract Blockchain Our matching engine is capable of sustaining 1,500,000 orders / second, making Finatch one of the fastest exchanges in the market today. You can be certain, on our exchange, that your orders will never be stuck due to the matching engine being overwhelmed.
FEATURE ROLLOUT We will roll out the platform in roughly the following order: Decentralized (on-chain) exchange Spot trading Margin trading Futures Anonymous instant exchange and more... COINS Finatch will support trading pairs in the following coins: BTC ETH LTC BCH FIN (Finatch Coin) More coins will be added over time. We generally will only add coins that have strong credibility, user base, and liquidity. If you have a coin that you wish to be listed on Finatch later. DEVICE COVRAGE We will provide cross-platform trading clients for: Web-based decentralized trading client Android native client iOS native client (pending App Store review) Mobile HTML5 client (including WeChat H5 client) PC (Windows) native client REST API MULTILINGUAL SUPPORT We will support English, Chinese, Japanese and Korean on all of our user interfaces. (The very initial release will be in English only.) More languages will be added over time.
FINATCH COIN We will build our own Blockchain based Crypto coin, called the Finatch Coin. The Finatch Coin Total Supply is capped at 952.5M, but a strict pre mine of 200M FIN will be mined during the genesis Block. FIN Coin will run on the Finatch Blockchain. Percentage (%) Amount (FIN) Participant 25% 50,000,000 Airdrop&Bounty Programs 25% 50,000,000 Project Development 40% 80,000,000 Founding Team 10% 20,000,000 Angel Investors No ICO or Pre-ICO will take place. 50% of pre-mined Coins will be distributed to the general Public Via Airdrop stages and Bounty Programs. FIN VALUE AND REPURCHASING PLAN You can use FIN to pay for any fees on our platform, inculding but not limited to: Exchange fees Withdraw fees Listing fees Any other fee
When you use FIN to pay for fees, you will receive a significant discount: 1st year 2nd year 3rd year 4th year 5th year Discount Rate 60% 30% 12.5% 6.75%5 no discount
REPURCHASING PLAN Every quater, we will use 15% of our profits to buy back the pre-mined FIN coin and Burn them, until we buy up 50% of the pre-mined FIN coin during genesis block (100M) back. All buy back transactions will be annouced on the blockchain. FUNDS USAGE
35% of the funds will be used to build the Finatch platform and perform upgrades to the system, which inculdes team recruiting, training, and the development budget. 50% will be used for Finatch branding and marketing, including continuous promotion and education of Finatch and Blockchain innovations in industry mediums. A sufficient budget for various advertisment activities, to help Finatch become popular among investors, and to attract active users to the platform. 15% will be kept in reserve to cope with any emergency or unexpected situation that might come up. FINATCH BLOCKCHAIN Finatch Blockchain is a powerful unique blockchain built to solve the problems of long confirmation times and high transaction fees on smart contract Blockchains.
We also solve the scalablity problem with block size, by increasing the block size limit to 1GB. Finatch Blockchain can handle more than 100,000,000 tranactions per second, with as little to as low as $0.001 tranaction fee, making our blockchain the most convinent and reliable blockchain in exixtence.
Our Blockchain runs on Scrypt PoW/PoS and Fault Tolorence Algorithms, making it one the most secure blockchains. You can deploy smart contracts, decentralized applications and create your own (FRC Tokens) on our blockchain.
BUILD DECENTRALIZED APPLICATIONS Combining a modified Bitcoin Core infrastructure with an intercompatible version of the Ethereum Virtual Machine (EVM), Finatch Blockchain merges the reliability of Bitcoin’s unfailing blockchain with the endless possibilities provided by smart contracts.
Designed with stability, modularity and interoperability in mind, Finatch Blockchain is the foremost toolkit for building trusted decentralized applications, suited for real-world, business oriented use cases. Its hybrid nature, in combination with a PoS/PoW consensus protocol, allows Finatch Blockchain applications to be compatible with major blockchain ecosystems, while providing native support for mobile devices and IoT appliances.
DEPLOY DECENTRALIZED SMART CONTRACTS Finatch makes it easier than ever for established sectors and legacy institutions to interface with blockchain technology. Create your own tokens, automate supply chain management and engage in self-executing agreements in a standardized environment, verified and tested for stability.
SMART CONTRACT LIFE CYCLE MANAGMENT Finatch, in cooperation with its academic partners, develops tools and methods to standardize the workflow for business smart contract development. This includes the formally verifiable translation of human-readable agreements to machine smart contracts, and the error-resilient specification of their elements, terms and conditions.
SETTING INDUSTRY STANDARDS Cooperating with a series of partners and third parties, Finatch aims to establish a smart contract hub, offering secure and thoroughly tested contract templates, tailor fitted for a multitude of industries and use cases, such as supply chain management, telecommunications, IoT, social networking, Crypto exchanges and many more. ABOUT FIN COIN FIN Coin is a decentralised Cryptocurrency based on Finatch. It is the local based Cryptocurrency of Finatch Blockchain. FIN Coins are cryptographic software tokens used to engage with distributed applications (DApps) and smart contracts on the Finatch Platform. FIN Coins will serve as the staking currency of the Finatch blockchain and fuel computational operations performed by the Finatch network.
SPECIFICATION Total Pre-Mined Supply: 200,000,000 Block Target: 3-15 seconds Stake Return: ~5 FIN Coin Algorithm: Scrypt PoW/PoS and FT The FINATCH Foundation: Governance Structure The development and maintenance of the FINATCH Blockchain, as well as all services provided by FINATCH, are directed and supervised by the FINATCH Foundation - a non-profit organization, representing FINATCH’s stake and token holders as elaborated below.
In order to avoid the inefficient conduct, open source and blockchain projects often suffer from, and to ensure a coherent and standardized implementation of the FINATCH blockchain, the FINATCH Foundation was established under the guidance and support of FINATCH Inc. The Foundation will oversee the development of the FINATCH Blockchain, advocate governance transparency, and promote the safety and harmony of the open source ecosystem.
The design of the Foundation’s governance structure mainly considers sustainability, management effectiveness, and fund-raising security in the open source community. The Foundation consists of various committees, such as Executive Judgment, Code Review, Finance & HR, as well as Marketing & PR. The different committees work in cooperation to manage FINATCH’s daily operations and special occasions with detailed operational procedures and rules.
Learn more here: https://finatch.org/governance-structure
Decentralized Governance Protocol The Decentralized Governance Protocol (DGP) is designed so that individual blockchain parameters can be modified through a specially designed smart contract on the blockchain. Most importantly, this technology allows these blockchain parameters to be changed without any disruption to the ecosystem. After a setting change, no new software must be downloaded by users, and no intervention is needed from stakers, miners and node operators.
The way the DGP works is relatively straightforward. First, a governing party for the DGP makes a proposal to change a parameter. Afterward, all the governing parties for the DGP can vote on the proposal, and if it receives enough approval votes, then the parameter change proposal becomes active. The proposal data is then placed in a standardized format and a particular storage space so that the blockchain software can easily access it without needing to execute the DGP contract directly.
Learn more here: https://finatch.org/decentralized-governance-protocol
The FINATCH Foundation will list the total assets that it holds including Bitcoin, Ethereum, Legal Tender, and FIN COINS. The Foundation will also seek complementary services to aid our efforts in transparency and professionalism with a professional auditing firm, legal team and a professional digital asset management solution. We hope this will help promote the healthy development of the FINATCH Project and serve as a model for other projects. The content will be made public to the community on the FINATCH.org Website
EXCHANGE LIST
Binance
Huobi
Kucoin
Bibox
Qryptos
Satoexchange
BIGone
Bitrue
Bilaxy
Bit-Z
Linkcoin
SECURE WALLET
Ledgerwallet
Trezor
submitted by icoinformation2021 to Finatch [link] [comments]

Serialization: Qtum Quantum Chain Design Document (6): x86 Virtual Machines Reshaping Smart Contract Ecosystem

Qtum Original Design Document Summary (6) -- Qtum x86 Virtual Machine

https://mp.weixin.qq.com/s/0pXoUjXZnqJaAdM4vywvlA
As we mentioned in the previous chapters, Qtum uses a layered design, using Qtum AAL, so that the Ethereum virtual machine EVM can run on the underlying UTXO model to be compatible with Ethereum's smart contracts. However, EVM itself has many limitations, and is currently only compatible with a high-level language such as Solidity for smart contract writing. Its security and maturity still require time verification. The Qtum AAL was designed to be compatible with multiple virtual machines at the beginning of the design, so after the initial compatibility with the EVM, the Qtum team was committed to compatibility with the more mainstream architecture of the virtual machine, which in turn was compatible with mainstream programming languages and toolchains.
The Qtum x86 virtual machine is the development focus of the Qtum project in 2018. It aims to create a virtual machine compatible with the x86 instruction set and provide similar operating system level calls, aiming to push smart contract development into the mainstream.
The following section intercepted some of the original Qtum development team's original design documents for the Qtum x86 virtual machine (with Chinese translation) (ps: document QTUM <#> or QTUMCORE<#> for internal design document numbering):
 
QTUMCORE-103:[x86lib] Add some missing primary opcodes
Description:There are several missing opcodes in the x86 VM right now. For this story, complete the following normal opcodes (it should just be a lot of connecting code, nothing too intense)
//op(0x9C, op_pushf);
//op(0x9D, op_popf);
//op(0xC0, op_group_C0); //186
// C0 group: _rm8_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar
//op(0xC1, op_group_C1); //186
// C1 group: _rmW_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar
Notes:
• Make sure to look at existing examples of similar code in the VM code.
• Look at the x86 design document references for some good descriptions of each opcode
• Ask earlz directly about any questions
• At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean
• Implement the first opcode listed and then have earlz review to make sure things looks correct
Task: [x86lib] add some missing main operation code
Description: Some opcodes are currently missing from x86 virtual machines. In this task, complete the following standard opcode (should only be some connection code, not too tight)
//op(0x9C, op_pushf);
//op(0x9D, op_popf);
//op(0xC0, op_group_C0); //186
// C0 group: _rm8_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar
//op(0xC1, op_group_C1); //186
// C1 group: _rmW_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar
note:
• Make sure to see existing similar code examples in VM (virtual machine) code
• View x86 design documents to better understand each opcode
• Ask any question directly to Earlz
• At the top of opcode_def.h, there is a large section of comments explaining the opcode function name criteria and the meaning of keywords such as "rW"
• Implement the first opcode listed, and then let Earlz check to make sure the code looks correct.
QTUMCORE-106: [x86lib] Add some more missing primary opcodes
Description: There are a few missing opcodes in the x86 VM right now. For this story, complete the following normal opcodes (it should just be a lot of connecting code, nothing too intense)
//op(0x60, op_pushaW); //186
//op(0x61, op_popaW); //186
//op(0x6C, op_insb_m8_dx); //186
//op(0x6D, op_insW_mW_dx); //186
//op(0x6E, op_outsb_dx_m8); //186
//op(0x6F, op_outsW_dx_mW); //186
Notes:
• Make sure to look at existing examples of similar code in the VM code.
• Look at the x86 design document references for some good descriptions of each opcode
• Ask earlz directly about any questions
• At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean
• Implement the first opcode listed and then have earlz review to make sure things looks correct
Task: [x86lib] add some missing main operation code
Description: Some opcodes are currently missing from the x86 virtual machine. In this task, complete the following standard opcode (should only be some connection code, not too tight)
//op(0x60, op_pushaW); //186
//op(0x61, op_popaW); //186
//op(0x6C, op_insb_m8_dx); //186
//op(0x6D, op_insW_mW_dx); //186
//op(0x6E, op_outsb_dx_m8); //186
//op(0x6F, op_outsW_dx_mW); //186
note:
• Make sure to see existing similar code examples in VM (virtual machine) code
• View x86 design documents to better understand each opcode
• Ask any question directly to Earlz
• At the top of opcode_def.h, there is a large section of comments explaining the opcode function name criteria and the meaning of keywords such as "rW"
• Implement the first opcode listed, and then let Earlz check to make sure the code looks correct.
QTUMCORE-104: [x86lib] Add some missing extended opcodes
Description: There are several missing opcodes in the x86 VM right now. For this story, complete the following extended (0x0F prefix) opcodes (it should just be a lot of connecting code, nothing too intense)
Opx(0xA0, op_push_fs); //386
Opx(0xA1, op_pop_fs); // 386
Opx(0xA8, op_push_gs); //386
Opx(0xA9, op_pop_gs); //386
Opx(0xAF, op_imul_rW_rmW); //386
Opx(0xB0, op_cmpxchg_rm8_al_r8); //48
Opx(0xB1, op_cmpxchg_rmW_axW_rW); //486
For(int i=0;i<8;i++)
{opx(0xC8 + i, op_bswap_rW); }
Notes:
• Make sure to look at existing examples of similar code in the VM code.
• Look at the x86 design document references for some good descriptions of each opcode
• Ask earlz directly about any questions
• At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean
• Implement the first opcode listed and then have earlz review to make sure things looks correct
Task: [x86lib] Adding Some Missing Extended Opcodes
Description: Some opcodes are currently missing from the x86 virtual machine. In this task, complete the following extension (0x0F prefix) opcode (should be just some connection code, not too tight)
Opx(0xA0, op_push_fs); //386
Opx(0xA1, op_pop_fs); // 386
Opx(0xA8, op_push_gs); //386
Opx(0xA9, op_pop_gs); //386
Opx(0xAF, op_imul_rW_rmW); //386
Opx(0xB0, op_cmpxchg_rm8_al_r8); //48
Opx(0xB1, op_cmpxchg_rmW_axW_rW); //486
For(int i=0;i<8;i++)
{opx(0xC8 + i, op_bswap_rW); }
note:
• Make sure to see the existing similar code example in the virtual machine code
• View x86 design documents to better understand each opcode
• Ask any question directly to Earlz
• At the top of opcode_def.h, there is a large section of comments explaining the opcode function name criteria and the meaning of keywords such as "rW"
• Implement the first opcode listed, and then let Earlz check to make sure the code looks correct.
The above series of tasks implements most of the necessary opcodes for the x86 lib kernel part (x86lib). These are the basics for the virtual machine to recognize and run x86 instructions and function as an emulator for x86 instructions.
QTUMCORE-105: [x86lib] Research how to do automated testing for x86lib
Description: Research and look for viable ways to do automated testing of x86lib's supported opcodes
Task: How to Automatically Test x86lib
Description: Study and find possible ways to automate x86lib supported opcodes
The Qtum team achieved automated testing of the x86 virtual machine kernel through the above tasks, because the parsing and running errors of the underlying instructions are often difficult to find through debugging, and must use some automated testing tools. This ensures the correctness of the x86lib kernel.
QTUMCORE-109:[x86] Add "reason" field for all memory requests
Description: In order to prepare for the upcoming gas model, a new field needs to be added to every memory access. This field basically gives the reason for why memory is being accessed so that it can be given a proper gas cost. Possible reasons:
Code fetching (used for opcode reading, ModRM parsing, immediate arguments, etc)
Data (used for any memory reference in the program, such as mov [1234], eax. also includes things like ModRM::WriteWord() etc)
Internal (used fro any internal memory reading that shouldn't be given a price.. probably not used right now outside of testbench/testsuite code)
This "reason" code can be place in MemorySystem(). It shouldn't go in each individual MemoryDevice object
Task: [x86] Add "reason" field to all memory requests
Description: In preparation for the gas model to be used, a new field needs to be added to each memory access. This field basically gives the reason why the memory was accessed so that the appropriate gas cost can be given.
Possible reasons are:
• Capture code (for opcode reads, ModRMB parsing, instant parameters, etc.)
• Data (used for memory references in programs such as mov[1234], eax, and operations similar to ModRM::WriteWord(), etc.)
Internal request (for any internal memory read that does not need to consume gas... currently only used in testbench/testsuite code)
The "reason" code can be placed in MemorySystem(). It should not be placed in any single MemoryDevice object.
The above task is mainly aimed at the Qtum x86 new gas model, and separate fields are reserved for different types of memory access requests. Currently only used to verify the feasibility, in the future will be used to calculate the actual gas price.
QTUMCORE-114: [x86] Add various i386+ instructions
Description: Implement (with unit tests for behavior) the following opcodes and groups:
//op(0x62, op_bound_rW_mW); //186
//op(0x64, op_pre_fs_override); //386
//op(0x65, op_pre_gs_override); //386
// op(0x69, op_imul_rW_rmW_immW); //186 (note: uses /r for rW)
// op(0x6B, op_imul_rW_rmW_imm8); //186 (note: uses /r for rW, imm8 is sign extended)
//op(0x82, op_group_82); //rm8, imm8 - add, or, adc, sbb, and, sub, xor, cmp
Task:[x86]Add various i386+ instructions
Description: Implement (and unit test) the following opcodes and groups:
//op(0x62, op_bound_rW_mW); //186
//op(0x64, op_pre_fs_override); //386
//op(0x65, op_pre_gs_override); //386
// op(0x69, op_imul_rW_rmW_immW); //186 (note: uses /r for rW)
// op(0x6B, op_imul_rW_rmW_imm8); //186 (note: uses /r for rW, imm8 is sign extended)
//op(0x82, op_group_82); //rm8, imm8 - add, or, adc, sbb, and, sub, xor, cmp
QTUMCORE-115: [x86] Implementer more i386+ opcodes
Description: Implement with unit tests the following opcodes:
(notice opx is extended opcode)
//op(0xC8, op_enter); //186
For(int i=0;i<16;i++)
{opx(0x80+i, op_jcc_relW); //386 opx(0x90+i, op_setcc_rm8); //386 }
Opx(0x02, op_lar_rW_rmW);
Opx(0x03, op_lsl_rW_rmW);
Opx(0x0B, op_unknown); //UD2 official unsupported opcode
Opx(0x0D, op_nop_rmW); //nop, but needs a ModRM byte for proper parsing
Opx(0xA0, op_push_fs); //386
Opx(0xA1, op_pop_fs); // 386
Opx(0xA2, op_cpuid); //486
Opx(0xA3, op_bt_rmW_rW); //386
Opx(0xA4, op_shld_rmW_rW_imm8); //386
Opx(0xA5, op_shld_rmW_rW_cl); //386
Opx(0xA8, op_push_gs); //386
Opx(0xA9, op_pop_gs); //386
Opx(0xAA, op_rsm); //386
Opx(0xAB, op_bts_rmW_rW); //386
Opx(0xAC, op_shrd_rmW_rW_imm8); //386
Opx(0xAD, op_shrd_rmW_rW_cl); //386
Make sure to remove these opcodes from the commented todo list as they are implemented
Task: [x86] Implement More i386+ Instructions
Description: Implements the following opcodes and unit tests:
(Note that opx is an extended opcode)
//op(0xC8, op_enter); //186
For(int i=0;i<16;i++)
{opx(0x80+i, op_jcc_relW); //386 opx(0x90+i, op_setcc_rm8); //386 }
Opx(0x02, op_lar_rW_rmW);
Opx(0x03, op_lsl_rW_rmW);
Opx(0x0B, op_unknown); / / UD2 official unsupported opcode
Opx(0x0D, op_nop_rmW); //nop, but requires a ModRM byte for proper parsing
Opx(0xA0, op_push_fs); //386
Opx(0xA1, op_pop_fs); // 386
Opx(0xA2, op_cpuid); //486
Opx(0xA3, op_bt_rmW_rW); //386
Opx(0xA4, op_shld_rmW_rW_imm8); //386
Opx(0xA5, op_shld_rmW_rW_cl); //386
Opx(0xA8, op_push_gs); //386
Opx(0xA9, op_pop_gs); //386
Opx(0xAA, op_rsm); //386
Opx(0xAB, op_bts_rmW_rW); //386
Opx(0xAC, op_shrd_rmW_rW_imm8); //386
Opx(0xAD, op_shrd_rmW_rW_cl); //386
After these opcodes are implemented, make sure to remove them from the commented TODO list.
QTUMCORE-118: Implement remaining opcodes in x86lib
Description: The remaining opcodes that do not result in an error or change of behavior should be implemented with unit tests. Take particular care and use many references for some of the weird opcodes, like nop_rm32.
Task: Implementing remaining x86lib opcodes
Description: The remaining opcodes that do not cause errors or behavior changes should be implemented through unit tests. Take special care and refer to some weird opcodes, such as nop_rm32.
The above series of tasks further adds support for i386+ opcodes and implements the rest of the necessary remaining opcodes. At this point x86lib can already support most i386+ instructions
QTUMCORE-117: Begin leveldb-backed database for x86 contracts
Description: For this story, the code work should done as a sub-project from Qtum Core, and can be done direclty in the Qtum Core github. For now, unit and integration tests should be used to confirm functionality. It will be integrated into Qtum Core later. You might need to modify Qtum Core some so that the project is built with proper dependencies. This story will implement the beginnings of a new database that will be used for smart contracts. This will only store meta-data, contract Bytecode, and constructor data for right now:
The leveldb dataset for this data should be named "contracts". The key for this dataset should be a 256-bit contract address (exact format will be specified later) awarded as a hex string.
The value data should contain the following:
• txid of contract creation (with this the chainstate db can be used to lookup blockhash)
• VM version
• contract creation parameters (see "contract deployment" page in design)
• contract creation data (the constructor data)
• contract bytecode
The interface for reading and writing into this database should be clear and extensible. Although it is being designed for the x86 VM, other VMs in the future will also use it.
Task: Implementing a leveldb database in an x86 contract
Description: For this task, code should be written in the Qtum Core subproject and can be done directly on the Qtum Core github. Currently, unit tests and integration tests should be used to confirm the correctness of the function. The following code will be integrated into Qtum Core. It may be necessary to modify the Qtum Core appropriately so that the project has the appropriate dependencies. This task will implement a prototype of a new database that can be used for smart contracts. This database currently only stores meta-data, contract bytecode, and constructor data.
The data leveldb data set should be named "contract." The key of the data set should be the contract address of a 256-digit hexadecimal string (the specific format will be specified later).
Value data should contain the following sections:
• Contract created transaction id (chain state database can use it to find block hash)
• Virtual Machine Version
• Contract creation parameters (see "Contract Deployment" page in the design)
• Contract creation data (constructor data)
• Contract bytecode
The interface for database reads and writes should be clear and extensible. Although designed for x86 virtual machines, other virtual machines can be used in the future.
The above task implements the most basic leveldb database available for x86 contracts. Currently, this database only stores some specific data such as contract codes, which can be expanded in the future. In addition, the design emphasizes the universality of the interface and facilitates the invocation of other virtual machines in the future.
QTUMCORE-119: Research needed functions in Qtum's version of libc
Description: We should evaluate the C99 standard library specifications to determine which functions should be supported in the x86 VM, with easy to use tooling provided to developers (ie, a custom toolchain). List the headers and functions that are common enough to warrant support , as well as is agnostic to the operating system, or can some way fit into the operating system like model of Qtum's x86 VM.
Task: To study the functions required in the libc version of Qtum
Description: We should evaluate the C99 standard library specification to determine which features should be supported in the x86 virtual machine and make it easier to use the tools provided to the developer (for example, a customized tool chain). Lists the most common function headers and functions that must be supported. These function headers and functions are agnostic to the operating system, or to some extent suitable for operating systems similar to the Qtum x86 virtual machine model.
Based on the c99 standard library specification, the Qtumx86 virtual machine implements a simplified version of the libc library for use by smart contract developers.
QTUMCORE-126: [x86] [Compiler] Figure out and document a way of compiling/packaging the QtumOS GCC toolchain for Windows, Linux, and OSX
Description: We should evaluate the C99 standard library specifications to determine which functions should be supported in the x86 VM, with easy to use tooling provided to developers (ie, a custom toolchain). List the headers and functions that are common enough to warrant support , as well as is agnostic to the operating system, or can some way fit into the operating system like model of Qtum's x86 VM.
Task:[x86][Compiler] Finding and documenting a way to compile/package QtumOS GCC toolchain for Windows, Linux and OSX
Description: As a contract developer, I don't want to compile the QtumOS toolchain when developing x86 virtual machine contracts.
For this task, study and document how to build the QtumOS GCC toolchain for Windows, Linux and OSX. Using this toolchain on all platforms should have the same experience. Following this document, anyone should be able to compile the pre-built version of GCC.
In order to use the same compiler tool for any common platform, the above task implements a cross-platform, pre-compiled gcc tool for smart contract developers*.*
QTUMCORE-127: [x86] [libqtum] Add basic blockchain data APIs
Description: As a contract devleoper, I want to be capable of getting basic blockchain data like network weight without needing to know how to write assembly code.
For this story, create a new project for libqtum to compile to libqtum.a using the QtumOS compiler, and place all definitions in a qtum.h file. The first operations to be added are some basic system calls for the following:
• Access to past 256 block hashes
• Block gas limt
• MPoS staking address for block (only the 0th address indicating the block creator)
• Current block difficulty
• Previous block time
• Current block height
These functions are not yet built into the x86 VM or Qtum, so these will just be mocks for now that can't be beta until later.
API list:
previousBlockTime() -> int32 – syscall(0)
• blockGasLimit() -> int64 – syscall(1, &return);
• blockCreator() -> address_t – syscall(2, &return);
• blockDifficulty() -> int32 – syscall(3);
blockHeight() -> int32 – syscall(4);
• getBlockHash(int number) -> hash_t (32 bytes) – syscall(5, number, &return);
Note, this inline assembly code can be used as a template for safely using the "int" opcode from C code, and should be capable of being put into a .S assembly file and used via:
//in C header
Extern long syscall(long syscall_number, long p1, long p2, long p3, long p4, long p5, long p6);
//in .S file
User mode
.global syscall
Long syscall(long number, long p1, long p2, long p3, long p4, long p5, long p6)
Syscall:
Push %ebp
Mov %esp, %ebp
Push %edi
Push %esi
Push %ebx
Mov 8+0*4(%ebp), %eax
Mov 8+1*4(%ebp), %ebx
Mov 8+2*4(%ebp),%ecx
Mov 8+3*4(%ebp), %edx
Mov 8+4*4(%ebp), %esi
Mov 8+5*4(%ebp), %edi
Mov 8+6*4(%ebp), %ebp
Int $0x40
Pop %ebx
Pop %esi
Pop %edi
Pop %ebp
Ret
Task:[x86][libqtum]Add basic blockchain data APIs
Description: As a contract developer, I hope to obtain basic blockchain data, such as network weight, without writing assembly code.
For this task, create a new project for libqtum, compile to libqtum.a using the QtumOS compiler, and put all definitions in the qtum.h file. The first operation that needs to be added is the basic system call to the following:
• Access to past 256 block hashes
• Block gas limit
• MPoS staking address of the block (only the creator of the 0th address indicator block)
• Current block difficulty
• Time of previous block
• The height of the current block
These features have not yet been built into x86 virtual machines or Qtum, so these are only temporary simulations that can be tested later
API list:
previousBlockTime() -> int32 – syscall(0)
• blockGasLimit() -> int64 – syscall(1, &return);
• blockCreator() -> address_t – syscall(2, &return);
• blockDifficulty() -> int32 – syscall(3);
blockHeight() -> int32 – syscall(4);
• getBlockHash(int number) -> hash_t (32 bytes) – syscall(5, number, &return);
Note that this inline assembly code can be used as a template for safely using the "int" opcode of C code and should be able to be put into an .S assembly file and used by:
//in C header
Extern long syscall(long syscall_number, long p1, long p2, long p3, long p4, long p5, long p6);
//in .S file
User mode
.global syscall
Long syscall(long number, long p1, long p2, long p3, long p4, long p5, long p6)
Syscall:
Push %ebp
Mov %esp, %ebp
Push %edi
Push %esi
Push %ebx
Mov 8+0*4(%ebp), %eax
Mov 8+1*4(%ebp), %ebx
Mov 8+2*4(%ebp),%ecx
Mov 8+3*4(%ebp), %edx
Mov 8+4*4(%ebp), %esi
Mov 8+5*4(%ebp), %edi
Mov 8+6*4(%ebp), %ebp
Int $0x40
Pop %ebx
Pop %esi
Pop %edi
Pop %ebp
Ret
The basic data of the blockchain is very useful for smart contract writing, but it is very difficult for ordinary smart contract developers to obtain this data without providing more tools. The above task provides an API for acquiring basic block data, enabling developers to quickly obtain relevant block data, thereby improving the efficiency of smart contract development.
QTUMCORE-128: [x86] [VM] Add very basic gas system
Description: As a contract devleoper, I want to test how intensive my prototype x86 smart contracts will be on a real blockchain.
For this story, add a very basic gas model to the x86 VM. There should be a new option added to Execute() that allows for specifying an absolute gas limit that execution will error upon hitting. It should also be possible to retrieve how much Gas was used during the execution of the program. For this basic gas model, each instruction is 1 gas. It is ok if there are edge cases where an instruction might not be counted.
Task: [x86][VM] Adds the Most Basic Gas System
Description: As a contract developer, I want to test the strength of my prototype x86 smart contract on the real blockchain.
For this task, add a very basic gas model to the x86 virtual machine. There should be a new option added to Execute() that allows you to specify an absolute gas limit, as long as you reach that value and you will get an error. It should also be possible to calculate how much gas is used during program execution. For this basic gas model, each instruction is 1gas. It is also possible if there are boundary scenes where the instruction may not be calculated.
The above task implements the most basic gas system of the x86 virtual machine, and can be used to calculate the specific consumed gas of the contract in the real blockchain.
QTUMCORE-129: [x86] [DeltaDB] Add very basic prototype version of DeltaDB
Description: As a contract developer, I want my prototype x86 contracts to persist within my own personal blockchain so that I can do more than just execute them. I need to be able to call them after deployment.
Right now, we will only concern ourselves with loading and writing contract bytecode. The key thus should be "bytecode_%address%" and the value should be the raw contract bytecode. The contract bytecode will have an internal format later so that bytecode, constant Data, and contract options are distinguishable in the flat data.
The exposed C++ class interface should simply allow for the smart contract VM layer to look up the size of an address's code, load the address's code into memory, and write code from memory into an address's associated data store.
Look at how the leveldb code works for things like "txindex" in Qtum and model this using the Bitcoin database helper if possible. There is no need for this to be tied to consensus right now. It is also also to ignore block disconnects and things That would cause the state to be reverted in the database.
Please do all work based on the time/qtumcore0.15 branch in Qtum Core for right now. Also, for the format of an "address", please look for "UniversalAddress" in the earlz/x86-2 branch, and copy the related Code if needed.
Task: [x86][DeltaDB] Add the most basic version of the DeltaDB prototype
Description: As a contract developer, I hope that my prototype x86 contract can exist in my own blockchain so that all I can do is not just run them. I hope to be able to call them after deployment.
For now, we only care about loading and writing contract bytecodes. Therefore, the key should be "bytecode_%address%" and the value should be the original contract bytecode. Contract bytecodes will have an internal format so that bytecode, constant data, and contract options can be distinguished in flat data.
The exposed C++ class interface should allow the smart contract virtual machine layer to look up the size of the address code, load the address code into memory, and write the code from memory into the address's associated data store.
Look at how the leveldb code for things like "txindex" in Qtum works, and if possible, model it using the Bitcoin database helper. There is no need to associate this issue with consensus. It is also possible to temporarily ignore the disconnection of the block and cause the state of the database to recover.
Now do all the work based on Qtum Core's time/qtumcore0.15 branch. In addition, for the "address" format, look for "UniversalAddress" in the earlz/x86-2 branch and copy the relevant code if necessary.
The above task adds the most basic database DeltaBD to the x86 virtual machine, which can be used to store contract status and is a necessary condition for contract invocation*.*
QTUMCORE-130: [x86] [UI] Add "createx86contract" RPC call
Description: As a smart contract developer, I want to be capable of easily deploying my contract code no too much worrying.
In this story, add a new RPC call named "createx86contract" which accepts 4 arguments: gas price, gas limit, filename (ELF file), and sender address.
The ELF file should be tore apart into a flat array of data refer the contract data to be put onto the blockchain.
  1. int32 size of options
  2. int32 size of code
  3. int32 size of data
  4. int32 (unused)
  5. options data (right now, this can be empty, and size is 0)
  6. code memory data
  7. data memory data
Similar ELF file processing exists in the x86Lib project and that code can be adapted for this. Note that there should be some way of returning errors and warnings back to the user in case of problems with the ELF file.
After the contract data is extracted and built, a transaction output of the following type should be constructed (similar to create contract)
OP_CREATE
The RPC result should be similar to what is returned from createcontract, except for a warnings/errors field should be included, and the contract address should be a base58 x86 address, and any other fields invalid for x86 should be excluded
Task: [x86][UI] Add "createx86contract" RPC Call
Description: As a developer of smart contracts, I hope to deploy my contract code very simply.
In this task, a new RPC call named "createx86contract" is added, which accepts four parameters: gas price, gas limit, filename (ELF file), and the sender address.
The ELF file should be split into a set of data indicating that the contract data was placed on the blockchain.
  1. int32 size of options (options, shaping 32-bit size)
  2. int32 size of code (code, shaping 32-bit size)
  3. int32 size of data (data, integer 32-bit size)
  4. int32 (not used)
  5. options data (options data, now empty, size 0)
  6. code memory data
  7. data memory data
There is a similar ELF file processing in the x86lib project, and its code can be modified according to the requirements here. Note that when there is a problem with the ELF file, there should be some way to return errors and warnings to the user.
After extracting and building the contract data, a transaction output of the following type will be constructed (similar to createcontract)
OP_CREATE
The RPC result should be similar to the one returned in createcontract, except that it contains a warning/error field, and the contract's address should be a base58 encoded x86 address. Any other fields that are invalid for x86 should be excluded.
The above task adds a new qtum rpc call, namely createx86contract. The rpc can load smart contracts directly from the elf executable file and deploy it to the blockchain. It also adds error return mechanisms to allow developers to know the contract deployment status.
summary
This chapter contains the most critical implementation details of the Qtum x86 virtual machine. Based on these tasks, the Qtum team has implemented the first virtual machine that can deploy and run x86 smart contracts. It also provides tools for writing smart contracts in C language. The prototype now supports writing contracts in C language. The implementation of the Qtum x86 virtual machine continues, and the follow-up Qtum project team will continue to expose the original design documents. Interested readers will continue to pay attention.
submitted by thisthingismud to Qtum [link] [comments]

FAQs

FAQs - All Frequently Asked Questions Posted and Updated Here
Q: I have lost massive sums holding various cryptocurrencies since leading coins such as Ethereum have fallen -88% peak-to-trough so far in 2018 and it looks as if it will fall further given the overpriced nature of Ethereum. Vitalik Buterin, the creator of Ethereum said himself that the cryptospace is way too overvalued. That said, why do I want my money tied up on your platform for 9 months? What are the advantages? How much risk am I taking?
A: With Hansecoin, multiple investors will be able to own a piece of the capital gain potential and yield of real estate, some land, an apartment, or an entire apartment complex. The asset provides a floor to the price and increases stability versus speculative tokens.
We are building out the world's first tokenisation platform that will be compliant with regulations. The first project Use Case when secured may deliver underlying yields of 7 to 11.4% or higher, potential capital gains, and provide bonuses and access to future project tokens at an attractive discount versus those joining after the Vesting Period. There is a revolutionary future in its application across multiple asset classes. Notably, this tokenisation approach may become a template for asset backed token projects.
With proof of concept at hand and construction started, the project shall be scaled up as several additional hard asset projects are in the queue and the platform can be white labelled. Our platform offers a replacement tool for the transaction-cost-inefficient closed-end fund structures or venture capital transactions while remaining small, solid, compact and in full regulatory compliance.
Reduced Risk: We are immune to the direction of cryptospace. Even if Ethereum were to go to zero, our token would still be valid and contractually binding. In light of the steep losses in Ethereum and other coins, the participant can stop the hemorrhaging by locking in their cryptocurrencies at a fixed rate in euros for the next 9 months while taking comfort in knowing the above benefits apply, ie, yields, capital gains, bonuses, future project access at a discount, etc. Further, the potential participation in prime residential real estate located a brief commute of 15 minutes from the city center in Tallinn, Estonia carries low risk given the history of otherwise equivalent, yet in terms of quality, design and attractiveness, inferior real estate projects launched in the neighbourhood which still sold out ahead of schedule. Indeed, the demographics of families in formation together with Estonia leading the EU in economic growth is a powerful combination contributing to the breakneck speeds of development in Tallinn.
Estonia has continuously the highest average GDP in the EU (if you compare the current members from 1994 to 2018) and thus is the EU’s fastest growing country. Estonia has been billed as the world’s leading digital nation given its pioneer status of its digital ID card program, the spread of free and ultra high speed WiFi across the country, being the pond from where Skype and Pipedrive sprung, and more. Today, its welcoming position on blockchain technologies, equivalent to that of Switzerland, as well as its e-Residency program is well known. e-Residency enables businesses to transact goods and services regardless of geographic location with the digital signature capacity known from the ID card program. Estonia’s regulators are sincerely collaborative, open for discussion, and evidently working with substantial commitment to create a fair system of regulation, monitoring and enforcement of the current legislation. They are comparatively solution driven so as to remain welcoming to the blockchain community. This explains why Estonia has the highest number of ICOs launched per capita and is ranked #5 worldwide.
From the CEO of CoinMetro, Kevin Murcko: “Although I get approached quite often to advise on ICO projects I rarely bite. Most, while they may be great 'back of napkin ideas' they usually lack substance and their teams, while sometimes quite elaborate, lack the drive, hunger, and experience to take a great idea and turn it into a great business. HanseCoin is different. The company focuses on a very specific use case for tokenization, the Asset-Backed Token, and it puts it to the test.
Not only does it provide a hedge against crypto volatility but it puts that money toward the creation of a regulator-approved platform for tokenizing any hard asset.
As a member of the Supervisory Board, I helped design the tokenization structure and I believe there is a revolutionary future in its application across multiple asset classes.
As As CEO of CoinMetro is it my job to ensure that we are constantly on the lookout for ways to gain market share and add value to not only our platform but the whole of the crypto ecosystem ... Essentially we are talking about an extension of the ICOexpress, call it a 'module', one of many in the works.”

Q: How are you compliant? Many ICOs fail to be even minimally compliant.
A: First, this is not a typical ICO but this structure represents the next evolutionary stage in asset financing in the cryptospace. We are one of if not the world’s first actual asset backed token (ABT) ICO backed by real estate. Together with our counsel and our partners from Coin Metro, we have stayed in lock-step with the regulators here in Estonia to ensure that regardless of future regulatory decisions made, due to the versatility of the project structure, it will remain compliant without that adversely affecting the business. Our token remains a utility token as demonstrated by PricewaterhouseCoopers (PwC) as it is neither a security, a debenture, nor a money market instrument. Still, we are prepared to issue a security token in the future should it become a suitable option and make sense to our expansion. Albeit that from our discussion with the relevant authorities it seems unlikely today Estonia may well pass legislation in this regard. Most importantly, leading companies are connected to our platform and its first project: we have Capital Mill, a leading developer and asset manager, as the real estate project manager, Uusmaa Kinnisvarabüro, the oldest and largest brokerage firm in Estonia as the residential sales agent, SWECO Projekt as the engineering company, 1Partner, a leading valuation company, as our appraiser, Telora AS as our supervisor, Studiomark as our architectural firm, and leading Estonian construction firms allowing the project to be built on time and in suitable quality for the residential clients.

Q: Is VPAT compliant? Does VPAT obey regulation? What about the other tokens PPT and VBT?
A: VPAT is an island, disconnected, and not tradable. Is it non-transferrable thus not a security. VPAT is heavily vetted and all VPAT holders are registered via AML/KYC with CoinMetro. Should our Issuing Company decide to issue another token (PPT, etc), that token may become tradeable and subject to regulatory law at that point.
There is an inherent difference and segregation of the VPAT from the potential PPT or VBT tokens. At the end of 9 months, the VPATs are burned, swapped, or extended and only then are PPTs issued. VPAT holders get various bonuses and preferred issuance of PPTs.
The VPAT is a centralised virtual token which results in a receipt issued to the VPAT participants (like a voucher). It is not an Ethereum based ERC distributed token unlike the PPT which may become subject to the legal, technical and regulatory environment.
As always, we will comply with any future legal, technical, and regulatory law set forth.

Q: What are the advantages of your platform?
A: Our platform offers a replacement tool for a variety of transaction cost inefficient transaction structures. The unwieldy closed-end funds of yesteryear simply front load developments with heavy hand costs for management and distribution. They typically start at around 10 million euros. Friends & family and crowd funding asset capital raises are typically limited to 1.5 – to at best 2 ¼ million euros. Our platform enables a far more efficient and less costly way for anyone who wishes to tokenise a project and raise capital between 1.5 and 10 million euros for their hard asset project, including but not limited to real estate. Blockchain simplifies and facilitates transactions by removing redundant layers.

Q: Future plans to expand?
A: An asset backed tokenisation does not end with standard real estate. This can also be done with other associated hard assets such as factories which include identifiable, traceable and productive machinery and equipment. Indeed, the founders and their partners are themselves invested in industrial assets, farming and agritech. We believe that such capital intensive segments are ideal candidates for subsequent, larger asset backed tokenisation capital raises when the concept with its technology and documentation is proven.
Eventually, HanseCoin, subject to project success, markets and regulation, may even become an issuing house with an investment advisory license. We will also enable others to white label our product since a number of projects have expressed deep interest. Indeed, as stated in the above article, a number of notable voices in the blockchain space such as Multicoin Capital partner Kyle Samani have said, "Using blockchains, you can securitize any asset for 1/100th the cost.” According to Prof. Stephen McKeon of the University of Oregon, "We will undoubtedly see tokenized real estate securities in 2018." An analyst at Apex Token Fund went on to explain, "A new level of liquidity is created when tokenizing traditional assets. This liquidity makes it faster and easier to rebalance a portfolio as the market changes."

Q: Please explain unpaid taxes to the Estonian government as raised here: https://www.reddit.com/CoinMetro/comments/9lyjie/comment/e7g8ws6
A: First, Tiskre Residentsid paid its October land taxes. The company had EUR 3,407.31 land tax to pay which EMTA demands on Oct 1, and we had scheduled to pay them alongside TSD declaration by Oct 10. Notably, we paid it today ahead of time. There is no tax debt and we would expect this to be reflected with the usual delay at sources such as ‘Inforegister’.
Second, Reval Grundwert is a family venture which arranges services to group entities including concept and implementation design, engineering and supervision, planning, family investment. A previous accountant miscalculated and misrepresented two smaller tax filings for which she taken to account and court. The restatement and reconciliation is underway with EMTA.

Q: How do you securitize the asset? Is it asset backed at the beginning?
A: The VPAT token is issued and provides a receipt as noted in the info memo. Funds are employed for the project platform infrastructure/software development and to secure the use case. The owners contribute the land into the asset company at a EUR 459,810 or a 15.4% discount to appraised market value to effectively sponsor the platform development for the Use Case even ahead of the full raise and the potential PPT issuance. The externally appraised value only reflects a sale as is: no potential, no expected value increases, it is considered conservative. Initially, the Issuer provides a deposit to the Asset Company owners in lieu of the irrevocable undertaking to, in the future, enter into the contracts. The deposit in this instance covers 90% of the fixed asset price. All-in the relevant discount to fair market value is thus 23.8% which should be considered a substantial buffer.
From the closing of the hard floor raise through the VPAT, the Issuer by securing itself with the future documentation in escrow, irrevocable undertakings locked in, and a pledge over the asset company's shares, is collateralised throughout its infrastructure development phase. Even the VPAT is an asset backed token.
Note, in the unlikely event that the tokenisation were to fail with no regulatorily compliant tokenisation at hand or the Issuer to fail in its development, the Issuer would accelerate the share pledge against the Asset Company. The asset could be sold and even a fire sale should suffice to cover the Issuer's relevant risk exposure, a restructuring, rescission, or new development in light of the aformentioned large discount.
In case of questions please do not hesitate to ask.

Q: How long do actual building developments take? [USE CASE]
A: In a simplified form and besides weather conditions etc., individual buildings and their build out time depend on the building types of which there are 2 in sector 1 (one apartment, one row house), another one in sector 2 (simpler row houses) and again two types in sector 3 (apartment buildings) plus a kindergarten on the plot between 2 and 3. Some of them such as in sector 1 individually take between 6 and 7 months to build core and shell, and subject to the client package requirements (three pre-defined), the interior furnishing and fittings takes between 1 and 1.5 months. The row houses in sector 2 can be erected within 5-6 months, then interiors and the furnishing as above plus landscaping (seasonal). The affordable housing in sector 3 could be built in the same time frame for the simpler apartment buildings and about 11 months for a grouping of three which are best erected as an ensemble.
A time schedule has been defined by the accredited, experienced external project management firm with owners, engineers, architects, interior architects and reputable construction companies which shows the targeted build out rhythm with overlapping and parallel build-outs. You can find this information in the project model section p.30 onwards. If you have specific questions do not hesitate to contact us and we shall be glad to go through this in applicable detail with you.
If you look at the plots and the drone videos listed for the asset company you can see that infrastructure (road, electricity, gas, water, sewage and street lighting) has been built out already alongside sector 3 and 2. Key information and extensive descriptions are also at hand in the info memo.

Q: Are all incoming ETH converted to EUR immediately?
A: Yes, though subject to market conditions. For example, the time it took to get sufficient confirmations was considerably longer in December 2017 when the crypto market was spiking. Until our minimum target of 2.281671m EUR is received, the deposit required to secure the projects initial use case, all incoming ETH is converted to EUR. Once this amount is surpassed, Hansecoin reserves the right to hold qualities of ETH as it sees fit based in its internal risk management policies.

Q: What happens if the soft cap for your asset raise is not met?
A: I presume you are referring to the hard floor of EUR 3.275 M as a fall-back rather than the soft or target cap. Were that hard floor fail to be reached, the software and platform infrastructure development would have to be carried on by HanseCoin preferably with its community in parallel to progressing with the road map, however, after an extension window of e.g. another 10, 15 or even 30 days were to run out before reaching the hard floor, and if no restructuring of the agreements with the asset owners could be agreed upon (deposit levels, timing), the development would have to carry on without securing the use case. The latter would remain an obligation of the owners to develop without HanseCoin. In turn, in such an unlikely event, HanseCoin would have to secure another Use Case for which it has two more assets at hand in the same attractive area, one in a comparable development stage and one at an earlier stage. Both would allow for collateralisation and lower deposit levels so that a replacement would be a suitable option. As stated in the info memo if less (as in not enough to entertain any of the other options) is raised until a future PPT issuance on the basis of the Hansecoin platform, the VPAT may have to be rescinded.
Notably, the aforementioned time frame and cascade of options should, from our perspective, allow HanseCoin sufficient capacity to attain sufficient commitment from VPAT partners and progress with the Asset Company on mutually agreeable terms.

Q: What if you can't get approved to go on with the development, or when the approval is getting delayed an unreasonable (>1y?) amount of time?
A: The risk of development of the tokenisation to become regulatorily compliant is mitigated as follows: HanseCoin will file alongside its efforts to create the PPTs, its application to attain an investment firm license in Estonia allowing it to act as fund manager. This puts it on the safe side if considerations of certain tokens as securities were to become effective. The board and supervisory board of HanseCoin assisted by counsel and auditors will take all necessary steps and employ their professional experience to meet the requirements and become licensed in the defined regulatory process. As indicated in the roadmap, CoinMetro as an exchange requires substantially more comprehensive licensing for a variety of their additional services to be rendered in the future and is seeking theirs with a view to having them in place by end of Q2 2019.
If the technical development of the tokenisation were to be delayed beyond the date of regulatory compliance, HanseCoin with the VPAT has the option to seek an extension to complete whatever technical matters would have to be resolved, albeit that the economic interest at hand should mitigate that. HanseCoin is keen to issue, list, and expand their tokenisation platform approach to a wide audience of potential participants and process a variety of underlying hard assets, as only then it is successful. The interest of HanseCoin's founders and team are aligned with the VPAT holders. We will push the development with determination and daily grind. As such we believe that a delay as you indicated beyond a month or even three months over the Vesting Period whilst technically possible is highly unlikely.

Q: What can HanseCoin offer me that I already do not have access to? I can already directly invest in property or buy equity in residental property via crowdfunding websites etc. What I cannot do as a U.K. citizen is easily invest in overseas property, does HanseCoin fix that problem? In addition will HanseCoin give people in emerging markets easy access to say, European and American property? What kind of restrictions might I face if , as a U.K. citizen, I wanted to buy an ABT for a U.S. property?
A: You can own a piece of real estate in any jurisdiction via our platform, ie, fractional ownership. As we onboard new projects, some will be European. The US comes with certain restrictions that may make onboarding US based projects an issue. At this time, the projects of interest are non-US. We will be sure we are compliant with any projects we approve.
Re crowd funding, on our home page at Hansecoin.com, scroll down and read:
Let’s talk about The Gap.

Q: Can I own Hansecoin if I am a US resident?
A: As referred to in the disclaimers of the info memo and the webpage, HanseCoin with its ongoing private sale and the upcoming public sale in principle is currently not offered to participants who are U.S. residents as regulation so implies and we are not offering securities at this time. Without providing legal advice, a private pre-sale may e.g. allow up to 35 non-accredited investors to participate under certain limitations and exemptions under rule 506 (b), however it may have little bearing on us as the private (pre-)sale of Hansecoin VPAT's would likely be considered a form of general solicitation in the U.S. Thus, in consideration of rule 506 (c) only accredited investors, i.e. those who can verify that they are, may have a path to participate in the private (pre-) sale. May we suggest to consider this with counsel and message us directly so that we can review the matter, in case you are an interested accredited investor. We obviously value your interest and shall be glad to continue the dialogue. It is not unlikely with upcoming regulation in Estonia and the EU as well as HanseCoin progressing to become a regulated investment firm in the near future that future issues including a potential mastercoin could be offered also in the U.S. We certainly would be glad if market rules were to allow truly global coverage.
NEW FAQS FOR RON TO POST ON WEBSITE:

Q: Did I understand correctly, that HanseCoin is a overarching platform for more asset backed token projects? That token PPT token itself is not limited to the current real estate (RE) you are developing? If so, what happens if let's say, the current RE is finished and you start another project, will there then the same process as now, but with a PPT2?
A: HanseCoin is an overarching platform and not limited to one project, albeit that the first project contributed at a significant discount to the platform to support its launch carries itself and the platform build-out. HanseCoin's goal is to efficiently onboard a variety of projects which fit the 'Gap' range for development capital, i.e. small/mid cap project financings for hard assets. We have three projects in the short term pipeline which shall be launched in stages over the next months. The structuring employed in the initial project can, as per current review be rolled out in more than a dozen, potentially more jurisdictions of the current EU-27. Variations of the structure used by HanseCoin render it sufficiently resilient to over time include more hard assets including factory machinery and equipment as well as segments such as rolling stock. However, we start with something small, solid and compact in real estate development where platform and participants in its onboarded project(s) can capitalise on sufficient potential to reap liquidity premiums and reduce transaction cost through tokenisation.

Q: Can I draw a similarity to Coin Metro’s (CM's) ICO express here: Both HanseCoin and ICO Express to onboard external projects? Now you guys lead the real estate (RE) development yourself, but maybe the next project is developed by an external team but uses your platform for tokenization?
A: I would say that we will work closely with CM's on their ICO Express, as there is no need to reinvent the wheel and we believe that they are in the process of setting up an excellent platform. Technically, I would consider us the Asset Financing Module associated with/connected to their platform. Given our understanding of RE in specific and asset financing in general the intention is to process a series of projects and develop the capacity of HanseCoin to assess, validate, wherever needed structure and adapt/improve underlying projects with strong project financing parties (project managers, engineers, architects, banks, brokers, supervisors, construction companies) etc. - we facilitate the RE development or third party projects employing HanseCoin as the project tokenisation platform.
In other asset finance segments, such as factory and machinery, the industries we can work with are widely varied, as Chris just stated, this can be biotech as well as manufacturing, the key is the underlying asset.
For retail solutions the logistics solutions connecting e-commerce and highstreet require substantial investments in hardware, data processing capacity and software. Whilst the line there blurs between pure hard assets and its steering/process technology, the physically distributed logistics aspect is intriguing and we believe we can in the future benefit from tokenisation.

Q: I'm interested in finding out more re contributing to the private sale (amount of funds being raised, minimum contribution size, etc).
A: Pursuant to ongoing discussions with a variety of interested parties including family offices across Germany, Austria and Scandinavia committing to certain amounts we have created a sliding incentive scale for those entering the Private Sale:
During the current phase up till the hard floor for the platform build-out we offer small, yet attractive discounts to early bird participants, whereas larger ticket sizes obtain higher discounts. Parties committing participations of EUR 50,000k receive a discount (as a token amount bonus) of 2.25%, EUR 100,000 equates 2.5% discount/bonus, EUR 200,000 results in 3% discount/bonus and tickets of EUR 500 k and above receive a 4% discount/ bonus.
For those followers here on Telegram the ticket sizes can be amended but discounts/bonus tokens of 1% kick in starting at EUR 10,000 (equivalent in ETH).
For the sake of good order, recently we have done one brief flash sale to reward our hardcore followers, tech contributors and early birds at a significant one time only 5% discount/bonus. We do not envisage it to be repeated.
As the token vesting period ends after latest 9 months and a tradable token is then issued even the lowest rung of discounts is slightly better than many peer products and approaches, certainly better than parking it in money market products. For small to medium size participants, generally, parking liquidity in attractive vehicles with underlying real estate and hard assets in Europe is not such a bad idea at this time. The tokens are available at short notice.
If this is of interest to you please advise which volumes in the above brackets you wish to pursue and we shall open the Private Sale to you.

Q: How does HanseCoin compare to other companies attempting to issue asset backed tokens? Aren’t such tokens securities?
A: Hansecoin has a unique approach in that it has achieved regulatory compliance even with token issuance. Have a look at the Whitepaper. Normally, tokens of this nature will be regulated as securities. So for HanseCoin to stay compliant, we have a regulatorily compliant token (VPAT) for the platform which is already asset backed. It is non-negotiable, non-transferrable, and non-tradeable thus is not a security token. HanseCoin will later issue tokenized securities known as PPTs upon being regulated as an investment firm in lock-step with what EU / Estonian regulators decide.
As noted, Hansecoin is live already. Its original token, the VPAT, is already asset backed and called an ABT. Due to substantial demand from private equity we are in a private sale at the moment. If and when suitable a public sale may be announced.
So, no more weeks of waiting as with so many others. If you are interested to enter into the private sale please register and let us know. [my note: Smartlands has launched their mastercoin which should be a security since it is tradeable but not issuing tokenized securities as of yet.]

Q: How can HanseCoin claim to have first mover advantage compared to, say, Smartlands, when HanseCoin hasn't even finished its capital raise or developed its platform? If my understanding is correct, Smartlands completed their token sale last year and have already developed their core platform
Also, I'm finding the whitepaper diifficult to digest. It’s very wordy. I'm sure the key points could be presented more succinctly.
A: For the sake of good order, Smartlands has placed its token but is not asset backed from the begininng. By the way, it has lost -24.8% from its peak 4 days ago, though through its excellent PR, I believe it is the only coin that has outperformed bitcoin this year, which attests to the power of the asset backed token.
That said, Smartlands does not have any live project. HanseCoin has not made such claims but is the first regulated asset backed token in that it has the underlying asset pledged to it in proportion to the funds raised, and one live project plus three which its shareholders have either secured or control over. The issuance of the HanseCoin PPT token is solely deferred due to and dependent on the current regulation. In order to become independent from that, HanseCoin will file to become a regulated investment adviser in December so that by February it can issue securities and thus tokenised securities no matter what ambiguity may exist then for other token approaches.
In the meantime, those who are holding HanseCoin VPAT tokens whose value is not pegged to any cryptocurrency but to hard assets sidestepped the recent huge drop seen in bitcoin and most all other cryptocurrencies. The average cryptocurrency has now lost over 90% of its value in 2018. Meanwhile, the value of the VPAT is pegged to the euro and the underlying asset.
Besides blockchain related software improvements, the current platform development is predominantly geared to the expansion into 17 EU jurisdictions and related systems compatibility, database design, and applicable interfaces, compliance process designs, linkage with exchanges, as well as research and development into future tokenisation components.
As to the whitepaper, based on requirements of the EFSA (the Estonian regulator), PWC Legal as our counsel, auditors, and tax advisers, we have to reflect the matter comprehensively. The summary pages tend to be important whilst the flow charts are there to assist with visuals.
Whilst you may consider it excessive, we have condensed both the tokenisation and the use case significantly. Some of our team have longstanding careers in investment banking, corporate audit, and structured finance. Any offering circular in asset backed bonds, a closed end fund prospectus or an euqity placement memorandum would run into hundreds of pages and a 8x multiple word count.
Our target was to simplify the sourcing, issuance and distribution of asset financing with benefits to participants and developers alike whilst substantially reducing transaction cost to enable and accelerate that. That is the key proposition of blockchain and only our platform is live and doing that. Having a listed token today is secondary.
Here are some bullet points which focus on the key points to our platform:
· First-mover Advantage - HanseCoin is the world's first regulated blockchain platform to tokenise hard assets;
· Technology - Solid Blockchain technology applied properly greatly lowers transaction costs across the board from project inception to completion thus participants reap high yields;
· Demand - Leading developers and sponsors across Europe wish to onboard their projects onto our platform;
· Regulatory Compliant - Regulatory passporting capacity into the majority of EU markets and capacity to go beyond;
· Client Access to Higher Yield - Development projects bring high yields to people who are not classic development investors at a time of historically low interest rates;
· Risk Mitigation - Excellent diversification opportunity to peg capital to the value of the underlying hard assets.
· Ongoing Transaction & Success Fee Generation - The platform generates ongoing transaction fees per project. The more projects and more participants, the higher the profits which are shared between Participants and the platform.
But the way, together with CoinMetro (www.coinmetro.com) and its CEO Kevin Murcko we will at Slush to present their exchange and our platform as the first solid Asset Backed Token for hard assets to listed on CoinMetro.

Q: How do projects such as https://www.meridio.co compete with HanseCoin?
A: Meridio.co offers fractional ownership which, whilst fine as a concept, does not lend itself to fit the tokenised securities approach EU regulators are starting to take (they have MIFID, AIFM, etc. to work with) and the specific segment of project/asset financing where development capital is actually required, the small and mid cap segment in Europe and beyond (we call it 'the gap' of EUR 1.5 to EUR 10 m of equity participations in projects) is not addressed. HanseCoin already owns shovel ready land and its platform is regulated.

Q: A few questions:
1a. Which tokens do private sale participants receive for their contribution? VPAT, PPT or both?
2a. Are VPAT tokens temporary in nature, having no further use once they have been swapped or burned following the completion of the platform development?
3a. What is the main potential benefit to a participant in acquiring VPAT tokens?
4a. Is PPT the participation token for the first project only or for all future projects supported by the platform? (Or something in between?)
5a. What is the HanseCoin master token?
A:
1a. The private sale participants receive VPATs.
2a. The VPAT is the asset backed token which starts the platform and provides exclusive access to (a) the PPTs prior to them becoming tradable as well as (b) the VBTs. All VPATs are burned, swapped, or extended at the end of the vesting period.
3a. The VPAT provides exclusive access to future tokens including the tradeable PPT, VBTs for bonuses, and potential further privileges which the platform may grant to its early sponsors and participants. The VPAT is also the only path to secure discounted PPT token access.
4a. As of today, the PPT covers the initial project use case. Each additional project will see an appropriate amount of PPTs issued to reflect the initial capital requirement of the underlying asset development project at its inception. During the platform development and regulation phase, additional VPATs will be issued in regard to further projects in the pipeline. The first PPT will be known as HanseCoin 8. Each additional project will countdown from 8 thus the second project will be known as HanseCoin 7, and so forth. Upon the first issuance and listing of a PPT, thus subject to further regulation of tokenised securities, it is envisaged to have VPATs only issued for each private sale phase.
5a. A master coin which represents not just one specific project but the value of HanseCoin as a whole company will be issued at some point when project tokens have gained critical mass in terms of projects, countries/markets covered and distribution. It seems likely that the countdown will fit well with this. The valuation will be dictated by the ongoing projects, projects to be on-boarded, and any white-labelling on the HanseCoin platform. We envisage that all original VPAT holders should have privileged access to an attractive bonus for the master coin which shall be accrued through VBTs during the PPT issuance period. These specific VBTs would vest until the issuance of the master coin. This is an exclusive benefit to the initial VPAT participants.

Q: So are VPAT and PPT *categories* of token rather that the actual tokens themselves? In other words, HanseCoin 8 is *a* PPT not *the* PPT? Also, if private sale participants receive VPATs, then why does hansecoin.coinmetro.com offer "HANS" tokens, which Chris tells me refers to "HanseCoin 8" tokens? Shouldn't coinmetro be offering VPAT tokens at this stage, not PPT tokens?
A: VPAT is a virtual token. PPT will be a compliant tokenized security we issue sometime next year, potentially ahead of the projected 9 month vesting period of the VPAT. The PPT will be compliant, in line with regulations as they are formed.
HANS is the ticker for the VPAT. Only the first phase VPAT currently exists that represents the first use case. HanseCoin 8 is the first use case. HanseCoin 7 will be the second use case, ticking down by one each time a new project is launched.
By the way, there is no such thing as a security token even though STO stands for security token offering. But then, many of the terms used in the cryptospace have been bastardized such as the term 'whitepaper'.

Q: I presume the VPAT for the second project will have a different ticker? What is the ticker for the first PPT (HanseCoin 8)?
A: A ticker will be assigned then by the listing exchange and the symbol is not decided, yet, although it seems reasonable to consider a variation of HANS (which is the ticker for the first VPAT) plus an indicator (technically, the ticker can remain as is whilst the sub-category is defined as an index).
submitted by HanseCoin to u/HanseCoin [link] [comments]

ICOs - One Click Import Demo Version 1.4 What is Blockchain - YouTube Bitcoin from the Command Line - Sending Bitcoin ... Bitcoin Cryptocurrency for Beginners 💰 - YouTube Blockchain - How To Verify A Bitcoin Transaction And Get ...

Buying crypto like Bitcoin and Ether is as easy as verifying your identity, adding a payment and clicking "Buy". Sign up for our Wallet today. P2P Network¶. This section describes the Bitcoin P2P network protocol (but it is not a specification).It does not describe the discontinued direct IP-to-IP payment protocol, the deprecated BIP70 payment protocol, the GetBlockTemplate mining protocol, or any network protocol never implemented in an official version of Bitcoin Core.. All peer-to-peer communication occurs entirely over TCP. Apr 10, 2019 - Fully editable UK Driving Licence PSD Template (photoshop) - Buy with Bitcoin (COMPLETELY ANONYMOUS!) Once you see in that format, click “Into Table” in the top left corner. 2.4. Proceed similarly from step 1.7 onwards. You will need to generate a new query for each of your coins. Simply change the bitcoin part in the API link to whichever coin you’re interested in. Replace bitcoin with your preferable coin’s ID as shown in the ticker. Remember, use the ID, not the coin name. They are ... Assemble the block header as laid out in the Bitcoin block hashing algorithm, using the data provided in the block template along with your very own merkle root. Note that miners are expected to check the "version" number, and should not create blocks with versions they do not understand unless the server instructs them to do so with the "version/force" or "version/reduce" mutations - you don ...

[index] [19078] [46929] [51542] [12403] [18406] [34018] [16200] [48998] [17935] [45018]

ICOs - One Click Import Demo Version 1.4

Tracking Bitcoin Transactions on the Blockchain ... How To Verify A Bitcoin Transaction And Get Your Hash ID - Duration: 2:17. Crypto Currency Wealth 75,594 views. 2:17. How to Accept Bitcoin on ... Blockchain explained. Shai Rubin, CTO of Citi Innovation Lab, explains in an easy and simple way the basics of blockchain. ATTENTION: I AM NOT ON TELEGRAM!!! To anyone who is being approached under the scam please report to Telegram. How I got Rich off Bitcoin! We've all been hea... Cryptico is the best premium website template for ICO Agencies and Cryptocurrency Investments company. Cryptico is easy to use, it provides everything you need to create great looking website ... One of the common complaints with Bitcoin is that it’s pretty hard to get started, and there’s a lot of overhead to making accounts and sending transactions....

#