Allows the user to pass null as the second or third parameter
to signrawtransaction, in case you need to (for example) fetch
private keys from the wallet but want to specify the hash type.
- If the height is in the first half, start at the genesis block and go up, rather than at the top
- Cache the last lookup and use it as a reference point if it's close to the next request, to make linear lookups always fast
* Fix wrong thread name for wallet *relocking* thread
- Was named the unlocking thread
* Use consistent naming
Signed-off-by: Giel van Schijndel <me@mortis.eu>
NOTE: These thread names are visible in gdb when using 'info threads'.
Additionally both 'top' and 'ps' show these names *unless* told to
display the command-line instead of task name.
Signed-off-by: Giel van Schijndel <me@mortis.eu>
Implement listunspent / getrawtransaction / createrawtransaction /
signrawtransaction, to support creation and
signing-on-multiple-device multisignature transactions.
This PULL reworks new (post-0.6.*) features of the
gettransaction/getblock RPC calls as follows:
It removes the 'decompositions' object argument from getblock,
replacing it just a list of transaction hashes; equivalent
(I believe) of passing the {"tx":"hash"} decomposition.
It replaces the 'decompositions' object argument of
gettransaction with a boolean flag; if true, returns
the same stuff that the {"script":"obj"} decomposition
would return (txins/txouts as hex, disassembled, and bitcoin
addresses).
It adds a "rawtx" field to the output of gettransaction,
that is the entire transaction serialized and hex-encoded.
It removes the "size" field from gettransaction, since the size
is trivial to compute from the "rawtx" field (either take the
length after hex-decoding, or just compute it as hex-length/2).
If the top-level object is an array, it is assumed to be an array of
JSON-RPC requests. An array is returned, containing one response (error or
not) per request, in the order submitted.
In a slight change in semantics, batched requests -always- return
an HTTP 200 OK status, even ones full of invalid or incorrect requests.
Use Boost's signal2 slot tracking mechanism to cancel any (still open)
listening sockets when receiving a shutdown signal.
Signed-off-by: Giel van Schijndel <me@mortis.eu>
Using this modification it should be relatively easy to, at a later
time, listen on multiple addresses (even Unix domain sockets should be
possible).
Signed-off-by: Giel van Schijndel <me@mortis.eu>
The RPC server now listens for, and handles, incoming connections on
both IPv4 as well as IPv6.
If available (and usable) it uses a dual IPv4/IPv6 socket on systems
that support it (e.g. Linux and BSDs) and falls back to separate
IPv4/IPv6 sockets on systems that don't (e.g. Windows).
Signed-off-by: Giel van Schijndel <me@mortis.eu>
This allows more flexibility in the RPC code, e.g. making it easier to
handle multiple simultaneous connections later on.
Currently asynchronous I/O is only used to listen for and accept
incoming connections. Asynchronous reading/writing is more involved.
Signed-off-by: Giel van Schijndel <me@mortis.eu>
This introduces internal types:
* CKeyID: reference (hash160) of a key
* CScriptID: reference (hash160) of a script
* CTxDestination: a boost::variant of the former two
CBitcoinAddress is retrofitted to be a Base58 encoding of a
CTxDestination. This allows all internal code to only use the
internal types, and only have RPC and GUI depend on the base58 code.
Furthermore, the header dependencies are a lot saner now. base58.h is
at the top (right below rpc and gui) instead of at the bottom. For the
rest: wallet -> script -> keystore -> key. Only keystore still requires
a forward declaration of CScript. Solving that would require splitting
script into two layers.
