BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[bible_pay]

BiblePay
1.1.4.4 - Leisure Upgrade

- Implemented faster boot time (90% faster on Linux, 40% faster on windows); Note that the first cold boot will be approx. 50% faster, then successive cold boots 90% faster on linux.
- Ensure PODC updates transmit for both Rosetta and WCG automatically
- Added checkpoint at block 63000
- Checked in MIPs Mac Build Configuration

The download from biblepay.org still seems to be 1.1.3.8

Oddly last night a few of my miners ended up on different forks at block 63828

8c53f3d28f18180a78d8fde6ce2fcb2ecee4f57ac7d3a31297848915f8d1938e
846572421ddf51d629b236f79e6f6af8c8a079baf5e45625c70646ec12d85ba3

Anyone else see this?

I do confirm we had a release problem.

I found a bug in the release script; fixed.

The new version should be out now.

On a side note: If your boot speed does not change on windows, please delete blocks and chainstate and re-sync (but only if you boot a few times and it is still slow).

I'll re-test windows to try to find the remaining (fast speed during memorizeprayers) incompatibility.

[1713411726]

1713411726

[1713411726]

1713411726

[1713411726]

1713411726

[bible_pay]

Everyone, please check your POW difficulty.  If its less than 1000, you may be on a fork.

If so, please delete your blocks and chainstate folder and restart.

[zthomasz]

My wallet "Sanctuaries" tab shows only 1 out of 3 of masternodes are Enabled.

Is this accurate?

[togoshigekata]

Code:

getblockhash 63936
d88de07a3d8c9c3a81d8841e5d568ef89e2720fb56aec1d69b6ae71c54ded0ca

[zthomasz]

Everyone, please check your POW difficulty.  If its less than 1000, you may be on a fork.

If so, please delete your blocks and chainstate folder and restart.

Does this apply to masternodes running 1.1.3.8c successfully for 4 weeks, but is now Expired and the difficulty is around 300?

[thesnat21]

Everyone, please check your POW difficulty.  If its less than 1000, you may be on a fork.

If so, please delete your blocks and chainstate folder and restart.

Curious what caused it

[markovonline]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

[bible_pay]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

[macko20]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

Rob,

All my wallets works perfectly, without restart. 1.1.3.8 (64-bit) version (win7 64bit) about 30day+

[bible_pay]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

Rob,

All my wallets works perfectly, without restart. 1.1.3.8 (64-bit) version (win7 64bit) about 30day+

Thanks, that brings up a good point also.  My regular wallets (3) were on the right chain but 30% of my sanctuaries were on the wrong chain so I rebuilt the blocks on those and resynced properly.  Its something to consider that todays problem was due to sanc rules.  It is interesting to note that the Sancs re-memorize the PODC data once every 4 hours right before doing the internal 'exec dcc' command (that is where they try to come to a podc quorum).  But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).

[bible_pay]

All,  Jaap has paid Coinexchange.IO for our new exchange listing fee (2 BTC) - that was the entire treasury.

We will be listed on August 15th.

[thesnat21]

Thanks, that brings up a good point also.  My regular wallets (3) were on the right chain but 30% of my sanctuaries were on the wrong chain so I rebuilt the blocks on those and resynced properly.  Its something to consider that todays problem was due to sanc rules.  It is interesting to note that the Sancs re-memorize the PODC data once every 4 hours right before doing the internal 'exec dcc' command (that is where they try to come to a podc quorum).  But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).

My clients thought they were still current.. so not sure how that rule would help

As for the delete/rebuild interesting idea.  There is still the oddity of when you do that, the PODC key seems to get lost until you re-start the client.

I'm guessing the scanning routine isn't looking for/updating the key info when it gets to that part of the blockchain.
(just a guess, since I have not looked into it really)


I've done it several times and gotten the unable to sign cpid error.

[togoshigekata]

All, Jaap has paid Coinexchange.IO for our new exchange listing fee (2 BTC) - that was the entire treasury.

We will be listed on August 15th.

CoinExchange.io
https://www.coinexchange.io/

CoinMarketCap - 24 hour Volume
https://coinmarketcap.com/exchanges/coinexchange/

Doge Market (To see how Exchange Looks)
https://www.coinexchange.io/market/DOGE/BTC

BiblePay Proposal to be listed on CoinExchange.IO
https://forum.biblepay.org/index.php?topic=231.0
123 Yes Votes, 8 No Votes

[bible_pay]

Thanks, that brings up a good point also.  My regular wallets (3) were on the right chain but 30% of my sanctuaries were on the wrong chain so I rebuilt the blocks on those and resynced properly.  Its something to consider that todays problem was due to sanc rules.  It is interesting to note that the Sancs re-memorize the PODC data once every 4 hours right before doing the internal 'exec dcc' command (that is where they try to come to a podc quorum).  But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).

My clients thought they were still current.. so not sure how that rule would help

As for the delete/rebuild interesting idea.  There is still the oddity of when you do that, the PODC key seems to get lost until you re-start the client.

I'm guessing the scanning routine isn't looking for/updating the key info when it gets to that part of the blockchain.
(just a guess, since I have not looked into it really)


I've done it several times and gotten the unable to sign cpid error.

On the 'trigger' to delete the chain and restart, there are ways to do that.  The rule would be something like: an hour has passed since the last cold boot, and the difficulty is less than (say 1000) POW, and a fork exists (IE getchaintips > 1) and the longer chain contains a bad block.  Then we restart the wallet with an -erasechain parameter.

As far as the memorizeprayers function, just delete SAN/prayers_prod  for now and restart.  Ill have to make it honor a startup where the best block height is less than the prayer height in the file.  Correct, its not checking that right now, thats a bug.

[noxpost]

Also just so everyone is aware, iquidus (the software that powers the block explorers ) has a very very hard time recovering from a fork. Mine got on the wrong chain for a bit, and couldn't recover, so I'm once again rebuilding the full database. Sorry for any inconvenience, but there's little else I can do.

[slovakia]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

Rob,

All my wallets works perfectly, without restart. 1.1.3.8 (64-bit) version (win7 64bit) about 30day+

win version works perfect 40day+ .... but 2 masternodes crashed again= any problems with masternode chain=it happened that jumped to other chain

[bible_pay]

About POW difficulty probably some kind of failure or who from the skilled hackers managed to bypass protection and lured tokens to themselves. I'm also interested in knowing the reason for such a decision and what caused this failure for all who are interested in this important information.

There is not a path in the wallets business logic that allows 'skilled hackers to bypass protection', however, as snat said this morning there were live forks, and we now had to restart our wallets to get on the right chain.

But the most accurate question is, why do we have to delete blocks and chainstate to recover our wallets?  Thats a question for me, why does the wallet favor the chain with the least work, after working 4 weeks perfectly?

I believe the answer has something to do with our strict CPID mining rules.  When a fork is a true alternative (IE lets say we have two baby forks at 5000 diff on block N+1), those two forks have two different sets of possible CPIDs.  Our wallet being inherited from dash will not reconsider a block to be good after its marked bad.  I think we need a feature programmed in that allows us to recover in this situation to the chain with the most work.

Rob,

All my wallets works perfectly, without restart. 1.1.3.8 (64-bit) version (win7 64bit) about 30day+

win version works perfect 40day+ .... but 2 masternodes crashed again= any problems with masternode chain=it happened that jumped to other chain

If a Sanc crashes we need a volunteer to start the sanc like this:

valgrind ./biblepayd
or
valgrind ./biblepay-qt

and tell us the line # of the crash.

sudo apt get install valgrind

[bible_pay]

But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).

Great idea!

[thesnat21]

Strange this superblock it seems like I missed the unbanked payment..

Anyone else see something similar?

[togoshigekata]

An orphanage from India, Brynn Children Home, has been in contact with me over Facebook, I think they will be creating a proposal soon!
https://www.facebook.com/Brynn-Children-Home-1668615016742705/