The connect option is already used by btcd to force a connection to
other full node peers. Wallet does not talk directly with these
peers, so the connect option is being renamed to something unique for
an RPC client connection.
Boolean options cannot be unset from a default true value on the
command line, so invert the allowfree option, renaming it
disallowfree, so attaching fees may always be forced by specifying
disallowfree = true in the configuration file, or --disallowfree on
the command line.
It may be desirable to never allow free transactions, even if the
calculated priority is high enough that a fee would not be required,
so this change adds a global configuration option to remove this check
and always attach a fee.
If ~/.btcwallet/btcd.cert does not exist and the CA file has not been
explicitly set using the config file or command line flags, it's
possible that the cert can be found in ~/.btcd. If connecting to a
localhost btcd and the previous statements are true, the default CA
file config option is updated for the certificate in them btcd
homedir.
If ~/.btcwallet/btcd.cert does exist and the CA file has not been set,
it is used without checking for a cert in the btcd homedir.
This change enables the --mainnet flag to connect to a mainnet btcd
instance and open and create mainnet wallets. Attempting to connect
to a testnet btcd, or opening a testnet wallet when running in mainnet
mode will result in an error printed to the logging output.
Testnet (version 3) remains the default network for now. btcwallet
will continue to receive fixes and new features, but at the moment we
believe that early adopters familar with using btcwallet on testnet
can safely use it for mainnet now as well.
Reminder: when dealing with mainnet coins, it is always a good idea to
keep backups of your wallet. btcwallet uses a deterministic wallet,
and any later addresses for an account can be recreated with just the
account's original wallet file (this does *not* include imported
addresses). Might we recommend Cyphertite for a backup solution?
This change copies the listening behavior of btcd by replacing the
--serverport option with --listen. By default, btcwallet will only
listen for localhost connections, but with this change it will be
possible to add listeners for remote connections.
This was added due to finding a bug with updateConfigWithActiveParams.
After consulting the btcd source code, the bug was fixed by replacing
the function (as it was no longer needed) when the new listening code
was introduced.
While here, mask out the password flag from being shown in the help
message.
This changes the locations that account files (wallet.bin, utxo.bin,
and tx.bin) are searched for when opening or disk syncing accounts.
Previously, files were saved in the following layout:
~/.btcwallet/
- btcwallet/
- wallet.bin
- tx.bin
- utxo.bin
- btcwallet-AccountA/
- wallet.bin
- tx.bin
- utxo.bin
This format had two issues. First, each account would require its own
directory, causing a scalability issue on unix (and perhaps other)
platforms. Second, there was no distinction between testnet and
mainnet wallets, and if mainnet support was enabled, btcwallet would
attempt to open accounts with testnet wallets.
Instead, the following file structure is now used:
~/.btcwallet/
- testnet/
- wallet.bin
- tx.bin
- utxo.bin
- AccountA-wallet.bin
- AccountA-tx.bin
- AccountA-utxo.bin
This solves both of the previously-mentioned issues by requiring only
two subdirectories (one each for the testnet and mainnet bitcoin
networks), and by separating the locations to open and save testnet
and mainnet account files.
At startup, a check for the old account file structure is performed.
If found, files are moved to the new locations, and the old account
directories are removed. Account files are moved to the testnet
directory, as only testnet support is currently enabled.
The version has been bumped to 0.1.1 to reflect this change.
Fixes#16.
This changes the default CA filename from 'cert.pem' to 'btcd.cert' to
reflect the fact that this cert is used for securely connecting to
btcd. With the introduction of autogenerated btcwallet certs (saved
to rpc.cert and rpc.key) this change was made to better differentiate
the two cert files.
To upgrade across this change, simply move the btcd cert. On unix,
use the command:
$ mv ~/.btcwallet/cert.pem ~/.btcwallet/btcd.cert
This adds an additional config option, -cafile, to specify the root
certificates checked when verifying a btcd TLC connection. btcd will
now automatically generate certs in
~/.btcd/data/{main,test}net/rpc.cert, and this file should be copied
to ~/.btcwallet/cert.pem.
The -btcdport option is also gone now, and replaced with -connect (or
-c), to specify both the hostname/ip and port of the server running
btcd.
This change copies the behavior of btcd for using seelog for logging,
including making timestamps human readable, and setting the default
logging level to info.
Fixes#8.
This copies the functionality of btcd for choosing the ports for the
HTTP client (for btcd) and server (for frontends). On testnet, the
following ports are used as default:
- btcd: 18334
- frontends: 18332
When running with the (currently disabled) --mainnet flag, btcwallet
will choose the following ports by default:
- btcd: 8334
- frontends: 8332
Both ports can be overridden no matter the chosen network using the -b
and -p flags.
Use on mainnet is not recommended until extensive testing has been
done, and should be done at your own risk. Run btcwallet with
--mainnet to operate on main Bitcoin network.
This is a big change that also many general fixes to problems found
when creating transactions. In particular the Utxo and Tx formats and
serialization functions were updated with additional information that
would be necessary for rolling back old utxo and tx data data after
btcd chain switches. This change also implements the json methods
'sendfrom' and 'sendmany' to create a new transaction based on a
frontend request.
Transactions are currently not sent to btcd since the tx relay code is
not finished yet, so a temporary error is returned back to frontends
who try to send new transactions.
