TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

[Rob Andrews]

And there is also ABN error again:

Code Select Expand

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.

[Rob Andrews]

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.

[Rob Andrews]

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.

[Rob Andrews]

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 Expand

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

[Rob Andrews]

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.

[orbis]

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.

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.

[Rob Andrews]

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. 

[orbis]

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

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 Expand

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 I think that it is not neccessary for us
There are some old logs from end of March.

[togoshigekata]

Thanks for looking into things Rob!

=

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. 

1. So this coin splitting behavior is intended and happens automatically every so often? when mining? (and every wallet is now set to mine by default?)
1.a. Is an amount of 4500001 ignored for coin splitting? when user is setting up a masternode?
1.b. Does this mean new miners have to own some amount of BBP coins in their wallet to participate in mining? (but they can jump in to mine when block hasnt been solved for 60 minutes if they dont have coins?)

2. Also for the CPK, I noticed that I never ran a command (exec cpk my_nickname) to create one, is default behavior that one is created automatically? And the command is to just add a nickname to it?

=

Just poking around the documentation:

https://wiki.biblepay.org/Getting_Started_with_Evolution
https://wiki.biblepay.org/Generic_Smart_Contracts

GSC (Generic Smart Contract)
"The GSC is split into a client server architecture. The client side user joins campaigns with a CPK (Christian Public Keypair) and competes in these campaigns for points. The server side (our Sanctuaries) assess user points and tracks user progress. Once per day, the points are converted and paid in a Generic Smart Contract. The GSC is voted on by the Sanctuaries automatically at a certain chain height. The GSC is paid once per day as a superblock from BiblePay core, and is split among campaigns by points rewarded per campaign per user. "

ABN (Anti-BotNet)
"which requires a certain amount of coin*age to be present in each mined block in order to mine BiblePay"
"Our network requires an average calculated and pre-assessed static amount (posted in getmininginfo) of required coin*age and stores this in the chain. Each miner checks this number, and will search the wallet (this is all automatic) for coins totaling the requirement and place these coins in an ABN Stake transaction - and then begin mining"

=

3. Is the ABN Stake transaction just coins going to the CPK address?
3.a. I havent noticed any of the CPK address transactions in my Transactions list, filter set to All, but I do notice coins moving around in Send >> Inputs (Settings >> Options >> Wallet >> Enable coin control features)

[togoshigekata]

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

These are my old Masternode setup notes:
https://forum.biblepay.org/index.php?topic=190.msg3701#msg3701
https://forum.biblepay.org/index.php?topic=108.msg1444#msg1444

Attempt to use VNC:
https://forum.biblepay.org/index.php?topic=244.msg4525#msg4525
https://forum.biblepay.org/index.php?topic=244.msg4523#msg4523

Masternode guide:
http://wiki.biblepay.org/Create_Sanctuary_2

[togoshigekata]

Sorry for providing too little information about the Watchman environment; let me try to explain.

In Prod, we are running a 1.5 year old codebase with Dashs Sentinel in Python (we renamed it Watchman-on-the-wall) - and we still use it in prod as-is from Dash (and its still required today since it helps create the budgets etc, creates watchdogs, etc).

In Evo, I have not ported Sentinel to Watchman yet (so its unavailable still), so we do not have to Test it yet.

What I'm considering however, is porting Watchman to c++, so we don't have to run both watchman and Evo as separate programs in each sanc (in the future).  (Thats what this release info was about, but - its really just in step 1).  I'm still going to do some internal testing on my end, then provide more info as how we can test the integrated version of watchman, so please don't worry about testing that yet.

[Rob Andrews]

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.

[Rob Andrews]

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.

[Rob Andrews]

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 Expand

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 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.

[togoshigekata]

Awesome, Thanks Rob!
Thank you for all of your hard work!
This is exciting!