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

I see the two 500K proposals won in the last superblock (getgovernanceinfo:last superblock height).  I see the 1Mil (dog mascot) didnt get paid, so it appears this one worked also.

~/biblepay-evolution/src/qt/biblepay-qt loads ok but perhaps to be expected crashed when you try to view leaderboard and proposals.

Ok, thanks a lot, that is something we missed, I am adding this to the list right now. 

Thats great that you synced to the top though, awesome!

On a side note, Dash added more messages and a protocol change to governance, so Evo cant load the governance objects from Biblepay-classic nodes (thats why the proposals dont show yet in prod). 

Interesting, I managed to send funds (BBP not tBBP) from my wallet on the mainnet to the wallet running EVO!

~/biblepay-evolution/src/biblepay-cli getinfo
{
  "version": 1040207,
  "protocolversion": 70732,
  "walletversion": 61000,
  "balance": 100.00000000,
  "privatesend_balance": 0.00000000,
  "blocks": 117804,
  "timeoffset": 0,
  "connections": 11,
  "proxy": "",
  "difficulty": 9338.691900918453,
  "testnet": false,
  "keypoololdest": 1557217142,
  "keypoolsize": 999,
  "paytxfee": 0.00000000,
  "relayfee": 0.01000000,
  "errors": ""
}

~/biblepay-evolution/src/biblepay-cli listtransactions
  {
    "account": "",
    "address": "BC2RsquwDER8sCKcMmDCy9rgKSusWLZpGn",
    "category": "receive",
    "amount": 100.00000000,
    "label": "",
    "vout": 1,
    "confirmations": 2,
    "instantlock": false,
    "blockhash": "49d1f7e4d26f8547da3ae9c25a40232080706293a95859f2e0c0770aa05d5270",
    "blockindex": 1,
    "blocktime": 1557225899,
    "txid": "29f1b61e84d4f6eae1ef9eb49b8ef3f9f49366576b3eeb57282e2e7367f9c917",
    "walletconflicts": [
    ],
    "time": 1557225892,
    "timereceived": 1557225892
  }

Yes, thats awesome, thanks for the tests.

Yes, the hash algorithm and miner is backwards compatible in evo up to a certain height.  After a certain height, we do switch to a newer version of POBH (with ABN), and the chained verses, but Evo works in all ways with the biblepay-classic nodes, Except it cant receive governance data from the classic sancs.

Hence the reason we have to fire up 50 or so Evolution sanctuaries for our mandatory cutover height (first).
So basically, the Evo sancs will become the official sancs at the cutover height.

$ ~/biblepay-evolution/src/biblepay-cli getblockcount
117799

$ ~/biblepay-evolution/src/biblepay-cli getblockhash 117799
1a038e93b4046038444f7a98abd546aa2a7a8580ade7771224a73685b79314b5

I don't know what exactly is required but here is the output of getmininginfo of EVO on the main chain pointed to purepool.

{
  "blocks": 117798,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 10211.68938254838,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 1,
  "networkhashps": 14937188254.95241,
  "hashps": 28.84073865488929,
  "minerstarttime": "05-07-2019 10:24:22",
  "hashcounter": 4865,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "required_abn_weight": 0
}


The progress can be followed here http://www.purepool.org/main/miner/BD9gmJ5vmPJtDewo9NyqUT7fJQgV39AW7R

Thanks a lot for doing this!  This is immensely helpful!

It appears from Purepools stats that you have successfully mined!

Sweet!

There are some differences in the output of the getmininginfo

>EVO -version
BiblePay Core RPC client version 1.4.2.7
>getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 1,
  "networkhashps": 10394307548.78834,
  "hashps": 222.8212327270187,
  "minerstarttime": "05-07-2019 11:16:12",
  "hashcounter": 4675568,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "Submitting Solution 05-07-2019 17:04:52; ",
  "poolinfo3": "",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "required_abn_weight": 0
}

-version
Biblepay Core RPC client version 1.2.0.1
biblepay-cli getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "genproclimit": 2,
  "networkhashps": 1418552.369007834,
  "hashps": 187.8965827796162,
  "minerstarttime": "05-07-2019 14:17:00",
  "hashcounter": 1903566,
  "pooledtx": 1,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 3052,
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "poolmining_use_ssl": true
}

Notice the great differences in networkhasps. Does this mean that early EVO (>v1.4.2.7) upgraders are at a severe disadvantage in terms of POBH mining when competing with v1.2.0.1? Or is this because I am the sole v1.4.2.7 on the mainnet? Difficulty appears to be similar though....

Can you kindly explain? Thank you. Testing is also a good educational experience for us all!

There are some differences in the output of the getmininginfo

>EVO -version
BiblePay Core RPC client version 1.4.2.7
>

Code: [Select]

getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "pooledtx": 0,
  "chain": "[b]main[/b]",
  "genproclimit": 1,
  "networkhashps": [u][b]10394307548.78834[/b][/u],
  "hashps": 222.8212327270187,
  "minerstarttime": "05-07-2019 11:16:12",
  "hashcounter": 4675568,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "Submitting Solution 05-07-2019 17:04:52; ",
  "poolinfo3": "",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "required_abn_weight": 0
}

-version
Biblepay Core RPC client version [u][b]1.2.0.1[/b][/u]
biblepay-cli getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "genproclimit": 2,
  "networkhashps": [u][b]1418552.369007834[/b][/u],
  "hashps": 187.8965827796162,
  "minerstarttime": "05-07-2019 14:17:00",
  "hashcounter": 1903566,
  "pooledtx": 1,
  "testnet": false,
  "chain": "[b]main[/b]",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 3052,
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "poolmining_use_ssl": true
}
Notice the great differences in networkhasps. Does this mean that early EVO (>v1.4.2.7) upgraders are at a severe disadvantage in terms of POBH mining when competing with v1.2.0.1? Or is this because I am the sole v1.4.2.7 on the mainnet? Difficulty appears to be similar though....

Can you kindly explain? Thank you. Testing is also a good educational experience for us all!

First of all, know that mining in Evo against prod (solo or against the pool) is virtually the same as mining in classic (as far as HPS, efficiency, and fairness) - there is no advantage to either client (except Evo might be 1% better due to its more optimized compiler and Depends environment etc).

Regarding the Network HashPS, first let me try to explain how Bitcoin calculates it.  Its a trailing average of chain hashpersecond found in the last 10 blocks or so (the blocks contain this data because we track the nonce req count and chain weight etc).  But, where this discrepency starts occuring is back in POBH v3, Alex and I were doing some testing and we realized due to our very unique hash algorithm we put waaaay more hashes in per hash than the networkhashps reported so we tweaked it in classic to be our new fangled estimate.

So the answer is in Evo its too low.  I remember now why this was not updated:  POBH changed in Evo.  I just made a punchlist item to fix this.
But in summary, its a barometer being affected by the wrong multiplier currently.

EDIT:  Actually Evo looks pretty accurate as-is (it seems this fig is too high in Classic).  Since I have the exact HPS in the pool, and the % of blocks solved by pool.bibepay.org, we really are doing about the Evo-hps right now in prod.

1.4.2.8b-Mandatory upgrade for TestNet

- Add testnet checkpoint
- Enhance ABN consensus rule to only require ABN when diff is greater
than threshhold (this should improve the SetBestChain business logic)
- Port biblepay-classic peer disconnect rules (enforcing network time
and minimum version)
- Ensure wallet does not crash in Prod when people click on Leaderboard
or Proposals

We should technically re-sync better on this version (I mean the initial sync after upgrading only), as now we have classic's code for mandatory upgrades in.

BTW:  Please dont erase any files, just upgrade.

We should technically re-sync better on this version (I mean the initial sync after upgrading only), as now we have classic's code for mandatory upgrades in.

BTW:  Please dont erase any files, just upgrade.

ha, to late. I deleted everything and now I have a problem, no peers

ha, to late. I deleted everything and now I have a problem, no peers

Check system clock ensure its correct within 5 mins and timezone is correct.

Delete banlist.dat, restart.

If you arent synced after 15 mins post IP address here and Ill search my log for the reason for your ban as we have 3 seed nodes in testnet.

nope, something doesnt work at all. Like I am on my own


what are the nodes, i saw them in previus version, but cant remeber. ns.biblepay.org?

Upgraded both wallets to v1.4.2.8b yesterday

I tried to just run them normally, but they would crash right away, tried to reindex and same thing, didnt see anything in the log (may have forgotten to add debug=1), so I wanted till today and tried again with reindex, both worked a couple hours ago

getblockhash 69207
6e40d8f*

Upgraded both wallets to v1.4.2.8b yesterday

I tried to just run them normally, but they would crash right away, tried to reindex and same thing, didnt see anything in the log (may have forgotten to add debug=1), so I wanted till today and tried again with reindex, both worked a couple hours ago

getblockhash 69207
6e40d8f*

When you say crash, what do you mean, and what version are you running (qt or non) and what platform (unix linux mac)?

Yeah, since I have not seen a crash yet except clicking on leaderboard in prod (which was fixed in the last version) I would really like to know how to reproduce.

Also, if anyone else has ever crashed in evo in testnet it would be really nice to have more info so we can fix it before we go to prod (thats what testnet is for).

nope, something doesnt work at all. Like I am on my own


what are the nodes, i saw them in previus version, but cant remeber. ns.biblepay.org?

Like I alluded to in the prior message, they would be compiled in if they are seed nodes so you dont need them, and I synced today with a node.

Is there a reason you are hiding your ip?

Upgraded both wallets to v1.4.2.8b yesterday

I tried to just run them normally, but they would crash right away, tried to reindex and same thing, didnt see anything in the log (may have forgotten to add debug=1), so I wanted till today and tried again with reindex, both worked a couple hours ago

getblockhash 69207
6e40d8f*

Synced