8

I've created a regtest network consisting of 2 nodes - node0 & node1.
I'd like to have a fork on the common blockchain and seemingly achieved it by doing so:

  1. nodes start
  2. node0 adds node1 via addnode
  3. node0 generates 1 block with hash 4dac...
  4. node1 generates 1 block with hash 5d8b...
  5. node0 invalidates node0's block with hash 5d8b... via invalidate <hash>
  6. node1 stops
  7. node0 generates 1 block with hash 64f2...
  8. node1 restarts
  9. node1 generates 1 block with hash 5sfg...
  10. node0: getchaintips returns an array with invalidated block's hash 5d8b... with status

Now my questions:
 a) How can I achieve a "valid-fork" status in the output of getchaintips for the previously invalidated fork? [SOLVED]

b) Is it possible for a node to "conciously"/via RPC give up its own chain and switch to the competing chain?

Improve this question
2
  • 1
    Did you had a look at: github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/…? – Jonas Schnelli May 11 '15 at 12:38
  • @JonasSchnelli: Yes i looked at that code but didn't understand much since I'm not familiar with python..but one difference is there between my scenario and the scenario described inside the code: I have subbranches of same lengths and the code describes branches of different lengths..is this the key point? – Aliakbar Ahmadi May 14 '15 at 10:41
1

The longest valid chain is always chosen automatically. Thus the way to make it forcefully switch is using the invalidateblock hidden RPC.

Improve this answer
0

I re-read the Bitcoin Developer Guide and re-read the help getchaintips section:

Each full node in the Bitcoin network independently stores a block chain containing only blocks validated by that node. When several nodes all have the same blocks in their block chain, they are considered to be in consensus. The validation rules these nodes follow to maintain consensus are called consensus rules.

and

Possible values for status:
[..]
"valid-fork":This branch is not part of the active chain, but is fully validated
[..]

For a) So in order to achieve a valid-fork status for a previously invalidated block hash node0 needs to reconsider that very block hash in order to have it fully validated on its copy of blockchain. This can be achieved by reconsiderblock <block hash>.

Note:reconsiderblock apparently "closes" the fork since getchaintips returns the same block hash for the active chain tip for both nodes.

For b) Nothing found out yet.

Improve this answer
1
  • For b: invalidateblock RPC marks a block as unconditionally invalid. The reconsiderblock RPC wipes this invalid state. – Pieter Wuille Sep 5 '15 at 2:14
-1

Regarding a) I'm not really familiar how it validates the block, but my guess is no.

as for b) it is possible to give up its own chain of the other chain is the longest valid chain.

Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.

Improve this answer
2
  • For b) You quote "When the bitcoin client switches to another, longer chain, all [...]" - But my question is how one can conciously, e.g. as per a RPC, switch the chain!? – Aliakbar Ahmadi May 14 '15 at 14:27
  • The longest chain is always selected by the wallet software there is no RPC option to force a chain switch. – Mark S. Mar 2 '16 at 23:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.