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

[bible_pay]

hps overflow

  "hashps": -17821.16225721191,


and now all miners says:   "poolinfo2": "ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN
w...

Let me try to reproduce this on my machine.  If need be, we will set the key to fix this.

[1714649701]

1714649701

[1714649701]

1714649701

[bible_pay]

Where do you see sourcelink that is wrong (we now have millions of lines of code and multiple sites and systems)?

www.biblepay.org -> WALLET -> Source

I think it was a bad idea to change our Github link, because there are many sites which automatically track development progress of coins, such as activity, number of commits, number of contributors, number of stars etc. And now they will lose track of BiblePay, so it will stagnate and rank lower in their lists, and over time it will appear as an abandoned coin, which is a shame, because this is one of the most active coins. And even if they find the new Github link and replace it, the development activity will reset to 0. Unless this linkage to Dash source improves it, but I doubt that they would count those 15,000 commits as BBP's.

Not possible; we had a prod system using the old link with a thousand users and a parallel build system for (classic), and a new system in development with over 1 million new lines of code.

I'm proud to be a part of the new branch as we are moving forward in a cleaner state.

 

[oncoapop]

ROB
why still losing miners on your pool


"hashps": -141049.1328107696,
"minerstarttime": "06-03-2019 08:16:42",
"hashcounter": -1812370492

check it,where is bug


thanks

On pool.biblepay.org at the moment (not like the previous night), some of my miners A & B appear to have a disproportionate boost in reported hashps when compared to my other miner (at least from this snapshot using reported pool hashps).

All are v1.4.3.1 and have similar conf files and importantly had the same conf files before block 123,000. Let's see if this translates into an increase in successfully mined blocks or not... (However, I can't tell from the pool though which worker mined the blocks...)

ID   OS                   Hashps (EVO)   Processor(s)      Approx hashps (EVO) with classic <123,000
A     Ubuntu 18.04   32,000             2xE5650            ~7000
B    Ubuntu 18.04     22,000             2xE5645           ~6500    
C    Windows 10 Pro  6,800              E5-2650L (ES)   ~5000

Edit: Sorry but that's all the data I have at the moment. This definitely needs a larger dataset. This data is shared so that this hypothesis (I am not making a conclusion and no one should at this stage...) can be investigated.

it is not affected by pool, also solo mining starts throwing hps like crazy, also negative numbers...
what i dont understand is, why my machines in pool hitting blocks, and solo machines nope... 0 blocks for 2 days period. before evo i had ~ 10 blocks/day with even higher diff

You are correct: pool.biblepay.org is just a control environment - all my 3 quoted miners are on the pool but the Ubuntu miners seem to report much higher hashps than my single windows miner. The increase appears to be disproportionate.

[togoshigekata]

getblockhash 48800 10cd2a8a52c95b79e320c57b147423fab5ef573273eecdbaf3750c9b2033539f

its correct chain?

getblockhash 123160

a05adbf7befd7b3e39fd9d37a0c145dd826d9f2e2a56c448f1c775e43ffbc882
(Diff is 10k)

=-=-=-=-=-=

I'm sure Togo is upgrading explorer.biblepay.org; Togo let us know if Evo runs faster for its database (maybe its fixed).

getblockhash 123291
a3c817***************

Explorer has been updated, its been syncing very fast
http://explorer.biblepay.org

[bible_pay]

whats correct conf? im mining and 0 hashes is

addnode=66.181.33.129:40000
addnode=213.250.22.35:40000
addnode=94.177.230.30:40000
addnode=104.167.97.213:40000
addnode=209.250.243.91:40000
addnode=45.76.61.179:40000
addnode=66.181.33.132:40000
addnode=155.138.165.167:40000
addnode=dns1.biblepay.org
addnode=node.biblepay.org
gen=1
genproclimit=15


where is bug?

thanks

Please either scan your log for 'biblepayminer' and see if there is an error in creating a block, or post the log and Ill look at it.

[thesnat21]

It seems the MN reward dropped by about 1k,  is this due to DGW or QT?

