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)
http://counterparty.io/docs/counterparty_lib/
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)).
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).
Use pip to install counterparty-cli (which will install counterparty-lib as its dependency)
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).
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
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. https://www.dropbox.com/s/7mx7uphhf12fmga/counterparty-lib-cheatsheet_9.51.3.pdf
Edit:
I put all config files here (URL below) so that it’s easier to copy them:
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:
Can I change log level of the counterparty-lib? I found there are logger code in source code.
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...?
https://github.com/CounterpartyXCP/counterparty-lib/blob/6205676804001c7231eccda9d554f3f46197deac/counterpartylib/lib/database.py
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.
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)
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.
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).