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

Started by Rob Andrews, March 24, 2019, 01:17:09 PM

Previous topic - Next topic

Rob Andrews

#285
Quote from: orbis on April 28, 2019, 09:12:37 AM
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:
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).


orbis

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

Rob Andrews

Quote from: togoshigekata on April 28, 2019, 01:57:13 PM
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?




Rob Andrews

Quote from: orbis on April 28, 2019, 02:40:47 PM
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.


Rob Andrews

Quote from: Rob Andrews on April 28, 2019, 02:44:01 PM
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.


togoshigekata

Quote from: Rob Andrews on April 28, 2019, 02:41:11 PM
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?

Im in agreement on blockhash for 52240
My masternode IP is:  108.61.194.83
I see 4 ENABLED masternodes

I never registered my cpk, so I just ran "exec cpk togo"

How do you view the leaderboard?
"exec prominence" is not working for me "Command not found"

Also do I need to run "exec join pog"?
Are POG and ABN different things?

Rob Andrews

Quote from: togoshigekata on April 28, 2019, 03:13:13 PM
Im in agreement on blockhash for 52240
My masternode IP is:  108.61.194.83
I see 4 ENABLED masternodes

I never registered my cpk, so I just ran "exec cpk togo"

How do you view the leaderboard?
"exec prominence" is not working for me "Command not found"

Also do I need to run "exec join pog"?
Are POG and ABN different things?

Ok great, just checking for my own sanity cause 5 participants seemed rather lonely.
Yes, I see your 108.61 as enabled, good deal.

So, when you ran the 'exec cpk togo' that did register your CPK.  (The Christian-Public-Keypair Address book entry can actually get created by another process, Ill explain that in the post when I reply to your other post).

So the exec prominence was changed to rpc command: leaderboard  (for ease of use).  Now you should see about 5 in there, but you will have to do a:
exec join pog
First, and then force out a GSC to get in the next superblock (exec sendgscc true). 

You can also view the leaderboard in QT by clicking "Leaderboard" (its like our old pog view).


So once you have a CPK, you are basically just in our list of CPKs (that lets you vote on future things and gives you voting weight depending on how much your average stake is).  You have to join pog in order to actually send GSC transmissions.

POG & abn are different:  POG is BiblePay campaign #1, proof-of-giving, its a hybrid stake/giving campaign requiring coin*age to get rewards, and a small component of it is POG (donations to the foundation).  These transmissions are one type.  ABN is another.

ABN is strictly for POW miners.  It adds the requirement to POBH mining to have coin age in each solved block.  So when your wallet is about to solve a POBH, it adds on the ABN with coin*age in it.  So each of these require distinct unlocks of the wallet for them to be successful.

Im adding the code now to support the autounlock command so people can type that in every time they boot.


Rob Andrews

Quote from: togoshigekata on April 28, 2019, 10:12:36 AM
Thanks for looking into things Rob!

=

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)
On coin splitting -  There is no actual splitting.  We are just sending the transactions change back to you when you break a bill (the same as classic does).  The only new thing to know is if your wallet is about to create a GSCC transmission for the POG (or other) campaign(s), if it assembles a 1 million coin*age stake by using 1.1 million in coins, the 100,000 of change is sent back to your CPK (Christian-Public-Key) address.  This also happens if you make a 1.1 million ABN stake - the leftover change is sent back to your 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?)"
->  This ABN transaction only occurs if you solve a POBH block, or create a new GSCC transmission.  These GSCCs are sent once an hour in testnet, and once every 24 hours in prod.

1.a. Is an amount of 4500001 ignored for coin splitting? when user is setting up a masternode?
->  Yes, any normal send from the Send UI works as classic does (no splitting, no difference in change, etc).


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?)
->  Yes, if the block is > 60 minutes (late block threshhold = true), anyone can mine it.  But yes, with ABN enabled on the network, with a 1000 minimum ABN weight, every mining use must have coin*age to mine.  So yes they would actually need biblepay to mine a POBH block.

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?
->  So on the CPK auto creation, when the wallet tries to mine, it realizes you had some coin*age for the ABN but you didn't have a CPK yet.  So it pre-created the wallet receive address for the CPK (and it is smart enough to re-use it when you register your cpk), so this is OK and normal.  This way it can re-access it for every ABN it tries to make.  (This also because you can mine BBP with just a plain old wallet with 5K in it for example and dont have to register your CPK or join any projects if you want to be simple).  I know we added a step to require BBP to mine BBP, but this is a tradeoff to enable the anti-bot-net weight rules.

Basically, we can make it harder for rich miners with hundreds of servers to keep pinching out the newbies if we ratchet up the minimum ABN weight requirement.



orbis

