Currently transactions are stored in reversed order if they belong to the same block, which can result in holes in history when pruning.
For example, consider a transaction chain A->B->C->D, where A,B,C belong to the same block, and D to the next block. It's stored in the history as C,B,A,D. So when C is pruned first, we have B,A,D in history, which results in incorrect balance calculations, because both A and D are considered to come from pruned outputs.
Storing transactions in A,B,C,D order, and then pruning A first, correctly results in only B being considered as coming from pruned output.
for i in range(l-1, -1, -1):
item = serialized_hist[80*i:80*(i+1)]
item_height = int(rev_hex(item[36:39].encode('hex')), 16)
- if item_height < tx_height:
+ if item_height <= tx_height:
serialized_hist = serialized_hist[0:80*(i+1)] + s + serialized_hist[80*(i+1):]
break
else: