Boog900

I think it's good to go but I can change anything if needed @h4sh3d

some transactions with the MergeMining seem to not have depth stored and only have the merkle_root. This means the current system will de-serialize them but will incorrectly put the size...

I have scanned every [pruned transaction](https://github.com/Boog900/monero-rs/blob/3e1ed9b7a458bed7c9e5d38b3775da0b26ad797e/src/database_types/transaction.rs#L33) up to block 2511915 using these changes and these are the only transactions where the extra field isn't fully parsed: // Error parsing tx-extra:...

This could be because of how txs are relayed. When we receive txs in the fluff stage, we add them to our fluff queue and set a timer on each...

> The txpool reached around 100MB, but those transactions got propagated over the time of like an hour, they didn't get submitted all at once. Ah ok, transactions are periodically...

> The txpool was empty again after around 12h, would you hat cause re-broadcasts? sorry, I don't know what you mean. > Also any ideas to improve efficiency here? Yes,...

> I wanted to ask if transactions are typically re-broadcasted within the first 12h of being in the txpool, because that's usually the timeframe of the txpool clearing up again....

I have scanned the blockchain up to 2769971 and here are some more transaction where the extra field is not fully parsed : // Error parsing tx-extra: 0x68de…09a3, height: 1761365...

@vorot93 yeah good point, I think I might add some methods on the extra field to build from bytes and to build from sub fields to make it easier for...

> I should also mention this does mean in unlucky cases where a blackhole occurs after just one hop, could result in longer delays than with a poisson distribution This...