Is there any obvious way to get a transaction stuck in the mempool?
Does mining software bother to check the transaction fees, i don’t think it would, it would expect all transactions to have the same fee.
I saw a post on here were someone sent a 0 fee transaction and it messed up the block explorer but it did get mined. I dont want that to happen. i want it to get stuck for maybe 2 hours, then either rejected or have the transaction updated so it goes through.
I do have one condition, these have to be z2z transactions.
If there were, we’d remove it It would be easily turned into a DoS attack on either the wallet sending the transaction, or the nodes maintaining the mempool.
For the latter case, zcashd implements the bounded mempool strategy documented in ZIP 401, which makes it impossible for transactions to be indefinitely stuck in the mempool and cause general mempool DoS; when the pool is under high load, each transaction has some probability of being randomly evicted.
Yes. zcashd inherited Bitcoin Core’s block creation logic, which we modified to prefer shielded transactions, but otherwise currently behaves roughly the same (sort by priority for part of the block, then by fee for the rest).
All transactions in the mempool are by definition valid candidates to be mined, and there is no way to prevent a miner from mining transactions that are in the global mempool (so the miner knows about them) and are valid to mine.
However, the “ensure tx is rejected if it isn’t mined after 2 hours” is easily enforced, by setting the transaction’s expiry height to a block height 2 hours in the future. This has the effect of causing the transaction to become invalid after that height, and be automatically evicted from the mempool if it is still there.
Thank you for the detailed response. This is really helpful.
I will pay around with this, This might do what I want. At least I know the conditions I need to recreate that could potentially cause something to get stuck.
Thank you for the links @vamsi they are very helpful.
I have looked through the documents, and I think I can do what I need to, but I am a little unsure. I would really appreciate it if you could let me know if this would work or not, or what the constraints are.
Going through zip401 and 225, It seems I could create transaction that cant be mined by setting the anchor and block expiry to be the same (the next block). Is it possible to set an anchor=xyz and expiry=xyz-1 (this wouldnt get broadcast by the nodes would it?)
Will this transaction propagate through the mempool and end up in every nodes recently evicted for 60ish minutes? or does the first node evict it and not propagate it? (does it even get this far)
Can I ask a node what it has in recently evicted?
I could be completely wrong here, so I would appreciate any extra info.
Yes, you could create a transaction like that, and you are correct that it cannot be mined. If a transaction uses the anchor for height XYZ, then by definition height XYZ - 1 is in the past, and so the transaction is already expired at the time it is created.
The first node wouldn’t even add it to its mempool. The mempool only contains transactions that can be mined; nodes would detect that the transaction is expired and drop it.
It would be easily turned into a DoS attack on either the wallet sending the transaction, or the nodes maintaining the mempool.