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)
  • pseudonymous (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 Poof 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.

Swagger Specification for Coinbase API v2

Coinbase has official client libraries for Python, Ruby, PHP, Node.js and Java, but what about other languages? Enter Swagger. Swagger is an open-source project which includes an specification for describing APIs in JSON or YAML and tools for generating ready-to-go client libraries in several languages.

Here at CoinFabrik, we have been writing a first draft swagger specification for Coinbase API v2. We’ve got the basics covered for now: Users, Accounts, Addresses and Transactions. If you would like to help expand the scope, make a pull request on the github repository.

Generating a Client Library

The easiest way to generate a client library for your language of choice is to load the swagger.json file into the Swagger Editor and then download it from the “Generate Client” tab. The libraries come with full documentation on how to use them, complete with examples.

This is the full list of languages and frameworks that can be generated right from the Swagger Editor:

Akka ScalaAndroidAsync ScalaClojureC#
C# .NET 2.0DartDynamic HTMLFlashGo
HTMLJavaJavaScriptJavaScript Closure AngularJmeter
Objective-CPerlPHPPythonQT 5 C++
RubyScalaSwiftTizenTypescript Angular
Typescript Node

ECDSA Security in Bitcoin and Ethereum: a Research Survey

Elliptic curve cryptography is becoming more and more popular. One of its main supporters is the cryptocurrency system Bitcoin which uses an elliptic curve scheme for their digital signatures. Smaller key size, a more efficient implementation than the RSA system, and a similar level of security make elliptic curve cryptography an interesting alternative to RSA.

Signatures based on elliptic curves are, mathematically speaking, currently very safe. There are, however, well-known attack strategies available, most prominently Pollard’s rho method, which one should take into account when choosing an elliptic curve. The SEC Group’s curve secp256k1, which is currently used in Bitcoin and Ethereum, has no known mathematical vulnerabilities, although it is more vulnerable to small design flaws than others. A private key has already been successfully extracted with a side-channeling attack and an invalid-curve attack might also be possible.

Those who want a deeper exploration of the security level of the signature scheme used in Bitcoin and Ethereum can read our full survey, complete with references to other articles here.