Bitcoind confirmations during fork

Question

I'm using bitcoind's JSONRPC interface to get transaction information for my wallet, specifically, I'm running a little script every time a block gets broadcast (using -blocknotify) which calls the getrawtransaction method to get the parsed raw transaction.

Among the fields returned by getrawtransaction we have confirmations, but what does this field contain during a fork? Ie. if one were to call the getrawtransaction method when there are two "current" blocks, what would this field contain? (bare in mind that in case of a fork, one of the two "current" blocks may include a transaction while the other may not).

Answer 1

All of the information provided by Bitcoin Core applies only to the chain it currently thinks is the best block chain. Any blocks which are not part of that chain are not counted towards the confirmation score.

If you're using Bitcoin Core in a merchant application, you should probably test what happens during various-length forks. You can do this using the regression test (regtest) mode. For example (I haven't tested this):

nodeA_options="-regtest -rpcpassword=foo"
nodeB_options="-regtest -rpcpassword=foo -datadir=/tmp/regtest -port=9999 -rpcport=10000"

## start node A
bitcoind -daemon $nodeA_options

## Create a block to get its coinbase in your wallet (unspendable for 100 blocks)
bitcoin-cli $nodeA_options setgenerate true 1

## start node B and connect it to node A; it'll sync the block
bitcoind -daemon $nodeB_options -connect=localhost

## stop node A to break the connection
bitcoin-cli $nodeA_options stop

## generate a block on node B
bitcoin-cli $nodeB_options setgenerate true 1

## Restart node A and generate a block
bitcoind -daemon $nodeA_options
bitcoin-cli $nodeA_options setgenerate true 1

## Stop and restart node B with a connection to node A
## At this point, both nodes have a different block #2 so you can see
##   what a fork looks like to the nodes
bitcoin-cli $nodeB_options stop
bitcoind -daemon $nodeB_options -connect=localhost

Of particular use, you will probably want to set the -alertnotify command, which can warn you about longer forks and allow you to automatically shutdown your payment processing system until the fork is resolved or you intervene manually. You may also want to look at the listsinceblock RPC which can work in conjunction with -blocknotify to tell you what's changed in the most recently-accepted block.

Answer 2

if one were to call the getrawtransaction method when there are two "current" blocks, what would this field contain? (bear in mind that in case of a fork, one of the two "current" blocks may include a transaction while the other may not).

Essentially, your client does a tiebreaker to figure out which one it will consider real. The block that arrived first wins.

The important part about this is that different nodes on the network might have seen the blocks in a different order.

This is why confirmations don't necessarily go up over time.