Describe the issue

This issue is related to #6748

I'm trying to create a new transaction on zcash v6.0.0 by using:

• simple sendtoaddress <address> amount and getting error of:

tx unpaid action limit exceeded: 5 action(s) exceeds limit of 0

• more complicated mechanism involving createrawtransaction, fundrawtransaction, signrawtransaction and sendrawtransaction to get the benefit of chaining together multiple receivers in a single transaction to save fees and avoid spamming zcash network and I'm getting same error:

error 66: tx unpaid action limit exceeded: 5 action(s) exceeds limit of 0

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Install zcash v6.0.0
2. Try sending a transaction out by using ./zcash-cli sendtoaddress <zcash_address> <amount>
3. You'll get an error: error 66: tx unpaid action limit exceeded: 5 action(s) exceeds limit of 0
4. Also the same goes if you try to create more advanced transaction by using createrawtransaction + fundrawtransaction, here is a way to reproduce even with a single receiver:

• ./zcash-cli createrawtransaction "[]" "{\"<address>\":<amount>"
• ./zcash-cli fundrawtransaction <result of createrawtransaction>
• ./zcash-cli signrawtransaction <result of fundrawtransaction>
• ./zcash-cli sendrawtransaction <result of signrawtransaction>

Expected behaviour

The transaction sending from official zcash daemon should be working flawlessly and there should be NO breaking changes like this to node operators or exchanges running zcash.

Such changes should be announced and SLOWLY introduced to anyone related to Zcash community as it's a BREAKING CHANGE for transaction creation.

I still don't get ZIP-317 what is the point of it as there is a mechanism related to fees in Bitcoin which worked just fine if mempool is stuffed with millions of transactions - miners simply pick up first the ones with highest fees.

Or if someone sends a transaction with e.g. 1100 inputs he will pay a lot of fees per byte resulting in high fee for this particular transaction or it won't stay in the mempool.

With ZIP-317 you've essentially increased fees for ANY transaction doesn't matter if it has 9999 inputs or just single one and fee also no longer depends on the TX size it depends on the total number of inputs or outputs (which one is bigger) and hardcoded to 5000 zat instead of making it possible to adjust fees based on the load on the blockchain.

You could instead simply increase min relayfee and resolve this issue without introducing complexity of new algorithms for fee calculation and also breaking all coin selection algorithms used in many BTC-like coins.

From this bug report you can understand that it's a half-baked feature as official implementation of sendtoaddress and createrawtransaction simply stopped working after Nov 23.

Workaround

You can of course tune the TX fee by using settxfee of the daemon and setting it to e.g. "paytxfee": 0.001 or more but this might fail if you use fundrawtransaction mechanism and chain together multiple receivers in a single transaction and also might fail under certain conditions if there are many inputs in your wallet.

The version of Zcash you were using:

./zcashd --version
Zcash Daemon version v6.0.0

Machine specs:

• OS name + version: Ubuntu 22.04.5 LTS
• CPU: doesn't matter
• RAM: 8G
• Disk size: 500G
• Disk Type (HD/SDD): HDD
• Linux kernel version (uname -a): doesn't matter

@str4d