Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob Andrews

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 128
106
Thats because the wallet pulls more blocks after the problem until it cant (you can check the log for ERROR to see the real root problem really occurs "ABN ERROR!  Block 50558.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000" at 50558. 
^ Thats got to be the real root problem in every log right now.

If you want you can exit even earlier at 49000 to give you more time - I would recommend that.

Also, I have successfully recovered a node with getchaintips just now, but lets go through that later, since we know we need another mandatory I dont want to confuse everyone right now.


107
Ok. So, now I'm stucked on 50655 :D
I was away of my PC, so I'll try to sync it again to 50k and make a backup :)
I hope, I'll stop it in right time :D

Thats because the wallet pulls more blocks after the problem until it cant (you can check the log for ERROR to see the real root problem really occurs "ABN ERROR!  Block 50558.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000" at 50558. 
^ Thats got to be the real root problem in every log right now.

If you want you can exit even earlier at 49000 to give you more time - I would recommend that.


108
Awesome, Thanks Rob!
Thank you for all of your hard work!
This is exciting!
Thanks, Ill answer that CPK stuff soon, in the mean time
do you have blockhash 06af* for 52240? 
Also whats your IP for your sanc, Id like to see if it shows in my enabled list.
(You see 4 enabled in your sanc list correct)?
Are you in the leaderboard yet Togo, as I only have 5 participants there?




109
So, I'm stucked on block 50561 again.  It looks, that resync is waiting for me again. Rob, in few last days I've made more than 10 full resync (deleted everything from biblepaycore folder - like in Togos post) but it never took less than 2 hours for me.
Maybe it is problem of my PC, but we've talked about this before latest mandatory testnet.
May it be caused with mine huge activity in constant download of data from my peers? May I be blocked somehow?
Sometimes it starts withou problem, but after some time download fall to 10kB/s.
I can guarant that it is not caused with my internet connection.
I have now tho internet providers (300 Mbps and 500Mbps) and it is the same on both. So, it can be caused with my PC, but on my second PC it was the same. Slow connection with peers.

I have tried to set gen=0, but there is still problem with sync.
Here is part from my debug.log:
Code: [Select]
2019-04-28 13:55:37 ERROR: AcceptBlockHeader: block f5cbf4edfd4df18b3204ac8c72b44ba04296e0334d50a9d40e9b208f4f835913 is marked invalid
2019-04-28 13:55:37 ERROR: invalid header received

So, I'll start resync again with gen=0 and I'll see if the sync will be faster.
BTW: Rob, can you delete debug.log from WIN wallet install file?
It is in ...BiblepayEvolution\doc\ folder after install and it has more then 67MB :D I think that it is not neccessary for us ;)
There are some old logs from end of March.

So, I think I have reproduced the same problem that you have (Im syncing from zero to 50558).  I'm running a deep analysis now with more logging to confirm the exact root cause at 50558.


In the mean time while I'm doing this, I think the speed problem has more to do with the latency from SK to the US servers (not the machine or the bandwidth).  Its a chatty process to download each block with all the back and forth confirms.

I recommend doing this for now (as most likely in prod, people will not be regularly syncing from 0 - although Im not against making a snapshot file in the future but we still have a pretty small block file).  Could you try this, delete all the normal files from earlier, and sync to block 50,000.  When it hits 50,000 click on File | Exit (do not pkill it, otherwise the flush may be bad on the blocks).  Then copy the "blocks","Chainstate" and "evodb" out to a subfolder (like /snapshot for instance).

Then when I post the resolution, just go back to 50K and start again for each testnet session.  (You can start back at 50K by removing the blocks, chainstate, evodb- and then copying the contents of your subfolder back to the appdata directory).

What I believe happened yesterday is when I set the evodb chainheight abnheight param we were at around block 50558 and I set it for 50560, meaning it didnt have enough blocks to propogate past the minimum for a newly syncing user from 0.  Meaning that I believe your node had memorized the prior height while checking the block (this is what Ive got running now in the background to double verify this before I release a fix).  If this is the case, we will have to bump a couple params and make a new release and all ensure we synced up past this height.


Btw, once you encounter a bad block you can forget trying to test the abn feature and the antigpu, because the wallet cant find proper coin age when its out of sync (or should I say its trying to build on faulty blocks on the wrong height etc).


110
So, I'm stucked on block 50561 again.  It looks, that resync is waiting for me again. Rob, in few last days I've made more than 10 full resync (deleted everything from biblepaycore folder - like in Togos post) but it never took less than 2 hours for me.
Maybe it is problem of my PC, but we've talked about this before latest mandatory testnet.
May it be caused with mine huge activity in constant download of data from my peers? May I be blocked somehow?
Sometimes it starts withou problem, but after some time download fall to 10kB/s.
I can guarant that it is not caused with my internet connection.
I have now tho internet providers (300 Mbps and 500Mbps) and it is the same on both. So, it can be caused with my PC, but on my second PC it was the same. Slow connection with peers.

I have tried to set gen=0, but there is still problem with sync.
Here is part from my debug.log:
Code: [Select]
2019-04-28 13:55:37 ERROR: AcceptBlockHeader: block f5cbf4edfd4df18b3204ac8c72b44ba04296e0334d50a9d40e9b208f4f835913 is marked invalid
2019-04-28 13:55:37 ERROR: invalid header received

So, I'll start resync again with gen=0 and I'll see if the sync will be faster.
BTW: Rob, can you delete debug.log from WIN wallet install file?
It is in ...BiblepayEvolution\doc\ folder after install and it has more then 67MB :D I think that it is not neccessary for us ;)
There are some old logs from end of March.

Let me try to reproduce first and  Ill comment.  Maybe we can make a snapshot of the first 50,000 blocks.
The main thing is that we ensure blocks 50k+ don't have any checkblock errors in them so I dont want you to sync past any bad blocks and cover up a problem.




111
Ive tried to make masternode again now with 4500001 tBBP,
I was able to add it to masternode.conf and start it!

Now I just need to setup Watchman?

=

Also I got a popup message about masternodeblsprivkey
"BiblePay Core - Warning - You should specify a masternodeblsprivkey in the configuration. Please see documentation for help."

https://docs.dash.org/en/stable/masternodes/setup.html#generate-a-bls-key-pair

https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html#enter-the-bls-key-on-the-masternode
https://docs.dash.org/en/stable/masternodes/maintenance.html#updating-masternode-information
https://blog.dash.org/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f

Im kind of confused how the bls keypair works

"The ProRegTx contains 2 Dash addresses (also called public keys) and one BLS public key, which represent 3 different roles in the masternode and define update and voting rights. The keys are:

ownerKeyAddr: This is a Dash address (public key) controlled by the masternode owner. It is different from the address used for the collateral. Because the owner uses the private key associated with this address to issue :ref:`ProUpRegTx <update-dip3-config>` transactions, it must be unique for each masternode.

operatorPubKey: This is the BLS public key of the masternode operator. Only the operator is allowed to issue :ref:`ProUpServTx <update-dip3-config>` transactions. Because the operator key is used during live masternode operation to sign masternode-related P2P messages, quorum-related messages and governance trigger votes, the BLS key must be unique for each masternode.

votingKeyAddr: This is a Dash address (public key) used for proposal voting. Votes signed with the corresponding private key are valid while the masternode is in the registered set."
https://github.com/dashpay/docs/blob/master/masternodes/understanding.rst

=

Masternode Setup:

https://github.com/biblepay/biblepay-evolution/blob/master/BuildBiblePay.txt
Great on setting up a sanc!

So on the BLS key pair, the pro-reg, dip3, and deterministic sancs:

So we have a two step process for testnet:
Setting up a legacy cold non-deterministic sanctuary, using a masternodeprivkey only.  This is the way we have been doing it up til now (IE the old dash codebase from 2017 that is in biblepay-classic).

Step 2 (future - IE in about 1 more day):
We upgrade a legacy sanc to a deterministic sanc (also called a dip3 sanc).  These dip3 sancs do use 2 keypairs:  BLS and regular privkey, have reward addresses and voting addresses and all that other stuff. 

So what I would like to ask all of us to do is set up a *legacy* sanc first, and ensure it is running.  Then in a day or so, we will enable dip3 (after we ensure our anti-gpu and abn and all this is stable).  I will post instructions on how to upgrade , and this step will automatically create the BLS privkey and the second address.

For now you can ignore the BLS warning on boot, that is normal.




112
I was able to add it to masternode.conf and start it!

Now I just need to setup Watchman?

I believe we are the first masternode coin to have The Sentinel compiled into biblepaycore, so that means:
You do not have to install watchman-on-the-wall.  Its built in now, and its one of the things we started testing (so far successfully) but it needs a little more testing before prod.

It runs automatically also, so there are no settings to configure.




113
Ok, this is new knowledge to me :)
I don't know that it is needed to have unlocked wallet. I'll try to unlock wallet everytime I start it :)
exec setautounlockpassword your_password didn't worked for me.

Well it looks like I made the 'exec setautounlockpassword' work with GSC transmissions only (but not with ABN) so for this current version you must unlock the wallet fully to ABN mine.  (with walletpassphrase blah time).

Looking at staking (and mixing) I can see why we ended up here.  We really must ask the user to either enter the pop up password, or run a command to have the securestring key handy for ABN mining (or for gsc) to work (IE its a must).  So in light of that, that means we need to take baby step 1 and get this 'setautounlockpassword' to be respected in both places, so I will do that first.  We dont necessarily need to make the pop-up work (its a decision we can think of later) as remember about 15 pages back I explained that might be frowned upon - so for now Ill fix the consistency with this autounlock password.

Let me know if you do Not have a syncing problem also, as I really want to ensure no one has a syncing problem in Evo. 



114
Hmm it happened again, got screenshots:
https://imgur.com/a/F882yIp
looks like coins get split up into the "CHRISTIAN-PUBLIC-KEY" address automatically

You scared me a little on this one, lol, OK I reproduced it and I can see whats going on.

So to reproduce, make a new receiving address (like T101), copy the To address, paste it in a new Send To Transaction, dont click any checkboxes,
and when you click send, the "Verification" list shows a Tithe of 10% in it (but it does not actually add it to the transaction total and does not really send it).

So the bug is just a validation message bug.

(You can see in the drill in of the sent tx list its just the base tx being sent).

On a side note, the only change back to the CPK should be coming from those ABN/GSC transactions, when we create an ABN/GSC stake, we send the change back to the CPK. 

So I will add fixing this Tithe validation now to the punchlist.




115
Hi all,
finally after 1421b update I was back on chain.
I had really big problem with ABN feature and I wasn't be able to sync.
I've tried it for few days and I spent many hours with clean install and resync.
Mostly it tooks me more than 3-4 hours to reach last block, then ABN error stops me and I started whole process again.
I was really disappointed and upset :)
Yesterday I was finally synced and it looks good, but then I stopped my wallet and today it wont synced again :(
Today there is problem with antigpu:
Code: [Select]
2019-04-28 09:12:54  AntiGPU i 0.000000, CPK ygjQUutb2MnpVJKyjQ3mTne4rg71FFPcwg      ERROR: TestBlockValidity: Consensus::ContextualCheckBlock:  (code 0)
I'm stucked at block 50706, So I need to make resync again :(
That lead me to the question of whether you are thinking about creating "bootstrap.dat" copy on your servers to sync faster.
Others coins has this like common "service".

We can look at the bootstrap for prod later once we know everything is fine, but we should be able to sync in less than 15 mins in testnet, otherwise we have bigger issues.
Please try putting the 'gen=0' in your biblepay.conf first also.
If you try Togos post above, can you see if it syncs to the top without a problem? 
I am thinking this AntiGPU error in your log has to do with you solving a block before the tip then being unable to mine because its the only last block on your chain (which makes the next one from you illegal).




116
I've been trying to start a Sanctuary, but I can't seem to sync my wallets properly :(

Please try 'gen=0' in the biblepay.conf  first, then see if it reaches the top?
It is probably trying to mine every time the blocks pause.


117
Hmm it happened again, got screenshots:
https://imgur.com/a/F882yIp
looks like coins get split up into the "CHRISTIAN-PUBLIC-KEY" address automatically
Sorry for the inconvenience but the lockup was changed to 4,500,001.  The change is normal (its just giving change back from the transaction).
The lack of masternode outputs is because it didnt recognize the 4,500,000 as a collateral tx.

However I will take a look at the above posts regarding foundation tithes etc but in the mean time you should be able to create a sanc.


118
And there is also ABN error again:
Code: [Select]
2019-04-28 09:34:09
CreateNewBlock::Unable to add ABN because Sorry, must be unlocked to create an anti-botnet transaction.antibotnetsignature failed on tx baddb353bac2364d696ad7749c0237092d3e0409ee9bafd5c983144216d351dc with purported coin-age of 0.000000
2019-04-28 09:34:09 ERROR: TestBlockValidity: Consensus::ContextualCheckBlock:  (code 0)

In order to ABN mine you have to unlock the wallet :
walletpassphrase nnnnn

It appears we dont respect this command yet:
exec setautounlockpassword your_password

EDIT:  Let me take a look at blackcoin and see if its possible for us to sign the stake in a similar way without asking the user to unlock the wallet (IE for staking only) as this will be a big nuisance if we don't investigate this.



119
I don't see any other cold sancs (other than my 3 in testnet).  It's going to be hard to perform quality testing with just me on board.
Is anyone planning on starting a sanc?

Im thinking about testing dip3 sancs tomorrow.

(We need to test upgrading a legacy sanc to a deterministic sanc).


120
I just enabled our antigpu feature starting @ 50560.  This is similar to the rule we had in PODC, where a CPID could not solve any block within a 4 consecutive block lookback in prod (and 1 block in testnet).  So in Evo, this means a distinct CPK cannot solve more than 1 block per 1 block lookback in test (4 blocks in prod).

So to test this, we will do a getblock 50560, look for the CPK field, and ensure it is changing each consecutive block forward) - no back to back solutions in testnet.


Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 128