This commit exports a new variant of the existing internal
calcNextRequiredDifficulty function which calculates and returns the next
required difficulty for a block after the end of the current best chain
based on the difficulty retarget rules.
In order to support the exported function the internal one was slightly
modified to accept the block timestamp instead of an entire block since
the timestamp is all that is needed and the caller of the exported
function might next have a full block yet.
This commit modifies the BuildMerkleTreeStore function to accept a slice
of btcutil.Tx transactions as opposed to a full block. This allows more
flexibility when calculating merkle roots since a full block may not be
created yet (particularly when generating blocks that need to be solved in
mining).
Previously, the BuildMerkleTreeStore function accepted a btcutil.Block
because originally the block itself cached the transaction hashes and it
was necessary to have access to the block to make use of the cached
transactions. However, the code has since been improved such that it
caches transaction hashes directly in each btcutil.Tx. This means the
code can remain as efficient as before while allowing the individual
transacitons to be passed.
This commit simply alphabetizes the subsystem logger variables, map, and
use switch so the order in the code is consistent with the sorted output
displayed when using --debuglevel.
The debuglevel parameter has accepted subsystems in additional to an
overall level for quite some time, but the sample config file was not
updated to reflect that.
This commit updates the sample config file accordingly.
This commit changes the websocket client code to use a mutex for
disconnect since it's theoretically possible a non-blocking select on the
quit channel could fall through from two different goroutines thus causing
a second call to close.
ok @jrick.
This change removes the processedtx notification, replacing it with
recvtx, and the spenttx notification, replacing it with redeemingtx.
Both new transactions return the full serialized transaction (encoded
in hexadecimal) rather than details about the transaction.
The old txmined notification has also been completely removed as it is
unreliable due to transaction malleability and no code should be
depending on it.
This change improves the mechanism by which btcd notifies a websocket
client of transaction relating to watched address and unspent outputs
in the following ways:
1. The old processedtx notification has been replaced with the new
recvtx notification. This notification, rather than parsing out
details used by wallet clients, sends the serialized transaction
(as hexadecimal) and any block details (if mined) if any transaction
output sends to one of the websocket client's watched addresses.
2. The old txspent notification has been replaced with the new
redeemingtx notification. This notification, rather than parsing
out details used by wallet clients, sends the serialized transaction
(as hexadecimal) and any block details (if mined) if any transaction
input spends a watched output.
3. When processing notifications for transaction outputs, if any output
spends to a client's watched address, a corresponding spent request
is automatically registered.
4. Transaction notifications originating from mempool now include both
transaction inputs and outputs, rather than only processing
5. When processing notifications for transaction inputs, a client's
output spent request is only removed if the transaction being
processed has also been mined into a block. In combination with the
4th change, this results in two redeemingtx notifications for
transactions which first appear in mempool and are subsequently mined
into a block.
This commit adds an additional sanity check to ensure the block that is
being processed does not contain a timestamp with a precision higher than
one second. This is necessary because the consensus rules only deal with
whole seconds in the time comparisons whereas the internal data structures
make use of Go time.Time values which support up to nanosecond precision.
Also, add a test to ensure the new functionality works as expected.
ok @owainga
This commit changes all cases which generate default timestamps to
time.Now to limit the timestamp to one second precision. The code which
serializes and deserializes timestamps already does this, but it is useful
to make sure defaults don't exceed the precision of the protocol either.
With this change there is less chance that developers using defaults will
end up with structures that have a higher time precision than what will
ultimately be sent across the wire.
This commit moves the subsidy halving interval to the chain params so it
can be configured per network. With that change it sets the regression
test halving interval to 150 to match the regression test params of the
reference implementation.
This was pointed out by @flammit.
The name findLatestKnownCheckpoint is confusing and doesn't really convey
the fact the purpose of the function is to the find the checkpoint prior
to the current known block.
Therefore, rename the function to findPreviousCheckpoint for clarity.
Also, update some comments to follow suit.
This commit adds an additional check to the block acceptance rules which
prevents new blocks that fork the main chain before the previous known
good checkpoint. This prevents storage of new, otherwise valid, blocks
from building off of old blocks which are likely at a much easier
difficulty and therefore could be used to waste cache and disk space.
Note this is slightly different than the other existing check which
prevents blocks with a timestamp before the timestamp of the latest known
good checkpoint since that check effectively prevents old side chain
blocks that already existed (per the claimed timestamp).
ok drahn@
This commit tightens the check for a pay-to-pubkey script by ensuring the
length of the pubkey is one of the two valid values of 33 or 65. This
mirrors the checks in the multisig script type check as well.
ok @owainga
This changes the implementation of the sendrawtransaction RPC handler
to match bitcoind behavior by always returning a rejection error for
any error processing or accepting the tx by the mempool. Previously,
if the tx was rejected for a rule error rather than an actual failure,
a client would still receive the tx sha as a result with no error.
Also, unexport the functions to generate script types. Everything should
(and is) be using PayToAddrScript() with an address type instead of
throwing bytes around.
discussed with #@davecgh
This commit makes use of the new btcscript.HasCanonicalPushes to enforce
canonical data pushes for transactions that are considered standard.
A canonical data push is one where the fewest number of bytes possible to
encode the size of the data being pushed is used. This includes using the
small integer opcodes for single byte data that can be represented
directly.
This commit adds a new ScriptBuilder interface that can be used to build
custom scripts. It currently is fairly basic, but it allows you to push
raw opcodes, ints, and data while respecting canonical encoding. These
primitives are sufficient to build any script.
This could be improved upon with quite a few things. One example would be
functions for certain opcodes that take properly typed parameters to make
it harder to create invalid scripts.
For now though, it is already quite useful since it handles all of the
opcode selection for canonical data pushes and integer encoding.
The initial discussion took place in #5.
This commit builds off the previous commit which fixed the execution of
multi-signature scripts with zero required signatures.
It introduces the concept of a "small int" which is one of OP_0 or OP_1 -
OP_16. All areas of code that deal with multi-sig transactions now make
use of these to ensure consistent handling.
This fixes a few issues surrounding multi-sig zero required signature
transactions included proper detection as a multi-sig script, signature
counting for script statistics, and
ok @owainga
It is possible for a multisignature transaction to require zero
signatures. For example, input 2 of testnet transaction
b2d93dfd0b2c1a380e55e76a8d9cb3075dec9f4474e9485be008c337fd62c1f7
in block number 185117.
Previously the code was pushing a false to the stack when no
valid signatures were found. This commit remedies that by pushing true
when no valid signatures were found, but none are required. Otherwise it
still pushes false when no valid signatures were found, but some are
required.
Fixes#7.
ok @owainga
This commit increases the block priority size to 50000 and the max
standard tx size to 100k. This matches relatively recent changes in the
reference implementation. The max block size was also increased to
750000, but since btcd does not currently create blocks, there is no
constant for it. That constant will likely be added as a part of the
getwork implementation since it requires block creation.
Closes#71.
Previously the websocket notifications for addresses were limited to
pay-to-pubkey-hash only. This commit removes that restriction so
all btcutil.Address types are supported. This includes pay-to-pubkey,
pay-to-pubkey-hash, and pay-to-script-hash.
When a spent notification and address notification is removed, the
tracking entry in the client which is used to track what to remove on
shutdown needs to be removed as well.
This commit refactors the entire websocket client code to resolve several
issues with the previous implementation. Note that this commit does not
change the public API for websockets. It only consists of internal
improvements.
The following is the major issues which have been addressed:
- A slow websocket client could impede notifications to all clients
- Long-running operations such as rescans would block all other requests
until it had completed
- The above two points taken together could lead to apparant hangs since
the client doing the rescan would eventually run out of channel buffer
and block the entire group of clients until the rescan completed
- Disconnecting a websocket during certain operations could lead to a hang
- Stopping the rpc server with operations under way could lead to a hang
- There were no limits to the number of websocket clients that could
connect
The following is a summary of the major changes:
- The websocket code has been split into two entities: a
connection/notification manager and a websocket client
- The new connection/notification manager acts as the entry point from
the rest of the subsystems to feed data which potentially needs to
notify clients
- Each websocket client now has its own instance of the new websocket
client type which controls its own lifecycle
- The data flow has been completely redesigned to closely resemble the
peer data flow
- Each websocket now has its own long-lived goroutines for input, output,
and queuing of notifications
- Notifications use the new notification queue goroutine along with
queueing to ensure they dont't block on stalled or slow peers
- There is a new infrastructure for asynchronously executing long-running
commands such as a rescan while still allowing the faster operations to
continue to be serviced by the same client
- Since long-running operations now run asynchronously, they have been
limited to one at a time
- Added a limit of 10 websocket clients. This is hard coded for now, but
will be made configurable in the future
Taken together these changes make the code far easier to reason about and
update as well solve the aforementioned issues.
Further optimizations to improve performance are possible in regards to
the way the connection/notification manager works, however this commit
already contains a ton of changes, so they are being left for another
time.
This commit adds a new configuration option, --rpcmaxclients, to limit the
number of max standard RPC clients that are served concurrently. Note
that this value does not apply to websocket connections. A future commit
will add support for limiting those separately.
Closes#68.
