Add PredicateTxGenerator#87
Conversation
tokatoka
force-pushed
the
tx_collision
branch
4 times, most recently
from
26c99aa to
2711ac8
Compare
tokatoka
force-pushed
the
tx_collision
branch
2 times, most recently
from
9ad7b6d to
185b1dc
Compare
| // Map from blockhash to (block variable index, list of transaction variable indices) | ||
| block_tx_var_map: HashMap<bitcoin::BlockHash, (usize, usize, Vec<usize>)>, | ||
| // Map from txid to tx variable index | ||
| txo_var_map: HashMap<Txid, VariableIndex>, |
There was a problem hiding this comment.
I think this should track outpoints (txid + index) instead of txid since the first insert will always be the 0-index of a tx and because of this I think the generator will only ever choose to build off of the 0-index even if there are other outputs.
| Ok((const_tx_var, outputs)) | ||
| } | ||
|
|
||
| /// `PredicateTxGenerator` generates transactions that spends the transactions in mempool depending on the given predicate. |
There was a problem hiding this comment.
Feel free to correct me, but PredicateTxGenerator is choosing txs based on mempool state. So the insertion anchor has to correspond to the point where that mempool state is already true, or at least can reasonably be true. Isn't anchoring on TakeTxo too early?
There was a problem hiding this comment.
Too early since the tx it's building off of might not have been sent yet? It does use get_random_instruction_index_from after the TakeTxo point, so it would succeed sometimes. To be correct all the time, it would need to track where SendTx for the tx is happening.
4 participants
This PR adds
PredicateTxGeneratorthatfor example:
DoubleSpendGeneratorthat spends a transaction who has another existing transactions that spend it.