Messages

2431

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 07, 2019, 01:42:21 PM »

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

2432

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 07, 2019, 12:36:35 PM »

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.

2433

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 07, 2019, 10:55:02 AM »

$ ~/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!

2434

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 07, 2019, 10:53:16 AM »

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.

2435

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 07, 2019, 10:48:24 AM »

~/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). 

2436

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 07, 2019, 10:46:31 AM »

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.

2437

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 07, 2019, 10:43:20 AM »

I guess the next step is to see if one can create a DIP3 masternode on the mainnet but I am unable to help with that as I do not have the required collateral...

Yes, the collateral is going up to 4,500,001, so its quite a risky thing to tie up 3* the amount currently LOL.
Well this is actually a very critical issue and relies on something that isn't readily apparent in the code that sort of drives our decision to do this a certain way.
The new Dash non-financial transactions require the pro-reg-tx payload to be stored in a certain way that starts storing data in the prod chain in an extended place, that I really don't want to be intermingled with biblepay-classic nodes.  Another words, we must ensure the dip15 cutover is on a height well after our mandatory upgrade height to evo - we will have to phase Evo in at a certain height, and run legacy sancs first:
For example:
Height 135,000 - Cutover to Evolution - convert sancs from 1.55m to 4.5MM
Height 145,000 - Upgrade to Deterministic sancs (between 135K-145K)
Height 145,001 - Mandatory upgrade to deterministic non-financial txes (dip15 is enabled)
Its a shame that we have to do this in two steps, but its really the only way I can see doing this - if we go directly to deterministic sancs, we would break the biblepay classic nodes (as the extra non-financial data would not be parseable).

But yes, we will talk more about this soon, and I will act as a sacrificial lamb with one of my sancs and create it in Prod through evo as a 4.5MM and ensure it starts. 
I think we will need to organize this endeavor in a way where we ask our Prod sancs to upgrade 7 days before the mandatory cutover height (IE before the exchanges even upgrade), because moving to evo requires all sancs to re-organize into a 4.5MM farm.
(If we asked them to upgrade after the height prod would have no sancs at the cutover height).  We also have to take into consideration the monthly budget height.
It would be good to frame this upgrade right after either May 30ths block, or June 30th's block.
At that point Sancs in prod would download Evo, upgrade to 4.5 MM in classic mode, then around the 7th, the mandatory height passes, the exchanges upgrade and then we have a certain buffer (say 25 more days) to upgrade to deterministic.

2438

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 06, 2019, 03:52:55 PM »

Oh btw, I did test Evo against prod last month, and also tested Pool mining (in prod mode).

If anyone feels up for it, please sync in prod, and verify you can sync to the top in prod.
Then configure the miner to be pointed at a pool, and ensure pool mining is working.
Note:  It would be very helpful if someone could test Purepool.  I only tested mining in evo in prod against pool.biblepay.org (successfully).

2439

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 06, 2019, 03:50:51 PM »

Next we need to ensure the payment amounts are correct for : POBH, monthly superblocks, daily superblocks and the qt effect on it.


After this it appears the entire wishlist has been fulfilled.  Let me know if anyone has any questions or concerns for this next version of BiblePay.

I believe we have tested almost all of the pieces successfully!


On a side note, I hope people have noticed the chained bible verses are now consecutive and the txlist double click shows these also.

2440

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 06, 2019, 03:38:45 PM »

Church Tithing/Mobile-wallet staking:
MIP is working on it.  If we don't get it finished by the end of June we will push it back to September.  On a side note, BBP has a PO Box (actually we have a physical address po box) now, and MIP is working on a relationship with Apple so he can also release BiblePay for iPhone.

ChainLocks:
This is most likely the only feature in this guide that won't make it in time for an end of June release.  This is only because Dash is still testing it and MIP and I would like to see it promoted to Dash-Prod before we release it in BiblePay. 

2441

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 06, 2019, 03:34:00 PM »

I'm starting to review this page:
https://wiki.biblepay.org/Nutrition_Information
To see what we forgot to test, and I wanted to mention something about soft forks and stable-prod features in Evo:

We did test the stable-prod feature a couple of releases back successfully.

At the time, we were not rewarding for diary entries and QT was around 30% and climbing.

I added two business logic changes to the server side and we had a leisure, and did not specifically mention it, but what happened was the current GSCs with existing votes were downvoted automatically and the new GSC (because of the 2% contract change in that GSC superblock) was upvoted, meaning this feature was tested successfully (we had a leisure upgrade for sancs, no hard consensus change release) and we succeeded in emitting a GSC.  So this is really great and very useful in the future as I can see a lot of possible releases in mid quarter updates with useful things between exchange mandatory upgrades.

2442

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 06, 2019, 02:20:35 PM »

Can someone do us a favor, please create a new legacy sanc (and of course you wont be able to see it in the sancs list because we are past dip15), and see if you can upgrade it to deterministic successfully?

Just want to ensure stragglers can still create sancs the old way and just upgrade them.

Remember we do need to paste the masternodeblsprivkey into the cold sancs biblepay.conf also.

2443

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 06, 2019, 02:19:09 PM »

Awesome!
Also, that gobject listwild is very useful!

Thanks, as you can imagine I needed it for a lot of debugging while looking for missing GSCs.

Note that you can also search by part of the hash with it (IE the beginning of the gobject id).

2444

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 06, 2019, 11:53:52 AM »

In Sanctuaries tab, I only see DIP3 Sanctuaries tab now

Name of my masternode is MN1, and in Transactions I notice rewards going to MN1-D address

In the cold setup, on the remote masternode, for masternode status command,
I see lots of new fields!

Code: [Select]

./biblepay-cli masternode status
{
  "outpoint": "e94e309dfc51d4166294a300a8e4a935c36e81614c95bc7ccf4b4abd054fb1b9-1",
  "service": "149.248.35.69:40001",
  "proTxHash": "04b7167841f9c174d135eed04c4011b077b4ead1b3c5050d45eae8e0a409e2e9",
  "collateralHash": "e94e309dfc51d4166294a300a8e4a935c36e81614c95bc7ccf4b4abd054fb1b9",
  "collateralIndex": 1,
  "dmnState": {
    "service": "149.248.35.69:40001",
    "registeredHeight": 63324,
    "lastPaidHeight": 64958,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "yZZ64ZSubgwAbSU6y7hpTNLV75ASDS4JeQ",
    "votingAddress": "yZZ64ZSubgwAbSU6y7hpTNLV75ASDS4JeQ",
    "payoutAddress": "yhTodPvmgv2RagCgtmPFvENztSm2FTeRRm",
    "pubKeyOperator": "02ea2b9f2dcad455907f2aaf547087118cb7ec30a12d0f2a529ea41125ea05e41ba5ad53bece8d1a0362a1c4f344c0a9"
  },
  "state": "READY",
  "status": "Ready"
}

In Proposals, I voted Yes for Speaking_Hall, No for Dog_Mascot and Abstain for Minecraft_Integration
(How do I check votes? gobject getvotes hash? and how do I link it back to an address?, Looks like it links to a masternodes collateral hash?)

Wow thats awesome, yes I see your vote for minecraft, so I can see it worked from the deterministic sancs cold controller, good.
So to see votes, you can:
1) Look at Proposals UI
2) gobject listwild all proposals Minecraft  (Note the case sensitivity on Minecraft)
Scrape the gobject
gobject get hash
It should show the votes after the gobject description.

The votes are linked by "Sent proregtxid " (the last field in deterministicsanctuary.conf).  You can also scrape this hash by right clicking on a deterministic sanc and saying Copy proreg-txid to clipboard.

2445

TestNet Discussion Archive / Re: TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

« on: May 06, 2019, 09:05:31 AM »

Ok, we are now transitioning to deterministic masternodes at height 64960!

At this point, your sanctuary reward payments should shift from the old mining address to your new deterministic address.

All proposal votes (on GSCs in this intermediate block will become invalid).

Lets see how the GSC system handles creation of the next proposal and if votes for it work also.

EDIT:  Please check your cold sanctuary and see if it reports all the new fields in:  masternode status

EDIT2:  Please ensure you can vote on proposals both from UI, command line alias and command line many.