Remove GetPriority and ComputePriority. Remove internal machinery for tracking priority in CTxMemPoolEntry.
(cherry picked from commit bitcoin/bitcoin@359e8a03d1)
Zcash:
* We don't have `src/bench/mempool_eviction.cpp`.
* We don't have `-walletrejectlongchains`.
* Now we can remove `MAX_PRIORITY`.
* Fix a comment in `coins.h` while we're changing code next to it.
* Update the `Mempool/PriorityStatsDoNotCrash` regression test.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
This a breaking API change to the prioritisetransaction RPC call which previously required exactly three arguments and now requires exactly two (hash and feeDelta). The function prioritiseTransaction is also updated.
(cherry picked from commit bitcoin/bitcoin@f9b9371c60)
Zcash: We don't have `LoadMempool` or `DumpMempool`.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
The prioritisetransaction API can always be used if a transaction needs to be submitted that bypasses minRelayTxFee.
(cherry picked from commit bitcoin/bitcoin@ad727f4eaf)
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
One test in AcceptToMemoryPool was to compare a transaction's fee
agains the value returned by GetMinRelayFee. This value was zero for
all small transactions. For larger transactions (between
DEFAULT_BLOCK_PRIORITY_SIZE and MAX_STANDARD_TX_SIZE), this function
was preventing low fee transactions from ever being accepted.
With this function removed, we will now allow transactions in that range
with fees (including modifications via PrioritiseTransaction) below
the minRelayTxFee, provided that they have sufficient priority.
(cherry picked from commit bitcoin/bitcoin@901b01d674)
Zcash: Take the upstream commit message (in particular the references to
priority) with a pinch of salt, since we're going to be removing priority
in the backport of bitcoin/bitcoin#9602 . The main reason to include this
commit is that it removes `GetMinRelayFee`, which is assumed to have
happened before bitcoin/bitcoin#9602 .
Note that Zcash doesn't have upstream's `-maxmempool` parameter; it
uses ZIP 401 for mempool size limiting instead.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
(cherry picked from commit bitcoin/bitcoin@27fae3484c)
Zcash: The change to tests is not included because we do not have
`qa/rpc-tests/prioritize_transaction.py` (`prioritisetransaction.py` is
very different). There is no point adding a test for this when it's
immediately going to be broken by the removal of priority and "free"
transactions. It will be up to the PRs that add the ZIP 317 changes to
make sure that fee deltas are taken into account for transactions
entering the mempool.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
zcash/zcash#5987 added a bridge to `orchard::Bundle<Authorized, Amount>`
for `getrawtransaction`. This commit expands it to also cover the
consensus rules, by migrating over missing functionality from the
hand-written FFI methods, and exposing the Orchard `BatchValidator` type
directly (as with Sapling) instead of via the C++ `AuthValidator`
intermediary.
Part of zcash/zcash#6397.
InsertBlockIndex should take a const reference to a uint256 instead of
just a uint256.
LoadBlockIndexGuts also assume std::function<CBlockIndex*(const uint256&)> insertBlockIndex
as an argument:
2d456afebe/src/txdb.h (L150)
Notable changes
===============
This hotfix remediates memory exhaustion vulnerabilities that zcashd inherited
as a fork of bitcoind. These bugs could allow an attacker to use peer-to-peer
messages to fill the memory of a node, resulting in a crash.
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEX8Nd8pnYcf0pobEL9FXpuSAjoYsFAmP1CD8ACgkQ9FXpuSAj
oYvGXQwAqaa1l5qC3VY/60jkH4xmWoSUEzeCOPUG7lYJrIEyzgXj8Ko0Cjr308jm
ISXDDTOxKb2hfnCbeqbZqRyFbzGzG5L6AkjHAvmQMiZwx2JlbH2k+jd5fggOZSMv
shL5KbxWN2YRftc8r+fDraJMbGULbKBWQooKaFyQmupT+bVsRf1Nh+lFIVG4FUwA
oWZot36wB6Y99Y57wlyN2m22+j1glyk5mKv2ttXYbdwSRTFB5W5L1US6Z8uxXQPb
Qa7sVO90QtzkHr+GPtMiTn513VuLFr+KArGn+qidU/PvblJI/vXuBf54g7JZw4Ot
gkKziatgaN3pO30I4rTij78LCgKJZ/WImLE7nwTl/bG2Ki1WfyolNLjS+1pXpcPL
xlXso5ioKlSIGhnlPouXwoxlaqTpDwRKLp0azNJl5hG/tXEHupToK2M61woi9LlP
4RB+a75OptFi9NMp/Sx0T8zNRn7OB8iP+3BgRP0+mzcLC1AHfjJk/IRo9CQh5jRZ
MMe98OrC
=6QYn
-----END PGP SIGNATURE-----
Merge tag 'v5.3.3' into hotfix-v5.4.2
zcashd release v5.3.3
Notable changes
===============
This hotfix remediates memory exhaustion vulnerabilities that zcashd inherited
as a fork of bitcoind. These bugs could allow an attacker to use peer-to-peer
messages to fill the memory of a node, resulting in a crash.
little memory when we disconnect the node.
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Co-authored-by: Jack Grigg <str4d@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
While limitations on the influence of attackers on addrman already
exist (affected buckets are restricted to a subset based on incoming
IP / network group), there is no reason to permit them to let them
feed us addresses at more than a multiple of the normal network
rate.
This commit introduces a "token bucket" rate limiter for the
processing of addresses in incoming ADDR and ADDRV2 messages.
Every connection gets an associated token bucket. Processing an
address in an ADDR or ADDRV2 message from non-whitelisted peers
consumes a token from the bucket. If the bucket is empty, the
address is ignored (it is not forwarded or processed). The token
counter increases at a rate of 0.1 tokens per second, and will
accrue up to a maximum of 1000 tokens (the maximum we accept in a
single ADDR or ADDRV2). When a GETADDR is sent to a peer, it
immediately gets 1000 additional tokens, as we actively desire many
addresses from such peers (this may temporarily cause the token
count to exceed 1000).
The rate limit of 0.1 addr/s was chosen based on observation of
honest nodes on the network. Activity in general from most nodes
is either 0, or up to a maximum around 0.025 addr/s for recent
Bitcoin Core nodes. A few (self-identified, through subver) crawler
nodes occasionally exceed 0.1 addr/s.
(cherry-picked from commit bitcoin/bitcoin@0d64b8f709)
I thought we had removed this a long time ago, TBH, its really
confusing feedback to users that we display whether a tx was
broadcast to immediate neighbor nodes, given that has little
indication of whether the tx propagated very far.
This should lower the main thread's likelihood to immediately reacquire
cs_main after dropping it, which should help ThreadNotifyWallets and the
RPC methods to acquire cs_main more quickly.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
We no longer fetch updates from the mempool unless we have fetched all
updates from the chain, as we would otherwise notify the wallet of
mempool changes for which they have not observed parent transactions
in the chain.
Co-authored-by: Jack Grigg <jack@z.cash>
Associate with each CTxMemPoolEntry all the size/fees of descendant
mempool transactions. Sort mempool by max(feerate of entry, feerate
of descendants). Update statistics on-the-fly as transactions enter
or leave the mempool.
Also add ancestor and descendant limiting, so that transactions can
be rejected if the number or size of unconfirmed ancestors exceeds
a target, or if adding a transaction would cause some other mempool
entry to have too many (or too large) a set of unconfirmed in-
mempool descendants.
(cherry picked from commit bitcoin/bitcoin@5add7a74a6)
Zcash:
- Mempool methods were adapted to our mempool changes.
- Default ancestor and descendant size limits were double to account for
our larger block size.
- The mempool_packages RPC test fee was adapted to account for our
emissions curve (which results in a smaller per-block reward that
needs to be split into smaller shards for sequential transactions.
- Includes some modifications to account for us backporting
bitcoin/bitcoin@f3fe83673e early in
zcash/zcash#5269.
(cherry-picked bitcoin/bitcoin@76f74811c4)
At startup, we choose one peer to serve us the headers chain, until
our best header is close to caught up. Disconnect this peer if more
than 15 minutes + 1ms/expected_header passes and our best header
is still more than 1 day away from current time.
(cherrypicked bitcoin/bitcoin@e2652002b6)
nMinimumChainWork is an anti-DoS threshold; wait until we have a proposed
tip with more work than that before downloading blocks towards that tip.
C++ `auto`, as opposed to `auto&`, does not infer reference types (except when it does:
https://blog.petrzemek.net/2017/12/08/when-auto-seemingly-deduces-a-reference-in-cpp/
but that doesn't apply here). The inferred type of `orchard_bundle` was therefore
`const OrchardBundle`. This made the assignment a call to `OrchardBundle::operator=`
which calls `orchard_bundle_clone`. A reference assignment is sufficient, because `tx`
is in scope throughout `ContextualCheckTransaction`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Many error messages would say "see debug.log" or similar, without
indicating where the debug log actually lives. This now prints the
actual path in those cases.
It also changes more general uses of "debug.log" to "debug log", since
the file name may not even be "debug.log" if the user has specified it.
`zcbenchmark` internally loops within the same process to run the same
benchmark multiple times. This meant it was being caught up in the
global validity cache, giving faster results for every iteration except
the first. This was not noticeable for the historic slow transparent
block, but became noticeable once we started caching Sapling and Orchard
bundle validity in zcash/zcash#6073.
As the intention of the benchmarks is to measure the worst case where
the block in question has not had any of its transactions observed
before (as is the case for IBD), we now disable cache storage if calling
`ConnectBlock` from a slow block benchmark.
Alex Morcos
Daira Emma Hopwood
Suhas Daftuar
Jack Grigg
Jack Grigg
DeckerSU
str4d
Kris Nuttycombe
Jon Atack
Pieter Wuille
Matt Corallo
Alfredo Garcia
Suhas Daftuar
Miodrag Popović
Greg Pfeil