Topic: TheBDM.bdv().getTxByHash() returning bad data (Read 689 times)
Hi. Just FYI, you should probably try this on [the new version](https://github.com/goatpig/BitcoinArmory/tree/testing). It's coming out soon and has some more changes that may or may not be compatible with what you wrote.
I worked around this by manually composing a txMap from bitcoind API calls, which I feed into UnsignedTransaction. It's suboptimal, but it works reliably.
https://github.com/CounterpartyXCP/counterblock/commit/6b95a6b3aa2ce467faa36db72296b3fed612b3ba
https://github.com/CounterpartyXCP/counterblock/commit/6b95a6b3aa2ce467faa36db72296b3fed612b3ba
Hi, I'm one of the Counterparty developers.
Over a year ago, we implemented offline storage of Counterparty assets using Armory. This has worked well, and numerous people use it for their Counterparty asset cold storage needs.
The code we wrote worked fine under the older versions of Armory (e.g. 0.92.x). In the low-S enforcement with bitcoind, and the subsequent update to Armory, I noticed the BDM API had changed.
I made my updates to work with that (easy enough) and the service starts up and runs against the newest armory release (0.93.3)
Here's the file, short and sweet: https://github.com/CounterpartyXCP/counterblock/blob/develop/counterblock/armory_utxsvr.py
However, under this new version, I'm having a problem producing BIP 0010 ASCII dumps from unsigned Tx hex, with no other changes except the update of the Armory code, upgrade to bitcoind-addrindex 0.12.0 and the necessary changes in our armory_utxsvr.py file. Debugging through it, it starts from this line:
https://github.com/CounterpartyXCP/counterblock/blob/develop/counterblock/armory_utxsvr.py#L33
The actual Exception is:
The cause ends up being with a getTxByHash() call returning an invalid (uninitialized) transaction object:
https://github.com/etotheipi/BitcoinArmory/blob/e59e10d38c4f1b64c949d3760205a5d78dcc9abf/armoryengine/Transaction.py#L2058
(Note that the txin, txhash, and so on all look good, via .toString() calls. The txhash is valid. But once input into getTxByHash(), the resultant cppPrevTx object is invalid (cppPrevTx.isInitialized() is False, .getBlockTxIndex()/.getBlockHeight() are of course all bogus -- and the "if" check on line 2059 doesn't catch that because is not checking for !cppPrevTx.isInitialized() (bug?)).
So my question is, what could be the cause of this? Just corruption, or something I'm missing in the code?
For good measure, I blew away the armory "database" dir and restarted armory_utxsvr.py, which rebuilt it (happens much quicker now it seems). Still no luck. The next step would be a bitcoind reindex? I was also going to try it on another box, and am downloading the blockchain now....
Thanks for any help.
Over a year ago, we implemented offline storage of Counterparty assets using Armory. This has worked well, and numerous people use it for their Counterparty asset cold storage needs.
The code we wrote worked fine under the older versions of Armory (e.g. 0.92.x). In the low-S enforcement with bitcoind, and the subsequent update to Armory, I noticed the BDM API had changed.
I made my updates to work with that (easy enough) and the service starts up and runs against the newest armory release (0.93.3)
Here's the file, short and sweet: https://github.com/CounterpartyXCP/counterblock/blob/develop/counterblock/armory_utxsvr.py
However, under this new version, I'm having a problem producing BIP 0010 ASCII dumps from unsigned Tx hex, with no other changes except the update of the Armory code, upgrade to bitcoind-addrindex 0.12.0 and the necessary changes in our armory_utxsvr.py file. Debugging through it, it starts from this line:
https://github.com/CounterpartyXCP/counterblock/blob/develop/counterblock/armory_utxsvr.py#L33
The actual Exception is:
Code:
Traceback (most recent call last):
File "/home/xcp/federatednode_build/env.counterblock/local/lib/python2.7/site-packages/jsonrpc/manager.py", line 108, in _get_responses
result = method(*request.args, **request.kwargs)
File "/home/xcp/federatednode_build/env.counterblock/local/lib/python2.7/site-packages/counterblock-1.3.1-py2.7.egg/counterblock/armory_utxsvr.py", line 33, in serialize_unsigned_tx
utx = UnsignedTransaction(pytx=pytx, pubKeyMap=hex_to_binary(public_key_hex))
File "/usr/lib/armory/armoryengine/Transaction.py", line 1965, in __init__
self.createFromPyTx(pytx, pubKeyMap, txMap, p2shMap)
File "/usr/lib/armory/armoryengine/Transaction.py", line 2068, in createFromPyTx
pyPrevTx = PyTx().unserialize(cppPrevTx.serialize())
File "/usr/lib/armory/armoryengine/Transaction.py", line 680, in unserialize
self.version = txData.get(UINT32)
File "/usr/lib/armory/armoryengine/BinaryUnpacker.py", line 66, in get
sizeCheck(4)
File "/usr/lib/armory/armoryengine/BinaryUnpacker.py", line 61, in sizeCheck
raise UnpackerError
UnpackerError
The cause ends up being with a getTxByHash() call returning an invalid (uninitialized) transaction object:
https://github.com/etotheipi/BitcoinArmory/blob/e59e10d38c4f1b64c949d3760205a5d78dcc9abf/armoryengine/Transaction.py#L2058
(Note that the txin, txhash, and so on all look good, via .toString() calls. The txhash is valid. But once input into getTxByHash(), the resultant cppPrevTx object is invalid (cppPrevTx.isInitialized() is False, .getBlockTxIndex()/.getBlockHeight() are of course all bogus -- and the "if" check on line 2059 doesn't catch that because is not checking for !cppPrevTx.isInitialized() (bug?)).
So my question is, what could be the cause of this? Just corruption, or something I'm missing in the code?
For good measure, I blew away the armory "database" dir and restarted armory_utxsvr.py, which rebuilt it (happens much quicker now it seems). Still no luck. The next step would be a bitcoind reindex? I was also going to try it on another box, and am downloading the blockchain now....
Thanks for any help.
Jump to: