Topic: BiblePay - New Coin Launch - Official Thread - page 87. (Read 119850 times)

Ah, I had never really considered that before since I've never come close to using up the keypools in any of my crypto wallets. I should probably go through and make sure my more frequently used wallets have plenty of reserved keys left.

Yeah, I realize we have some cosmetics work to do.

Yeah, use the smaller one 419.2 for now.
I got your message on networkhashps being off, we can work together on that also.

Thanks.

Could you please give a detailed example?  Im not aware of any.  Also, include txids and the name of the system.  Im not even sure what system you refer to?

Yeah, thats a good point but I believe I see the reason for this.

So first I just ran the commands, and dont see any problems with our zapwallettxes and rescans, all the coins are in the wallet and no orphan tx are present.
Moving on to reindex, the wallet erases the blocks file and loads the blockindexes back one by one, and counts how many block indexes exist vs how many blocks are in the chain.  In this case, I also reindexed 7324 block indexes with a tip height of 7292.  So we basically agree, the height is actually 7292 which agrees with the pool.  The primary thing to look for is any corruption or business logic failure- It "appears" (God willing) that we are OK as far as algorithm logic, another words, there are no checkblock errors, and all the nodes agree on the 7292 without rejecting one in the middle and causing us to fork back to somewhere between the birth of F7000 and 7292.  So thats good.

As far as explaining why we have 28 extra block indexes in memory, that can be explained and is possibly partially not even related to f7000 its probably partially related, but not entirely.  The block index can be floating around the network due to blocks that fit on smaller chains, but dont fit in the tree.  Another words, we have 28 blocks that were solved by miners that dont fit in the chain but do fit under other blocks.  So that is Good also, another words the wallet is finding the longest chain and skipping by those dead ends.

They do get pruned eventually.  

Im feeling better about it but not sure if we are out of the woods yet.  I think we will need Wests pool for one.  I sent him the word document on how to create a second pool.  He is working on that.

What's going on with unsucessfull withdraws?

