Minergate Review 2020 - Is Minergate scam or legit ...

Ethereum Classic

Ethereum Classic is an open, decentralized, and permissionless public blockchain, that aims to fulfill the original promise of Ethereum, as a platform where smart contracts are free from third-party interference. ETC prioritizes trust-minimization, network security, and integrity. All network upgrades are non-contentious with the aim to fix critical issues or to add value with newly proposed features; never to create new tokens, or to bail out flawed smart contracts and their interest groups.
[link]

Classic Ether Market & Trading Discussion

Ethereum has forked and moved to a new chain. This sub is for the discussion of the Ethereum chain which didn't move the coins.
[link]

Ethereum 's Top 7 Mining Tools in 2020

If there is a cryptocurrency that has acquired popularity close to Bitcoin, then it is Ethereum. It is among the leading crypto-currencies when it comes to market capitalization. Ethereum is not just a cryptocurrency, but it is also a blockchain system that is useful in creating decentralised applications. Since Ethereum Blockchain is used by most companies now, it is gaining popularity among Ethereum miners and developers.
Ethereum mining is a great way to make more cash. Benefiting from cryptocurrencies in p is a perfect option. Since many applications for Blockchain depend on Ethereum. Ethereum mining is going to be lucrative, as its price is expected to grow. The Ethereum minimum can be simplified with the use of the best Ethereum software. There are some apps like that on the market, and we've got the seven best for you here.
7 Ethereum 's Best Apps:
ETHminer- This is an Ethereum mining application which is supported on Linux , Windows, and Mac. It is also possible to use the Ethash algorithm, luke Ellaisma, Musicoin Ethereum Classic, Metaverse, It is a command-line program that allows you to construct shortcut commands using a Windows cmd / batch file or Linux Bash script.
The next software on our list is CGMiner-A, which was published in 2011. It is one of the common choices and has compatibility with GPU, FPGA, and ASIC. It is open-source software and can cause advanced detection of blocks.
It is written in C; Ethereum developers are able to save a hash rate without delay using this Ethereum mining programme. On Linux , Windows, and Mac, this program is open.
BitMinter- The graphical interface is transparent and it links easily to the Bitminter mining pool. This software was launched in 2011 and has more than 450,000 user accounts registered. The Java Network Launch Protocol (JNLP) is the foundation of its operations. Linux, Windows and Mac are also compatible with this programme.
Claymore- This is one of the most powerful mining applications for Ethereum, and without delaying the mining pace, you can scale up the hash rate. You can also mine other cryptocurrencies like Lbry, Pascal, Siacoin, and Decred using this Ethereum mining programme. This software is Linux and Windows compatible and not Mac compatible.
WinETH- If you are looking for an Ethereum mining app that is fast and simple to use, then this is the one for you. It is comparable to WinETH, but it has a simpler Interface and a smarter algorithm that makes it easy to use for Ethereum miners.
Minergate-It was the first mining app for Ethereum to deliver merged mining. You can use this app to concurrently mine two separate coins without impacting the main coin's hash rate. In addition, this coin will also tell you about the market's most valuable coins.
This programme can be used by Ethereum miners to mine other coins, including Zcash, Liteoin, Monero.
BFGMiner- This programme is written in C and operates on various Linux, Windows and Mac operating systems. You will mine crypto coins and have both SHA256D and Scrypt on its algorithm. It also offers you total support for tracking.
Conclusion- These are some of the popular mining applications for Ethereum that you can use. If you would like to know more about the creation of Ethereum, or Ethereum mining, If you wish to know more about Ethereum development, or Ethereum mining, or you want to enroll for Ethereum certification, connect with Blockchain Council today.
submitted by Blockchain_org to BlockchainStartups [link] [comments]

Some sites to make extra money

Hello Fellow Redditors,
I am going to list some of my income sources. I will try to give as much information as I can.
Some details about me:I am u/abhiearns, I am currently studying. I want to create some sort of extra income sources. I have been trying to use beermoney as well as other passive income communities like passive_income, passiveincome to find some sites and sources that can work for me.
Enough with the details, Let start by listing some of my extra income sources.
Active Earning: So, I will start with sites on which you have to work actively and devote some serious hours to earn some extra income. These are some beermoney sites (include survey sites, and other such sites):


Passive Earning (No Initial Investments): These will list some of my passive earning sources, I am not listing my investments here because I think they deserve a separate section.Disclaimer: I have 2 laptops and an extra phone so I use all of them for earning, the payments may vary depending on the number and power of various computers.




Passive Earning (Investments Required): These are the sources which require some sort of initial investment. These sources can be risky and there are chances to lose money.



\** I am still trying other sites and apps. I will keep updating this post.*
These are some of the sources I use to earn, I highly recommend these. I won't say you will become a millionaire using these but still its little more than you had yesterday.
submitted by abhiearns to thesidehustle [link] [comments]

Some extra income sources for you

Hello Fellow Redditors,
I am going to list some of my income sources. I will try to give as much information as I can.
Some details about me:I am u/abhiearns, I am currently studying. I want to create some sort of extra income sources. I have been trying to use beermoney as well as other passive income communities like passive_income, passiveincome to find some sites and sources that can work for me.
Enough with the details, Let start by listing some of my extra income sources.
Active Earning: So, I will start with sites on which you have to work actively and devote some serious hours to earn some extra income. These are some beermoney sites (include survey sites, and other such sites):
Passive Earning (No Initial Investments): These will list some of my passive earning sources, I am not listing my investments here because I think they deserve a separate section.Disclaimer: I have 2 laptops and an extra phone so I use all of them for earning, the payments may vary depending on the number and power of various computers.
Passive Earning (Investments Required): These are the sources which require some sort of initial investment. These sources can be risky and there are chances to lose money.
\** I am still trying other sites and apps. I will keep updating this post.*
These are some of the sources I use to earn, I highly recommend these. I won't say you will become a millionaire using these but still its little more than you had yesterday.
submitted by abhiearns to clicksforbeermoney [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]

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]

Some Earning Experiments

Hello Fellow Redditors,
I am going to list some of my income sources. I will try to give as much information as I can.
Some details about me:I am u/abhiearns, I am currently studying. I want to create some sort of extra income sources. I have been trying to use beermoney as well as other passive income communities like passive_income, passiveincome to find some sites and sources that can work for me.
Enough with the details, Let start by listing some of my extra income sources.
Active Earning: So, I will start with sites on which you have to work actively and devote some serious hours to earn some extra income. These are some beermoney sites (include survey sites, and other such sites):
Passive Earning (No Initial Investments): These will list some of my passive earning sources, I am not listing my investments here because I think they deserve a separate section.Disclaimer: I have 2 laptops and an extra phone so I use all of them for earning, the payments may vary depending on the number and power of various computers.
Passive Earning (Investments Required): These are the sources which require some sort of initial investment. These sources can be risky and there are chances to lose money.

\** I am still trying other sites and apps. I will keep updating this post.*
These are some of the sources I use to earn, I highly recommend these. I won't say you will become a millionaire using these but still its little more than you had yesterday.
submitted by abhiearns to AbhiEarns [link] [comments]

Mining with old phone and tablet

Anyone know of a way I can use my old phone (S7) and tablet (Nvida Shield) to mine. It wouldn't have to be anything big like Bitcoin. I guess google banned all apps in the app store from being used to mine but everything online keep referring me to things like MinerGate (the app cannot be used to mine anymore). Anyone have any ideas?
submitted by Xannon99182 to CryptoCurrency [link] [comments]

/r/Monero - Newcomers Please Read. Everything You Need To Know.

What is Monero (XMR)?
Monero is a secure, private, untraceable (crypto-)currency. It is open-source and freely available to all. Don't believe us? Click here.
Monero is a tool that people can actually use. It makes receiving payments hassle-free, since merchants and individuals no longer need to fear the source of funds they are accepting. With transparent systems like Bitcoin, Ethereum, Verge, or Dash, these people need to hope (or spend substantial resources verifying) the sender did not use the funds illicitly. Furthermore, merchants do not want all their vendors known, and individually do not want everyone to know how much they are spending. If I spend more than I should at Newegg (store), that's my own business.
Monero is different because every transaction is always private. There is no way for pools and exchanges to opt out of sending private transactions. Thus, Monero's anonymity set far exceeds any other coin's anonymity set. Over 86,000 transactions in the past month of August, 2017 hid the sender and receiver, and about 99.95% of them also hid the amount (will increase to 100% of all new transactions in September)! There is no suspicion in using a private transaction, since all transactions are private. A single transaction does not stick out.*
This privacy is afforded with the best technology. I implore you to take a few minutes to learn about the four main technologies that Monero uses to provide privacy:
There are several other things that make Monero great! It has a smooth tail emission, dynamic blocks and fees, and an accessible Proof of Work (mining) algorithm.
*You can optionally choose a very large, unusual ringsize to make the transaction stick out. This is not recommended, and normal users who leave the ringsize at the default setting will not experience any issues. Also, it's possible for a user to manually add identifying information to the tx_extra field, which is something that a user must seriously go out of their way to do.
Now you know Monero (XMR) has the best technology. What else makes Monero (XMR) different than other cryptocurrencies?
P.S. Want a quick-start, simple your-grandma-could-do-it guide? Here's a great one!
Am I a bad person to consider using this?
No, Monero is freedom money. You can do whatever you want with it, whenever you want, where ever you want. We make it clear that you should own your wealth 100%. What you do with it, is none of our concern.
Where does the word Monero come from?
The word Monero comes from the language Esperanto. Monero means coin oand currency. The plural way of saying Monero in Esperanto and in our cryptocurrency is Moneroj.
How do I store Monero?
Monero Core
Monero Core GUI (If you don't know how to use it, click here for instructions and tutorial)
Monero Web-Wallet
Offline Wallet Generator
Is there a lightweight wallet for Monero?
Not yet, but you can use the official GUI with a remote node.
Are there any other ways to store Monero (XMR)?
Yes, there are many mobile wallets out there that allow you to store Monero (XMR). We do not recommend them, because they are not official releases of Monero. If you do decide to use other wallets, please make sure to do your research first before storing any Moneroj in the wallet. Anything used for Monero outside of official releases, will be used at your own risk. Some may be used for scamming purposes. If you still decide to take the risk; do not use them for large amounts. Also keep in mind that there is a high chance that Monero support will not be able to help you if you bump into any problems from applications outside of official releases. Why should you not use non-official wallets? Well would you buy a house and give your only key you have to the buildemanagement and wait for him/her to open the door to the house you supposedly own? No. Same goes with cryptocurrencies. You should always have possession of your private keys, and your Moneroj. Most non-official releases own your private keys, therefore you do not own the Moneroj.
How do I buy Monero (XMR) with fiat?
Kraken
Bitfinex
Monero For Cash
Local Monero
Other Options
Which exchanges support Monero (XMR)?
Poloniex
Bithumb
Kraken
Bitfinex
Bittrex
Bitsquare
ShapeShift
Livecoin
BTER
How do I setup a offline cold paper wallet?
Step-by-step guide for cold storage and offline transaction signing with optimal security
Guide For Securely Generating An Offline Cold Paper Wallet
USB Monero Cold Wallet Guide
Is there a Chinese translation so I can understand Monero? 是否有中文翻译,以便我能理解Monero?
Monero (XMR) Chinese Translation
Can I buy Monero (XMR) with CNY? 我可以用人民币买Monero吗?
BTER
*Can I buy Monero (XMR) with KRW?
Bithumb
Where can I find a good mining pool?
Monero Pools
What miner should I use?
CPU:
XMR-Stak (Windows-Linux)
CpuMiner by tpruvot (Windows, Linux)
CpuMiner By Wolf
xmr-stak (MacOS)
cpuminer(MacOS) By correcthorse
GPU:
XMR-stak (AMD)
Ccminer (nVidia) by KlausT, psychocrypt, and fireice-uk
Claymore's CryptoNote GPU Miner (AMD)
If you are a Windows user, click here.
Can I use a proxy for mining?
You can use XMR Proxy. If you want to monitor your rigs you can use Monero Mining Monitor.
How can I setup a local wallet while running node with little bandwidth?
You can use GUI, as a remote node as it uses very little bandwidth. Go to settings tab and change: "localhost:18089" to "node.moneroworld.com:18089". If you are still having problems, then just use our Monero Web-Wallet.
Can I run Monero through Tor or I2P?
Guide to use Monero with Tor correctly
Monero Safety Through Tor
Monero I2P
My vendor only accepts bitcoin but I only have Monero, and I know bitcoin is not private/anonymous. What should I do?
Use XMR.TO, but you should also educate them about bitcoins lack of privacy. Tell them to visit this post.
How long does it take to sync to the blockchain?
It can take from a few hours (using SSD drive) or even 24 hours, depending on hard drive and connection speed.
How do I generate a QR-code for a Monero address?
How to generate a QR code for a Monero address
Moneroqrcode.com for a personalized code
Guide to check balance
List of scams: (Always do a background check / research for anything outside of official releases.)
Did you know over 50 high profile artists accept Monero on their online stores? Check out Project Coral Reef
Are there any other sub-reddits that specialize in certain parts of Monero or just related to Monero?
Yes, there are a few. However, please keep in mind that this sub-reddit (/Monero) is the official Monero sub-reddit.
/xmrtrader - Trading, and investing related discussions & inquires.
/MoneroMining - Mining related discussions & inquires.
/MoneroCommunity for those who want to help grow the community.
/moonero for shitposts and memes.
/MoneroMarket for buying and selling wares for Monero.
/MoneroSupport for, you guessed it, Monero support.
Want to get involved? Click here for a list of sources.
How can I participate in the Monero community?
We welcome everyone to join us and help out. Check the "Community Info" section on our subreddit for our website, forum, stack exchange, github, twitter, and facebook. Anyway, we hope you stick around beyond the hype. Monero has a lot going for it, and we hope you agree! We really need your help, since this project is entirely driven by the community!
Nun vi spertis liberecon.
submitted by cryptonaire- to Monero [link] [comments]

Beginner's Guide to Exchanges - Part 2

Beginner’s Guide to Exchanges – Part 2

A little late, but as promised here is Part 2 of the Beginner’s Guide to Exchanges. I would like to sincerely thank everyone for their support and feedback in making these.
Link to Part 1
This time I also made a Google Docs survey in the hopes of sharing the results with the community. I thought we could share what we use as a whole and why redditors choose the exchanges they do. For skeptics (as you all should be), I assure you that I am not collecting personal information. This is for recreation and if you are still wary, then by all means abstain!
Link to Survey
In Part 3 I will be wrapping up this series by covering decentralized, semi-decentralized, and derivative exchanges. Here it goes!

00 – Concepts and Definitions (Continued)

04 – Fiat Exchanges – Canada

QuadrigaCX

Country Linked Bank Transfer Wire Transfer Paypal Credit/Debit Crypto Transfer
CAD Deposit 1%/ Withdraw Free Free Free (Withdraw Only) 1% (Withdraw Only) Free
USD - Free Free (Withdraw Only) - Free
Exchange Type Maker Taker
Fiat .5% .5%
BTC/ETH .2% .2%
Feature Details
2FA Google Authenticator or Email 2FA Available
Wallet Security Undisclosed amount of funds in cold storage
Web Security 3rd Party Security provided by CloudFlare
Bug Bounty Expired $50 bounties
Tier Level Name Email DOB Phone Address Official ID Bank Info Credit Score Limits
Basic Account X X Digital only, Limits Vary
Verified Account X X X X X X Limits Vary

05 – Fiat Exchanges – Europe

CEX.IO

Country Credit/Debit Bank Transfer Crypto Transfer
Europe 3.5%+ €0.24 Deposit €0 / Withdraw €25 (SEPA €10) Free
Russia 5% + ₽ 15.57 - -
UK 3.5%+ £0.20 Deposit £0 / Withdraw £20 (SEPA Free
US 3.5%+ $0.25 Deposit $0 / Withdraw $50 Deposit $0 / Withdraw 1%
Exchange Type Maker Taker
All Currencies 0% .20%
Feature Details
2FA Google Authenticator Available
Wallet Security Undisclosed amount of funds in cold storage
Credit Card Data Overseen by 3rd Party Kyte Consultants
Web Security SSL Certificates and Encrypted Personal Data
Tier Level Name Email DOB Phone Address ID + Photo Bank Info KYC Limits
Basic Account X X X Digital only
Verified Account X X X X X X $10,000 Daily/$100,000 Monthly

BTC-E / XBTC-E

Country Credit/Debit Bank Transfer Paypal
Europe - SEPA - Deposit .5% / Withdraw 1% (€100 min) -
Russia 6% 6% -
US 7% Deposit .5% ($20 min) / Withdraw 1% ($100 min) 7%
Exchange Type Maker Taker
All Currencies .20% .20%
Feature Details
2FA Google Authenticator Available
Password Expiration Must be changed every 6 months
DDoS Protection 3rd Party Security Services provided by CloudFlare
Bug Bounty Yes at xBTCe
Tier Level Name Email DOB Phone Address Official ID Bank Info KYC Limits
Verified User X X X X X No Stated Limits

Liqui.io

Exchange Type Maker Taker
All Digital Currencies 0.1% .25%
Feature Details
2FA Google Authenticator Available
Bug Bounty Reported bounty posted on HackerOne (unconfirmed)

06 – Fiat Exchanges – South Korea

안녕하세요 여러분! 혹시 우리 한국인 친구 이 보고서를 한국어로 읽고 싶어한다면 알려주세요. 관심이 많이 있다면 간단한 한국어 보고서도 만들 수 있습니다. This year, ETH has taken off like a rocket in the Land of the Morning Calm. With a population of just 50 million, South Koreans account for almost 30% of daily ETH trade volume. Even more surprising is that currently the daily volume of ETH is about 5 times higher than that of Bitcoin on Korean exchanges. Since demand is high, ETH is trading at a premium on Korean exchanges. Some users have been talking about capitalizing off this imbalance by trading on arbitrage between exchanges. For those who have no connection to Korea and hope to do so, I have bad news – all Korean exchanges require a National ID number and access to a Korean bank account. This makes Korean exchanges virtually closed to Korean nationals and those with long-term visas. Sorry everyone.

Bithumb

Coinone

Korbit

07 – Fiat Exchanges – China

With a great deal of anticipation, major Chinese exchanges started trading ETH this summer. Since these exchanges deal huge volumes of Bitcoin already, naturally it was expected that they invest heavily into ETH as well. So far this hasn’t quite lived up to the hype with many exchanges still favoring Bitcoin, Litecoin, Altcoins, and even Ethereum Classic (Gulp). Three of these exchanges underwent inspections by the Peoples Bank of China earlier this year and will be working closely with the government to ease fears of money laundering and market manipulation. There are a lot of Chinese sites, and since my Chinese is non-existent this list is basically just for name recognition. In many ways these sites are very similar in regards to security, verification, and fees compared to their western counterparts; just marketed at a different audience and currency. If users are seriously interested in these exchanges and making reviews, please contribute or ask!

OK Coin

Huobi

CH-BTC

Yunbi

08 – Coinswaps & Cryto-converters

ShapeShift

Changelly

submitted by poop_dragon to ethtrader [link] [comments]

[À Lire] Tout sur Monero, résumé en Français

Qu'est ce que Monero (XMR)?
Monero est une (crypto-)devise sécurisée, personnelle et intraçable. Monero est Open-source et librement accessible à tous.
Monero est une vraie monnaie que tout le monde peut réellement utiliser dans la vraie vie. Il permet simplement de recevoir des paiements sans de soucier de la provenance des fonds. Avec les systèmes dit 'transparents' comme Bitcoin, Ethereum, Verge ou Dash (par exemple), les personnes ne peuvent qu'espérer (ou bien passer pas mal de temps à vérifier) que le payeur n'a pas utilisé ses fonds de manière frauduleuse. De plus, les vendeurs ne souhaitent pas que les acheteurs soit tracés et connus de tout, tout comme chacun d'entre nous ne veut pas que tout le monde sache combien nous dépensions. Si je dépense plus que je ne devrais sur Amazon, c'est mon problème.
Monero est différent car chacune des transactions est toujours privée. Il n'y a aucun moyen pour une mine ou une plateforme d’échange de devise de désactiver ces transactions privées. Par conséquent, l’anonymat offert par Monero dépasse largement celui des autres cryptomonnaies. À ce jour (depuis le fork de septembre), 100% des transactions cachent l'émetteur, le receveur et le montant. Il n'y a également aucune raison d'avoir peur d'effectuer une transaction privée, puisque toutes les transactions Monero le sont. En aucun cas une transaction peut "briller" plus que les autres.
Cette "privacy" (ce qui relève du privé, au sens personnel) est apportée par ces 4 principales technos :
Il y a bien d'autres choses qui font que Monero est un bon projet :
Maintenant que vous être familier avec Monero, et êtes convaincu qu'il utilise ce qui se fait de mieux en cryptographie, qu'apporte-t-il de plus par rapport aux autres crypto-monnaies ?
Suis-je un forcément un délinquant si j'utilise Monero ?
Non, bien sûr que non. Monero se considère comme la monnaie de la liberté. Il est possible d'en faire ce que l'on veut, où on veut, quand on le veux. Cependant, il n'est évidement pas conseillé de mettre tout ses revenus dedans, bien que nous croyons fortement dans son utilité dans la vie réelle, il y a toujours un risque non négligeable lié aux marchés boursiers. Après, ce que vous en faites ne nous regarde pas ! (et il nous serait impossible de le savoir ! ;) )
D'où vient le mot "Monero" ?
Monero vient de l’Espéranto. Il signifie "pièce de monnaie", "monnaie" ou "devise". Le pluriel de Monero est "Moneroj"
OK. Comment débuter ? Comment stocker mes Moneroj ?
Nous recommandons UNIQUEMENT l'usage des logiciels officiels:
Guide d'installation pour grand-maman !
Y a-t-il un portefeuille léger pour Monero ?
Pas pour le moment, mais il est possible d'utiliser l'interface officielle en la connectant à un nœud existant. C'est vrai que le client officiel est relativement lourd, mais les équipes de devs travaillent durement à son allègement.
Y a-t-il d'autre moyen de stocker des Moneroj ?
Oui, il existe plusieurs portefeuille pour mobile, mais nous ne les recommandons absolument pas car ils ne sont pas issus de développements officiels. Certains ont fait état de perte de Moneroj, de vol ou autre. Si vous voulez tout de même utilisez un portefeuille tiers, faites le en tout état de cause et de connaissance, et pour de petites sommes. La plupart de ces portefeuilles tiers possèdent vos clés privées (ce qui sert à générer votre adresse, et ne doit absolument pas être connue de quiconque (sauf peut-être un avocat, pour vos enfants au cas où )) et donc les moneroj présents ne vous appartiennent pas.
Comment acheter des moneroj ?
Il existe plusieurs plateformes d’échange de cryptomonnaies contre des devises.
Pour changer des crypto-monnaies entre elles:
En France, il existe La Maison du Bitcoin, qui permet d'acheter des bitcoin par virement ou carte bleue. Il suffit ensuite de changer les bitcoins pour des Moneroj (XMR) via Shapeshift ou une des plateformes d’échange listées ci-dessus.
MINING:
Où trouver une bonne mine (pool) ? Monero Pools
Quel logiciel de minage utiliser ? CPU:
GPU:
J'ai un commerçant qui accepte uniquement les bitcoins, mais bitcoin n'est ni privé ni anonyme. Comment faire ?
Il est possible d'utiliser XMR.TO, mais il serait bien de sensibiliser votre vendeur sur l'absence de privacy et d’anonymat inhérent au Bitcoin. ;)
Liste des ARNAQUES avérées:
SubReddit en relation avec le Monero:
(tous en Anglais)
Note:
Ce post est une tentative hasardeuse de traduction faite par moi même du post original du sub principal. Si vous voyez une erreur, une coquille de trad ou une tournure de phrase ambiguë, dites le moi !
Je tenterais la traduction d'un des guides d'utilisation du GUI...
ttlk.
submitted by ttlk to Monero_Fr [link] [comments]

How to Mine Cryptocurrency and Bitcoin on Mac/Windows, using CPU or GPU with MinerGate and NiceHash Bitcoin Mining (Handy - Android) minergate Mining With the MinerGate App Bitcoin Mining On Android EASIEST FASTEST METHOD! HOW TO HOW TO MINER BITCOIN ON ANDROID [2019]

Monero XMR Grin GRIN Bitcoin BTC Ethereum ETH Litecoin LTC Ethereum Classic ETC Bitcoin Gold BTG Zcash ZEC Block Producer EOS TRON Representative TRX ICON Representative ICX. Services . Blockchain explorers Rechner Pool Status Service monitor Lumi Wallet MinerGate token. Affiliate. Registrieren Anmelden. Fastest miner in the industry: MinerGate xFast. Cryptocurrency mining pool trusted by more ... Download our official wallet app and start using Bitcoin now. Other Versions. Bitcoin Cash Register (BCH) BCH Merchant is a simple Point of Sale app that allows you to accept Bitcoin Cash (BCH) payments at any retail location. Android Github iOS Github. Badger Wallet. Easily pay for things online in the browser or the mobile app. Supports tokens. Add to Chrome. Add to Firefox. Bitcoin.com ... Free app that mines bitcoins. In Seconds. Free desktop software that combines different algorithms for mining crypto-currencies and allowing transactions between them. Fast Bitcoin miner for Gaming PC . With one button your can start mining bitcoins! Easy bitcoin address setup. Every 4-5 days you can withdraw your mined bitcoins. No fees! Get massive hashing power for mining Bitcoin from your ... MinerGate, in turn, shares the rewards based on how much input everyone is committing. This is a way to boost your passive income, by putting your computer to work especially when it’s not in use. Let’s review some of the best alternatives to MinerGate. 14 Best MinerGate Alternatives Cudo Miner Kellitta Mining with MinerGate is ver very easy and profitable mygate. I think MinerGate is one of the best pools out there as of to date I'v lost bitcoin on a few different pool's but haven't ever worried about losing anything on MinerGate's pool Daveeoff. Big Thanks to Sir "CLAUDE" who helped me and solved all my problems valdo123. Make your computer mine for cash. Download Miner & Start ...

[index] [41121] [11703] [34532] [34978] [9139] [18833] [33635] [45832] [42774] [16596]

How to Mine Cryptocurrency and Bitcoin on Mac/Windows, using CPU or GPU with MinerGate and NiceHash

MINERGATE The easiest mining app to use out of the lot was MinerGate, it already has pools you can easily join, lots of different coins you can mine and integrated wallets to collect the coins in ... Bitcoin Mining (Handy - Android) minergate letzfetz1337. Loading... Unsubscribe from letzfetz1337? ... Mine Bitcoin on your Android Device - Duration: 6:01. Dave Bennett 124,754 views. 6:01 ... Lien : https://minergate-miner.fr.aptoide.com/?store_name=ehz&app_id=31513541 💯INSTANT GAMING💯 Acheter vos jeux beaucoup moins cher https://www.instant-gamin... Phone Farm & Chill: 4 New Apps For Passive Income, Bitcoin Mining & A $100 Paypal Cash Out - Duration: 12:00. Tech Hustler 37,858 views Minergate next steps tutorial - GPU mining, Withdrawing Funds - Duration: 15:43. ... Bitcoin Mining Using Android Phone !! Easiest and Safest Method !! - Duration: 4:34. DroidMonster Inc 463,398 ...

#