Author

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

full member
Activity: 462
Merit: 103
Any thoughts on C-CEX going on vacation, on the release of a mandatory upgrade next month? Does this mean C-CEX will be on an unacceptable version? Disallowing transactions on the exchange seems like a wise move in this context.

C-CEX will already not allow any crypto deposits/withdrawals during their "vacation", just fiat. So their BBP wallet can effectively be on whichever version; it will only be possible to trade internally. And when they come back after three months, if there was a mandatory upgrade, they will need to upgrade. This has already happened last time when Rob contacted Yuriy (C-CEX owner) and asked him to upgrade, which he did quickly, so I believe it will go without a hiccup.
newbie
Activity: 150
Merit: 0
Too many bugs after the Superblock ..
Hope Rob can fix it A.S.A.P. , and it should make other way for superblock payment to prevent these bugs occurs.

Rob commented a while ago about knowing what went wrong, but not wanting to force another mandatory update prior to the June one.

Hopefully the fix is in place before the next monthly block.


The conflicting superblock issue is known, and should be fixed before the next budget superblock from what I've read.  Because there was no PoDC superblock, everyone's MAG got knocked down to 0.  Since no one has MAG, the blocks take 15+ minutes to solve (since until the block time hits 15 minutes, you must have MAG to solve, after that, it's open to all).  This should be the last time this bug rears it's head.
OK guys. Just relax, West is right Smiley This is happened after monthly budget superblock.
If there is not Mag we must to wait 15 minutes for anyone to mine block without "working" CPID. This was happened last month too and it is in "must to do" for next mandatory update as it was mentioned. But it looks, that this month it has bigger affect to miners. We must just wait for next "daily" superblock and after that it will be all in normal. I hope Cheesy I just remember these type of discussion from previous months. So restart fallen miners and wait for block 49405 Smiley
jr. member
Activity: 219
Merit: 3
How does this monthly superblock collision impact traffic to your pool today?

Do you mean solutions? Hard to say, as the pool had rejected nearly all of them until the point when I deactivated the detail check of the solutions. But indeed, the pool is finding a lot lees blocks, but that it true for everybody, as nobody can find blocks in the first 15 minutes.

jr. member
Activity: 219
Merit: 3
Ah I see, so the pools actually DO find blocks. I was just wondering, because on main pool the "block distribution" shows the last (paid) block as 49198 and I haven't received a payout after that... Wink

I have the number for the main pool from the front page of it. I think the "block distribution" page is simply stuck Smiley
full member
Activity: 1176
Merit: 111
Both pools are finding blocks right now. Slow, but that is to be expected ^^
Last main pool block: 49337
Last Purepool block: 49343

How does this monthly superblock collision impact traffic to your pool today?
jr. member
Activity: 405
Merit: 3
Yes of course - as can everybody else today (like every solo miner too). So where's the difference?

Ok, maybe I simply misunderstood your post Smiley
I don't see any difference between solo and the pools right now. Both pools are finding blocks right now. Slow, but that is to be expected ^^
Last main pool block: 49337
Last Purepool block: 49343
Ah I see, so the pools actually DO find blocks. I was just wondering, because on main pool the "block distribution" shows the last (paid) block as 49198 and I haven't received a payout after that... Wink
full member
Activity: 1176
Merit: 111
Yes I think so too, but all this should imo NOT influence the chance of the pools finding blocks, or am I wrong here? The percentage distribution of hashrate today shouldn't be different from two days ago.

You would see better distribution if you averaged results over 30 days. For one day though, the results can vary wildly. It is very possible you would find 0 blocks and someone else could find 20 blocks.
jr. member
Activity: 219
Merit: 3
Yes of course - as can everybody else today (like every solo miner too). So where's the difference?

Ok, maybe I simply misunderstood your post Smiley
I don't see any difference between solo and the pools right now. Both pools are finding blocks right now. Slow, but that is to be expected ^^
Last main pool block: 49337
Last Purepool block: 49343
jr. member
Activity: 405
Merit: 3
Yes I think so too, but all this should imo NOT influence the chance of the pools finding blocks, or am I wrong here? The percentage distribution of hashrate today shouldn't be different from two days ago.

The pools are finding the blocks with the miners -> If the miners do not have a valid CPID, they can't find a block in the first 15 minutes after a block was found -> The pool can't find blocks in this timeframe Smiley
Yes of course - as can everybody else today (like every solo miner too). So where's the difference?
jr. member
Activity: 219
Merit: 3
Yes I think so too, but all this should imo NOT influence the chance of the pools finding blocks, or am I wrong here? The percentage distribution of hashrate today shouldn't be different from two days ago.

The pools are not really finding the blocks, the miners do, but the clients assign the blocks to the pools -> If the miners do not have a valid CPID, they can't find a block in the first 15 minutes after a block was found -> The pool can't find blocks in this timeframe Smiley
jr. member
Activity: 405
Merit: 3
While the error itself seems to be normal, the rate with which it occurs surely isn't (maybe two dozen of these per second...).  Roll Eyes

I honestly wonder who is mining the blocks right now, because somehow the pools (or at least the main pool) don't seem to have gotten a single paid block since 49200..

From my understanding, there is a fall back after 15 minutes where anyone can mine a block. So, I believe this is how it will work until the next daily superblock is in effect. Since we all effectively have no magnitude for one blockchain day, it becomes a race to first acceptable block after 15 minutes of errors in the log.
Yes I think so too, but all this should imo NOT influence the chance of the pools finding blocks, or am I wrong here? The percentage distribution of hashrate today shouldn't be different from two days ago.
full member
Activity: 1176
Merit: 111
Too many bugs after the Superblock ..
Hope Rob can fix it A.S.A.P. , and it should make other way for superblock payment to prevent these bugs occurs.

Rob commented a while ago about knowing what went wrong, but not wanting to force another mandatory update prior to the June one.

Hopefully the fix is in place before the next monthly block.


The conflicting superblock issue is known, and should be fixed before the next budget superblock from what I've read.  Because there was no PoDC superblock, everyone's MAG got knocked down to 0.  Since no one has MAG, the blocks take 15+ minutes to solve (since until the block time hits 15 minutes, you must have MAG to solve, after that, it's open to all).  This should be the last time this bug rears it's head.

Any thoughts on C-CEX going on vacation, on the release of a mandatory upgrade next month? Does this mean C-CEX will be on an unacceptable version? Disallowing transactions on the exchange seems like a wise move in this context.
full member
Activity: 1176
Merit: 111
While the error itself seems to be normal, the rate with which it occurs surely isn't (maybe two dozen of these per second...).  Roll Eyes

I honestly wonder who is mining the blocks right now, because somehow the pools (or at least the main pool) don't seem to have gotten a single paid block since 49200..

From my understanding, there is a fall back after 15 minutes where anyone can mine a block. So, I believe this is how it will work until the next daily superblock is in effect. Since we all effectively have no magnitude for one blockchain day, it becomes a race to first acceptable block after 15 minutes of errors in the log.
jr. member
Activity: 490
Merit: 4
Just tried starting POW mining on another linux machine, now there is an additional error block constantly occuring:
Code:
2018-05-29 16:45:06
ProcessBlockFound::Generated 531.66911489
2018-05-29 16:45:06  CPID is not in prior superblock.  Contextual check block failed.  CPID db10b6e68bce4cf573a2937ddd7f4d10, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 16:45:06 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted
2018-05-29 16:45:06  CPID is not in prior superblock.  Contextual check block failed.  CPID db10b6e68bce4cf573a2937ddd7f4d10, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 16:45:06 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted
2018-05-29 16:45:06  CPID is not in prior superblock.  Contextual check block failed.  CPID db10b6e68bce4cf573a2937ddd7f4d10, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 16:45:06 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted
2018-05-29 16:45:06  CPID is not in prior superblock.  Contextual check block failed.  CPID db10b6e68bce4cf573a2937ddd7f4d10, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 16:45:06 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted
While the error itself seems to be normal, the rate with which it occurs surely isn't (maybe two dozen of these per second...).  Roll Eyes

I honestly wonder who is mining the blocks right now, because somehow the pools (or at least the main pool) don't seem to have gotten a single paid block since 49200..

They are going to folks that are heat mining, but only to folks after 15min has elapsed since the last block was generated.

Code:
49299 : 96892ec0fc8a2710fa84f26c9c84cd3e
49300 : fa5062d1c29baf2e298b674f40ee59b7
49301 : fa5062d1c29baf2e298b674f40ee59b7
49302 : 96892ec0fc8a2710fa84f26c9c84cd3e
49303 : 684b644e09134455f34639d65bea3851
49304 : 684b644e09134455f34639d65bea3851
49305 : 96892ec0fc8a2710fa84f26c9c84cd3e
49306 : 4ccf98820bb7e49687830de075251942
49307 : 4ccf98820bb7e49687830de075251942
49308 : 96892ec0fc8a2710fa84f26c9c84cd3e
49309 :
49310 :
49311 : 96892ec0fc8a2710fa84f26c9c84cd3e
49312 : 4928c2303e4e4ff44eb031b5a95403b3
49313 : 4928c2303e4e4ff44eb031b5a95403b3
49314 : 96892ec0fc8a2710fa84f26c9c84cd3e
49315 : 3f78732b8867b33a2b34197cab50f4f2
49316 : 3f78732b8867b33a2b34197cab50f4f2
49317 : 96892ec0fc8a2710fa84f26c9c84cd3e
49318 :
49319 :
49320 : 96892ec0fc8a2710fa84f26c9c84cd3e
49321 :
49322 :
49323 : 96892ec0fc8a2710fa84f26c9c84cd3e
49324 :
49325 :
49326 : 96892ec0fc8a2710fa84f26c9c84cd3e
49327 : 684b644e09134455f34639d65bea3851
49328 : 684b644e09134455f34639d65bea3851
49329 : 96892ec0fc8a2710fa84f26c9c84cd3e
49330 : 81a9edf3cda71577fa658525188b5982
49331 : 81a9edf3cda71577fa658525188b5982
49332 : 96892ec0fc8a2710fa84f26c9c84cd3e
49333 : 4928c2303e4e4ff44eb031b5a95403b3
49334 : 4928c2303e4e4ff44eb031b5a95403b3
49335 : 96892ec0fc8a2710fa84f26c9c84cd3e
49336 : 684b644e09134455f34639d65bea3851
49337 : 684b644e09134455f34639d65bea3851
49338 : 96892ec0fc8a2710fa84f26c9c84cd3e


What I find interesting is the blocks with no CPID, these folks would not be able to mine generally..
edit:
also since cpid's are allowed to double-up mine.. this puts us at risk of a double-spend with less effort,  so keep miners running ...
jr. member
Activity: 405
Merit: 3
Just tried starting POW mining on another linux machine, now there is an additional error block constantly occuring:
Code:
2018-05-29 16:45:06
ProcessBlockFound::Generated 531.66911489
2018-05-29 16:45:06  CPID is not in prior superblock.  Contextual check block failed.  CPID db10b6e68bce4cf573a2937ddd7f4d10, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 16:45:06 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted
2018-05-29 16:45:06  CPID is not in prior superblock.  Contextual check block failed.  CPID db10b6e68bce4cf573a2937ddd7f4d10, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 16:45:06 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted
2018-05-29 16:45:06  CPID is not in prior superblock.  Contextual check block failed.  CPID db10b6e68bce4cf573a2937ddd7f4d10, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 16:45:06 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted
2018-05-29 16:45:06  CPID is not in prior superblock.  Contextual check block failed.  CPID db10b6e68bce4cf573a2937ddd7f4d10, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 16:45:06 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted
While the error itself seems to be normal, the rate with which it occurs surely isn't (maybe two dozen of these per second...).  Roll Eyes

I honestly wonder who is mining the blocks right now, because somehow the pools (or at least the main pool) don't seem to have gotten a single paid block since 49200..
full member
Activity: 406
Merit: 101
Too many bugs after the Superblock ..
Hope Rob can fix it A.S.A.P. , and it should make other way for superblock payment to prevent these bugs occurs.

Rob commented a while ago about knowing what went wrong, but not wanting to force another mandatory update prior to the June one.

Hopefully the fix is in place before the next monthly block.


The conflicting superblock issue is known, and should be fixed before the next budget superblock from what I've read.  Because there was no PoDC superblock, everyone's MAG got knocked down to 0.  Since no one has MAG, the blocks take 15+ minutes to solve (since until the block time hits 15 minutes, you must have MAG to solve, after that, it's open to all).  This should be the last time this bug rears it's head.
jr. member
Activity: 490
Merit: 4
Too many bugs after the Superblock ..
Hope Rob can fix it A.S.A.P. , and it should make other way for superblock payment to prevent these bugs occurs.

Rob commented a while ago about knowing what went wrong, but not wanting to force another mandatory update prior to the June one.

Hopefully the fix is in place before the next monthly block.

newbie
Activity: 39
Merit: 0
Too many bugs after the Superblock ..
Hope Rob can fix it A.S.A.P. , and it should make other way for superblock payment to prevent these bugs occurs.

jr. member
Activity: 490
Merit: 4
Dang thanks for the notice on the debug.log... 5k on my linux machine

So far I have watched as 3 more blocks I "mined" were stripped away heh..  

They all got 1 confirmation, then disappeared after the next block was mined. this is going to be a fun day Smiley

edit: not that I expected anywhere near that many to be mined.. but this is the first time I believe I've seen mined blocks orphaned.

edit2:  Interesting... many blocks being mined right after the other by a single cpid...
This would explain some of it..  49312 was one I lost,  as well as 49315 and 49327


49312 : 4928c2303e4e4ff44eb031b5a95403b3
49313 : 4928c2303e4e4ff44eb031b5a95403b3
49314 : 96892ec0fc8a2710fa84f26c9c84cd3e
49315 : 3f78732b8867b33a2b34197cab50f4f2
49316 : 3f78732b8867b33a2b34197cab50f4f2
49317 : 96892ec0fc8a2710fa84f26c9c84cd3e
49318 :
49319 :
49320 : 96892ec0fc8a2710fa84f26c9c84cd3e
49321 :
49322 :
49323 : 96892ec0fc8a2710fa84f26c9c84cd3e
49324 :
49325 :
49326 : 96892ec0fc8a2710fa84f26c9c84cd3e
49327 : 684b644e09134455f34639d65bea3851
49328 : 684b644e09134455f34639d65bea3851

jr. member
Activity: 405
Merit: 3
Is something wrong right now?
My Desktop PC is not showing all transactions, biblepay-centrals biblepayd is stuck ad "Loading block index" and https://explorebiblepay.com/ is down, as is my own explorer.

Error on biblepay-central:
2018-05-29 09:25:04 Verifying governance.dat format...
2018-05-29 09:25:04 ERROR: Read: Checksum mismatch, data corrupted
2018-05-29 09:25:04 Error reading governance.dat: Dump: File format is unknown or invalid, please fix it manually

Edit: The error on the explorer is longer:

Anyone else having any problems?

My wallet seems to be stable (v1.1.2.4).  Current block 49306, Last block time: Tue May 29 12:23:26 2018 (BST = GMT+1/UTC+1)

EDIT: I do see the following in my debug.log though, so that may relate to the error:

2018-05-29 11:52:35  CPID is not in prior superblock.  Contextual check block failed.  CPID 557d748a659072797daf84734316fd49, Payments: 0.000000  ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-05-29 11:52:35 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted

Also it is writing this error to the logfile a lot - I renamed the old log after closing Biblepay, and in under half an hour the new log had reached 235MB and over 2.6 million lines, so is likely what is crashing it on some people's machines.

Try starting the wallet with "-printtoconsole" to see if that stops it crashing.

Yes, my Win10 wallet just crashed again. I checked the debug.log and it's a whopping 1.7 GB (!), and that's after I deleted it maybe 2 hours ago! I think I will leave it for now and wait until things are sorted out. :-D

P.S.: My Win7 wallet is also starting to fill up the debug.log, now already at 900 MB :/.

P.P.S: On Linux it's even worse, one is over 4GB already, last entries all look like this:
Code:
CTransaction(hash=d3c995962a, ver=1, vin.size=2, vout.size=2, nLockTime=49251)
    CTxIn(COutPoint(1e4473ba95370f1cf6561dc5362d12068d1763b821b1379b2ceca84fafa4becf, 0), scriptSig=483045022100defb89c7cfaf, nSequence=4294967294)
    CTxIn(COutPoint(1e4473ba95370f1cf6561dc5362d12068d1763b821b1379b2ceca84fafa4becf, 1), scriptSig=47304402205c49db6cfc7866, nSequence=4294967294)
    CTxOut(nValue=0.03764780, scriptPubKey=76a9148ac427afb9ee16f8c2303e16)
    CTxOut(nValue=3597.00000000, scriptPubKey=76a914e965155a4b2f5b5b2b3476ac)

  CTransaction(hash=2a6f32aea8, ver=1, vin.size=2, vout.size=2, nLockTime=49326)
    CTxIn(COutPoint(f45b2c6f51f34570f3e0a26acad29f276af689d0d101b5b1a2d6eb6e4082858b, 0), scriptSig=473044022051a5413716f3e2, nSequence=4294967294)
    CTxIn(COutPoint(f45b2c6f51f34570f3e0a26acad29f276af689d0d101b5b1a2d6eb6e4082858b, 1), scriptSig=47304402203b9fe7c87cc2ed, nSequence=4294967294)
    CTxOut(nValue=0.02540500, scriptPubKey=76a914dd309b00d0ccbd86301714be)
    CTxOut(nValue=12477.00000000, scriptPubKey=76a914e6155af1e7a0bf3d6d118921)
Jump to: