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

[daemonko]

is there some ban / limitation for new ip addresses? i added some machines, but: after biblepayd starts, it takes ages until the blocks are loaded, measured traffic is below 80KB/s; when checking biblepay-cli getmininginfo, the blocks value is increasing very slowly. any similar problems? explanations? what to do? i use ubuntu 16. when i run speedtest-cli, the results are fast enough: download 42mbps, upload 11mbps. any thoughts?

[1715531035]

1715531035

[1715531035]

1715531035

[1715531035]

1715531035

[1715531035]

1715531035

[hvdb]

1.0.7.5 version seem have problem.

It is the second times occurred , I am re-indexing again.
I worry it will happen again....



Hello all!
I have been following this thread and this project for several weeks now and I am really excited to see the hard work and dedication going into developing all of this. However the last couple of days it seems to me that the only concern you have regarding troubleshooting is with the MN owners, not the miners.
Several people reported the above mentioned error and I also experience it regularly since updating to 1.0.7.5 on different machines, different networks, even different cities across Germany. So the error is definitely not on my side, because also the configurations on these machines differ from each other and each and every one gets this error after a few hours of mining.
However, no one has offered any permanent solution or even explained where this is coming from. I think the only reason so few people have this problem is because judging by the connected peers on my systems most people are still on the working version 1.0.7.1.

So when will this annoying problem be fixed? Another question you never answered was how this new "competitive mining" feature really works. Right now it seems to me that all the update did was giving an even bigger malus to the faster CPUs and DualCPU-systems and more and more degrading mining output. For example my 10 year old Core2 laptop with proclimit 1 is sometimes producing almost as many shares as my Dual-hexacore-Xeon server on proclimit 12, which is absolutely ridiculous.

I understand that your main priority right now are your precious masternodes, but please don't forget about us small-time miners and remember that without the miners your blockchain wouldn't really work either. Comparing the output from before Christmas or even from last week I'm currently at approx. 10%, which barely - if at all - covers my electricity bill.

Thanks for your time and effort and God bless this project!


Edit: For clarification: up to now it seems that the error only occurs with the linux client (Ubuntu 16.04 LTS in my case), the windows wallet doesn't seem to be affected.

Hi Dave,

Its just not true that we only care about precious masternodes.

Here is the way I view the priorities right now just so you know:  I want to ensure we are ready for block 24600, so we can pay our orphans. 

Next, I want to maintain production support levels.  That includes any critical errors with 1075.  And finally, I place a very low priority level personally on any "hash speed discussions".  So maybe thats the point of contention.  We only have enough resources to talk about the prod support and the critical errors and not about peoples mining speed, unless its an inconsistency in the pool that affects everyone.

Of course we have time to talk about how competetive mining works.

But first:
So, Im not aware of a critical bug in 1075, and have not received a log.  Can someone please give us a log so we can see what stopped the node in 1075??

There is no way to even look at a problem without a log.

Can we have a look after we hit the 24600 block at the pool?
I can help investigating and testing etc, no problem.

It feels weird that we only hit 20-25% with nearly 2800 miners and 2390627.92 hps.
Are there really lots of people solo mining, could be but I find it hard to believe if we look at the numbers and interest here on the forum.

[aikida3k]

Way to misquote me.  

I don't believe there is such thing as a Hell. We burn our Dead, to send them as a message to the Gods, and they are returned.

Similar to when you say to a kid "You look so much like your grandma" or "You look so much like your Dad". Or when Corn uses Dead Fish to Grow. Or how all the Water we are drinking has been through Dinosaur Urinary tracts, and Animal Urinary tracts over and over. We are brought back as well, maybe not the same form, but our energy is reused.

