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

hvdb

newbie

Activity: 17

Merit: 0

Quote from: zer01112 on January 05, 2018, 01:55:31 PM

Quote from: nomad1307 on January 05, 2018, 01:35:42 PM

Quote from: dave_bbp on January 05, 2018, 10:50:55 AM

Quote from: bible_pay on January 05, 2018, 09:58:11 AM

Changes to the Pool to help investigate the percentage of blocks Solved by the Pool miners:

I've been investigating the distinct solved blocks by the pool over 24 hours and see that the pools percent dropped to 17% from approx. 45% two weeks ago, despite having an increase in hashpower and an increase in distinct miner count.

Looking at the mining template that is given to every miner, I came to the conclusion that one possibility is everyone together is trying to solve the same block (since the pool only has one address, and our distinct transaction count in the block is relatively low). I was thinking maybe everyone is doing the same work without realizing it, and that means as we increase the load on the pool, the problem actually gets worse (as diff increases, more miners do exactly the same work).

So to investigate this I analyzed the top 1000 solutions in the last 15 minutes and sure enough, about 15% of the solutions appear to be exactly the same.

So in light of this I am adding two new features to the pool to attempt to "potentially" measure and or solve this problem:

#1: We now require unique solutions for every miner. So any miner who sends the same solution as another miner, the early bird gets the share, the later solution gets marked as SOLUTION_STALE and then the core asks the pool for a new piece of work. (This will probably cause the big dogs in the pool to lose some shares, relatively speaking compared to small dogs, but we'll see).

#2: Since I want to eliminate the possibility of a duplicated block template across the pool, I have requested the pool to have 7 receiving addresses, starting now. Now, the pool will check its receive address list whenever doing block checking. It will also issue a random receiving address in the block template, thereby creating a more unique template per miner. This is now in prod.

Let us monitor the pool for the next 24 hours and see if we have an uptick in pool based solutions.

That sounds like a very possible cause. Right now I'm seeing quite the effect on the shares: overall I think shares dropped a little bit, but the more significant change is that my small miners (genproclimit=1) have completely disappeared from the list (despite still mining and showing hashps>200 in "getmininginfo"). So it seems that the slow machines currently drop out completely from time to time because they don't hit legit shares fast enough? Let's see how it all works out in a couple of hours or tomorrow. Wink

I am having the same problem

Same here...

Look at the work list the small miners are there but looking at the leaderboard, they are gone...
Also shares is indeed a (lot) lower, but if we hit more blocks it should in the end be the same right?

zer01112

newbie

Activity: 16

Merit: 0

Quote from: nomad1307 on January 05, 2018, 01:35:42 PM

Quote from: dave_bbp on January 05, 2018, 10:50:55 AM

Quote from: bible_pay on January 05, 2018, 09:58:11 AM

Changes to the Pool to help investigate the percentage of blocks Solved by the Pool miners:

I've been investigating the distinct solved blocks by the pool over 24 hours and see that the pools percent dropped to 17% from approx. 45% two weeks ago, despite having an increase in hashpower and an increase in distinct miner count.

Looking at the mining template that is given to every miner, I came to the conclusion that one possibility is everyone together is trying to solve the same block (since the pool only has one address, and our distinct transaction count in the block is relatively low). I was thinking maybe everyone is doing the same work without realizing it, and that means as we increase the load on the pool, the problem actually gets worse (as diff increases, more miners do exactly the same work).

So to investigate this I analyzed the top 1000 solutions in the last 15 minutes and sure enough, about 15% of the solutions appear to be exactly the same.

So in light of this I am adding two new features to the pool to attempt to "potentially" measure and or solve this problem:

#1: We now require unique solutions for every miner. So any miner who sends the same solution as another miner, the early bird gets the share, the later solution gets marked as SOLUTION_STALE and then the core asks the pool for a new piece of work. (This will probably cause the big dogs in the pool to lose some shares, relatively speaking compared to small dogs, but we'll see).

#2: Since I want to eliminate the possibility of a duplicated block template across the pool, I have requested the pool to have 7 receiving addresses, starting now. Now, the pool will check its receive address list whenever doing block checking. It will also issue a random receiving address in the block template, thereby creating a more unique template per miner. This is now in prod.

Let us monitor the pool for the next 24 hours and see if we have an uptick in pool based solutions.

That sounds like a very possible cause. Right now I'm seeing quite the effect on the shares: overall I think shares dropped a little bit, but the more significant change is that my small miners (genproclimit=1) have completely disappeared from the list (despite still mining and showing hashps>200 in "getmininginfo"). So it seems that the slow machines currently drop out completely from time to time because they don't hit legit shares fast enough? Let's see how it all works out in a couple of hours or tomorrow. Wink

I am having the same problem

Same here...

nomad1307

newbie

Activity: 7

Merit: 0

Quote from: dave_bbp on January 05, 2018, 10:50:55 AM

Quote from: bible_pay on January 05, 2018, 09:58:11 AM

Changes to the Pool to help investigate the percentage of blocks Solved by the Pool miners:

I've been investigating the distinct solved blocks by the pool over 24 hours and see that the pools percent dropped to 17% from approx. 45% two weeks ago, despite having an increase in hashpower and an increase in distinct miner count.

Looking at the mining template that is given to every miner, I came to the conclusion that one possibility is everyone together is trying to solve the same block (since the pool only has one address, and our distinct transaction count in the block is relatively low). I was thinking maybe everyone is doing the same work without realizing it, and that means as we increase the load on the pool, the problem actually gets worse (as diff increases, more miners do exactly the same work).

So to investigate this I analyzed the top 1000 solutions in the last 15 minutes and sure enough, about 15% of the solutions appear to be exactly the same.

So in light of this I am adding two new features to the pool to attempt to "potentially" measure and or solve this problem:

#1: We now require unique solutions for every miner. So any miner who sends the same solution as another miner, the early bird gets the share, the later solution gets marked as SOLUTION_STALE and then the core asks the pool for a new piece of work. (This will probably cause the big dogs in the pool to lose some shares, relatively speaking compared to small dogs, but we'll see).

#2: Since I want to eliminate the possibility of a duplicated block template across the pool, I have requested the pool to have 7 receiving addresses, starting now. Now, the pool will check its receive address list whenever doing block checking. It will also issue a random receiving address in the block template, thereby creating a more unique template per miner. This is now in prod.

Let us monitor the pool for the next 24 hours and see if we have an uptick in pool based solutions.

That sounds like a very possible cause. Right now I'm seeing quite the effect on the shares: overall I think shares dropped a little bit, but the more significant change is that my small miners (genproclimit=1) have completely disappeared from the list (despite still mining and showing hashps>200 in "getmininginfo"). So it seems that the slow machines currently drop out completely from time to time because they don't hit legit shares fast enough? Let's see how it all works out in a couple of hours or tomorrow. Wink

I am having the same problem

616westwarmoth

full member

Activity: 406

Merit: 101

Quote from: togoshigekata on January 01, 2018, 07:50:54 PM

Quote from: bible_pay on January 01, 2018, 09:33:49 AM

I have a side project for someone who might want to track our Deflationary feature and make a monitoring department out of it:

If someone wants to grab the code and take a look at GetBlockSubsidy, you will see a function in there that decreases our emission by 1.5% per month or 19.5% per year.

It would be nice to post here the next block we decrease our subsidy, then we can make a wiki page out of it to refer to in the future.

I think even though this sounds simple, this will be a large component of the cornerstone of success here at biblepay.

Then once per month we can all look forward to the deflationary block number to hit, and realize the subsidy is going down by 1.5% and therefore everyone gets a "raise" theoretically.

Quote from: bible_pay on January 01, 2018, 11:04:02 AM

Just as a very crude start, we need to make a wiki page for this soon, but for a reference as to exactly when our block numbers kick over for our next monthly deflation target:

Block   AccumulatedDepreciationLevel   Subsidy
06150   .0150               14775
12300   .0300              14550
18450    .0450              14325
24600    .0600               14100
30750    .0750               13875

So what this means is at block 24600, the same block as our superblock, our monthly deflation measure kicks in and lowers the subsidy from ~14325 to ~14100.

Reposting to see if anyone is interested in programming BiblePay's deflation

Sorry to bring this back to the top, but my understanding was the deflationary 1.5% was compounding, which the main.ccp confirms.

Code:

iDeflationRate = .015; // 1.5% per month, compounded monthly (19.5% per year with compounding)

dave_bbp

jr. member

Activity: 405

Merit: 3

Quote from: bible_pay on January 05, 2018, 09:58:11 AM

Changes to the Pool to help investigate the percentage of blocks Solved by the Pool miners:

I've been investigating the distinct solved blocks by the pool over 24 hours and see that the pools percent dropped to 17% from approx. 45% two weeks ago, despite having an increase in hashpower and an increase in distinct miner count.

Looking at the mining template that is given to every miner, I came to the conclusion that one possibility is everyone together is trying to solve the same block (since the pool only has one address, and our distinct transaction count in the block is relatively low). I was thinking maybe everyone is doing the same work without realizing it, and that means as we increase the load on the pool, the problem actually gets worse (as diff increases, more miners do exactly the same work).

So to investigate this I analyzed the top 1000 solutions in the last 15 minutes and sure enough, about 15% of the solutions appear to be exactly the same.

So in light of this I am adding two new features to the pool to attempt to "potentially" measure and or solve this problem:

#1: We now require unique solutions for every miner. So any miner who sends the same solution as another miner, the early bird gets the share, the later solution gets marked as SOLUTION_STALE and then the core asks the pool for a new piece of work. (This will probably cause the big dogs in the pool to lose some shares, relatively speaking compared to small dogs, but we'll see).

#2: Since I want to eliminate the possibility of a duplicated block template across the pool, I have requested the pool to have 7 receiving addresses, starting now. Now, the pool will check its receive address list whenever doing block checking. It will also issue a random receiving address in the block template, thereby creating a more unique template per miner. This is now in prod.

Let us monitor the pool for the next 24 hours and see if we have an uptick in pool based solutions.

That sounds like a very possible cause. Right now I'm seeing quite the effect on the shares: overall I think shares dropped a little bit, but the more significant change is that my small miners (genproclimit=1) have completely disappeared from the list (despite still mining and showing hashps>200 in "getmininginfo"). So it seems that the slow machines currently drop out completely from time to time because they don't hit legit shares fast enough? Let's see how it all works out in a couple of hours or tomorrow. Wink

togoshigekata

full member

Activity: 1260

Merit: 115

I guess I spoke too soon, now Im getting 502 error, sigh, but I was on and did see sell and buy orders going through for BiblePay

seasonw

hero member

Activity: 714

Merit: 500

Quote from: ?? on ??

I believe CoinsMarkets exchange is back online!

https://coinsmarkets.com/trade-BTC-BBP.htm

Not really, I can view the page but still have difficulty to login...

I believe the DDOS issue haven't solved yet.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Changes to the Pool to help investigate the percentage of blocks Solved by the Pool miners:

I've been investigating the distinct solved blocks by the pool over 24 hours and see that the pools percent dropped to 17% from approx. 45% two weeks ago, despite having an increase in hashpower and an increase in distinct miner count.

Looking at the mining template that is given to every miner, I came to the conclusion that one possibility is everyone together is trying to solve the same block (since the pool only has one address, and our distinct transaction count in the block is relatively low). I was thinking maybe everyone is doing the same work without realizing it, and that means as we increase the load on the pool, the problem actually gets worse (as diff increases, more miners do exactly the same work).

So to investigate this I analyzed the top 1000 solutions in the last 15 minutes and sure enough, about 15% of the solutions appear to be exactly the same.

So in light of this I am adding two new features to the pool to attempt to "potentially" measure and or solve this problem:

#1: We now require unique solutions for every miner. So any miner who sends the same solution as another miner, the early bird gets the share, the later solution gets marked as SOLUTION_STALE and then the core asks the pool for a new piece of work. (This will probably cause the big dogs in the pool to lose some shares, relatively speaking compared to small dogs, but we'll see).

#2: Since I want to eliminate the possibility of a duplicated block template across the pool, I have requested the pool to have 7 receiving addresses, starting now. Now, the pool will check its receive address list whenever doing block checking. It will also issue a random receiving address in the block template, thereby creating a more unique template per miner. This is now in prod.

Let us monitor the pool for the next 24 hours and see if we have an uptick in pool based solutions.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: dave_bbp on January 05, 2018, 07:47:13 AM

Quote from: bible_pay on January 05, 2018, 07:28:43 AM

Great to hear, thanks! Let me take a look at this 20% block thing in detail next.

EDIT: Btw, I just realized when you fixed your problem with the removal of the semicolon, the cookie actually contained your password, the one you typed in on the UI, that was not intentional thats a bug, that is supposed to be hashed first. So this will be fixed in the next pool release also so that the password is never stored anywhere.

Haha yes, I was already wondering why the cookie contained my password in "clear type", that did not seem very secure to me. Grin

Yeah, I dont like that, its released now if you want to look at the new cookie.

Still looking into this distinct solved count by the pool.... Honing in on the block template given to every miner at the same time with one pool address in it.

dave_bbp

jr. member

Activity: 405

Merit: 3

Quote from: bible_pay on January 05, 2018, 07:28:43 AM

Great to hear, thanks! Let me take a look at this 20% block thing in detail next.

EDIT: Btw, I just realized when you fixed your problem with the removal of the semicolon, the cookie actually contained your password, the one you typed in on the UI, that was not intentional thats a bug, that is supposed to be hashed first. So this will be fixed in the next pool release also so that the password is never stored anywhere.

Haha yes, I was already wondering why the cookie contained my password in "clear type", that did not seem very secure to me. Grin

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: dave_bbp on January 05, 2018, 02:29:45 AM

Quote from: dave_bbp on January 04, 2018, 05:35:51 PM

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.

Seems to have worked as expected over night. I tried 3 different things:
a) one machine with 1.0.7.5 and SSL enabled --> crashed
b) one machine with 1.0.7.5 and SSL disabled --> worked
c) one machine with 1.0.7.6 and SSL enabled --> worked

So this was definitely and solely an SSL issue, which is fixed in 76; thanks again.

Regarding the pool login: now without the semicolon in my password the pool page works like a charm and does not kick me out every couple of minutes, so problem solved I guess. Wink

Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. Roll Eyes

Great to hear, thanks! Let me take a look at this 20% block thing in detail next.

EDIT: Btw, I just realized when you fixed your problem with the removal of the semicolon, the cookie actually contained your password, the one you typed in on the UI, that was not intentional thats a bug, that is supposed to be hashed first. So this will be fixed in the next pool release also so that the password is never stored anywhere.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: sharpshot on January 05, 2018, 06:51:25 AM

As the 2 exchanges are unusable at the moment, I wonder if it would be worth looking at BiblePay having it's own exchange? All we would need is one of the big coins with low transaction fees to exchange with. I would be happy just to buy and sell BiblePay with Litecoin. As some of these exchanges are a one man operation, with many coins, would it be that difficult to do with just BiblePay and one other coin? If some of the fees went towards the orphans, then it would be even better. I think it could also make it much easier for newbies to buy BiblePay, they could get Litecoin or whatever was chosen from Coinbase and then just use the BiblePay exchange.

I was originally thinking along those lines also for a while, I was considering writing a generic exchange inside the pool, but recently, we have been working with a couple of the bigger exchanges, the info should be available soon.

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: hvdb on January 05, 2018, 03:18:50 AM

Quote from: dave_bbp on January 05, 2018, 02:29:45 AM

Quote from: dave_bbp on January 04, 2018, 05:35:51 PM

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.

Seems to have worked as expected over night. I tried 3 different things:
a) one machine with 1.0.7.5 and SSL enabled --> crashed
b) one machine with 1.0.7.5 and SSL disabled --> worked
c) one machine with 1.0.7.6 and SSL enabled --> worked

So this was definitely and solely an SSL issue, which is fixed in 76; thanks again.

Regarding the pool login: now without the semicolon in my password the pool page works like a charm and does not kick me out every couple of minutes, so problem solved I guess. Wink

Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. Roll Eyes

So I updated to 1.0.7.6 and most miners keeped working.
However some crashed.
I don't see a direct reason why... there is no error or exception.
Any idea?

Code:

2018-01-04 23:02:32 CMasternodePayments::FillBlockPayee -- Masternode payment 693702923735.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:02:32 CMasternodePayments::FillBlockPayee -- Masternode payment 693702923735.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:03:47 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:07 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:26 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:31 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:07:38 msghand thread interrupt
2018-01-04 23:07:38 addcon thread interrupt
2018-01-04 23:07:38 opencon thread interrupt
2018-01-04 23:07:38 net thread interrupt
2018-01-04 23:07:38 scheduler thread interrupt
2018-01-04 23:07:38 mnbcon thread interrupt
2018-01-04 23:07:39 PrepareShutdown: In progress...
2018-01-04 23:07:39 StopNode()
2018-01-04 23:07:51 Verifying mncache.dat format...
2018-01-04 23:07:51 Loaded info from mncache.dat  93ms
2018-01-04 23:07:51      Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 15347
2018-01-04 23:07:51 Writting info to mncache.dat...
2018-01-04 23:07:51 Written info to mncache.dat  690ms
2018-01-04 23:07:51      Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 7, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 15472
2018-01-04 23:07:51 mncache.dat dump finished  784ms
2018-01-04 23:07:51 Verifying mnpayments.dat format...
2018-01-04 23:07:52 Loaded info from mnpayments.dat  484ms
2018-01-04 23:07:52      Votes: 24388, Blocks: 2541
2018-01-04 23:07:52 Writting info to mnpayments.dat...
2018-01-04 23:07:54 Written info to mnpayments.dat  1807ms
2018-01-04 23:07:54      Votes: 25812, Blocks: 2684
2018-01-04 23:07:54 mnpayments.dat dump finished  2293ms
2018-01-04 23:07:54 Verifying governance.dat format...
2018-01-04 23:07:55 Loaded info from governance.dat  1295ms
2018-01-04 23:07:55      Governance Objects: 15 (Proposals: 13, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 69), Votes: 0
2018-01-04 23:07:55 Writting info to governance.dat...
2018-01-04 23:07:56 Written info to governance.dat  773ms
2018-01-04 23:07:56      Governance Objects: 15 (Proposals: 13, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 70), Votes: 691
2018-01-04 23:07:56 governance.dat dump finished  2068ms
2018-01-04 23:07:56 Verifying netfulfilled.dat format...
2018-01-04 23:07:56 Loaded info from netfulfilled.dat  40ms
2018-01-04 23:07:56      Nodes with fulfilled requests: 8
2018-01-04 23:07:56 Writting info to netfulfilled.dat...
2018-01-04 23:07:56 Written info to netfulfilled.dat  0ms
2018-01-04 23:07:56      Nodes with fulfilled requests: 9
2018-01-04 23:07:56 netfulfilled.dat dump finished  40ms
2018-01-04 23:08:17 Shutdown: done

Its possible that 1075 let a bad block in (not a security problem, but marked as bad) and that prevents the tip from being read, possibly, please try deleting chainstate -R and blocks -R on that particular node.

sharpshot

full member

Activity: 250

Merit: 101

As the 2 exchanges are unusable at the moment, I wonder if it would be worth looking at BiblePay having it's own exchange? All we would need is one of the big coins with low transaction fees to exchange with. I would be happy just to buy and sell BiblePay with Litecoin. As some of these exchanges are a one man operation, with many coins, would it be that difficult to do with just BiblePay and one other coin? If some of the fees went towards the orphans, then it would be even better. I think it could also make it much easier for newbies to buy BiblePay, they could get Litecoin or whatever was chosen from Coinbase and then just use the BiblePay exchange.

hvdb

newbie

Activity: 17

Merit: 0

Quote from: dave_bbp on January 05, 2018, 02:29:45 AM

Quote from: dave_bbp on January 04, 2018, 05:35:51 PM

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.

Seems to have worked as expected over night. I tried 3 different things:
a) one machine with 1.0.7.5 and SSL enabled --> crashed
b) one machine with 1.0.7.5 and SSL disabled --> worked
c) one machine with 1.0.7.6 and SSL enabled --> worked

So this was definitely and solely an SSL issue, which is fixed in 76; thanks again.

Regarding the pool login: now without the semicolon in my password the pool page works like a charm and does not kick me out every couple of minutes, so problem solved I guess. Wink

Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. Roll Eyes

So I updated to 1.0.7.6 and most miners keeped working.
However some crashed.
I don't see a direct reason why... there is no error or exception.
Any idea?

Code:

2018-01-04 23:02:32 CMasternodePayments::FillBlockPayee -- Masternode payment 693702923735.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:02:32 CMasternodePayments::FillBlockPayee -- Masternode payment 693702923735.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:03:47 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:07 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:26 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:04:31 CMasternodePayments::FillBlockPayee -- Masternode payment 693702926015.000000 to BNidV9kWAZECM1sEtg7ZiQyYn2ghDY6mN9
2018-01-04 23:07:38 msghand thread interrupt
2018-01-04 23:07:38 addcon thread interrupt
2018-01-04 23:07:38 opencon thread interrupt
2018-01-04 23:07:38 net thread interrupt
2018-01-04 23:07:38 scheduler thread interrupt
2018-01-04 23:07:38 mnbcon thread interrupt
2018-01-04 23:07:39 PrepareShutdown: In progress...
2018-01-04 23:07:39 StopNode()
2018-01-04 23:07:51 Verifying mncache.dat format...
2018-01-04 23:07:51 Loaded info from mncache.dat  93ms
2018-01-04 23:07:51      Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 15347
2018-01-04 23:07:51 Writting info to mncache.dat...
2018-01-04 23:07:51 Written info to mncache.dat  690ms
2018-01-04 23:07:51      Masternodes: 84, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 7, entries in Masternode list we asked for: 0, masternode index size: 84, nDsqCount: 15472
2018-01-04 23:07:51 mncache.dat dump finished  784ms
2018-01-04 23:07:51 Verifying mnpayments.dat format...
2018-01-04 23:07:52 Loaded info from mnpayments.dat  484ms
2018-01-04 23:07:52      Votes: 24388, Blocks: 2541
2018-01-04 23:07:52 Writting info to mnpayments.dat...
2018-01-04 23:07:54 Written info to mnpayments.dat  1807ms
2018-01-04 23:07:54      Votes: 25812, Blocks: 2684
2018-01-04 23:07:54 mnpayments.dat dump finished  2293ms
2018-01-04 23:07:54 Verifying governance.dat format...
2018-01-04 23:07:55 Loaded info from governance.dat  1295ms
2018-01-04 23:07:55      Governance Objects: 15 (Proposals: 13, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 69), Votes: 0
2018-01-04 23:07:55 Writting info to governance.dat...
2018-01-04 23:07:56 Written info to governance.dat  773ms
2018-01-04 23:07:56      Governance Objects: 15 (Proposals: 13, Triggers: 1, Watchdogs: 1/1, Other: 0; Seen: 70), Votes: 691
2018-01-04 23:07:56 governance.dat dump finished  2068ms
2018-01-04 23:07:56 Verifying netfulfilled.dat format...
2018-01-04 23:07:56 Loaded info from netfulfilled.dat  40ms
2018-01-04 23:07:56      Nodes with fulfilled requests: 8
2018-01-04 23:07:56 Writting info to netfulfilled.dat...
2018-01-04 23:07:56 Written info to netfulfilled.dat  0ms
2018-01-04 23:07:56      Nodes with fulfilled requests: 9
2018-01-04 23:07:56 netfulfilled.dat dump finished  40ms
2018-01-04 23:08:17 Shutdown: done

dave_bbp

jr. member

Activity: 405

Merit: 3

Quote from: dave_bbp on January 04, 2018, 05:35:51 PM

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.

Seems to have worked as expected over night. I tried 3 different things:
a) one machine with 1.0.7.5 and SSL enabled --> crashed
b) one machine with 1.0.7.5 and SSL disabled --> worked
c) one machine with 1.0.7.6 and SSL enabled --> worked

So this was definitely and solely an SSL issue, which is fixed in 76; thanks again.

Regarding the pool login: now without the semicolon in my password the pool page works like a charm and does not kick me out every couple of minutes, so problem solved I guess. Wink

Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. Roll Eyes

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

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.**

Alex873434

member

Activity: 98

Merit: 10

Hey Rob,

Could you check the slack if you're around?

616westwarmoth

full member

Activity: 406

Merit: 101

Quote from: immakingacoin on January 04, 2018, 12:44:54 PM

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.

haladez

newbie

Activity: 19

Merit: 0

Quote from: bible_pay on January 04, 2018, 04:53:57 PM

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.

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