The prefix byte (netID) which is used to encode address is the same for
both the public test and regression test networks. Previously the code
was working under the assumption there was a 1-to-1 mapping of prefix byte
to bitcoin network, however as noted above that assumption was not
correct.
This commit modifies things a bit to choose the prefix byte at address
creation time instead of at encode time and internally stores the prefix
byte instead of the network. It also adds a new function, IsForNet, to the
Address interface which allows callers to test if an address is valid for
the passed network type. The end result of this change is that callers
will only need to change their checks from testing if addr.Net() is the
active bitcoin network to instead using addr.IsForNet(activeNet).
Closes#2.
Address is a generic interface for any type of "address" a
transaction can be sent to, including but not limited to
pay-to-pubkey, pay-to-pubkey-hash, and pay-to-script-hash.
This change implements Address and concrete types for P2PKH and P2SH
addresses with 100% test coverage. Pay-to-pubkey support will be
added in the future.
This API is intended to replace the old EncodeAddress/DecodeAddress
functions which are now deprecated.
This commit adds a new AppDataDir function that can be used to get an
operating system and application specific directory to be used for storing
application data.
For example:
dir := AppDataDir("myapp", false)
Would result in:
POSIX (Linux/BSD): ~/.myapp
Mac OS: $HOME/Library/Application Support/Myapp
Windows: %LOCALAPPDATA%\Myapp
Plan 9: $home/myapp
This is work toward conformal/btcd#30.
This commit unfortunately changes the public API of Block which I
ordinarily don't like to do, but in this case, I felt it was necessary.
The blocks used throughout the database and elsewhere should be indepedent
of the protocol version which is used to encode the block to wire format.
Each block has its own Version field which should be the deciding factor
for the serialization and deserialization of blocks. In practice, they
are currently the same encoding, but that may not always be the case, and
it's important the blocks are stable depending on their own version
regardless of the protocol version.
This makes use of the new Serialize and Deserialize functions on MsgBlock
which are intended for long-term storage as opposed to wire encoding.
