bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 11, 2018, 02:08:04 PM Last edit: August 11, 2018, 03:39:34 PM by 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.
|
|
|
|
|
|
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 11, 2018, 03:40:11 PM |
|
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
Member
Offline
Activity: 489
Merit: 12
|
|
August 11, 2018, 04:08:09 PM |
|
My wallet "Sanctuaries" tab shows only 1 out of 3 of masternodes are Enabled.
Is this accurate?
|
|
|
|
togoshigekata
|
|
August 11, 2018, 05:49:20 PM |
|
getblockhash 63936 d88de07a3d8c9c3a81d8841e5d568ef89e2720fb56aec1d69b6ae71c54ded0ca
|
|
|
|
zthomasz
Member
Offline
Activity: 489
Merit: 12
|
|
August 11, 2018, 05:52:02 PM |
|
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
Jr. Member
Offline
Activity: 490
Merit: 4
|
|
August 11, 2018, 07:27:32 PM |
|
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
|
|
August 11, 2018, 07: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.
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 11, 2018, 08:49:41 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.
|
|
|
|
macko20
Newbie
Offline
Activity: 89
Merit: 0
|
|
August 11, 2018, 10:03:04 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 (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 11, 2018, 11:21:18 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).
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 11, 2018, 11: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.
|
|
|
|
thesnat21
Jr. Member
Offline
Activity: 490
Merit: 4
|
|
August 12, 2018, 12:53:13 AM |
|
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 (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 12, 2018, 01:18:14 AM |
|
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
Jr. Member
Offline
Activity: 235
Merit: 3
|
|
August 12, 2018, 02:44:52 AM |
|
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
|
|
August 12, 2018, 07:12:30 AM |
|
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 (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 12, 2018, 01:28:34 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 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 (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 12, 2018, 03:31:56 PM Last edit: August 12, 2018, 08:33:46 PM by 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
Jr. Member
Offline
Activity: 490
Merit: 4
|
|
August 12, 2018, 09:12:03 PM |
|
Strange this superblock it seems like I missed the unbanked payment..
Anyone else see something similar?
|
|
|
|
|
|