The you address is the one we already set up fo the user, so either waht
we connected to (this will work with tor, etc), or the ip the user
connect to us from otherwise. We must however check to see if it is the address
of the proxy and strip it.
The me addesss, we use the same address selection for local addresses as
always
This should mean that we pass our tor address out in the version message
and thus the peers should add us to their addressmanager.
This implements only the bare bones of external ip address selection
using very similar algorithms and selection methods to bitcoind. Every
address we bind to, and if we bind to the wildcard, every listening
address is recorded, and one for the appropriate address type of the
peer is selected.
Support for fetching addresses via upnp, external services, or via the
command line are not yet implemented.
Closes#35
Perform the requisite processing on .onion addresses to turn them into the tor
reserved ipv6 region (the same as bitcoind and onioncat). Furthermore,
when printing an ip address, reverse the conversion so we print it
nicely. base32 as standard is uppercase, but tor and bitcoind seem to
use lowercase so we first must for we force .onion addrs to uppercase
(and to lowercase on the reverse).
As a side effect we now should handle dns names on the command line (via tor if
required) and add them to the addressmanger as necessary.
The code to send an address messages in batches was previously clearing
all addresses from the existing message after queueing it to be sent.
Since the message is a pointer, this means it was removing the addresses
from the same message which might not have already been sent yet (from
another goroutine) which led to a race.
This commit modifies the code to create a new address message for each
batch as intended.
Fixes#58.
Updated handleGetRawTransaction to populate all the fields required to
match bitcoind. It still doesn't handle MULTISIG addresses correctly.
Changed handleGetBlock to implement new optional verbose (default true)
flag and also added a verboseTx flag to return TxRawDefault instead of
Txid. When verbose=false, GetBlock returns hex-encoded wire bytes for
the block.
Changed TxRawResult to omitempty block info for mempool tx as well as
moved Txid to Vin.TxId from Vin.ScriptSig.Txid (both match bitcoind
output)
Added support for new bitcoind [verbose=true] and added non-standard
optional verboseTx to return TxRawResults intead Txids
The vout field (as part of the getrawtransaction JSON reply) should be
set to the input's previous outpoint's index, not the current input
index.
Found by flam and reported on IRC. Thanks!
This switches a break to a continue if a txout does not include a
pay-to-pubkey-hash script type. btcwallet only supports
pay-to-pubkey-hash at the moment, and this fixes an issue where a tx
may have an different type of output, as well as pay-to-pubkey-hash,
which may be ignored by the wallet notification code.
Found by dhill.
I previously fixed the duplicate send (before seeing GH issue #54),
but forgot that btcwallet expects a nil reply when rescan has
finished. This adds the final reply back, but replies with nil.
Fixes#54.
This updates the replies for rescan and tx notifications with
additional information that is needed for wallet to properly support
the listtransactions command.
While here, drastically improve rescan performance by not looking up
every sha in rescan's block range.
This commit modifies btcd to run cleanly as a Windows service. btcd is
intended to be a long running process that stays synchronized with the
bitcoin block chain and provides chain services to multiple users. It
follows that a service is the best option on Windows for this
functionality.
A few key points are:
- Supports graceful shutdown via the service stop/shutdown commands
- Integrates cleanly with the Windows event log
- Adds a new /s flag that can be used to install/remove/start/stop the
service
One outstanding issue is that the application data directory is currently
user specific which means, by default, if you start btcd as a user, the
same data won't be used as when it's running as a service. This needs to
be resovled. The most likely approach will be to put all data into the
common appdata directory Windows provides, but it will require some
additional work to deal with permissions properly as user processes can't
write there by default.
Closes#42.
This commit modifies the logging to also log all output to a rolling log
file in the btcd home directory under the logs folder. It uses a maximum
size of 10MB per log file and a max rotation size of 3. This means the
log files will not exceed 30 megabytes.
The code was previously only changing the logging level if it wasn't the
default which is accurate for setting the log level once at startup time,
but it needs to set it unconditionally to allow dynamic updates.
