(We express it that way rather than 300 zats/1000 bytes, because the
threshold is always rounded to an integer and then multiplied by 3.)
Bitcoin Core added the concept of "dust" in bitcoin/bitcoin#2577.
At that point the dust threshold was tied to three times the
minRelayTxFee rate, with the motivation that if you'd pay more than
a third of the minimum relay fee to spend something, it should be
considered dust. This was implemented as a standard rule rejecting
dust outputs.
This motivation will not apply after ZIP 317 block construction
is implemented: at that point the ZIP 317 marginal fee will be
5000 zats per logical action, but the dust threshold rate will
still be three times 100 zats per 1000 bytes. Those costs would
only coincide if the marginal size per logical action were
5000/300 * 1000 ~= 16667 bytes, and in practice the marginal size
for any kind of input is much smaller than that.
However, to avoid interoperability problems (older wallets creating
transactions that newer nodes will reject because they view the
outputs as dust), we will have to coordinate any increase in the
dust threshold carefully.
More history: in Zcash the minRelayTxFee rate was 5000 zats/1000 bytes
at launch, changed to 1000 zats/1000 bytes in zcashd v1.0.3 and to
100 zats/1000 bytes in zcashd v1.0.7-1 (#2141). The relaying problem
for shielded transactions (#1969) that prompted the latter change was
fixed more thoroughly by the addition of `CFeeRate::GetFeeForRelay`
in #4916, ensuring that a transaction paying `DEFAULT_FEE` can always
be relayed. At the same time the default fee was set to 1000 zats,
per ZIP 313.
An earlier commit in this PR changed relaying policy to be more strict
about enforcing minRelayTxFee. The commit just before this one also
allowed `-minrelaytxfee=0`, which we are going to use to avoid some test
breakage. But if the dust threshold rate were still set to three times
the minRelayTxFee rate, then setting `-minrelaytxfee=0` would have the
side effect of setting the dust threshold to zero, which is not intended.
Bitcoin Core took a different approach to disentangling the dust
threshold from the relay threshold, adding a `-dustrelayfee` option
(bitcoin/bitcoin#9380). We don't want to do that because it is likely
that we will change the dust policy again, and adding a user-visible
config option might conflict with that. Also, it isn't a good idea for
the dust threshold rate to be configurable per node; it's a standard
rule parameter and should only be changed with network-wide coordination
(if it is increased then wallets have to change before nodes, and vice
versa if it is decreased). So for now we set it to a constant that
matches the behaviour before this PR.
Since we can no longer modify the dust threshold, we remove a check
from transaction_tests.cpp that relied on doing so.
This change also indirectly fixes a false-positive assertion error that
would occur in `SpendableInputs::LimitToAmount` if we allowed the dust
threshold to be zero.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
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>
If `valueBalanceSapling` were `INT64_MIN`, the negation would be undefined
behaviour. Also, if `valueBalanceSapling` were a large-magnitude value
then `nValueOut += -valueBalanceSapling;` could overflow, which would be
undefined behaviour.
In practice neither of these cases can happen because `GetValueOut()` is
only called on non-contextually valid transactions, for which
`valueBalanceSapling` will have been checked to be in range.
`GetShieldedValueIn()` is similarly cleaned up for consistency.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
This missing was causing `hashBlockCommitments` to be incorrectly computed
in mined blocks, due to the specific way the coinbase transaction gets
constructed. This went unnoticed when the default `authDigest` for legacy
transactions was the null hash, but was exposed when that changed to
`[0xFF; 32]`.
The Rust parser is stricter than the C++ parser, so we can reach errors
now non-contextually that previously were thrown by the consensus rules.
Various tests have been updated to check for these exceptions, as they
can no longer instantiate these transactions to pass to the consensus
rules. The tests use an unsafe constructor so they can still check the
consensus rules.
Using `const_cast` to serialize into an otherwise-constant field is
undefined behaviour:
https://github.com/zcash/zcash/issues/967#issuecomment-225467855
Instead, we should make CTransaction's members non-const and private,
and provide accessors. It's not practical to make this change everywhere
yet, but we can start by only introducing new fields in this way. We
will need to provide accessors for orchardBundle's properties in any
case, since we need to call across the Rust FFI.
The majority of the parser is in C++, but Orchard bundles are parsed
exclusively by Rust.
The ZIP 244 test vectors are brought in here so we can start by testing
round-trip serialization.
This matches the existing transaction builder structs:
- SpendDescriptionInfo
- OutputDescriptionInfo
- TransparentInputInfo
It also removes the dependency of the transaction format on the proving
system.
crypto_sign_verify_detached is still used within the consensus rules
until Canopy activation. ed25519-zebra generates signatures that are
valid under both pre- and post-Canopy rules (for our honest usage),
so we can use it to generate transaction signatures now. Then once
Canopy activates, we can remove the remaining usages of crypto_sign.
It needs to be closer to the root of our dependency tree, so that it can
depend on the transaction format. The libzcash compilation unit is
further from the dependency tree root than the transaction format.
We don't support making pre-Sapling JoinSplit proofs, and we load the
parameters for post-Sapling JoinSplit proofs at proving time, so there
is no need for a global ZCJoinSplit to be passed through the APIs.
Update note classes to be polymorphic
Closes#3194. Lays foundation for introduction of Sapling notes through refactoring and creation of a class hierarchy for Sprout notes. This PR updates some tests, but otherwise is a no-op.
Not returning a value at the end of a non-void function is undefined behaviour.
Given that this managed to pass our full test suite, I guess that GCC looks for
un-returned values at the end of a function and uses them as the return value,
if the keyword is missing. Clang OTOH complains, which is how we spotted this:
https://ci.z.cash/#/builders/16/builds/282
Details of Sapling datatypes will be filled in later; for now, they are treated
as binary blobs.
Includes code cherry-picked from upstream commit:
7030d9eb47254499bba14f1c00abc6bf493efd91
BIP144: Serialization, hashes, relay (sender side)
Daira Emma Hopwood
Alex Morcos
Jack Grigg
str4d
Kris Nuttycombe
Alfredo Garcia
Jim Posen
Steven Smith
Janito Vaqueiro Ferreira Filho
Kris Nuttycombe
Kris Nuttycombe
Larry Ruane
Taylor Hornby
Dimitris Apostolou
Eirik Ogilvie-Wigley
Ariel Gabizon
Sean Bowe
Homu
Simon