Have not seen any mining rewards yet.

[bible_pay]

I looked at two different blockhash, and their values are very close. The values differ only by 2-5 blockhash
which is the normal?

I think this is due to the 1.2.0.1 still more than the 1.4.3.1 in currently, which causes this to happen.

Should MN need mandatory update to the 1.4.3.1 and automatically block the 1.2.0.1?

getblockhash 123206
2eb580b31020f70e506b293576b53d18d75cc8d71a4604126e0e94489fb1bf7d

masternode of 1.4.3.1 Version


Details for Block #123206
Hash    25fe70c744fec7adf54f275b9875665e735695eadc684d038fb7fee5e64d8755

chainz explorer

Hi Eternal,
1) On the blockhash, even though the first hex character is close, the whole hash is still different (another words its just a coincidence the hashes are close) - hash functions on one digit are wildly different.
2) The Chainz explorer is on the wrong chain (they are on 1.2.0.1) Biblepay Classic.  Classic just went out of sync on its own fork last night.. I have an e-mail in my inbox that I believe chainz is working on upgrading now.

Please use the 1.4.3.1 explorer for now for reference.

[bible_pay]

It seems the MN reward dropped by about 1k,  is this due to DGW or QT?

Have not seen any mining rewards yet.

Could you please post an example block #?

Then I can give an example.  QT is off however.

[bible_pay]

ROB
why still losing miners on your pool


"hashps": -141049.1328107696,
"minerstarttime": "06-03-2019 08:16:42",
"hashcounter": -1812370492

check it,where is bug


thanks

On pool.biblepay.org at the moment (not like the previous night), some of my miners A & B appear to have a disproportionate boost in reported hashps when compared to my other miner (at least from this snapshot using reported pool hashps).

All are v1.4.3.1 and have similar conf files and importantly had the same conf files before block 123,000. Let's see if this translates into an increase in successfully mined blocks or not... (However, I can't tell from the pool though which worker mined the blocks...)

ID   OS                   Hashps (EVO)   Processor(s)      Approx hashps (EVO) with classic <123,000
A     Ubuntu 18.04   32,000             2xE5650            ~7000
B    Ubuntu 18.04     22,000             2xE5645           ~6500    
C    Windows 10 Pro  6,800              E5-2650L (ES)   ~5000

Edit: Sorry but that's all the data I have at the moment. This definitely needs a larger dataset. This data is shared so that this hypothesis (I am not making a conclusion and no one should at this stage...) can be investigated.

Thanks, Sounds like its going to be a busy day .


I'll check this too.

[bible_pay]

getblockhash 48800 10cd2a8a52c95b79e320c57b147423fab5ef573273eecdbaf3750c9b2033539f

its correct chain?

getblockhash 123160

a05adbf7befd7b3e39fd9d37a0c145dd826d9f2e2a56c448f1c775e43ffbc882
(Diff is 10k)

=-=-=-=-=-=

I'm sure Togo is upgrading explorer.biblepay.org; Togo let us know if Evo runs faster for its database (maybe its fixed).

getblockhash 123291
a3c817***************

Explorer has been updated, its been syncing very fast
http://explorer.biblepay.org

Wow, thats great!  Do you think our Evo branch fixed the slowness in Iquidis?  Ill wait til you test it out for 24 hours or so.

[bible_pay]

hps overflow

  "hashps": -17821.16225721191,


and now all miners says:   "poolinfo2": "ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN
w...

I just realized one difference in my test environment; I created my cpk this morning.

Can you please try this first: 
exec cpk your_nickname

exec join pog


Then come back after 5 confirms and restart your miners.  If you still have trouble with an ABN weight too low, please post the log surrounding the error, it probably has additional details in there where it creates the block.


In the mean time Ill ensure ABN req weight is 0 at the network level.

[bible_pay]

next bad things for new users

http://wiki.biblepay.org/Ubuntu_Packages


first things for all updates/upgrades is changing all old links and guidelines on main web


please,change it

It looks like Licht maintains this; or MIP, would you like to edit this?  I think we need to wait for MIP to complete the chiaBLS fix first so then he will know the repo name.

