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

[vahtis]

Is there way to mute notifications?
Running wallet 24/7 and you get notification sound for every transaction for every PODC update and PrivateSend denominiation.

[1715274824]

1715274824

[1715274824]

1715274824

[1715274824]

1715274824

[vahtis]

Any idea what is wrong with my setup
Work done in BOINC says 2346
Miner statistics are empty https://pool.purepool.org/main/miner/BM6rTtdn5ysfSK9Q1vTZrzoBpCFqP5khP2/
getmininginfo returns

14:31:30

getmininginfo


14:31:30

{
  "blocks": 37344,
  "currentblocksize": 6250,
  "currentblocktx": 1,
  "difficulty_podc": 767.320809860965,
  "difficulty_pow": 5704.160161074824,
  "difficulty": 767.320809860965,
  "errors": "",
  "genproclimit": 1,
  "networkhashps": 762553.5798064935,
  "hashps": 118.8864529848553,
  "minerstarttime": "03-27-2018 09:45:22",
  "hashcounter": 21300461,
  "pooledtx": 1,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "Unable to sign CPID; ",
  "poolinfo2": "Submitting Solution 03-29-2018 11:28:50; ",
  "poolinfo3": "",
  "miningpulse": 50622,
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "poolmining_use_ssl": true
}

Please also provide your 'exec getboincinfo'

18:41:24

exec getboincinfo


18:41:26

{
  "Command": "getboincinfo",
  "CPID": "252455be172ea3aa289d1237fce91818",
  "Address": "BM6rTtdn5ysfSK9Q1vTZrzoBpCFqP5khP2",
  "CPIDS": "252455be172ea3aa289d1237fce91818;",
  "CPID-Age (hours)": 422871,
  "NextSuperblockHeight": 37515,
  "NextSuperblockBudget": 1179301,
  "252455be172ea3aa289d1237fce91818_ADDRESS": "BM6rTtdn5ysfSK9Q1vTZrzoBpCFqP5khP2",
  "252455be172ea3aa289d1237fce91818_RAC": 211,
  "252455be172ea3aa289d1237fce91818_TEAM": 15044,
  "252455be172ea3aa289d1237fce91818_TaskWeight": 0,
  "252455be172ea3aa289d1237fce91818_UTXOWeight": 0,
  "Total_RAC": 211,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 0,
  "Total Budget (One Day)": 0,
  "Total Budget (One Week)": 5968341,
  "Superblock Count (One Week)": 8,
  "Superblock Hit Count (One Week)": 6,
  "Superblock List": "37105,36695,36490,36285,36080,35875",
  "Last Superblock Height": 37310,
  "Last Superblock Budget": 1179301,
  "Last Superblock Payment": -1,
  "Magnitude (One-Day)": 0,
  "Magnitude (One-Week)": 0
}

Alright, I see that you don't have any TaskWeight or UTXOWeight. As far as I know, you need that in order to validly mine.

Please check if you followed all these instructions:
https://www.biblepay-central.org/en/mining-how-to/

Sadly, I don't have time to help you further right now, but maybe someone else can take it over from here

Time solved this

[znjrols5]

Hi rob,

You're doing a great work here, thanks for all the work you've done.

However, since I see that there are mentions of pool not working correctly, I have unfortunately had some problems with pool.biblepay.org. When I point my machines to pool.biblepay.org, I see them more in 'missing miners' section than in 'my miners' (active ones). I have tried once again today after you said that you fixed something on it, and it still misbehaves. From the client part, I've seen no errors, but still for some reason, for bigger part of time my worker is in 'missing miners' part, thus results to missing rewards from a lot of mined blocks. I have just now pointed one worker again to mine on pool.biblepay.org, and I'll update with more info on current behavior.

Thanks, lets get this baby back up - Im cleaning it up now.  Please give me an example minername that is showing up in missing section, that should not be, and I will trace it.

So, I'm currently mining on workerid=rols-4. It looks like the missing miners sections is working as it should, and that the problem is that the pool is not 'accepting' my hashpower, i.e. it is just sometimes showing my worker in 'leaderboard' section.

Note 1. I was also mining on pool.biblepay.org a couple of days ago, and I was checking the pool several times a day. Half the time I saw my miners in leaderboard, half the time they were missing. And when I opened block distribution I saw that I missed my share for several blocks, thou I'm pretty sure all those miners were working all the time.

Note 2. I confirm I have no problems while mining on purepool with same miners.

