- Added commands for using budgets "mnbudget" and "mnfinalbudget"
- Supports 100% decentralized budget control and view-only site with json meta data object
- Removed of reference node and replaced with decentralized quorums that pick the masternodes who get paid each block.
- Made a budgeting system, where masternodes can vote on individual budgets and the data is stored perminently on each clients computer
More info regarding KeePass: http://keepass.info/
KeePass integration will use KeePassHttp (https://github.com/pfn/keepasshttp/) to facilitate communications between the client and KeePass. KeePassHttp is a plugin for KeePass 2.x and provides a secure means of exposing KeePass entries via HTTP for clients to consume.
The implementation is dependent on the following:
- crypter.h for AES encryption helper functions.
- rpcprotocol.h for handling RPC communications. Could only be used partially however due some static values in the code.
- OpenSSL for base64 encoding. regular util.h libraries were not used for base64 encoding/decoding since they do not use secure allocation.
- JSON Spirit for reading / writing RPC communications
The following changes were made:
- Added CLI options in help
- Added RPC commands: keepass <genkey|init|setpassphrase>
- Added keepass.h and keepass.cpp which hold the integration routines
- Modified rpcwallet.cpp to support RPC commands
The following new options are available for darkcoind and darkcoin-qt:
-keepass Use KeePass 2 integration using KeePassHttp plugin (default: 0)
-keepassport=<port> Connect to KeePassHttp on port <port> (default: 19455)
-keepasskey=<key> KeePassHttp key for AES encrypted communication with KeePass
-keepassid=<name> KeePassHttp id for the established association
-keepassname=<name> Name to construct url for KeePass entry that stores the wallet passphrase
The following rpc commands are available:
- keepass genkey: generates a base64 encoded 256 bit AES key that can be used for the communication with KeePassHttp. Only necessary for manual configuration. Use init for automatic configuration.
- keepass init: sets up the association between darkcoind and keepass by generating an AES key and sending an association message to KeePassHttp. This will trigger KeePass to ask for an Id for the association. Returns the association and the base64 encoded string for the AES key.
- keepass setpassphrase <passphrase>: updates the passphrase in KeePassHttp to a new value. This should match the passphrase you intend to use for the wallet. Please note that the standard RPC commands walletpassphrasechange and the wallet encrption from the QT GUI already send the updates to KeePassHttp, so this is only necessary for manual manipulation of the password.
Sample initialization flow from darkcoin-qt console (this needs to be done only once to set up the association):
- Have KeePass running with an open database
- Start darkcoin-qt
- Open console
- type: "keepass init" in darkcoin-qt console
- (keepass pops up and asks for an association id, fill that in). Example: mydrkwallet
- response: Association successful. Id: mydrkwalletdarkcoin - Key: AgQkcs6cI7v9tlSYKjG/+s8wJrGALHl3jLosJpPLzUE=
- Edit darkcoin.conf and fill in these values
keepass=1
keepasskey=AgQkcs6cI7v9tlSYKjG/+s8wJrGALHl3jLosJpPLzUE=
keepassid=mydrkwallet
keepassname=testwallet
- Restart darkcoin-qt
At this point, the association is made. The next action depends on your particular situation:
- current wallet is not yet encrypted. Encrypting the wallet will trigger the integration and stores the password in KeePass (Under the 'KeePassHttp Passwords' group, named after keepassname.
- current wallet is already encrypted: use "keepass setpassphrase <passphrase>" to store the passphrase in KeePass.
At this point, the passphrase is stored in KeePassHttp. When Unlocking the wallet, one can use keepass as the passphrase to trigger retrieval of the password. This works from the RPC commands as well as the GUI.
3c30f27 travis: disable rpc tests for windows until they're not so flaky (Cory Fields)
daf03e7 RPC tests: create initial chain with specific timestamps (Gavin Andresen)
a8b2ce5 regression test only setmocktime RPC call (Gavin Andresen)
Start the RPC server before doing all the (expensive) startup
initialisations like loading the block index. Until the node is ready,
return all calls immediately with a new error signalling "in warmup"
with an appropriate status message (similar to the init message).
This is useful for RPC clients to know that the server is there (e. g.,
they don't have to start it) but not yet available. It is used in
Namecoin and Huntercoin already for some time, and there exists a UI
hooked onto the RPC interface that actively uses this to its advantage.
- ensures a consistent usage in header files
- also add a blank line after the copyright header where missing
- also remove orphan new-lines at the end of some files
Port over https://github.com/chronokings/huntercoin/pull/19 from
Huntercoin: This implements a new RPC command "getchaintips" that can be
used to find all currently active chain heads. This is similar to the
-printblocktree startup option, but it can be used without restarting
just via the RPC interface on a running daemon.
Changes:
* Add Add/Have WatchOnly methods to CKeyStore, and implementations
in CBasicKeyStore.
* Add similar methods to CWallet, and support entries for it in
CWalletDB.
* Make IsMine in script/wallet return a new enum 'isminetype',
rather than a boolean. This allows distinguishing between
spendable and unspendable coins.
* Add a field fSpendable to COutput (GetAvailableCoins' return type).
* Mark watchonly coins in listunspent as 'watchonly': true.
* Add 'watchonly' to validateaddress, suppressing script/pubkey/...
in this case.
Based on a patch by Eric Lombrozo.
Conflicts:
src/qt/walletmodel.cpp
src/rpcserver.cpp
src/wallet.cpp
New RPC methods: return an estimate of the fee (or priority) a
transaction needs to be likely to confirm in a given number of
blocks.
Mike Hearn created the first version of this method for estimating fees.
It works as follows:
For transactions that took 1 to N (I picked N=25) blocks to confirm,
keep N buckets with at most 100 entries in each recording the
fees-per-kilobyte paid by those transactions.
(separate buckets are kept for transactions that confirmed because
they are high-priority)
The buckets are filled as blocks are found, and are saved/restored
in a new fee_estiamtes.dat file in the data directory.
A few variations on Mike's initial scheme:
To estimate the fee needed for a transaction to confirm in X buckets,
all of the samples in all of the buckets are used and a median of
all of the data is used to make the estimate. For example, imagine
25 buckets each containing the full 100 entries. Those 2,500 samples
are sorted, and the estimate of the fee needed to confirm in the very
next block is the 50'th-highest-fee-entry in that sorted list; the
estimate of the fee needed to confirm in the next two blocks is the
150'th-highest-fee-entry, etc.
That algorithm has the nice property that estimates of how much fee
you need to pay to get confirmed in block N will always be greater
than or equal to the estimate for block N+1. It would clearly be wrong
to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay
12 uBTC and it will take LONGER".
A single block will not contribute more than 10 entries to any one
bucket, so a single miner and a large block cannot overwhelm
the estimates.
Adds two new info query commands that take over information from
hodge-podge `getinfo`.
Also some new information is added:
- `getblockchaininfo`
- `chain`: (string) current chain (main, testnet3, regtest)
- `verificationprogress: (numeric) estimated verification progress
- `chainwork`
- `getnetworkinfo`
- `localaddresses`: (array) local addresses, from mapLocalHost (fixes#1734)
contrib/devtools/fix-copyright-headers.py script to be able to perform this maintenance task with ease during the rest of the year, every year. Modifications to contrib/devtools/README.md to document what fix-copyright-headers.py does.
Currently it is only possible to use `walletpassphrase` to unlock the
wallet when bitcoin is started in server mode.
Almost everything that manipulates the wallet in the RPC console
needs the wallet to be unlocked and is thus unusable without -server.
This is pretty unintuitive to me, and I'm sure it's even more confusing
to users.
Solve this with a very minimal change: by making the GUI start a
dummy RPC thread just to handle timeouts.
Split bitcoinrpc up into
- rpcserver: bitcoind RPC server
- rpcclient: bitcoin-cli RPC client
- rpcprotocol: shared common HTTP/JSON-RPC protocol code
One step towards making bitcoin-cli independent from the rest
of the code, and thus a smaller executable that doesn't have to
be linked against leveldb.
This commit only does code movement, there are no functional changes.
