using 1.1.9.6 (2019-02-27 15:39:43 -0600)
I did an exec bankroll of a single 500k BBP just now. It wouldn't let me run another exec bankroll on the change address. I had to send it to a different receiving address first. Then I was able to do an exec bankroll. you're saying it should work, but it doesn't work for me.
can anyone else reproduce my situation?
This happened to me as well, except instead of a second bankroll I was unable to send a podcupdate until sending the coins to myself using coin control. I posted this as a github issue 3 weeks ago. I think more will run into this as they transition away from PoDC to PoG. My workaround is to run two wallets - one for PoDC and one for PoG. I keep enough for 100% stake in PoDC and send the rest to PoG. PODCUpdate: Unable to locate coins not marked as POG bankroll denominations. https://github.com/biblepay/biblepay/issues/70same here, yesterday i had some spare coins on second wallet so i did bankroll, but after this tx eb913f6ae03b350b0f3a200ea2094886c09a91d71ce6624587a55c95bf3b3fba podc stops updating as it could not locate not pog coins... i resent them back to my wallet but it didnt help It's hard to say without any error messages, could be anything. |
|
|
|
I'm enjoying the new higher POW difficulty I'm seeing (6200 right now). This is good for our security.
I'm not sure yet, but it appears POG is slowly attracting more users.
How many users do we currently have? Checking latest stats: We have 100 active pool miners (POBH), 90 POG miners, 370 total PODC cpids. We have 5,100 (all-time) e-mail addresses in the pool (IE that I can notify in 30 days about POG, if PODC is retired). |
|
|
|
|
Looking at the code for our podcupdate, I still don't see a problem, we only skip POG denominated amounts and locked sanc funds.
Im guessing the two wallets that did something with coin control probably rearranged funds to avoid an error such as "unable to create transaction - too large" or something of the like.
If it happens again we will need all that info I posted earlier - with the exact podcupdate error message from the log.
As far as exec bankroll- a separate github issue for that with a specific example.
|
|
|
|
After running 1.1.9.6 for 24+ hours, just restart the wallet with -zapwallettxes=1 once and it will remove the orphaned transactions -- then going forward we should not see new ones appear. If I run tithe=2 , I run into orphans sometimes. I think I am trying to tithe too fast? Should I run two wallets then? I think you mentioned there's a limit of 2 tithes per blocks from same address? What do you think of InstantSend as default? Would that help with PoG difficulty window? What version are you running first? Its only been out for 12 hours. No, No, No, No. So on this one, the main thing I want to convey to the community here is that we only have 65% upgraded to versions that gracefully reject tithes. So the answer is 2 mins is OK, but we cant expect this to be perfect until 99% upgrade to versions after 1195 or so. So yes, you can use 2, but dont judge the orphans yet. No never run two wallets, no need. There is a limit of 75 global tithes per block. InstantSend would just reduce the total confirms but wouldnt help. |
|
|
|
So please don't insinuate that we aren't trying to fix production issues. I'll go out on a limb and say I think we have a cleaner environment in github with production support issues than 75% of the communities issues lists. Especially when dealing with prod support emergencies.
Please don't take it the wrong way. We appreciate all that you do. We all want a better BiblePay product, right? I closed the issue because I figured out a workaround (make a separate PoG wallet). But I still have problems with exec bankroll (different circumstance). I'm just trying to help bbptoshi by explaining what I did. I doubt anyone thinks you aren't fixing production issues. Look at all the fixes and new features we've in the last few weeks!  After running 1.1.9.6 for 24+ hours, just restart the wallet with -zapwallettxes=1 once and it will remove the orphaned transactions -- then going forward we should not see new ones appear. If I run tithe=2 , I run into orphans sometimes. I think I am trying to tithe too fast? Should I run two wallets then? I think you mentioned there's a limit of 2 tithes per blocks from same address? What do you think of InstantSend as default? Would that help with PoG difficulty window? What version are you running first? Its only been out for 12 hours. Was on 1.1.9.5 and now I'm tithing on 1.1.9.6. Still ran into some tithes too high this one is interesting... tithe amount is 9.79 and max tithe is 9.79, but considered Illegal tithe - tithe too high? Looks like block PoG diff was 9.78999999 so that makes sense now. "xxx": "Legal: -3 [TITHE_TOO_HIGH], Amount: 9.79, Height: 104236, Spent_Coin_Value: 1046.00, 9212fd788f03968e2dfc81372bf9e4b779f510e980bf0303525284d45b257715-76, Age: 1.55, NickName: xxx [Max Tithe Amt: 9.79, Min Age: 1.51, Min Coin Value: 530.04]", http://explorer.biblepay.org/api/getblock?hash=efa857e0928fdc37c970cbd13337d80ecb96158342502524744ac35ee0650c6a "block_tithes": 617.8805,
"24_hour_tithes": 7509.68399948,
"pog_difficulty": 1386.882573590632,
"min_coin_age": 1.51,
"min_coin_amt": 530.04,
"max_tithe_amount": 9.78999999,
OK, just try to proofread your post and think what others feel when you click the red button. OK, thats cool. Anyway, on that tithe you posted (-3) that was not from 1196. I can tell because 1196 sends out .05% less than the TDP params for the block. So I suggest going through your list - and auditing blocks up to your cutover point. Thats why I said wait 24 hours- then your list will be clean with 1196. EDIT: Yes - its possible on 1195 that a tithe that is rounded down is over the limit by .000001 satoshi. |
|
|
|
What is the actual reward distribution now that we have POG in place?
This is what I found in the official BBP webpage but POG is not listed.
10% Charity
5% IT
2.5% PR (Public Relation campaigns)
2.5% P2P (Orphan Letter Writing, Pay To Preach, Pay to be a Priest, FAQ Writers, Social Media)
38.5% Proof of Distributed Computing (PODC) [Cancer Research]
3% Proof of Work (POW)
38.5% Masternodes (Sanctuaries)
Can someone clarify how are the coins distributed?
Thank you!
Here you go: https://wiki.biblepay.org/EconomicsThank you Rob! What is the plan/future of PODC? I'm going to enter a topic for it later today - and we can discuss its future. |
|
|
|
using 1.1.9.6 (2019-02-27 15:39:43 -0600)
I did an exec bankroll of a single 500k BBP just now. It wouldn't let me run another exec bankroll on the change address. I had to send it to a different receiving address first. Then I was able to do an exec bankroll. you're saying it should work, but it doesn't work for me.
can anyone else reproduce my situation?
This happened to me as well, except instead of a second bankroll I was unable to send a podcupdate until sending the coins to myself using coin control. I also agree about the checkboxes at the top. I only understand that checking custom lets you see hypothetical scenarios by changing the parameters. When you sent coins to yourself via coin-control to enable yourself to spend the coins in a PODC update, please tell us the exact amounts to had to free. If they were change for pog bankroll denoms, then they would not have worked in a PODC update anyway (as PODC updates skip those). If you can reproduce the scenario again, please enter a github with a screen shot of the coin control before you reallocate, an actual PODC update error message, and the output of exec getdimensionalcoins 0 0 so we can see the actual coins involved in the failed podc update. |
|
|
|
After running 1.1.9.6 for 24+ hours, just restart the wallet with -zapwallettxes=1 once and it will remove the orphaned transactions -- then going forward we should not see new ones appear. If I run tithe=2 , I run into orphans sometimes. I think I am trying to tithe too fast? Should I run two wallets then? I think you mentioned there's a limit of 2 tithes per blocks from same address? What do you think of InstantSend as default? Would that help with PoG difficulty window? What version are you running first? Its only been out for 12 hours. No, No, No, No. |
|
|
|
using 1.1.9.6 (2019-02-27 15:39:43 -0600)
I did an exec bankroll of a single 500k BBP just now. It wouldn't let me run another exec bankroll on the change address. I had to send it to a different receiving address first. Then I was able to do an exec bankroll. you're saying it should work, but it doesn't work for me.
can anyone else reproduce my situation?
This happened to me as well, except instead of a second bankroll I was unable to send a podcupdate until sending the coins to myself using coin control. I posted this as a github issue 3 weeks ago. I think more will run into this as they transition away from PoDC to PoG. My workaround is to run two wallets - one for PoDC and one for PoG. I keep enough for 100% stake in PoDC and send the rest to PoG. PODCUpdate: Unable to locate coins not marked as POG bankroll denominations. https://github.com/biblepay/biblepay/issues/70No, actually what you mean is you entered it 3 weeks ago and we helped you, and you closed it 19 days ago and re-opened it 2 days ago, correct? So please don't insinuate that we aren't trying to fix production issues. I'll go out on a limb and say I think we have a cleaner environment in github with production support issues than 75% of the communities issues lists. Especially when dealing with prod support emergencies. |
|
|
|
ROBERT
if you will be deleting posts....ill be writing to Theymos that you makin joke from this forum and ppl its FIRST warning to you you are very little person on this BTT,so Calm Down
This is a self-moderated topic. You can start your own thread if you want. Why are you still here? Your last racist and homophobic message to me will not be tolerated. I've reported you to BTC Talk mods and will ask them to kick you off this forum. That kind of hate speech is not tolerated. Plus he is on the ban list. Slovakia, see the ban list on the bottom of the OP post. |
|
|
|
|
After running 1.1.9.6 for 24+ hours, just restart the wallet with -zapwallettxes=1 once and it will remove the orphaned transactions -- then going forward we should not see new ones appear.
|
|
|
|
Great work on the POG everyone. Its a great complement to PODC and they balance each other well for different users. The POG Engine is a powerful interface, and in using it I came up with some additional thoughts.
- Would it be possible to number the list in the POG Engine so users can count the tithes? This would be useful for the custom view especially.
- Another suggestion would be to consider rounding the max tithe (and enforcement of such) to the tenth or whole number to make it a bit more user friendly. Not rounding individual tithes, just the limits. Also could include rounding of the minimum age and minimum coin (maybe should be called note) amount.
For example (and I changed the verbiage and order a bit as a suggestion):
Max. Tithe: 9.5
Min. Coin Age (Days): 3.4
Min. Note Size: 1290
The order then is consistent with the 'tithe 9.5 3.4 1290' command.
Thanks for considering my suggestions, all!
Thanks for the suggestions. On the pog leaderboard UI, we do have the tithe count so we could probably add a column to it. On the tithe max allowed amount snapping to nearest 10th idea, its a pretty good idea (in that we could probably quote the amounts rounded down, while the hard consensus allows up to the internal amount)- its certainly interesting. Could you put an enhancement suggestion in github so this does not get lost? https://github.com/biblepay/biblepay/issues |
|
|
|
"Total Legal Tithes Amount": 566.35999992,
"Total Illegal Tithes Amount": 251.27999999,
"Total Legal Tithe Count": 59,
"Total Illegal Tithe Count": 26
Better but still a lot of tithe too high reasons. The new version should make a big difference. |
|
|
|
|
I'm enjoying the new higher POW difficulty I'm seeing (6200 right now). This is good for our security.
I'm not sure yet, but it appears POG is slowly attracting more users.
|
|
|
|
|
BiblePay
1.1.9.6 - Leisure Upgrade
- Ensure pogpool is up to date before auto-tithing
- Auto tithe 5% less than max allowed, with 5% more age. This is
configurable by the user by setting pogbuffer=.05 (the default is
already set to .05). Set to 0 to disable.
- Fix titheinfo ROI negative figure.
- Make tithe change return to "TITHES" address.
- Enhance exec pogaudit to include actual tithe difficulty parameters
|
|
|
|
i have also txs with >1bpp back to tithes lowest pile is 0.49990180 and highest 1.47982520. looks like everything is +0.5bbp  You seem to understand what I was saying. Maybe Rob didn't understand. It is not a big deal, but I think if you get change it should be consistent right? Less than 1 BBP? I don't know, I was thinking maybe one time you need min coin value 1899 and because you got too much change, your tithe was 1898, so you can not tithe. I know, silly worry... On the idea about 'exec consolidate' to consolidate change, I was thinking we might not need it because 'exec bankroll' virtually does the same thing. If a user runs exec bankroll the same process will sweep the change into a larger bank note.
Skipping this idea. Understandable. Still ran into some issues trying to bankroll. Even though I had enough non-tithe and non-PoDC to create my denominations, the PoDC balance gave the unable to bankroll error. You should be able to bankroll even if PoDC balance exists without touching PoDC funds. Even if PoDC goes away, those that migrate from PoDC to PoG, potentially have the same issue. They'd need to send their PoDC balance to a non-tithe and non-PoDC address and do the exec bankroll from there. What is it that I'm not understanding - you seem to be saying the change is inconsistent, and I seem to be saying the change is based on the leftover amount after a denominated change amount (posted above) - but for some reason you quoted Capulo and said the same complaint over. Its usually best in this situation to enter a github issue with the exact transaction ID so we can explain why you received that amount. Regarding PODC, its PODC updates that skips pog denominated funds in PODC updates. Not POGs exec bankroll that skips PODC update funds. POG exec bankroll just skips locked and POG denominated amounts. Sorry, my mistake. I finally found a case where my hypothesis was not correct: http://explorer.biblepay.org/tx/1756b896769f70b0f0c98b8b72357a82bed6bbb13965230d79b6b8f9aa16bbe7BBP tithe > 9.5 BBP but change is <1 BBP. It is quirky the range goes somewhere between 0 to 2, but its not a bug. I would think change would be 0 to 1, but maybe that's just an incorrect assumption. The important thing is that if we start with a very large note (like 5,000 bbp) and we tithe 9, it will take 100 uses to whittle it down to 4,100, so the small amount of change whether .10 bbp or 1.10 bbp is really not causing much of a problem (compared to the actual use of the note) so I think adding more complexity to try to make change smaller is probably something we can look at later towards the end of the year. But change should range from .01 to 1.90 the way it is now (depending on the 3 things). |
|
|
|
i have also txs with >1bpp back to tithes lowest pile is 0.49990180 and highest 1.47982520. looks like everything is +0.5bbp You seem to understand what I was saying. Maybe Rob didn't understand. It is not a big deal, but I think if you get change it should be consistent right? Less than 1 BBP? I don't know, I was thinking maybe one time you need min coin value 1899 and because you got too much change, your tithe was 1898, so you can not tithe. I know, silly worry... On the idea about 'exec consolidate' to consolidate change, I was thinking we might not need it because 'exec bankroll' virtually does the same thing. If a user runs exec bankroll the same process will sweep the change into a larger bank note.
Skipping this idea. Understandable. Still ran into some issues trying to bankroll. Even though I had enough non-tithe and non-PoDC to create my denominations, the PoDC balance gave the unable to bankroll error. You should be able to bankroll even if PoDC balance exists without touching PoDC funds. Even if PoDC goes away, those that migrate from PoDC to PoG, potentially have the same issue. They'd need to send their PoDC balance to a non-tithe and non-PoDC address and do the exec bankroll from there. What is it that I'm not understanding - you seem to be saying the change is inconsistent, and I seem to be saying the change is based on the leftover amount after a denominated change amount (posted above) - but for some reason you quoted Capulo and said the same complaint over. Its usually best in this situation to enter a github issue with the exact transaction ID so we can explain why you received that amount. Regarding PODC, its PODC updates that skips pog denominated funds in PODC updates. Not POGs exec bankroll that skips PODC update funds. POG exec bankroll just skips locked and POG denominated amounts. |
|
|
|
|
On the idea about 'exec consolidate' to consolidate change, I was thinking we might not need it because 'exec bankroll' virtually does the same thing. If a user runs exec bankroll the same process will sweep the change into a larger bank note.
Skipping this idea.
|
|
|
|
Just to give me a second witness, if you look through your illegal tithes for the day, are they all illegal by only .05 bbp or less?
I haven't checked recently, but they were off only by a little bit. 0.05 BBP is close. I'll check in 8 hours when I think my BBP matures again. Have you noticed if the tithe is >= 9.5 then your change is between 1-2 BBP. If tithe is <9.5, then change is <1 BBP? So I think I see the reason the tithes are off by a few cents. It appears the miner thread needs to call and ensure the pogpool is updated right before it tithes - Im working on adding a call and a buffer option to the for the next version. On the change, the actual change amount doesn't really have a relationship to the amount tithed it has more to do with what coin it chose to tithe with and how much change it would receive when it breaks the coin. When it breaks the coin, it subtracts the denominated amount from the change and makes two transactions - one denominated and one change. The denominated should go to "TITHES" but its currently going to Change (to me that is the only issue - the cosmetic display problem). EDIT: Nvm on the cosmetic issue; fixed; now both returns go to TITHES and I was able to test it in debug and it works... |
|
|
|
|
Show Posts