Note 3. Don't know if it means something, but I saw these messages at one point recently:
"poolinfo1": "BNvQ5Txs1riZvuKA5W7prbtwx7PuSXXBwL; ",
"poolinfo2": "RM_04-02-2018 21:59:49; Submitting Solution 04-02-2018 21:59:51; Submitting Solution 04-02-2018 21:59:58; ",
At the moment of writing this post, I also saw a few 'submitting solution', but my worker is still not showing up on my leaderboard.

Note 4. I used pool.biblepay.org a month and two months ago, did not see this behavior, everything was working as it should.

I see the problem, you must have had a lot of machines last week when the pool emitted the high machine report and it manually banned tadao32, nbzz, tadao, brother, kappo, vladoru and Rolz.    Ok I removed the ban for everyone, but the pool still has a rule where it starts discarding packets for miners who have more than 10 machines pointed at the pool simultaneously.

Sorry for the hassle.

Why the limit on the number of machines?

[joelles]

Yeah Rob why limit machines? It's only incentive for other to mine solo or other pool

[Fishnandy]

Only just learning about biblepay - looks great. I have a mining rig and I'm interested in peoples experience with CPU mining. If you have an i3 CPU, and are mining other coins with the GPU's, how is the stability with biblepay?

Hi yes you can mine bbp with your cpu while  mining other coins with your gpu been doing it with all my Riggs for a few weeks now

[thesnat21]

This is not meant as a dig, just a report out of what I am actually seeing.

Status update:
Post-20bbp/rac stake.

So far I have declined,  I was up to almost 2k bbp/day earnings prior to the change.
Day 1:  earnings dropped to 1127
Day 2:  earnings dropped to 979

Regarding the earlier assumption : 30$ in biblepay = enough to stake a decent home machine.
Earlier in this thread it was mentioned a "decent gaming machine" could produce 6k RAC

The math on this...   6000 * 20 = 120000 bbp required to fully stake.
Assuming BBP is 0.003usd/per  this is 120,000*0.003  = $360

This is a significant difference from the 30$(roughly 10x) figure mentioned earlier. 30$ will stake you for a 500 RAC machine which would be a very low end.. (my old i3 from 6+years ago is doing 3x this)


As a result, since I had only earned 25k-ish the last 2 months mining. I'm now at 20% stake under the new rules.

What I decided is ok, fine I will lower my RAC since it doesn't benefit me any to continue how I was mining.
This seems to only have reduced my payment, not my UXTOWeight.

So because I'm a small fish. and cannot buy my way into the coin I have to either do 5x the work to keep up with my smaller payout, or wait out the RAC drop until I can be fully staked while accepting smaller payouts than normal for my work. (not sure how much time this would take)

I see others excited about their increased payouts.. I will be completely honest, this is frustrating for someone in my position, or any potential newbies trying to join the coin.


I'd be curious to see a list of all the payout changes, and did this changeover control the "botnets" that were being used as the reason for this change?  Perhaps that would help a little i guess. 

[znjrols5]

I'm pretty sure that my WCGRAC is wrong in biblepay network... Yesterday at some point, 'exec totalrac' showed around 12k RAC, and later that day around 9k RAC. Through 'exec getboincinfo' I saw that my RAH RAC was the same (it should have been), and my WCG RAC jumped. After that it dropped, but I am constantly working on WCG (since it was added to biblepay), so it should only go up monotonically the first two weeks (since RAC is two week average, afaik). I didn't experience these problems with RAH, before WCG was implemented in biblepay network.
So, at the moment of writing, my WCG RAC reported through getboincinfo is 2972, but my BOINC shows around 7.5k. I know it should have some latency, show a bit lower than 7.5k, but my WCG RAC on BOINC was around 3k two days ago. My cpid is 307c54df37dd7a158ef9fd7dfe1a1815

[SVK Noko]

Only just learning about biblepay - looks great. I have a mining rig and I'm interested in peoples experience with CPU mining. If you have an i3 CPU, and are mining other coins with the GPU's, how is the stability with biblepay?

Hi, I'm mining BBP with CPU and simultainously by GPU other coins via MinerGate and via NiceHash SW and everything works fine, no interference between.

[bible_pay]

Biblepay Core version 1.1.1.7 (64-bit)

A fatal error occurred. Biblepay Core can no longer safely continue and will quit.

