soapboxfork / OmbudsCore

Resilient digital speech on the blockchain and on your laptop.
https://getombuds.org
GNU General Public License v3.0
6 stars 0 forks source link

[ombfullnode] Fails to resolve long chain reorganizations #3

Closed NSkelsey closed 9 years ago

NSkelsey commented 9 years ago

This can be demonstrated with the following sql command on the block table in Trisong's Testnet data.

select * from blocks where height < 0;

This is caused by the pubrecmanager pushing blocks into the pubrecord that have a blk height set to -1, which is the default value when no height is provided. The issue lies in how the blockmanager and pubrecmanager interact. Specifically, the block manager always pushed the block to the pubrecmanager even if the block we are lookng at is already stored in the chain here. If this was really the case though, it would seem that the block would be written over the next time it comes through the chain manager.

Specifically when the chain manager sees the block a second time it records it while the precmanager fails.

17:51:43 2015-07-11 [ERR] PREC: Failed to store blk sqlite3: column hash is not unique [2067]
17:51:43 2015-07-11 [INF] CHAN: Adding orphan block 0000000000232314840923226cbee849819f7b2aeb77d406dd787981242a2560 with parent 00000000009250e029e25e64fd97692d146978a002ce0e24555ba10b48222576

In Godeps/_workspace/src/github.com/btcsuite/btcd/blockchain/process.go on line 194, we find btcd's handling of orphaned blocks (IE they are just pushed into the db.)

In our case though, we would rather just write over the block in the record with the correct height.

NSkelsey commented 9 years ago

Using an UPSERT in the pubrecdb should fix this problem. 65bf adds this change.