Stucked again.
Block 50564.
log:
2019-04-28 20:52:36 {PNB}: ACC 
ContextualCheckBlock::ABN ERROR!  Block 50564.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000, RequiredWeight 1000.000000ERROR: AcceptBlock: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 20:52:36 Misbehaving: 193.187.180.41:40001 peer=1 (0 -> 1)
2019-04-28 20:52:36 ERROR: ProcessNewBlock: AcceptBlock FAILED: low-abn-weight, Insufficient ABN weight (code 16)

But good news is that my backup works :D
But....
next stuck block 50589:
2019-04-28 21:05:47 {PNB}: ACC 
ContextualCheckBlock::ABN ERROR!  Block 50589.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000, RequiredWeight 1000.000000ERROR: AcceptBlock: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 21:05:47 Misbehaving: 108.61.194.83:40001 peer=5 (0 -> 1)
2019-04-28 21:05:47 ERROR: ProcessNewBlock: AcceptBlock FAILED: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 21:05:47  AntiGPU i 0.000000, CPK yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe      UpdateTip: new best=ffd3388b019833152c97333ad0b92c682decb88d52a0c2915d0c28197d078766 height=50543 version=0x20000001 log2_work=45.94637348 tx=143538 date='2019-04-27 21:55:43' progress=0.994223 cache=0.0MiB(0txo)
2019-04-28 21:05:48 {PNB}: ACC   AntiGPU i 0.000000, CPK ygavD5YuAJXpHDMLRyiiJ199YM5y9fTWfB      UpdateTip: new best=639d36532617d90194c7cb36e05e4c6b6130671377871fc2c054543eecd8a6bd height=50544 version=0x20000001 log2_work=45.94637566 tx=143540 date='2019-04-27 21:56:10' progress=0.994225 cache=0.0MiB(0txo)
2019-04-28 21:05:48 {PNB}: ACC  ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)

BTW: now i have gen=0 and unlocked wallet

Rob Andrews

Quote from: togoshigekata on April 28, 2019, 10:12:36 AM
Thanks for looking into things Rob!


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)

On #3,  Yes, its as if your wallet is finding enough coin*age, taking those coins, making a transaction to yourself, and sending those to your CPK address (which proves you owned that much coin*age).  It only does this however if you solved that POBH block.

On #3a, We do not show the ABN tx as a separate row on the txlist (because then you would see two entries for every block mined).  (This is the same behavior as we see in blackcoin and other staking systems) - it looks really cluttered if we do that.  You can see the tx though if you double click your mining reward, we show the debug info.  You can also get the txid and type : getrawtransaction txid 1, and see all the coins it used for the stake.



Rob Andrews

Quote from: orbis on April 28, 2019, 04:14:57 PM
Stucked again.
Block 50564.
log:
2019-04-28 20:52:36 {PNB}: ACC 
ContextualCheckBlock::ABN ERROR!  Block 50564.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000, RequiredWeight 1000.000000ERROR: AcceptBlock: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 20:52:36 Misbehaving: 193.187.180.41:40001 peer=1 (0 -> 1)
2019-04-28 20:52:36 ERROR: ProcessNewBlock: AcceptBlock FAILED: low-abn-weight, Insufficient ABN weight (code 16)

But good news is that my backup works :D
But....
next stuck block 50589:
2019-04-28 21:05:47 {PNB}: ACC 
ContextualCheckBlock::ABN ERROR!  Block 50589.000000 does not meet anti-bot-net-minimum required guidelines: BlockWeight 0.000000, RequiredWeight 1000.000000ERROR: AcceptBlock: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 21:05:47 Misbehaving: 108.61.194.83:40001 peer=5 (0 -> 1)
2019-04-28 21:05:47 ERROR: ProcessNewBlock: AcceptBlock FAILED: low-abn-weight, Insufficient ABN weight (code 16)
2019-04-28 21:05:47  AntiGPU i 0.000000, CPK yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe      UpdateTip: new best=ffd3388b019833152c97333ad0b92c682decb88d52a0c2915d0c28197d078766 height=50543 version=0x20000001 log2_work=45.94637348 tx=143538 date='2019-04-27 21:55:43' progress=0.994223 cache=0.0MiB(0txo)
2019-04-28 21:05:48 {PNB}: ACC   AntiGPU i 0.000000, CPK ygavD5YuAJXpHDMLRyiiJ199YM5y9fTWfB      UpdateTip: new best=639d36532617d90194c7cb36e05e4c6b6130671377871fc2c054543eecd8a6bd height=50544 version=0x20000001 log2_work=45.94637566 tx=143540 date='2019-04-27 21:56:10' progress=0.994225 cache=0.0MiB(0txo)
2019-04-28 21:05:48 {PNB}: ACC  ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)

BTW: now i have gen=0 and unlocked wallet

Yes, sorry, I was not clear  - actually I never got back to you yet :),  lol, we do need an upgrade here because I confirm that the height issue introduced about 48 hours ago causes all people who have to sync from below 50K to get stuck at your height, but the people already running are still running, thats why you are pulling your hair out.

Im working on trying to get the other suggestions in at the same time (like the autounlock feature).


