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

exec prominence shows empty list now for me:

Code: [Select]

biblepay-cli exec prominence
{
}

getblockhash 4109
341d64d1b90f739dd16500834dffea8e6a4cc3bc514a8ebf0f9fd8467c077de1

exec prominence shows empty list now for me:

Code: [Select]

biblepay-cli exec prominence
{
}

getblockhash 4109
341d64d1b90f739dd16500834dffea8e6a4cc3bc514a8ebf0f9fd8467c077de1

Yeah, this is because most of our testnet members lost most of their coin-age, and their miner has not sent a new GSC transmission since, so therefore that particular superblock was empty.  I just set the spork to make our gsc transmissions more frequent for now (once an hour) - but this requires you to reboot the wallet.

(Next version has a command to send a GSC manually also btw).

So far it looks like we are staying in sync now.

Btw your hash matches.  I did receive a payment in the first superblock, and like everyone else waiting for the next GSC transmission.

OK, seems I am back on the correct chain.

How come that I lost most of my tBBP in the meantime ? (over 2 000 000)
I deleted all files except wallet.dat before starting the newest version.

I see many debit transactions like these:

Code: [Select]

{
    "account": "",
    "address": "yPpyP7oXSH4e5jq8kQuCYFdDnDFbX1B7xU",
    "category": "send",
    "amount": -407184.34410700,
    "label": "CHRISTIAN-PUBLIC-KEY",
    "vout": 1,
    "fee": -0.00500000,
    "confirmations": 0,
    "instantlock": false,
    "Anti-BotNet-Transaction": true,
    "trusted": false,
    "txid": "a559a4c16f2c1f6a937412620538da1d0cb4f1dd10fddf7d61b432b0c43d500d",
    "walletconflicts": [
    ],
    "time": 1553805526,
    "timereceived": 1553805536,
    "abandoned": false
  },

there are no matching credit transations for those..

We rolled back 24 hours primarily because I found that the first superblock created had a piece of bad business logic for the first amount, so I moved back to before that first superblock.

Your wallet probably has some orphaned debits, just restart with:
-zapwallettxes=1

And they should then be free.

We rolled back 24 hours primarily because I found that the first superblock created had a piece of bad business logic for the first amount, so I moved back to before that first superblock.

Your wallet probably has some orphaned debits, just restart with:
-zapwallettxes=1

And they should then be free.

right, -zapwallettxes=1 helped, thanks!

I lost most of my non-sanc funds; sent 125k to start.  Please remind us in another 500 blocks and we can send more.

Thanks Rob... Got the TestNet payment...Looks like I will have plenty tBBP from mining payments..

getblockhash 4316 - d111449fa5aa59f9c042eab06cfdb053f2e5703ca0ea38db70cb2cb3910ed362

 ...Look ok?

Thanks Rob... Got the TestNet payment...Looks like I will have plenty tBBP from mining payments..

getblockhash 4316 - d111449fa5aa59f9c042eab06cfdb053f2e5703ca0ea38db70cb2cb3910ed362

 ...Look ok?

Yes, perfect.    If you need any more I have more now, please dont hesitate to ask.

I wanted to clarify one nice thing about ABN, as I think we have people under the 'perception' that ABN uses up all your coin-age and you can't participate in a GSC campaign (like POG) because you now lack coin-age.

This is primarily not true - first of all ABN only uses up coin-age if you solve a block.  So it stifles the success of a bot-net miner by using up coin-age *as* they solve blocks.

For a normal miner, who isn't actually solving many blocks, the coin-age is not spent (as we only add it to the block once and it is freed after each block ticks by), so another words, the average user will be able to participate in GSC's with almost full coin-age. 


On a side note, I've disabled most of our features temporarily while we test proposals, GSCs, GSC transmission and payments.
We can then isolate some of our other features and test them in distinct phases.

We were doing great til about block 5000, cat debug.log | grep bits

Something went wrong with DGW.   Will check in the morning...

We were doing great til about block 5000, cat debug.log | grep bits

Something went wrong with DGW.   Will check in the morning...

So just to explain whats going on over here, I believe DGW is not a cause but an effect.  It looks like the problem started at block 4940 (that is the forkpoint).
Basically, we had 3 sancs online (I think all 3 were mine at the time as it was early in the game). 

Sanc #1 had 8 triggers in memory for block 4940 (this was a gsc superblock), and 7 of them had some type of epoch time issue - (that is problem #1; first of all we need to fix this problem - I do have a log of this issue so I will fix this first, meaning the IsSuperblockTriggered will not complain about the event_block_height not matching the start_epoch blockStart).

Next problem, our minimum vote quorum level is 20% net yes in testnet, but this is only .60 in testnet with 3 sancs (we do have a floor of 2 for Creation, but not for Superblock Triggering) another words, this needs beefed up and standardized so that both creation requires a better minimum and also triggering matches the same number (it does not match).  In prod this wont be a problem because we will be dealing with a much bigger number, like 80 sanctuaries for example.  So I will move the floor to 3 in testnet, and standardize the agreement on the trigger also - this would have prevented Sanc #1 from actually emitting the superblock.

As far as the fork itself, Sanc #1 emitted the superblock, the others rejected it -  (I can see from sanc #2s log at 4940 that it says, Superblock Not triggered - normal block) (This is where things get bad), so basically half of the network accepted the superblock, and this forked the chain at 4940, the other 2 sancs banned my sanc, and split the network.

