Tested against master using the REST api (/rest/mempool/contents), simple addition of a field.
Personal use case is for fee analysis software.
Tested against master using the REST api (/rest/mempool/contents), simple addition of a field.
Personal use case is for fee analysis software.
No test affected 😞 care to improve by asserting the new field in the relevant RPC's 😉?
Concept ACK
I guess you need to update the documentation as well.
Tests are failing. txid2 and txid3 work as expected. txid1 fails on both my test and #11203 (add wtxid to mempool entry output).
Do not merge as is.
txid1 is failing because at that point "tx" is actually referring to the input to txid1, not the transaction for txid1. It works fine for me if I add
tx = FromHex(CTransaction(), self.nodes[0].gettransaction(txid1)['hex'])
prior to the assert_equal lines (and uncomment them obviously).
Doh. You're absolutely right. Fixed.
The final commit 'Refactor segwit 3-tx-chain' changes all references to 'tx' to 'tx/tx1/tx2/tx3' in order to clarify that. It has a large diff and can be dropped if necessary (only affects code style).
I have also rebased on master at 3255d63.
Should be good to go now.
Concept ACK, but it turns out GetTxSize is not actually what we claim it is. See the calculation of GetVirtualTransactionSize which potentially includes number of sig ops in the calculation.
I thinke the right path forward is:
255 | + # Check that wtxid is properly reported in mempool entry (txid1) 256 | + assert_equal(int(self.nodes[0].getmempoolentry(txid1)["wtxid"], 16), tx1.calc_sha256(True)) 257 | + 258 | + # Check that weight and sizei (actually vsize) are properly reported in mempool entry (txid1) 259 | + assert_equal(self.nodes[0].getmempoolentry(txid1)["size"], (self.nodes[0].getmempoolentry(txid1)["weight"] + 3) // 4) 260 | + assert_equal(self.nodes[0].getmempoolentry(txid1)["weight"], len(tx1.serialize())*3 + len(tx1.serialize_with_witness()))
serialize needs to be made serialize_without_witness
Needs rebase and review comments addressed.
Closing this, please see #14649