sendrawtransaction
and getmempoolentry
with the goal that submitting the tx to the mempool will become optional.
sendrawtransaction
and getmempoolentry
with the goal that submitting the tx to the mempool will become optional.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
70@@ -71,9 +71,9 @@ def send_self_transfer(self, *, fee_rate=Decimal("0.003"), from_node, utxo_to_sp
71 tx.wit.vtxinwit[0].scriptWitness.stack = [CScript([OP_TRUE])]
72 tx_hex = tx.serialize().hex()
73
74- txid = from_node.sendrawtransaction(tx_hex)
75- self._utxos.append({'txid': txid, 'vout': 0, 'value': send_value})
76- tx_info = from_node.getmempoolentry(txid)
77+ tx_info = from_node.testmempoolaccept([tx_hex])[0]
78+ self._utxos.append({'txid': tx_info['txid'], 'vout': 0, 'value': send_value})
79+ from_node.sendrawtransaction(tx_hex)
reject-reason
is a part of the tx_info
object can’t we just return the reject-reason
rather than raising an exception?
sendrawtransaction
would throw.
This makes me notice a potentially unwanted side-effect in send_self_transfer
. If a test case is catching an exception in send_self_transfer
, self._utxos.append({'txid': txid, 'vout': 0, 'value': send_value})
is happening before some rpc calls and assertions that could potentially fail. This could cause some confusing behavior in the case an exception does get thrown, and self._utxos
is left modified
Not related to this PR imo as this behavior was already present, but do you think it would be useful to do self._utxos.append({'txid': txid, 'vout': 0, 'value': send_value})
at the very end of this method, when we know it will succeed, in another PR?
testmempoolaccept
succeeds but sendrawtransaction
fails
79+ from_node.sendrawtransaction(tx_hex)
80 assert_equal(tx_info['vsize'], vsize)
81- assert_equal(tx_info['fee'], fee)
82- return {'txid': txid, 'wtxid': tx_info['wtxid'], 'hex': tx_hex}
83+ assert_equal(tx_info['fees']['base'], fee)
84+ return {'txid': tx_info['txid'], 'wtxid': from_node.decoderawtransaction(tx_hex)['hash'], 'hex': tx_hex}
tx_info
here? There have been a few cases where that would have been nice when I worked with MiniWallet
. If you think it’s useful I could open a PR for that
Also I’m pretty sure you can get wtxid with tx.calc_sha256(with_witness=True)
sha256 here is is an int
, not a hex encoding of how txids are represented in Bitcoin (with endian switched for some reason)
If you think it’s useful I could open a PR for that
Sure, let’s do that in the PR where the return value is needed.
What do you think of a bool option?
Sure, but let’s do that in the PR that needs the feature. (To not introduce dead code branches right away)