So doing a reindex had some odd results. It processes through the reindex all the way up until the progress meter says around 4 or 6 hours behind (I've done this twice, first time was 4 hours second time it said 6). In the debug log I see no errors but then tail of the file states the reindex completed:

---

2017-09-12 13:50:21 ProcessNewBlock : ACCEPTED
2017-09-12 13:50:21  7317.000000 189UpdateTip: new best=8b59e22885de070cb91790c279e66f0a4ec3d0d19d2a9203729d8e984a341945  height=7289  log2_work=46.895307  tx=11177  date=2017-09-12 13:25:24 progress=0.999845  cache=1.1MiB(4593tx)
2017-09-12 13:50:21 ProcessNewBlock : ACCEPTED
2017-09-12 13:50:21  7318.000000 189UpdateTip: new best=709b269c65b9a67926110eba5e677a523e8c06910cd22716651705eb9c78cff7  height=7290  log2_work=46.90914  tx=11178  date=2017-09-12 13:26:49 progress=0.999854  cache=1.1MiB(4594tx)
2017-09-12 13:50:21 ProcessNewBlock : ACCEPTED
2017-09-12 13:50:21  7319.000000 189UpdateTip: new best=f3e51b45b7bdad3a787ef5ff3c7e7524700c062654c4b150eeb27a5f0cafbaff  height=7291  log2_work=46.928668  tx=11179  date=2017-09-12 13:29:43 progress=0.999872  cache=1.1MiB(4595tx)
2017-09-12 13:50:21 ProcessNewBlock : ACCEPTED
2017-09-12 13:50:21  7320.000000 Loaded 7320 blocks from external file in 37577ms
2017-09-12 13:50:21 Reindexing finished

---

What I find odd here is that I'm pretty sure we are in the 7280s..... not 7320 which makes me think when I reindexed that it followed the wrong chain.

If I attempt to rescan in this state when the core comes back up it can never find a source to sync.

This system was originally installed with 1.0.2.x and was upgraded with the existing blocks still in place.

Thoughts? Ideas?

I have some experience with this. The only thing you need to be careful with is not to "run out of keys". The wallet file has 1000 pre-generated private keys with biblepay that are used for every new address you generate. Once you used all the keys, it automatically starts generating new keys for the new addresses.

So if you start mining on a lot of PCs and they suddenly run out keys and start generating new ones, the wallet.dat you kept may not contain these new keys!

The way to mitigate this could be to start with a wallet.dat with a bigger pool of pre-generated keys (can do that with biblepay-cli keypoolrefill x where x is the amount of pre-generated keys you want. You need to be careful as you wallet.dat file can become quite big!)

bible_pay but if i understand: every machine must be runnin wallet(same wallet.dat) for mining ... right? not exists any miner sw

Just noticed the block explorer is reporting a really high difficulty, too.

getmininginfo -> "difficulty": 419.2772529614635,
getdifficulty -> 4192.772529614635

Seems to be a decimal point out of place. The block explorer uses getdifficulty to retrieve the value. I take it the lower value is the correct one?

Yes its paramount.
Please Try these 3 tests after deleting debug.log:

biblepay-qt -reindex

biblepay-qt -rescan
biblepay-qt -zapwallettxes=1

Then take a look at the log and ensure there are no errors, and your block height remains the same and wallet balance is still full?

Then after all that you can delete: Blocks, Chainstate, Database folders (of course always keep a copy of wallet.dat!) and then resync from 0 and ensure no banning occurs and syncing does not stop?


Ill do this also asap today.

Definitely, wallets should always be encrypted, especially if you're going to be distributing it across multiple machines. You should also keep an encrypted backup copy in cloud storage or at least a USB or something. I'm sure there's even tools that would let you make a paper BBP wallet. As long as it's encrypted nobody can do anything with the wallet file even if it's stolen or compromised, and it protects you from losing your wallet to a HDD failure or laptop theft or anything else that can happen if you only have a single copy.

Yes sort of, the 7 minute block targets are being met accurately currently, but our rule regarding Difficulty subsidy adjustment, with the new algorithm being harder to solve, since the difficulty has jumped to 293 (from .05) is causing a lower reward.  The wallet has a protection mechanism that pays out BBP per a chart compiled in GetBlockSubsidy, the higher the diff the lower the reward.  Right now, we have gone from a 20,000 subsidy all the way down to 9000 subsidy.  

As far as my thoughts on this, I personally would have preferred the 16,000 subsidy range at this level, with 9000 being reserved for Very high diffs (maybe a 2930 diff) IE one magnitude higher.  

But since it is the way it is, I think we should leave it, and maybe make a slight adjustment when the sactuaries go live, or when the next mandatory occurs, if necessary, as by then we will know more about our popularity, demand on the pools, and will have multiple pools.

At this point we are harder to mine, and have less reward per block, so the exchange being a free market should take that into account and BBP may increase in value.

@bible_pay - Good morning. Do you still think it would be best to have a few nodes reindex and resync this morning? If so could you tell me what the Windows command to do a reindex would be? Is it a launch option or a debug console command?

Yeah, I havent actually done that myself yet, but I have 'one' piece of info on that.  Blue said he copied his one wallet.dat file over to 10 machines, and now on his desktop he receives notifications when any machine mines a block (IE the txlist updates).  So he has one consolidated wallet.

I was going to add: In POW, since coins can be received in a locked wallet, you can encrypt and lock your wallet and still receive rewards from any POW device out there mining into that single wallet.

happy_merchant i was think,that i see that not exists any miner for it= so i have to install wallet to all machines,right? thanks

There's a wallet.dat file in your BiblepayCore directory (usually ~/.biblepaycore on linux or /AppData/Roaming/BiblepayCore on windows). Just copy whatever wallet.dat file you want to use from one machine and place it in the BiblepayCore directory on the other machine.

guys: can i mining with 2 machines to 1 wallet? or every machine must have own wallet always?

Block explorer is back on the main fork again.

I've also gone ahead and hid the network hashrate reporting for now so as to not cause confusion. The rpc getnetworkhashps method is giving a different value from the networkhashps from getmininginfo, and they're both reporting in the GH/s range which clearly isn't right, so I don't think they're really giving much useful info at present.

Bible coin or Bible pay  sounds great.

how can i change mining info?
1 PC = 1 wallet? can i mining with 1 wallet on 10 servers?