Can DeserializationValueBoundsError be triggered by a valid tx? about python-bitcointx HOT 6 CLOSED

The user was kind enough to give me the evidence, I can now see that the error is in Joinmarket code; the transaction being deserialized contained marker bytes (which are not actually a valid part of a transaction), which aren't valid. So, closing. Sorry for the trouble.

from python-bitcointx.

The exception happens here:

This corresponds to the following code in Bitcoin Core: https://github.com/bitcoin/bitcoin/blob/409afd715351592a00ad5a0e5400858f6e734eef/src/serialize.h#L344-L346

It is possible that in some places the decoding calls ReadCompactSize with range_check = false, but bitcointx does not call deserialize with allow_full_range = True in the same case (edit: no, this only happens in case that is not relevant to tx decoding)

Needs investigation.

from python-bitcointx.

The ability to skip this check was added to ReadCompactSize in October: bitcoin/bitcoin@1d3ec2a, the code in bitcointx is of course based on older code (edit: even if it enables skipping the check with allow_full_range=True, this is only used in PSBT code)

from python-bitcointx.

But the relaxation of this check only happens when processing ADDRV2_FORMAT for BIP155, so should not matter for transaction decoding.

The python code for the compact size deserialization seems to be corresponding to the C++ code, so I'd say the problem is somewhere in the other part of data.

If the user has the transaction hex data, maybe good idea could be to ask them to try decoderawtransaction RPC of Core to check if it is really correct

from python-bitcointx.

I agree that it is certainly far more likely to be an error outside this library, feeding in invalid transaction data. But I thought asking the question in abstract is certainly worthwhile, as if such a thing were possible, I'd certainly need to know about it.

Thanks for looking into it!

from python-bitcointx.

I think we cannot fully exclude the possibility that the problem is in the lib, because the problem might be in incorrect deserialization code before the execution got to this compact integer deserialization. But without looking at data that caused the problem, it would be hard to search for the error - would need to audit almost all of serialization code just hoping to spot the (possibly non-existent) error. If we could have at least some definitive result (even without having the data at hand), like "there exists a hex string that is parsed successfully by decoderawtransaction, but gives this error when parsed with bitcointx", then putting extra scrunity on bitcointx deserialization code might be justified

from python-bitcointx.