Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rob Andrews

Pages: 1 2 [3] 4 5 6 7 8 9 10 ... 127
$ ~/biblepay-evolution/src/biblepay-cli getblockcount

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

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": "",
  "required_abn_weight": 0

The progress can be followed here

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

It appears from Purepools stats that you have successfully mined!


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

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.

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.

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 (successfully).

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.

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.

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. 

I'm starting to review this page:
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.

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.

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

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": "",
  "proTxHash": "04b7167841f9c174d135eed04c4011b077b4ead1b3c5050d45eae8e0a409e2e9",
  "collateralHash": "e94e309dfc51d4166294a300a8e4a935c36e81614c95bc7ccf4b4abd054fb1b9",
  "collateralIndex": 1,
  "dmnState": {
    "service": "",
    "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.

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.

It looks like we made it through the night with no issues (and no spam).  We have a .50~ diff and 5 enabled sancs (all deterministic).

Today I will flip dip15 and see if we wreak havoc or if we continue smoothly.

Ok, I just made my 3 deterministic and set up the masternodeblsprivkey on the remote sancs, and rebooted them.
So it looks like we have:
Rob, Rob, Rob,

Anyone else need to upgrade?

Pages: 1 2 [3] 4 5 6 7 8 9 10 ... 127