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 ... 118
1
1.4.1.8-Mandatory Upgrade for TestNet

- Improve GSC consensus rule
- Add historical BTC price to each gsc superblock for future reports
- Prevent multiple UI popups within 7 seconds

2
So I found a "bug" in 1417.  It appears that when we move to dip3, our sancs cant sign the signature for one of our features properly (primarily because the structure of this feature has changed in Evo, so its really a class change that breaks compatibility with one of our old methods).

This means I need to upgrade the function in 1418 and have another mandatory release.

It looks like Im the only one who updated my sancs so far (I see my 3 online) so hopefully this wont be too big a deal.

Please hold off on testing while I fix this. 




3
I had to delete everything, than it synced headers as well.

Glad you are synced.  I believe your headers were already synced before this step. 


4
Please ensure your hashes match - someone came on with high hash:
getblockhash 36743
d7d64e0701e5480e3b53429d7015b03ae0351c025dfd6d4de9c86f05f8294bd6



5
I compiled a version of the daemon/cli for Linux amd64, available here
https://www.biblepay.org/biblepayd-1.4.0.7-x86_64-pc-linux-gnu.tar.gz

And MacOS QT version here
https://www.biblepay.org/biblepaycore-testnet.dmg

Thanks - added the Mac version to the OP post.


6
I see someone was nice enough to enter about 15 proposals right before we upgraded!

Thanks!

Who was that btw?

Unfortunately all this work was in vain because we had the mandatory upgrade right after, and there were no sancs around to vote at that height for that superblock (see getgovernanceinfo, see last superblock height), that block ended up turning out to be a regular block.

This is to be expected in this case.

So please let us do it again soon.


7
I am stuck the whole day at Syncing Headers 96,3% , progress bar  is  2sec behind.

19:25:02
getblockhash 36743

19:25:02
d7d64e0701e5480e3b53429d7015b03ae0351c025dfd6d4de9c86f05f8294bd6

I took a look at that stuck 1-10 second behind header issue, and it turns out what that means is your node doesn't have a fully synced gobject list (IE it believes the masternodes and gobjects are not synced) - also, if you do an mnsync status, you are probably in chain synced true and gobjects synced = false. 
Another words, that is a feature that lets you know something is wrong with the mnsync status only.

EDIT: Ok, so yes you are synced on the blockchain - my hash agrees.

I think you just have a bad mncache.

Try this:  stop node, rm mnc*.*, rm gov*, rm mnp*,  restart wallet, wait 10 mins - see if mnsync status shows all trues then and the bar dissapears?




8
Ok, Ive resynced all my nodes and restarted my sancs  - they went to enabled, Im seeing this hash:

getblockhash 34746
123eebf58f402f349adc10d578ef80a9e8a4200a45326db28b6eb39ab0b364a8

9
Actually it looks like we are encountering a brand new Evo-specific issue as of a new block from yesterday:

2019-04-18 13:59:56 ERROR: ConnectBlock(): ProcessSpecialTxsInBlock for block 4b1205177d60daa173491b742e39501ae29a48605bf3ed617ade77149feb6fb2 failed with bad-protx-collateral (code 16)

It looks like two of us tried to create deterministic sancs before the spork was enabled.  But what is interesting is this was legal yesterday but today the block is actually being rejected.  (I can understand that partially since all the sancs are disabled right now), but what is interesting to me is that we reject the entire block if the Pro-reg-tx fails.

Let me take a look at this issue in detail.  In the mean time I think the only way to sync is to re-sync every node to before 34510 occurred.

Ok.  I see whats going on here.  At first it seems a little strange that a single bad pro-reg tx could fork the chain (because business logic rejects the entire block that contains the bad pro-reg) -- but thats not whats really happening in the bigger picture. 

In the bigger picture we will always have a supermajority of sancs online in prod to make the call, so with sancs actually online, the pro-reg would have been processed or the sanc-quorum would have rejected the block.

The rule goes like this:  For chainlocks, llmqs, and pro-reg-special-transactions, all of these are forwarded to a processor that checks validity based on the llmq (long living masternode quorum), and if any fail, the entire block is rejected.

