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

slovakia

full member

Activity: 770

Merit: 100

Quote from: macko20 on August 11, 2018, 05:03:04 PM

Quote from: bible_pay on August 11, 2018, 03:49:41 PM

Quote from: markovonline on August 11, 2018, 02:54:57 PM

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

noxpost

jr. member

Activity: 235

Merit: 3

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.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: thesnat21 on August 11, 2018, 07:53:13 PM

Quote from: bible_pay on August 11, 2018, 06:21:18 PM

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.

togoshigekata

full member

Activity: 1260

Merit: 115

Quote from: bible_pay on August 11, 2018, 06:23:16 PM

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

thesnat21

jr. member

Activity: 490

Merit: 4

Quote from: bible_pay on August 11, 2018, 06:21:18 PM

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.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

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.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: macko20 on August 11, 2018, 05:03:04 PM

Quote from: bible_pay on August 11, 2018, 03:49:41 PM

Quote from: markovonline on August 11, 2018, 02:54:57 PM

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

macko20

newbie

Activity: 89

Merit: 0

Quote from: bible_pay on August 11, 2018, 03:49:41 PM

Quote from: markovonline on August 11, 2018, 02:54:57 PM

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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: markovonline on August 11, 2018, 02:54:57 PM

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.

markovonline

sr. member

Activity: 854

Merit: 253

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.

thesnat21

jr. member

Activity: 490

Merit: 4

Quote from: bible_pay on August 11, 2018, 10:40:11 AM

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

zthomasz

member

Activity: 489

Merit: 12

Quote from: bible_pay on August 11, 2018, 10:40:11 AM

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?

togoshigekata

full member

Activity: 1260

Merit: 115

Code:

getblockhash 63936
d88de07a3d8c9c3a81d8841e5d568ef89e2720fb56aec1d69b6ae71c54ded0ca

zthomasz

member

Activity: 489

Merit: 12

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

Is this accurate?

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

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.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: thesnat21 on August 11, 2018, 08:13:15 AM

Quote from: bible_pay on August 10, 2018, 09:21:59 PM

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.

togoshigekata

full member

Activity: 1260

Merit: 115

Quote from: turbokongen on August 11, 2018, 01:59:20 AM

Regarding exchanges, did anyone try to aproach Bittrex?
They clearly state that it does not cost anything to be listed, but the token needs to go through a listing review before it gets listed: https://support.bittrex.com/hc/en-us/articles/360000475411-How-do-I-submit-a-token-to-Bittrex-for-listing-

Rob has an Enhanced Verified account with Bittrex and submitted to them and Poloniex back in November
Reference: https://bitcointalksearch.org/topic/m.24639333

I contacted Poloniex again recently a few days ago, I think Rob submitted again to Bittrex in the past few months

thesnat21

jr. member

Activity: 490

Merit: 4

Quote from: bible_pay on August 10, 2018, 09:21:59 PM

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?

MIP

newbie

Activity: 362

Merit: 0

Quote from: bible_pay on August 10, 2018, 09:21:59 PM

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

MacOS version also available in wallets section.

turbokongen

newbie

Activity: 30

Merit: 0

Regarding exchanges, did anyone try to aproach Bittrex?
They clearly state that it does not cost anything to be listed, but the token needs to go through a listing review before it gets listed: https://support.bittrex.com/hc/en-us/articles/360000475411-How-do-I-submit-a-token-to-Bittrex-for-listing-

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