Live Updated Cryptocurrency Investment Tracking Spreadsheet (Update 2)

We present an update of my previous article for cryptocurrency investment tracking. I received valuable feedback from some users, and I decided to update the spreadsheet based on those suggestions.

The idea with this new spreadsheet, is to add only the transactions in the History tab:

Cryptocurrency Investment Tracking History
Live update Cryptocurrencies Positions History

And reflect current asset position in the ‘Position’ tab:

Cryptocurrency Investment Tracking Positions
Live update Cryptocurrencies Positions

Also, ‘Prices’ tab contains the cryptocurrencies prices:

Cryptocurrency Investment Tracking Prices
Live update Cryptocurrencies Positions Prices

This new structure keeps tack of all your transactions, and also allows to calculate the profits of those movements.

You can see, copy and comment the Cryptocurrencies Positions Spreadsheet.

Review of AppeCoin: An Alternative Anonymous Cryptocurrency

AppeCoin, Sergio D. Lerner‘s proposal for an e-cash scheme, is designed for a peer-to-peer network which does not rely on a Trusted Third Party. Like the cryptocurrencies Monero or Zcash, AppeCoin is a protocol which aims to guarantee to its users full privacy. Lerner’s e-cash scheme leverages coin shuffling. Unlike ZeroCoin, where the monetary units are of a fixed value and so the transaction amount can be deduced from the number of units sent, AppeCoin enables users to truly hide transaction amounts by offering the option to divide and combine coins.

You can find the latest version of the AppeCoin draft here.

Overview:

