This commit modifies finalized transaction check used by the memory pool
and block templates to use the network adjusted time instead of the
unadjusted local time. This helps keep the transactions accepted to the
memory pool, and hence allowed to relay, more consistent across nodes.
By exporting StandardVerifyFlags, clients can ensure they create
transactions that btcd will accept into its mempool.
This flag doesn't belong in txscript. It belongs in a
policy package. However, this is currently the least worse place.
This modifies the recently added code which rejects free/low-fee
transactions with insufficient priority to ignore resurrected transactions
from disconnected blocks. It also exempts resurrected transactions from
the free/low-fee rate limiting.
By default, have the mempool reject free and low-fee transactions that
have insufficient priority to be mined in the next block.
Addtionally, add a new configuration option, -norelaypriority, to
disable the check.
* Address index is built up concurrently with the `--addrindex` flag.
* Entire index can be deleted with `--dropaddrindex`.
* New RPC call: `searchrawtransaction`
* Returns all transacitons related to a particular address
* Includes mempool transactions
* Requires `--addrindex` to be activated and fully caught up.
* New `blockLogger` struct has been added to factor our common logging
code
* Wiki and docs updated with new features.
* When an inv is to be sent to the server for relaying, the sender
already has access to the underlying data. So
instead of requiring the relay to look up the data by
hash, the data is now coupled in the request message.
The mempool's MaybeAcceptTransaction methods have also been modified
to return a slice of transaction hashes referenced by the transaction
inputs which are unknown (totally spent or never seen). While this is
currently used to include the first hash in a ProcessTransaction error
message if inserting orphans is not allowed, it may also be used in
the future to request orphan transactions from peers.
This commit addresses a few nitpicks in the recent getrawmppol update
which populates the starting and current priority fields.
In particular:
- Move the new calcInputValueAge function before the function which
invokes it so it is consistent with the rest of the mempool code
- Double space after periods for consistency
- Correct the comments for calcInputValueAge to indiciate that inputs
which are in the the memory pool count as zero toward the value age
rather than the incorrect claim that that the overal input value age is
zero when one of them does
- Rename endingPriority to currentPriority to match the RPC field and its
actual function
- Make the comment about using zero when input transactions can't be found
for some reason more accurate since there can be (and frequently is)
more than one input transaction
This change removes transactions from a newly connected block
from the orphan pool if they exist. Additionally, any orphan
transactions that are no longer orphan transactions are moved
to the mempool and inv'd to the currently connected peers.
This commit builds on the recent limiter updates. The recent changes
introduced a new function named calcTxFee which could easily be confused
with calculating the fees of the transaction rather than its intended
purpose of calculating the minimum transaciton relay fee.
Rather than taking that approach, this commit instead renames the existing
function to calcMinRequiredTxRelayFee and uses a consistent variable name
for the serialized size of a transaction. It then moves the check for
whether or not the check should be applied based on the serialized size of
the transcation and block priority to the call site.
This approach also has the benefit of avoiding two calls to the
calculation function since it's a local at the call site.
ok @jrick, @dajohi
Before, btcd was rate limiting all transactions that had a minimum
fee of zero. Now, btcd only rate limits transactions that contain
a fee less than the calculated fee based on size.
Closes#163
This commit implements reject handling as defined by BIP0061 and bumps the
maximum supported protocol version to 70002 accordingly.
As a part of supporting this a new error type named RuleError has been
introduced which encapsulates and underlying error which could be one of
the existing TxRuleError or btcchain.RuleError types.
This allows a single high level type assertion to be used to determine if
the block or transaction was rejected due to a rule error or due to an
unexpected error. Meanwhile, an appropriate reject error can be created
from the error by pulling the underlying error out and using it.
Also, a check for minimum protocol version of 209 has been added.
Closes#133.
This commit implements the long polling portion of the getblocktemplate
RPC as defined by BIP0022. Per the specification, each block template is
returned with a longpollid which can be used in a subsequent
getblocktemplate request to keep the connection open until the server
determines the block template associated with the longpollid should be
replaced with a new one.
This is work towards #124.
This commit helps prevent transaction malleability by enforcing that the
extra dummy value on multisig transaction script contains no data for a
transaction . This syncs with a recent change in Bitcoin Core to remain
compatible.
As part of this change a new constant has been introduced which is used to
specify the script flags which are used for standard transactions. This
constant is then used in both the memory pool and the mining code to
ensure they remain in sync with one another.
Closes#131.
ok @jrick, @dajohi
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 commit implements a rebroadcast handler which deals with
rebroadcasting inventory at a random time interval between 0 and 30
minutes. It then uses the new rebroadcast logic to ensure transactions
which were submitted via the sendrawtransaction RPC are rebroadcast until
they make it into a block.
Closes#99.
This commit adds a new function named NewBlockTemplate along with
supporting infrastructure which is part of the core functionality needed
to support mining.
In particular the function creates a new block template which contains a
fully populated block with a zero nonce that is ready to be solved as well
as additional information regarding the fees and number of signature
operations for each transaction included in the block. The specific
transaction selection logic mirrors the reference implementation.
Various cleanup, optimizations, and comment suggestions provided by
@owainga. Also contains some naming suggestions and comment fixes from
@flammit.
This commit removes the word "only" from the non-standard transaction
error message when the number of items on the stack does not match the
number of expected items.
This was suggested by @mbelshe.
This change modifies the RPC server's notifiation manager from a
struct with requests, protected by a mutux, to two goroutines. The
first maintains a queue of all notifications and control requests
(registering/unregistering notifications), while the second reads from
the queue and processes notifications and requests one at a time.
Previously, to prevent slowing down block and mempool processing, each
notification would be handled by spawning a new goroutine. This lead
to cases where notifications would end up being sent to clients in a
different order than they were created. Adding a queue keeps the
order of notifications originating from the same goroutine, while also
not slowing down processing while waiting for notifications to be
processed and sent.
ok @davecgh
This mirrors a recent change in the reference implementation. Since the
vast majority of the network still uses it and transactions which aren't
considered standard won't be relayed, the rules for standard transactions
need to be kept consistent.
Ideally this should be handled via floating fees, but we're rather limited
until we have miner support and a larger network share so the probability
of a transaction being relayed and confirmed is high.
Closes#100.
ok @owainga
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 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.
