How is this possible?
I tithed total -785.7002298 and got rewards 696.2677964
I tithed total -785.7002298 and got rewards 696.2677964
God punished us for being so greedy
Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 228. (Read 243437 times)
February 09, 2019, 05:36:57 AM
God punished us for being so greedy
February 09, 2019, 04:12:49 AM
price of BBP looks horrible 4 satoshi
macko20 we droped to 1.....
why ppl mining this coin then?
macko20 we droped to 1.....
why ppl mining this coin then?
February 09, 2019, 04:06:55 AM
How is this possible?
I tithed total -785.7002298 and got rewards 696.2677964
I tithed total -785.7002298 and got rewards 696.2677964
I have one expression for this in my mind but I can not break forum rules :-)
February 09, 2019, 03:57:08 AM
How is this possible?
I tithed total -785.7002298 and got rewards 696.2677964
I tithed total -785.7002298 and got rewards 696.2677964
February 09, 2019, 03:37:37 AM
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
my nick disappeared on pogpool
February 09, 2019, 02:51:40 AM
For POG is necessary to keep wallet running 24/7? Or?
February 09, 2019, 01:25:33 AM
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.
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/71
As far I can see with current system it is not possible to predict it if it is profitable to tithe at any given time because you cannot see in to future.
February 09, 2019, 01:22:56 AM
Regarding the network data consumption it is still the same as before. Big amount of data more than 1MB per minute. Its 1,5 GB daily, it means 45 GB monthly data consumption (tithe=1, gen=1) per one Wallet. So its not usable for users which have some monthly data limitation from their internet provider.
Wallet shows that I have sent 2 GB in half an hour. No wonder my network seems slow.
PODC, tithe=1 and gen=1
Something is wrong there - I havent sent 1 gig since I booted it last, so first ensure you are completely synced.
Then clear the Tools | Network Monitor tab.
Then watch it for 24 hours and see if its too high and if it matches what gig monitor you are looking at - and verify all this is on port 40,000 if so.
(You might be running other things).
I misunderstood the view. Numbers on the top right are from last restart. I got almost 12 H observation now and it is 667 MB.
February 09, 2019, 01:08:26 AM
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.
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/71
February 08, 2019, 10:45:53 PM
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.
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.
February 08, 2019, 10:44:09 PM
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.
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.
February 08, 2019, 09:38:07 PM
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.
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:))
February 08, 2019, 09:13:27 PM
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.
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?
February 08, 2019, 08:36:43 PM
for the bandwidth it would be interesting to see the usage of clients no longer connected (leave in the list for a while?)
Every time we have a fork or a "delete your datafiles" event that's a lot of data the network needs to absorb and re-transmit.
Every time we have a fork or a "delete your datafiles" event that's a lot of data the network needs to absorb and re-transmit.
February 08, 2019, 07:53:13 PM
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.
I've been trying to figure out how to do an apples-to-apples comparison. The vast majority of coins I'm getting through miner software, not from wallet mining or uploading chunks of blockchain. Usually once a week I start the wallets to update the chains, that's it. BBP is the only thing I have running continuously. And I don't know which traffic is going from POBH, and which from the chain updates.
February 08, 2019, 06:22:08 PM
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.
February 08, 2019, 06:18:57 PM
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.
February 08, 2019, 06:17:50 PM
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. February 08, 2019, 06:15:32 PM
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, 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.
February 08, 2019, 06:12:16 PM
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, 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?
Jump to: