BiblePay - New Coin Launch - Official Thread

[oliwer21]

What's going on with unsucessfull withdraws?

[bible_pay]

@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?

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.

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?

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.

[bible_pay]

What's going on with unsucessfull withdraws?

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?

[bible_pay]

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?

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.

[happy_merchant]

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!)

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.

[p3ppymon]

Would checkpoints help to standardise the block count for each user?

[oliwer21]

What's going on with unsucessfull withdraws?

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?

ok, win10 64. wallet was 1.0.2.9 ver. now is 1.0.3.1
withdrawal was made on 9/11/2017 3:25:02 PM  for 4800 coins user oliwer21 on pool.
Wallet adress was BDzPsShbJKApWukGsrjdvDom7ig6XF9Sjz

[maarekelets]

@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?

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.

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?

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.

Eventually the wallet caught up and I went through the rescan and zap and all appears good on this wallet. Hopefully the pool comes back the same way.

At some point when life slows down a bit can you post a debrief paper on what occurred? I'm legit interested in what caused the need for the fork.

[bible_pay]

What's going on with unsucessfull withdraws?

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?

ok, win10 64. wallet was 1.0.2.9 ver. now is 1.0.3.1
withdrawal was made on 9/11/2017 3:25:02 PM  for 4800 coins user oliwer21 on pool.
Wallet adress was BDzPsShbJKApWukGsrjdvDom7ig6XF9Sjz

It looks like what happened is at the moment you clicked withdraw, the pool sent the withdraw out on a fork, generated a txid, deducted the amount from you, and now the txid is no longer on the network:
getrawtransaction 31c4f925defd969400687a891f33d6006ee4c8cddd66357ca005ccab88b87438 1

Meaning that you should be credited for this. 

The 4800.00 has been credited to your pool account.


Sorry about the inconvenience.

[MorpheWQ]

What's going on with unsucessfull withdraws?

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?

ok, win10 64. wallet was 1.0.2.9 ver. now is 1.0.3.1
withdrawal was made on 9/11/2017 3:25:02 PM  for 4800 coins user oliwer21 on pool.
Wallet adress was BDzPsShbJKApWukGsrjdvDom7ig6XF9Sjz

My last 2 test withdrawals were lost.
Wallet address: B8sQGxPgKZHxhTM6qwRYSmUoffcCyeFEwv

TX1: c55e4abbd7dfde59ce79f39a750e2bab420eac2e79aab82c202d315ffc9ba746
TX2: 0bde527f5147b12e3b6c62988d8692b48acbd482f8b8df765a855a87c0921122

I think, there is a problem with c-cex.

[bible_pay]

What's going on with unsucessfull withdraws?

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?

ok, win10 64. wallet was 1.0.2.9 ver. now is 1.0.3.1
withdrawal was made on 9/11/2017 3:25:02 PM  for 4800 coins user oliwer21 on pool.
Wallet adress was BDzPsShbJKApWukGsrjdvDom7ig6XF9Sjz

My last 2 test withdrawals were lost.
Wallet address: B8sQGxPgKZHxhTM6qwRYSmUoffcCyeFEwv

TX1: c55e4abbd7dfde59ce79f39a750e2bab420eac2e79aab82c202d315ffc9ba746
TX2: 0bde527f5147b12e3b6c62988d8692b48acbd482f8b8df765a855a87c0921122

Looks like those two were not lost - please rescan your chain.

[616westwarmoth]

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

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.

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.