2018-04-03 02:47:57 ProcessNewBlock : ACCEPTED
2018-04-03 02:47:57 socket select error The operation completed successfully.  (0)
2018-04-03 02:47:57 UpdateTip: new best=0000008c1acb3a1b82cfa097a1df8dbf140417facb54bdd7c7362425a6627452  height=4747  log2_work=34.391322  tx=6163  date=2017-08-26 03:17:09 progress=0.042876  cache=0.7MiB(2887tx)
2018-04-03 02:47:57 ProcessNewBlock : ACCEPTED
2018-04-03 02:47:57

************************
EXCEPTION: St8bad_cast      
std::bad_cast      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2018-04-03 02:47:57

************************
EXCEPTION: St8bad_cast      
std::bad_cast      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

A friend of mine told me this happens if you setgenerate true to a number > 2, and heat mine without a CPID.

Please let us know if you are heat mining without a CPID and what your genproclimit is, and what OS flavor you have.

Once I have more info I will fix the problem permanently.

[jaapgvk]

This is not meant as a dig, just a report out of what I am actually seeing.

Status update:
Post-20bbp/rac stake.

So far I have declined,  I was up to almost 2k bbp/day earnings prior to the change.
Day 1:  earnings dropped to 1127
Day 2:  earnings dropped to 979

Regarding the earlier assumption : 30$ in biblepay = enough to stake a decent home machine.
Earlier in this thread it was mentioned a "decent gaming machine" could produce 6k RAC

The math on this...   6000 * 20 = 120000 bbp required to fully stake.
Assuming BBP is 0.003usd/per  this is 120,000*0.003  = $360

This is a significant difference from the 30$(roughly 10x) figure mentioned earlier. 30$ will stake you for a 500 RAC machine which would be a very low end.. (my old i3 from 6+years ago is doing 3x this)


As a result, since I had only earned 25k-ish the last 2 months mining. I'm now at 20% stake under the new rules.

What I decided is ok, fine I will lower my RAC since it doesn't benefit me any to continue how I was mining.
This seems to only have reduced my payment, not my UXTOWeight.

So because I'm a small fish. and cannot buy my way into the coin I have to either do 5x the work to keep up with my smaller payout, or wait out the RAC drop until I can be fully staked while accepting smaller payouts than normal for my work. (not sure how much time this would take)

I see others excited about their increased payouts.. I will be completely honest, this is frustrating for someone in my position, or any potential newbies trying to join the coin.

I'd be curious to see a list of all the payout changes, and did this changeover control the "botnets" that were being used as the reason for this change?  Perhaps that would help a little i guess. 

I was the one that gave the 30 dollar figure. I was looking at my own computers (which are AMD Phenom II's and A8's), and they give me about 2000 RAC. It's indeed 120 dollars. Higher than I thought. Don't know how I got the 30 dollar figure. In an ideal world, I would like 3 things:
1. No botnets
2. Fair entrance for new users.
3. Making it expensive for power-users to participate.

The first one is covered now. Maybe it's a bit too expensive right now for new users with a lot of computing-power right now, but that doesn't mean this can't change in the future. The third one certainly is true for new power-users, but existing power-users that believe in Biblepay (I consider myself a moderately big user) that have been in the game for a long time have an advantage because they have more BBP. They have that much BBP because they didn't sell, because they have a long-term view for the coin. I think that whales aren't a bad thing per se if they believe in the project.

The thing I really like about Biblepay in it's current form, is that it is actually transparent who are the mining whales. I believe this is fairly unique. You really know what you are investing in.

This isn't really in reply to you thesnat21, I'm just rambling a bit at this point.

Just two more things:

1. The 20BBP/RAC was democratically decided. Maybe some users didn't realize the power of their vote, but I think now most have realized that voting matters. As far as I know, the staking requirements can be adjusted every mandatory, no nothing is stopping us to have another vote in two months and take in all the information and opinions we have gathered in that time, and come to another consensus (hopefully with a lot more people involved). Maybe we should have a public vote, maybe a sanctuary vote. There is a lot to consider here.

2. Heat mining doesn't really require staking. You need a functioning CPID for every wallet that you are mining with. But I think that nothing is stopping people from sharing the wallet.dat between multiple wallets. And also, you could use one PC, set one cpu-thread to mine Rosetta and set the rest to heat-mine. That way you don't really have to stake and can still earn BBP via heat-mining.
That maybe isn't really how Biblepay is intended, but nothing is stopping users from walking that path.

