I want to find the root of the problem, if there is an inconsistency, I want us to at least quantify it. I do not want high pool fees for the long term. I believe with auto-payment, the fees will drop back to normal within a month. I dont think this is enough info however, to hone in on the problem. We are going to need a whole thread, Im going to need a volunteer to be an arbiter, and I believe there is enough info out there between the miner, the code, and the wise to figure out where the bottleneck is- whether its in a nonce limit, or a wait state, or a solo-mine vs Pool. Alex has done a lot of testing on his VMs and found he has the ability to scale his rewards appropriately, so I think its possible to break this problem down into sub problems. First create a thread here: http://forum.biblepay.org/index.php?board=6.0Then if we could have a volunteer work with Pkman to break the problem down into quantifiable pieces, and ask him for more info, such as his getmininginfo start, duration, then getmininginfo stop, make columns in the sheet for that and figure out where the problem is. This is me volunteering for the second time. There is something very clearly wrong when my strongest processor is getting less than a third of the hash of my weakest so I have a vested interest to find out why. Ok, go for it, you are a moderator here: http://forum.biblepay.org/index.php?board=6.0Please collect all the info you can and see if Alex can help you with any technical questions, and once you have a hypothesis as to what is wrong, send me some higher level info (or send to Alex first) and Ill work with him in Slack on it and try to get to the bottom of it. |
|
|
|
Dear Rob Can you tell me? Why? Our mining project to get low coins? Maybe i am error for test , the info below 1 PC = 24 core = share 48
1 PC = 24 core (tested 1 of 1vCPU = total 24 vPC ) = share 91
1 PC = 24 core (tested 1 of 4vCPU = total 6 vPC) = share 62
Same PC ~Same Ram ~Same network
Big Share= get more coin or not? I called top of 3 big dog to tested . This is correct detail data. Please fix the problem. If you feel this is good at BBP future that you keep doing that. Big pool fee is ok , I support. But low coin of day that is not good.  I hope BBP will being just，fair and open. I don't want any misunderstanding . Please explain. Love BBP Love this coin. Thanks Rob ,Have are nice day From Hong Kong ...Man I want to find the root of the problem, if there is an inconsistency, I want us to at least quantify it. I do not want high pool fees for the long term. I believe with auto-payment, the fees will drop back to normal within a month. I dont think this is enough info however, to hone in on the problem. We are going to need a whole thread, Im going to need a volunteer to be an arbiter, and I believe there is enough info out there between the miner, the code, and the wise to figure out where the bottleneck is- whether its in a nonce limit, or a wait state, or a solo-mine vs Pool. Alex has done a lot of testing on his VMs and found he has the ability to scale his rewards appropriately, so I think its possible to break this problem down into sub problems. First create a thread here: http://forum.biblepay.org/index.php?board=6.0Then if we could have a volunteer work with Pkman to break the problem down into quantifiable pieces, and ask him for more info, such as his getmininginfo start, duration, then getmininginfo stop, make columns in the sheet for that and figure out where the problem is. |
|
|
|
Dear Rob Can you tell me? Why? Our mining project to get low coins? Maybe i am error for test , the info below 1 PC = 24 core = share 48
1 PC = 24 core (tested 1 of 1vCPU = total 24 vPC ) = share 91
1 PC = 24 core (tested 1 of 4vCPU = total 6 vPC) = share 62
Same PC ~Same Ram ~Same network
Big Share= get more coin or not? I called top of 3 big dog to tested . This is correct detail data. Please fix the problem. If you feel this is good at BBP future that you keep doing that. Big pool fee is ok , I support. But low coin of day that is not good. I hope BBP will being just，fair and open. I don't want any misunderstanding . Please explain. Love BBP Love this coin. Thanks Rob ,Have are nice day From Hong Kong ...Man This problem is since... relese. Earlier in old topic Rob said he wont change it because he want to support small minners with low core cpus. But I think, You already know from this topic that multiwallet is your 24 core cpu best friend  especially since Rob takeoff limitation of solutions per ip from pool? I had finished the test about the gain of BBP. Testing equipment : Machine A & B are Dual L5630 CPU (2.4Ghz 8Core16Thread), all setting are same except cpu core setting Machine C : AMD Ryzen Pro 1700X (3.4Ghz 8Core16Thread) ----------------- machine A: each VM with 2 core (around 410HSP) , Total 8 VM in 9hours BBP Gain = 196.2544 BBP per hour = 21.80604444 machine B : each VM with 1 core(around 200HSP) , Total 16VM in 9hours BBP Gain = 486.0898 BBP per hour = 54.00997778 Machine C : All CPU resource used by one BBP process(8500HSP), Each Day = 309.3764 BBP per hour = 12.89068333 This is undoubtedly a disadvantage for high-performance machines in current BBP calculate method. High cost of high-performance machines but the return rate is lower than the low performance machine. For example, John pay $ 1000 a day for machine rent to get 5000 BBP Peter pay $200 a day and gets the same 5000 BBP I do not think anyone wants to be John.... The huge question for machine A, the fast ryzen, is it running competetive mining? The elephant in the room here is since we have the anti-GPU feature, the low-nonce limiter, the first thing a fast machine will be doing is hashing faster per second, using up all its nonces. Please check to see if the fast testbed is running competetivemining=true? |
|
|
|
It's 86 masternodes. About 205 blocks are split between them. 205/86 = 2.38. I assume that one MN will receive 2 rewards per day. But for example B9dk5UzLjDu42V2TkrL1pMkFDLcFrPzzR4 it received one reward yesterday. That's all right? Can this be related to the watchman version (MN ver.103)? Well thank you.
Over time they smooth out to 2.5 per day assuming a static count. The system has an algorithm where a node will maintain a certain position in the payment queue once established. |
|
|
|
A minor issue at pool.biblepay.org ... the sort feature doesn't work in the "My Leaderboard" section of the Home page. I've tried it with several browsers (IE 11, Chrome 63.0, Firefox 56). Would be nice to have it working, no rush.
Yeah, that sort is 95% programmed but requires something to be done for every section. Lets look at it soon, I think we will tackle this notify feature next. |
|
|
|
Yesterday I received the first "auto-payout" from the pool. The feature itself works, but how is it configured? My available balance for payout was something like 700 BBP (not counting the immature of course), but the auto-payout transmitted a very odd 39.7342? Since then nothing more has happened. What is the threshold for the auto-withdrawal? Also I would really appreciate if the auto-withdrawal would transmit only whole BBP and not fractions of it (up to now I managed to keep my wallet absolutely clean of every fractional values....). This is not only an aesthetical request but also eases things up for tax-purposes later (German bureaucracy...). Thanks.  On another note: the inital positive effect of the pool adjustments seems to have dried out a little bit, still <25% blocks... They daily auto payment is still not finished, primarily because Im letting the pool regain its health. Right now, around 9AM CST, we send out a multileg transaction to everyone we owe more than 10 BBP to, we currently send 5% of the Mature balance. This is going to be tweaked in the future to about 50% of the mature balance. Your mining credits are not whole numbers, and no feature will be implemented for whole numbers. 10-4 on the pool percentage, its hovering around 30% of the actual blocks per day. |
|
|
|
as i mentioned few days ago, add email notification for stopped miners Ill try to look into this tomorrow. |
|
|
|
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.
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. iDeflationRate = .015; // 1.5% per month, compounded monthly (19.5% per year with compounding) Our deflationary effect is compounded as we reduce the block reward 12 times per year, at a rate of 1.5% per reduction instance, giving a total effect of 19.5% annually (since the deflation percent is multipled by smaller and smaller gross numbers over time), in contrast to a one time annual deduction of only 18% (IE 12*1.5). The subsidy level emitted per month however, in the rows above, offer a glimpse of the static emission per block, but not of the declining curve of the total money supply. |
|
|
|
rob, it looks like you hit the problem, number of solved blocks are increasing... huraaay Yeah, I will be very happy if we get back to half solved by the pool, and lose this deficit and enable auto pay, and on top of that our diff will probably double, which makes us more attractive to the world. That begs to question, what else can we do to make it better. Ill take a look at what I can do to make the core more unique for solo miners also. Ill add 10 more receiving addresses now and see if we can get this thing purring overnight. |
|
|
|
199 blocks away from superblock!
Sounds good! Hey we are close to overtaking Doge in price. .00000057 compared to .00000068. Go Orphans! Orphan Memes are better than Doges. |
|
|
|
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.  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? Yeah, the distinct nonce rule is hitting the little ones pretty hard, let me take a look at if we can enforce a distinct nonce after one share per miner, that would at least keep the list full and allow people to know they are hashing. |
|
|
|
|
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.
|
|
|
|
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.  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. |
|
|
|
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. Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. 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. |
|
|
|
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. |
|
|
|
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. Only "problem" remaining is: why is the (only existing) pool hitting less than 20% of the blocks. 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? 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. |
|
|
|
BiblePay - 1.0.7.6
Leisure Upgrade for Core WalletPart 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.gitcd 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.** |
|
|
|
|
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)....
|
|
|
|
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. |
|
|
|
|
Show Posts