So, Im glad you have your backup though to fall back to.  Ill notify asap as soon as its ready.






togoshigekata


Rob Andrews

Quote from: togoshigekata on April 28, 2019, 04:27:51 PM
Thank you for answering all my questions Rob!

No problem, so while we are discussing splitting, MIP had also asked about this, can we potentially not send the stake back to the CPK, but instead to an anonymous change address.  I investigated that today, and there are many issues here that surface - for one in order to prove that the CPK (who is registered) actually staked the amount, we currently send the coins to our own CPK and when we check the sig, we verify the recipient sig is the one who signed the coins.

So, although we could make a whole new scheme, I want to explain, my idea in the future is to take the average amount staked to each CPK per day, and use that for the CPKs voting weight (for those Christian object votable lists).  And for non-sanc polls (such as multi-choice community steering polls).  Another words, in this system we expose the users average free balance for voting weight.

So Im thinking what we do is when we create our training manual - for security concious individuals concerned with anonymity, we create a use case where users will generally create sancs with their anonymizable balances and lock those.
Then the non-anon part of Biblepay is your free balance.  This is used for GSC campaigns, mining, ABN staking, and voting. 

So I think this idea works relatively well to appease concerns from both camps.  We need to be anon-concious for investors, but we also need to be spreading the gospel and doing the cool things necessary on the public side with the CPKs.

The primary change in the future to make this a reality is to explain to the anon camp they will need to create cold storage addresses for their sanc outputs (not send them back to the hot wallet where our GSC will pick them up and convert them to CPK funds).



orbis

Quote from: Rob Andrews on April 28, 2019, 04:19:38 PM
Yes, sorry, I was not clear  - actually I never got back to you yet :),  lol, we do need an upgrade here because I confirm that the height issue introduced about 48 hours ago causes all people who have to sync from below 50K to get stuck at your height, but the people already running are still running, thats why you are pulling your hair out.

Im working on trying to get the other suggestions in at the same time (like the autounlock feature).


So, Im glad you have your backup though to fall back to.  Ill notify asap as soon as its ready.
I can confirm that it's impossible to get over it (I've tried it so many times, but still nothing) :)
In the meantime, while I'll be waiting for mandatory I have few cosmetic update tips :)
1. I've looked so many times on "synchronization screen" that I realized it is based on biblepay-light theme and it would be better to have it based on biblepay-traditional theme, because it's more bezaleel friendly visual.
You can see it side by side here: https://prnt.sc/ni1npi
2. Other thing which disturbs me is min window height in bezaleel theme. It's 855px and it's impossible to make it smaller. When you change it to traditional theme it's only 740px which is better to me, but I think it can be even lower :)
Side by side here: https://prnt.sc/ni1p7r
3. Leaderboard button should be on left menu (like with POG).
4. Leaderboard sorting is not going well. It sorts badly. Try to sort it and it sorts based on first digit not by whole number. I haven't screenshot, because I'm not able to sync, byt you can try it :) This problem was in POG leaderboard too, but if I remember correctly MIP repaired it.
5. Leaderboard doesn't respect window width and when the window is smaller it just put there horizontal scrollbar. E.g. columns in tx view adjust their width based on window width and there is only vertical scrollbar. Maybe this problem is in other views (maybe proposals) but I'm not synced to confim that.

Maybe more tips will be after I'll be synced after new mandatory release :)

Rob Andrews

Quote from: orbis on April 28, 2019, 05:16:24 PM
I can confirm that it's impossible to get over it (I've tried it so many times, but still nothing) :)
In the meantime, while I'll be waiting for mandatory I have few cosmetic update tips :)
1. I've looked so many times on "synchronization screen" that I realized it is based on biblepay-light theme and it would be better to have it based on biblepay-traditional theme, because it's more bezaleel friendly visual.
You can see it side by side here: https://prnt.sc/ni1npi
2. Other thing which disturbs me is min window height in bezaleel theme. It's 855px and it's impossible to make it smaller. When you change it to traditional theme it's only 740px which is better to me, but I think it can be even lower :)
Side by side here: https://prnt.sc/ni1p7r
3. Leaderboard button should be on left menu (like with POG).
4. Leaderboard sorting is not going well. It sorts badly. Try to sort it and it sorts based on first digit not by whole number. I haven't screenshot, because I'm not able to sync, byt you can try it :) This problem was in POG leaderboard too, but if I remember correctly MIP repaired it.
5. Leaderboard doesn't respect window width and when the window is smaller it just put there horizontal scrollbar. E.g. columns in tx view adjust their width based on window width and there is only vertical scrollbar. Maybe this problem is in other views (maybe proposals) but I'm not synced to confim that.

Maybe more tips will be after I'll be synced after new mandatory release :)

I have #3 already, and I think Marcus can probably do #1 if  hes working on the new Bezaleel now, but Ill take care of all the rest for the next release.