Peers have private accounts and can send monetary units, called bills, to other peers. The amount of a bill is encrypted and is only known to the bill`s owner. Bills can be divided into smaller bills or combined into larger bills. The process of bill splitting and bill combining can be done without revealing the value of the bill or its parts. Zero-knowledge proofs are used to demonstrate correctness: the value of the bill is equal to the sum of its parts. There is a minimum bill value in order to avoid inflation.

Transactions to other peers can be sent without revealing their public addresses by using universal re-encryption. Once a payment is sent, it has to be accepted by the receiver. Payer and payee exchange the secret keys of the encrypted bill. The communication between payer and payee uses hybrid encryption and entity authentication.

The community verifies the validity of transactions and that coins have been divided or combined correctly. In a proof-of-work based framework, these changes are recorded in a ledger maintained by the miners. In order to increase anonymity, AppeCoin provides private, delegated, and public bill shuffling. The correctness of the shuffles is verified by the miners.

AppeCoin seeks to ensure (see p. 6 in draft):

  • Efficiency: low transaction wait-time.
  • Security: no double-spending, no over-spending, unforgeability (of bills and payment transcripts), authenticity, non-repudiation, portability.
  • Privacy: anonymity (payer cannot be identified from data exchanged during payment), untraceable (infeasible to follow the history of a bill), unlinkable payments, private account balance, hidden transaction amounts.

The difficulty of the decisional Diffie-Hellman problem and of the representation problem should guarantee security and privacy as long as the encryption scheme used resists Ciphertext-only attacks and Chosen-Plaintext attacks.

More Details:

Below, we describe some key cryptographic building blocks and algorithms used in the AppeCoin protocol.

A.1: Universal Re-Encryption of Schnorr Public Keys: A bill contains the public key of the present bill owner. Universal re-encryption is used to re-encrypt the public key of the bill owner without making him change his private key.

A.2: Bill Shuffle: The BillShuffle algorithm shuffles the bills and provides a zero-knowledge proof of correctness of the shuffle. The input of the BillShuffle algorithm is a list A = (a1, … , an) of bills ai with i=1, … , n and its output is a list B = (b1, … , bn) where bi is the encryption of  aπ(i) for a permutation π with encryption key k.

Two proof systems are considered in AppeCoin proposal. Both apply the Fiat-Shamir heuristic to an interactive public-coin proof system. The second proof system proposed uses a (pseudo-)random subset test which makes it more efficient. Zero-knowledge is achieved by blinding the encryption key and only showing the verifier the image or preimage of a randomly chosen subset under the given permutation π, but not the subset itself. The prover commits to the encryption of the product of the elements of the subset. The assumed hardness of the representation problem makes it difficult to just guess the product.

A.3: CoinSplitting: The input of the CoinSplitting algorithm is a bill a and produces an output of two bills b and c whose values add up to the value of bill a. The algorithm provides a zero-knowledge proof for correctness.

The amount v of a bill is hidden in the exponent, i.e. as xv. (Note that in the proposal exponentiation refers to homomorphic encryption). The core idea of the CoinSplitting algorithm for proving balance, i.e. va= vb + vc, is to check the correctness of the equation xva = xvb × xvc.  A blinding factor is used to disguise proportion: xkva  zk= xkvb  zkb × xkvc zkc  with k=kb + kc for random kb and kc. The prover changes exponents or multiplies factors and provides the verifier with proofs of knowledge.

A.4: InRangeProof: The input for the InRangeProof algorithm is a bill and a range for its value. When the bill is in the given range, the algorithm´s output is 1.

A.5: SendBill: This action includes two algorithms which produce a public and a private message.

Public message: This message is spread through the network and contains the hash of the public key of the current bill owner, and the destination address and signature of the sender.

Private message: This message is sent privately from the sender to the receiver of the transaction, and is essentially the encryption of the secret keys of the bill, so that the receiver can verify the amount and modify the bill.

A.6: ReceiveBill: The receiver checks the sender´s identity, and verifies that the bill and the amount which was sent to him, is correct.

A.7: Public Check of Transaction: Miners search for the serial number of the bill in the ledger, and verify that the bill is unspent and that the sender´s Schnorr signature is correct. The sender´s public address is temporarily visible, until it is disguised by re-encryption.

Comments:

We think the AppeCoin proposal is exciting and would like to comment on some of its strong points and point to places which we think should be filled out more.

Ad A.1: Universal Re-Encryption:

a) The decisional Diffie-Hellman (DDH) should be assumed instead of computational Diffie-Hellman (CDH) (AppeCoin draft, p. 8).

b) The AppeCoin draft claims that universal re-encryption is secure for any encryption scheme satisfying indistinguishability, but provides no reference. Young/Yung´s article Semantically Secure Anonymity: Foundations of Re-Encryption demonstrates the security for one such encryption scheme, the ElGamal encryption.

Ad A.2: BillShuffle:

a) Security aspects: Formal proof is needed for the claim that BillShuffle provides a non-interactive zero-knowledge proof.

The Fiat-Shamir heuristic is a common way to transform a constant round interactive proof into a non-interactive proof. The heuristic is proven to be secure, i.e. computationally sound, in the random oracle model. Some examples of insecure transformations exist in the plain model, but the Fiat-Shamir heuristic applied to interactive proofs, not just arguments, was recently  proven secure under some conditions for the hash functions involved. See Tauman-Kalai/Rothblum/Rothblum.

Some evidence is provided for the security of the BillShuffle algorithm, but there is no formal proof of security in the draft. Completeness is straight-forward. The article of Tauman-Kalai/Rothblum/Rothblum may imply that the BillShuffle algorithm satisfies computational soundness even in the plain model: the Fiat-Shamir transform is applied to proofs. Although it seems plausible that zero-knowledge can be deduced from the strength of the encryption scheme, the required zero-knowledge simulator is missing.

b) Performance: The proof system with the random subset test requires an average of rounds*3/2 exponentiations to prove and verify a shuffle of n bills which results in a very fast run time. [Compare the shuffle protocol by Abe (22*n log⁡(n) exponentiations), Sako-Kilian (642*n exponentiations), Furukawa or Groth or Lipmaa-Fausti/Zajac (using pairings: roughly 3n), Lindell-Pinkas (cut-and-choose on circuits; roughly  15qn + 39n + 10q + 6 exponentiations, where q is a statistical security parameter)].

The private keys of shuffle participants may be vulnerable to side-channel attacks since a participant of a shuffle must decrypt all shuffled bills until he finds his own which causes an average of n/2  calls of his private key.

c) Technical Remarks:

  1. In figure 4, the definition of bw as bw:=awk is missing.
  2.  In figure 7, p. 13, Blob D should start with s (number of rounds) in order to have the same hash H(C) as in the proof;
  3. In figure 7, p. 13, bj in 8.2.3 should be swapped with aQ(s,i)  in 9.2.3;
  4. In figure 8, p. 14, in 14.1.1.3, ts × k should be replaced by rs × k. Index s should be j. Similarly, this applies to ts × k-1  in 1.4.2.1.1.

Ad A.3: CoinSplitting:

a) Security aspects: Formal proof is needed for the claim that CoinSplitting provides a zero-knowledge proof for correctness.

Heuristically, the Discrete Logarithm Problem makes it hard for the prover to cheat the verifier by changing exponents. The prover could try to push some part of vb into the exponent of the neighboring factor z, but he would have to know the logarithm of the blinding factor  (which should be verifiably chosen at random) with respect to the basepoint or with respect to x. However, the draft lacks a formal proof for soundness. Although we could find no evidence that the proof in CoinSplitting leaks information, the draft does not provide a formal proof for zero-knowledge.

b) Performance: Proof and verification for two bills requires 12 exponentiations and many zk-proofs of knowledge of encryption keys (e.g. using Schnorr ID protocol in case of a Pohlig-Hellman encryption scheme). The proposal´s author, Sergio Lerner, hopes to improve this in the future.

c) Technical Remarks:

  1. In DecompProof1, p. 23, we suggest defining bu as bu=au, i.e., bu= auk qb ; otherwise bt= budoes not hold;
  2. In DecompProof1, p. 23, Step 6 should be analogous to step 3.

Additional Resources

If you liked this article, you might also like:

Live Updated Cryptocurrency Investment Tracking Spreadsheet

This Google Spreadsheet can help you track your cryptocurrency investments. It gets the prices from an external API and keeps them updated. It supports the 15 most popular cryptocurrencies. It uses Poloniex and Cryptocompare APIs to retrieve latest currency’s rates:

Cryptocurrencies Value Calculator

It uses a script based on FastFedora Project which can be optionally downloaded from GitHub.

Instructions:

  • Go to the Google spreadsheet here.
  • Go to File -> Make a Copy.
  • Put you own cryptocurrencies and values.
  • Enjoy!

Fast Smart Contracts Execution in an Ethereum Private Blockchain Development Environment

We describe a geth source code change which enables faster block mining. We hope this option will be included in Ethereum command lines.

Private Ethereum blockchains may be deployed by private entities to use in production or in the software development process. There are different ways of speeding the development environment. Some developers choose an Ethereum branch which does not depend on mining via slow proof-of-x methods. Others prefer a modification of the most up to date Ethereum node. The unchanged Ethereum node takes about 15 seconds per new block, while the mining difficulty function below dramatically reduces this lag time.

For developers, this means faster transaction and smart contract execution since every smart contract function, every event fired, and every state change depends on block mining time.

Source Code Change

In the current version you should replace CalcDifficulty here with the following:

Note

Increasing the mining rate will reduce your filesystem capacity much faster than usual due to the underlying Ethash DAG. You can safely remove your ~/.ethash directory to free space. Be sure to stop geth first.

Alternatives

Private blockchains which use different consensus algorithms can still take advantage of the Ethereum virtual machine and the programming languages supported there (e.g. Solidity). See the following technologies:

Real World Project in Private Blockchain Development

In the blockchain development industry lot of new technologies had arisen in the latest months. Unfortunately, most of the new platforms are not ready to use in production or directly they were built only to develop Demos.

Our developers in Coinfabrik have been struggling to use them in the real world. Our customer asked to use Hyperledger but our initial tests were not successful. It was difficult to make the blockchain work and the smart contract platform is not ready yet. Therefore, the only available option was an Ethereum based blockchain since the EVM is the only one able to run smart contracts out of the box. We first tried Monax Eris but they provide docker images which we were not able to make it work on AWS and also they did not provide a permissionable smart contract store. Then, we started testing JP Morgan Quorum platform for this blockchain software development project. To start, we solved the AWS issue, also present in Monax Eris. In addition to this, we found that Cakeshop, Quorum’s smart contract deployment tool, was not working fine. It was able to publish only small smart contracts but we needed to develop some bigger ones and it did not work at all. In addition to this, Quorum does not have a Web3 like interface so the interaction with the smart contracts was very hard. Monax Eris provides a different API which is richer than Quorum interface.

Finally, we started testing our own Private Ethereum Blockchain. We had to solve some gas price issues to avoid ‘out of gas’ issues, PoW difficulty adjustments and some issues with Solidity versions but it mostly worked. The problem we found when relaying on a smart contract for all the website functionality is that everything was slower than we were expecting, user interaction was not fluent. That is why we had to adjust the complexity to generate blocks every second or faster, which ended up in a very fast blockchain storage grow. We fixed it modifying core code to trigger block creation in a different way. This problem is not present in Monax Eris since they use Tendermint which generates new blocks when it is necessary.

Conclusion

Private Blockchain development technologies are very immature and are not ready for the real world. Each small task requires a lot of time and adjusting the platforms is not straightforward and there is almost no documentation. I hope Enterprise Ethereum Alliance can fix the platform to use it for enterprise use.

zk-SNARKs Technically Explained: Basic Principles

The full technical article is available here.

Introduction

Payment confidentiality is a property for cryptocurrencies which allows the user to hide the sender and receiver, as well as the amount of a transaction in the blockchain. Monero Research Lab invented Ring Confidential Transactions, while Zcash uses a different approach based on recent scientific progress in the field of ‘Non-Interactive Proof systems’: zk-SNARK protocol for circuits.

Circuits are basically ‘programs’ which take values as inputs and result in an output value. The corresponding decisional problem is to determine whether a given assignment for the inputs and output of a specific circuit is valid. Such a problem can be reduced to an algebraic problem about polynomials which allows a ‘shorter’ verification and, at the same time, can hide the correct assignment from the verifier. This might sound unlikely, but we will see how it is possible.   

Our aim is to illustrate the reduction of the decisional problem for circuits to an algebraic property of polynomials, which C. Reitwießner’s excellent survey zkSNARKs in a Nutshell leaves out,  and to show how this reduction can be used for zk-SNARK. Please see M. Green’s blog post Zero-Knowledge-Proofs: An illustrated Primer  for a good survey  of Zero-Knowledge-Proof.

We will discuss the security assumptions behind zk-SNARKs in a future article.

If you liked this article, you might also like:

Quantum Resistant Public Key Exchange: The Supersingular Isogenous Diffie-Hellman Protocol

Synopsis of our full article:

Though the research on quantum computers is still facing big challenges, there is also some progress in this field. The National Institute of Security and Technology (NIST) recently published a report on Post-Quantum Cryptography which informs about new developments. They believe that it is time to think of quantum-safe primitives, and  announced open calls to encourage researchers to work on proposals. This continues prior work in the field by D. J. Bernstein and others.

Quantum computers would endanger all cryptographic protocols which are based on prime factorization and discrete logarithms. Private keys used for transactions in Ethereum and Bitcoin would no longer be safe. Shor`s algorithm could be used to discover them in quantum polynomial time. We will give a glimpse of the idea of how this algorithm works, starting with  Deutsch´s quantum algorithm which is easier to understand but shows already some basic principles.

