My cpid is over 15 years old. What do you mean expires in six months? Why could it expire? Last time I did exec associate again I lost 1-2 days of podc payments. Are you going to reimburse everyone for the lost time?
Why some face invalid destination address? Not a great time to renew of we are losing podc through MN vote soon anyway.
Dear Sun, If you continue to post in such a disrespectful way, your Bitcointalk access for this forum will be banned. Rob |
|
|
|
Please try forcing a podcupdate 'exec podcupdate true' then check your rac.
This is existing behavior - this is that if you miss a podcupdate (yours looks missing for 24 hrs) it queries 0 rac from wcg until you send a new podcupdate.
Yes I know, but the last output I posted is actually the answer for the forced PODC update (tried that several times): 21:42:21

exec podcupdate true
21:42:21

{
"Command": "podcupdate",
"PODCUpdate": "Processed (1) over 0 CPID(s) successfully."
}
Please try 'exec associate user pass true' then wait til the 5 confirms hits, then try again, and please, let us know that its fixed. For the naysayers, Yes, I want to try this. This is because cpids' over 6 months old expire in the chain. We need non-expired DCC associations in the chain with valid wallet sigs. This is just a coincidence of the timing, but the new wallet requires all of the elements to be present (IE I dont think its a bug). |
|
|
|
BiblePay
1.1.9.7 - Leisure Upgrade
- Slow down POG leaderboard UI refresh
- Speed up boot time
- Fix bug where PODC update is unable to find destination address
- Fix mining crash in windows 10
Could someone please tell us if this fixes the crash in windows 10. Also, we had complaints of someone trying to do 'exec podcupdate' and receiving "Invalid Destination Address". This fixes that problem.
Also: This wallet fixes the problem where a person is unable to run 'exec podcupdate true' because the transaction is rejected. Please try again in this version.
I realized that I missed PODC payment yesterday because my wallet got confused with POG and PODC and somehow touched my PODC pile so that my specified utxoamount wasn't met anymore. Today in the morning I tried to send PODCupdate true, but got the "invalid destination address" error. I didn't have time then to do anything about it. Now I read that you already fixed this error. However for me it seems to have caused an even "worse" situation: my wallet (1198) doesn't even read out my RAC anymore. This is how it looks like: "Command": "getboincinfo",
"CPID": "7c9264559fef3c1c689ee9fc3ff42494",
"Address": "BNetxsZfjyNfW73Kvsh5AYLHENpEHcR3qh",
"CPIDS": "7c9264559fef3c1c689ee9fc3ff42494;",
"CPID-Age (hours)": 431011,
"NextSuperblockHeight": 104970,
"NextSuperblockBudget": 998673,
"Total_RAC": 0,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 61522,
"Total Budget (One Day)": 998673,
"Total Budget (One Week)": 7066751,
"Superblock Count (One Week)": 8,
"Superblock Hit Count (One Week)": 8,
"Superblock List": "104765,104560,104355,104150,103945,103740,103535,103330",
"Last Superblock Height": 104765,
"Last Superblock Budget": 998673,
"Last Superblock Payment": 0,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 8.705839501066333 "Command": "totalrac",
"Total RAC": 0,
"UTXO Target": 10,
"StakeBalance": 2586156,
"Threshhold to receive 10% rewards (below this UTXO Amount rewards are lost)": 10,
"Stake Level Required For 10% Level": 10,
"Stake Level Required For 20% Level": 10,
"Stake Level Required For 30% Level": 10,
"Stake Level Required For 40% Level": 10,
"Stake Level Required For 50% Level": 10,
"Stake Level Required For 60% Level": 10,
"Stake Level Required For 70% Level": 10,
"Stake Level Required For 80% Level": 10,
"Stake Level Required For 90% Level": 10,
"Stake Level Required For 100% Level": 10,
"Total Team RAC": 5793726 "Command": "podcupdate",
"PODCUpdate": "Processed (1) over 0 CPID(s) successfully." Any ideas? Right now it looks like I'm gonna miss out the second PODC payment in 3 days.  Please try forcing a podcupdate 'exec podcupdate true' then check your rac. This is existing behavior - this is that if you miss a podcupdate (yours looks missing for 24 hrs) it queries 0 rac from wcg until you send a new podcupdate. |
|
|
|
Is this approved and transparant? Can people see, if they want, on black and white where the money is goining to?
Yes, see accountability.biblepay.org. |
|
|
|
|
We had 9 letters written this period, these have been sent.
Note: We need about 78 more letters written over the next 60 days, if anyone will help. Reward is above 8,500 BBP now.
* On a side note, the bbp price scale has been expanded in the pool so now the subway gift card is more accurately priced (The last high price was due to not having enough zeroes in our price on the home page - fixed).
|
|
|
|
|
BiblePay
1.1.9.8 - Leisure Upgrade
- Honor the pogbuffer setting preventing auto-tithe from constantly
working (this bug affected auto-tithe and the rpc tithe)
|
|
|
|
|
BiblePay
1.1.9.7 - Leisure Upgrade
- Slow down POG leaderboard UI refresh
- Speed up boot time
- Fix bug where PODC update is unable to find destination address
- Fix mining crash in windows 10
Could someone please tell us if this fixes the crash in windows 10. Also, we had complaints of someone trying to do 'exec podcupdate' and receiving "Invalid Destination Address". This fixes that problem.
Also: This wallet fixes the problem where a person is unable to run 'exec podcupdate true' because the transaction is rejected. Please try again in this version.
|
|
|
|
regarding auto tithe, it looks here is problem. Why does wallet choose wrong coin roll? I have a lot of rolls with coin age >2.415 and amount > 859
An this happens every 5 minutes in debug.log(tithe=5)
BiblePayMiner::Choosing to tithe with coin age 2.300208 and coin amount 4989.001000 with a total tithe amount of 9.660000 with current pog difficulty of 2250.069728 with buffered tithe amount of 9.177000. CreateTransaction::Requiring specific coin age 2.415000 and coin amount 859
BiblePayMiner::SendTithe::Error - Unable to send tithe - Amount 9.660000, Error Unable to Create Transaction: Unable to locate coins older than minimum_tithe_coin_age. ResendWalletTransactions: rebroadcast 2 unconfirmed transactions
Wait, let me check. |
|
|
|
After update to 1.1.9.6 all my titheable coin disappear   . i mean my coin still in wallet but no able to tithe. coinage ..etc..gone...WTH i can't understand.. It seems I have kind of the opposite problem.  Since updating to 1195 or 1196 (not sure which, I'm currently on 1196) my wallet does not tithe as often as it can. I have set "tithe=10" and my POG Engine Room is full of tithable coins, but the wallet only tithes 3 times (every 10 minutes), then waits for approx. 3-4 hours, then again tithes 2 or 3 times and so on ... Any ideas? I have same problem. After updating to 1196 my wallet doesnt send automatic tithes regularly, although I have coins with requested coin age and amount. I tried to change tithe= parameter, but its same. Second issue I dont like - if my wallet finally sends some tithes - they often ends as illegal. When I tithe manually sometimes I get this error: tithe 9 { "Error": "Error: The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here." } Yeah, thats not 1196, thats a tithe problem. Try restarting with -zapwallettxes=1 and manually tithe and let us know if it fixed it? |
|
|
|
Yes, I find those kind of errors too, but they are quite rare. Maybe the wallet waits for a prolonged time after this?
I also tested faster manual tithing right now, and I could practically tithe successfully every 4 or 5 seconds.
Well I'll just leave the wallet running with tithe=5 over night.
Thanks for your help!
Anyway, I
The one I use for PoDC and 5% solo mining (Windows 10) does not crash. on my mac and Windows 10 it keeps crashing on me daily. and I'm getting reports from some Linux masternode holders 1196 crashing on them. exec mypogaudit is a useful feature, but I'm not sure if it is worth risking your wallet crashing if you use PoG.
Well its pretty obvious to me we didnt have mac and windows 10 crashes up til the last release otherwise I would have seen at least one github issue. I see you just entered one now. Thanks, we'll look at it. So basically this is a brand new mining issue with pog in windows 10 and mac. Svk Niko said his crashed too on windows but was on 1191. So far other versions that been reliable for me. Debugging most probable cause now.. |
|
|
|
If tithe is in mempool can txt be rejected because min coin age or min coin value doesn't meet current requirements? As a test I tithes 75x and hit the mempool limit. I don't think all made it in. The ones on next block were illegal because min coin age changed.
I know you want to reject before tx is made but sometimes mempool tx may be illegal after the fact.
I may be misunderstanding something here but that's my assessment.
Yes, tithe will gracefully be rejected out of the memory pool, and tx will fail immediately if it doesn't meet diff requirements, if someone fraudulently modifies the client and forces it in and the client misses the local check, however, only 62% have upgraded, so right now we have a 62% chance of that working every time (for an end user running a fraudulent version). So this is why I don't want to discuss that particular thing to a great-great degree if its not entirely in prod yet, but, I do want to discuss any prod support issue until the pog works 100% correctly. I don't see a problem in this case. |
|
|
|
Yes, I find those kind of errors too, but they are quite rare. Maybe the wallet waits for a prolonged time after this?
I also tested faster manual tithing right now, and I could practically tithe successfully every 4 or 5 seconds.
Well I'll just leave the wallet running with tithe=5 over night.
Thanks for your help!
Anyway, I
The one I use for PoDC and 5% solo mining (Windows 10) does not crash. on my mac and Windows 10 it keeps crashing on me daily. and I'm getting reports from some Linux masternode holders 1196 crashing on them. exec mypogaudit is a useful feature, but I'm not sure if it is worth risking your wallet crashing if you use PoG.
Well its pretty obvious to me we didnt have mac and windows 10 crashes up til the last release otherwise I would have seen at least one github issue. I see you just entered one now. Thanks, we'll look at it. So basically this is a brand new mining issue with pog in windows 10 and mac. |
|
|
|
# mempool tx: 1
=> manual tithe works perfect
=> # mempool tx: 4
=> tried manual tithe again: works after approx. 2 minutes
=> further manual tithes also seem to work, # mempool tx is rising (currently 11)
I'd try tithe=5 (every 5 minutes) Anything useful coming from your debug.log? I'm not able to tithe and there's lines like this: 2019-03-01 19:20:35 BiblePayMiner::Choosing to tithe with coin age 2.650532 and coin amount 1087.001000 with a total tithe amount of 9.610000 with current pog difficulty of 2522.398416 with buffered tithe amount of 8.168500. CreateTransaction::Requiring specific coin age 2.932500 and coin amount 963
BiblePayMiner::SendTithe::Error - Unable to send tithe - Amount 9.610000, Error Unable to Create Transaction: Unable to locate coins older than minimum_tithe_coin_age.
Yes, I find those kind of errors too, but they are quite rare. Maybe the wallet waits for a prolonged time after this? I also tested faster manual tithing right now, and I could practically tithe successfully every 4 or 5 seconds. Well I'll just leave the wallet running with tithe=5 over night. Thanks for your help! Anyway, I I just had the exact same problem! What I did to fix it was: from the UI, uncheck pog tithe, check Donate to foundation, send any amount, then after it sends I went back to pog tithing. I have no idea why freeing up the coin order fixed it - it seems to be the same thing that fixed Capulos PODC send yesterday (sending an interim tx). Ill check into it more asap. |
|
|
|
Not sure what this means, but QIEX said: https://info.qiex.com/temporary-maintenance-announcement/TEMPORARY MAINTENANCE ANNOUNCEMENT
! WE FOUND A POTENTIAL SECURITY RISK AT THE QIEX EXCHANGE. IN ORDER TO ENSURE THE SAFETY OF USERS’ FUNDS, QIEX IS ACTIVELY HANDLING IT.
! DUE TO THE HIGH LEVEL OF SECURITY RISK, QIEX IS TROUBLESHOOTING ALL POSSIBLE SECURITY RISKS. THIS MAY TAKE A LONG TIME.
! ALL UNFINISHED ORDERS FOR THE USER HAVE BEEN CANCELLED AND RESTORED TO YOUR FUNDS ACCOUNT. ENSURE THAT YOUR ASSETS CAN BE TRADED SMOOTHLY.
! AFTER LOGGING IN SUCCESSFULLY THROUGH THIS PAGE, FOLLOW THE PROMPTS TO CONDUCT YOUR WITHDRAWAL.
! THIS MAY BE A BIT COMPLICATED, BUT TO KEEP YOUR MONEY SAFE, QIEX HAS DONE THE MOST SECURE AND EASY TO USE BALANCE. WE ARE VERY SORRY ABOUT THIS.
! BELIEVE THAT WE WILL MEET AGAIN SOON, AND WE WILL BE REFRESHED TO SURPRISE YOU.
! THANK YOU FOR YOUR LONG-TERM TRUST IN QIEX.
That is quite depressing. First Cryptopia then QIEX. |
|
|
|
After update to 1.1.9.6 all my titheable coin disappear . i mean my coin still in wallet but no able to tithe. coinage ..etc..gone...WTH i can't understand.. If they are orphans on the ui, just restart with zapwallettxes=1. Its not really 1196. I experienced a few orphans myself yesterday, still trying to work out the final conditions to prevent this nuisance. The good news is - its definitely possible to prevent these orphans over the long term, we just need to see exactly why they form before they are formed. (I could add code to free them, but I want to focus on preventing them first). (If you did zapwallettxes=2 before, that causes you to lose all coin-age. To recover start with -rescan or a wallet backup first). |
|
|
|
error message is only: unable to locate coins not marked as pog....
but i have several 5000.001 piles, few <1bbp piles, rosetta payout pile and then 487308.0000000 pile which i want to use with podc. it does not have .001 suffix, it is not labeled as TITHES etc and not works with podcupdate
Do me a favor, see if lowering the banknote quantity to 1 allows it then do the larger quantity right after that. If so we might have to make it smart enough to try the large then the small method before it fails. i'm not sure what you mean write me steps and i will try but i already did bankroll, i just need to send 480k as podcupdate Someone should enter a ticket with the exec getdimensionalbalance 0 0 in the ticket and we will write a feature that logs the exact coins we skip over in podcupdate to the log file. |
|
|
|
So wait; first of all I dont consider someone who tithes more than once a jerk. I don't think someone who tithes more than once a jerk. I consider someone who deliberately muscles their way in and tithes 100x a jerk. Someone has a higher chance now to have their tithe included at the expense of someone else. The other ones can queue up for the next block, but PoG difficulty can change and their legal tithe becomes illegal because their tithe is not meeting: 1) min coin age, 2) min coin value, and/or 3) max tithe. If you feel my question is not relevant, I can live with that. Thanks for your reply. Well the issue here is really that POG is quite a fertile playground if anyone can tithe that many transactions per day. We just need avg difficulty to rise so that it takes more like 5 days coin age, then the hypothetical person won't be able to tithe 100x to begin with. So I don't see a problem. The one time a jerk tithes 75* in a block might prevent users in that block from tithing, but there is no guarantee that diff will stay high. Also, remember diff does not rise based on a single block (its always 4 back). It should all work out over time. |
|
|
|
error message is only: unable to locate coins not marked as pog....
but i have several 5000.001 piles, few <1bbp piles, rosetta payout pile and then 487308.0000000 pile which i want to use with podc. it does not have .001 suffix, it is not labeled as TITHES etc and not works with podcupdate
Do me a favor, see if lowering the banknote quantity to 1 allows it then do the larger quantity right after that. If so we might have to make it smart enough to try the large then the small method before it fails. |
|
|
|
It's hard to say without any error messages, could be anything.
I'll try to give write up a test procedure to show you. Okay, so based on your 40 block PoG difficulty window, there's opportunity to tithe several times a day. Now, let's say some jerk wants to tithe 100 coins manually. This is more than the 75 txes you mentioned can go in a block. Who decides which tx are included in the block? Does the miner decide? Is there a more equitable way to prioritize infrequent tithers first? Or maybe limit how many the same address can tithe in the same block and queue for the next block? This would increase illegal tithes because tithe too high or coin age requirement errors can appear. But it doesn't seem fair someone can tithe 100 times and block out other participants. I ask now because if PoDC is removed, all of that BBP will either move to MNs, PoG, or sold. So, those that participate in PoG means there will be more tithe tx in blocks overall. 22:35:56 tithe 1
22:35:57 
{
"Error": "This block is currently full of tithes. Please wait until the next block."
}
Yeah, Ill try to look at Capulos issue. So wait; first of all I dont consider someone who tithes more than once a jerk. The system is deliberately set up to allow legal tithes in. The idea is for us to grow substantially, so that you really only have one legal tithe per day - then maybe per week if we had 20,000 users, etc. Its OK if someone has enough coin age to tithe more than once per block or day. Your bringing up a plethora of issues all over the spectrum that are really bitcoin issues. They really are irrelevant. The bitcoin miner works fine in selecting the first 75 who make it in one block. The important thing to know is that if someone had legal coin age and a legal tithe, they have an equal chance of being in a block. (Because dash already went through this once, and they stripped the timestamps out of the miner, so the miners dont know who is first or later, miner only picks non-determistically based on current height and internal receive time - not on the transaction timestamped time). I don't think you take into consideration what happens when we have more users; the diff rises and the frequency of tithing per user drops. |
|
|
|
|
Show Posts