One time, in like elementary school, I had this dream where I was in a city made of concrete, with graffiti everywhere. And I went inside a building with a wooden door. Then inside, it was like a giant hallway, with benches and pillars and trash cans on 1 side, and the other side was like Movie Theater Picture things, where the lights are surrounding the Movie Poster. And it was all Concrete walls and floors and ceiling, and like a trashed red carpet. And at the end of the hall, on the movie poster side, there was a door, and a staircase. And the next floor was the same as the first, and I went to the end, and up another staircase, and to another identical looking floor. And eventually I ended up in a room with a bunch of other kids, and there was one kid that was older and he was like the leader of all the kids, because it seemed like no one knew where they were. And then he ran into a giant tunnel in the wall, and we followed him, and when we followed him the room was like the top of a mcdonalds play place, where there are different directions to go that are different colors. And each kid went with 1 other kid down a tunnel to find the older kid, and me and 1 other kid were left. So we looked around and found a set of Cafeteria Tables, the kind that fold up, like the long tables with like 50-100 seats, and that can all fold up and roll in a corner. There were some of those in a corner, and we moved them and there was a Maroon tunnel. So we went down it, and then when we got to the room at the other end there was just a staircase that had 2 walls, and the staircase kind of tapered up between the walls. And we were about to walk up the staircase, but then I looked up and there was a vampire or something hanging from the ceiling, and he fell towards me and I woke up.

I had another one where my brother died, and he is actually dead now. It was a much different situation than in the Dream though.

But sure, someone says they went to hell, that makes sense. I don't discount that. But it's not the only place you can go in your Dreams.

Dreams these days are the domain of Babalon.  Ugh.  Go away.  You are only here because of your false god karma.  Go away please.

[bible_pay]

I need to restart some of my miners once/twice per day (reindex fixes them)
The miners that are failing use HTTPS.

The few miners that are running using http seems to be not affected (I haven't needed to restart them, but they are also slower machines)

@Dave, are you using HTTPS or http?

Interesting, indeed I use HTTPS on all of my miners (seemed like the right thing to do...), so perhaps it's really related to that. As soon as one is crashing again I will return to HTTP and see if it runs stable again.


On another note: since the security update on the pool page (required password change) I have to log on again and again because the auto-logoff is set to just a couple of minutes. This is really annoying when you want to watch your miners' output over let's say 1-2 hours because I have quite a complicated pw that I need to type over and over again.
Just as a suggestion: would it be possible to 1) change the auto-logoff time to maybe 1 hour or something like that and 2) add the function that after typing username and password you can just hit return to login (instead of having to click on "login"; not sure if this is complicated to realise...)?

That shouldnt be happening, its a little more complicated on the back end; we post an HTTPS cookie into your machine with our domain and your sha256 hash of your cookie, and try to use it after the session expires - it has a dynamic expiry time due to have an app pool, so best thing is to 1) ensure your new pass actually works by logging off many and logging on, 2) open more than one window and see if you do not need to log in twice, 3) ensure you are accepting cookies from the pool.
If all this works you should no longer have that log off nuisance.

Looking at https issue now (in the core wallet).. it appears to be isolated to https traffic...

[bible_pay]

1.0.7.5 version seem have problem.

It is the second times occurred , I am re-indexing again.
I worry it will happen again....



Hello all!
I have been following this thread and this project for several weeks now and I am really excited to see the hard work and dedication going into developing all of this. However the last couple of days it seems to me that the only concern you have regarding troubleshooting is with the MN owners, not the miners.
Several people reported the above mentioned error and I also experience it regularly since updating to 1.0.7.5 on different machines, different networks, even different cities across Germany. So the error is definitely not on my side, because also the configurations on these machines differ from each other and each and every one gets this error after a few hours of mining.
However, no one has offered any permanent solution or even explained where this is coming from. I think the only reason so few people have this problem is because judging by the connected peers on my systems most people are still on the working version 1.0.7.1.

So when will this annoying problem be fixed? Another question you never answered was how this new "competitive mining" feature really works. Right now it seems to me that all the update did was giving an even bigger malus to the faster CPUs and DualCPU-systems and more and more degrading mining output. For example my 10 year old Core2 laptop with proclimit 1 is sometimes producing almost as many shares as my Dual-hexacore-Xeon server on proclimit 12, which is absolutely ridiculous.

I understand that your main priority right now are your precious masternodes, but please don't forget about us small-time miners and remember that without the miners your blockchain wouldn't really work either. Comparing the output from before Christmas or even from last week I'm currently at approx. 10%, which barely - if at all - covers my electricity bill.

Thanks for your time and effort and God bless this project!


Edit: For clarification: up to now it seems that the error only occurs with the linux client (Ubuntu 16.04 LTS in my case), the windows wallet doesn't seem to be affected.

Hi Dave,

Its just not true that we only care about precious masternodes.

Here is the way I view the priorities right now just so you know:  I want to ensure we are ready for block 24600, so we can pay our orphans. 

Next, I want to maintain production support levels.  That includes any critical errors with 1075.  And finally, I place a very low priority level personally on any "hash speed discussions".  So maybe thats the point of contention.  We only have enough resources to talk about the prod support and the critical errors and not about peoples mining speed, unless its an inconsistency in the pool that affects everyone.

Of course we have time to talk about how competetive mining works.

But first:
So, Im not aware of a critical bug in 1075, and have not received a log.  Can someone please give us a log so we can see what stopped the node in 1075??

There is no way to even look at a problem without a log.

Can we have a look after we hit the 24600 block at the pool?
I can help investigating and testing etc, no problem.

It feels weird that we only hit 20-25% with nearly 2800 miners and 2390627.92 hps.
Are there really lots of people solo mining, could be but I find it hard to believe if we look at the numbers and interest here on the forum.

I know, even though we have officially 202 blocks per day, Alex pointed out that we have historically Always had 150 due to the nature of the bible hash algorithm.  So, technically, the main pool is getting 33%, but still, its been dropping lately, not increasing.

The pool has a system where it constantly checks the last 11 blocks every block to ensure it didnt reorganize and not pay- so Im sure its not an accounting error.

You can always do the 'exec subsidy height' to see the payees of each block.  Alex also has the pool marked in the BX.

[aikida3k]

You know nothing, you understand nothing.  I have already searched out your heart.  You are here because of karma.  You believe that by helping us, you will get help with your coins yourself.  Now go away.

[immakingacoin]

Invoking the Meditation Deity, Kalachakra
http://kalachakranet.org/teachings/Kalachakra-initiation-Berzin.pdf

http://padmakumara.org/practices/ebooks/TbsPractice_kalachakra.pdf

This Meditation Deity is the Calendar, put simply. But is a larger essence and cycle of time, but put simply, this Deity is the Calendar.

[immakingacoin]

I am Hindu, but I am bringing Christians and Black Hebrew Isrealites to your Coin. I believe this is a good Coin to have in existence.

[bible_pay]

is there some ban / limitation for new ip addresses? i added some machines, but: after biblepayd starts, it takes ages until the blocks are loaded, measured traffic is below 80KB/s; when checking biblepay-cli getmininginfo, the blocks value is increasing very slowly. any similar problems? explanations? what to do? i use ubuntu 16. when i run speedtest-cli, the results are fast enough: download 42mbps, upload 11mbps. any thoughts?

Check machines time zone and time- we enforce network time - it wont sync until set.

[bible_pay]

And currently, I have been sharing your Coin with ISUPK members on Youtube and Twitter. So the Followers of General Yahanna will probably use your Coin, and I assume even make their own Coin soon.

And I will be sharing mine with the Kemetic Community (the New Black Panthers) and the Moorish Science Temple (which is kind of like a Black Shriner's Temple).

Please quit spamming us here; if you are making a coin why are you spending all your time here?

Side note: Its illegal to spam e-mail addresses, dont post them here.

[bible_pay]

Anyone suffering from the 1.0.7.5 HTTPS (reindex) bug, on linux, 1.0.7.6 is out, please compile and let us know if the problem is solved.

(Building windows version now)....

[ogmaro]

Are they still in Ico?

[immakingacoin]

I will contact you guys again after we do our Bitcointalk launch. And I will be getting people to use your coin, just watch over the next week and 2 and month. You will notice a big difference.

[immakingacoin]

Are they still in Ico?

We are in ICO, and we are only doing the ICO on Facebook, it is not for Bitcointalk users. And we will be launching the other coins within the next few days. The first one will be Texas based, and it will be a PoW Cryptonote.

[togoshigekata]

Anyone suffering from the 1.0.7.5 HTTPS (reindex) bug, on linux, 1.0.7.6 is out, please compile and let us know if the problem is solved.
(Building windows version now)....

[dave_bbp]

I need to restart some of my miners once/twice per day (reindex fixes them)
The miners that are failing use HTTPS.

The few miners that are running using http seems to be not affected (I haven't needed to restart them, but they are also slower machines)

@Dave, are you using HTTPS or http?

Interesting, indeed I use HTTPS on all of my miners (seemed like the right thing to do...), so perhaps it's really related to that. As soon as one is crashing again I will return to HTTP and see if it runs stable again.


On another note: since the security update on the pool page (required password change) I have to log on again and again because the auto-logoff is set to just a couple of minutes. This is really annoying when you want to watch your miners' output over let's say 1-2 hours because I have quite a complicated pw that I need to type over and over again.
Just as a suggestion: would it be possible to 1) change the auto-logoff time to maybe 1 hour or something like that and 2) add the function that after typing username and password you can just hit return to login (instead of having to click on "login"; not sure if this is complicated to realise...)?

That shouldnt be happening, its a little more complicated on the back end; we post an HTTPS cookie into your machine with our domain and your sha256 hash of your cookie, and try to use it after the session expires - it has a dynamic expiry time due to have an app pool, so best thing is to 1) ensure your new pass actually works by logging off many and logging on, 2) open more than one window and see if you do not need to log in twice, 3) ensure you are accepting cookies from the pool.
If all this works you should no longer have that log off nuisance.

Looking at https issue now (in the core wallet).. it appears to be isolated to https traffic...

So I tried logging on and off several times, this didn't help. Having logged in I can open another tab and don't need to log in again, so this is working.
Then I checked the cookies my browser saved from pool.biblepay.org and I think I found the mistake: the credentials_password cookie saves a wrong value for my pw (double-checked this by deleting it, logging off and on again, same mistake). The problem seems to be that my pool-pw uses a semicolon ( ; ) in the middle of the word and this seems to create a problem for the cookie, because the cookie-pw stops at the letter before the ";". I will try and change my pw again without diacritical signs and see if that helps.

One of my computers just crashed again, I disabled SSL, let's hope for the best. :-D


Edit:
Oh, you beat me to it by posting the update, I'm gonna give this a try then, let's see how it works out over night.

[haladez]

I know, even though we have officially 202 blocks per day, Alex pointed out that we have historically Always had 150 due to the nature of the bible hash algorithm.  So, technically, the main pool is getting 33%, but still, its been dropping lately, not increasing.

Doesn't that mean the block times have been wrong the entire time?
If I recall correctly, this was pointed out some months ago as well that our block times are around 10 minutes on average instead of 7 minutes like intended.

[616westwarmoth]

Is there a BiblePay YouTube video yet? I would share it.

Just got my sound equipment in.  Will hopefully have a new video out this weekend.  Will keep everyone posted.  Will likely do the easier one (shorter) called "How to Mine BBP on Windows" since there is a Linux glitch atm it seems and the stereotypical Linux user is more advanced.

[Alex873434]

Hey Rob,

Could you check the slack if you're around?

[bible_pay]

BiblePay - 1.0.7.6
Leisure Upgrade for Core Wallet

Part 1:  For Entire network:

- Fix bug in HTTPS Pool communication
- Show a bible verse in pop-up balloon when receiving a transaction


Part 2:  Sanctuaries:

BiblePay - Watchman-On-The-Wall v1.0.0.4
Mandatory Upgrade for Sanctuaries Only

- Prevent bad proposals or triggers from being loaded, keep watchman running

Upgrade instructions:

cd ~/.biblepaycore
rm watchman -R
git clone https://github.com/biblepay/watchman.git
cd watchman
virtualenv venv
venv/bin/pip install -r requirements.txt

To test:
venv/bin/python bin/watchman.py
(Ensure watchman.py returns no errors)



** Note: The core wallet upgrade is primarily to address the SSL/reindex bug.

Please treat the watchman upgrade as a mandatory if you still have more than one pesky trigger (IE type: gobject count
Look for trigger count, see if triggers > 1 - then please apply this patch asap) or if your sanctuary is in the WATCHDOG_EXPIRED state.   Otherwise, if you are both ENABLED and only see one trigger, please upgrade at your convenience, as the update is still needed by all sanctuaries.  **


**Note:  This is the same release as we announced earlier for Linux.**