Dealing with block reorgs

[cygnet3]

I'm wondering how clients to blindbit-oracle should deal with block reorgs.

I imagine clients need some kind of endpoint to get the block hash at a given height. Clients should remember the block hash of the last n blocks. Before scanning, they check if the hash of the last scanned block matches the hash given by the server. If not, they 'roll back' the changes in that block, and check the same for block n-1. Then n-2, et cetera.

I don't think n needs to be very big, since most reorgs are only of height 1.

[setavenger]

Thinking about this a bit, I'm not sure whether Oracle itself handles reorgs properly to begin with. Have you noticed anything?

The hashes are stored but are not exposed via any endpoint yet. I believe this could be easily done though. Another option would be to return the block hash and the previous block hash. Any thoughts?

[cygnet3]

I haven't really tested out reorgs, so I haven't checked if blindbit handles them properly internally.

I'm looking for stats on block reorgs. The only thing I found so far is this list, which shows that all reorgs over the last 4 years have been 1-block reorgs: https://learnmeabitcoin.com/technical/blockchain/chain-reorganization/

For Dana we'll probably only keep track of the block hash for the last block scanned. If that doesn't match, we'll just jump a 'safe' number of blocks back, say 5 blocks, and start scanning from there instead. For that we'd only need an endpoint that returns the block_hash at a height n

[setavenger]

#30

Does this PR suffice for your use-case?

[setavenger]

pinging @cygnet3

[cygnet3]

Sorry for the late response. I haven't tested it but the block-hash endpoint looks fine to me!