Some cryptographic protocols, including code-based, lattice-based or hash-based cryptography,  would already survive quantum computers. De Feo and Jao´s proposal — the Supersingular Isogenous Diffie-Hellman Protocol — which we discuss in the article, has the advantage of being exponentially complex while having much smaller key-size compared to these other protocols. The very recent work by Castello-Longa-Naehrig presents a high-speed and constant-time implementation of SIDH which pushes this proposal further for practical use. We will briefly discuss their interesting proposals.

Comparison of Cryptocurrency Developments

Working for our customers in our blockchain development company we built this spreadsheet which is a work in progress, comments are welcome here, which describes the features of multiple blockchain and sidechain technologies. Views about blockchain technologies range from hype to skepticism. A blockchain is a distributed database and consensus network that can be used to validate cryptocurrency transactions. Blockchains do not replace conventional databases, instead they create consensus protocols between untrusted parties on what information needs to be appended to a shared database. This obviates or reduces the need for trusted third parties in financial agreements.

Below we describe the different types of blockchain players and their features:

Type of player

  • Cryptocurrencies (e.g. Bitcoin, the first cryptocurrency in history)
  • Blockchain platforms (e.g. Ethereum, a platform that has its own cryptocurrency)
  • Sidechains (e.g. Rootstock, a sidechain which provides smart contracts for Bitcoin)
  • Distributed ledgers/private blockchains (e.g. R3 develops blockchains for the financial industry)

Market capitalization

Market capitalization is a meaningful indicator of the importance and power of a blockchain player. Bitcoin is the biggest player with a market capitalization of approximately 10 billion dollars, followed by Ethereum with around 1 billion dollars (as of July 2016). This can change quickly, because it’s a young and therefore unpredictable market.

Liquidity

A meaningful indicator for the usability and value of a cryptocurrency is liquidity. Liquidity defines how easily and quickly cryptocurrencies can be purchased or sold without significant loss.

License

Most players have licensed their software as open source. For example Bitcoin is licensed under the MIT free software license.

Asset names, currency symbols and three letter currency codes

Cryptocurrencies and sidechains use unique asset names, currency symbols and three letter currency codes to identify themselves. For example Bitcoin, which is also the asset name, uses ฿ as its currency symbol and BTC as its official three letter currency code.

Public and private

Public blockchains are available to the general public, while private blockchains are restricted to clients and internals of banks or other institutions.

Identity

Identity protection and privacy may be important to users and traders to safeguard their business strategies, while identifying users may be important to criminal and tax institutions. There are different levels of protection:

  • anonymous (traders or users cannot be identified by anyone)
  • pseudo-anonymous (traders or users can be identified only by blockchain intelligence and network traffic analysis)
  • private (traders or users identities are only known to the organization running the blockchain or platform)
  • transparent (traders and users identities are known to everyone)

Consensus methods

Consensus methods like Proof of Work or Proof of Stake determine how transactions are validated.

  • In validation by Proof of Work (PoW) the result of an expensive cryptographic calculation is required as proof of the right to vote on consensus.
  • In validation by Proof of Stake (PoS) the amount of voting power for consensus is directly proportional to the shares held. For example, holding 10% shares bestows 10% voting power.

Scripting language, Turing completeness and smart contracts

Many cryptocurrencies have their own scripting languages which can be embedded into transactions. Some languages are Turing complete (e.g. Solidity in Ethereum) and can run any algorithm. This is necessary to run smart contracts which are programs to conduct consensus-enforced contracts between users. Insurance companies could use smart contracts to compensate automatically for crop loss due to hail, for instance. A supply service could use a smart contract to charge on delivery. A more complex example of the use of smart contracts is a DAO (Decentralized Autonomous Organization), a company run by smart contracts rather than by managers. Smart contracts can be used for financial products, property registration, prediction markets, crowdfunding, and other purposes.

Governance, Stakeholders and Conflict of Interests

Governance refers to who decides what happens with a blockchain in terms of software updates: Miners, nodes, users, the core development team, and other stakeholders. Ideological, technical, financial and privacy interests can influence the direction of a cryptocurrency. This can lead to conflicts of interests among the governance and may even cause a cryptocurrency to split and form an Altcoin.

Transaction speed, fees and micropayments

Cryptocurrency transactions should be fast and cheap and even micropayments should be allowed. The proof of stake consensus method allows faster and cheaper transactions, although these are less secure than those which use proof of work. New off-chain methods offer secure, instant micropayments. This is useful when charging for small amounts, like in pay-per-minute video streaming, or pay-per-megabyte data transmission.

Processing power

Processing power costs (CPUs, GPUs, ASICs) are proportional to energy costs. Proof of work tends to require a lot of energy and substantial computer equipment. proof of stake is less expensive.

Security

A variety of attack vectors challenge the security and reliability of a blockchain. Here are some examples: A 51% Attack is when a stakeholder of a Proof of Stake cryptocurrency owns 51% of all shares and abuses his or her majority power to bias consensus to agree on double spending. A Sybil attack is when one node fakes various node identities and gains a voting advantage to bias consensus.

Note: Bitcoin’s security threshold is not 51%, but about 33% due to selfish mining. Ethereum’s security is theoretically 12.5% due to uncle mining. The only PoW blockchain that has 51% security is RSK.

Some Comments on the Security of ECIES with secp256k1

The challenge of modern cryptography is to find efficient but secure encryption schemes. The Elliptic Curve Integrated Encryption Scheme (ECIES) is a widely used encryption scheme which is specified in many standards. It is used for example in Ethereum’s Whisper. While Bitcoin Core does not implement ECIES, it can be employed to send secure messages using Bitcoin keys. Together with the Decentral Jaxx project we contributed with the OpenPGP.js project that follows this approach.

Most encryption schemes rely on the intractability of some variants of the Diffie-Hellman problem. ECIES security assumes, amongst other things, that the hashed decisional Diffie-Hellman problem over the specified elliptic curve is of exponential complexity. Although this problem is easy for a specific class of elliptic curves, the rest can currently only be solved via discrete logarithms. This is in general a harder task which is believed to be of exponential complexity for carefully chosen elliptic curves.

In our paper here we summarize the ECIES scheme and its security when paired with the secp256k1 curve of the SEC Group which is currently used in Ethereum.  (For more information about the complexity of the discrete logarithm problem on elliptic curves please see our previous article: ECDSA Security in Bitcoin and Ethereum: a Research Survey)

Interdependent Transactions in Bitcoin, RSK and Ethereum

A recent paper titled The Blockchain Anomaly presents the difficulties the authors encountered when trying to make two transactions interdependent such that the second transaction cannot be executed without the first being confirmed. Although the paper may be useful as a guide, the title is misleading since Bitcoin does not guarantee the order of transactions (no dependencies between inputs and outputs).

Also, “The Blockchain Anomaly” states that Bitcoin requires six block confirmations to finalize a transaction, but the original Bitcoin paper does not actually stipulate a specific number. In addition, each Bitcoin wallet application can choose which algorithm inform the user that a transaction has been confirmed. In fact, for stronger security, the number of block confirmations should not be constant, but should depend on several factors:

  • Transaction amount (large transactions require more confirmations to prevent double-spending)
  • The properties of other transactions included in competing blocks (such as the presence of bribe fees) during the confirmation interval
  • The properties of other transactions included in the confirmation chain (to detect if these other transactions could be targeted by double-spend attacks which reorganize the blockchain)
  • The state of the network’s hashing power (to detect sudden drops which might indicate the preparation of a parallel secret branch by an attacker)
  • The state of trusted peers (to detect Sybil attacks)

The same happens in Ethereum, users are not obliged to wait exactly 12 block confirmations. . First, let’s try to define the problem more clearly. One formulation might be: “Alice wants to pay to Carol only if Bob pays to Alice first”. As Nakamoto consensus only assures probabilistic settlement, this problem can be easily solved by picking a long enough confirmation time for the Bob/Alice transaction (e.g. 7 days of confirmation blocks). Then if the payment is reverted, the whole platform would be halted as insecure and the Alice/Carol payment will never be confirmed either, so this problem is not very interesting. A more interesting problem would be “Alice wants to pay to Carol as soon as Bob pays Alice”. This problem arises in a number of contexts such as in a crypto asset exchange, spending money right after an investment has been secured, or in fast betting applications, such as SatoshiDice.

Solutions

For Bitcoin, one solution is to create a single transaction that contains both payments, but this requires off-chain coordination that is beyond of the scope of the problem. In addition, this solution will not work if the second payment is governed by a third condition, such as winning the SatoshiDice game. A simpler and more elegant solution is to use the unspent output of the Bob/Alice payment as an input of the Alice/Carol payment. This makes the second payment consensus-dependent on the first, establishing a static dependency. The cost of this solution is near zero: in the worst case it is the transaction fees related to the overhead of the space consumed by one input.

In Ethereum and RSK we cannot link two transactions unless they are created by the same account and contract. When two transactions are created by the same account, the second payment cannot be confirmed without the first because each transaction has an increasing nonce value, and nonce values cannot be skipped. If the payments are created by different accounts, then we can link them with a conditional payment contract. This contract must be created and funded on creation, before the first payment, and it automatically self-destructs afterwards. Here it is:

This contract solves the problem when the conditions of the payment to C (e.g. amount, additional transaction data) are known before the payment to the conditionalPayment1 is executed. If the conditions for payment to C must be decided by Alice after Bob’s payment, then a contract like the following conditionalPayment2 contract is required.

Both conditionalPayment1 and conditionalPayment2 are hard-wired for particular source and destination addresses, but a generic contract can also be created to handle third party conditional payments in a trustless manner. Generic contracts require:

  • An initial transaction to set up the conditional contract.
  • A secure method to send the address of the contract, since he may not know Alice’s address.
  • Two transactions If the payment from Alice to Carol is greater than the payment from Bob to Alice. Alice must fund the contract with additional coins (using fund() or when creating the contract), or split her payment to Carol into two different transactions, one coming from the conditional contract and the other from Alice’s own account.
  • Almost 100 times more gas than two standard transactions. This means that a generic contract is 100 times more expensive.

Both RSK and Ethereum platforms have a special opcode BLOCKHASH that allows a contract to retrieve the hash of one of the previous 256 blocks counting from the block being processed. This opcode is a better way to create dependencies. The underlying idea is that after Bob’s  transaction to Alice has been confirmed, Alice creates a transaction to Carol as an on-the-fly contract that checks the blockchain to make sure Bob’s transaction is there. If it is not, then the contract returns the funds to Alice, and only some minimal gas is consumed.

On-the-fly contracts can also be used to reduce storage costs. When a new contract is created, some setup code given by the creator is called. When programming in Solidity, this setup code is the smart contract constructor (whose name is the same as the contract name). The constructor can perform any operation and self-destruct afterwards , which prevents the smart contract from persisting, and refunds the cost of contract code storage to the creator. This makes Alice’s transaction far cheaper.

The following is an example of a Solidity smart contract based on BLOCKHASH. In Solidity, the BLOCKHASH opcode can be accessed using the block.blockhash() method. Alice must set the blockIndex and blockHash as soon as Bob’s contract has been observed in the blockchain. The blockIndex is the blockchain height of the block that contains Bob’s transaction and blockHash is the block ID or hash.

The cost of executing this contract is only five times the cost of a single transaction.  Re-writing this small contract in RVM/EVM assembler would probably cut that cost in half.

RSK Labs is creating an Ethereum-compatible platform that tries to cover the most common use cases at the lowest possible cost. RSK is working on new opcodes and native contracts to allow transaction dependencies with lower overhead. The RSK virtual machine release 2.0 has a new native contract, IS_TRANSACTION_MEMBER, which receives a block number, a transaction hash and an SPV proof for the transaction trie as arguments and returns “true” if the transaction is included in that block, and “false” otherwise. A similar native contract, IS_LOG_MEMBER, can be used to detect whether a certain log entry has been recorded in the receipt trie. With these native contracts you can, for example, create a contract that pays Carol if Bob pays Alice, but allows the payment from Bot to Alice to be fully independent from the contract. For example, suppose that X is a contract where users vote to elect one of the members as president. When a president is elected, a message stating the elected user account is logged or, some coins are sent to the elected user account. Then, a contract Y can be created that rewards the elected user by sending him coins from contract Y. Contract Y can be called by any user, sending the “proof of winning election” as an SPV proof using IS_LOG_MEMBER/IS_TRANSACTION_MEMBER.

Conclusion

Programmers of smart contracts should pay special attention to transaction dependencies when fast responses are required or when a break in the dependency causes significant monetary loss. Input/output dependencies can be used to easily create guaranteed transaction dependencies in Bitcoin , but special smart contracts are required in RSK and Ethereum. The naïve RSK/Ethereum smart contract which receives a first payment and only afterwards performs a second payment is very expensive in terms of consumed gas. BLOCKHASH can do the same thing at 1/20 of the cost. RSK is working on additional opcodes and native contracts to provide this functionality without the need to specify a new destination address for a new contract for the first payment.