I can confirm this.  I run a locked wallet on my other couple machines (which is a copy of the wallet.dat from my main machine).  One of which mines solo.  When the solo box hit a block, the block reward showed on my main PC wallet (and after vnc'ing to the others, it showed up on those as well).  So the advantage is there is less to worry about if you run several boxes and they revert to solo mining if the pool goes down (or they solo by design).  The downside would be a slightly higher security risk, so encrypt your wallet before copying it and the encryption will travel.

[616westwarmoth]

@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?

You can reindex from launch options or the debug console.  Go to Wallet Repair, hit the Rebuild Index button.  It will kill the wallet, and then immediately restart it just like you had gone to the command line started it with the -reindex flag.  I find it works a lot faster if you change your biblepay.conf file and comment out (#) the gen=1 line so it's not trying to do too much at once.  Then after it finishes reindexing, close the wallet normally, re-edit your .conf file to re-enable gen=1 and you're set.

[oliwer21]

What's going on with unsucessfull withdraws?

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?

ok, win10 64. wallet was 1.0.2.9 ver. now is 1.0.3.1
withdrawal was made on 9/11/2017 3:25:02 PM  for 4800 coins user oliwer21 on pool.
Wallet adress was BDzPsShbJKApWukGsrjdvDom7ig6XF9Sjz

It looks like what happened is at the moment you clicked withdraw, the pool sent the withdraw out on a fork, generated a txid, deducted the amount from you, and now the txid is no longer on the network:
getrawtransaction 31c4f925defd969400687a891f33d6006ee4c8cddd66357ca005ccab88b87438 1

Meaning that you should be credited for this. 

The 4800.00 has been credited to your pool account.


Sorry about the inconvenience.

ok, theyare back:P thx.
withdraw is safe now?

P.S. pls can You write how to set wallet for everyone? cuz its a bit mess in thread and i don't know how to fix for example banned list and why my "getminninginfo" shows me invalid result on pool3?

[bible_pay]

What's going on with unsucessfull withdraws?

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?

ok, win10 64. wallet was 1.0.2.9 ver. now is 1.0.3.1
withdrawal was made on 9/11/2017 3:25:02 PM  for 4800 coins user oliwer21 on pool.
Wallet adress was BDzPsShbJKApWukGsrjdvDom7ig6XF9Sjz

It looks like what happened is at the moment you clicked withdraw, the pool sent the withdraw out on a fork, generated a txid, deducted the amount from you, and now the txid is no longer on the network:
getrawtransaction 31c4f925defd969400687a891f33d6006ee4c8cddd66357ca005ccab88b87438 1

Meaning that you should be credited for this. 

The 4800.00 has been credited to your pool account.


Sorry about the inconvenience.

ok, theyare back:P thx.
withdraw is safe now?

P.S. pls can You write how to set wallet for everyone? cuz its a bit mess in thread and i don't know how to fix for example banned list and why my "getminninginfo" shows me invalid result on pool3?

78% are on the new version, so pool withdraws are safe.  Still waiting for c-cex to take us offline. 

As far as the 'invalid solution' error, Im working on that now inside the pool, so that should be fixed soon.  Also, I think the pool performance will speed up as I found an issue with it.

As far as mining guides, I added the Togo's mining guide PDF to the web site (www.biblepay.org) from Reddit.

However, it would be nice if someone would make one for our wiki:
http://wiki.biblepay.org

[616westwarmoth]

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

There is no independent mining software for BBP.  So every machine must run the "wallet", i.e., Biblepay Core.  If you have multiple machines you can run different wallet.dat (separate accounts) on each one, or you can copy your main wallet.dat (which should be encrypted) to another machine and they will both mine to the same wallet and be accessible from any of the machines running that wallet.dat.

[oliwer21]

78% are on the new version, so pool withdraws are safe.  Still waiting for c-cex to take us offline. 

As far as the 'invalid solution' error, Im working on that now inside the pool, so that should be fixed soon.  Also, I think the pool performance will speed up as I found an issue with it.

As far as mining guides, I added the Togo's mining guide PDF to the web site (www.biblepay.org) from Reddit.

However, it would be nice if someone would make one for our wiki:
http://wiki.biblepay.org

I was thinkig about things like this:
to apply this
biblepay-qt -reindex

biblepay-qt -rescan
biblepay-qt -zapwallettxes=1
or delete baning list?
Do we all need to do such thigs?

[inblue]

Would you be able to package up your backup blockchain as a bootstrap to get some of us running again?

In theory you are supposed to merge two files (as detailed at http://cryptochainer.com/dir/?page_id=154 from "To create your own bootstrap.dat..." onwards), but renaming a copy of blk0001.dat usually works.  Name the file "bootstrap.dat" and if we download it and delete the existing chain (don't delete the wallet!) then copy this in before starting biblepay it should read the chain from that file instead (and renames it to bootstrap.dat.old).

This is a good idea. If the dev or anyone wants to help others who are still not on the longest chain (and to speed up the process of adoption), they can even simply zip the .biblepaycore folder (just without wallet.dat and biblepay.conf) and share it. That's even easier than making a bootstrap.dat file, and by zipping everything you even get an added benefit of having the peers.dat file with the good peers etc.

[bible_pay]

Would you be able to package up your backup blockchain as a bootstrap to get some of us running again?

In theory you are supposed to merge two files (as detailed at http://cryptochainer.com/dir/?page_id=154 from "To create your own bootstrap.dat..." onwards), but renaming a copy of blk0001.dat usually works.  Name the file "bootstrap.dat" and if we download it and delete the existing chain (don't delete the wallet!) then copy this in before starting biblepay it should read the chain from that file instead (and renames it to bootstrap.dat.old).

This is a good idea. If the dev or anyone wants to help others who are still not on the longest chain (and to speed up the process of adoption), they can even simply zip the .biblepaycore folder (just without wallet.dat and biblepay.conf) and share it. That's even easier than making a bootstrap.dat file, and by zipping everything you even get an added benefit of having the peers.dat file with the good peers etc.

Im not bashing the idea at all, but right now you can sync the wallet in 2 minutes from 0.  Its really not necessary yet.

[Exavier]

Agreed. This blockchain syncs fast. Maybe when it's huge and 6 months plus to sync up but right now that seems like a waste of time.