[bible_pay]

ROB
why still losing miners on your pool


"hashps": -141049.1328107696,
"minerstarttime": "06-03-2019 08:16:42",
"hashcounter": -1812370492

check it,where is bug


thanks

Well it looks like the biggest problem is half of the miners are still running classic.  All the ones with 99.9% error rates appear to be on the wrong chain (1.2.0.1).

MillerPR is smoking somehow with 400,000 HPS (that is 4* higher than normal).

Yeah, Ill check this out also, Im prioritizing.

NOTE that even with this very high diff (> 50K),  pool.biblepay.org solved 28 blocks!  Thats almost double the normal.

[thesnat21]

It seems the MN reward dropped by about 1k,  is this due to DGW or QT?

Have not seen any mining rewards yet.

Could you please post an example block #?

Then I can give an example.  QT is off however.

I just looked at 127397
13df1109030fb47f7e19d9366c10956a391fa9d469168ff64b0d49fa3cf8b6c3

I noticed our hashrates are orders of magnitude larger,  a machine that used to do 8k hps is doing 200k hps.

This could be affecting the difficuly / DGW calc?

Code:

"vout": [
    {
      "value": 2739.76625668,
      "valueSat": 273976625668,
      "n": 0,
      "scriptPubKey": {
        "asm": "0399218fcbe7ae8eb836c5bae60b221a2c5097877561249f531f339d4cbc61003f OP_CHECKSIG",
        "hex": "210399218fcbe7ae8eb836c5bae60b221a2c5097877561249f531f339d4cbc61003fac",
        "reqSigs": 1,
        "type": "pubkey",
        "addresses": [
          "B5NvpPVkiJPQXYtjnQMEzY2Egh9oWzW5X9"
        ]
      },
      "message": "<VER>1.4.3.1</VER>"
    }, 
    {
      "value": 2739.76625668,
      "valueSat": 273976625668,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 cd1d9adc8c09cc7934f5363461469662ef40778b OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914cd1d9adc8c09cc7934f5363461469662ef40778b88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "BP9dc2XhBahAmwRcvtawSdYm7HcGEeWwCm"
        ]
      },
      "message": ""
    }

[bible_pay]

It seems the MN reward dropped by about 1k,  is this due to DGW or QT?

Have not seen any mining rewards yet.

Could you please post an example block #?

Then I can give an example.  QT is off however.

I just looked at 127397
13df1109030fb47f7e19d9366c10956a391fa9d469168ff64b0d49fa3cf8b6c3

I noticed our hashrates are orders of magnitude larger,  a machine that used to do 8k hps is doing 200k hps.

This could be affecting the difficuly / DGW calc?

Code:

"vout": [
    {
      "value": 2739.76625668,
      "valueSat": 273976625668,
      "n": 0,
      "scriptPubKey": {
        "asm": "0399218fcbe7ae8eb836c5bae60b221a2c5097877561249f531f339d4cbc61003f OP_CHECKSIG",
        "hex": "210399218fcbe7ae8eb836c5bae60b221a2c5097877561249f531f339d4cbc61003fac",
        "reqSigs": 1,
        "type": "pubkey",
        "addresses": [
          "B5NvpPVkiJPQXYtjnQMEzY2Egh9oWzW5X9"
        ]
      },
      "message": "<VER>1.4.3.1</VER>"
    }, 
    {
      "value": 2739.76625668,
      "valueSat": 273976625668,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 cd1d9adc8c09cc7934f5363461469662ef40778b OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914cd1d9adc8c09cc7934f5363461469662ef40778b88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "BP9dc2XhBahAmwRcvtawSdYm7HcGEeWwCm"
        ]
      },
      "message": ""
    }

Oh thats block 123297, ok.
Yeah, its not DGW in this case (You will see more like a 1k-2k reduction when diff is > 90,000) but this diff is just 25K, not a big deal (probably a 500BBP reduction) but anyway the large change occurred at block 123201 (Evo cutover height).

