Author

Topic: How exactly are forks resolved in bitcoin? (Read 265 times)

legendary
Activity: 1135
Merit: 1166
November 10, 2018, 02:37:04 PM
#5
Your description is correct - the UTXO set is reverted to the previous state and then updated for the blocks in the new chain branch.  Reverting is done by means of "undo data" that is stored along each block by Bitcoin Core - and that keeps all the information necessary to revert changes made (e.g. outputs that have been spent in the block and were thus removed from the UTXO set, so that they can be added back in).
Actually there is no need to any "undo" data, the block which has to be thrown out of the main chain holds all of the data necessary for undo: its transactions have spent utxos as inputs which are the rows to be added (again) and their outputs are the rows to be removed, given the reorg process is happening reasonably in a bottom-up fashion.

That's unfortunately not true.  While the spending transaction contains the txid and vout of the spent output, it does not contain all data that the UTXO set holds - notably missing are the scriptPubKey and amount, among other things.  Those could be looked up in the block that created the output, but that one might already be pruned and the lookup would be inefficient.  Because of that, these pieces of data are stored by Bitcoin Core in undo data.
legendary
Activity: 1456
Merit: 1175
Always remember the cause!
November 07, 2018, 03:42:16 PM
#4
Your description is correct - the UTXO set is reverted to the previous state and then updated for the blocks in the new chain branch.  Reverting is done by means of "undo data" that is stored along each block by Bitcoin Core - and that keeps all the information necessary to revert changes made (e.g. outputs that have been spent in the block and were thus removed from the UTXO set, so that they can be added back in).
Actually there is no need to any "undo" data, the block which has to be thrown out of the main chain holds all of the data necessary for undo: its transactions have spent utxos as inputs which are the rows to be added (again) and their outputs are the rows to be removed, given the reorg process is happening reasonably in a bottom-up fashion.
member
Activity: 183
Merit: 25
November 05, 2018, 06:30:17 PM
#3
Your description is correct - the UTXO set is reverted to the previous state and then updated for the blocks in the new chain branch.  Reverting is done by means of "undo data" that is stored along each block by Bitcoin Core - and that keeps all the information necessary to revert changes made (e.g. outputs that have been spent in the block and were thus removed from the UTXO set, so that they can be added back in).

Oh i see its quite an obvious answer  Roll Eyes. thanks
legendary
Activity: 1135
Merit: 1166
November 05, 2018, 01:58:20 PM
#2
Your description is correct - the UTXO set is reverted to the previous state and then updated for the blocks in the new chain branch.  Reverting is done by means of "undo data" that is stored along each block by Bitcoin Core - and that keeps all the information necessary to revert changes made (e.g. outputs that have been spent in the block and were thus removed from the UTXO set, so that they can be added back in).
member
Activity: 183
Merit: 25
November 05, 2018, 01:28:30 PM
#1
so say there is one block 1500. the next block published is 1501_a. but at the same time another block is published 1501_b.
a node recieves 1501_a first and stores it as the main chain. but the next block is actually mined on top of 1502_b.

so now the node has to revert any changes made with block 1501_a. and change it so that it never happened but was instead 1501_b and then 1502_b.

how does the node revert the changes exactly?

the only thing i can think that has to be changed are, the utxo set would need to be edited to go back to 1500. and then 1501_b, 1502_b.
and the last block hash has to be changed to 1502_b as well as deleting 1501_b.

but how is the utxo set reverted? it means that utxos that were spent and deleted from the db after block 1502_a was processed, will have to some how be recovered again. how is this done?
Jump to: