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

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: capulo on June 03, 2019, 02:26:50 AM

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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: thesnat21 on June 03, 2019, 10:16:52 AM

Quote from: bible_pay on June 03, 2019, 10:05:05 AM

Quote from: thesnat21 on June 03, 2019, 10:03:36 AM

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": "1.4.3.1"
},
{
"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.

thesnat21

jr. member

Activity: 490

Merit: 4

Quote from: bible_pay on June 03, 2019, 10:05:05 AM

Quote from: thesnat21 on June 03, 2019, 10:03:36 AM

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": "1.4.3.1"
},
{
"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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: slovakia on June 03, 2019, 06:51:36 AM

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.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: slovakia on June 03, 2019, 04:01:14 AM

next bad things for new users Sad

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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: capulo on June 03, 2019, 02:26:50 AM

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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: togoshigekata on June 03, 2019, 09:35:27 AM

Quote from: bible_pay on June 02, 2019, 05:34:00 PM

Quote from: slovakia on June 02, 2019, 05:31:51 PM

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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: oncoapop on June 03, 2019, 07:42:09 AM

Quote from: slovakia on June 03, 2019, 06:51:36 AM

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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: thesnat21 on June 03, 2019, 10:03:36 AM

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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: eternalenvoy on June 03, 2019, 12:33:20 AM

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.

thesnat21

jr. member

Activity: 490

Merit: 4

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

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: slovakia on June 03, 2019, 12:28:32 AM

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.

togoshigekata

full member

Activity: 1260

Merit: 115

Quote from: bible_pay on June 02, 2019, 05:34:00 PM

Quote from: slovakia on June 02, 2019, 05:31:51 PM

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

oncoapop

newbie

Activity: 5

Merit: 0

Quote from: capulo on June 03, 2019, 08:49:01 AM

Quote from: oncoapop on June 03, 2019, 07:42:09 AM

Quote from: slovakia on June 03, 2019, 06:51:36 AM

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.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: inblue on June 03, 2019, 07:49:23 AM

Quote from: yaronidon on June 02, 2019, 10:00:39 PM

Quote from: bible_pay on June 02, 2019, 09:26:27 PM

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.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: capulo on June 03, 2019, 02:26:50 AM

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.

capulo

newbie

Activity: 491

Merit: 0

Quote from: oncoapop on June 03, 2019, 07:42:09 AM

Quote from: slovakia on June 03, 2019, 06:51:36 AM

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

inblue

full member

Activity: 462

Merit: 103

Quote from: yaronidon on June 02, 2019, 10:00:39 PM

Quote from: bible_pay on June 02, 2019, 09:26:27 PM

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.

oncoapop

newbie

Activity: 5

Merit: 0

Quote from: slovakia on June 03, 2019, 06:51:36 AM

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.

slovakia

full member

Activity: 770

Merit: 100

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

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