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

[Rob Andrews]

just one small bug
the info/staff on this popup windows is not updating acordanly to status bar on the main window.

Thats because any block less in duration than 60 mins is "the end" according to our progress bar, but, I believe as soon as the Sanctuary sync process starts, this is cleared, so I think this is not a live bug, but Ill keep an eye on it, thanks.  Im pretty sure Ive seen this but it clears after a couple more mins.

[Rob Andrews]

Proposal appears to be successfully made. If you need me to set up another sanctuary, vote for or else vote against.

Thanks a lot, voted on it!

[Rob Andrews]

Interesting, this appears to be the anti-botnet feature you implemented, Rob.

Can you kindly explain what is happening? It appears that I staked BBP to mine a block?
So in this example, I staked 30,953 BBP to mine a 10,300 BBP block?

{
    "account": "",
    "address": "ybEzAPVjwGqqDVKHsJZUoDG82jpiGPcKMg",
    "category": "immature",
    "amount": 10299.50936000,
    "vout": 0,
    "confirmations": 1,
    "instantlock": false,
    "generated": true,
    "blockhash": "0dbfcd1587816e0516b8928ca53ca022ce95261be90c3b8a6f65bc3908a9cdf9",
    "blockindex": 0,
    "blocktime": 1553749516,
    "txid": "e69ed826877f71811361a12aef4702f9b3a2ad915caf8caef7c62e9779ffe5d3",
    "walletconflicts": [
    ],
    "time": 1553749516,
    "timereceived": 1553749532
  },
  {
    "account": "CHRISTIAN-PUBLIC-KEY",
    "address": "yMjm7qwu2pQ3xRwtxu6qcGrdzdtCTPgcU4",
    "category": "receive",
    "amount": 30953.52702350,
    "label": "CHRISTIAN-PUBLIC-KEY",
    "vout": 0,
    "confirmations": 1,
    "instantlock": false,
    "Anti-BotNet-Transaction": true,
    "blockhash": "0dbfcd1587816e0516b8928ca53ca022ce95261be90c3b8a6f65bc3908a9cdf9",
    "blockindex": 2,
    "blocktime": 1553749516,
    "txid": "9a5ce7d79cf10d36c232e73fe480b26dc2b69132b50955519eb13ea92fb90679",
    "walletconflicts": [
    ],
    "time": 1553749516,
    "timereceived": 1553749532
  },
  {
    "account": "",
    "address": "yMjm7qwu2pQ3xRwtxu6qcGrdzdtCTPgcU4",
    "category": "send",
    "amount": -30953.52702350,
    "label": "CHRISTIAN-PUBLIC-KEY",
    "vout": 0,
    "fee": -0.00500000,
    "confirmations": 1,
    "instantlock": false,
    "Anti-BotNet-Transaction": true,
    "blockhash": "0dbfcd1587816e0516b8928ca53ca022ce95261be90c3b8a6f65bc3908a9cdf9",
    "blockindex": 2,
    "blocktime": 1553749516,
    "txid": "9a5ce7d79cf10d36c232e73fe480b26dc2b69132b50955519eb13ea92fb90679",
    "walletconflicts": [
    ],
    "time": 1553749516,
    "timereceived": 1553749532,
    "abandoned": false
  }
]

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

[Rob Andrews]

** GSC Update **

Overall I'm pretty excited that we are making 'normal' progress for the most part.
Good and not-perfect news. 
The good news is block 3095 (our last superblock) was voted on by 3 sancs, so it had 3 votes, and technically it should have emitted, but-- 3095 was a regular block.  Its hard to say exactly why it didnt emit, it could either be not running watchman (doubtful that is the issue), or could be something to do with the height being a daily height, anyway I'll research this in detail now and find out what happened to our payments.  So at this point everyone who was waiting for the daily got skipped and now we are waiting for block 3300 (although we don't want to hold our breath, as the problem now needs solved for 3300 to work).
On the bright side, our blocks become 1 minute blocks after height 3200 so testing should start zipping by faster with faster progress.

According to getgovernanceinfo, we have until height 4305 for our 'monthly' superblock - thats when we see the outcome of our QT proposals.

Ill check into this daily superblock issue now...

Great work everyone!

exec prominence shows 9 users in the leaderboard for height 3300.

[Rob Andrews]

So, I see the reason we didn't pay at the last superblock.  I'm going to try to create a release really quick, if we can get a good chunk of us upgraded by block 3300, we have a shot at checking to see if the bug is dead.

Building....

[Rob Andrews]

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

[Rob Andrews]

Cancel that last post; we are now waiting for block 3505 in a hands-off fashion.

The last superblock was not paid before everyone upgraded, so it was also a regular block.

[Rob Andrews]

Cancel that last post; we are now waiting for block 3505 in a hands-off fashion.

The last superblock was not paid before everyone upgraded, so it was also a regular block.

Ok, I think we did it.  I received a reward for 3505. 

[Rob Andrews]

I added the BBP reward amount to the prominence rows for the next version.

[Rob Andrews]

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.

[oncoapop]

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

[Rob Andrews]

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!

[rastiks]

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?

[Rob Andrews]

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.

[Rob Andrews]

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.