top of page

Counterparty Development Update #9: counterpartyd v9.49.3, New Features in Counterwallet, New counterblockd & More

Today is the one year anniversary of the Counterparty project! We’ll write about that in a separate post today, but first it’s time for our usual weekly development update.

counterpartyd v9.49.3

The new version of counterpartyd published this week contains a lot of code improvements and bug fixes. The biggest change is the improved logging system and allowing for providing public keys manually through the API and CLI.

Here’s a list of all API changes:

  1. PubkeyHashes may everywhere be replaced by pubkeys (or the latter may be provided either as a string or a list via the optional pubkey parameter).

  2. The API Status Poller now starts correctly.

  3. The API will no longer search the local wallet for pubkeys, so they must be passed to the API manually if being used for the first time. Otherwise, you may get a " not published in blockchain" error.

More about this release can be found in our Release Document.

counterblockd v1.0.0

Currently undergoing final testing, there were a lot of changes implemented in counterblockd this week which has been completely reorganized, with many improvements. counterblockd now allows developers to write custom plugins for it, which are loaded dynamically and allows them to extend counterblockd with new parsing functionality, write gateways to other currencies or services, and much more. For more information on this, see the Modules document. (We will have open source, real-world examples of this in use, soon.)

Due to this change, counterblockd can now be seen as a separate and full-fledged component of the Counterparty software lineup, instead of what it was largely before (a software product that provided advanced functionality that Counterwallet required, but not much else). As such, it will be receiving its own version number, independent from Counterwallet.

We will be completing our final testing of this new version of counterblockd in the upcoming days, and promoting it to master.

Migrating to New Wiki

As announced in our community update post, we have shut down the old Counterparty Wiki ( and moved all of its content to the new Wiki hosted at GitHub in order to consolidate documentation for greater ease of use. As with the old wiki, everyone (with a GitHub account) is welcomed to contribute to the development of new content or updating of existing content. Please note that some links on the sidebar, such as the Technology and Developers Guide, link to the OfficialWiki repository restricted to Counterparty team members. The rest of the content is hosted on the CommunityWiki repository and is open to public contribution.

Announcing the Removal of Ubuntu 12.04 and 13.10 Support

On February 28th, we will remove the support for old versions of Ubuntu from the code. Versions 12.04 and 13.10 have been a challenge to support from the very beginning, and since Ubuntu 14.04 is the new official LTS release we decided not to provide support for old versions anymore.

We are giving everyone enough time to prepare for the switch (2 months time) and will be making additional announcements before we remove the code on February 28th. However, please don’t wait till the last minute. If you’re using Ubuntu 12.04 or 13.10 best thing to do would be to upgrade to 14.04 immediately and avoid any issues when the support for older versions is removed.

Ruby Gem For Communicating With Counterparty API server

Chris Derose, Counterparty Foundation community director, made a Ruby gem and enabled everyone to use Counterparty in their ruby and/or ruby on rails app.

The gem is hosted on GitHub and open for everyone to use. It is designed to abstract communications with the counterpartyd api server in an ActiveRecord-esque object model.

Chris also listed some examples to help you get started, while the documentation on the objects is available via counterparty_ruby's rubydoc and the Counterparty official API guide.

Changes and Fixes Across Our Repositories

Once again, our developers have made significant progress in terms of code refactoring, unit testing and bug stomping. Let’s look at the most important changes implemented this week across all our repositories.


  1. Implemented accepting multisig addresses that are lists of public keys (instead of pubkeyhashes) for both source and destination (#570).

  2. Implemented asking for pubkey in CLI only if not in wallet and not in blockchain (by search) since users don’t know if their addresses have been used before

  3. Implemented Sanity Checking on Public Keys

  4. Abstracted away sanity check

  5. Placed check in CLI and API

  6. Implemented better abstraction in API’s Compose Function

  7. Extract pubkeys from address and convert address to pubkeyhash‐form separately.

  8. Fixed bug in cli(): address_name -> address

  9. Moved Functions Requiring Proxy to

  10. Updated API Docs about PubkeyHash->Pubkey Option and v9.49.3 changes

  11. Implemented better abstraction in CLI get_pubkey()

  12. Updated docstring documentation for testing suite

  13. Implemented using SQL SUM instead Python sum() to calculate XCP supply

  14. Implemented better cache for unconfirmed_transaction(): Removed query by batch and added preparing cache for each transaction during the mempool initialization in The cache is really effective after the mempool is initialised in blocks.follow()

  15. Put rpcthreads=1000 rpctimeout=300 in README

  16. Added a missing import statement in counterparty-cli

  17. Fixed logging for counterparty-cli

  18. Removed extraneous --force option in counterparty-cli

  19. Implemented version check before adding blocks to the database (#586)

  20. Moved version check from API Status Poller to two places in blocks.follow().

  21. Moved version check on startup to reparse().

  22. Removed old backwards‐compatibility code from check.version.

  23. Moved logging of version check and forced skipping of version check to inside version check function.

  24. Have logger handle logging of failed version check.

  25. Listed correct reason for protocol change in version check exception.


  1. Implemented manually providing pubkeys for multisig addresses

  2. In 'Create multisig address' dialog box, there is now one field for each address that composes the multisig address. For each field, when an address is entered, CW searches the pubkey in the wallet and in the blockchain. If CW can not find the pubkey, a new field appears and users have to manually provide it.

  3. In 'Send' dialog box, when the destination is a multisig address, CW searches the pubkeys in the wallet and in the blockchain. If CW can not find them, a new field appears for each missing pubkey.

  4. Fixed signature issue for multisig transaction

  5. Fixed sweeping issue (in case of timeouts, wait 1 min and retry)

  6. Added removal of the last normal address from Counterwallet

  7. Removed BTC Pay notification (#623)

  8. Replaced counterpartyd get_asset_info() with counterblockd get_assets_info()


Beyond the code reorganization itself, here’s a list of all changes:

  1. Increased JSON API request timeout to 120 seconds

  2. Implemented support for new order_match id format

  3. Implemented always trying/retrying for RPC calls

  4. Removed Callback and RPS

  5. Modularized Counterblockd functionality & plugin interface for third-party modules

  6. Optimized

  7. Fixed the difference of one satoshi between BTC balances returned by counterpartyd and counterblockd

  8. Implemented an alternative for counterpartyd api get_asset_info() method to speed up the login in counterwallet for wallet with a lot of assets

  9. Updated versions of deps (fixes issue with fetching SSL urls)

  10. Fixed the issue with passing JSON data in POST requests

  11. Added rollback command line argument and RollbackProcessor


  1. Clarified use of sudo sv start counterpartyd

  2. Updated mongo to current

  3. Fixed issues with Federated Note setup script

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

In order to stay up to date with our progress subscribe to our newsletter at the bottom of this page and receive weekly updates via email.


bottom of page