[bible_pay]

rob, last payout was not as you wrote, that if somebody stake 20% then he get 20%
check this: https://www.biblepay-central.org/en/podc/user/1987688/
he had 20% and got 40%
i still think it is as i wrote, that user will have 20% shares, and block reward will be divided by sum of all shares, so payout for one share will not be 20% but more (depends on how many users staking 100%)

Yes, I also received only a little payout and the explorer says I staked 50k, although I had (already since yesterday) almost 500k staked and several podcupdates going through.
However I think this is correct, since the payout for the next superblock is decided at the moment of the last one, i. e. approx. 24h before. Tomorrow's payout should be as expected.

Dave-

The easy way to see this is to look @ the pool superblock view report, and highlight your row yellow, scroll to the top and memorize where the utxo/utxo weight columns are, scroll back down and check your UTXO/UTXOWeight values - see if your magnitude reflects your utxo stake level.

I checked over 10 last night and they look on the money....

Hmm... I don't think this is correct, because right now it shows a utxoweight of 0 with a utxoamount of 1.7k for me, which is absolutely ridiculous and I have no idea where these numbers come from. My controller wallet holds 500k (and some change) and I manually added "utxooverride=500000" (wallet version 1.1.1.7).
I tried "exec podcupdate true" several times, but my reported utxoweight (in getboincinfo) changes constantly (sometimes it's correct, sometimes it's the old 50001, often it seems to be a completely random number). Something is seriously wrong there.

My only explanation would be that I also have this wallet running on my ARMs for pool mining. Since lichtsucher hasn't updated the linux ppa yet, they still run on 1.1.1.3. Could this be the problem? Otherwise I wouldn't know what else I could do...
Missed out on 2 payments already and apparently gave my coins away to the "big guys", it's a shame. :/

Hi Dave,

Oh OK now Im starting to understand the problem a little deeper.  First of all since you have the utxooverride set in the primary controller wallet I think those are going out.  Just type 'exec utxoreport cpid' and you will see the pattern.  I dont believe there is a problem with gyrating amounts (as 2,000 people are using it now) I believe the gyrating amounts are being sent at intervals between your controller, your other wallets...  The utxoreport will reveal that.

As far as running the latest, yes - if your miners are not running the latest they should technically be OK- but are probably trying to send podc updates using the old default of 50,000.  So best advice there is to set 'utxoamount=-1' on the OLD mining wallets pre 1.1.1.6, or 'utxooverride=-1' on the new mining wallet (actualy just put both in the file), that should prevent it from being sent.  Notice - you cant use '=0' because zero means it will try to send 50K.....

Once you interpret the utxoreport then lets go from there - it should reveal that your mining wallets are sending in a small stake, preventing you from being paid.  Your Pool row is probably @ utxo below 5% meaning it drops to zero.

[bible_pay]

Only just learning about biblepay - looks great. I have a mining rig and I'm interested in peoples experience with CPU mining. If you have an i3 CPU, and are mining other coins with the GPU's, how is the stability with biblepay?

If you set up Rosetta@Home first, then PODC mine, its great.
Heat (POW) mining is a little complicated.
Stability is 100% great as long as you have a CPID set up.

[skyline9394]

Biblepay Core version 1.1.1.7 (64-bit)

A fatal error occurred. Biblepay Core can no longer safely continue and will quit.

2018-04-03 02:47:57 ProcessNewBlock : ACCEPTED
2018-04-03 02:47:57 socket select error The operation completed successfully.  (0)
2018-04-03 02:47:57 UpdateTip: new best=0000008c1acb3a1b82cfa097a1df8dbf140417facb54bdd7c7362425a6627452  height=4747  log2_work=34.391322  tx=6163  date=2017-08-26 03:17:09 progress=0.042876  cache=0.7MiB(2887tx)
2018-04-03 02:47:57 ProcessNewBlock : ACCEPTED
2018-04-03 02:47:57

************************
EXCEPTION: St8bad_cast      
std::bad_cast      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2018-04-03 02:47:57

************************
EXCEPTION: St8bad_cast      
std::bad_cast      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

A friend of mine told me this happens if you setgenerate true to a number > 2, and heat mine without a CPID.

Please let us know if you are heat mining without a CPID and what your genproclimit is, and what OS flavor you have.

Once I have more info I will fix the problem permanently.

im not mining i download the wallte and try to sycn it that it and get this error on 32bit 64bit and other computer

[bible_pay]

Yeah Rob why limit machines? It's only incentive for other to mine solo or other pool

Because only one distinct CPID with payments and magnitude can actually solve a block, therefore rewarding one miner a disproportionate share would be unfair for everyone else.  If anyone could always solve a block it would be fair to let the floodgates swing wide open, but think about what is happening in this scenario:

User 1 has 100 machines - And pulls 90% of the block reward
User 2-11 have 1 machine each - and pull 1% of block reward each

Now in reality over 100 blocks, user 1 is only allowed to solve up to 13 of those blocks Max (because of the distinction rules), so he pulled in 9% of the reward yet we paid him 90%?  LOL, not a good idea....

The CPID rules were put in to make it easy to solo mine, so the pool has to have new rules to make it fair.

I might go in and actually track the shares that "count" by each miner (IE let them throw whatever power they have at it) but that requires a more elaborate share system, one that verifies each packet is actually going toward real work in the pool.  This would look something like this:  If big dog A has 100 machines, and he recently solved a block with his CPID, his shares dont count for 5 more blocks after (so none are rewarded to his miners).  Then I suppose we could open up the floodgates wide if we had that rule in place...  Licht should also work on this rule, because the little miners are being hosed if not.

[thesnat21]

I was the one that gave the 30 dollar figure. I was looking at my own computers (which are AMD Phenom II's and A8's), and they give me about 2000 RAC. It's indeed 120 dollars. Higher than I thought. Don't know how I got the 30 dollar figure. In an ideal world, I would like 3 things:
1. No botnets
2. Fair entrance for new users.
3. Making it expensive for power-users to participate.

The first one is covered now. Maybe it's a bit too expensive right now for new users with a lot of computing-power right now, but that doesn't mean this can't change in the future. The third one certainly is true for new power-users, but existing power-users that believe in Biblepay (I consider myself a moderately big user) that have been in the game for a long time have an advantage because they have more BBP. They have that much BBP because they didn't sell, because they have a long-term view for the coin. I think that whales aren't a bad thing per se if they believe in the project.

The thing I really like about Biblepay in it's current form, is that it is actually transparent who are the mining whales. I believe this is fairly unique. You really know what you are investing in.

This isn't really in reply to you thesnat21, I'm just rambling a bit at this point.

Just two more things:

1. The 20BBP/RAC was democratically decided. Maybe some users didn't realize the power of their vote, but I think now most have realized that voting matters. As far as I know, the staking requirements can be adjusted every mandatory, no nothing is stopping us to have another vote in two months and take in all the information and opinions we have gathered in that time, and come to another consensus (hopefully with a lot more people involved). Maybe we should have a public vote, maybe a sanctuary vote. There is a lot to consider here.

2. Heat mining doesn't really require staking. You need a functioning CPID for every wallet that you are mining with. But I think that nothing is stopping people from sharing the wallet.dat between multiple wallets. And also, you could use one PC, set one cpu-thread to mine Rosetta and set the rest to heat-mine. That way you don't really have to stake and can still earn BBP via heat-mining.
That maybe isn't really how Biblepay is intended, but nothing is stopping users from walking that path.

For the record I have been mining/holding all my BBP since day 1,  missing out on a PODC payment and being slow to realize the switch over affected me a bit, but I don't think it would have been a huge change to my figures above.. (maybe 2-5kbbp)


I agree the goal set was met, and I welcome a re-vote farther down the line after some real-world examples.  Things don't always work as planned and its hard to predict the exact outcome of a change like this.

I don't expect change today,  just throwing out my thoughts for when it comes back around

As for the additional points,
#1.  People like myself that were not paying close attention to the forum could have missed the call to vote.   This just speaks to a need for a more central communications hub for news.   It is easy to lose sight of things in a thread like this, even if it is on multiple pages.  When I started I didn't read from page 1, and I doubt anyone else would.

#2. It would be helpful to outline the process to do this.   Especially for new folks joining if they try to start with PODC only it will be very frustrating.  It could streamline the process for people to start if this is more clearly documented, or people could easily be referred to it.

[bible_pay]

Biblepay Core version 1.1.1.7 (64-bit)

A fatal error occurred. Biblepay Core can no longer safely continue and will quit.

2018-04-03 02:47:57 ProcessNewBlock : ACCEPTED
2018-04-03 02:47:57 socket select error The operation completed successfully.  (0)
2018-04-03 02:47:57 UpdateTip: new best=0000008c1acb3a1b82cfa097a1df8dbf140417facb54bdd7c7362425a6627452  height=4747  log2_work=34.391322  tx=6163  date=2017-08-26 03:17:09 progress=0.042876  cache=0.7MiB(2887tx)
2018-04-03 02:47:57 ProcessNewBlock : ACCEPTED
2018-04-03 02:47:57

************************
EXCEPTION: St8bad_cast      
std::bad_cast      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2018-04-03 02:47:57

************************
EXCEPTION: St8bad_cast      
std::bad_cast      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

A friend of mine told me this happens if you setgenerate true to a number > 2, and heat mine without a CPID.

Please let us know if you are heat mining without a CPID and what your genproclimit is, and what OS flavor you have.

Once I have more info I will fix the problem permanently.

im not mining i download the wallte and try to sycn it that it and get this error on 32bit 64bit and other computer

Try downloading it and saving it to the drive first, then go into advanced and unblock it, install it as administrator, dont run it yet, then:

Open explorer navigate to
%appdata%\biblepaycore

Delete All contents including debug.log
Leave that window open

Now Run biblepay as administrator

Now Verify the debug.log has the most recent timestamp.

See if it does not crash.

[bible_pay]

I was the one that gave the 30 dollar figure. I was looking at my own computers (which are AMD Phenom II's and A8's), and they give me about 2000 RAC. It's indeed 120 dollars. Higher than I thought. Don't know how I got the 30 dollar figure. In an ideal world, I would like 3 things:
1. No botnets
2. Fair entrance for new users.
3. Making it expensive for power-users to participate.

The first one is covered now. Maybe it's a bit too expensive right now for new users with a lot of computing-power right now, but that doesn't mean this can't change in the future. The third one certainly is true for new power-users, but existing power-users that believe in Biblepay (I consider myself a moderately big user) that have been in the game for a long time have an advantage because they have more BBP. They have that much BBP because they didn't sell, because they have a long-term view for the coin. I think that whales aren't a bad thing per se if they believe in the project.

The thing I really like about Biblepay in it's current form, is that it is actually transparent who are the mining whales. I believe this is fairly unique. You really know what you are investing in.

This isn't really in reply to you thesnat21, I'm just rambling a bit at this point.

Just two more things:

1. The 20BBP/RAC was democratically decided. Maybe some users didn't realize the power of their vote, but I think now most have realized that voting matters. As far as I know, the staking requirements can be adjusted every mandatory, no nothing is stopping us to have another vote in two months and take in all the information and opinions we have gathered in that time, and come to another consensus (hopefully with a lot more people involved). Maybe we should have a public vote, maybe a sanctuary vote. There is a lot to consider here.

2. Heat mining doesn't really require staking. You need a functioning CPID for every wallet that you are mining with. But I think that nothing is stopping people from sharing the wallet.dat between multiple wallets. And also, you could use one PC, set one cpu-thread to mine Rosetta and set the rest to heat-mine. That way you don't really have to stake and can still earn BBP via heat-mining.
That maybe isn't really how Biblepay is intended, but nothing is stopping users from walking that path.

For the record I have been mining/holding all my BBP since day 1,  missing out on a PODC payment and being slow to realize the switch over affected me a bit, but I don't think it would have been a huge change to my figures above.. (maybe 2-5kbbp)


I agree the goal set was met, and I welcome a re-vote farther down the line after some real-world examples.  Things don't always work as planned and its hard to predict the exact outcome of a change like this.

I don't expect change today,  just throwing out my thoughts for when it comes back around

As for the additional points,
#1.  People like myself that were not paying close attention to the forum could have missed the call to vote.   This just speaks to a need for a more central communications hub for news.   It is easy to lose sight of things in a thread like this, even if it is on multiple pages.  When I started I didn't read from page 1, and I doubt anyone else would.

#2. It would be helpful to outline the process to do this.   Especially for new folks joining if they try to start with PODC only it will be very frustrating.  It could streamline the process for people to start if this is more clearly documented, or people could easily be referred to it.

Excellent points, thanks.  Maybe Togo, Light, and I should get together and see what it takes to make an XML feed of news items, then we could put a news ticker on biblepay-central and in the pool.biblepay.org. 

But it would be a lot nicer for us if we had it honor Togos tweets, and Light and I just work on putting the "widget" on the web sites .

[bible_pay]

