I was able to get the pubkey for my address using validateaddress, however I’m not sure what the next steps are to add “023dee07a5e6cc9c74f9d72d006dcbce00ac1ecf72347dc816ff570bc0f97ebefe” to my counterpartyd.
I feel like there is a simple connection here I’m missing, any help would be appreciated.
Thanks for the quick reply Something. I managed to progress a bit further, I wasn’t familiar with the cli and apparently that’s what I needed to be using. Indeed the cli didn’t work due to missing dependencies.
I’m getting a new error that I’m not to sure about:
Also, it seemed like I had to specify my configuration file using ‘–data-dir ~/.config/counterpartyd’ and I thought that seemed odd. If I don’t do that I get all sorts of errors ranging from ‘AttributeError: ‘module’ object has no attribute ‘user_config_dir’’ to ‘backend RPC password not set.’ Does it indicate that my configuration file isn’t in the default location?
I’d try “–source ADDRESS” without quoting the address, just put it there as-is, but I’m not sure since I haven’t tried that myself.
> Also, it seemed like I had to specify my configuration file using ‘–data-dir ~/.config/counterpartyd’ and I thought that seemed odd.
Haha, yeah that’s weird and annoying. I still haven’t had time to figure that out myself, so:
a) I use the extremely long CLI (I pass all variables allthough that shouldn’t be the case)
b) it seems unavoidable, at least on Fed Node, since there’s no shell for the XCP user, I would think
and
c) You could (I guess) install counterpartyd for the user you’re running this CLI stuff as, and then maybe you could just run it without passing all the variables to every line (you’d have to create your own config files, by copying them from the XCP user). I think this could be a good approach for Fed Node users.
Or write a simple shell wrapper (Bash, Python, whatever) to get these vars and pass them in the full form to the CLI (I’ve started doing this for commands that I often use, like tailing the logs and so on).
Edit: to answer the question, I think that doesn’t indicate your config filel’s in the wrong location, but I can’t tell for sure because I don’t actually know where it is. The default loco is .config/counterpartyd[-testnet]/counterpartyd.[testnet.]conf, but if you’re running a Fed Node then you don’t have it installed, so that’s why.
See how to impersonate the XCP user here (in case you run a Fed Node):
I tried the command without quoting the address, looks like it created the same unsigned raw transaction as it did previously, but I still get the name “NameError: name ‘source’ is not defined” error that I got previously.
Out of curiosity I tried sending the raw transaction that is being created from the command by hand through bitcoind:
@Calum The missing dependencies for the cli is a known issue, there was an issue opened for it at github by rippler . I am not sure if this was already fixed though
@something I cloned the latest counterpartyd_build and then ran ./setup.py update. After doing that I noticed your comment was to actually clone the latest bitcoind_build, I just wanted to double check which one needed updating.
Also, I’m fairly new to Linux and was wondering if when you say “I just nuke my installs” it’s as simple as blowing away my counterpartyd_build directory?
Yes, because counterpartyd_build isn’t supposed to contain user-specific persistent data, I just delete it and re-run setup.py.
That’s not much slower than “setup.py update”. I used the word clone because after you delete it you need to run “git clone source target” to redownload the source from Github.
On Fed Node I don’t do that (because it builds bitcoin core, Nginx and other stuff from source) - there I run setup_federated_node.py => (U)pdate from Git. It’s possible to “manually” run “git clone” to check out specific updates of various components (rather than use one global “branch” value), but I’ve never tried that and because Fed Node is more difficult to troubleshoot I use the built-in update procedure.