The current system while not perfect, is self policing. pagalo, ishtosh, sakic, etc must realize they are getting an negative ROI if they submit too many tithes. I'm sure there may be others who think they can over tithe as well, but you can see things have calmed down. This makes me question if a mandatory is really necessary. Aren't mandatories every three months at most? We just had a mandatory... In 1187, what does tithing look like. Will it be thousands of tiny donations (spammy?) clogging up the network raising bandwidth cost for everyone? BiblePay - 1.1.8.7 - Mandatory Upgrade
For entire network before block 102,025
- Fix bug in POG mining algorithm causing too many tithes to enter the pog pool per day - During block heights 100,775-102,024 BiblePay corrects most of the overflow effects as a temporary leisure fix - After block 102,025 (the mandatory deadline cutover height) Biblepay upgrades POG to v2.0; this allows thousands of tithes into the pog pool per day and corrects the algorithm from overflow effects and prevents attacks - Fix POW difficulty value for POBH in getinfo - Make POG leaderboard sort by share % descending - Allow tithe=n (allow any value including 2; 0=off, 1=default, 2-up = minutes between tithing) - Increased PODC vote height to 107,000 (when we vote to retire PODC) https://github.com/biblepay/biblepay/commit/52b3fe81ca2ada664d815f21d090aa7ac12b5448 - Yes, a mandatory is necessary - In POG v2.0 one person cannot over-tithe (the coin-age will be spent quicker) - Tithing wont be spammy, it will be about 3* more frequent as it is now, but this "assumption" of spammy is not correct to begin with, as difficulty will settle in a dynamic fashion - I don't see evidence that BBP has high bandwidth costs due to transactions yet - as a matter of fact I asked for evidence and didnt receive a baseline from any other coin b. If I do receive a baseline, the study is not done until a report shows bytes per messagetype (so that is two steps) |
|
|
|
BiblePay - 1.1.8.7 - Mandatory Upgrade
For entire network before block 102,025
- Fix bug in POG mining algorithm causing too many tithes to enter the pog pool per day - During block heights 100,775-102,024 BiblePay corrects most of the overflow effects as a temporary leisure fix - After block 102,025 (the mandatory deadline cutover height) Biblepay upgrades POG to v2.0; this allows thousands of tithes into the pog pool per day and corrects the algorithm from overflow effects and prevents attacks - Fix POW difficulty value for POBH in getinfo - Make POG leaderboard sort by share % descending - Allow tithe=n (allow any value including 2; 0=off, 1=default, 2-up = minutes between tithing) - Increased PODC vote height to 107,000 (when we vote to retire PODC) https://github.com/biblepay/biblepay/commit/52b3fe81ca2ada664d815f21d090aa7ac12b5448
|
|
|
|
c-cex hot wallet might be on different chain. My withdraws and deposits are not working
Created ticket, thanks. |
|
|
|
ROBERT you wrote here that you setuped limits on your pool for credible accounts and this is what?  This withdrawal amount exceeds BiblePay's hot wallet limit; please withdraw less than 1001 bbp.ROBERT? The message is accurate. |
|
|
|
We will have a fix out within 8 hours.
Phase 1 will correct the problem as people upgrade within 48 hours.
Phase 2 will correct the problem in a more graceful way permanently (after 7 days).
Could you please be a bit more transparent. What are the phases? Please read the notification on the release. |
|
|
|
Only stability gives success.
There were too many changes, and testnet is for testing,
I wrote after testing how many bugs is in POG.
Unfortunately, Rob just laughed.
Interesting you would say there are bugs but not share specific. Most people here are not programmers. But I didnt laugh, Im all ears for the improvements to POBH that he said he secretly has. I replied with and maintain that there are no holes in POG. I already know of the attack vector that people claimed was an attack vector for pog (people saving up coin-age and hitting us while diff is low) but that is not an attack as we have that patched in develop its just never being used in Prod (yet), so skipping that known one, I maintain there are no holes in POG. On POBH, I said Im all ears for you to share your secret. But I can say up front, Im sure we already know what you will say, and you know when I reply it will ruin your theory (thats why hes holding it back). There is nothing new being brought to the table with POBH- the other coins have gone through it. Im not embarassed that we limit POBH to distinct users - it is still a noble effort to do that. Its the difference between rewarding rich kids with 20 servers and rewarding distinct houses in BBP. Im thinking the distinct houses are Christian economy members. POG is still good - we're just going through a week of embarassment here (I am at least). In my opinion this is not very good. Again donations to orphans Tithes given 1315 Reward 1184.26594402 We will have a fix out within 8 hours. Phase 1 will correct the problem as people upgrade within 48 hours. Phase 2 will correct the problem in a more graceful way permanently (after 7 days). |
|
|
|
Only stability gives success.
There were too many changes, and testnet is for testing,
I wrote after testing how many bugs is in POG.
Unfortunately, Rob just laughed.
Interesting you would say there are bugs but not share specific. Most people here are not programmers. But I didnt laugh, Im all ears for the improvements to POBH that he said he secretly has. I replied with and maintain that there are no holes in POG. I already know of the attack vector that people claimed was an attack vector for pog (people saving up coin-age and hitting us while diff is low) but that is not an attack as we have that patched in develop its just never being used in Prod (yet), so skipping that known one, I maintain there are no holes in POG. On POBH, I said Im all ears for you to share your secret. But I can say up front, Im sure we already know what you will say, and you know when I reply it will ruin your theory (thats why hes holding it back). There is nothing new being brought to the table with POBH- the other coins have gone through it. Im not embarassed that we limit POBH to distinct users - it is still a noble effort to do that. Its the difference between rewarding rich kids with 20 servers and rewarding distinct houses in BBP. Im thinking the distinct houses are Christian economy members. POG is still good - we're just going through a week of embarassment here (I am at least). |
|
|
|
Just be a while on other stuff. I updated the windows wallet but no block source available. What should be the correct conf file? PODC is removed? Could someone repost the upgrade post link? Thanks.
it seems the first message is tooooo old and need to be updated.
You need only wallet.dat and peers file, without peers it can take a few hours. Ensure clock is correct within 2 secs, ensure timezone is correct. We have 5 live DNS seeds, but if you still didnt sync, addnode 45.76.63.197 |
|
|
|
Only stability gives success.
There were too many changes, and testnet is for testing,
I wrote after testing how many bugs is in POG.
Unfortunately, Rob just laughed.
Interesting you would say there are bugs but not share specific. Most people here are not programmers. Rob pushes people away from himself. One by one, he will be alone with the promises of 3-5 new users daily. Most of us have a lot of bbp. It is not pleasant to see what is happening. Youll have to wait for POG to be re-released and given a true chance before being proven wrong. I'll bet you 250,000 bbp that we have more than 500 concurrent POG users by June 18th this year. Are you willing to escrow 250K? TheSnat can hold the money. I think if we grow from 200~ to 500 by mid year that would be a testament of growth for POG, and should be enough to lift the price. |
|
|
|
Only stability gives success.
There were too many changes, and testnet is for testing,
I wrote after testing how many bugs is in POG.
Unfortunately, Rob just laughed.
Interesting you would say there are bugs but not share specific. Most people here are not programmers. Rob pushes people away from him. One by one, he will be alone with the promises of 3-5 new users daily. Most of us have a lot of bbp. It is not pleasant to see what is happening. I don't get why we use 'new users' as a metric. Folks new to BBP, would presumably be drawn in by the new feature (POG) and its promise (profit). Profit oriented people are usually quick to sell, especially in this market condition. There aren't so many profitable coins, so I think people are looking more for stability and the hope of a coin's survival to better days. It seems to me that the vast majority of crypto is destined to fail. Let's not be one of them. I'm all for innovation, but uncorking it near the bottom I don't understand. Gift cards are nice, but how are they encouraging hodling of BBP? Either I buy the BBP and convert to the gift card, or I'm already hodling and will just convert. How does profit-mindedness contribute to hodling? Will quick profits be helpful to the coin long term? The main point is I don't see 300 active users on PODC making BiblePay a household name. We gave it a long shot. While I do see the possibility that POG offers, a pool of 10,000 users could make us a household name. |
|
|
|
Please be patient everyone. In the mean time, don't be greedy and tithe too much at once, or everyone will receive negative ROI that day.
I'll make it top priority for us to fix the algorithm so: 10,000 people can be in the pool, diff does not cycle catastrophically, and the enforcement is bulletproof for someone with a lot of coin age waiting to abuse the system when low diff occurs.
Why are you blaming people when system is broken? This is not blaming. This comment was not meant for everyone, just those who took advantage of the low difficulty. I meant it just as a warning not as a judgement. |
|
|
|
Yes, basically it does mean that it is now unprofitable to tithe the rest of the day, as the pool took in 110K or so and pays out 92K.
The confusing thing we have going on right now is some of our reports are based on 40 blocks, some 205. This is confusing.
If tithing is no longer profitable today, why am I still tithing? Shouldn't the code see that it is unprofitable and not tithe? I thought that was one of the selling points of PoG? Was your statement with the assumption the tithe=1 only? If we try to tithe every 10 minutes, would this claim still apply? I'm not going to sit here and answer all of the smart alleck questions if we have a bug thats needs addressed in the code. Let's finish our next leisure upgrade first this week, then I'll answer all your questions. Yes, the wallet is designed to be profitable when the algorithm is within its bounds, and yes it enforces it. Hi, it was not meant to be a smart alleck question. Anyway, I posted this as an issue here: https://github.com/biblepay/biblepay/issues/71Thanks, I apologize for jumping to conclusions. I'll explain more as the weekend ends. I'll make it top priority for us to fix the algorithm so: 10,000 people can be in the pool, diff does not cycle catastrophically, and the enforcement is bulletproof for someone with a lot of coin age waiting to abuse the system when low diff occurs. (We already thought of these 3 things when testing, but the parameters in the code are not correct). The 205 wide report can most likely be done at the same time (to provide a 2nd indicator how much was tithed per day, but honestly when the first issue is fixed this will become irrelevant as the cycles will never break bounds). |
|
|
|
How is this possible?
I tithed total -785.7002298 and got rewards 696.2677964
The technical reason its currently possible: We have 5 cycles per day of 40 blocks. In each cycle, when difficulty drops to 0, an inrush of people tithe and cause diff to be outside its bounds (IE Too high). This happened every cycle yesterday. I'm working on a fix as highest priority. This is actually a small fix but will require a mandatory. We can make this algorithm work perfectly. Please be patient everyone. In the mean time, don't be greedy and tithe too much at once, or everyone will receive negative ROI that day. |
|
|
|
Rob your script deleted accounts on pool again???it looks yes (my miners nick was changed) thx for it,amazing my nick disappeared on pogpool I dont have any scripts running - all I ever had was one to delete people in India who upvoted each others letters. You already emailed me about this, why double the post and drag everyone through it? You know Ive replied to 100% of my emails, for everyone, about the pool, every time. On this one youll have to wait til I have time to reply. We need to fix POG first. |
|
|
|
Yes, basically it does mean that it is now unprofitable to tithe the rest of the day, as the pool took in 110K or so and pays out 92K.
The confusing thing we have going on right now is some of our reports are based on 40 blocks, some 205. This is confusing.
If tithing is no longer profitable today, why am I still tithing? Shouldn't the code see that it is unprofitable and not tithe? I thought that was one of the selling points of PoG? Was your statement with the assumption the tithe=1 only? If we try to tithe every 10 minutes, would this claim still apply? Good job ROB, now you can tithe every 10min with 1-2 sato:)) Thanks, was this post designed to help our community? I'm not judging POG until it's in prod for 60 days after the next upgrade. |
|
|
|
Yes, basically it does mean that it is now unprofitable to tithe the rest of the day, as the pool took in 110K or so and pays out 92K.
The confusing thing we have going on right now is some of our reports are based on 40 blocks, some 205. This is confusing.
If tithing is no longer profitable today, why am I still tithing? Shouldn't the code see that it is unprofitable and not tithe? I thought that was one of the selling points of PoG? Was your statement with the assumption the tithe=1 only? If we try to tithe every 10 minutes, would this claim still apply? I'm not going to sit here and answer all of the smart alleck questions if we have a bug thats needs addressed in the code. Let's finish our next leisure upgrade first this week, then I'll answer all your questions. Yes, the wallet is designed to be profitable when the algorithm is within its bounds, and yes it enforces it. |
|
|
|
Maybe Australia or some island have bandwidth usage issue. But it is unlimited where I live. I don't push more than 500gb a month either way for total monthly usage. And that includes Netflix streaming.. I don't really see the bandwidth argument as a stumbling block.
Just to be clear... even in the USA there are a lot of internet providers going to tiered data limits. Mediacom for example started doing it probably 5 or so years ago. Their entry level cable plan only allows for 400GB of data each month. Just a year or 2 back that was as little as 250GB. My in-laws that only use it to stream netflix and pay bills used to come close to tapping out their 250GB limits. So, if BBP wallet is responsible for 45GB+ each month, it is no laughing matter. That kind of bandwidth could go to running "beermoney" applications and earn more with less power depending on the app and month. I'm hoping that the data isn't really that much but rather factoring in their contribution to DC. Rosetta tends to have work units that require more disk space than a lot of projects. So, if people are contributing to that project currently, they should feel a pinch on the data traffic. I'm curious to see the results people find. I really don't mind providing an advanced report showing bytecount per messagetype outbound, but what we need first is a good accurate 24 hour baseline showing our outbound byte count vs. Dash preferably, or another Dash based wallet. Its futile to write all that code if someone doesn't claim with accuracy/proof that we use more bandwidth than normal. |
|
|
|
Also, someone on Discord asked if you set it for tithe=1 does the wallet check every 4 hours to attempt a tithe, or will it tithe ASAP if more than 4 hours have elapsed? For example, let's say I tithed 3 hours ago... but the PoG difficulty is so high, I won't be able to tithe until 3 hours later (6 total hours elapse). When the 6th hour is approached, will the auto tithe fire off a donation?
Looking at the code, it only does the getdifficulty and applicability check once every 4 hours (with auto on). So yes, they would miss out on tithing if the diff drops while their miner is not checking. So in their case they should probably do the tithe=10. |
|
|
|
Can you explain how PoG relates with PoBH?
So, in biblepay.conf, all you really need are three lines?
tithe=1
gen=1
nickname=orphan_supporter
gen=1 is making hashes... does this use up all the cpu threads? also, you don't need cpid for this?
So gen=1 is just interpreted once by biblepay, it tells the miner to turn on (btw, gen=1 is the default with POG) we list it in case someone has gen=0 in their file (as that would turn the miner Off). Anyway, genproclimit is what controls the threadcount. With POG, it only uses thread 0. By default with POG the genproclimit=1. So it only uses 1% or so of the cpu by default. You can increase it if you want and you will do more pow solo mining (for the reaper reward). The CPID sign check is now disabled, so you can run the POBH miner without a cpid now. |
|
|
|
Can you explain how PoG relates with PoBH?
So, in biblepay.conf, all you really need are three lines?
tithe=1
gen=1
nickname=orphan_supporter
gen=1 is making hashes... does this use up all the cpu threads? also, you don't need cpid for this?
Nickname is mandatory or optional? Optional. |
|
|
|
|
Show Posts
