random i tried on my 4 machines on win 10 home/pro;win 7
setgenerate true 12
setgenerate true 40
setgenerate true 80
setgenerate true 112
Please find the setgenerate level that crashes your miner, then enter a github ticket. A dev needs to debug the miner on windows. Then run it on a lower thread count til we solve it. |
|
|
|
Ok guys, it's a shame that it happened but unfortunately our .50 podc mincoinage rule is causing all these problems.
Let's blame all of our problems this week on this key.
(The issue was that we couldn't actually predict how frequent or when PODC updates would occur by each user, and since they spent their own coin age on each podc update, technically they lost the coin age and then the sancs didn't include them in the consensus mechanism).
So I have disabled the rule via our spork and now starting in tonight's PODC superblock we should be back on the prior rules.
Warning: The 20BBP per rac rule is implemented for a reason. If you are caught deliberately abusing PODC by sharing UTXO funds, we have the capability to blacklist the CPID. The sancs already have this code running, so it is a very real possibility your CPID will be blacklisted if you share UTXO funds. TheSnat has the capability to report on this activity and will be monitoring for this starting tomorrow.
excellent...thanks Rob here is problem with setgenerate true x  What did you type in for setgenerate true, an x or what was the thread count? If you are michelle_75779 on SouthXChange, why are you so courteous here and backstabbing to us on there? (IE swearing and saying we are dying quickly). I thought your other handle was michelle, from the days of forum.biblepay. |
|
|
|
No restriction, but with more than 20 threads the cpu use should already be above 90%. |
|
|
|
0.5 coin age is 12hours?
Yes, but now its set to zero, so it should work like it did in the past - except TheSnat will monitor manually (using his reports). |
|
|
|
I've tried following the instructions at https://wiki.biblepay.org/Ecommerce so I can buy gift cards. I can't make it work: 09:22:08 exec listproducts
09:22:09
{
"Command": "listproducts"
} The shelves are empty. They talk about unlocking my wallet but I can find no way to do that. I added my shipping address in my biblepay.conf file and restarted my wallet. Yeah, we did have Amazon integration once, but that is temporarily disabled due to the high fees. But now we have Walmart integration live, but only inside the pool. To buy the gift card please visit pool.biblepay.org and click Store. Its all we have right now. (Im going to work on Walmart gift cards that can be emailed very soon). |
|
|
|
Ok guys, it's a shame that it happened but unfortunately our .50 podc mincoinage rule is causing all these problems.
Let's blame all of our problems this week on this key.
(The issue was that we couldn't actually predict how frequent or when PODC updates would occur by each user, and since they spent their own coin age on each podc update, technically they lost the coin age and then the sancs didn't include them in the consensus mechanism).
So I have disabled the rule via our spork and now starting in tonight's PODC superblock we should be back on the prior rules.
Warning: The 20BBP per rac rule is implemented for a reason. If you are caught deliberately abusing PODC by sharing UTXO funds, we have the capability to blacklist the CPID. The sancs already have this code running, so it is a very real possibility your CPID will be blacklisted if you share UTXO funds. TheSnat has the capability to report on this activity and will be monitoring for this starting tomorrow.
excellent...thanks Rob here is problem with setgenerate true x What did you type in for setgenerate true, an x or what was the thread count? |
|
|
|
|
Ok guys, it's a shame that it happened but unfortunately our .50 podc mincoinage rule is causing all these problems.
Let's blame all of our problems this week on this key.
(The issue was that we couldn't actually predict how frequent or when PODC updates would occur by each user, and since they spent their own coin age on each podc update, technically they lost the coin age and then the sancs didn't include them in the consensus mechanism).
So I have disabled the rule via our spork and now starting in tonight's PODC superblock we should be back on the prior rules.
Warning: The 20BBP per rac rule is implemented for a reason. If you are caught deliberately abusing PODC by sharing UTXO funds, we have the capability to blacklist the CPID. The sancs already have this code running, so it is a very real possibility your CPID will be blacklisted if you share UTXO funds. TheSnat has the capability to report on this activity and will be monitoring for this starting tomorrow.
|
|
|
|
Ok, so I ran 'exec utxoreport cpid' for your cpid, and I do see that you have sent UTXOs after Feb 1:in my sql database for your cpid.
(I see you have a registered DCC record). I've only made deposits to my BBP wallet. The wallet sent those UTXOs on its own. I don't know what a DCC record is. Right, the dcc record is the original 'exec associate' when you joined team biblepay, and I realize your wallet sent these utxos from the core qt wallet. What I'm basically hypothesizing is that we have two current issues: 1) The forum tool used for diagnosing the problem is not picking up data after 2-1 2) Our own mincoinage PODC rule requiring .50 aged utxo's is causing a big problem for PODC right now (I'm confirming this right now) I e-mailed TheSnat for #1. I'll verify #2 and if its a problem I will address this before noon today but note everyone we will have a fallback plan to prevent cheating. |
|
|
|
missing my hashes ped second 2 on 1 machine... where is problem?  So on this issue it looks like your two miners that start with name "kl*" were deleted when your account was deleted (due to the orphanage attack I mentioned in the email). So you can just recreate them, but please dont use that offensive name again or Ill manually delete them. Please rename them in your configs also. |
|
|
|
we want answers
what chain is correct?
Just verify you are on the correct chain: getblockhash 99930 9bcfc9b2ef4a2fd71a5350c057f5b25fd26e269e5260eb62f6237403ccea33a2 On a side note, verify that your miners are on this chain. Any miner not on this chain still mining wont be showing up in your miners list, and will have errors on the leaderboard. |
|
|
|
With POG, since we have a daily POG superblock payment, the home controller wallet would need to be run at least an hour a day in order to enter the pog pool regularly.
Do people need to move coins to TITHE address or create bankroll denominations explicitly? Or can people take a "normal" wallet with coins here and there, and expect the "autotithe" function to take the necessary coins to tithe automatically? Regarding my issue, put it on very low priority, it's clear that there is something going on with people doing PoDC and I think this is more relevant (and probably the root cause of everything is closer) They don't need to move them, if they tithe from any address in the GUI, its a valid tithe (POG params light up after block 100,000). When bankroll denominations are created the wallet sends them to "TITHE" just for easy recgonizing, but the address does nothing special. |
|
|
|
coin age 0.5 is problem......
ROB he asked about Masternode win wallet
Makes sense. If you do I think coins send to podcupdate is too new afterwards. Since PoDC update is every 4 hours, you would need double your stake to get 100% ... so now every time you do podcupdate you don't have any coins that are eligible to do podcupdate okay . I don't have proof, this is my opinion. Rob - would rolling back the min coin age 0.5 days for PoDC update be a reasonable place to start troubleshooting? I'm coming to this conclusion also, but let me look at this for a tad longer. |
|
|
|
all infos is posted here.......what you want, debug is here.......when i tried 50times run PPA --daemon and still crashed its not my problem..... before upgrade to 1185 all worked..... new upgrade to 1185 fucked up all .... check how many ppl got problem with PODC rewards....... this is mistake of main DEV......
As I said, we can check it Live using Discord, I'll be around for the next 2 hours if you want. MIP i deleted explorer and all with BBP..... BLE (CPU idle mining coin) explorer ran in same time like BBP= working till now without my hand, BBP? nonstop problems .... nonstop upgrade,nonstop updates, nonstop change rules, nonstop rpoblems,nonstop angries,nonstop crashing,nonstop facepalms!!!!!! yes VULTR for 10$ and for few weeks you can delete it=cos your df space will be fully  Ok I saw you edited. I just wanted to prove that it can be done without issues, I don't want to set up a permanent explorer so I know I'm short on ram and HD. You have to understand that the coins that don't update and don't experiment with new concepts are dead coins. I have also missed PoDC payments in the past, crashed many Masternodes... , and I am not complaining all day. Instead I joined the efforts and tried to improve things as they were within my possibilities, which I think it's a more constructive approach. +++ This is constructive. |
|
|
|
... Trash ...
Warning: You have violated our community guidelines. I'm turning your posts over to the bitcointalk mods. You have 2 more chances. |
|
|
|
So far the best investment I ever did! A really stable and good community. Friendly and helpful. The coin is also stable and the project has very interesting features. Thanks.
Due to adverse market conditions we might have had a bad 2018, but there is no reason we cant have a great 2019 for new users going forward. |
|
|
|
If you just stake from the wallet does it need to be open 24/7?
With POG, since we have a daily POG superblock payment, the home controller wallet would need to be run at least an hour a day in order to enter the pog pool regularly. With PODC, the controller wallet needs to send a daily podc update (at least once per day). The PODC cancer miners running Rosetta@Home usually run 24/7. |
|
|
|
I had a masternode upgraded to 1.1.8.5 last weekend and it worked fine till today. Then crashed and no matter if I made -reindex and even -rescan it kept crashing. I remembered a similar experience that slovakia posted here days ago, but I don't know whether it's related or not. Finally I deleted all *.dat files in .biblepaycore directory (except wallet.dat) and finally it restarted and has not crashed for a while. So it seems there was some DAT file corrupted around. This is the debug.log tail I obtained when it crashed, in case it helps: 2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=100e5f2b628871f5afb66c490f835ed731ea59c11ceb38a5f5473b45b1d6891b-0, error: Keys don't match: pubkey=f523728d1a020c70ad8e96752c3dfae28d777153, pubkeyFromSig=95205da74d7b92e5e4abd86889c9b133bba08142, strMessage=100e5f2b628871f5afb66c490f835ed731ea59c11ceb38a5f5473b45b1d6891b-096047OP_DUP OP_HASH160 2a9cadeeca2063d705c5239ca5a46dca50d09a00 OP_EQUALVERIFY OP_CHECKSIG, vchSig=HDg225CMJ6jLF9fF/pyAdHyl8FQ6Ijmz5oAZRBUw3tUWfMpM+dZfr3W1Qkb7S3gfbsxMbFq5e/cJUCx/iSFUkQo=
2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=b8c1b1db0023998fd778d8ccb1d635752ec8c5f87fb7c142b2a7e51133df778c-1, error: Keys don't match: pubkey=05d0e579e2f014ad321d9137a388e6a5d87c39aa, pubkeyFromSig=1849807f680ee1f0e913d317d3934ad694965f1a, strMessage=b8c1b1db0023998fd778d8ccb1d635752ec8c5f87fb7c142b2a7e51133df778c-196046OP_DUP OP_HASH160 dbd8633bef3358b38e6999145b62bace625e1dae OP_EQUALVERIFY OP_CHECKSIG, vchSig=HHzqGSWGkTVhQfvn27q2s2m46knjfIEM/Ir+DBNWpn/adz90xiX0MBGFp0cTAdlDhcSe5FEODtabVMkaXR+7KZI=
2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=568458d0f68bda886b9817ef59d875140199bb31b07e73084bd7e921324589e0-0, error: Keys don't match: pubkey=2b9e29bd8a14826585c9380596da9b22f5202513, pubkeyFromSig=ba2cbe966783369306a7442127625dffb99459c2, strMessage=568458d0f68bda886b9817ef59d875140199bb31b07e73084bd7e921324589e0-096044OP_DUP OP_HASH160 2d7d70e7a403f6b85813242e00ffe29a2b461012 OP_EQUALVERIFY OP_CHECKSIG, vchSig=G69f4ZfXHUzN23hMfDwqsDOlWEfz/hk7vyXTYnwgMD77JQkLASyBZQwRY1X/UurngUmdoBVeYQ/6B584DGuNjCQ=
2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=efdef8cb957623718418294b9eafc056528728f82561c09b2b1473f7e6fe5796-0, error: Keys don't match: pubkey=9fd7399ad53825e1ffbe2129e07538fb8b72c661, pubkeyFromSig=865518e614e67256c29052da7c7db622fdfda7f9, strMessage=efdef8cb957623718418294b9eafc056528728f82561c09b2b1473f7e6fe5796-096044OP_DUP OP_HASH160 2d7d70e7a403f6b85813242e00ffe29a2b461012 OP_EQUALVERIFY OP_CHECKSIG, vchSig=G8sjOcy0DUfGAG7vkI5pbzT/V2erskdn8UZQWGMo1ARaLxbZx/f8KnY0nH5r4gdjVedHbDA+VLPudAXH8PwFdeY=
2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=69c98e66199ebb8b60e476cd1f052d83fd5bde47bc7fa2dffd95038b79730877-0, error: Keys don't match: pubkey=fbc1aaf068c31254e302e9d8f6155d2d524b8aae, pubkeyFromSig=bf783412c5eed505d027b4fb16628272c32d20eb, strMessage=69c98e66199ebb8b60e476cd1f052d83fd5bde47bc7fa2dffd95038b79730877-096043OP_DUP OP_HASH160 caedc5a1e499093261e620884726a218e07fd693 OP_EQUALVERIFY OP_CHECKSIG, vchSig=HC5RqeFUCdeXImzwMQzwYL5jpzOs+IlpnwvRfIdkrGw3P/9/+2SvysiEi4uT9rZCuPWw3GvNRLOxeu2o9SBflfs=
2019-02-06 10:50:56 DCC hash 0000000000000000000000000000000000000000000000000000000000000000 Age 2451.000000 FileTimeStamp 1549447808.000000 IsOld No
Chosen Sanctuary - pulling down the DCC file... Aggregator 0.000000, Percentile 0.000000
2019-02-06 10:51:10 Filter File 100050 Processing DCC Line 2000000.000000 Processing DCC Line 4000000.000000 Processing DCC Line 6000000.000000 Processing DCC Line 8000000.000000 Processing DCC Line 10000000.000000 Processing DCC Line 12000000.000000
I'm running the PODC consensus process on one of my sancs (exec dcc). We can then see the lines in the log to see if the whole thing finishes and rule this part out first. It doesn't look like that was the problem, dcc finishes and I see the magnitude file has been created. I see our last superblock contains all the mags. This has more to do with some CPIDs (but not all) are not having their UTXO weight recognized, possibly due to the new .50 age rule. I'll look into that next. |
|
|
|
I had a masternode upgraded to 1.1.8.5 last weekend and it worked fine till today. Then crashed and no matter if I made -reindex and even -rescan it kept crashing. I remembered a similar experience that slovakia posted here days ago, but I don't know whether it's related or not. Finally I deleted all *.dat files in .biblepaycore directory (except wallet.dat) and finally it restarted and has not crashed for a while. So it seems there was some DAT file corrupted around. This is the debug.log tail I obtained when it crashed, in case it helps: 2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=100e5f2b628871f5afb66c490f835ed731ea59c11ceb38a5f5473b45b1d6891b-0, error: Keys don't match: pubkey=f523728d1a020c70ad8e96752c3dfae28d777153, pubkeyFromSig=95205da74d7b92e5e4abd86889c9b133bba08142, strMessage=100e5f2b628871f5afb66c490f835ed731ea59c11ceb38a5f5473b45b1d6891b-096047OP_DUP OP_HASH160 2a9cadeeca2063d705c5239ca5a46dca50d09a00 OP_EQUALVERIFY OP_CHECKSIG, vchSig=HDg225CMJ6jLF9fF/pyAdHyl8FQ6Ijmz5oAZRBUw3tUWfMpM+dZfr3W1Qkb7S3gfbsxMbFq5e/cJUCx/iSFUkQo=
2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=b8c1b1db0023998fd778d8ccb1d635752ec8c5f87fb7c142b2a7e51133df778c-1, error: Keys don't match: pubkey=05d0e579e2f014ad321d9137a388e6a5d87c39aa, pubkeyFromSig=1849807f680ee1f0e913d317d3934ad694965f1a, strMessage=b8c1b1db0023998fd778d8ccb1d635752ec8c5f87fb7c142b2a7e51133df778c-196046OP_DUP OP_HASH160 dbd8633bef3358b38e6999145b62bace625e1dae OP_EQUALVERIFY OP_CHECKSIG, vchSig=HHzqGSWGkTVhQfvn27q2s2m46knjfIEM/Ir+DBNWpn/adz90xiX0MBGFp0cTAdlDhcSe5FEODtabVMkaXR+7KZI=
2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=568458d0f68bda886b9817ef59d875140199bb31b07e73084bd7e921324589e0-0, error: Keys don't match: pubkey=2b9e29bd8a14826585c9380596da9b22f5202513, pubkeyFromSig=ba2cbe966783369306a7442127625dffb99459c2, strMessage=568458d0f68bda886b9817ef59d875140199bb31b07e73084bd7e921324589e0-096044OP_DUP OP_HASH160 2d7d70e7a403f6b85813242e00ffe29a2b461012 OP_EQUALVERIFY OP_CHECKSIG, vchSig=G69f4ZfXHUzN23hMfDwqsDOlWEfz/hk7vyXTYnwgMD77JQkLASyBZQwRY1X/UurngUmdoBVeYQ/6B584DGuNjCQ=
2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=efdef8cb957623718418294b9eafc056528728f82561c09b2b1473f7e6fe5796-0, error: Keys don't match: pubkey=9fd7399ad53825e1ffbe2129e07538fb8b72c661, pubkeyFromSig=865518e614e67256c29052da7c7db622fdfda7f9, strMessage=efdef8cb957623718418294b9eafc056528728f82561c09b2b1473f7e6fe5796-096044OP_DUP OP_HASH160 2d7d70e7a403f6b85813242e00ffe29a2b461012 OP_EQUALVERIFY OP_CHECKSIG, vchSig=G8sjOcy0DUfGAG7vkI5pbzT/V2erskdn8UZQWGMo1ARaLxbZx/f8KnY0nH5r4gdjVedHbDA+VLPudAXH8PwFdeY=
2019-02-06 10:50:55 ERROR: CMasternodePaymentVote::CheckSignature -- Got bad Masternode payment signature, masternode=69c98e66199ebb8b60e476cd1f052d83fd5bde47bc7fa2dffd95038b79730877-0, error: Keys don't match: pubkey=fbc1aaf068c31254e302e9d8f6155d2d524b8aae, pubkeyFromSig=bf783412c5eed505d027b4fb16628272c32d20eb, strMessage=69c98e66199ebb8b60e476cd1f052d83fd5bde47bc7fa2dffd95038b79730877-096043OP_DUP OP_HASH160 caedc5a1e499093261e620884726a218e07fd693 OP_EQUALVERIFY OP_CHECKSIG, vchSig=HC5RqeFUCdeXImzwMQzwYL5jpzOs+IlpnwvRfIdkrGw3P/9/+2SvysiEi4uT9rZCuPWw3GvNRLOxeu2o9SBflfs=
2019-02-06 10:50:56 DCC hash 0000000000000000000000000000000000000000000000000000000000000000 Age 2451.000000 FileTimeStamp 1549447808.000000 IsOld No
Chosen Sanctuary - pulling down the DCC file... Aggregator 0.000000, Percentile 0.000000
2019-02-06 10:51:10 Filter File 100050 Processing DCC Line 2000000.000000 Processing DCC Line 4000000.000000 Processing DCC Line 6000000.000000 Processing DCC Line 8000000.000000 Processing DCC Line 10000000.000000 Processing DCC Line 12000000.000000
I'm running the PODC consensus process on one of my sancs (exec dcc). We can then see the lines in the log to see if the whole thing finishes and rule this part out first. |
|
|
|
Missing payments since 1-31-19: Status: 2449 confirmations
Date: 1/24/2019 19:00
Source: Generated {mined}
Credit: 461.14692118 Biblepay
Net amount: +461.14692118 Biblepay
Status: 2904 confirmations
Date: 1/22/2019 10:09
Source: Generated {mined}
Credit: 465.93032872 Biblepay
Net amount: +465.93032872 Biblepay
Status: 222 confirmations
Date: 2/4/2019 21:45
Source: PODC-Payment
Source: PODC Research
Credit: 26 563.73000000 Biblepay
Net amount: +26 563.73000000 Biblepay
Status: 632 confirmations
Date: 2/2/2019 20:39
Source: PODC-Payment
Source: PODC Research
Credit: 24 632.33000000 Biblepay
Net amount: +24 632.33000000 Biblepay
Status: 837 confirmations
Date: 2/1/2019 19:47
Source: PODC-Payment
Source: PODC Research
Credit: 37 712.38000000 Biblepay
Net amount: +37 712.38000000 Biblepay
Status: 1042 confirmations
Date: 1/31/2019 18:49
Source: PODC-Payment
Source: PODC Research
Credit: 50 133.28000000 Biblepay
Net amount: +50 133.28000000 Biblepay
Ok, so I ran 'exec utxoreport cpid' for your cpid, and I do see that you have sent UTXOs after Feb 1:
09:37:23

exec utxoreport 3c077620e211d1237d796b34fe93941d
09:37:34

{
"99911 [02-06-2019 13:20:05] (7344596 BBP) [TXID=5eeb7552748e12927946b300f84c86d4b8830a2443fe019fc302afc44a1dc127] ": "0.10",
"99868 [02-06-2019 08:47:07] (7344596 BBP) [TXID=32eb368f4bc5caa67f10053ad00ce9408f17302a0264f2467182855076489db2] ": "0.19",
"99836 [02-06-2019 04:20:49] (7344596 BBP) [TXID=413e392fbecee53d1a15c2aa61deb9fa29f18a4a999452f9c6039415d98ef453] ": "0.18",
"99794 [02-05-2019 23:55:15] (7344596 BBP) [TXID=a1c2e7e0cebb66a00130be525d40aceabe4b7dbcfbb7375fd558fa43ff3d5a1c] ": "0.18",
"99753 [02-05-2019 18:12:11] (7344596 BBP) [TXID=e8e6b6a35b8a0ad856ff62c3e7de365951aca769f7890807f4e738e3545be747] ": "0.24",
"99711 [02-05-2019 14:01:14] (7318032 BBP) [TXID=048243563634e6dbe1e954d989597bef9b38478cf928f56ce048a0acb60d9a40] ": "0.17",
"99670 [02-05-2019 09:26:58] (7318032 BBP) [TXID=3a3d34935f96cc609d5f8c21b238c05c0ea61cb3b21e1fd59f176777a97aad22] ": "0.19",
"99632 [02-05-2019 04:50:35] (7318032 BBP) [TXID=e557219a9bbcfa1ec133ddfc8a2fefa9a70357b05dc0984afe9f5dbb06ad8b25] ": "0.19",
"99593 [02-05-2019 00:34:02] (7318032 BBP) [TXID=f132ad7e60aadb5fe41146a1a66bce58836dc5094db6ffd29084e9c67fc8b8de] ": "0.18",
"99562 [02-04-2019 20:16:15] (7318032 BBP) [TXID=7f3206052025725b53b8a08202f94cb788dfc7b938f41548648d5569d9c217a5] ": "0.18",
"99522 [02-04-2019 15:57:08] (7318032 BBP) [TXID=387076cc38bfc6286f4fd0c06d71bb643cb8345a64e0eef89149220e8ee88598] ": "0.18",
"99484 [02-04-2019 11:34:29] (7318032 BBP) [TXID=356ab8ea11d8d484f5e7971135b5426f676d0b5f8016a7890684cc02a6f252a0] ": "0.18",
"99447 [02-04-2019 07:19:38] (7318032 BBP) [TXID=3a3091739dbcbf5a4894665fbb5f7e2c12fb770254ccfbb2b2aa9e9230d2c15c] ": "0.18",
"99414 [02-04-2019 03:08:17] (7318032 BBP) [TXID=ed5f76fcb1df8a1a675aec580b43ece51c1c7f335f149cfb9f3f47dd605018a0] ": "0.17",
"99379 [02-03-2019 22:35:38] (7318032 BBP) [TXID=d3d23c8ed4797eb0c731ee862dab44953f82ef24a48540891ae606f1e54d3969] ": "0.19",
"99345 [02-03-2019 18:25:59] (7318032 BBP) [TXID=e44c4200817f73630e256a662e125141fbff58b5baeee42937e961aaead0d400] ": "0.17",
"99308 [02-03-2019 14:00:36] (7293400 BBP) [TXID=a722502e732f4234ae59b7a0297b86e35844ceb53e10c47b7504f33e98c175a6] ": "0.18",
"99274 [02-03-2019 09:51:32] (7293400 BBP) [TXID=cc8717a52d0ceb44d642b303b9f875ff81b040b9a3d91c151f45aeaf059a64a9] ": "0.17",
"99238 [02-03-2019 05:32:03] (7293400 BBP) [TXID=f574c35f7be213180282c2785a1d9c732bd743236f28362fe9894185942bd316] ": "0.18",
"99200 [02-03-2019 01:15:00] (7293400 BBP) [TXID=573e7daa2a538ceda2d6955c14289cb2e7519388a27a96c8a4c9f8fc4d1baf3a] ": "0.18",
"99162 [02-02-2019 20:53:40] (7293400 BBP) [TXID=065a107e8c73d69eee0d397a5a9d842780721a9d4c02b6588bb8b88467d64299] ": "0.18",
"99126 [02-02-2019 16:03:18] (7255688 BBP) [TXID=e0c9aafc4a2633b39f2dba8fd5ff21b328be70b8597dc4a3686bb074979ab69a] ": "0.20",
"99090 [02-02-2019 11:39:12] (7255688 BBP) [TXID=01b8d6d34cbac7d91fc0e530aaf9cf471a65b5dd8ac58fde0816cf25b84e69c7] ": "0.18",
"99053 [02-02-2019 07:24:06] (7255688 BBP) [TXID=24d775a84b95e37c90ab9aedfb2c97bd5a5d55145b56e2df7f81da8a66568ec9] ": "0.18",
"99016 [02-02-2019 03:04:10] (7255688 BBP) [TXID=28ac1f5ed83fb3411e57d7ef39aef83948ceed01ad6e561765c4dd1a4b3884a2] ": "0.18",
"98978 [02-01-2019 22:21:48] (7255688 BBP) [TXID=9e07dd7998a7afebec004258659b0d46eaf906d583081fc85006a8007c0c0c69] ": "0.20",
"98936 [02-01-2019 17:44:28] (7255688 BBP) [TXID=78ea1be6010d650574170a228c3098fe22642a8971ec02a4705bc7d67682d141] ": "0.19",
"98901 [02-01-2019 13:36:59] (7205554 BBP) [TXID=3c10cc7babb87f7511df9b9ff89b708b7380d31a3ce012d5b5d02ba98e01bbba] ": "0.17",
"98867 [02-01-2019 09:21:22] (7205554 BBP) [TXID=a260e27e951a86d15e3b26e767976f7a448562d336d03660b1ffdcaa0ee51234] ": "0.18",
"98834 [02-01-2019 04:37:58] (7205554 BBP) [TXID=c72afd2574165e22134cf18db59e55231d7061042c23f9ee1e12b710922b6767] ": "0.20",
"98798 [02-01-2019 00:28:36] (7205554 BBP) [TXID=fcda762466e4a8a32725fe495c3c747028037a1e25af58f39e5ded3222c28048] ": "0.17",
"98759 [01-31-2019 19:57:18] (7205554 BBP) [TXID=af9c68f13be32376e0738bc32716e4a0d4711615489b69b0f222ecf8c2950b9f] ": "0.19",
"98720 [01-31-2019 15:23:00] (7205554 BBP) [TXID=6f11a0428d2361ec6ccd57c49693e4e1abe2d794f3dc4b3bb9548864434b4591] ": "0.19",
"98684 [01-31-2019 11:01:02] (7180441 BBP) [TXID=d382de1465f02a088b72cb8f26172f20c9667aee0d5d77dc9667967bf625e28e] ": "0.18",
"98650 [01-31-2019 06:56:05] (7180441 BBP) [TXID=fcaceeed89e9440364a5548458087dd68011fb0ace7fd276d73c24800e2b4c2b] ": "0.17",
"98610 [01-31-2019 01:53:40] (7180441 BBP) [TXID=2b5ab5ee9865cd197de78b92d4ba141fda41109e086cf6d398daf07bec9aa84e] ": "0.21",
"98570 [01-30-2019 21:18:14] (7180441 BBP) [TXID=042648b611dfc94c30171174f23b7c765219ed06394315477718997050f53a10] ": "0.19",
"98535 [01-30-2019 16:36:34] (7180441 BBP) [TXID=6a608a74b45ccd4a21e1289bec83ce2d3ff839b1b140002ae7d46444a315fb76] ": "0.20",
"98493 [01-30-2019 12:00:15] (7155809 BBP) [TXID=fbcf5f25d3b1fc62471fc55a4161ef065cc26c5f774fb740e1359c8de3f2874e] ": "0.19",
"98457 [01-30-2019 07:46:15] (7155809 BBP) [TXID=6b21ff5acf95310ce2caa57fb4929649214368cd1dafec52ae9e9afb58442382] ": "0.18",
"98417 [01-30-2019 02:51:36] (7155809 BBP) [TXID=430e5895b1a6eb4a53803621e2220603957f000bdd18b0385785db85602b5301] ": "0.20",
"98375 [01-29-2019 22:22:38] (7155809 BBP) [TXID=2d592411b20f6be2667fc6a4ec912bb6ebf82ddeae03dbd71a7f69ed7284ba02] ": "0.19",
"98336 [01-29-2019 17:33:24] (7155809 BBP) [TXID=6c3e0586e5740b85447e3de917041e1a5136e796205d62ceed3f30f05f6fd750] ": "0.20",
"98298 [01-29-2019 12:59:50] (7130456 BBP) [TXID=5998b409d1ef3383741ffec47ac8c17a52c36aab5c3fb852847748426250894a] ": "0.19",
"98262 [01-29-2019 08:33:31] (7130456 BBP) [TXID=d3a1774381d1a2524f508f105f8a3e7b2b6d599000182f5d9807e741fea0c798] ": "0.18",
"98223 [01-29-2019 04:19:51] (7130456 BBP) [TXID=41598197d5520a4020e202f49ee1ed5d0e30231f30ba127a123a1aee7035001f] ": "0.18",
"98190 [01-29-2019 00:13:32] (7130455 BBP) [TXID=7816847196d97185dc6fc9ed93b5a122709e0f156cd803b068b988691b21fae0] ": "0.17",
"98151 [01-28-2019 20:02:15] (7130456 BBP) [TXID=7774220bb160505bc9499f7b440f274e215fc89819c3b5289e9a4d906e2d858c] ": "0.17",
"98116 [01-28-2019 15:46:01] (7130456 BBP) [TXID=db05783e331f60a90e5ea79cf7b58ca86d68ee7ba65bfc4c9d8efe70041972dc] ": "0.18",
"98081 [01-28-2019 11:36:47] (7103252 BBP) [TXID=afabdcc18b39c73477352d22fc952e2c6053376c0f3f986df346e798df172f01] ": "0.17",
"98048 [01-28-2019 07:32:06] (7103252 BBP) [TXID=dfee4349db78011d98d95b7c51c84373f69ab6b5cdbb8443688c72a96aba9c3d] ": "0.17",
"98007 [01-28-2019 03:07:51] (7103252 BBP) [TXID=f8554e8d7f451f6b7f967e2de0f8d55a320d5eaabee3886baef5458835dfc55d] ": "0.18",
"97942 [01-27-2019 19:17:38] (7103252 BBP) [TXID=d32d5f22525044e1087c711de2f833f0159f4454be4e74dc4cef6c345c3e2d9c] ": "0.33",
"Average Span (Days)": 0.1857578631062266,
"Average UTXO Amount": 7231329.503867195
}
TheSnat, I believe Aurum has a point, I don't see podc records after 1-31. Now as far as why you didn't receive the PODC payment itself, let me take a look at what I have in my sql database for your cpid. (I see you have a registered DCC record). |
|
|
|
|
Show Posts
