Quote from: ranochigo on November 14, 2019, 01:43:27 PM

Quote from: Sohyun Park on November 14, 2019, 01:11:21 PM

Quote from: pireff on November 09, 2019, 08:06:47 PM

it's running quite fast actually, but i need an explanation on how exactly i can detect orphans, and mark them as so.

Yes, it is running fast but, why do you wan to detect is as you can see last 2 years there are zero orphan blocks mined. You can check all the details of the orphan block in the link below:
https://www.blockchain.com/charts/n-orphaned-blocks?timespan=all

Also, here are all the blocks that are "mined but ultimately not attached to the main Bitcoin blockchain".
https://api.blockchain.info/charts/n-orphaned-blocks?timespan=all&scale=1&format=json

That's wrong. Orphan blocks still occur once in a while but they are less common with the better connection between the mining pools. Mining pools are often listening directly to each other and thus it is less likely for orphans to occur. It was more common in the past whereby the propagation of the network was much slower.

True, I first thought to exclude them from the main explorer chain, but still preserve them, to show as an additional feature, kinda of what blockchain.info does. But, as you said, when syncing the bitcoin client receives no orphan blocks, so I will either need a very long running daemon, or some kind of patch on the current source. So I finally decided to just exclude them.

I see that happening the following way. I'm currently syncing at 0.5 sec intervals, so after every sync I check 101 blocks behind. If confirmations parameter returned by the daemon is -1, i'm removing all blocks ahead and the current one, reverting all transactions and addresses, and resyncing.

In my above strategy, I'm assuming that forks of orphans beyond 101 blocks will not happen, atleast not practically. If that's not the correct way to do that, I accept constructive criticism.

pireff

Posts

Merits