Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 168. (Read 243386 times)

Capulo was refunded.

i'm still locked... nothing changed

Please see this post:

https://bitcointalksearch.org/topic/m.51111202

Users are not supposed to upgrade Sancs or controllers to Evo until after block 123,001 passes.

Yes, watchman built in the new evo version but at this moment , i cannot enable the masternode before 123,001 if i used the new evo version?

Watchman-on-the-wall is built in the new Evo version and pre-configured to run automatically, so you can delete watchman-classic after block 123,001.

Cheers!

I used the arm BBP version, i alreay to started the biblepayd that i found the new problem is watchdog tool, it is because the watchdog config still under old file path ~/.biblepaycore.
Any EVO new watchman Version update?


https://imgur.com/zCHu0PH

So let me know if we still have any outstanding c-cex issues; 6 days left before the shut down.

In case someone wants to test Biblepay Evo RC compiled binaries for ARM32/64 (daemon) devices in Ubuntu 16.04/18.04 

ARM32 bit : https://biblepay.org/biblepayd-evo-arm-linux-gnueabihf.tar.gz
ARM64 bit : https://biblepay.org/biblepayd-evo-aarch64-linux-gnu.tar.gz

Any feedback is welcomed.

Thanks, now I understand. Syncing from zero seems indeed the best option and it's easier for users than messing with those files.

Regards,

Mart

Basically, the governance system caches sanc payments and gobjects and votes in a few different governance files when the client shuts down.

So, if we asked people to copy the classic blocks files, (IE to sync from where they left off), they could miss some governance objects and files etc (and it would make this kind of complicated), so Ill probably ask them to just sync from zero when we explain the upgrade to them (for the Evo launch).

I'll modify the wiki page asap.

Thanks for your explanation Rob.   I understand what I need to do now, but don't know what you mean with governance files to be honest.


Best regards,

Mart

Sorry for the delay, lots of BiblePay things going on.

So just to be *extra* careful during this upgrade, I moved the BiblePay data directory for Evolution to a different location.  You might ask why; with Evo we have HD wallet support and yes Dash does have an upgrade from legacy wallets (but during testing I ran into a couple errors and that made me nervous for one) - in addition, the block format is changing and Evo adds an extra database file (Evo supports both compact and non compact blocks).  Just to be safe I decided its less risky for us to ask the users to just copy their wallet.dat to the new location.  Technically, its a good exercise to always have an extra copy of wallet.dat anyway (and I encourage users to keep an offsite copy of your wallet.dat on a flash drive).  Maybe someday, we will have a nice hardware wallet and a branded flash drive .

For now, let me give you the high level technical solution; and when we are closer to launching Ill make a wiki page for Getting Started that includes more details, and our ability to join POG at the same time.

Migrating To Evolution from Classic:

Old application data directory:  %appdata%\biblepaycore  (or ~/.biblepaycore)
New application data directory:  %appdata%\biblepayevolution (or ~/.biblepayevolution)

Steps to migrate:

Copy wallet.dat from the old place to the new place then boot Evo.


Note:  You can let the blocks sync manually to ensure your governance files get updated correctly.


Once things settle down you can delete your old:
~/.biblepaycore -r
~/biblepay -r

Files to regain the disk space.


=-=-=-=-=-=-=-=-=-=-=-=-=-
Regarding the Hard Fork question at block 123,200:

Yes, after block 123,199 biblepay-classic ceases to work correctly and forks at that point.  So it is recommended to upgrade to the mandatory version by block 123,000 (this is the block height where our May governance superblock is paid).

Happy Bitcoin Pizza Day!
https://bitcointalksearch.org/topic/pizza-for-bitcoins-137
https://bitcointalksearch.org/topic/m.1195

Dash Core v0.14 Released
https://github.com/dashpay/dash/releases/tag/v0.14.0.0

An Introduction to Dash Platform, DAPI, and Drive
https://blog.dash.org/an-introduction-to-dash-platform-dapi-and-drive-9d080d6e89c9

When it's time to upgrade to the Evo version, do I need to copy my wallet file from classic to the evo folder? (I'm a miner) Or how do I access my funds, it's a fork right, or not?

After this incident, I know how to confirm the blockchain status now.

Thanks both. 

Just remember you can't just check the block heights on explorers and if they are different assume it is a fork. You have to check the block hashes they could be on the same chain and just not synced.

For example right now if you go to explorer.biblepay.org lastest block is 120774 but on cryptoid latest block is 120779 this is not a fork you can check by comparing the hashes on 120774 (which are the same caeca403803c6ceff11e77322c210610b1fcf9d447f003d2a2170484800b10ac ) it just means explorer.biblepay.org is lagging for some reason.

Thanks, so it is node-lag.

I make the hypothesis that (on the basis that it is known that Iquidis is very inefficient for us, for some reason) that the whole time we had iquidis behind in *block count* and chainz up to date in *block count*.

I apologize for sounding snippy.

When I check at later again, my nodes have been automatically synchronized and consistent state same with explorer.

I don't know what is caused my nodes delay(It maybe when data is acquired from other nodes, but other nodes are also unable to get the latest blockchain?)

But yes, my nodes is on the same chain after checked the blockhash.

Thanks.

Out of your 17 posts, 15 claimed we were on a fork and the other claimed we were crashing.

Both of these things are obviously false, as we only had windows10 crashes during our last pog release a few months ago- and now - that is in this era of 1201 (3 months) - no one has been crashing.

So its either a matter of you not recognizing the replies (telling you we were not on a fork), or worse - if you are spreading FUD.

As far as this situation, can you now admit that your nodes were not synchronized by height (but were all on the same chain)?  (I see no indication of this, but instead another question to us alluding to "normal behavior") - Thats not normal behavior, btw.

Then, we can put the FUD theory to rest.