there is a flaw in the test case logic that needs to be addressed. Currently it runs through parse_stamp and parse_src20 logic independently. while iin the typical codebase flow these are processed serially with parse_src20 relying on the output data from parse_stamp. There is also loads of edge cases in there with zlib compressed versions, and a need to process real tx_hashes all the way through blocks.py to validate things on the actual trx decoding. There are things in blocks that need to be adjusted irt strings vs bytestrings that gets annoying later on both in parse_stamp and parse_src that requires flipping between data types all the time and creates confusion. There is a variance in SRC-20 vs CP transaction among other things.
Reference issues:
https://github.com/stampchain-io/btc_stamps/issues/252
https://github.com/stampchain-io/btc_stamps/issues/257
there is a flaw in the test case logic that needs to be addressed. Currently it runs through parse_stamp and parse_src20 logic independently. while iin the typical codebase flow these are processed serially with parse_src20 relying on the output data from parse_stamp. There is also loads of edge cases in there with zlib compressed versions, and a need to process real tx_hashes all the way through blocks.py to validate things on the actual trx decoding. There are things in blocks that need to be adjusted irt strings vs bytestrings that gets annoying later on both in parse_stamp and parse_src that requires flipping between data types all the time and creates confusion. There is a variance in SRC-20 vs CP transaction among other things.