Thankfully those two duplicated transactions were never spent when they first
appeared. Because of that, I chose to not not add them to the UTXO at all when
they first appear. When the duplicates appear they get added to the UTXO
successfully because the earlier, conflicting versions are not pre
I’m also running into this exact same issue with my parser, now I understand
why the relay field behavior I was seeing doesn’tmatch the wiki.
So to parse a version message, you can’t rely on the protocol version? You have
to know how long the payload is, and then parse the message accordingly?
I hope I'm not thread-jacking here, apologies if so, but that's the approach
I've taken with the node I'm working on.
Headers can be downloaded and stored in any order, it'll make sense of what the
winning chain is. Blocks don't need to be downloaded in any particular order
and they don't need t
ion is
added to be a block, then proof could be provided for the bad transaction.
The only slightly difficult thing is confirming inflation. That can be checked
on a block by block basis when downloading the entire block chain.
> Regards,
> Tamas Blummer
> http://bitsofproof.co
I haven't done the math on this, so it may be a terrible idea. :)
I've been wondering if block propagation times could also be improved by
allowing peers to request the list of transaction hashes that make up a block,
and then making a follow-up request to only download any transactions not
curr
5 matches
Mail list logo
