GitHub - mempool/mempool: Bitcoin blockchain explorer and

NEM community subreddit

NEM (New Economy Movement) is a dual-layer blockchain with 100% original source code. Launched on March 31, 2015, the NEM mainnet supports multiple ledgers on its cryptocurrency layer, and the NEM Smart Assets layer supports mosaics to represent any asset. NEM’s proprietary coin is XEM, which is harvested (mined) using a Proof-of-Importance (PoI) algorithm. This community is for discussions regarding the blockchain platform.
[link]

Blockchain Explorer API for pubKey in JSON /r/Bitcoin

Blockchain Explorer API for pubKey in JSON /Bitcoin submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

C#, bitcoin blockchain API json and newtonsoft json parser.

For the life of me I cannot get json.net to deserialize json from the blockchain API. Has anybody been able to do this?
submitted by ths1977 to csharp [link] [comments]

GetBlock.io is Going Live! Fee-free Access to Full Blockchain Nodes

Hello!
At GetBlock we provide connection for the most popular cryptocurrencies nodes via an open API (JSON-RPC). There is no need to deploy a node yourself, our service allows you to connect to the blockchain via a full node without having to pay a fee.
We are constantly developing and adding new nodes, on the contrary, the connection always stays put — fast and secure 24/7. At the moment, GetBlock offers nodes of more than 20 cryptos, including Bitcoin (BTC), Ethereum (ETH), Monero (XMR), and Litecoin (LTC).
The platform is quite suitable for young entrepreneurs and beginners, as well as for crypto developers and blockchain users, for all those who have neither time nor resources to run their own full node.
To start using the node, please get your personal and free API key. Tell us about your project or why you need access to blockchain data, and we will grant you a free API key.
If you do have any further questions or partnership offers, feel free to contact us via email: [[email protected]](mailto:[email protected])
submitted by getblockio to u/getblockio [link] [comments]

Alternatives to rest.bitcoin.com?

TL;DR: What are some serious alternatives to rest.bitcoin.com (free or paid) offering JSON REST API?

Having no time and resources to maintain my own full node/indexer servers, I have used multiple remote APIs to interact with the BCH blockchain. Sadly, most of them are unstable and tend to quickly die.
I have used Bitprim.org, which went out of business during last year's hard fork upgrade without prior warning and returning incorrect data to its clients. I have used bitcore.io from BitPay, which returns incorrect data for unconfirmed transactions and also has very little documentation - most of the endpoints are not documented. I have used Blockchain.com in the past but they do not support BCH. I tried using BTC.com but they do not support the CashAddress format (so I assumed it is not maintained).
Finally, the best service I used so far is rest.bitcoin.com, it has little downtime and is very well documented. The only issue I faced when I started using it is that it does not serve requests over TOR, which is not a big deal.
The problem is that its quality is decreasing over time. There is more and more downtime, they recently dropped support for testnet (trest.bitcoin.com) WITHOUT WARNING and nothing is said about this in the documentation, the site still says it is fully operational and the error message returned says nothing about the endpoint being obsolete/deprecated. Moreover, they do not seem to maintain their repo, tons of issues are open without answer, I submitted a pull request to it and have received no answecomment so far.
I am now looking for serious (reliable, documented...) alternatives. I am willing to pay for an API key. Thank you!
submitted by merc1er to btc [link] [comments]

New Ethereum Developer Course

Hey All! We've been working heads down on a new developer curriculum for the last year. We're excited to announce it's finally here.
This curriculum is composed primarily of in-browser coding tutorials and challenges (no need to install any dependencies!). It also includes videos and guides which will help you apply what you learned in your local development environment when you're done with the course.
The full course includes:
Learning JavaScript: A collection of JavaScript coding tutorials and challenges which thoroughly teach JS from scratch with the latest ECMAScript features. Networking: Writing Asynchronous Code and communicating with servers through APIs Data Structures: Building and understanding data structures that are important to blockchain programming (especially trees and linked lists) Blockchain: Understanding Bitcoin, Proof-Of-Work, Digital Signatures and building core blockchain data structures. As well as learning about Ethereum, the EVM, ethers.js, and the Ethereum Node JSON-RPC API. Smart Contracts: Our largest section! This includes 21 coding tutorials and challenges thoroughly teaching the latest Solidity version 0.6.x from the very basics. Decentralized Applications: Deploy Smart Contracts and interact with them through ethers.js. You'll have three new working decentralized applications at the end of this section which you'll be able to extend upon to build bigger projects!
You can find the full listing here: https://www.chainshot.com/curriculum
The course is available through a monthly subscription. We'll also be starting live coding classes next month for all subscribers!
We hope you'll choose to learn with us. Let us know if you have any questions/concerns. All feedback is welcome. :)
submitted by dan-nolan to ethdev [link] [comments]

ETHEREUM FRONTEND JAVASCRIPT APIS: WHAT YOU NEED TO KNOW

ETHEREUM FRONTEND JAVASCRIPT APIS: WHAT YOU NEED TO KNOW

https://preview.redd.it/9djdo90nx9051.jpg?width=2400&format=pjpg&auto=webp&s=54ca700da20bac0692ed294a31e75cfefb96f671
Blockchain has emerged as a popular technology, and if you are planning to make a career in this field, then there are various certification programs. When we talk about Blockchain, then it becomes important to mention about Ethereum. It is a cryptocurrency and an open-source platform as well. There has been some great development in this field, and those who are planning to learn about Ethereum must go for a certified Ethereum course.
Blockchain developers who are developing apps on Ethereum must know about the different frontend javascript which can simplify their task. In this blog, we will be highlight three such popular javascript APIs.
Ethereum Overview:
Ethereum emerged after Bitcoin and has now become a popular Blockchain platform. It is a cryptocurrency as well. It is an open-source software platform. Ethereum offers a flexible platform to the developer so that they can develop decentralized apps with ease.
Although scalability is a bit of an issue with Ethereum, in the current scenario, it is one of the best platforms for decentralized application development.
Looking at the broader spectrum and use of Blockchain, it has become a great career opportunity for many. Hence, option for certified Blockchain Developer is the right way to give your career the right boost.
What is API?
API is a set of the protocol which is used of building and integrating the applications across different platforms. APIs eventually simplifies app development and enables seamless interaction of your products and services with the user.
Popular frontend Javascript APIs:
Web3.js- This is a collection of libraries which empowers you to connect with remote Ethereum node. It is achieved by using HTTP or IPC connection. This is used for the following :

  1. Send ether from one account to another
  2. Interact with smart contracts
  3. Retrieve user account
It interacts with Ethereum Blockchain with JSON RPC protocol. A copy of all the data and code is present on the Blockchain. The API requests an individual Ethereum node with JSON RPC to read and write data to the network.
Ethers.js
Another frontend javascript is Ethere.js, which is used by most of the decentralized application developers owing to its features and functionalities. It has the following main features:

  1. It is open source
  2. It is completely safe as it keeps private keys restricted to the clients
  3. You can import and export using JSON wallets which again adds to the security feature
  4. Import and export BIP 39 mnemonic phrases
  5. You can connect to Ethereum nodes via JSON-RPC, MetaMask, INFURA, or Etherscan.
  6. It is completely TypeScript ready
  7. It offers complete functionality for all Ethereym needs
  8. Extensive documentation
  9. It has a huge collection of test cases
  10. It has an MIT Licence.
If you are looking for another API to develop javascript with Ethereum, then you must consider Ether.js. It is loaded with features that any Blockchain developer would require. The library is designed in such a way that it matches the need of the client. With the use of ether.js, it becomes easier to write javascript-based wallets.
Light.js
The third entrant in our list is light.js. It provides high-level tools which are used for developing efficient Dapps on the light client. This is also a great alternative to web3.js. It works with remote nodes and makes it easy for a developer to build decentralized applications with ease.
Here it becomes important to mention that light.js chooses the best pattern which works with light clients, it listens to headers and makes API calls on a new header an ensures that network calls are not extreme.
The end objective is to put up a high-level library such that the decentralized app developers can make use of this and create apps.
Besides, these there are other APIs like Web3-wrapper can also be used by blockchain developer. These APIs aim to simplify the task of the developer so that they can create apps which work seamlessly.
Final Thoughts
If you are working on a decentralized application developed, then you would come across either of these apps or will be using one of them. In case you are new to this field and are looking for gaining comprehensive knowledge in this field, then you must go for a Certified Ethereum Expert online training program by Blockchain Council. This exhaustive program will help you learn about Ethereum, APIs and allied concepts and at the same time, learn how to use them. In case you want to learn how to use smart contracts on Ethereum based applications, then you must opt for Certified Solidity Developer coursesby Blockchain Council. Connect with us today to explore more about Ethereum.
submitted by Blockchain_org to BlockchainStartups [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]

Groestlcoin 6th Anniversary Release

Introduction

Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

Windows
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
OSX
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).

Features

Download

Source

Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.

Features

Download

Windows
Linux :
 pip3 install -r requirements.txt python3 bip39\_gui.py 

Source

ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Factom Protocol Information

The Factom protocol is a data-centric platform for Proof of Existence (PoE) and decentralized applications. Just as TCP / IP enables the WWW, the Factom Protocol enables countless applications to be built on top of it.
Layer 2 Applications
Token and Tokenomics
Factom is a two token system. Only the Factoid (FCT) is transferable and able to be traded on exchanges. Entry Credits (EC) are obtained by burning FCT and are used to enter data into the Factom Protocol. Entry Credits are $.001 each and that price is fixed. Therefore, if FCT is worth $1.00 and you burn it, you receive 1,000 EC. If FCT is worth $10.00 each and you burn one, you receive 10,000 EC. The two token system allows for:
Community Discussion
Development
Tools
Testnet Resources
Top Exchanges (by volume)
Education
Wallets
Block Explorers
Authority Node Operators
Authority Node Operators are the coalition of companies that decentralize the Factom Protocol.
Recent Newsletters
submitted by Factomize to factom [link] [comments]

Getblock Nodes. Free access to blockchain nodes

Hello!
We are a multi-block explorer, and we have several blockchain nodes:
In the near future we are expecting the addition :)
If you are interested in getting a free access to blockchains API (JSON-RPC), simply follow the link (Feedback form at the bottom of the page).
Tell us about your project or why you need access to blockchain data, and we will grant you a free API key.
Since as a result we become partners, and all serious partnerships are public, we will have to exchange active links in the «Partners» section on our websites.
submitted by getblockio to u/getblockio [link] [comments]

Darwinia development team Itering wins funding from Web3 Foundation

Darwinia development team Itering wins funding from Web3 Foundation

https://preview.redd.it/9wjacfdet2g41.jpg?width=750&format=pjpg&auto=webp&s=f2344aa2383ac3d6f5fe54c21cbdd921964e5040
Web3 Foundation announced a new list of W3F Grants for its funding plan. The project Scale submitted by the Darwinia development team Itering(www.itering.io), who has received the investment support of Web3 Foundation and has become the officially recognized project of the Web3 ecosystem and Polkadot.

What is Scale

Scale is a substrate JSON-RPC API client and libraries implemented in ruby language for general use. It contains the implementation of low-level data formats, various substrate types and also supports metadata. This work is the prerequisite of our subsequent series of projects. We hope to easily access Polkadot and Substrate through our familiar language ruby, such that the applications based on Polkadot / Substrate can be developed at a fast pace. We plan to develop some substrate-based web games. The back end of these applications is prepared to be developed in ruby language, and then interact with nodes or synchronize data through RPC.

About Itering

Itering (www.itering.io) is a blockchain technology company founded in Singapore in 2018. Most of people in this company are senior blockchain developers and experts in the blockchain core technology and participate in the development the open source projects of Bitcoin, Ethereum, NEO, etc. The blockchain core development is the most important part of current development, especially the cross chain technology.
The Darwinia Network is also developed by Itering and focus on the assets exchange and help blockchain applications cross-chain. The first integration part of Darwinia Network facing on gaming is Evolution Land, which is also developed by Itering in 2018 to 2019, and have Ethereum Land and Tron Land. The goal of Itering is to promote the massive adoption of blockchain and iterate to a trust-free future. The Scale is the first big step in blockchain games and Evolution Land, and also let the Darwinia Network move much forwards to the goal.

Following Us

ITERING: https://www.itering.io/ DARWINIA: https://darwinia.network/ Twitter: https://twitter.com/DarwiniaNetwork Telegram: https://t.me/DarwiniaNetwork
submitted by sixige to dot [link] [comments]

Is there a way of downloading the current state of the mempool or an example of it?

Hi everyone,
I would like to test some algorithms to assemble a candidate block and also do some statistical analysis. In order to do this, I need an example of the mempool transactions. However, I wasn't able to find any simple way of downloading it. My best attempt so far was to download the data from the blockchain.info API accessing this link: https://blockchain.info/unconfirmed-transactions?format=json. However, I think the number of transactions is limited by 10 and usually the mempool has more than 10 thousand transactions. I also tried https://www.smartbit.com.au/txs/unconfirmed and https://blockchair.com/bitcoin/mempool/transactions, but they also limit the number of transactions and the access to the some important data, such as ancestor, is not so direct. The only solution I found so far was to install bitcoin core, download the entire chain (which I want to avoid) and only then be able to get the mempool transaction data. Anyway, I don't need to right now to get access to the mempool. I only need an example of a snapshot of it. Could anyone help me on this task?
Thanks in advance
submitted by bpmsilva to Bitcoin [link] [comments]

[FOR HIRE] Python Software Engineer — 12 years of experience

Looking for a job: CTO, Team Lead, Developer. 12 years of professional experience in software development. Python, JavaScript. Available for remote work and relocation.
Experienced in planning the development of new projects, working on the architecture, preparing the requirements, writing specifications, and leading teams. I enjoy teaching people to code and doing code review. I ask other developers to write code of high quality and refactor it so the code is simple and readable.
Worked on 20 complex projects for companies from 5 countries, including an adaptive online learning platform for Bloomberg and The Economist used by students around the world for exam preparation.
I have experience with caching, task queues, unit tests, image processing, encoding, API, parsing, multithreaded and asynchronous applications.
When working on a project, I write detailed documentation that helps any new developers to quickly join the project.
[email protected]
submitted by aruseni to RemoteJobs [link] [comments]

[FOR HIRE] Python Software Engineer — 12 years of experience

Looking for a job: CTO, Team Lead, Developer. 12 years of professional experience in software development. Python, JavaScript. Available for remote work and relocation.
Experienced in planning the development of new projects, working on the architecture, preparing the requirements, writing specifications, and leading teams. I enjoy teaching people to code and doing code review. I ask other developers to write code of high quality and refactor it so the code is simple and readable.
Worked on 20 complex projects for companies from 5 countries, including an adaptive online learning platform for Bloomberg and The Economist used by students around the world for exam preparation.
I have experience with caching, task queues, unit tests, image processing, encoding, API, parsing, multithreaded and asynchronous applications.
When working on a project, I write detailed documentation that helps any new developers to quickly join the project.
[email protected]
submitted by aruseni to Jobs4Bitcoins [link] [comments]

Tamamı TÜRKÇE 129 Udemy Kursu (Programlama|Web Tasarım|Excel|Linux|MATLAB|Dreamweaver|Photoshop)

