Author

Topic: Orphaned blocks detection (Read 234 times)

newbie
Activity: 4
Merit: 0
November 17, 2019, 03:33:53 AM
#6
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.
legendary
Activity: 2909
Merit: 1308
November 14, 2019, 01:35:27 PM
#5
The orphan blocks are stored within the Bitcoin database. Parse the database and you should be able to sieve them out.
only when your Node receives this block while running.
if you download the database from another node that only the valid blocks are transferred

correct me if I'm wrong.
legendary
Activity: 2982
Merit: 4193
November 14, 2019, 09:43:27 AM
#4
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.
member
Activity: 103
Merit: 10
November 14, 2019, 09:11:21 AM
#3
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
legendary
Activity: 2982
Merit: 4193
November 09, 2019, 11:45:01 PM
#2
Hello Bitcointalk members, as it's apparent from the title, i need a reliable way to detect orphan blocks. I wrote a custom explorer, and it's running quite fast actually, but i need an explanation on how exactly i can detect orphans, and mark them as so.
In normal circumstances, orphan occurs when block A and B are produced at the same time and that a portion of the network is building on Block A and the other is building on Block B. The miners will compete with each other until either of the sides find a block. This further extends the network and thus one of the forks now have a larger accumulated proof of work. The longer fork will supersede the shorter one. The problem with this is that nodes won't register (AFAIK) block B after they've received block A. Hence, you would need to have a very good connection to the network and a modified client to see all of the orphans that is on the network.
What the longest chain fork due to orphan blocks is?
IIRC, the longest fork I've seen was during the 2013 hard fork and that lasted >30 blocks. Normally, the orphans should not go beyond 6 blocks.
If on every block sync, i check the last 1000 blocks, is that enough to assume that every block beyond these 1000 is NOT an orphan?
Is the -1 confirmations the only way to detect them?
The orphan blocks are stored within the Bitcoin database. Parse the database and you should be able to sieve them out.
newbie
Activity: 4
Merit: 0
November 09, 2019, 04:06:47 PM
#1
Hello Bitcointalk members, as it's apparent from the title, i need a reliable way to detect orphan blocks. I wrote a custom explorer, and it's running quite fast actually, but i need an explanation on how exactly i can detect orphans, and mark them as so.

What the longest chain fork due to orphan blocks is?
If on every block sync, i check the last 1000 blocks, is that enough to assume that every block beyond these 1000 is NOT an orphan?
Is the -1 confirmations the only way to detect them?

Admins, if this post is not for this board/section, feel free to move it
Jump to: