zancas
December 12, 2025, 6:53pm
64
I am confused.. doesn’t ZIP317 make the fee for transaction proportional to the number of outputs?
Why is an additional filter necessary?
Should such a use be at least considered through the ZIP process as an update to ZIP317?
Also, for flavor, here’s my official position on Zerdinals:
The filter exists from way before ZIP-317 (it might be inherited from Bitcoin? I’m not sure). Its usefulness is questionable now that ZIP-317 exists, but it was easier to simply implement it in zebra to guarantee consistency across both nodes than to argue where it should keep existing and possibly remove it from zcashd. When zebrad becomes the only node it will be easier to remove the filter if we wish to.
str4d
December 12, 2025, 8:50pm
66
It is indeed inherited from Bitcoin:
committed 10:15AM - 24 Aug 12 UTC
later extended to cover “dust”:
master ← gavinandresen:fee_bandaid
opened 02:35PM - 26 Apr 13 UTC
This is a quick, safe fix for transaction fee handling. A riskier, more complica… ted fix still needs to happen, but will take more time to code/test/etc.
Two motivations for this pull:
First, to discourage people from bloating users' wallets and the UTXO set with tiny outputs.
This pull defines 'uneconomic dust' as 54.3 uBTC (5430 satoshis, about $0.007 at current prices), and treats any transaction with outputs less than 5430 satoshis as non-standard (won't be relayed, won't be mined). 5430 satoshis is derived from the cost (in fees) to spend a TxOut/TxIn. See https://people.xiph.org/~greg/txouts2.png for proportion of recent outputs this will (eventually) affect.
Second, we have no idea what will happen to Bitcoin prices or transaction volume / competition for space in blocks. So this patch lets users and miners specify the minimum transaction fees at startup, using the -mintxfee / -mintxrelayfee options (which I'm intentionally leaving undocumented for now). The dust/nonstandard test is based on the -mintxrelayfee.
Qt and RPC both now tell the user why CreateTransaction fails, if it fails; Qt error reporting is a little wonky (try to send one satoshi, and you get two modal dialog boxes, one after the other; I don't care enough to try to fix that).
Note: I spent several hours trying, and failing, to create unit tests for this patch; CWallet::fFileBacked is ignored by several of the wallet routines used by CWallet::CreateNewTransaction. In the end, I decided thatrefactoring CWallet to support unit testing would be much more extensive and riskier than these changes.
We did consider the interaction between dust and ZIP 317; see this commit’s comment for extensive details.
committed 05:49PM - 17 Apr 23 UTC
(We express it that way rather than 300 zats/1000 bytes, because the
threshold i… s 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>
1 Like
zancas
December 18, 2025, 6:20pm
67
OK, so filtering is not necessary per se, but matching behaviors across nodes is desirable.
To recap, now that Zerdinals have highlighted the discrepancy, Zebrad is matching Zcashd to standardize behavior.
1 Like
i remember i had at one time a few ZEC , now i regret not holding them @buy2cbonline
