Alright, I've got a test version up here:
https://github.com/nixed18/combfulluiA release is available to be downloaded, or people can build it themselves.
For simplicity I'm gonna refer to the normal version as legacycomb and the test version as mergedcomb
BuildDo the same steps as the normal combfullui (
https://bitcointalksearch.org/topic/m.54605575) but with two differences:
1. Make sure you don't install in the same folder as your normal combfullui; after cd Documents, type in mkdir combfullui_rpctest, then type in cd combfullui_rpctest
2. Type in "go get github.com/syndtr/goleveldb/leveldb" to install LevelDB
Set up bitcoin.conf1. Navigate to the directory where you have stored your BTC blockchain. By default it is stored in C:\Users\YourUserName\Appdata\Roaming\Bitcoin on Windows. You'll know you're there when you see blocks and chainstate folders, along with some .dat files for stuff like the mempool, peers, etc.
2. Look for a file named "bitcoin.conf". If one doesn't exist, make one by right clicking the whitespace and going New>TextFile. Then rename this file to "bitcoin.conf"
3. Open "bitcoin.conf" in Notepad and add the following two entries, replacing XXXXX with what you want your log info to be. This is only used to your BTC node.
rpcuser=XXXXX
rpcpassword=XXXXX
4. Save and exit
Set up config.txt1. Navigate to the directory you installed mergedcomb
2. Create a text file called "config.txt". Launching the program will automatically create this file if you don't.
3. Open "config.txt" in Notepad, and add the following lines, replacing the XXXXX with the same values that you used in your "bitcoin.conf".
btcuser=XXXXX
btcpass=XXXXX
4. Save and exit. If mergedcomb was open during this edit, you must restart the program for your changes to take effect.
Note: There are two further options that you can use in the config: "btcmode=" and "port=". The only valid value for "btcmode=" is "regtest", any other entry will result in a normal boot. "port=" sets the port that the mergedcomb listens on, set it to a normal number lol I haven't made the proper processing for it to reject letters yet.RunAssuming you're using an unmodded BTC, you can run either the BTC or the mergedcomb first, it doesn't matter. While the mergedcomb is running, it'll keep checking if there's a BTC server running on your machine, and if so, will attempt to connect with it. When you run BTC,
either run bitcoind.exe OR run bitcoin-qt.exe with "-server" as an argument.AFAIK this version is compatible with any recent BTC build. It is also compatible with the Modded BTC, however you either must run it in tandem with legacycomb, or modify mergedcomb's port to be 2121. The Modded BTC must be able to communicate with a Haircomb client to start. The default port for mergedcomb is 3232 btw.
Merged comb should begin mining automatically, assuming that the BTC chain is up to date. BTC's RPC doesn't like to respond to queries while it's validating blocks, mining progress may be slow or non-existent before the BTC chain is all caught up.
NotesThis is essentially a proof of structure, so approach it as such. There's more to do, listed below, but it makes sense to finalize the structure before refining anything.
A brief overview:
Mining: Mergedcomb pings BTC until it is told there's a change in the chain, mergedcomb then sets up a mining config with the start height, target height, and direction (mine or unmine), and begins pulling blocks. Block info is funneled through the miner, which first mines all the commits in the next block, which is done by triggering miner_mine_commits_internal() as usual. Then once all the commits have been stored, the miner stores the block hash under the key 99999999 CAT blockheight. If unmining, the miner REMOVES the hash first, then begins unmining the commits. This ordering should minimize the possibility of incorrect block content while also storing the hash. This is important for DB cleaning, which happens on load.
Loading: Mergedcomb iterates through every entry in levelDB. Entries are stored in numerical ordering, which is convenient. First, check that the commit entry belongs to a block who's hash has been stored. If it has, move it to an array for said block. Once a new block is reached, all the commits in the old block array. Continue until you reach the hashes, aka block 99999999, then stop. If a commit's block does NOT have a stored hash, then it and every other commit after the fact are all marked as orphaned, and so are any hashes for those blocks (i.e. if block 6 does not have a stored hash, all the commits on block 6, 7, 8, 9, etc. are all considered bad and must be redownloaded). After pulling all the orphaned commits and hashes, delete the from the db without mining them. In the future this can be made more efficient, but for now it makes sense from a safety perspective.
This setup should, barring manually messing around with the commits files or manually inputting commits, prevent any problems. The hash is always stored/removed as the seal, even if the mine/unmine process is interrupted by a crash the next time you boot that block's commits will all be orphaned, as they won't have a stored hash, and will get negated and remined.
Note: currently mergedcomb contains some code I haven't tested for cleaning orphaned blocks. The code has been tested for cleaning the most recent block, but what has not been fully tested yet is the multi-block cleaning that would be trigger by messing removing a block hash that's halfway down the chain. I'll test it over the next couple of days, this is just a heads up there may be some problems if you try to mess with it.Testing with BTC's regtest mode has been implemented, not Testnet yet though. As this whole modification doesn't make any changes to the transaction processing code, regtest will work for simulating chainstate changes and how they affect the database. A separate commitsdb is created specifically for regtest, so you don't need to worry about overwriting the normal one.TODO:
- Implement block by block fingerprinting. This will allow for 100% certainty that no problems have occurred in the commits file, and will also potentially allow for selective block repairs if commits get corrupted/orphaned, rather than bruteforcing every commit above the problem.
- Better comms structure. The channel communication isn't built on a solid foundation because it doesn't need to be yet. If it is projected that it'll need to expand to become a more substantial part of the system, then reorganizing it properly is a good idea.
- Better datatype management. I need to go through and make a few things more uniform and consistent I think, I haven't done any optimization in this regard.
- More thorough error management testing. Right now it seems to work alright, but I haven't gone through it enough to be 100% confident in it yet. This also includes better logging for debugging.
- Memory management. I need to go through the best way to negate this, probably combine this with datatype management lol.
Overall there's a lot to be done to format everything and make it less sloppy, but like I said this is really a structure proof before doing stuff like that.