abpa 2017-01-12 06:46:23
I'm not sure that counts as invalid, but in order to know if it is longer or not it has to sync it
mod_cure 2017-01-12 06:46:37
does bitcoin remove the orphan block and but the new blocks on it from the longest fork chain or branch that fork and fetch all the blocks from longest fork chain?
abpa 2017-01-12 06:46:59
Bitcoin Core keeps around various branches so that it can figure out which is the best one
arubi 2017-01-12 06:47:00
mod_cure, https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages <- step 15 and on
piqure 2017-01-12 06:47:01
^^^ WARNING: any URL may lead directly or indirectly to COIN-STEALING MALWARE! ^^^
stoner19 2017-01-12 06:48:08
mod_cure = curecoin?
mod_cure 2017-01-12 06:49:37
abpa, when bitcoin creates a branch. does it have to fetch all the blocks(starting all over) from the longest chain?
abpa 2017-01-12 06:50:16
What does starting all over mean? Bitcoin Core never knows what will be the chain with the most work so it always has to have room for contenders
abpa 2017-01-12 06:51:00
There are some protections against trying to DOS by submitting very old and low work blocks
mod_cure 2017-01-12 06:52:38
abpa, block chain forks. what is chain reconvergence?
abpa 2017-01-12 06:52:56
I don't know, what does that mean?
mod_cure 2017-01-12 06:53:03
nm
arubi 2017-01-12 06:53:46
the question is literally step 15 in the wiki, and the answer is the steps that come after :P
mod_cure 2017-01-12 06:54:39
arubi, ok thanks
arubi 2017-01-12 06:55:12
mod_cure, sure. might wanna look at `bitcoin-cli getchaintips` for some cool info
mod_cure 2017-01-12 06:56:06
arubi, nice... just ran it
mod_cure 2017-01-12 06:56:37
i only have one. active.
arubi 2017-01-12 06:56:50
well.. that's the point right
arubi 2017-01-12 06:57:02
oh only one tip
arubi 2017-01-12 06:57:28
well, "stay a while and listen"
mod_cure 2017-01-12 06:58:36
arubi, how is a side branch created?
arubi 2017-01-12 06:59:24
a block builds on an inactive valid chain. it's inactive because it doesn't have enough work
mod_cure 2017-01-12 07:02:08
little lost on the branch and side chains. need to find some info. readying in my book about block chain fork.. the network reconverges on a new longest chain... does that mean 1 fork(not the longest chain - orphan block) creates a branch then start all over from nothing and copy all the block from the new fork longest chain?
arubi 2017-01-12 07:03:03
mod_cure, these different chains, active and inactive only differ from the oldest forked block onwards, and so it's easy to keep track of all inactive chains along with the active one (a few megebytes I guess) so when switching a chain it's only required to do some simple house cleaning
arubi 2017-01-12 07:04:06
there's no point in re-checking everything. sure the current utxo state is now wrong, but you don't need to check it all from the beginning, just roll back to what it was that many blocks ago, and rebuild it from there on to the newest block that you already validated
arubi 2017-01-12 07:05:09
you do have to keep tabs on roll back data. core does that
arubi 2017-01-12 07:05:45
I guess I understand why you ask this question, because if you don't keep tabs, it's not really possible to rebuild the utxo state from "a few blocks ago"
mod_cure 2017-01-12 07:09:23
arubi, ok. bare with me :) so lets say as of now.. I have the longest chain.. active chain... then 30 minutes goes and we have a block chain fork... my client realize i have an orphan block and my chain is no longer the longest chain...i take the orphan block(transactions) put them back in the pool memory(unconfirm transactions).. then i fetch parent block from the new fork to be in sync... where does branching inactive come into play her
mod_cure 2017-01-12 07:09:23
e ?
mod_cure 2017-01-12 07:09:48
s/here/here/
mod_cure 2017-01-12 07:09:51
s/her/here/
arubi 2017-01-12 07:10:51
well someone could still build on top of that orphan block
arubi 2017-01-12 07:11:21
and your current active chain tip might get orphaned itself in favor of the previous orphan's chain which is now longer
arubi 2017-01-12 07:11:43
you might have more than two competing chains, but one is active
raynold 2017-01-12 07:15:09
ahh it's a wonderful day
arubi 2017-01-12 07:15:31
it's pretty cold around here..
mod_cure 2017-01-12 07:23:54
arubi, i need to read up on branches. little puzzled.
arubi 2017-01-12 07:26:42
mod_cure, okay, but I think you're over complicating it if you think there's anything more to it than some process that happens completely locally in each node
arubi 2017-01-12 07:27:40
I'm think you're attributing some aspect of the network to what goes on when there's a fork, but I might be wrong
arubi 2017-01-12 07:28:30
the rules are simple to a fully verifying node to follow, and each node behaves the best it can with the information it receives from its peers
arubi 2017-01-12 07:28:42
s/verifying/validating
arubi 2017-01-12 07:30:04
so each node runs through the steps in the wiki when it receives some message about a block, and eventually the best chain wins if the network isn't segregated
mod_cure 2017-01-12 07:31:39
arubi, lets say i have active main chain(5 blocks)... two miners proof the solutions to the target hash.. half of the nodes receive block 'a' from miner a.. and the other hald of nodes receive block 'b' from miner b... the high is the same but wrong version... then miner 'b' win and send another block 'c'... my client has block 'a' and 'c' but not 'b'... my client needs to sync up with the new longest chain.. to me block 'c' is an orphan
mod_cure 2017-01-12 07:31:39
block.. where does brancing comeinto play here and how does my client sync up? put the orphan block 'c' in the memory pool and roll back block 'a' ? sorry
arubi 2017-01-12 07:32:43
your client does have b
arubi 2017-01-12 07:33:19
why wouldn't it? it's not like any nodes from the b group didn't tell you about it right?
arubi 2017-01-12 07:33:53
the branching is between a and b, like you said
arubi 2017-01-12 07:34:41
you have both to begin with, because you heard about both from your peers, now block c comes along and a re-org happens on your end and you roll back b, and go from a->c
arubi 2017-01-12 07:36:50
what I mean, before a and b branched, all nodes were connected between them. miner a connects to half and miner b connects to the other half and both broadcast different block #6, but the nodes still are all connected
arubi 2017-01-12 07:38:41
and nodes who got block b#6 would most definitely want to tell those who go a#6 about that block
arubi 2017-01-12 07:39:24
anyway, mod_cure , this is only an issue when you actually sync from scratch the first time
arubi 2017-01-12 07:41:35
I mean, deep chain forks at the tip are not very common
