Besides being shorter, using "BTC" rather than "Bitcoin" in the
AmountUnit constants is deemed to be better for these units as BTC is
already a recognized monetary unit.
AmountBaseBitcoin has likewise been renamed to AmountSatoshi as this
is consistant with how it is returned as a string. The "standard"
part of the comment in the const block has been removed, as Satoshi is
technically not a standard term for this unit.
ok @davecgh
Originally the various NewAddressX family on functions were limited to
only btcwire.MainNet and btcwire.TestNet3. They were changed a while back
to also support the regression test network however the comments were not
updated. This commit simply removes the comments which limited the
available choices since all btcwire.BitconNet types are now supported.
This commit removes the previously deprecated TxShas function from
btcutil.Block. The preferred method to access transaction hashes is via
the Sha function on each btcutil.Tx contained within the block.
For example, the following illustrates how convert the old TxShas approach
to the new method:
OLD:
for i, sha := range block.TxShas() {
// use sha
}
NEW:
for i, tx := range block.Transactions() {
// use tx.Sha()
}
This commit also updates the tests for the removed function.
This commit contains a basic definition for CoinSelector along with some
utility classes and some basic algos to make creating transactions from
a set of available unspent outpoints easier.
Thanks to @dajohi, @davec, @jrick for all the feedback and suggestions
regarding interfaces, organization, optimization, comments and
documentation.
This commit modifies DecodeAddress to accept and decode pay-to-pubkey
addresses (raw serialized public keys). Since the resulting Address
needs to have a network associated with it, and a raw serialized public
key does not encode the network with it, a new parameter has been added
which requires the caller to specify a default network to use when
decoding addresses.
In the case the address has a network encoded with it such as for
pay-to-pubkey-hash and pay-to-script-hash addresses, the network will be
decoded from the address and the resulting Address instance will have that
network associated with it. When the address does NOT have a network
encoded with it, such as a pay-to-pubkey address, the provided default
network will be associated with the returned Address instance.
Also, the tests have been updated to test the new functionality.
ok @owainga and @jrick.
Since all of the deprecated address conversion functions have been
removed, consolidate the remaining private key funcs and tests into
address.go and address_test.go, repectively.
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.
This commit changes three things with cert generation.
- The extended key usage field has been removed since specifying the
extended key usage field prevents the cert from working with firefox
even when it specifies it can be used as a server
- Creates a random serial number since browsers like firefox and chrome
won't accept two certificates with the same issuer and serial number
- Adds the digital signature key usage capability since some validators
like node.js expect that instead of key encipherment
btcd, btcwallet, and an upcomming standalone tool to generate the TLS
certificates all need a way to generate TLS certificate pairs. This
function, adapted from the cert gen code in btcd, abstracts this logic
so all programs can reuse the code.
Unlike the older btcd certificate generation code, this new function
allows specifying additional hostnames and IPs to add to the list of
addresses for which the cert is valid.
This commit adds a new concrete Address interface implementation for
pay-to-pubkey addresses. It supports uncompressed, compressed, and hybrid
pubkeys. It also provides a convenience method for converting to a
pay-to-pubkey-hash address.
This commit adds a new flag to the tests which controls whether or not an
address can be decoded. This is to support the upcoming public key
address type and possible future addresses which aren't directly
decodable.
This allows the addresses to be treated as fmt.Stringer for easy printing.
There is no difference between String and EncodeAddress (in fact String
just calls EncodeAddress).
Rather than repeating the same code in both the pay-to-pubkey-hash and
pay-to-script-hash encoding, refactor it into separate functions. This
makes it easier to support new networks, for example, since it can be
changed in one place.
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 adds both positive and negative tests for the new Tx and
Transactions Block API functions.
This is part of the ongoing transaction hash optimization effort noted in
conformal/btcd#25.
This commit adds two new functions to the Block API for working with the
recently added Tx type from the Block.
These new functions are named Tx and Transactions. Tx returns a
transactions for the specified index as a Tx and also memoizes it so
subsequent calls are more efficient. Transactions returns a slice of all
transactions in the Block wrapped in a Tx.
This is part of the ongoing transaction hash optimization effort
noted in conformal/btcd#25.
This commit adds both positive and negative tests for the new Tx type to
bring its coverage to 100%.
This is part of the ongoing transaction hash optimization effort noted
in conformal/btcd#25.
Currently, transaction hash caching is provided via Block directly, but a
transaction is not always part of a block and there are several cases
where only the transaction needs to be dealt with without wanting to pass
the entire block and transaction index around to be able to get at the
cached hash.
So, this commit adds a new type named Tx which is a wrapper that provides
easier and more efficient manipulation of raw wire protocol transactions.
It memoizes the hash for the transaction on its first access so subsequent
accesses don't have to repeat the relatively expensive hashing operations.
The idea is the callers can pass around pointers to these Tx types instead
of raw btcwire.MsgTx pointers.
For now, the Block API has not been changed, but the plan is to change it
to provide access to these wrapped transactions rather than having it do
the transaction hash caching directly.
This is only the first part of a series of changes working towards
optimizations noted in conformal/btcd#25.
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.