Sıfırdan Türkçe İos Programlama Öğrenin https://www.udemy.com/sifirdan-ios-programlama-ogrenin/ Sanal Havacılığa Giriş https://www.udemy.com/sanal-hav-giris/ Blok Tabanlı Robot Programlamaya Giriş https://www.udemy.com/blok-tabanli-robot-programlamaya-giris-makeblock/ VirtualBox ile Sanal Makine Oluşturmak ve Yapılandırmak https://www.udemy.com/virtualbox-ile-sanal-makine-olusturmak-ve-yaplandrmak/ Yeni Başlayanlar İçin Adobe Photoshop Temel Tasarım Eğitimi https://www.udemy.com/course/yeni-baslayanlar-icin-web-tasarim-egitimi-adobe-photoshop/ Bilgisayar Sektörü ve İş Dünyası - 1 https://www.udemy.com/course/bilgisayar-alanlarndan-is-dunyasna-gecis/ Emmet Eklentisi Kurulum ve Kullanımı https://www.udemy.com/course/emmet-eklentisi-kurulum-ve-kullanimi/ PDO ile Youtube Data API Kullanarak Video Scripti Yapmak https://www.udemy.com/course/pdo-ile-youtube-data-api-kullanarak-video-scripti-yapmak/ Angular 4 & Todo Uygulaması https://www.udemy.com/angular-4-todo-uygulamasi/ Uzmanından Ücretsiz Wordpress Eğitimi https://www.udemy.com/uzmanindan-ucretsiz-wordpress-egitim-seti/ İonic 3'ü Gerçek Projeden Öğrenin - Meditasyon Uygulaması https://www.udemy.com/course/ionic3u-gercek-projeden-ogrenin-meditasyon-uygulamasi/ Unit Test Yazma Sanatı https://www.udemy.com/unit-test-yazma-sanati/ Film Yapım ve Yönetmenlik https://www.udemy.com/film-yonetmek/ Yeni Lightroom CC ile Fotoğraf Düzenleme https://www.udemy.com/course/yeni-lightroom-cc-ile-fotograf-duzenleme/ Derinlemesine Excel Vlookup ve Index-Match fonksiyonları https://www.udemy.com/course/derinlemesine-excel-vlookup-ve-index-match-fonksiyonla Psikoloji ve Alt Alanları https://www.udemy.com/psikoloji-ve-alt-alanla Kütüphaneler için Hizmet Ortak Tasarımı: Xlibris Yaklaşımı https://www.udemy.com/course/kutuphaneler-icin-hizmet-ortak-tasarim-xlibris/ Blender Animasyon Temelleri https://www.udemy.com/blender-animasyon-temelleri/ Linux: Herkes İçin Özgür İşletim Sistemi https://www.udemy.com/temel-linux-terminal-komutla VirtualBox ile Sanal Makine Kurulumu https://www.udemy.com/course/virtualbox-ile-sanal-makine-kurulumu/ Tablosuz ( Div ) tasarım site yapımı ve basit veritabanı https://www.udemy.com/tablosuz-div-tasarim-site-yapimi-ve-basit-veritabani-islemleri/ Sıfırdan PowerPoint Derslerini öğrenerek Slayt dersi hazırla https://www.udemy.com/course/powerpoint-derslerini-detayli-ogren MS Excel : İşinizi Kolaylaştıracak Kısayollar ve Öneriler https://www.udemy.com/course/ms-excel-isinizi-kolaylastiracak-kisayollar Arduino Eğitim Kursu https://www.udemy.com/course/sezerduino Ücretsiz Udemy HTML CSS JavaScript kursu https://www.udemy.com/web-yazlma-giris-html-css-javascript-temel-egitim/ Ücretsiz Udemy PHP Eğitim Seti https://www.udemy.com/php-egitim-seti-1-a/ Ücretsiz Udemy Arduino ile Robotik Eğitim https://www.udemy.com/ardunio-ile-robotik-egitimi Ücretsiz Udemy Siber Zorbalık Eğitimi https://www.udemy.com/siber-zorbalik-egitimi Ücretsiz Udemy Excel Kursu https://www.udemy.com/basitten-ileriye-excel-baslangic/ Uzmanından Ücretsiz Udemy WordPress Kursu https://www.udemy.com/uzmanindan-ucretsiz-wordpress-egitim-seti/ Ücretsiz Udemy Mühendisler İçin Matlab https://www.udemy.com/matlabbe Udemy Ücretsiz İngilizce Kursu https://www.udemy.com/ozerkirazingilizce/ Yeni Başlayanlar İçin Adobe Photoshop Tasarım Eğitimi https://www.udemy.com/yeni-baslayanlar-icin-web-tasarim-egitimi-adobe-photoshop/ Udemy Ücretsiz Linux Dersleri https://www.udemy.com/linux-ogreniyorum Sıfırdan Türkçe İos Programlama Öğrenin https://www.udemy.com/course/sifirdan-ios-programlama-ogrenin/ Yeni Başlayanlar İçin Adobe Photoshop Temel Tasarım Eğitimi https://www.udemy.com/course/yeni-baslayanlar-icin-web-tasarim-egitimi-adobe-photoshop/ Yeni Başlayanlar İçin Adobe Dreamweaver Temel Kod Eğitimi https://www.udemy.com/course/videobilgi-yeni-baslayanlar-icin-web-tasarm-egitimi/ PHP Eğitim Seti 1 https://www.udemy.com/course/php-egitim-seti-1-a/ Yeni Başlayanlar İçin Adobe Flash Temel Animasyon Eğitimi https://www.udemy.com/course/yeni-baslayanlar-icin-adobe-flash-temel-animasyon-egitimi/ Forecasting in Time Series(Zaman Serilerinde Öngörü/Tahmin) https://www.udemy.com/course/forecasting-in-time-serieszaman-serilerinde-ongorutahmin İSG Sınavı Pratik Çalışma Soruları (Aralık 2019) https://www.udemy.com/course/isg-sinavi-pratik-calsma-sorulari/?couponCode=DISCUDEMY.COM TMGD Pratik Deneme SINAVI https://www.udemy.com/course/tmgd-deneme-sinavi/?couponCode=DISCUDEMY.COM MBLOCK İLE BLOK TABANLI KODLAMA ÖĞRENİYORUM https://www.udemy.com/course/mblockilebloktabanlikodlamaogreniyorum/ Bitcoin veya kripto paralar ile al-sat yaparak kazanın 2019 https://www.udemy.com/course/bitcoin-veya-kripto-paralar-ile-al-sat-yaparak-kazann (HATALI PYTHON!) Sıfırdan ileri seviye Pyhton 3 https://www.udemy.com/course/hatali-python-sfrdan-ileri-seviye-pyhton-3 Adobe Animate CC Dersleri https://www.udemy.com/course/adobe-animate-cc-dersleri Özer Kiraz ile sıfırdan başlayan İngilizce kursuna katılın! https://www.udemy.com/course/ozerkirazingilizce Unity C# | Oyun Geliştiricisi Olma Eğitimi https://www.udemy.com/course/unity-oyun-gelistirme-egitimi/ C# Dersleri : Adım Adım Sıfırdan - İleriye https://www.udemy.com/course/csharpders/ Kolay ve Hızlı Illustrator CC Öğrenin https://www.udemy.com/course/illustrator_ogren/ Sıfırdan İleri Seviyeye Komple Uygulamalı Wordpress Eğitimi https://www.udemy.com/course/sfrdan-ileri-seviyeye-komple-uygulamal-wordpress-egitimi/ Temel ve İleri Excel: 2 Eğitim 1 Arada! https://www.udemy.com/course/2-egitim-1-arada-temel-excel-ve-ileri-excel/ PLAXIS İLE GEOTEKNİK TASARIM https://www.udemy.com/course/plaxis-ile-geoteknik-tasarim/ Öğrenci Kariyeri 101: Erasmus,W&T,AIESEC,Not Ortalaması,Staj https://www.udemy.com/course/ogrenci-kariyeri-101-erasmuswtaiesecnot-ortalamasstaj/ En iyi [ÜCRETSİZ] Video Edit Programı https://www.udemy.com/course/en-iyi-ucretsiz-video-edit-program/ Sketch ile Arayüz Tasarımı (UI Design) https://www.udemy.com/course/ui-tasarimlar-yapmayi-ogrenin/ Java ile Programlama https://www.udemy.com/course/java-ile-programlama/ Online İş Modelleri Ücretsiz Eğitim https://www.udemy.com/course/online-is-modelleri-ucretsiz-egitim/ Youtube Youtuber İle Öğrenilir https://www.udemy.com/course/youtube-youtuber-ile-ogrenili 90 Dakikada Wordpress Eğitimi https://www.udemy.com/course/90dkwordpressegitimi/ SolidWorks Tasarım Tablosu (Design Table) https://www.udemy.com/course/solidworks-y/ PHP Symfony FW ile Sıfırdan Gelişmiş Uygulama Geliştirme https://www.udemy.com/course/php-symfony-framework-ile-sifirdan-gelismis-uygulama-gelistirme/ Unity 2019 Multiplayer Oyun Tasarlama https://www.udemy.com/course/photonnetwork-ile-unity-de-multiplayer-oyun-tasarlama/ Tinkercad İle Elektronik Devre Simülasyonu https://www.udemy.com/course/tinkercad-ile-elektronik-devre-simulasyonu/ Ansys Rigid Dynamic Tanıtım Kursu https://www.udemy.com/course/ansys-rigid-dynamic-tantm-kursu/ Dropshipping Kursu https://www.udemy.com/course/dropshipping-kursu/ Unity - Kendi Serverini Yazarak Online Oyununu Yapmak https://www.udemy.com/course/unity-kendi-serverini-yazarak-online-oyununu-yap/ JAVA FULL STACK DEVELOPER -1 (Komple Web sıfır-Orta Seviye) https://www.udemy.com/course/hamitmizrak_javafullstackdevelope Baştan Sona İDECAD STATİK v10 KURSU https://www.udemy.com/course/bastan-sona-idecad-statik-v10-kursu/ HTML5 ve CSS3 https://www.udemy.com/course/html5-css3-html5-css3-html5-css3-html5-css3-html5-css3-html5-css3-html/ Python ile Yazıdan Sese https://www.udemy.com/course/python-ile-yazidan-sese/ Temel NodeJS Eğitimi https://www.udemy.com/course/temel-nodejs-egitimi/ Tamamı ile Web Tasarım - Trunçgil Akademi https://www.udemy.com/course/web-tasarim/ Linux: Herkes İçin Özgür İşletim Sistemi https://www.udemy.com/course/temel-linux-terminal-komutla Oyun Modeli Tasarlama https://www.udemy.com/course/oyun-modeli-tasarlama/ ÜCRETSİZ ! 3D Sıfırdan Catia Eğitimi (3D Örnek Çizimlerle) https://www.udemy.com/course/sfrdan-catia-egitimi-3d-ornek-cizimlerle/ YDS YÖKDİL ve YKS-DİL İNGİLİZCE SINAVLARI HAZIRLIK REHBERİ https://www.udemy.com/course/yds-yokdil-ve-yks-dil-ingilizce-sinavlari-hazirlik-rehberi/ TOEFL Speaking Kursu (Yeni sisteme göre) https://www.udemy.com/course/toefl-speaking-kursu-yeni-sisteme-gore/ Basitten Karmaşığa Adım Adım JQUERY Eğitim Seti https://www.udemy.com/course/basitten-karmasiga-adim-adim-jquery-egitim-seti/ ÜCRETSİZ ! 2D Sıfırdan Catia Eğitimi (2D Örnek Çizimlerle) https://www.udemy.com/course/sfrdan-catia-egitimi-2d-ornek-cizimlerle/ Python Programlamanın Temelleri https://www.udemy.com/course/python-programlamann-temelleri/ Java ile Programlamaya Giriş 1 https://www.udemy.com/course/java-ile-programlamaya-giris-1/ Java ile Programlamaya Giriş 2 https://www.udemy.com/course/java-ile-programlamaya-giris-2/ Solfej Eğitimi - Nota Öğrenim Dersleri https://www.udemy.com/course/solfej-egitimi-nota-ogrenim-dersleri/ Unity 3D ile Sıfırdan Oyun Geliştirmeyi Öğrenin https://www.udemy.com/course/unity-egitim-seti/ C# ile Katmanlı Mimari Öğren : Ado .Net ile WinForm https://www.udemy.com/course/1-saatte-c-sharp-ile-katmanli-mimari-ogren/ Bir Saatte Css Öğren https://www.udemy.com/course/1-saatte-css-ogren/ JSON Eğitimi (Uygulamalı) https://www.udemy.com/course/json-egitimi/ Mastercam ile Uygulamalı Cad Cam https://www.udemy.com/course/mastercam-ile-uygulamal-cad-cam/ (Ücretsiz) Canva Sosyal Medya İçerik Üretimi [30 Dakika] https://www.udemy.com/course/sosyal-medya-icerik-uretimi/ (Ücretsiz) Faceboook Reklamcılığı [30 Dakika] https://www.udemy.com/course/facebook-reklamcilik-egitimi/ Unreal Engine 0 Dan Düzgün Anlatım https://www.udemy.com/course/unreal-engine-0-dan-duzgun-anlatm/ PHP PDO MySql kullanarak admin panelli site yapımı https://www.udemy.com/course/php-pdo-mysql-kullanarak-admin-panelli-site-yapm/ Agile Yazılım Geliştirme, Proje ve İnsan Yönetimi Yaklaşımı https://www.udemy.com/course/agile-yazilim-gelistirme/ Oracle SQL Eğitimi https://www.udemy.com/course/oracle-sql-egitimi/ Temel Dijital Pazarlama Eğitimi / Dijital Medya Kursu https://www.udemy.com/course/temel-dijital-pazarlama-egitimi-dijital-medya-kursu/ (Ücretsiz) Dijital Pazarlama Eğitim Videoları https://www.udemy.com/course/ucretsiz-dijital-pazarlama-egitimi/ (Ücretsiz) Google İşletmem Eğitimi - Google My Business https://www.udemy.com/course/google-isletme-hesabi-ekleme-egitimi/ (Ücretsiz) Kod Yazmadan Kişisel Web Sitesi Oluşturma https://www.udemy.com/course/kod-yazmadan-kisisel-web-sitesi-yapma-egitim-seti/ Sıfırdan Bootstrap 4 Öğrenme https://www.udemy.com/course/sifirdan-bootstrap-4-dersleri-bootstrap-egitimi/ Hiç Bilmeyenler için Python https://www.udemy.com/course/hic-bilmeyenler-icin-python/ Render Hataları Üzerine Kritik https://www.udemy.com/course/render-hatalar-uzerine-kritik/ YAŞAMAK İÇİN YEMEYİ ÖĞRENİN https://www.udemy.com/course/yasamak-icin-yemeyi-ogrenin/ Sanal makineye Sıfırdan Windows 10 kurulumu https://www.udemy.com/course/sanal-makineye-sfrdan-windows-10-kurulumu/ Hızlı HTML5 Programlama https://www.udemy.com/course/hzl-html5-programlama/ 3ds Max İle Villa Modelleme Eğitimi https://www.udemy.com/course/3ds-max-ile-villa-modelleme-egitimi/ KONUŞMA DÜZEYİNDE İNGİLİZCE ÖĞRENİYORUM https://www.udemy.com/course/konusma-duzeyinde-ingilizce-ogreniyorum/ Android Uygulama Geliştirme - Kotlin Eşliğinde https://www.udemy.com/course/android-uygulama-gelistirme-kotlin-esliginde/ Devrim Danyal ile Kısa Kısa Blockchain Bitcoin Kriptopara https://www.udemy.com/course/devrimdanyalilekisakisa/ SQL Server DBA Eğitim Videosu Serisi https://www.udemy.com/course/sql-server-dba/ Electron.js ile Masaüstü Uygulama Yapımına Giriş https://www.udemy.com/course/electronjs-ile-masaustu-uygulama-yapimina-giris/ Expressjs ve Socketio İle Chat Uygulaması Geliştirelim https://www.udemy.com/course/expressjs-ve-socketio-ile-chat-uygulamas-gelistirelim/ Kurumsal Mimariler İçin Sql Server Veri Tabanı Tasarımı https://www.udemy.com/course/veritabani-tasarimi/ Hasan Yüksektepe ile Wordpress Eklentisi Geliştirme https://www.udemy.com/course/hasan-yuksektepe-ile-wordpress-eklentisi-gelistirme/ SİBER ZORBALIK EĞİTİMİ https://www.udemy.com/course/siber-zorbalik-egitimi/ Arduino ile Robotik Eğitimi https://www.udemy.com/course/ardunio-ile-robotik-egitimi/ Veri Bilimine Giriş https://www.udemy.com/course/veri-bilimine-giris/#instructor-1 Real Time Mesajlaşma Uygulaması https://www.udemy.com/course/real-time-mesajlasma-uygulamas/ Windows Server Hakkında Kısa Bilgi https://www.udemy.com/course/windows-server-hakknda-ksa-bilgi/ Sıfırdan Macbook Pages Öğrenin https://www.udemy.com/course/sfrdan-macbook-pages-ogrenin/ Baş Denetçi Nasıl Olunur https://www.udemy.com/course/bas-denetci-nasl-olunu Temel Linux Eğitimi Dokümantasyon Kaynağı https://www.udemy.com/course/linux-dokumantasyonu/ PMBOK V6 İçeriği ile Proje Yönetimi Eğitimi - 0/11 - Giriş https://www.udemy.com/course/pmbok-v6-icerigi-ile-proje-yonetimi-egitimi-011-giris/ Geometri -Örnek Soru Çözümleri-TYT-YKS, https://www.udemy.com/course/geometri-ornek-soru-cozumleri-tyt-yks/ Vray For Sketchup 1.49 https://www.udemy.com/course/vray-for-sketchup-149/ Baştan sona C Programlama eğitimi https://www.udemy.com/course/bastan-sona-c-programlama-egitimi/ Sıfırdan ReactJS ve Context Api https://www.udemy.com/course/sifirdan-reactjs-ve-context-api/ Mühendislik Öğrencileri İçin Matlab https://www.udemy.com/course/matlabbe Kodlama Bilmeden Web Sitesi Yapma | Blogger Dersleri https://www.udemy.com/course/kodlama-bilmeden-web-sitesi-yapma-blogger-dersleri/
submitted by whiteh4cker to Turkey [link] [comments]