I'm pretty sure that my WCGRAC is wrong in biblepay network... Yesterday at some point, 'exec totalrac' showed around 12k RAC, and later that day around 9k RAC. Through 'exec getboincinfo' I saw that my RAH RAC was the same (it should have been), and my WCG RAC jumped. After that it dropped, but I am constantly working on WCG (since it was added to biblepay), so it should only go up monotonically the first two weeks (since RAC is two week average, afaik). I didn't experience these problems with RAH, before WCG was implemented in biblepay network.
So, at the moment of writing, my WCG RAC reported through getboincinfo is 2972, but my BOINC shows around 7.5k. I know it should have some latency, show a bit lower than 7.5k, but my WCG RAC on BOINC was around 3k two days ago. My cpid is 307c54df37dd7a158ef9fd7dfe1a1815

So since we are integrated a little closer with RAH, I have the core wallet showing you the "current live" RAH RAC when you type exec getboincinfo using their XML call (just for cosmetic use for the user - the Sanc actually gets the RAH RAC from the nightly back-end files to allow them to come to consensus easier, thats why your RAH rac on getboincinfo is more current than the superblock view report), but anyway, WCG is a little different- when they merged with IBM, they removed some of the boinc XML calls - so we cant get the WCG RAC the same way, so we actually use the nightly WCG dump files for their RAC.  Their RAC is exported to our network once per night at 00:00:00 UTC.  So it pretty much stays static for 24 hours at a time.  What I surmise is someone dumped the rac twice yesterday at WCG but normally that doesnt happen so you probably picked up two views of it, which I believe will be rare over long term.

[bible_pay]

rob, last payout was not as you wrote, that if somebody stake 20% then he get 20%
check this: https://www.biblepay-central.org/en/podc/user/1987688/
he had 20% and got 40%
i still think it is as i wrote, that user will have 20% shares, and block reward will be divided by sum of all shares, so payout for one share will not be 20% but more (depends on how many users staking 100%)

Yes, I also received only a little payout and the explorer says I staked 50k, although I had (already since yesterday) almost 500k staked and several podcupdates going through.
However I think this is correct, since the payout for the next superblock is decided at the moment of the last one, i. e. approx. 24h before. Tomorrow's payout should be as expected.

Dave-

The easy way to see this is to look @ the pool superblock view report, and highlight your row yellow, scroll to the top and memorize where the utxo/utxo weight columns are, scroll back down and check your UTXO/UTXOWeight values - see if your magnitude reflects your utxo stake level.

I checked over 10 last night and they look on the money....

Hmm... I don't think this is correct, because right now it shows a utxoweight of 0 with a utxoamount of 1.7k for me, which is absolutely ridiculous and I have no idea where these numbers come from. My controller wallet holds 500k (and some change) and I manually added "utxooverride=500000" (wallet version 1.1.1.7).
I tried "exec podcupdate true" several times, but my reported utxoweight (in getboincinfo) changes constantly (sometimes it's correct, sometimes it's the old 50001, often it seems to be a completely random number). Something is seriously wrong there.

My only explanation would be that I also have this wallet running on my ARMs for pool mining. Since lichtsucher hasn't updated the linux ppa yet, they still run on 1.1.1.3. Could this be the problem? Otherwise I wouldn't know what else I could do...
Missed out on 2 payments already and apparently gave my coins away to the "big guys", it's a shame. :/

I got same problem here(wallet version 1.1.1.7), I don't know why the utxoweight is mismatch with my setting utxooverride=YYYYY in config.

For example:
I set utxooverride=100000 in config file, but utxoweight show 1234 while not a vaule of 100000 , so I need manual to update (exec podcupdate true) , then the result is normal after that.
Unfortunately, when the podc automatically update again, the utxoweight will mismatch again, this is a fault loop.

I think that this problem is caused by too frequent automatic updates, can it be changed to every 12 hours or per day?

Do you have just one controller wallet or do you also have multiple heat miners like Dave?  Try setting utxooverride=-1 on all wallets other than the controller wallet first.  Let me know if that works and also if you still need to control the podcupdate interval (I assume if podc updates drop to controller only, 4 times per day is OK still).

[bible_pay]

Is there way to mute notifications?
Running wallet 24/7 and you get notification sound for every transaction for every PODC update and PrivateSend denominiation.

Which OS is this, and do you want the taskbar notifications stopped or just the sound muted but leave taskbar notifications?