Background
Bitcoin is today, as it has always been, by far the most widely used cryptocurrency, the most valuable cryptocurrency, and consequently also the most secure blockchain. All other blockchains and decentralized consensus mechanisms suffer from at least one of the following problems:
- they provide no compelling advantages over Bitcoin itself
- they lack a developed software ecosystem
- they lack name-recognition, community adoption and merchant adoption
- they could be attacked with little effort and low cost, as the security of a blockchain is roughly proportional to its value
As of November 2014, the “market capitalization” of Bitcoin is over 90% of that of the entire cryptocurrency economy (source), in which there are over 500 separate and incompatible currencies and protocols. Given this, we believe the way forward is to consolidate the markets and features of the entire cryptocurrency world onto one blockchain. The best candidate host chain is the Bitcoin blockchain itself, given its indisputable preeminence.
With one blockchain, the Bitcoin motto vires in numeris takes on a whole new meaning, because the strength of each use of a given blockchain reinforces every other. The problem with this is that Bitcoin, while revolutionary in so many ways, is actually rather limited in its capabilities. Bitcoin is really only two things – a ledger recording distributed consensus, and a currency whose transactions are recorded in that ledger. Bitcoin even lacks native support for the creation of additional digital tokens on its blockchain.
Counterparty remedies this situation by providing a platform for general peer‐to‐peer finance on the Bitcoin blockchain. Counterparty effectively extends the Bitcoin protocol in a safe and backwards‐compatible fashion. Bitcoin nodes not aware of Counterparty’s existence can safely ignore it (and discard its data); nodes that parse Counterparty transactions can leverage the power of the Bitcoin blockchain to support such forward-looking features as a distributed digital asset exchange and options markets. The Bitcoin protocol stays exactly the same, while supporting the development and adoption of valuable new features, all secured by the full power of the Bitcoin network. On top of this, the Bitcoin currency itself can be used directly, trustlessly and in a peer‐to‐peer fashion within the Counterparty protocol. With Counterparty’s tight integration into the Bitcoin blockchain, it is just as decentralized and robust as is Bitcoin itself. The benefits of this cannot be overstated.
The limitation of Counterparty up to now has been that all of its smart contracts have had to be hard‐coded into the protocol’s reference client by a set of core developers (as is the case with Bitcoin itself). This means that the addition of new features has been much slower than it needed to be. The solution to this problem is to allow users to write their own smart contracts, which they (and other contracts) can execute whenever they want.
This is the basic model of Ethereum, which is a project to create a novel blockchain in addition to a programming language and virtual machine for the creation of smart contracts. But the development of a new blockchain is unnecessarily slow and risky. Instead of reinventing the wheel, we, the cryptocurrency community, should be making evolutionary, tractable improvements to Bitcoin itself, whenever possible.
Counterparty Contracts
With Counterparty Contracts, users may write Turing Complete smart contracts into the Bitcoin blockchain and execute their code on all Counterparty nodes. We’ve ported Ethereum’s language and virtual machine over to the Counterparty platform, using the pyethereum codebase. The result is hosted on GitHub and open for public testing. Today, you can take Turing Complete Ethereum code, or write your own, and run it on Bitcoin with Counterparty. Anything that one could ever do with Ethereum, one can now do with Bitcoin and Counterparty.
One of our primary focuses was around maintaining compatibility between the Counterparty and Ethereum contract language. This also maximizes the security of the system. Our success is reflected in the fact that our implementation passes 100% of pyethereum’s contract execution integration tests:
~/counterpartyd > py.test test/pyethereum_contracts_test.py -v -x
=============================== test session starts ================================
platform linux -- Python 3.4.2 -- py-1.4.25 -- pytest-2.6.3 -- /usr/bin/python
collected 14 items
test/pyethereum_contracts_test.py::test_evm PASSED
test/pyethereum_contracts_test.py::test_sixten PASSED
test/pyethereum_contracts_test.py::test_returnten PASSED
test/pyethereum_contracts_test.py::test_namecoin PASSED
test/pyethereum_contracts_test.py::test_currency PASSED
test/pyethereum_contracts_test.py::test_data_feeds PASSED
test/pyethereum_contracts_test.py::test_hedge PASSED
test/pyethereum_contracts_test.py::test_post PASSED
test/pyethereum_contracts_test.py::test_suicider PASSED
test/pyethereum_contracts_test.py::test_reverter PASSED
test/pyethereum_contracts_test.py::test_stateless PASSED
test/pyethereum_contracts_test.py::test_array PASSED
test/pyethereum_contracts_test.py::test_array2 PASSED
test/pyethereum_contracts_test.py::test_array3 PASSED
==============================14 passed in 63.47 seconds ===============================
~/counterpartyd >
Counterparty contract addresses are even compatible with Ethereum’s, and there are only a few necessary and minor incompatibilities in the two contract languages:
- Two EVM opcodes (
COINBASEandGASLIMIT) involved in mining were removed because XCP is unmined. - The new
ASSET_BALANCEopcode may be used to retrieve the balance of native Counterparty assets and BTC. It takes two inputs (addressandasset_id) and returns one value (the balance of the address in the asset named). It has the same gas cost asBALANCE(which looks only at XCP). - The new
SENDopcode may be used for sending native Counterparty assets to Counterparty (Bitcoin) addresses.SENDhas three inputs (address,quantity,asset_id) and no outputs; it has the same cost asCALL.
The basic fee structure of Counterparty Contracts will be very similar to that of Ethereum. Different computational or storage operations will be associated with different fees, to prevent abuse of the system. Contract execution fees will be paid only in XCP, the native currency of Counterparty, (it would not be possible for them to be paid in Bitcoin). The contract system will be fully compatible with the existing Counterparty asset system and decentralized exchange.
The economics of the fee system for Counterparty Contracts will necessarily be rather different from those of Ethereum, simply because there are no Counterparty miners. All Counterparty nodes will execute all contracts, and it will be the holders of XCP that receive the fees for the execution. The simplest and most robust way to make this payment will be just to destroy the fees, and to thereby reduce the money supply, as this is equivalent to paying the fee out to all holders of XCP in proportion to the size of their holdings. Unlike with Ethereum, the fees will not be constant values, but rather fractions of the total extant supply of XCP, so that no amount of computation will deplete the supply of XCP and drive it into negative territory: the divisibility of XCP ensures that there will always be enough XCP.
With a framework for the composition, use, and reuse of arbitrary smart contracts, Counterparty will reinforce its position as the ‘go‐to’ Bitcoin 2.0 platform for individuals and businesses looking to make use of blockchain technology: being built on Bitcoin, it will have the maximum security and the maximum addressable market; being a platform for user‐created smart contracts, it will be able to do anything that any other platform ever could.
The initial launch of Counterparty Contracts will be live on Bitcoin testnet only. The subsequent move to mainnet will be entirely backwards‐compatible, becoming live with a particular block number, the way that all protocol upgrades have thus far occurred. This upgrade will make the vast majority of possible protocol enhancements unnecessary, as it will make Counterparty into an infinitely extensible platform. Existing Counterparty users, and XCP holders, will only benefit from this development.
XCP, in particular, will have a whole new use as consumable value, as it will power what will undoubtedly become the world’s first fully‐distributed platform for smart contracts. This innovation will also be a great boon for Bitcoin, which will become a more complete ecosystem with its release. Every Bitcoin address is already a valid Counterparty address, and with Counterparty Contracts, innovation in cryptocurrency, cryptosecurities, smart contracts and more can all happen on the same blockchain where the crypto-revolution began.
Quick Start
This example uses the Ethereum Project’s tool serpent to compile a simple script for doubling the value of the input data, from Serpent to EVM Code. That code is published and executed on the Bitcoin blockchain using counterpartyd, the Counterparty reference client.
$ counterpartyd.py --testnet server
<wait for counterpartyd to catch up with Bitcoin Core>
$ serpent compile 'return(msg.data[0]*2)'
600e80600b60003960195860026000350260005460206000f26000f2
$ counterpartyd.py --testnet publish --source=$SOURCE --code-hex='600e80600b60003960195860026000350260005460206000f26000f2' --gasprice=1 --startgas=1000000 --endowment=0
<contract ID is 2aef5c6c033e2bc2269a1336c71fda802056cad7>
$ serpent encode_datalist '53'
0000000000000000000000000000000000000000000000000000000000000035
$ counterpartyd.py --testnet execute --source=$SOURCE2 --contract='2aef5c6c033e2bc2269a1336c71fda802056cad7' --gasprice=5 --startgas=160000 --value=10 --payload-hex='0000000000000000000000000000000000000000000000000000000000000035'`
<result is 0x70 = 106>
Further reading on the Ethereum contract language(s) is available here:
