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

1.4.0.4-TestNet Mandatory Upgrade

- Enhance ABN mining (allow miner to sleep if block is not late and ABN
is insufficient, ensure all miners wake up when blocks are late)
- Enable daily superblock logic

As you upgrade each node, please re-sync.  You could be on your own chain (as this was a mandatory) and it was not released with a cutover height.

As you upgrade each node, please re-sync.  You could be on your own chain (as this was a mandatory) and it was not released with a cutover height.

Kindly confirm if this is also what you are on. The testnet network is really sparse too. Thank you.

bbpd@testnet:~$ block
4111
bbpd@testnet:~$ cli getblockhash 4111
fe1c896a86d64c3986807a33109a73a51a069c96693f9a99af71c41a9d5452bc

Kindly confirm if this is also what you are on. The testnet network is really sparse too. Thank you.

bbpd@testnet:~$ block
4111
bbpd@testnet:~$ cli getblockhash 4111
fe1c896a86d64c3986807a33109a73a51a069c96693f9a99af71c41a9d5452bc

Yes, your on it!

Yes sir exactly, let me try to explain and please let me know if I left anything out.

So now we have ABN mining enabled, and each block requires (about 5005 ABN weight according to getmininginfo).  So no block is accepted in testnet except those over 60 minutes old or those that have the weight.  You can see how much weight yours had by doing : getblock 3109.  It shows: abn-weight : 22500.42.   Thats because the coin amount spent * the age = 22500.42.

Now moving on to the actual transaction, our wallet create an "anti-botnet-transaction" by finding the stake-age, creating the transaction and placing it somewhere in the block (the reason we moved to dynamic block transaction positions, is our wallet now supports chainlocks, and ChainLock might put a transaction in vout[1], so BiblePay made it dynamic).  To find out where it is we have a field called abnlocator, you can find the value by doing a 'getrawtransaction txidvout[0] 1' (for the coinbase transaction) and looking at that transactions output fields, for ablocator, and then get the value and it points to "where" your signed stake is.

As far as the monetary value, the stake was for 30953, but note - all abn transactions are sent to self, so you actually received it all back (IE you spent  , received 30953 + the block reward).  (You also keep the tx-fee because the staker is the solver).

We have very high security on this feature also, as evo doesnt ever allow double spends or malleability, we dont allow stakes sourced from stakes, stakes make people lose coin age, we verify the signature, and also, we verify the solver is the one who created it, so in my experience I feel this is a solid feature.

I also love how it will use up the coin-age for a person who has a couple hundred PCs!  That gives more distinct users to biblepay.

We should also thank MIP and give him half of the credit, because although we spoke about this back when we were designing POL, I forgot about it until he reminded me recently.

May I have few questions?

1. You say ABN weight is about 5005.  His stake was 30953. Is it because he did not have a coin with lower value?

2. From this it seems beneficiary to have multiple smaller coins, otherwise all larger ones would be spent on mining. Is exec bankroll working in evolution?

3. iI the ABN weight moving automatically or is it a static setting?

4. you wrote "we dont allow stakes sourced from stakes". Does this mean that if a coin is spent on a stake, it cannot be spent on another stake again, even after it ages out?

May I have few questions?

Please see inline:

1. You say ABN weight is about 5005.  His stake was 30953. Is it because he did not have a coin with lower value?
->  Yes, his lowest coin * age was 30953.  If he had smaller coins it would have used those instead.


2. From this it seems beneficiary to have multiple smaller coins, otherwise all larger ones would be spent on mining. Is exec bankroll working in evolution?
->  Imho, I think in prod, the average coin will be more like 5000 due to the spending and rewards, and requirements so much higher it will always take multiple coins to make a stake --   and in this system, it automatically combines multiple coins to make a stake.  We don't have exec bankroll in evo.  I cant think of a reason we need it (for this use case).  But, we could port it though just to have it so we can consolidate coins easier for people with a lot of change, but even that case is not really going to happen much, since both ABN and GSC-POG makes a lot of consolidated change back to the wallet, so technically in evo, we will have tidy consolidated wallets all the time.

3. iI the ABN weight moving automatically or is it a static setting?
-> Its not completely static.  Its a spork setting.  But, Im thinking in prod it will be more like 100,000 as its most likely best to set it to be a factor of our money supply and the average capital reqd to solve one block per day, for example.   (EDIT: I think it has to be toward the low end closer to 100K so that smaller users can also mine).

4. you wrote "we dont allow stakes sourced from stakes". Does this mean that if a coin is spent on a stake, it cannot be spent on another stake again, even after it ages out?
-> You can re-spend the output of a stake in another block.  I just meant from a security perspective with Evo it wont be possible to do any funny business like that.

EDIT:

Ill need to release a mandatory upgrade tomorrow morning to ensure everyone is on the same chain.  We have too many old versions floating around.

On TestNet...Can you please send tBBP: ygM8C2FbeMxSCd77TNZNAyTUmym9nwgCFL

On TestNet...Can you please send tBBP: ygM8C2FbeMxSCd77TNZNAyTUmym9nwgCFL

Welcome aboard; please hang on.

I noticed last night an unusually high amount of spam in our debug logs.

Let me take care of this spam, the mandatory upgrade version, and anything that looks strange, and then make a release for testnet.

ETA about 3 more hours.

EDIT:

Ill need to release a mandatory upgrade tomorrow morning to ensure everyone is on the same chain.  We have too many old versions floating around.

Dear Rob,
Thank you for all your hard work that MIP and you and others have put into the development and maintenance. Glad to help and be part of testnet.
Can I make one small suggestion, if I may?  Each time after a Mandatory Update - at least on Testnet where this is so frequent - can you kindly post the latest block and blockhash so that we can all periodically check that we are on the right chain as we may have missed these frequent updates as we were away or something.
That would be greatly appreciated! Thank you.

Dear Rob,
Thank you for all your hard work that MIP and you and others have put into the development and maintenance. Glad to help and be part of testnet.
Can I make one small suggestion, if I may?  Each time after a Mandatory Update - at least on Testnet where this is so frequent - can you kindly post the latest block and blockhash so that we can all periodically check that we are on the right chain as we may have missed these frequent updates as we were away or something.
That would be greatly appreciated! Thank you.

Yes, will do.  I already realize that this needs done, but what intereferes in testnet, sometimes our testnet chain legally continues after I shut my nodes down.  Meaning that you guys are technically the ones that should post a good hash on the forum once all the nodes resync (as sometimes its out of my control).

But anyhow, in this case, we are making a mandatory that will require us all to delete our cached gov objs, and resync, so I think in this case I will be able to post a good hash after we all upgrade.

Building...

1.4.0.5 - TestNet Mandatory Upgrade

- 2 min testnet blocks in testnet after block 5000 (diff was too low for
anti-fork code)
- Remove log spam
- Add GSCTransmission icon to txlist
- Fix getchaintips
- Add end_epoch to GSC Smart contract (prevents a type of validation
error)
- Verify CPK is in good standing before transmitting a GSC transmission
- Correct block subsidy on GSC server side total to account for first
reward
- Disconnect old versions (prior to 1405 in testnet)
- Add feature to logger to prevent duplicate log rows


** Critical instructions for upgrade:  Please clean the blocks data first, then restart the node, and in addition please ensure you delete these governance files:


rm blocks -r
rm chainstate -r
rm evodb -r
rm gov*
rm mnc*
rm mnp*



(One of our superblock calculations was incorrect -- and its cached in our nodes, hence the reason we went off the rails, so now we have to ensure this data is deleted before restarting).

The chain is rolling back to block 3500 or so, will post a hash.

I'm in agreement on 3 nodes:


getblockhash 3550

c4dafb2ddfa0a3f734fda2049c1a54ad46b4b87d19e0c11ac1d0cca6ac5d3812


Please ensure your sancs have enough collateral (if you started them after 3550) and that you rejoin the pog campaign if you joined after 3550.

Also, please re-enter any proposals again.  I re-entered one.

On TestNet...Can you please send tBBP: ygM8C2FbeMxSCd77TNZNAyTUmym9nwgCFL

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

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