I'd like to know also. I don't think you can query orphan blocks. I wonder about bitcoin core, when it encounters a fork does it lead to a blocknotify callback starting with a common ancestor, and all the way up to the latest? Or just the latest block.
Topic: Effect of orphan blocks on bitcoin wallet API (Read 2160 times)
ping.
Does anybody know the answer?
Does anybody know the answer?
When a couple of blocks are orphaned, I assume the following will happen.
Can someone verify this is correct? (Kind'a difficult to test).
Let's say there is a two-block fork:
291873
^
|
291872
^
|
291871 291871
^ ^
| |
291870 291870
^ ^
| /
291869
^
|
291868
And the bitcoin wallet went down the right-hand-side (incorrect) fork until 291872, and then jumped back. It's behavior would be:
a) Prior to orphaning, getblockhash returns one set of hashes for the blocks at that height:
getblockhash 291869
00000000000000004674e91dd6efeac7255d1de13fadc55261241dcb6d8397b5
getblockhash 291870
0000000000000000e8033afc5dfad298a95c73cbe7bc11186c7544460c007fde
getblockhash 291871
000000000000000079557def76dddcd2c93da1b66c4371a714223bdb6c5d7ae4
b) Once the orphan chain is detected and resolved, those block heights values will now map to different hashes. E.g.:
getblockhash 291869
00000000000000004674e91dd6efeac7255d1de13fadc55261241dcb6d8397b5 // still the same
getblockhash 291870
0000000000000000419cfd8ed2fc0e919c1cdb20f4fb009a4a19fdd7a20d5961 // new hash
getblockhash 291871
0000000000000000a2185dc7779f93831925909cb489e8e7a9d007beee0cc619 // new hash
and after this point, life will be good again. getblockhash 291872 will return the new valid hash from the main chain etc.
c) The previous hashes will still be usable to retrieve the orphaned block information directly (e.g. through getblock), but getblockhash will return a different block at that height.
d) Since the wallet jumped back to the main chain, there is no other way to enumerate these orphaned chains again unless you kept track of it while it was happening and scribbled away their hashes.
Can someone verify this is correct? (Kind'a difficult to test).
Let's say there is a two-block fork:
291873
^
|
291872
^
|
291871 291871
^ ^
| |
291870 291870
^ ^
| /
291869
^
|
291868
And the bitcoin wallet went down the right-hand-side (incorrect) fork until 291872, and then jumped back. It's behavior would be:
a) Prior to orphaning, getblockhash returns one set of hashes for the blocks at that height:
getblockhash 291869
00000000000000004674e91dd6efeac7255d1de13fadc55261241dcb6d8397b5
getblockhash 291870
0000000000000000e8033afc5dfad298a95c73cbe7bc11186c7544460c007fde
getblockhash 291871
000000000000000079557def76dddcd2c93da1b66c4371a714223bdb6c5d7ae4
b) Once the orphan chain is detected and resolved, those block heights values will now map to different hashes. E.g.:
getblockhash 291869
00000000000000004674e91dd6efeac7255d1de13fadc55261241dcb6d8397b5 // still the same
getblockhash 291870
0000000000000000419cfd8ed2fc0e919c1cdb20f4fb009a4a19fdd7a20d5961 // new hash
getblockhash 291871
0000000000000000a2185dc7779f93831925909cb489e8e7a9d007beee0cc619 // new hash
and after this point, life will be good again. getblockhash 291872 will return the new valid hash from the main chain etc.
c) The previous hashes will still be usable to retrieve the orphaned block information directly (e.g. through getblock), but getblockhash will return a different block at that height.
d) Since the wallet jumped back to the main chain, there is no other way to enumerate these orphaned chains again unless you kept track of it while it was happening and scribbled away their hashes.
Jump to: