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

[Lichtsucher]

Its not really quite bad, since the exchanges are down, all coins sent on either version will either be orphaned or live on the 1101+ chain.
Its to be expected, because starting on 1101, we require the higher protocol version in order to communicate.
The fork is not a hard fork (related to block cutover) its just network segmentation.
So Im not quite ready to say its time for a mandatory because were not actually done testing.  We'll hurry.

Then I will update the purepool to the current version now, too.

[Lichtsucher]

The chain seems to be joined again, right? ^^

1.1.0.1 System from the post above:
biblepay-cli getblockhash 33268
80447526670309ff730eb64c81e8c1ef4a67a2f7a173aa351fba338eee5ce4eb

Same system now (nothing changes, simply executed the command again)
biblepay-cli getblockhash 33268
550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1

The main pool is also on the same height again

[bible_pay]

Its not really quite bad, since the exchanges are down, all coins sent on either version will either be orphaned or live on the 1101+ chain.
Its to be expected, because starting on 1101, we require the higher protocol version in order to communicate.
The fork is not a hard fork (related to block cutover) its just network segmentation.
So Im not quite ready to say its time for a mandatory because were not actually done testing.  We'll hurry.

Then I will update the purepool to the current version now, too.

Sorry about that, we had the best intentions. 

[bible_pay]

The chain seems to be joined again, right? ^^

1.1.0.1 System from the post above:
biblepay-cli getblockhash 33268
80447526670309ff730eb64c81e8c1ef4a67a2f7a173aa351fba338eee5ce4eb

Same system now (nothing changes, simply executed the command again)
biblepay-cli getblockhash 33268
550699009b14fe33f79be164dbba0ac063e4423d7a0fa75f119738704c7388d1

The main pool is also on the same height again

Its very possible this happened, because we usually have at least one "hobbyist" out there who lowers the protocol version to try to get their solutions on the new chain.  The hard fork does not occur til 33400.  The code is programmed to reorganize to the chain with the most work.

So we probably bucked all the CPIDs off the new chain (1101), and they probably need to re-associate those cpids all over again.

Oh well, thats the life of a cancer researcher .

After 33400 however yes we need to expect full reliability and trace all missing transactions and pay them.

[Lichtsucher]

Sorry about that, we had the best intentions.  

Better do hard changes now then later, the coin is still small enough.
And big changes are sometimes raw at the start.

Nobody will remember such problems in a month when everything is working good again 

[bible_pay]

One little surprise tidbit of info we have coming in the future- since Biblepays future relies on a lot of cancer transactions, due to the new
 PODC integrity feature (where an unspent coin is tied to a cancer task) we will most likely raise the average transaction fee from milliBBP to centBBP or maybe even BBP in some cases.  This means even though mining revenue is dropping by 90%, there will be a lot more fees collected by miners per block in a few months (after we have about 2500 CPIDs cancer researching constantly).

Meaning that I expect a block to be 600 in payment for the heat side, plus 100 or so BBP in fees.  So we will not have complete famine for the heat miners.

[Lichtsucher]

Mhh, there still is a difference between the 1.1.0.1+ chain and the older clients.

My 1.0.8.6 system shows a height of 33275, the explorer does the same. But the main pool, purepool and my 1.1.0.1 client show 33272 as height

I just saw it in my logs, I get a lot of invalid heights (invalid from the point of view of the purepool), as 33275 is highter then the allowed 33272 (height of the purepool)

Maybe not all is fine. But with the new release near, we will survive it

[bible_pay]

Mhh, there still is a difference between the 1.1.0.1+ chain and the older clients.

My 1.0.8.6 system shows a height of 33275, the explorer does the same. But the main pool, purepool and my 1.1.0.1 client show 33272 as height

I just saw it in my logs, I get a lot of invalid heights (invalid from the point of view of the purepool), as 33275 is highter then the allowed 33272 (height of the purepool)

Maybe not all is fine. But with the new release near, we will survive it

Thats normal, the 1101+ is not accepting the 1086 blocks right away, but after it has no choice then it pulls it in.

[Lichtsucher]

Launchpad is building Ubuntu packages for 1.1.0.2c right now

[Bitconee]

Guys my hashrate fell like 80-90%. Is this supposed to happen? Am I gonna get that much less BBP's or is it gonna sort itself out somehow? 

[orbis]

Guys my hashrate fell like 80-90%. Is this supposed to happen? Am I gonna get that much less BBP's or is it gonna sort itself out somehow? 

Yes this is normal with new version.

[dave_bbp]

Hello everyone,

it seems I'm having trouble with my CPID association in prod. I tried PODC in testnet couple of weeks ago and it worked perfectly. Yesterday I associated my CPID to my main wallet, the transaction was completed and the wallet said "successful".
However it doesn't seem to have worked. My exec getboincinfo still looks like this:

Code:

{
  "Command": "getboincinfo",
  "CPID": "",
  "Address": "",
  "CPIDS": "",
  "CPID-Age (hours)": 422322,
  "NextSuperblockHeight": 33620,
  "NextSuperblockBudget": 760165,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 0,
  "Total Budget (One Day)": 0,
  "Total Budget (One Week)": 0,
  "Superblock Count (One Week)": 0,
  "Superblock Hit Count (One Week)": 0,
  "Superblock List": "",
  "Last Superblock Height": 0,
  "Last Superblock Budget": 0,
  "Last Superblock Payment": -2,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 0
}

I tried to just associate again, but the wallet just returns "Unable to sign CPID 7c9264559fef3c1c689ee9fc3ff42494". Usually it should take about 6 blocks only to let the CPID show up, correct? Could it be I associated it on a fork, since yesterday I think I still used 1.0.9.x?

[orbis]

Hello everyone,

it seems I'm having trouble with my CPID association in prod. I tried PODC in testnet couple of weeks ago and it worked perfectly. Yesterday I associated my CPID to my main wallet, the transaction was completed and the wallet said "successful".
However it doesn't seem to have worked. My exec getboincinfo still looks like this:

I tried to just associate again, but the wallet just returns "Unable to sign CPID 7c9264559fef3c1c689ee9fc3ff42494". Usually it should take about 6 blocks only to let the CPID show up, correct? Could it be I associated it on a fork, since yesterday I think I still used 1.0.9.x?

Just wait those 6 blocks. If it was successful than it might be OK.

[jaapgvk]

Guys my hashrate fell like 80-90%. Is this supposed to happen? Am I gonna get that much less BBP's or is it gonna sort itself out somehow? 

Yes this is normal with new version.

We haven't reached the cut-off block for PODC yet, so rewards are still the same, but there is some unexpected behavior going on with our blockchain, so everyone: please prepare to upgrade your wallets soon.

[bible_pay]

Guys my hashrate fell like 80-90%. Is this supposed to happen? Am I gonna get that much less BBP's or is it gonna sort itself out somehow? 

After block 33400, with PODC it is better to just lower your hashrate and increase your Rosetta cancer intensity.
But between now and 33400, you can go ahead and increase your genproclimit as high as you want - if you want to expend more for POW.

The reason for the difference is we have a 250ms sleep in the new miner by default, its easier to just increase your genproclimit than to disable it.  Or you can set the 'minersleep=0' parameter if you wish.

[bible_pay]

From Vultr staff regarding CPU utilization abuse:

Hello,

   If you're setting maximum usage to 60% per core, you shouldn't encounter any issues -- when we check for abusive CPU usage, we're generally looking for CPU usage that's pegged at maximum (100% on a single-core instance, or some multiple of 100% for multi-core instances). You can use the 'uptime' tool to see system load averages -- this is the same kind of data that we get on the hypervisor side when monitoring VPS resource utilization.

If you have any further questions, please let us know!

Lloyd W. Slade
System Administrator

[bible_pay]

Launchpad is building Ubuntu packages for 1.1.0.2c right now

Thanks a lot buddy, and brother if in Christ.

[slovakia]

very very very weird........ total mess.... and again HURRY HURRY HURRY.......

0/confirmed .... its main chain broken?

masternode winners is broken too

what will be next?

[bible_pay]

Biblepay - v1.1.0.2
Mandatory Upgrade
For entire network (Sanctuaries and Users)

- Enable Proof-of-Distributed Computing at block 33440

[slovakia]

bible_pay can you to explain why is all transfers 0/confirmation? thx