|
Hey eh eh, it looks like were back to high performance (in the pool) now.
The stored procs worked, and I think adding them improved the quality of the system & code anyway.
Hopefully we can make it through the next 30 days now, with high load.
I moved the Leaderboard link back to the protected area, in case it was being abused by the outside.
Ill take a look at the account issue next.
|
|
|
|
it's a lost day and lots of troubles after the last update .
2/3 of my workers are running dry and not even show up in account .
Yea, Im working on it, I have a couple new ideas that may or may not work. Im going to convert a core part of the system over to stored procs and try that next (that might let the database server do 3-4 operations at a time, while right now they are one at a time). After that, Ill look into running two instances and splitting the load. Cant say exactly how long, but Im working on it now. Raising the diff on the big dogs didnt help so Ill be putting that back. |
|
|
|
I'm getting this trying to log in to the pool :
Service Unavailable
HTTP Error 503. The service is unavailable.
earlier today it was very slow.
Yea, this morning it was doing fine. I just checked on it and reset it and its up, but its getting pounded. Its receiving over 250 hits per second. It is actually inserting 250 rows per second of work in the work table. One other thing that is surprising, is I see over the last two days, we increased our pool activity by 20% per day and user count by 20% per day. I do have a new server at home for it, but Im on vacation. In the mean time, Im going to check and see if I can gauge how the bigdogs ask for work, possibly if I have a history of a big dog, we can start each of their work units out a little harder. Ill check that out now and that might decrease the hits per server to half. Inblue, Ill have to look at all that you wrote a little later today. |
|
|
|
Plans to setup an Slack or Telegram group?
Also what are the plans on adding Bittrex / Cryptopia / Yobit to the exchange list?
We are going to have a slack group within 30 days, and invite more developers, and create functions like PR, Charity, Orphan communications, etc. Our next mandatory is not released yet, so I would rather see that updated at c-cex before bringing on any new exchanges. However, we have reached out to 3. As far as revolutionary achievements, maybe God will give us that ability. I could see us working on a standardized crypto payment gateway that benefits more wallets than just ours simultaneously - a service that allows instant debit/credit card payments from any currency with enough market depth. I have a lot of info on this already, but I have to dig it up. |
|
|
|
It is good to know pool started to charge fee to cover development and server cost. Does it mean that it is officially released now?  BTW, what does it mean by "Anonymous User Pool Fee"? I thought we have to create pool account in order to mine? Its still not ready for prod, still beta. We have a couple open items in the testnet testing thread for the pool that should make it nicer. The anonymous row is the fee subtracted from the mining credit when the user has 'cloaked' their profile from the public. The fee is still 0 for non-anonymous users. |
|
|
|
If im not mistaken there's 4M new coins every day and by 2018 there will be around 500M more. So it would make sense to have at least 0.1% of all the coins to run a masternode. So maybe something between 500k and 1M coins. This of course is all speculation  On the masternodes, I was thinking they should probably be around $500 or so. Thats about 700,000 bbp. This is just an estimate. Id really like a good 90 day baseline first. As far as charging for the pool, I am thinking about charging 1% for Anonymous users and leaving the pool as Free for non-anonymous. It would help pay for the server and any queries I have to do. It would also allow the code to be modified so when open sourced people can charge fees. Ill take a look at those mining guides that someone posted. EDIT: Good post on the masternode analysis also, regarding 51% attacks, thanks. Wow, 700k seems a lot to me, I have less than 200k now  If there are 100 masternodes, 205 blocks per day, 20k per block, 10% for masternode. Then 205 * 20k * 0.1 / 100 = 4100bbp per day. Correct me if wrong calculation... I never setup a masternode before, but I'd like to setup one for biblepay. 700k still my coin, right? Just need to secure in the masternode wallet? Regarding 700k, we have to ensure it is a high enough amount to cover instantsend transactions. You are basically becoming the insurance to guarantee the amount gets instantly from point A to B without the recipient waiting for the transaction. So it cant be too low, the backing funds must cover expensive transactions. Also, think of this as an entrepreneurial venture where it takes a real investment to get started but promises good earning potential. Yes, your math is correct, we would move 4100bbp from the subsidies that now go to the miners to the masternodes when they go live with the assumption that we had 100. Yes, on the escrow amount, if it was 700k, your coins are sent to an escrow address and held. They can be withdrawn at any time. Once withdrawn, the masternode monthly payment stops coming to your personal wallet address. |
|
|
|
|
Inblue, regarding the pool punchlist, progress has been made:
1. If you don't type your password when you edit the account,
the password for your account will change to blank,
so if you try to login again with your (old) password,
it will be denied and then it turns out you can login just with the username, leaving the password field blank!
-> Unable to reproduce (appears to not be broken). B: When the password is deliberately set to blank,
you may log in with a blank password temporarily - this is by design so I can reset a users password.
NOTE: The users passwords are stored as hashes, so the system does not actually store passwords on disk.
You can test this problem by just changing usertext1 only, and click save. Then logoff and log back in with your standard password.
2.
Block explorer navigation link exists only when you are logged out
-> Fixed, and moved the Orphans to the unprotected area also to expose these links to the world.
3. From the Withdraw page, the Home navigation link leads to the Account page
-> Fixed
All navigation links are visible only from the home page, on all other pages there is only the Home link,
which can be annoying to go through two links every time you want to take a look at something else
-> User can click Back on mouse, not worth fixing yet unless we upgrade entire menu to a database driven flyout menu system
-> Partially fixed though, since now you can click unprotected links from the masthead, maybe we will make those nicer and put more up there in the future.
Switch to Test Net link shows Switch to Main Net only after you click it, later it shows Switch to Test Net again and you can't go back to Main Net unless you refresh the page
-> Fixed
Existence of a horizontal scrollbar on all pages (empty gray content on the right)
-> Fixed
Block distribution history table changes row background color after your highlighted yellow row, instead of not changing it until the next block height
-> Fixed
Kind of a similar thing on the Leaderboard - it was probably intended for the same user to retain the same row color if their workers are next to each other, but that seems useless because:
-> Fixed
Users can have vastly different hash rates so their workers will not be next to each other
-> Leaderboard sorted by hashpersec desc... Cant do much here
It kind of exposes anonymous users when their workers are next to each other because you can conclude that's the same anonymous user, not multiple users
-> This really is hashpersec desc, so this is just a coincidence
Confusing order of navigation links - especially Log off which should be at the end, not somewhere in the middle;
or Leaderboard which is probably a very used link, but it's placement is like it's less important than the Switch to Test Net link.
-> Moved LogOff to last position; Moved leaderboard to unprotected area (allowing clickability sitewide and exposing it to the masses)
General look of the website which people may not find aesthetically pleasing
-> I havent looked into this yet; but could you please give a few of the most important improvement recommendations we could make, being relatively specific in this case?
EDIT: PS, Before UAT testing on the above, be sure to press ctrl-f5 after logging in to pull latest css files.
|
|
|
|
Could you all please provide any feedback if you think the pool has any front end UI problems now. The login,logout works fine, and is Designed to expire your session after 15 mins of inactivity. The rest of it, to me works fine now, and someone mentioned AJAX, but imo, its not even necessary as I think we have some pretty important priorities-like the interface for writing to our orphans, etc. Pool should be behaving better... as of 3 days ago.
Nothing on this list is a priority except probably the first point: - If you don't type your password when you edit the account, the password for your account will change to blank, so if you try to login again with your (old) password, it will be denied and then it turns out you can login just with the username, leaving the password field blank!
- Block explorer navigation link exists only when you are logged out
- From the Withdraw page, the Home navigation link leads to the Account page
- All navigation links are visible only from the home page, on all other pages there is only the Home link, which can be annoying to go through two links every time you want to take a look at something else
- Switch to Test Net link shows Switch to Main Net only after you click it, later it shows Switch to Test Net again and you can't go back to Main Net unless you refresh the page
- Existence of a horizontal scrollbar on all pages (empty gray content on the right)
- Block distribution history table changes row background color after your highlighted yellow row, instead of not changing it until the next block height
- Kind of a similar thing on the Leaderboard - it was probably intended for the same user to retain the same row color if their workers are next to each other, but that seems useless because:
- Users can have vastly different hash rates so their workers will not be next to each other
- It kind of exposes anonymous users when their workers are next to each other because you can conclude that's the same anonymous user, not multiple users
- It breaks table consistency and readability
- Confusing order of navigation links - especially Log off which should be at the end, not somewhere in the middle; or Leaderboard which is probably a very used link, but it's placement is like it's less important than the Switch to Test Net link.
- General look of the website which people may not find aesthetically pleasing
That's all I could find for now, I hope it was helpful. You must have been working on this list for a while, there is no way a human could have done this in 15 mins, lol. Anyway, looks like I have some work to do (on this). Will take care of the hot items. |
|
|
|
Thanks, this is a great start. I added these to the website under Guides. |
|
|
|
The current reward is 20K, it goes down 10% each year.
Currently the reward is split 90% miner, 10% Orphan Fund (charity).
After Sanctuaries come on line (Masternodes, end of year), the split will become 80/10/10 Miner/MN/Charity.
This coin introduces a pretty novel algo and is one of very view that can be considered charitable, plus the community has so far been pretty helpful and is inclusive, so I think its got that going for it. On the downside, you have this giant inflation in the first few months (we'll be close to 1.5B coins at year's end), a Dev who is very helpful but still anon right now, a mining pool run by the dev that has a bit of stability issues with it's interface (but the pool itself is pretty solid) and a fair amount of uncertainty about specifics for the future.
I agree with your assessments and want to say, I am impressed by your assessments and all your posts so far and they seem to be accurate and fair. But I do want to appeal on the klunky problematic UI on the pool. A few days ago, that update fixed the 'problems'. Could you all please provide any feedback if you think the pool has any front end UI problems now. The login,logout works fine, and is Designed to expire your session after 15 mins of inactivity. The rest of it, to me works fine now, and someone mentioned AJAX, but imo, its not even necessary as I think we have some pretty important priorities-like the interface for writing to our orphans, etc. Pool should be behaving better... as of 3 days ago. |
|
|
|
If im not mistaken there's 4M new coins every day and by 2018 there will be around 500M more. So it would make sense to have at least 0.1% of all the coins to run a masternode. So maybe something between 500k and 1M coins. This of course is all speculation On the masternodes, I was thinking they should probably be around $500 or so. Thats about 700,000 bbp. This is just an estimate. Id really like a good 90 day baseline first. As far as charging for the pool, I am thinking about charging 1% for Anonymous users and leaving the pool as Free for non-anonymous. It would help pay for the server and any queries I have to do. It would also allow the code to be modified so when open sourced people can charge fees. Ill take a look at those mining guides that someone posted. EDIT: Good post on the masternode analysis also, regarding 51% attacks, thanks. |
|
|
|
Wheels are rolling again, update: Hello all, 1.0.2.3 for testnet is now available on the website ( www.biblepay.org) inside the Prod download, and as usual, the testnet features are not enabled in prod, but are ready for testing in testnet. Will you all please delete the testnet3 blocks and chainstate folder first? This will make it easier, and more rapid to test what we want to test, as I made the cutover rule in testnet start at block 1. In the new version, we now raise the bar even higher, by integrating our unique txindexlookup in the PoBh algorithm. The txindexlookup supports 3 call types: blockhash, txid, and tx.vout.address. This way, the miner must be a fullnode to actually query these outputs. Each mining loop performs a security hash using PoBh, but also a txindex lookup. Now we have 2 biblehashes for every x11 hash, minimizing the effects of x11. X11 is used for our blockindex lookups for speed. I will start my node now in testnet, and unban anyone I have banned. If you cant get a connection to me, let me know as I may have to unban you again until you upgrade. The only thing not addressed in this update is the networkkhps. I cant determine it yet, we will need to do more testing on this new version to try to calculate it. We can also verify that the late block threshhold has been alleviated, down below 30 mins. Thanks! |
|
|
|
BiblePay doesn't need big exchanges right now. C-CEX is very good old exchange (and it's pretty hard to get listed there). I track the price and trading volume and it looks like these are very stable.
I agree; lets slow down and make a solid coin first. We could still use a volunteer to write a mining guide PDF for the pool and solo mining. Please volunteer here so we dont have anyone do double the work. |
|
|
|
Will the thread limit per worker be lifted in the next mandatory maybe?
Thats just on the web pool side, so we can resolve that without changes to the core. |
|
|
|
I've been mining on the new testnet for a while now. The mining itself seems to go smoothly. I get about 1/3 the hashesps that I got in the previous testnet.
I had a peer earlier, but it now seems to have disappeared, so I don't have any connections. But it seems I'm definitely not the only one mining, since I'm not finding every block.
I've been solo mining on test with 1.0.2.2 for a while now, mined a little over half the blocks. The algo changed a little so that's probably why the hashps is different from live. Network hash reporting seems to be way off (it's saying 172 GH/s), but it probably just hasn't been updated for the algo changes yet. The hash ratio is virtually 1:1 for me if I'm reading this right: "ratio": 1,
"hc1": 416718793,
"bhc2": 416718862,
so that looks like it's working as expected. Would be interesting to see if the block times are more consistent than on live. Manually looking up blocks is kind of a pain, I wonder if I can rig up a simple RPC client to dump the timestamps in a human readable format. --edit-- Actually wasn't too hard to set up BitcoinLib to work with Biblepay. It looks like we're still seeing some of the hour+ stuck blocks now and then, which are probably responsible for driving the average block time up so much higher than the 7 minute target. Minimum time is much better than on live, not seeing any of those instant blocks (weird fluke at block 312 where it actually came in at an earlier timestamp than block 311, I'm guessing a miner with an out of sync clock?). I cut out blocks 0-99 in the statistics because the first blocks were going really fast until the difficulty stabilized. height: 423
max: 4235 (70.58 minutes)
min: -1 (-0.02 minutes)
avg: 617 (10.28 minutes)
height: 100 | hash: 58e0f2cecc38301dfa99e7c52b438
height: 429 | difficulty: 1.52944059 | blocktime: 4.63
height: 430 | difficulty: 1.87050462 | blocktime: 2.32
height: 431 | difficulty: 2.48742754 | blocktime: 3.32
height: 432 | difficulty: 3.65735333 | blocktime: 6.12
height: 433 | difficulty: 4.67876990 | blocktime: 0.70
height: 434 | difficulty: 6.10679065 | blocktime: 38.48
height: 435 | difficulty: 2.54011743 | blocktime: 2.00
height: 436 | difficulty: 2.36355665 | blocktime: 3.45
height: 437 | difficulty: 1.97032561 | blocktime: 7.02
height: 438 | difficulty: 5.01105888 | blocktime: 10.35
height: 439 | difficulty: 3.90234281 | blocktime: 13.33
height: 440 | difficulty: 2.77608888 | blocktime: 10.73
height: 441 | difficulty: 2.41586709 | blocktime: 33.73
height: 442 | difficulty: 1.52078064 | blocktime: 2.20
height: 443 | difficulty: 1.27905615 | blocktime: 1.98
height: 444 | difficulty: 1.23269506 | blocktime: 12.95
height: 445 | difficulty: 2.35090225 | blocktime: 0.77
height: 446 | difficulty: 2.87526230 | blocktime: 17.80
Thanks happy, that analysis is very helpful. I had added in the human readable block timestamp to showblock, and was going through them manually, but of course this is much more detailed and valuable. Its pretty revealing. The good news is we are not far off to achieving the proper diff level , subsidy level and spacing expected without x11. But I see a few adjustments that need made. I agree, on the minimum spacing, we solved that, so it is of little concern and would just pollute the code to enforce any block minimum, as without x11 I believe in prod, there will be many fewer minimum spaced blocks now. Regarding the late block threshhold however, the 4-5 you encountered that took one hour, I see the problem. The good news is, I found the root cause, and its because the switch in testnet didnt actually enter the code that resolves late blocks > 30 mins elapsed! So that is being fixed now, along with the minor diff tweak and gui tweak. The other thing that needed fixed is the subsidy calculation for higher diffs. Without x11, the subsidy drops quicker because the diff will rise with a different curve. The new curve being implemented now for the next version will cure this: /* BiblePay Difficulty Level Chart:
1 19998.2933653649
51 19863.6590388237
101 19730.3798134583
151 19598.4375645471
201 19467.8144693848
251 19338.4930012641
301 19210.4559235953
351 19083.6862841633
401 18958.1674095155
451 18833.8828994796
*/
I think what I would like to do now is make an attempt at raising the bar higher, and integrating our txindex lookup into testnet, then we test these few changes as one, and if all goes well we shoot for a mandatory with all this in at once. I want to minimize mandatories so as not to upset our service providers. Ill work on the txindex feature next and get back to you all. EDIT: I forgot to add, on the x11 ratio you inspected, you are correct, it is now 1:1. I was doing analysis on the viability to make it one x11 to a million biblehashes, but for technical reasons, it has to be just a flat 1:1. Basically, every time the nonce on the block is incremented, the miner must know the x11 hash in order to hash the biblehash, therefore in the new system it really is 1:1. That should be of no concern at all to our goal however, and should work fine for us and allow us to move forward. |
|
|
|
Guys, is there any news about putting biblepay to c-cex? i would like to know if there is a tentative date, because it appears the 15th didn't, so any news dev?
Biblepay is already listed at c-cex for some days: https://c-cex.com/?p=bbp-btcOh good  , the thing is I tough it didn't because there wasn't any link in the ANN, they just put c-cex.com and that's it, thanks for the link then. Dev, I think you should update the OP regarding the c-cex exchanger. Alot of people will just read through the OP but not whole discussion. Exchanger is an important fact to a coin. Fixed, thanks. |
|
|
|
is it a real issue with poolinfo3 that we should care about :
" "poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ",
"poolinfo2": "RM_08-23-2017 04:00:34; RM_08-23-2017 03:47:48; ",
"poolinfo3": "POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; ",
"miningpulse": 42887,
"poolmining": true
"
We can silence the debug info once the pool is ready to go to prod. Right now its still valuable to me occasionally. The format for those messages are: each thread is reported sequentially and semicolon delimited; RM means ready to mine; Guids are miner guids;etc. I plan on leaving the informative ones in and removing the miner guid and pool addresses and things that are not human. |
|
|
|
Hello.
as a Christian i am totally against this!
Bible should not be involved with payments/money, since it doesn't have nothing to do with it. I dont know what you are but i will title you SCAMMER!just because if you where christian you wouldn't do this!
So you're saying it does have something to do with it?  And this coin does Christian deeds like helping children in need, you should read up more about it. Yes, and in addition, we are known for our fruits, you can see we sponsor 74 orphans. Your fruits however look sour (negatives next to your name). |
|
|
|
Just saw this on the leaderboard: http://imgur.com/a/fNhnIanh7nho has an unusual high amount of shares. In the Block Distribution History his payout seems as expected when you look at his total hashpower, so his amount of shares seems to be a bug without consequences for the payout. I'm gonna wait and see what happens when the next block is mined by the pool though, just to make sure... Thanks for that, that helps a lot. Above all, I dont see any hacking activity in the logs around this time, and nothing strange about cang2 at 2 am. Although I do see something that needed fixed in the log based on this and now is fixed. But back to the issue of the high shares. I have an audit table that keeps track of historical work by minerguid and it appears cang1 is the high power server (300khps) and cang2 was temporarily a low power server. Anh was probably expirimenting and pointed the high power server at the low power miner. All I can fabricate is he received a ton of small work based on his proven level, but cang1 was actually solving all of it quickly and asking for harder work. Then he probably put configs back to the original way to see what happens. Then the hashes diminished in the round for cang2. I will keep an eye on this particular situation. The pool does make it incrementally harder for the miner once it gets a feel as to how fast it is. I dont see anything else unusual other than the high rate in which solutions were solved (all the solutions are checked). |
|
|
|
|
Thanks for the analysis guys, Im reading the messages, but have gotten a little behind on vacation out in a remote area with a laptop and a relatively slow connection. Ill be in a better area out this way tomorrow and will analyze your analysis in more depth and hopefully get the testnet ball rolling again.
I have been working on the pool back end, writing some police analysis software, and trying to make the hashps more stable.
I have to head out, will be on tomorrow.
|
|
|
|
|
Show Posts