Im also going to move sanc #1 to the cloud so as to standardize the connectivity (as I see a strange DNS problem on sanc #1 also).

As you can see I have a lot of work to do, so it is no longer necessary to continue testing until we have another release.
Thanks for everyones help so far.

I'll post again when the next version is ready.  I'm going to attempt to test the first superblock alone to make sure everything is sane.

I'll post again when the next version is ready.  I'm going to attempt to test the first superblock alone to make sure everything is sane.

So, I don't want to release an official testnet release until this superblock issue is tested, but I will release an alpha tonight for the brave users.

Anyone who feels like jumping in early can upgrade (after I post the release version in about 30 mins), testing is purely to help us reach block 5000.
If everything goes well we can stay on the chain.

NOTE:  It is Extremely important to follow these directions before you upgrade:

cd testnet3
rm blocks -r
rm chainstate -r
rm evodb -r
rm mnc*
rm mnp*
rm gov*
cd ../SAN
rm pra* <-- Extremely important, you must remove the prayers file, as it contains cached campaign data that must be removed for testing to be successful
optional: rm testnet wallet.dat (this will just clean up the txlist and make it a smaller file.)

In this version, we needed to reset the chain again, primarily because of a change I made to DGW for testnet (to clean it up while our engine is on the floor).
So this means we also have to re-create our sancs.

I've recreated 3 new sancs in the cloud this time for more reliability, and we are synced up to block 2266 so far.

Linux users, you can get the latest now if you want, or wait until the alpha test is finished.

Remember we also must recreate our CPK (exec cpk nickname), and (exec join pog).

1.4.0.6b-TestNet Mandatory Upgrade

- Remove log spam
- Standardize minimum quorum level for both creating and emitting GSC
superblocks
- Require the minimum quorum in IsSuperblockTriggered for GSCs
- Change DGW for testnet to be more straightforward
- Fix bug in getchaintips where it does not show correct branch length
- Allow miner to know if ABN weight is sufficient when abn is off

So, I don't want to release an official testnet release until this superblock issue is tested, but I will release an alpha tonight for the brave users.

Anyone who feels like jumping in early can upgrade (after I post the release version in about 30 mins), testing is purely to help us reach block 5000.
If everything goes well we can stay on the chain.

NOTE:  It is Extremely important to follow these directions before you upgrade:

cd testnet3
rm blocks -r
rm chainstate -r
rm evodb -r
rm mnc*
rm mnp*
rm gov*
cd ../SAN
rm pra* <-- Extremely important, you must remove the prayers file, as it contains cached campaign data that must be removed for testing to be successful
optional: rm testnet wallet.dat (this will just clean up the txlist and make it a smaller file.)

In this version, we needed to reset the chain again, primarily because of a change I made to DGW for testnet (to clean it up while our engine is on the floor).
So this means we also have to re-create our sancs.

I've recreated 3 new sancs in the cloud this time for more reliability, and we are synced up to block 2266 so far.

Linux users, you can get the latest now if you want, or wait until the alpha test is finished.

Remember we also must recreate our CPK (exec cpk nickname), and (exec join pog).

If you send some tBBP, I can set up a sanc, if needed. or else, will just roll in testnet with zero.
yMSnfBPVTqdstm2grmztDxmxqkLdPzJCJG

Thanks!

If you send some tBBP, I can set up a sanc, if needed. or else, will just roll in testnet with zero.
yMSnfBPVTqdstm2grmztDxmxqkLdPzJCJG

Thanks!

oh, that's strange, I got block reward without even staking (I have zero in the wallet).

should be on the same chain as I can see your 3 sancs

getblockhash 4297
7b8125733561d649d5a89694dc8e0f7509abae344e7a4da9b5a233911b04bc30

If you send some tBBP, I can set up a sanc, if needed. or else, will just roll in testnet with zero.
yMSnfBPVTqdstm2grmztDxmxqkLdPzJCJG

Thanks!

Thanks!  Sent in 2Tx.

On a side note, so far things are looking good (knock on wood).

We made it through the first superblock, all nodes are in agreement, all 3 sancs are up and none are banned, the network did not split, and we are 50 blocks in towards the next superblock.

I see a couple (very minor things that we can fix) on a side note, I see that none of my nodes have been sending gsc updates (this would be a good time for us to go over the rules and the overrides anyway), so Im not sure if Ill be in the next superblock but we have 150 more blocks to make attempts to enter it.

The other thing is its pretty obvious that its hard to get good reporting at this stage, so I need to look into making a better report to see whats happened over the last few superblocks.

So far its probably safer for more to come onboard, but lets see what happens.

One other bug I noticed:  I can see in the 'exec datalist cpk' list, that the CPKs do have nicknames (I see uptime, randrews, etc), but in exec prominence there are no nicknames.  Ill be sure we fix that again.

Edit:
 
To be more specific on an emergency wishlist:
- 1. Add the nickname to exec prominence and exec getcampaigns
- 2. Add a parameter to exec prominence to show the contents of the *next* superblock (maybe this should be the default).  Right now the default is to show the contents of the *last* superblock.  (This would allow us to see changes that are occurring, for example, if you sent a second gsc update in one day, your total points and payments would increase in the dynamic report).