So what we need to do first everyone, please re-sync your chain to before 34510 and please do not send any 'upgradesanc' commands or pro-regs until we successfully recreate our sanc quorum with 4.5 mm locks.  Also just to be safe, lets ensure diff is > 1.0 and we solve the next GSC superblock after that with exec health showing true.

Then we can re-group and talk about testing the next layer(s).


10
Actually it looks like we are encountering a brand new Evo-specific issue as of a new block from yesterday:

2019-04-18 13:59:56 ERROR: ConnectBlock(): ProcessSpecialTxsInBlock for block 4b1205177d60daa173491b742e39501ae29a48605bf3ed617ade77149feb6fb2 failed with bad-protx-collateral (code 16)

It looks like two of us tried to create deterministic sancs before the spork was enabled.  But what is interesting is this was legal yesterday but today the block is actually being rejected.  (I can understand that partially since all the sancs are disabled right now), but what is interesting to me is that we reject the entire block if the Pro-reg-tx fails.

Let me take a look at this issue in detail.  In the mean time I think the only way to sync is to re-sync every node to before 34510 occurred.


11
I'm seeing this hash:
getblockhash 37124
1e0d0a836d61d246d0202507747a71e2960eaf683668d45b38365616cbed6ffa

Last night I recreated my 3 sancs and enabled them but through the night people upgraded and reorganized and erased the block I sent my 4.5MM in.
I just recreated my 3 legacy sancs again; re-starting sancs now.




12
1.4.1.7 - Mandatory Upgrade for TestNet

- Fix bug showing old proposals in Proposals List page
- Change sanctuary lockup collateral to 4,500,001
- Upgrade persisted data storage system from v1.0 to v1.1
- Add txlist double click drill in: display of biblepay-classic fields:
height, time, difficulty
- Add RPC leaderboard command (leaderboard me=true/false [height ||
last || future]
- Add exec upgradesanc sancname.  This is a BiblePay utility that allows
you to upgrade a non-deterministic sanc to a deterministic sanc.  We
also add the deterministic.conf file, so the user can write scripts to
read their own deterministic sanc keys and automate the deployment of
the keys to the remote server(s).
- Fix low-abn-weight bug
- Make exec join healing display the wiki URL so the user can learn
about the healing campaign first


Note:  We just changed our sanctuary lockup collateral to 4,500,001.  Please re-create your sancs.

We will talk about Deterministic a little later, for now please re-create the standard way - but note: It is recommended that we re-create Cold sancs, as the upgrade to dip3 will require cold sancs.  (Hot sancs cannot be upgraded to dip3).


13
I'm starting to add some documentation to explain to new users how to get started:

Getting started with Evolution:
https://wiki.biblepay.org/Getting_Started_with_Evolution
GSC's:
https://wiki.biblepay.org/Generic_Smart_Contracts
Healing Campaign:
https://wiki.biblepay.org/BiblePay_Healing_Campaign
Street Healing:
https://wiki.biblepay.org/Street_Healing
Spiritual Warfare:
https://wiki.biblepay.org/Spiritual-Warfare-I



I realize we need a specific section for Grandma also - I'll continue to refine the getting started guide.

Please let me know if anyone would like to see more expanded info on any of these, and/or if this is sufficient to call us "easy to use" with the release of Evo.



14
The new version is almost ready, but I see the 4.5MM lockup poll is most likely winning.

I believe this is a good time for us to include the higher collateral in the next release (since we need a mandatory change anyway for the ABN rule).

We will need to re-create our sancs @ 4.5 MM.

Stay tuned...


15
So, I did add the legacy double click info to our txlist, and over the last day, I added a new command to allow us to upgrade a sanc to deterministic.

Let me iterate through the punchlist, and verify some other small things we might need for our next round of testing, and then ill create a new release for testnet.

BTW, our ABN feature worked about 95%, but I did discover a bug in it so only 1 of its 2 features are enabled, will fix this as part of this next release also.

Progress is now speeding up, and everything looks very solid.  I feel bullish about the next version of BiblePay.


Pages: [1] 2 3 4 5 6 7 8 ... 118