Nano timestamps

First off, big thanks to u/Matoking for his nanolib library, and thanks to https://www.alilnano.com/ for the nano to test with
---
TL;DR I made a small API that is able to timestamp strings and json in-real-time using the nano blockchain instead of using the bitcoin blockchain. Check it out here - http://134.209.54.121/ (will be moving it soon). I have a few questions near end of post:

Lately, I've worked on some DNA sequences that I'd like to maintain in the public domain (as a synthetic biologist). In order to do that, I thought it would be nice to timestamp the data I generated on a blockchain (this timestamp does not to be extremely specific, within a few days is fine). At first, I checked out https://opentimestamps.org/ which is a great project. HOWEVER - getting the block takes quite a few hours, which really sucks for integrating it into different applications (https://github.com/opentimestamps/opentimestamps-client/blob/masteREADME.md). I wanted to (nearly) instantly get a hash that can be attributed to a certain piece of data.

Here comes Nano, which is feeless and nearly instant, and so solves my problem. I like hacking little things together, so I made a small Flask app, code here https://github.com/Koeng101/nanotimestamps. You can check out the actual API at http://134.209.54.121/, try it out! (I'm still connected to mynano ninja, so I don't have enough api calls to begin integrating into things)

Questions:
  1. In my understanding, Nano's block lattice basically makes the 'frontier' blocks the only ones that are really saved in a decentralized manner, and previous blocks can be pruned (https://www.reddit.com/nanocurrency/comments/aqq6zm/nano_how_2_blocks_and_lattices/). How about unpocketed transactions? For example (if I remember correctly) xrb_3bejnuc1qx31a37147smsyuu568p7jkuy4yfneoohemqu8psy75g7rys7mck is the hash of 'Hello World', and there are a couple unpocketed transactions floating there, which can never be pocketed unless you can find the private key of that public key. Will those ever be pruned from the ledger?
    1. Is this an ethical project? If those transactions are never removed from the ledger (ie can't be pruned), then that means that every file or json I hash to save will now be bloating the ledger. I'm not too worried about the burn rate, since I only send 1 raw.
    2. How do I set up my node so I can do RPC calls to it? Sorry for being a noob, but I couldn't figure this one out. My node online node is here 134.209.61.219, and I just can't figure out how to remotely connect to it with RPC.
    3. Any other thoughts I should keep in mind?

Next steps:
  1. I bought the domain names nanotimestamps.com and nanotimestamps.org to set up a more official looking website
  2. I plan on adding in file upload to the API
  3. I plan on adding upgrading the CPU so I can solve the PoW quicker (main bottleneck)

Nano rocks! Thanks for being awesome people.
submitted by koeng101 to nanocurrency [link] [comments]

Kin is Open source - MythBusters EP03

Here is how an open source project looks like https://medium.com/0x-trackeannouncing-the-0x-tracker-public-api-152e34fe70d6 Also worth mentioning that they collected 25m instead of 100m plus they didn't already have a big userbase to abuse like Kik but still overdelivered. Kik can't even post a consistent layout of a KRE payment in their Subreddit, to allow users to automated fetch this data with a programming language of their choice without needing to modify their code each week.
A very long time ago i asked the Kik team if they plan to create some tools/apis so other 3rd party entities can get the important data(KRE payouts as JSON for example) fast and easy so they can verify that Kin isn't a scam and by doing so they would also promote their findings and generate new ideas based on those. The community would contribute on those findings as well. By doing so they would increase transparency and that's the last thing they like to do.
Let's break down why Kin isn't open source. We will look only at the changes made by Kik on thr Stellar chain.
First of all where is the code of the KRE? ;) It's neither decentralized (the current direction gives a clear indication that it will never be) nor is it open source. Where is the KRE code guys to say that it's open source? It's surely not open source. Oh and btw, nobody can contribute. Adam tried but Kik employees are assholes, means a contribution is just a waste of time.
How can i contribute to the anti spam? Can someone show me where the totalitarians hide the non totalitarian antispam code? Again.... Not open source / open source compatible.
Kevin switched his tone from "get banned" to "we value your feedback(he is lying)" to give a false sense that your feedback is really being considered. We know that they never did that in the past and now they try psychological tricks to calm the masses. That's another similarity between Kik/Kin and the tricks used by the Nazis.
The second change is the whitelisting. It's by definition extreme centralized which blocks all benefits that "open source" provides.
So my question is, how can someone say that Kin is open source if their only change isn't?
Users like KovaKourva spread this lies, because they think that a picture of the ecosystem with apps beeing connected with each other is sufficient enough to call something open source.
Stellar is open source and they harvest the benefits of it but Kin isn' t. What you would call Kin is a shitclone-shitcoin
Remember Kin isn't Kik (at least in theory because on paper it is) but Ted still manages to run it like his own private company even tho he isn't the CEO after scamming 15k persons. Why does Ted decide what to do if he is just the founder with no obligations?
Why are they allowed to run Kin like a private owned company if their goal is to create a self sustaining ecosystem for other apps? No way this will work and no way that a partner like giphy will join under these Nazi conditions.
Kik is designing Kin in a way where contributions are not possible by default. It was just designed to fulfill the needs of Kik. You don't need to be a magician to guess that they ll abuse app developers in the future.
How can someone modify Kin a bit to his needs without forking it into another blockchain? There are no proposals possible like we see in Eth or BIP in bitcoin. Nobody is going to fork Kin to use this broken garbage modified for their own company under another name so we can say that Kin gets some open source benefits
Also, the idea behind open source software is that users are effectively co-developers, suggesting ways to improve it and helping to hunt out bugs and problems, but Kik makes suggestions on the kre look like a witch hunt.
When a programmer or engineer runs into a problem or an opportunity to improve the Kin code, they generally suggest a change to a Kin maintainer an experienced user who provides feedback and guidance on making the proposed improvement(this doesn't exist on Kin, because they follow the rules of the 3rd totalitarian Reich with Ted Hitlerston as their leader). Through this collaborative process, the less experienced contributor gains a deeper understanding of the system’s structure and functions which means the ecosystem as a whole get's more developers with a deeper understanding to tackle future problems(f.e. Fixing bugs or security problems) .
The problem is that there is never feedback but only a naive answer. Kin never cared to use the benefits of open source mentioned above until they lost their app, they never cared to build up a community(loyal stupid kool-aid moonbois excluded) and in fact they still fail. Their plan till now was to use that money to bailout their own app which they attempted to do(draining ico money to do a 2y old rework of their app while they are still able to participate in the kre payouts on top of 3t coins plus using ICO money to defend the app KIK against their scammy move) but now they see that they failed and they need us more than ever. Did you guys forget how they were running the show till now treating us like shit? Those guys are sociopaths/psychopaths, scam artists that have mastered the art of deceiving. ted_on_reddit
We saw this unfolding when Adam suggested that the KRE is fucked up. Months after, Ted and his team realize that this is the case.
//Edit - i typed this on my phone thus the bad structure
submitted by 0xKilluah to KinFoundationTruth [link] [comments]

Blockchain Receive Payments API v2 HD BIP32 xpub Bitcoin JSON-RPC Tutorial 3 - bitcoin.conf bitcoin ticker PHP tutorial from btc-e API using json+php Building Bitcoin Websites - Blockchain API 2 of 2 Blockchain Términos de servicio API

Fill out form and click “Create New API Key Now” Once generated you can view your keys under API Settings; Websocket API. The Websocket API can be used to receive market data and to interact with the trading system in real time. Every message is in a JSON format and trading messages use the FIX standard for naming of fields, and message types. Blockchain Data API. Query JSON data on blocks and transactions. Almost all the data you see on this website is available in JSON format. View Documentation. Simple Query API. Simple plain text API for querying blockchain data. View Documentation. Websockets. Low latency streaming socket channel providing data on new blocks and transactions. Some API calls are available with CORS headers if you add a &cors=true parameter to the GET request . Single Block. https://blockchain.info/rawblock/$block_hash; You Now you can transfer Bitcoin from your new blockchain wallet API. All transactions are worth a 0.0001 BTC miner’s fee. This is how it looks in PHP: The result of its execution is processed by the user system (the result will be in JSON format). All about blockchain info API is stated in the blockchain API documentation. Bitcoin price index data and the API has been used by many projects, tools, and journalists. Some uses of the XBP are shown below: We’d love to hear how you’re using the CoinDesk XBP !

[index] [14743] [5480] [318] [2507] [1610] [15202] [9037] [14261] [15030] [1519]

Blockchain Receive Payments API v2 HD BIP32 xpub

Building Bitcoin Websites - Working With Blockchain.info JSON Data - Duration: ... Bitcoin API - Bitcoin, Crypto currency live and historical data to excel - Duration: 10:55. Ethereum 2.0 LIVE - Blockchain & Exchange and the Future of ETH 2020 Ethereum FUND 146,811 watching Live now Clean Code - Uncle Bob / Lesson 1 - Duration: 1:48:42. This program explain a real time python program example to json format data to mysql database and schedule the job using crontab. http://naveendavisv.blogspo... 🔷Ethereum 2.0 LIVE - Blockchain & Exchange, Finance, Investments 2020 and the Future of ETH Ethereum 2.0 15,578 watching Live now 시경이형~이번엔 한우 짝갈비야~ - Duration: 15:39. How To Easily Query Bitcoin Blockchain Stats with Blockchain.info API - Duration: ... Working With Blockchain.info JSON Data ... Programming a simple bitcoin trading bot with bitfinex API ...