You got so far into the the file (229714131 bytes) that it makes me think maybe the file itself is corrupt. Try blowing away namecoind data and download its blockchain again?
But conversely, you got it in the testnet as well, so that seems unlikely.
Topic: General questions arising when adding Namecoin support to Armory - page 3. (Read 5589 times)
November 11, 2014, 04:57:55 PM
November 11, 2014, 04:51:22 PM
I think I may have gotten in over my head with trying to add Namecoin support. I don't think I'm going to be able to finish the C++ parts (myself at least).
I hardcoded Namecoin as the network, because I couldn't figure out how to access the configuration data from within the detectAllBlkFiles method. As an aside, I made the variable a string, so that it can be used for future altcoin additions.
Now I get a bunch of errors like the following when building the db.
The merkle root calculation should be independent of the chain in use, so I don't think that is it. The dat file should be parsable. So I don't understand what caused the error.
FWIW, I get these errors with Namecoin and Namecoin Testnet.
I'll look more into it when I have time later, but I just wanted to post where I'm at now, in case anyone has any tips.
I hardcoded Namecoin as the network, because I couldn't figure out how to access the configuration data from within the detectAllBlkFiles method. As an aside, I made the variable a string, so that it can be used for future altcoin additions.
Now I get a bunch of errors like the following when building the db.
Code:
-ERROR - 1415733082: (StoredBlockObj.cpp:332) Merkle root mismatch! Raw block data is corrupt!
-ERROR - 1415733082: (BlockUtils.cpp:315) Error parsing block (corrupt?) - block header valid (hash=faa064f45e4bec7b52b83f78517d632fe43d6064afd8d55587e202a56c70a633) (error encountered processing block at byte 229714131 file /home/joseph/.namecoin/testnet/blk0001.dat, blocksize 666)
-ERROR - 1415733082: (BlockUtils.cpp:315) Error parsing block (corrupt?) - block header valid (hash=faa064f45e4bec7b52b83f78517d632fe43d6064afd8d55587e202a56c70a633) (error encountered processing block at byte 229714131 file /home/joseph/.namecoin/testnet/blk0001.dat, blocksize 666)
The merkle root calculation should be independent of the chain in use, so I don't think that is it. The dat file should be parsable. So I don't understand what caused the error.
FWIW, I get these errors with Namecoin and Namecoin Testnet.
I'll look more into it when I have time later, but I just wanted to post where I'm at now, in case anyone has any tips.
November 11, 2014, 12:41:46 PM
You cannot get an instance of BlockDataManager_LevelDB from anywhere, anymore. But anywhere that calls getBlkFilename has an instance of BlockDataManagerConfig available.
I recommend you put a boolean in in BlockDataManagerConfig that sets things to namecoin mode, and then check that boolean wherever getBlkFilename is called, and maybe write a new function, or use etotheipi's old version and modify its parameters based on that.
I recommend you put a boolean in in BlockDataManagerConfig that sets things to namecoin mode, and then check that boolean wherever getBlkFilename is called, and maybe write a new function, or use etotheipi's old version and modify its parameters based on that.
November 11, 2014, 10:03:16 AM
First of all, yes I am developing against the dev branch. When I am done, I plan on stashing my changes, bringing dev up-to-date, reapplying my changes, and making a git diff to email.
Looking at BlockDataManagerConfig and BDM.py, I see that the Python code passes the magic bytes to the C++ code. So I think the best way to do what I want to do is by checking the magic bytes.
The comments in cppForSwig/BlockUtils.h reference a GetInstance() method. I don't see any GetInstance() method, so I assume it was removed? How would I safely get an instance of BlockDataManager_LevelDB? I think I want an instance of BlockDataManager_LevelDB, because that class has getMagicBytes().
Looking at BlockDataManagerConfig and BDM.py, I see that the Python code passes the magic bytes to the C++ code. So I think the best way to do what I want to do is by checking the magic bytes.
The comments in cppForSwig/BlockUtils.h reference a GetInstance() method. I don't see any GetInstance() method, so I assume it was removed? How would I safely get an instance of BlockDataManager_LevelDB? I think I want an instance of BlockDataManager_LevelDB, because that class has getMagicBytes().
November 11, 2014, 12:30:40 AM
FYI, here's the old transitional code for the same method:
https://github.com/etotheipi/BitcoinArmory/blob/v0.88-beta/cppForSwig/BtcUtils.h#L736
And as njaard said: you don't access python from C++. If you need something, put it in the C++ side, and call it from python. SWIG is amazing (being able to call C++ objects and methods as if they're native python objects), but it doesn't go both ways, and in fact it can get quite complicated to do so.
https://github.com/etotheipi/BitcoinArmory/blob/v0.88-beta/cppForSwig/BtcUtils.h#L736
And as njaard said: you don't access python from C++. If you need something, put it in the C++ side, and call it from python. SWIG is amazing (being able to call C++ objects and methods as if they're native python objects), but it doesn't go both ways, and in fact it can get quite complicated to do so.
November 10, 2014, 11:13:13 PM
Hi Joseph,
The short answer is "you don't". The useful answer is that Armory loads the C++ side from BDM.py. There it creates a BlockDataManagerConfig object. When you create a BlockDataManagerConfig, you could specify parameters there that affect the C++ side's behavior, like the file format convention for blk files.
You're developing against the "dev" branch, right? You should.
The short answer is "you don't". The useful answer is that Armory loads the C++ side from BDM.py. There it creates a BlockDataManagerConfig object. When you create a BlockDataManagerConfig, you could specify parameters there that affect the C++ side's behavior, like the file format convention for blk files.
You're developing against the "dev" branch, right? You should.
November 10, 2014, 10:13:35 PM
So I am working on adding Namecoin support to Armory.
I think that I got a lot of the work done already. My issue is that Namecoin is based off of an old version of Bitcoin. Therefore it uses block files like ~/.namecoin/blk0001.dat instead of ~/.bitcoin/blocks/blk00000.dat, which is used by modern Bitcoin clients. Armory is currently designed to look for blocks of the latter naming convention.
What I want to do is modify the C++ code to find the Namecoin blocks when the --namecoin flag is set and to find Bitcoin blocks when there is no --namecoin flag. I've figured out that I want to modify the getBlkFilename function in cppForSwig/BtcUtils.h. The problem is I need to do so based on a variable called COIN in armoryengine/ArmoryUtils.py (it's not in the GitHub repo, just in my local repo). The variable COIN will either be the string 'Namecoin' or the string 'Bitcoin' based on flags set when running Armory.
So my question is how would I go about accessing COIN from BtcUtils.h? Or is there some other way to determine the network in use that I am missing?
I think that I got a lot of the work done already. My issue is that Namecoin is based off of an old version of Bitcoin. Therefore it uses block files like ~/.namecoin/blk0001.dat instead of ~/.bitcoin/blocks/blk00000.dat, which is used by modern Bitcoin clients. Armory is currently designed to look for blocks of the latter naming convention.
What I want to do is modify the C++ code to find the Namecoin blocks when the --namecoin flag is set and to find Bitcoin blocks when there is no --namecoin flag. I've figured out that I want to modify the getBlkFilename function in cppForSwig/BtcUtils.h. The problem is I need to do so based on a variable called COIN in armoryengine/ArmoryUtils.py (it's not in the GitHub repo, just in my local repo). The variable COIN will either be the string 'Namecoin' or the string 'Bitcoin' based on flags set when running Armory.
So my question is how would I go about accessing COIN from BtcUtils.h? Or is there some other way to determine the network in use that I am missing?
Jump to: