It’s Friday and time for the Counterparty Update. This week featured some exciting community news, technical discussions and development progress.
From the Community
The biggest news from the community is the Bittrex integration of the Counterparty native currency – XCP. Bittrex is a cryptocurrency exchange, founded in 2014 in Las Vegas by a team of 4 computer scientists. It is an altcoin-focused cryptocurrency-only exchange that has the most pairs of all altcoin markets. What differentiates Bittrex from other exchanges is the fact they don’t charge any fees for deposits and withdrawals, and instead of percentage of the volume traded, they take a fixed fee to charge for transactions. For Bitcoin transactions, for example, it is 0.0002 BTC, while for XCP you will pay a fixed fee of 0.1.
Besides Poloniex, Counterparty DEX, MasterXchange, Melotic and ALTS.Trade you now have the option to trade your XCP on Bittrex.
In other news, our Chief Scientist – Adam Krellenstein answered some common technical questions on Reddit. You can find the questions and Adam’s replies below:
Q: How does the Counterparty protocol achieve consensus?
The Bitcoin network uses proof of work to determine the longest chain. Counterparty transactions are parsed from the Bitcoin blockchain and saved to a local SQLite DB, which is actually kept quite small. Is it wrong to assume Counterparty’s consensus occurs on Bitcoin’s blockchain? What goes in these SQLite databases?
What happens when OP_RETURN data is auto-pruned as Gavin Andresen stated quite plainly would happen in due time at MIT?
A: The local Counterparty SQLite database is like the Bitcoin LevelDB database—independent of the consensus mechanism. What goes in the database s the parsed blockchain data: debits, credits, etc. Counterparty only uses prunable outputs to store its data. Counterparty only needs some Bitcoin full nodes somewhere to have an unpruned copy of the blockchain (which is easy, especially as all Counterparty clients will have one).
Q: What are the risks to consensus?
If there is risk of consensus breaks in Counterparty, isn’t there also risk of insiders directly revising Counterparty asset balances or manipulating betting outcomes in their own favor?
If I were to prepend CNTRPRTY to a malicious string and broadcast it onto Bitcoin’s blockchain, it would be parsed by counterpartyd. These counterpartyds would be running on live servers. What is the risk to the servers?
A: All of the Counterparty code is completely open-source. If someone published malicious code, people would notice and not update their clients. Same as with Bitcoin.
All of the data in the Bitcoin blockchain is safely parsed by the Counterparty client. The code is not ‘executed’. Again, all Bitcoin clients also parse Bitcoin blockchain data safely.
Q: How do Smart Contracts form a consensus?
A: Smart contracts don’t form consensus. Every network participant just executes each contract in the same way (like a ‘send’ transaction). The consensus is formed with the blockchain determining which contracts exist and the order they are found in.
Q: Can the Counterparty Team rewrite the Counterparty ledger’s history, in an emergency or by decree? How does that compare to the same risks with Bitcoin Core devs?
Bitcoin payments achieve strong consensus in part thanks to there being more hashing power on the Bitcoin blockchain versus other Proof of Work chains. In addition, there are 7000 Bitcoin full nodes running at any given time. The fact is there are considerably fewer than 7000 people running Counterparty nodes. Doesn’t that mean Counterparty has weaker consensus propertise relative to Bitcoin?
A: It’s identical to the case with Bitcoin. The Bitcoin core devs could publish a copy of Bitcoin Core that does anything, but no one would download it. There aren’t ‘Counterparty nodes’—Counterparty clients only communicate with each other through the Bitcoin blockchain.
Q: Is a 51% attack against Counterparty possible?
Can I 51% attack your SQLite database? I’ll just fork the reference implementation to revise history in my favor and quadruple the number of Counterparty nodes so that my ledger history becomes the dominant one. Would the broadcasts relay faster to my 80% dominant node network? How would a 51% attack on the Bitcoin blockchain affect Counterparty? How would a Bitcoin blockchain reorganization affect Counterparty?
A: To do a 51% attack on Counterparty, you have to do a 51% attack on Bitcoin, and the effects would be the same, too. Blockchain reorganizations are handled by Counterparty the same way they are handled by Bitcoin.
Q: How can a thin client trustlessly lookup the Bitcoin public address associated with the OSTOCK asset name?
For many this is the drawback that turns them off to Counterparty, because it means they should as well sign up for a centralized exchange to use Counterparty.
If Android thin clients can’t lookup @OSTOCK’s Bitcoin public address and trustlessly receive an authentic response, lots of the world’s transactions would be at risk. It’s globally financially motived MITM attacks.
The protocol won’t let users of thin clients trustlessly conduct high value transfers as is possible with Bitcoin with SPV. If the Bitcoin blockchain outgrows the average user, then he cannot use Counterparty without signing up to a centralized exchange, largely defeating the purpose of having a distributed protocol in the first place.
The risk of a well-placed MITM attack against Counterparty thin clients, including Counterwallet.io, is just as high with Counterparty as it is with OneName.io.
A: You don’t have to sign up for a centralized service to use Counterparty. You can use a local copy of the blockchain just fine. The only difference between Counterparty and Bitcoin here is that Counterparty doesn’t support SPV. We’re working on solutions to this issue now. Protocols like VerSum offer excellent models for untrusted verification here.
Development Updates
After the v9.49.4 release, Counterparty developers started working on the next counterparty-lib version, which so far has the following implementations:
- automatically spend 1‐of‐N multisig outputs (solves issue #415)
- remove get_asset_info(assets) method from the API
- replace get_xcp_supply() method from the API by get_supply(asset)
- default to using opreturn encoding when possible (solves issue #690)
- added HTTP REST API – documentation can be found on http://docs.counterpartylib.apiary.io/#
- authentication on JSON-RPC API is off by default
- RPC password is not mandatory now
- get_unspent_txouts API method parameter and return values changed
Other changes and fixes:
- Implemented better logging of UTXO search – improved memory utilization for counterparty-server [#698]
- Keep running counterparty-cli if protocol changes file can’t be found [#697]
- Keep server running even with patchy internet access [#677]
- Fixed Dividend Fee Check [#707]
- Fixed bug with re-downloading databases in Federated Node build [#224]
That concludes our update for this week. In order to stay up to date with Counterparty, subscribe to our newsletter at the bottom of this page and receive weekly updates via email.