At this height bbp started escrowing additional for GSC contracts (which are 1mm bbp per day, deflating as usual).  So the normal reward was about 10K for heat, with it being 5.4K the remaining 4.6k went to the GSC budget.

[bible_pay]

hps overflow

  "hashps": -17821.16225721191,


and now all miners says:   "poolinfo2": "ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN weight is too low to mine; ABN
w...

So to address this one and Slovakia's negative hashps as the same time:

This is strictly confined to the hashcounter (in getmininginfo), which we have set up as an int.
We will change this to an int64_t in the next release.

In the mean time, you can restart your mining with (setgenerate true N) and it will reset.

This should not be hurting anything.

[bible_pay]

Since BBP is already escrowing GSC funds we might as well start enabling the GSC rewards.

Everyone please create your CPKs and join the POG campaign.
Optionally join Healing if you plan on praying for others, casting out demons, or being a street healer.

The next GSC superblock is at 123430.  We have one CPK who made it in that block (Congratulations Worldpeace!, you might get 870,000 BBP!).

Remember that all of us that join today will be in tomorrows block (123,635).

After you wait 6 confirms, type 'exec sendgscc' to force one out.
Then after 6 more blocks, type 'leaderboard' to see if you are in tomorrows superblock.

Or, you can do it the easy way, and just click on the Leaderboard from the GUI and see if you make it in.

[bible_pay]

Capulo, I don't see any abn errors personally, but I have a cpk.

Im not hearing any other complaints of this ABN issue.  To be safe, I set the ABN weight to 0, and the future abn starting height to 126000.

Please double check now, after you create your cpk.

[thesnat21]

Since BBP is already escrowing GSC funds we might as well start enabling the GSC rewards.

Everyone please create your CPKs and join the POG campaign.
Optionally join Healing if you plan on praying for others, casting out demons, or being a street healer.

The next GSC superblock is at 123430.  We have one CPK who made it in that block (Congratulations Worldpeace!, you might get 870,000 BBP!).

Remember that all of us that join today will be in tomorrows block (123,635).

After you wait 6 confirms, type 'exec sendgscc' to force one out.
Then after 6 more blocks, type 'leaderboard' to see if you are in tomorrows superblock.

Or, you can do it the easy way, and just click on the Leaderboard from the GUI and see if you make it in.

Wow congrats worldpeace...

Will do on the GSC.  Since I missed the end of testnet,  POG still requires us to send funds in, will the wallet do this auto?

[bible_pay]

Since BBP is already escrowing GSC funds we might as well start enabling the GSC rewards.

Everyone please create your CPKs and join the POG campaign.
Optionally join Healing if you plan on praying for others, casting out demons, or being a street healer.

The next GSC superblock is at 123430.  We have one CPK who made it in that block (Congratulations Worldpeace!, you might get 870,000 BBP!).

Remember that all of us that join today will be in tomorrows block (123,635).

After you wait 6 confirms, type 'exec sendgscc' to force one out.
Then after 6 more blocks, type 'leaderboard' to see if you are in tomorrows superblock.

Or, you can do it the easy way, and just click on the Leaderboard from the GUI and see if you make it in.

Wow congrats worldpeace...

Will do on the GSC.  Since I missed the end of testnet,  POG still requires us to send funds in, will the wallet do this auto?

Yea, we just have to double check that a GSC quorum exists and it pays out at 123430, but from what I see, typing exec health for example, the sancs only found worldpeace in this contract (early bird!), and 33 voted on it, so I believe he will receive this reward .


As far as POG, I didn't want to start right off the bat with an intrusive auto-payment (even though people must join POG for the wallet to send a donation), so right now we have this set at a 2.50 BBP donation once per 24 hours, but please, let me double check all the GSC frequency settings in prod.  Ill also post the keys people can use to override this.

But to answer you question, people do need to keep the donation set up in POG to receive substantial rewards (as outlined in the getting started guide) as cubed root of donation is what drives the multiplier of your coin*age....


When you type exec gscc, you can analyze the tx, and it should send 2.50 to the foundation.