The genesis block for each network is a parameter for the network. As
such, it makes more sense to define them in this package instead of in the
wire protocol package.
ok @jrick
The examples uses a btcutil API that was recently updated from passing
btcwire.BitcoinNet to *btcnet.Params. This change updates the btcutil
call in the examples, as well as modifying the example in the README
to match that in doc.go (where errors were handled slightly
differently).
The ParamsForNet function was removed, so likewise this change removes
ErrUnknownNet error that it used to return.
As network registration is now necessary for correct handling of
alternate network encoding magics, and therefore the ErrDuplicateNet
error returned by Register is here to stay, kill the comment about the
error being removed later.
This commit refactors the code to make use of the btcnet package for
network-specific parameters instead of switching on the specific network.
For example, the percentage of the network that needs to run version 2
blocks is different between testnet and mainnet. Previously the code was
using a switch to choose these values. With this refactor, those
parameters are part of the network parameters provided when creating a new
chain instance.
Another example is checkpoints, which have been moved to btcnet so they
can be specified by the caller instead of hard coded into this package.
As a result, the checkpoints for the standard networks are now specified
in the btcnet package.
This makes it easier to add new networks such as a testnet4 should it
become needed. It also allows callers to define their own custom network
parameters without having to modify the code of the package to add new
switch cases for the custom network.
This commit adds more chain-related fields to the parameters as a part of
converting btcchain to work with btcnet parameters instead of coding the
network-specific knowledge into the package itself.
It also moves the checkpoints from btcchain since checkpoints are a
network parameter and make more sense here.
ok @jrick
This commit raises the maximum allowed size for a standard signature
script to cover a 15-of-15 multi-signature pay-to-script-hash with
compressed pubkeys.
This mirrors a recent change to remain compatible with Bitcoin Core.
ok @owinga who also helped verify and correct the script math.
Closes#128.
This change modifies the params struct to embed a *btcnet.Params,
removing the old parameter fields that are handled by the btcnet
package.
Hardcoded network checks have also been removed in favor of modifying
behavior based on the current active net's parameters.
Not all library packages, notable btcutil and btcchain, have been
updated to use btcnet yet, but with this change, each package can be
updated one at a time since the active net's btcnet.Params are
available at each callsite.
ok @davecgh
This change adds two parameters to the Params struct which are used by
btcd to alter behavior based on the active network, rather than
hardcoding checks for a particular network.
The first, ResetMinDifficulty, specifies whether the target difficulty
can change between the retarget intervals.
The second, RelayNonStdTxs, specifies whether standard transaction
checks should not be performed when accepting mempool transactions.
The zero values (false) for both of these bools are the correct
parameter values for mainnet.
While here, rename the test network version 3 to "testnet3", as both
btcd and btcwallet will include additional handling to rename this to
"testnet" for directory names, and a switch to "testnet3" is planned
in the future.
PushedData returns an array of byte slices containing any pushed data
found in the passed script. This includes OP_0, but not OP_1 - OP_16.
help from and ok @owainga
- Keep comments to 80 cols for consistency with the rest of the code base
- Made verify a method off of Signature instead of PublicKey since one
verifies a signature with a public key as opposed to the other way
around
- Return new signature from Sign function directly rather than creating a
local temporary variable
- Modify a couple of comments as recommended by @owainga
- Update sample usage in doc.go for both signing messages and verifying
signatures
ok @owainga
This change removes the internal pad function in favor a more opimized
paddedAppend function. Unlike pad, which would always alloate a new
slice of the desired size and copy the bytes into it, paddedAppend
only appends the leading padding when necesary, and uses the builtin
append to copy the remaining source bytes. pad was also used in
combination with another call to the builtin copy func to copy into a
zeroed byte slice. As the slice is now created using make with an
initial length of zero, this copy can also be removed.
As confirmed by poking the bytes with the unsafe package, gc does not
zero array elements between the len and cap when allocating slices
with make(). In combination with the paddedAppend func, this results
in only a single copy of each byte, with no unnecssary zeroing, when
creating the serialized pubkeys. This has not been tested with other
Go compilers (namely, gccgo and llgo), but the new behavior is still
functionally correct regardless of compiler optimizations.
The TestPad function has been removed as the pad func it tested has
likewise been removed.
ok @davecgh
Ordinarily, getwork will return an error if btcd is not connected to any
other peers. This commit relaxes that requirement when running in
regression test mode since it is useful for development purposes.
While here, also improve check which returns an error from getwork is not
current to exclude the check when the best chain height is zero since the
code never believes it is current when at height 0.
This commit adds a full suite tests for the new reject message added in
protocol version 70002 to bring the overall test coverage of btcwire back
up to 100%.
Closes#9.
This commit adds the new reject protocol message added to recent versions
of the reference implementation. This message is intended to be used in
response to messages from a remote peer when it is rejected for some
reason such as blocks being rejected due to not conforming to the chain
rules, transactions double spending inputs, and version messages sent
after they're already sent.
This is work toward issue #9.
- Correct MsgFilterLoad max payload
- Enforce max flag bytes per merkle block
- Improve and finish tests to include testing all error paths
- Add fast paths for BloomUpdateType
- Convert all byte fields to use read/writeVarBytes
- Style and consistency updates
- README.md and doc.go updates
Closes#12.
- Group the new read/writeVarBytes functions together to be consistent
with the existing code
- Modify the comments on the new read/writeVarBytes to be a little more
descriptive and consistent with existing code
- Use "test payload" for field name in the tests for the
read/writeVarBytes functions which is more accurate
- Remove reserved param from NewAlert since there is no point is having
the caller deal with a reserved param
- Various comment tweaks for clarity and consistency
- Use camel case for fuction params for consistency
- Move the NewAlert and NewAlertFromPayload functions after the receiver
definitions for code layout consistency
Closes#11.
Along the same lines as the previous commit, the RPCs that return
serialized data structures should use the max protocol version btcd
supports as opposed to the maximum protocol version etcwire supports.
The getinfo RPC should return the max protocol version btcd supports as
opposed to the maximum protocol version btcwire supports. Currently they
are both the same value, so there is no issue. However, they will not
always be the same.
