Open marcopeereboom opened 3 years ago
Would need dcrwallet logs too, but guessing you need to blow away your rpc.key that was generated in your wallets directory when you loaded it seperately.
That was indeed the issue. Why is it not ignoring the generated certs?
Not sure what you mean, ignore them. It's set to onetimekey, so if you have a key there already it can't do what it would like.
dcrwallet will never overwrite an existing keypair, regardless of what options you run it with.
Per the log:
2020-12-14 10:58:57.839 [INF] DCTN: Starting /Applications/decrediton.app/Contents/Resources/bin/dcrwallet with --configfile=/Users/marco/Library/Application Support/decrediton/wallets/testnet/testwallet numero dos/dcrwallet.conf,--gaplimit=20,--issueclientcert,--csppserver=cspp.decred.org:5760,--rpclistenerevents,--pipetx=4
It says --issueclientcert
; shouldn't that return whatever is in the dir or generate an ephemeral cert?
Am I missing something or one cannot use the bundled dcrwallet
/dcrctl
for advanced operations?
the onetimekey option is set on the conf file decrediton generates. issueclientcert
is for the grpc tls connection.
I believe decrediton should notice this error and notify the user, so they can take their actions for fixing it
rpc.cert & rpc.key are the server's cert and key. The key is written out so that decrediton can trust it as the CA root. The key is not written out with --onetimetlskey so that the connection cannot be MITM'd by reading the key. On the next restart, because the cert can no longer be used, because no matching key is recorded, it is fine for dcrwallet to overwrite it with a new CA root. But we can't do this if both a cert and key exist, because dcrwallet makes the assumption that you have copied these somewhere and removing them would break other configs.
I understand all that but we need the ability to use dcrwallet and dcrctl without "breaking" decrediton.
I am open to options. Maybe a support script that launches dcrwallet without allowing it to create these files?
you can run it manually with --onetimetlskey just like decrediton does. Then it won't write out a rpc.key and break future decrediton runs.
To run a dcrwallet instance backed by the same db as a Decrediton wallet, the easiest way is to go to the wallet dir ("~/.config/decrediton/wallets/testnet/blah") and edit the corresponding dcrwallet.conf
by
noinitialload=1
nolegacyrpc=1
username=
and password=
You can then run dcrwallet -C ./dcrwallet.conf
and point dcrctl to the local rpc.cert.
I guess we could modify Decrediton to specify --noinitialload
and --nolegacyrpc
on the CLI args when launching the underlying dcrwallet (vs relying on that being present in the dcrwallet.conf).
Another alternative would be having some advanced wallet settings where users can enable the json-rpc endpoint for their wallets.
instead of editing, why not write out a second config at a non-default path, which can be chosen using -C if you want to manually run the wallet?
That would work as well
Would it be ok to listen on localhost so that dcrctl can run when decrediton is on?
That would be the least problematic imo.
Now that dcrwallet has moved to client cert auth, Decrediton no longer sets an rpc username and password, so that needs to be specified somehow.
In order to obtain a public key address from a decrediton wallet I did the following:
dcrwallet
by handdcrctl validateaddress xxx
dcrwallet
Now on restart decrediton hangs with
Starting wallet...
.The command I used to start
dcrwallet
was:The
dcrctl
command was ran as follows:Dcrwallet log:
Note the
^C
to stop the wallet in the logDecrediton log: