Bitcoin Forum
March 29, 2024, 12:12:17 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [PATCH] Automatic block validation  (Read 8245 times)
bdonlan (OP)
Full Member
***
Offline Offline

Activity: 221
Merit: 102


View Profile
August 16, 2010, 02:57:55 AM
 #1

I've written a patch to help automatically validate cached blocks after validation fixes such as the one that was pushed out today. You can find it at

http://fushizen.net/~bd/blockverify.patch

or

http://github.com/bdonlan/bitcoin/commit/b205251959448ca99123f2bc95b088bf06d4ef3b

Upon first run with this patch, all blocks will be verified, and any invalid blocks, as well as blocks orphaned by removal of such blocks, will be removed from the block index. A version stamp
(BLOCK_VERIFY_TOKEN in db.cpp) will be then written to the db; this will cause the next run to skip the verification pass. Any future validation fixes can then simply bump BLOCK_VERIFY_TOKEN to force a revalidation of the block chain.

Note that I may be missing some important steps when deleting the old blocks - in particular, no attempt is made to update the wallet, or to prune stored uncommitted transactions. Review would be helpful.
1711671137
Hero Member
*
Offline Offline

Posts: 1711671137

View Profile Personal Message (Offline)

Ignore
1711671137
Reply with quote  #2

1711671137
Report to moderator
1711671137
Hero Member
*
Offline Offline

Posts: 1711671137

View Profile Personal Message (Offline)

Ignore
1711671137
Reply with quote  #2

1711671137
Report to moderator
You can see the statistics of your reports to moderators on the "Report to moderator" pages.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
bdonlan (OP)
Full Member
***
Offline Offline

Activity: 221
Merit: 102


View Profile
August 16, 2010, 04:33:10 AM
 #2

Hmm, it seems I am missing something important - disconnecting transactions which are no longer part of the accepted block chain. I'm going to have to work on this a bit - the naive approach of simply blasting away all TXNs, then reconnecting things is far too slow, and hits the transaction memory limit.
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 6611


View Profile
August 16, 2010, 03:25:54 PM
Last edit: August 16, 2010, 08:06:58 PM by satoshi
 #3

That's a difficult approach.

We need to cause a reorg, which will disconnect the invalid chain.

This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best.

Here's what I was thinking of.  (I haven't tested this yet)  It checks all the blocks in the main chain.  If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg.  (It can't change pindexBest without actually doing a reorg)

This isn't perfect yet.  It still needs to receive one valid block to trigger the reorg.  

It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention.  I probably should break out part of AddToBlockIndex that sets the new best block.  I'll probably end up doing that instead of the code below.

Code:
bool CTxDB::LoadBlockIndex()
{
    ...

    // Verify blocks in the main chain
    vector<CBlockIndex*> vChain;
    for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
    {
        vChain.push_back(pindex);
        CBlock block;
        if (!block.ReadFromDisk(pindex))
            return error("LoadBlockIndex() : block.ReadFromDisk failed");
        if (!block.CheckBlock())
        {
            bnBestChainWork = pindex->pprev->bnChainWork;
            foreach(CBlockIndex* pindex2, vChain)
                pindex2->bnChainWork = 0;
        }
    }

    return true;
}
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 6611


View Profile
August 16, 2010, 05:08:02 PM
Last edit: August 16, 2010, 06:50:13 PM by satoshi
 #4

It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention.  I probably should break out part of AddToBlockIndex that sets the new best block.  I'll probably end up doing that instead of the code below.
This is what I ended up doing in SVN rev 139.

Instead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!