What options should I set for launching counterparty-lib?

I got an error when I started counterparty-lib. I guess that I need to set up some options like bitcoind RPC userID and Password. What options should I set for launching counterparty-lib?

The error is this below…

xcp@ubuntu:~$ python3
>>> from counterpartylib import server
>>> db = server.initialise()
[ERROR] Unhandled Exception
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.4/dist-packages/counterpartylib/server.py", line 195, in initialise
    raise ConfigurationError('backend RPC password not set. (Use configuration file or --backend-password=PASSWORD)')
counterpartylib.server.ConfigurationError: backend RPC password not set. (Use configuration file or --backend-password=PASSWORD)

I think the official document does not mention about that…

$ python3
>>> from counterpartylib import server
>>> db = server.initialise(<options>)
>>> server.start_all(db)


As the message says, you should set things like backend-password=PASSWORD in your startup script.

But an even better way is to install counterparty server (sudo pip3 install counterparty-cli, which installs both the server and client (CLI)).

  1. Install patched Bitcoin Core 0.10.2 as per http://counterparty.io/docs/bitcoin_core/
    Then start it up and let it sync (may take 1-2 days and require up to 50GB of space; use testnet if you want to wait less and don’t need mainnet).
  2. Use pip to install counterparty-cli (which will install counterparty-lib as its dependency)
  3. Edit config files server.conf (for Counterparty server) and client.conf (for the client/CLI).
    See http://counterparty.io/docs/counterparty-cli/ for more details.
    If your patched Bitcoin Core runs on testnet, don’t forget to start it with --testnet or have testnet=1 in your config files (both client and server).

You can see How do I get started developing on Counterparty? for a list of public Counterparty servers.

Thank you so much. I installed Counterparty CLI and I started the server.

The log file shows just “[INFO] Connecting to database”. Does it take for a while for the initialization?

2015-08-03-T16:39:00+0900 [INFO] Running v9.51.3 of counterparty-lib.
2015-08-03-T16:39:00+0900 [INFO] Acquiring lock.
2015-08-03-T16:39:00+0900 [INFO] Connecting to database.

Counterparty seems to be running.

xcp@ubuntu:~/.cache/counterparty/log$ ps -ef | grep counter
root     31154 31137  0 16:38 pts/12   00:00:00 sudo counterparty-server start
root     31155 31154  1 16:38 pts/12   00:00:16 /usr/bin/python3 /usr/local/bin/counterparty-server start

Can I see the initialization progress by seeing logs?

counterparty-client getinfo returns RPCError. Do you think that it will work normally after counterparty and bitcoin are synced?

xcp@ubuntu:~$ sudo counterparty-client getinfo
[INFO] Running v1.1.1 of counterparty-client.
Unhandled Exception
Traceback (most recent call last):
  File "/usr/local/bin/counterparty-client", line 9, in <module>
    load_entry_point('counterparty-cli==1.1.1', 'console_scripts', 'counterparty-client')()
  File "/usr/local/lib/python3.4/dist-packages/counterpartycli/__init__.py", line 12, in client_main
  File "/usr/local/lib/python3.4/dist-packages/counterpartycli/client.py", line 257, in main
    view = console.get_view(args.action, args)
  File "/usr/local/lib/python3.4/dist-packages/counterpartycli/console.py", line 16, in get_view
    return util.api('get_running_info')
  File "/usr/local/lib/python3.4/dist-packages/counterpartycli/util.py", line 92, in api
    return rpc(config.COUNTERPARTY_RPC, method, params=params, ssl_verify=config.COUNTERPARTY_RPC_SSL_VERIFY)
  File "/usr/local/lib/python3.4/dist-packages/counterpartycli/util.py", line 80, in rpc
    raise RPCError('Cannot communicate with {}.'.format(url))
counterpartycli.util.RPCError: Cannot communicate with http://rpc:rpcpass@localhost:4000/rpc/.

You’re welcome. The log is telling you Counterparty server can’t authenticate against Bitcoin Core. You could use counterparty-server --backend-user=BTC-core-rpc-user --backend-password=BTC-core-rpc-password start to see whether you got the RPC credentials right, then populate your server.conf with them, start counterparty-server and then use the same approach (with different parameters) for counterparty-client.

Or you can reference page 1 of this document to see which parameters from server.conf map to which parameters of bitcoin.conf. This example is for testnet and I use separate config files for testnet (as I mentioned above, you could use one set of files for mainnet and testnet, and then run testnet by running server/client with --testnet). There are some CLI examples in this file as well.


  1. I put all config files here (URL below) so that it’s easier to copy them:
  2. I suggest to install counterparty-cli and counterparty-lib from source - how-to is available here:

Thank you for the information. Unfortunately still I cannot connect to counterparty server. I’ve confirmed my bitcoind’s config and counterparty’s config were OK. I checked ‘netstat’ command and TCP port 4000 was not opened.

My guess is that ‘PRAGMA foreign_key_check’ or ‘PRAGMA integrity_check’ is processing now. That process takes for a while. I have a same experience before. At that time I commented out the lines to save time.

I’d like to ask 2 questions:

  1. Can I change log level of the counterparty-lib? I found there are logger code in source code.
  2. Can I skip ‘PRAGMA check’? It is time consuming for development phase.

My status is below…

$sudo counterparty-client getinfo
counterpartycli.util.RPCError: Cannot communicate with http://counterparty-rpc:counterparty-rpcpass@localhost:4000/rpc/.

xcp@ubuntu:~$ sudo counterparty-server start
[sudo] password for xcp: 
[INFO] Running v1.1.1 of counterparty-server.
[INFO] Running v9.51.3 of counterparty-lib.
[INFO] Acquiring lock.
[INFO] Connecting to database.

PRAGMA check is processing now...?

Hi Zono,

  • You can change the parameters as per Sqlite docs (stop counterparty-server, use Sqlite CLI to change config parameters)
  • PRAGMA_CHECK maybe can be replaced with PRAGMA_QUICK_CHECK (https://www.sqlite.org/pragma.html#pragma_quick_check), but it’s not something that we test. I think this check runs only rarely, for example when the DB is first deployed (if you use counterparty-server bootstrap, for example). I don’t find it time consuming (yes, sometimes it runs for 10+ mins, but if you normally shutdown counterparty-server (using CTRL+C), it takes only 1-2 mins at startup, in my experience). I use the top command to watch if counterparty-server is stuck or active - if it’s “working”, then I just wait. The longest check I’ve seen was around 30 mins, when the entire DB had to be checked on a slow PC.

Did you use bootstrap/download the Counterparty DB, or did you let it catch up naturally?

Normally for test/dev environments it’s better to use testnet because DB is smaller and the wait is shorter, then do final testing on mainnet. Or point your counterparty-client to public Counterparty server (e.g. CoinDaddy’s servers) while the DB is catching up / checking consistency (create a different config file and use counterparty-client --config-file coindaddy.server.conf getinfo - a detailed example of using CoinDaddy’s Counterparty server can be found here)

Hi something

Even though I waited for over 6 hours, PRAGMA check didn’t finish. Something may be wrong with my server.
I didn’t find a way to change to PRAGMA_QUICK_CHECK so I changed database.py directly and deployed it.


def get_connection(read_only=True, foreign_keys=True, integrity_check=True):
def get_connection(read_only=True, foreign_keys=False, integrity_check=False):

getinfo returns normally! Thanks!

$ sudo counterparty-client getinfo
[INFO] Running v1.1.1 of counterparty-client.
    "bitcoin_block_count": 368331,
    "db_caught_up": true,
    "last_block": {
        "block_hash": "0000000000000000007efb08b3181f80bb579de4e4e5596bb0d53faacaceee11",
        "block_index": 368331,
        "block_time": 1438658364,
        "difficulty": 52278304845.59168,
        "ledger_hash": "566e38ed02f5801f81f21a798bf6bf9650de741551be0fcd651912b6109b2b53",
        "previous_block_hash": "00000000000000000c226102ed08ed5a41e5465c231f60d176047b47820f0de9",
        "txlist_hash": "567061a060d62ee3f3379c5d98d14077f2fb31f97c5a2dd153afd07ebfecdffe"
    "last_message_index": 1027558,
    "running_testcoin": false,
    "running_testnet": false,
    "version_major": 9,
    "version_minor": 51,
    "version_revision": 3

Regarding testnet, Yes I agreee with you I use testnet for development but I need to setup counterparty for mainnet for now. I’m working on setup Tokenly-CMS(https://github.com/tokenly/tokenly-cms) on my own server. I’m not sure about CoinDaddy’s servers. If it can be useful for my goal I will use it. I’ll check it out.


Okay, good to hear it works now. If you plan to use this DB for production, you should definitively have a properly checked DB.

While this current setup is working, you could prepare a 2nd, good copy of Counterparty Database on another server and copy it over.

I suggest to change integrity_check to True before you start selling, or try to download the DB again (stop counterparty server, make a backup of the current DB).

I didn’t download the DB file directly. I guess the install script downloaded it automatically. I will download it and try it again.

In my case the file wasn’t downloaded, but if you used the Federated Node install script, it offers the option to run bootstrap first.