|
I need it for compile windows build from gitian.
But I can't get it from googling.
Where can I get that file? If you have, please send me, wsxdrfv (at) hanmail (dot) net
Thanks.
|
|
|
|
|
So when receive bitcoin, wallet program also shows QR code with address.
How it is possible? How can adopt that system to new coin?
|
|
|
|
They are called DNS Seeds And they are hard coded into the client to help nodes bootstrap. Basically they are IP addresses of bitcoin nodes run by Bitcoin community members and they assist in peer discovery since new nodes on the network don't know which addresses to connect to. Are there no way to start ./bitcoind without connect to other peer? I just want to test source revision and function test without connect to peers. |
|
|
|
|
So bitcoin core first start, it need to know ip address of peers to connect to.
Where from those info?
I saw chainparams.cpp has variable like vSeeds.emplace_back("dnsseed.bitcoin.....com", true);
Then bitcoin client first try to access to above address, then fetch nearest peer's ip address from above site?
Then, developer should wrote down ip address (something like 133.344.67.22) to above site before?
or, How it works?
|
|
|
|
So I want to know script's structure, for new block generation process and its work process for satisfy proof of work function is pow.cpp. Eventually, I want to know how to do actually mine and validate genesis block for new coin. |
|
|
|
|
So after block found, all workers(nodes) now work for new block,
following its algorithm, SHA256, if Bitcoin.
Then what is source file name (or function name even better) that code this algorithm actually working part?
|
|
|
|
What exactly are the lines you changed (as in post the code snippets for your changes).
chainparams.cpp, CMainParam part, line number 133~135 base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,33); base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,33); base58Prefixes[SCRIPT_ADDRESS2] = std::vector<unsigned char>(1,33); |
|
|
|
Are you sure that the addresses you are getting are P2SH addresses? The default used to be P2PKH, and unless you are modifying the latest code, that's all you are going to get. P2PKH prefixes are not governed by the prefix corresponding to SCRIPT_ADDRESS.
If you don't know what those mean, then you need to do more research.
I know p2sh, p2pkh, so how to change '3' to another character? I have changed all 5 value of prefix to 33 which is for 'E', but not worked. |
|
|
|
Did you reset your datadir before trying with the new genesis block? Reset as in delete the blocks and chainstate folders.
Yes I deleted whole folders, files inside Home/.(coin name) folder. |
|
|
|
|
yes so I changed again to that value,
consensus.hashGenesisBlock = genesis.GetHash();
printf("genesis.GetHash = %s\n", genesis.GetHash().ToString().c_str());
printf("genesis.merkleroot = %s\n", genesis.hashMerkleRoot.ToString().c_str());
assert(consensus.hashGenesisBlock == uint256S("0x0000c978c4bf731c7e48018bc21f658b37394b5d18bd2ceca383768387578d76"));
assert(genesis.hashMerkleRoot == uint256S("0x88e2acfcaec30f35652d10b861700def63129f9ac8176cdda889fed7baa730bb"));
but still debug.log says,
.....
.....
...
2018-03-02 04:25:09
case 2
2018-03-02 04:25:09
case 2
2018-03-02 04:25:09
case 2
2018-03-02 04:25:09
case 2
2018-03-02 04:25:09
case 2
2018-03-02 04:25:09 Genesisblock : CBlock(hash=0000c978c4bf731c7e48018bc21f658b37394b5d18bd2ceca383768387578d76, ver=0x00000001, hashPrevBlock=0000000000000000000000000000000000000000000000000000000000000000, hashMerkleRoot=88e2acfcaec30f35652d10b861700def63129f9ac8176cdda889fed7baa730bb, nTime=1519619579, nBits=1f00ffff, nNonce=210708, vtx=1)
CTransaction(hash=88e2acfcae, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, 4294967295), coinbase 04ffff001d0104114e6f7720697320323031382d30322d3230)
CScriptWitness()
CTxOut(nValue=500.00000000, scriptPubKey=410438b425136a6d49d84513c38e12)
2018-03-02 04:25:09
2018-03-02 04:25:09 Bitcoinessence version v0.15.1.0-unk
2018-03-02 04:25:09 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2018-03-02 04:25:09 Assuming ancestors of block 59c9b9d3fec105bdc716d84caa7579503d5b05b73618d0bf2d5fa639f780a011 have valid signatures.
2018-03-02 04:25:09 Setting nMinimumChainWork=00000000000000000000000000000000000000000000002ebcfe2dd9eff82666
2018-03-02 04:25:09 Using the 'standard' SHA256 implementation
2018-03-02 04:25:09 Using RdRand as an additional entropy source
2018-03-02 04:25:09 Default data directory /home/lee/.bitcoinessence
2018-03-02 04:25:09 Using data directory /home/lee/.bitcoinessence
2018-03-02 04:25:09 Using config file /home/lee/.bitcoinessence/bitcoinessence.conf
2018-03-02 04:25:09 Using at most 125 automatic connections (1024 file descriptors available)
2018-03-02 04:25:09 Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2018-03-02 04:25:09 Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2018-03-02 04:25:09 Using 4 threads for script verification
2018-03-02 04:25:09 scheduler thread start
2018-03-02 04:25:09 HTTP: creating work queue of depth 16
2018-03-02 04:25:09 No rpcpassword set - using random cookie authentication
2018-03-02 04:25:09 Generated RPC authentication cookie /home/lee/.bitcoinessence/.cookie
2018-03-02 04:25:09 HTTP: starting 4 worker threads
2018-03-02 04:25:09 init message: Verifying wallet(s)...
2018-03-02 04:25:09 Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2018-03-02 04:25:09 Using wallet wallet.dat
2018-03-02 04:25:09 CDBEnv::Open: LogDir=/home/lee/.bitcoinessence/database ErrorFile=/home/lee/.bitcoinessence/db.log
2018-03-02 04:25:09 Cache configuration:
2018-03-02 04:25:09 * Using 2.0MiB for block index database
2018-03-02 04:25:09 * Using 8.0MiB for chain state database
2018-03-02 04:25:09 * Using 440.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2018-03-02 04:25:09 init message: Loading block index...
2018-03-02 04:25:09 Opening LevelDB in /home/lee/.bitcoinessence/blocks/index
2018-03-02 04:25:09 Opened LevelDB successfully
2018-03-02 04:25:09 Using obfuscation key for /home/lee/.bitcoinessence/blocks/index: 0000000000000000
2018-03-02 04:25:09 LoadBlockIndexDB: last block file = 0
2018-03-02 04:25:09 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
2018-03-02 04:25:09 Checking all blk files are present...
2018-03-02 04:25:09 LoadBlockIndexDB: transaction index disabled
2018-03-02 04:25:09 Initializing databases...
2018-03-02 04:25:09 Pre-allocating up to position 0x1000000 in blk00000.dat
2018-03-02 04:25:09 Opening LevelDB in /home/lee/.bitcoinessence/chainstate
2018-03-02 04:25:09 Opened LevelDB successfully
2018-03-02 04:25:09 Wrote new obfuscate key for /home/lee/.bitcoinessence/chainstate: 735383118d952a83
2018-03-02 04:25:09 Using obfuscation key for /home/lee/.bitcoinessence/chainstate: 735383118d952a83
2018-03-02 04:25:09 init message: Rewinding blocks...
2018-03-02 04:25:09 block index 11ms
2018-03-02 04:25:09 init message: Loading wallet...
2018-03-02 04:25:09 nFileVersion = 150100
2018-03-02 04:25:09 Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total
2018-03-02 04:25:09 Performing wallet upgrade to 60000
2018-03-02 04:25:10 keypool added 2000 keys (1000 internal), size=2000 (1000 internal)
2018-03-02 04:25:10 keypool reserve 1
2018-03-02 04:25:10 keypool keep 1
2018-03-02 04:25:10 wallet 1434ms
2018-03-02 04:25:10 keypool added 1 keys (0 internal), size=2000 (1000 internal)
2018-03-02 04:25:10 setKeyPool.size() = 2000
2018-03-02 04:25:10 mapWallet.size() = 0
2018-03-02 04:25:10 mapAddressBook.size() = 1
2018-03-02 04:25:10
case 2
2018-03-02 04:25:10 ERROR: ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=8)
2018-03-02 04:25:10 *** Failed to read block
2018-03-02 04:25:10 Error: Error: A fatal internal error occurred, see debug.log for details
|
|
|
|
You still have failed to generate a valid genesis block. Reindexing isn't going to do anything. Since you seem to be having such a hard time creating the genesis block, why don't you use a script like https://github.com/lhartikk/GenesisH0 to do it for you? Very strange. So my chainparams is like this, static CBlock CreateGenesisBlock(uint32_t nTime, uint32_t nNonce, uint32_t nBits, int32_t nVersion, const CAmount& genesisReward)
{
const char* pszTimestamp = "Now is 2018-02-20";
const CScript genesisOutputScript = CScript() << ParseHex("0438b425136a6d49d84513c38e12204f9cbd22c6dfa7efce443d9582db7df1b6862d36de74db2c13e0d96b749ca7949ccbe2640e8ec4e10982a84a06cfb6071d66") << OP_CHECKSIG;
return CreateGenesisBlock(pszTimestamp, genesisOutputScript, nTime, nNonce, nBits, nVersion, genesisReward);
}
genesis = CreateGenesisBlock(1519619579, 44453, 0x1f00ffff, 1, 500 * COIN);
consensus.hashGenesisBlock = genesis.GetHash();
printf("genesis.GetHash = %s\n", genesis.GetHash().ToString().c_str());
printf("genesis.merkleroot = %s\n", genesis.hashMerkleRoot.ToString().c_str());
assert(consensus.hashGenesisBlock == uint256S("0x00001e1f488925de2046bfb8bb24bd821f9b4ac3762b4da908a2e3ade576f5ac"));
assert(genesis.hashMerkleRoot == uint256S("0x88e2acfcaec30f35652d10b861700def63129f9ac8176cdda889fed7baa730bb"));
So I did GenesisH0 command like, python genesis.py -z "Now is 2018-02-20" -p "0438b425136a6d49d84513c38e12204f9cbd22c6dfa7efce443d9582db7df1b6862d36de74db2c1 3e0d96b749ca7949ccbe2640e8ec4e10982a84a06cfb6071d66" -t 1519619579 -n 44453 -b 0x1f00ffff -a scrypt But result is 04ffff001d0104114e6f7720697320323031382d30322d3230 algorithm: scrypt merkle hash: eeed278f4f20eceeafe7a2dc728c611b3aef1656a6b8404d8b68a48d03e53991 pszTimestamp: Now is 2018-02-20 pubkey: 0438b425136a6d49d84513c38e12204f9cbd22c6dfa7efce443d9582db7df1b6862d36de74db2c1 3e0d96b749ca7949ccbe2640e8ec4e10982a84a06cfb6071d66 time: 1519619579 bits: 0x1f00ffff Searching for genesis hash.. genesis hash found! nonce: 172682 genesis hash: d79fa40dc89f83ef4ff182f915bd5e778127e654909351debac676978effe31f So nonce and genesis hash is different with [ assert(consensus.hashGenesisBlock == ] part? Anyway, I changed nonce and genesis hash like below to follow above result, genesis = CreateGenesisBlock(1519619579, 172682, 0x1f00ffff, 1, 500 * COIN); assert(consensus.hashGenesisBlock == uint256S("0xd79fa40dc89f83ef4ff182f915bd5e778127e654909351debac676978effe31f")); But after compile this with [make, make install], run ./(my coin name)d error says, genesis.GetHash = 0000c978c4bf731c7e48018bc21f658b37394b5d18bd2ceca383768387578d76 genesis.merkleroot = 88e2acfcaec30f35652d10b861700def63129f9ac8176cdda889fed7baa730bb bitcoinessenced: chainparams.cpp:285: CMainParams::CMainParams(): Assertion `consensus.hashGenesisBlock == uint256S("0xd79fa40dc89f83ef4ff182f915bd5e778127e654909351debac676978effe31f")' failed. Aborted (core dumped) So then this means genesish0 is not work with current source? (litecoin 0.15.1) |
|
|
|
Ok, so current status is, if I run with ./bitcoind, then get error of ---------- ERROR: ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=8) 2018-03-01 08:55:21 *** Failed to read block 2018-03-01 08:55:21 Error: Error: A fatal internal error occurred, see debug.log for details ---------- and if I run with ./bitcoind -reindex, then get error of ---------- 2018-03-01 08:55:45 Reindexing block file blk00000.dat... 2018-03-01 08:55:45 case 2 2018-03-01 08:55:45 ERROR: AcceptBlock: high-hash, proof of work failed (code 16) 2018-03-01 08:55:45 Reindexing finished 2018-03-01 08:55:45 Failed to open mempool file from disk. Continuing anyway. 2018-03-01 08:59:30 Potential stale tip detected, will try using extra outbound peer (last tip update: 180 seconds ago) 2018-03-01 09:02:30 Potential stale tip detected, will try using extra outbound peer (last tip update: 360 seconds ago) 2018-03-01 09:05:30 Potential stale tip detected, will try using extra outbound peer (last tip update: 540 seconds ago) 2018-03-01 09:08:30 Potential stale tip detected, will try using extra outbound peer (last tip update: 720 seconds ago) 2018-03-01 09:11:30 Potential stale tip detected, will try using extra outbound peer (last tip update: 900 seconds ago) 2018-03-01 09:14:30 Potential stale tip detected, will try using extra outbound peer (last tip update: 1080 seconds ago) 2018-03-01 09:17:30 Potential stale tip detected, will try using extra outbound peer (last tip update: 1260 seconds ago) ..... continuing forever..... ------------- above's case 2 means, I added manually like, bool CheckProofOfWork(uint256 hash, unsigned int nBits, const Consensus::Params& params)
{
bool fNegative;
bool fOverflow;
arith_uint256 bnTarget;
bnTarget.SetCompact(nBits, &fNegative, &fOverflow);
// Check range
if (fNegative || bnTarget == 0 || fOverflow || bnTarget > UintToArith256(params.powLimit))
{
LogPrintf("\ncase 1\n");
return false;
}
// Check proof of work matches claimed amount
if (UintToArith256(hash) > bnTarget)
{
LogPrintf("\ncase 2\n");
return false;
}
return true;
} Any comments appreciated.. |
|
|
|
Then instead of using the checkproofofwork function, copy out its code into your while loop and refer to the variables directly from within the ChainParams. This is simple programming debugging and troubleshooting, you should not need hand holding and someone to tell you exactly what to do.
Even after doing that, still debug.log says ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=8)... Seems there is no hope... Note that i am not an expert in coding and debugging, but this error CBlockDiskPos(nFile=0, nPos=8)... might have something to do with you having an invalid hash/nounce.. See this as reference; https://bitcoin.stackexchange.com/questions/60299/altcoin-creation-from-bitcoin-readblockfromdisk-errors-in-block-header-at-cblocBut it seems that you've already read that answer, assuming you're leegod on SE? yes I already read it. leegod is my nickname. And as first reply of that thread said, it doesn't work with new source. Still has CBlockDiskPos error. |
|
|
|
|
I know if run ./bitcoin-qt, wallet GUI program started.
Then if everything is normal and fine, what will happen when run ./bitcoind?
|
|
|
|
|
And how to block whale mine block even at 0.00001 second? How to set minimum required block generation time?
|
|
|
|
|
I revised base58Prefixes[SCRIPT_ADDRESS1, 2] = std::vector<unsigned char>(1, 33) at source file, chainparams.cpp,
and compiled with [make, make install],
but when I run xxxcoin-qt, and address checked, it doesn't changed at all, why?
|
|
|
|
If network difficulty adjusts in a time unit, then yes.
If the difficulty adjusts after X blocks, then no. In that case it would take the time it needs to get the X blocks mined until the difficulty adjusts again.
Actually I want to adopt Sha256 or Scrypt because actually I want to lure those whales. So for your last sentence, I think it is important, how to implement like that? If I cloning litecoin (or bitcoin) then is it enough to change just [ consensus.nPowTargetTimespan ] as short as possible like 1 hour? |
|
|
|
|
What is pump and dump,
and how to block?
|
|
|
|
Then instead of using the checkproofofwork function, copy out its code into your while loop and refer to the variables directly from within the ChainParams. This is simple programming debugging and troubleshooting, you should not need hand holding and someone to tell you exactly what to do.
Even after doing that, still debug.log says ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=8)... Seems there is no hope... |
|
|
|
RGBkey has answered your first 2 questions so I'll answer the last one: If all these are true, why not shorten difficulty retarget time as short as possible? Isn't it more good way? Bitcoin uses a fairly long difficulty retarget time to prevent miners gaming the system like what happened in Bcash last yearAs you noted, if you have short difficulty retarget time, a miner with large hashpower could mine blocks quickly to reap rewards, wait for difficulty to adjust, then repeat. With Bitcoin the miner would have to sustain the attack for about 2 weeks which is prohibitively expensive. Also block generation time is like a lottery where it's possible to find many blocks within the expected block generation time or not find any within that time, so if this happens you do not even need a miner with large hashpower to destabilise your network, just bad luck. However there are altcoins that have a difficulty retatget time with a different algorithm, such as Kimoto Gravity Then, what is best adoption for newly started coin? Just shorten difficult retarget parameter to shorten like 1 hour? or Kimoto? How to adopt it? |
|
|
|
|
Show Posts
