February 13, 2015

This week we decided to try out a different newsletter format and combine our community and development updates into a comprehensive weekly blog post. Instead of publishing two posts per week, we’ll share all relevant Counterparty news in a single update – every Friday.

From the Team

Once again, our team has been working hard on developing new tutorials, updating existing documentation and resolving emerging issues with new product versions. We have several new Counterwallet tutorials listed on our site, with more to come:

As announced in the last community update, we’re in the process of migrating our forum to Discourse. Current forum will remain available during the migration and all posts and comments submitted will be migrated to the new platform.

Finally, we’d like to address what seems to be a common question among the community lately: What are our main goals for the following months? After reviewing the current situation in the Counterparty community and the Bitcoin ecosystem, on the last board meeting, the Counterparty Foundation Directors decided on the following goals to be fulfilled in the next six months:

Finish the development of Smart Contracts, prepare for the official launch on mainnet, and drive global awareness.

Finish the development of the desktop wallet.

Pursue mobile wallet integration.

Work with exchanges on XCP integration.

Start preparing Counterparty events and educational courses.

As we stated previously, we are marching confidently forward with big plans and a clear vision: to make Counterparty the best, most secure and most advanced platform for smart contracts on the Bitcoin blockchain, and we continue to work hard every day on fulfilling that vision.

Development Updates

With the recent changes in our codebase and the complete reorganization of our components, we’ve made a significant step forward in making Counterparty the standard framework for developing Bitcoin 2.0 applications. Today we have a clear distinction between block explorer and wallet dependencies, as well as a clear distinction between applications and the library. Developers can now easily build an alternative CLI or GUI just by using counterparty-lib as an ordinary Python library. In addition, the development of light wallets will now be much easier, enabling the use of a distant block explorer and a local light wallet.

Moving forward, our focus will remain on thorough testing and quality assurance, making sure all emerging issues are adequately and timely addressed, and that the documentation is updated with new information and useful examples.

Once again, to monitor our daily progress watch our GitHub repositories:

counterparty-lib – Reference implementation of the Counterparty protocol

counterparty-cli – Command-line interface for counterparty-lib

counterparty-gui – Counterparty GUI (OS X and Windows)

Counterwallet – Web wallet

counterblock – Provides extended API services to Counterwallet, as well as Counterparty 3rd-party applications

federatednode_build – Federated Node Build System

When it comes to changes implemented this week, here is a list of the most relevant ones:



federatednode_build

This week we released a new v1.1.0 version of the Federated Node build system (previously called counterpartyd_build), with major updates to the build system, to coincide with the structural changes made to counterpartyd (now counterparty-lib and counterparty-cli) and counterblockd (now counterblock)

Revamped and refactored build system: Build system is for federated node only, given that counterparty and counterblock both have their own setuptools setup.py files now.

and both have their own setuptools files now. Renamed repo from counterparty_build to federatednode_build

to Removed Windows and Ubuntu 12.04/13.10 support.

Service name changes: counterpartyd service changed to counterparty , counterblockd service changed to counterblock . bitcoind service changed to bitcoin

service changed to , service changed to . service changed to Bitcoin-testnet data-dir location changed: moved from ~xcp/.bitcoin-testnet to ~xcp/.bitcoin/testnet3

to All configuration file locations changed: counterparty: From ~xcp/.config/counterpartyd/counterparty.conf to ~xcp/.config/counterparty/server.conf counterparty-testnet: From ~xcp/.config/counterpartyd-testnet/counterpartyd.conf to ~xcp/.config/counterparty/server-testnet.conf counterblock: From ~xcp/.config/counterblockd/counterblockd.conf to ~xcp/.config/counterblock/server.conf counterblock-testnet: From ~xcp/.config/counterblockd-testnet/counterblockd.conf to ~xcp/.config/counterblock/server-testnet.conf

Log and data directories changed as well (please see counterparty and counterblock release notes for more information, as well as the federated node document’s troubleshooting section for the new paths with federated nodes).

and release notes for more information, as well as the federated node document’s troubleshooting section for the new paths with federated nodes). Updated the setup guide for federated nodes for new paths, service names, and more, located at: https://counterparty.io/docs/federated_node/

When updating to this new version, please BACKUP all data, and do a complete rebuild.

BRANCH=master

wget -q -O /tmp/fednode_run.py https://raw.github.com/CounterpartyXCP/federatednode_build/${BRANCH}/run.py

sudo python3 /tmp/fednode_run.py

When prompted, choose rebuild (‘r’), and then answer the other questions as appropriate. This rebuild should not delete your existing data, but does automatically build out everything for the new configuration files and paths.



counterparty-cli

Implemented refactoring measures to make counterparty-cli usable by counterparty-gui

usable by Refactored messages commands – Introduced counterpartycli.messages module, continued preparation for counterparty-gui .

module, continued preparation for . Added getrows command Examples: counterparty-client --unconfirmed --testnet getrows --table balances --filter 'address' '=' 'muQjaj46wghHprjSjpgU7D55JxKyK5dJtZ' counterparty-client --unconfirmed --testnet getrows --table balances --filter 'address' '=' 'muQjaj46wghHprjSjpgU7D55JxKyK5dJtZ' --filter 'asset' '=' 'UTXO'

command Removed market command Currently there are three categories of commands: commands to compose transactions, commands to get data related to addresses in the wallet (wallet, balances, pending etc..), commands to get arbitrary data ( getrows ) The market command is a mix of the second and the third category which displays a lot of information of little or no use. For this reason the market command has been removed. Open orders, open bets and feeds can now be accessed with the getrows commands: open orders: counterparty-client getrows --table orders --filter status = open --filter give_asset = XCP open bets: counterparty-client getrows --table bets --filter status = open feeds: counterparty-client getrows --table broadcasts --filter status = valid --order-by=timestamp --order-dir=DESC

command Introduced the clientapi module – Unified function to call Wallet and Counterparty API methods. Should be used by applications like counterparty-gui import counterpartycli.clientapiclientapi.initialize(...)unsigned_hex = clientapi.call('create_send', {...})signed_hex = clientapi.call('sign_raw_transaction', unsigned_hex)tx_hash = clientapi.call('send_raw_transaction', signed_hex)

Specified minimum version for requests

counterparty-lib

Cleaned-up API removed get_asset_info(assets) replaced get_xcp_supply() with get_supply(asset)

Removed version number in setup.py

Removed major version for the database file name

Moved protocol_changes.json to countepartylib folder

to countepartylib folder Added support of BTCD for the backend

Added tests for database version checking

Refactored database version checking

Bitcoin Core with addrindex patch v0.10.0

Another important development update this week is the new version of Bitcoin Core with addrindex patch – v0.10.0. The release has been tagged as stable and it is recommended for everyone running the patched version to upgrade to this new release. Downloads are available here.

Support Updates

Here are some news and common issues and workarounds:

counterparty-lib (stand-alone install via pip3) 3rd party package requirement issues: in case of problems with outdated packages, use pip3 to upgrade them manually or install from develop branch as per this workaround. Users of stand-alone counterpartyd 9.49.[1-3] considering an upgrade to counterparty-lib 9.49.4 can check out this post (or, once the forums have been migrated, you can search the forums for “counterparty-lib cheat sheet”) for a single-page overview of main configuration and other files.

(stand-alone install via pip3) Federated Node Build System counterparty-client configuration file(s) is/are missing. This is a known issue (see here) and a quick workaround is to create client.conf (and/or client.testnet.conf) after Federated Node install has completed. To do that, create the file in the default location (same as server.[testnet.]conf ) and give it the same permissions and ownership (chmod, chown) as for other files in that directory On Federated Node 1.1.0, counterparty-lib and counterparty-cli are not visible in pip3 list output, but it is not necessary to install them manually. Apart from the missing client configuration file (above), everything else is installed by the Federated Node Build script. One of noteworthy changes in Federated Node v1.1.0 (release notes can be found here) is that build time has been somewhat shortened because Bitcoin Core is installed from a deterministically built binary package (see run.py). Federated Node users interested in security and other aspects of the deterministic build process used for these binaries can read more about it here: https://github.com/devrandom/gitian-builder.



That concludes our update for this week. If you have any questions regarding recent or upcoming changes you can contact us via our support channel, gitter, forum or github.

Don’t forget to follow us on social media and subscribe to our newsletter to receive weekly updates via email.