 Show Posts
|
|
Pages: [1] 2 3 »
|
It appears that the wallet locked error resolved itself after I reloaded the wallet about six times, and now it will not stay open (it is crashing every time I open it) on Windows 1.4.4.3 http://prntscr.com/ogu3qq |
|
|
|
Just stopping in to report that my miner appears to have stopped communicating with the pool again possibly. Mining all night but nothing reported on pool. On 1.4.4.3 / win 10 on main PC. 04:43:18

getmininginfo
04:43:18

{
"blocks": 132469,
"currentblocksize": 1000,
"currentblocktx": 0,
"difficulty": 3310.109699313393,
"errors": "",
"pooledtx": 0,
"chain": "main",
"genproclimit": 7,
"networkhashps": 565085.2395507756,
"hashps": 0,
"minerstarttime": "07-18-2019 08:40:39",
"hashcounter": 0,
"pooledtx": 0,
"chain": "main",
"biblepay-generate": true,
"poolinfo1": "Pool mining with eyeseven; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ",
"poolinfo2": "RMC_07-18-2019 08:40:45; RM_07-18-2019 08:40:45; RMC_07-18-2019 08:40:45; RMC_07-18-2019 08:40:45; RMC_07-18-2019 08:40:45; RMC_07-18-2019 08:40:45; RMC_07-18-2019 08:40:46; ",
"poolinfo3": "",
"poolinfo5": "Internal ABN: Invalid 1563439245; ",
"abninfo": "No block to mine... Please wait... 1563439396; No block to mine... Please wait... 1563439397; No block to mine... Please wait... 1563439396; No block to mine... Please wait... 1563439396; No block to mine... Please wait... 1563439396; No block to mine... Please wait... 1563439396; No block to mine... Please wait... 1563439397; ",
"gsc_errors": "low abn weight 0",
"poolmining": true,
"pool_url": "https://pool.biblepay.org",
"required_abn_weight": 125000
}
04:43:37

exec getabnweight
04:43:37

{
"Command": "getabnweight",
"version": 2.6,
"weight": 1104113.225231481,
"total_required": 409513
}
This is what is filling my debug.log -- I assure my wallet is unlocked 2019-07-18 08:48:54
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:48:54 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
2019-07-18 08:48:54
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:48:54 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
2019-07-18 08:49:08
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:49:08 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
2019-07-18 08:49:08
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:49:08 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
2019-07-18 08:49:08
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:49:08 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
2019-07-18 08:49:08
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:49:08 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
2019-07-18 08:49:09
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:49:09 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
2019-07-18 08:49:09
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:49:09 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
2019-07-18 08:49:09
***** CreateNewBlock::Unable to add ABN because Sorry, the wallet must be unlocked to create an anti-botnet transaction. *****
2019-07-18 08:49:09 ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlock: (code 0)
04:51:20  exec createabn 125000 1 04:51:20  { "Command": "createabn", "xml": "<MT>ABN</MT><abnmsg><nonce>0b70318ad5b83ea3fb4bc31d997f9b4253dd367a48c22bc9a6325e667323de53</nonce><ppk>ppk</ppk></abnmsg><abnsig>IGtaXnpevbCbrfXzuuRDnyFg+We2x6p1yn/8AI4PrVafRwWbvKlVoBJjr2XKc5CNcdNzUQbGBazj3wisA+NbUf0=</abnsig><abncpk>B7hrQmWPc7gScHT1QDrPGnmVUE9Hsnq5XB</abncpk><abnwgt>125000</abnwgt>", "err": "", "coin_age_data_selected": "621.0000(1.43)=[885.28] depth=309, <ROW>1161.2800(0.78)=[905.38] depth=165, <ROW>1000.0000(1.43)=[1427.04] depth=309, <ROW>1000.0000(1.43)=[1429.11] depth=309, <ROW>1000.0000(1.43)=[1431.00] depth=309, <ROW>1000.0000(1.43)=[1433.30] depth=310, <ROW>1000.0000(1.43)=[1434.84] depth=310, <ROW>997.9923(2.69)=[2679.84] depth=573, <ROW>401733.0000(2.72)=[1093876.18] depth=582, <ROW><TOTALREQ>409513.27</TOTALREQ><TOTALAGE>1105502</TOTALAGE>", "success": "225636c033e868fb1fe84006f92de45cc2fa6c46b15f577e2c5eb4b3411b2611", "coin_age_data_pre_select": "621.0000(1.43)=[885.28] depth=309, <ROW>1161.2800(0.78)=[905.38] depth=165, <ROW>1000.0000(1.43)=[1427.04] depth=309, <ROW>1000.0000(1.43)=[1429.11] depth=309, <ROW>1000.0000(1.43)=[1431.00] depth=309, <ROW>1000.0000(1.43)=[1433.30] depth=310, <ROW>1000.0000(1.43)=[1434.84] depth=310, <ROW>997.9923(2.69)=[2679.84] depth=573, <ROW>401733.0000(2.72)=[1093876.18] depth=582, <ROW><TOTALREQ>409513.27</TOTALREQ><TOTALAGE>1105502</TOTALAGE>", "audited_weight": 1105194.421644164, "vin_coin_age_data": "\nGetVINCoinAge: Output #0, Weight: 1433.96, Age: 1.43, Amount: 1000.00, TxTime: 1563315857...Output #1, Weight: 1424.68, Age: 1.42, Amount: 1000.00, TxTime: 1563316659...Output #2, Weight: 1424.68, Age: 1.42, Amount: 1000.00, TxTime: 1563316659...Output #3, Weight: 1433.96, Age: 1.43, Amount: 1000.00, TxTime: 1563315857...Output #4, Weight: 906.18, Age: 0.78, Amount: 1161.00, TxTime: 1563372314...Output #5, Weight: 1093583.12, Age: 2.72, Amount: 401733.00, TxTime: 1563204556...Output #6, Weight: 1424.68, Age: 1.42, Amount: 1000.00, TxTime: 1563316659...Output #7, Weight: 2678.44, Age: 2.69, Amount: 997.00, TxTime: 1563207637...Output #8, Weight: 884.72, Age: 1.42, Amount: 621.00, TxTime: 1563316659..." } |
|
|
|
I do have some free time now, so I will be reviewing through the testnet thread and getting things launched off of my tablet-top (I previously used it to mine BBP so I know it works.) |
|
|
|
BiblePay
1.4.4.3-Leisure Upgrade
- Enhance ABN/GSC tx creator to sort by coin-age first, then create the
tx (IE use lowest coin age possible).
For some reason the download links are again showing only a few kb in size. Good news though is that 1.4.4.2 has been working flawless for me on several machines, switching between ABN and Funded seamlessly and no crashes so far. Great! Ok, it's redeployed, please try now. What a beautiful afternoon, Rob I had one crash since I upgraded to 1.4.4.3, but it's been stable since it first happened. Perhaps it could have been a hiccup from the new install? Overall, things have been running very smoothly. Thanks again for your hard work!  |
|
|
|
|
Also: Pool leaderboard seems to be missing a 0/digit somewhere. Just noticed it, not sure if you are working on it currently.
|
|
|
|
Kinda worried that botnets are gaming the system, even with funded ABN.
They have 3m+ hashpower and still gain top subsidy even with a 63% hashrate penalty.
and 65+ machines
Yeah, I see the non funded guys are solving 65% of the blocks, and diff did rise above 7000 recently. I think we should let it play out for 30 days and in the mean time we can discuss it. I'm open to hearing any opinions. On one hand it just means that non funded miners are willing to take a penalty to keep mining, and it sort of points to our funded miners not having as many mining machines (which makes sense as they are different people - probably investors vs. miners). The question is, are we really seeing "bot-net" activity; I would think not really, as those are the miners that just want to mine (as compared to a nefarious group that wants to copy biblepay out to 300 machines in a school, etc). These miners do have to create pool accounts and show up in the leaderboard. So we have to think of are we creating a fair environment for everyone and are the newbies happy also. Understandable. But even for that 65% penalty, if hashrate is in the millions (6 million + to be precise) wouldn't that 65% cascade down to miners WITH abn? I am only seeing maybe a 10-12k increase in hashrate per my one miner according to the pool, (comparing to RPC because of my own abn funding.) I understand it should cascade to all miners using their own abn -- but it doesn't feel like it is calculating fully for other miners. How does it split rewards from funded abn to nonfunded, I guess is what I'm trying to ask. Edit for better example: Big miner is using funded abn to mine across a ton of rigs, produces 6 million hashpower in total but he's solving far more blocks than miners with their own ABN, so his fees get pushed up to 67%. Technically speaking, I believe the pool deducts 67% of his total hashpower and is suppose to divide it evenly to those with ABN mining -- so they can remain competitive against big networks / hash that aren't buying BBP to fund their own wallets. So, if there were 10 miners with their own ABN, and this joe comes and kicks all his miners online producing 6 million hashpower, it should take 67% of that 6 million (3.5 million?) and distribute it evenly to the 10 miners using their own ABN, which would up their hashrate by 350k each (on the pool, giving them part of the distribution correctly), ontop of what their rigs are producing. (since they're getting it from the funded miner) Is that how it works? First let me say this: The pool currently charges zero fees for normal mining (we charge 0 for everything), and additionally, zero fees for the ABN (the abn amount docked from each miner is just passed on to the rest of the pool). (Just to clarify) - I realize you arent insinuating the pool is getting any of the abn fee , just throwing that out there for others. So I think what you are saying is because the Funded ABNs are now the minority, since they have a smaller HPS in total than the pool, they should actually receive even a greater reward because the non-funded miners are getting a greater share of pool total emissions? In my thinking, I'm not sure if it'll take emissions away from the big hashpower coming from funded abn -- as non-funded miners that recieve the "bonus" would simply keep them relevant in their own mining. This gives a person with a single CPU and a wallet full of coins the ability to remain relevant if several big miners suddenly came and threw all their hashrate at once on funded miners, which would game the emission rewards from those non-funded either way. So, if three big miners came online with a total of 6 million hashrate each on funded pool miners, they would most certainly game the network in its current state, choking out small miners of rewards unless the sliding scale ratio of a "fee" were to pass the % of hashrate deducted from their mining and distributed it evenly amongst those non-funded. Altogther, with 3 miners like that they would be providing about 9 million hashpower (with 9+ million deducted) against smaller miners with 1-500k hashpower(non-funded, without the distribution) I think I see and agree with what you are saying. You are sort of saying that its irrelevant how much HPS the 'non-funded' miners are mining with, that their HPS should really be Boosted by the amount docked from the funded, because in reality, the non-funded miners are supporting the ABNs for 65% of the pool, yet they are not even 10% of the hashpower (IE its not a fair distribution of hashpower compared to the bonus they receive for their tiny contribution in HPS). So another words, we need a better algorithm to provide a bonus for the ones providing the ABNs. Something like : HPS docked from the funded miners gets ADDED to the HPS of the non-funded .... Let me look into the technical feasibility of this. Yes sir, that is exactly it. Exceptional! I hope that it can be done, because I see that miner growing with hashrate (up to 4.1 million now...) and his subsidy reward is over half of what's allotted. Even though he's docked for hashrate for not having coins in his wallet, he's still outmining everybody that is holding coins. OK, now the ABN-provider miners are receiving the hashpower docked from the funded miners. Let's see how this plays out. I made an edit to the post before yours as well, but I can see the difference already. So long as they continue to game funded-mining now, they could only raise their deducted hashrate on the sliding scale, eventually providing up to 99% of their hashrate to non-funded users based on funded blocks solved(if it can go that high,) correct? |
|
|
|
Kinda worried that botnets are gaming the system, even with funded ABN.
They have 3m+ hashpower and still gain top subsidy even with a 63% hashrate penalty.
and 65+ machines
Yeah, I see the non funded guys are solving 65% of the blocks, and diff did rise above 7000 recently. I think we should let it play out for 30 days and in the mean time we can discuss it. I'm open to hearing any opinions. On one hand it just means that non funded miners are willing to take a penalty to keep mining, and it sort of points to our funded miners not having as many mining machines (which makes sense as they are different people - probably investors vs. miners). The question is, are we really seeing "bot-net" activity; I would think not really, as those are the miners that just want to mine (as compared to a nefarious group that wants to copy biblepay out to 300 machines in a school, etc). These miners do have to create pool accounts and show up in the leaderboard. So we have to think of are we creating a fair environment for everyone and are the newbies happy also. Understandable. But even for that 65% penalty, if hashrate is in the millions (6 million + to be precise) wouldn't that 65% cascade down to miners WITH abn? I am only seeing maybe a 10-12k increase in hashrate per my one miner according to the pool, (comparing to RPC because of my own abn funding.) I understand it should cascade to all miners using their own abn -- but it doesn't feel like it is calculating fully for other miners. How does it split rewards from funded abn to nonfunded, I guess is what I'm trying to ask. Edit for better example: Big miner is using funded abn to mine across a ton of rigs, produces 6 million hashpower in total but he's solving far more blocks than miners with their own ABN, so his fees get pushed up to 67%. Technically speaking, I believe the pool deducts 67% of his total hashpower and is suppose to divide it evenly to those with ABN mining -- so they can remain competitive against big networks / hash that aren't buying BBP to fund their own wallets. So, if there were 10 miners with their own ABN, and this joe comes and kicks all his miners online producing 6 million hashpower, it should take 67% of that 6 million (3.5 million?) and distribute it evenly to the 10 miners using their own ABN, which would up their hashrate by 350k each (on the pool, giving them part of the distribution correctly), ontop of what their rigs are producing. (since they're getting it from the funded miner) Is that how it works? First let me say this: The pool currently charges zero fees for normal mining (we charge 0 for everything), and additionally, zero fees for the ABN (the abn amount docked from each miner is just passed on to the rest of the pool). (Just to clarify) - I realize you arent insinuating the pool is getting any of the abn fee , just throwing that out there for others. So I think what you are saying is because the Funded ABNs are now the minority, since they have a smaller HPS in total than the pool, they should actually receive even a greater reward because the non-funded miners are getting a greater share of pool total emissions? In my thinking, I'm not sure if it'll take emissions away from the big hashpower coming from funded abn -- as non-funded miners that recieve the "bonus" would simply keep them relevant in their own mining. This gives a person with a single CPU and a wallet full of coins the ability to remain relevant if several big miners suddenly came and threw all their hashrate at once on funded miners, which would game the emission rewards from those non-funded either way. So, if three big miners came online with a total of 6 million hashrate each on funded pool miners, they would most certainly game the network in its current state, choking out small miners of rewards unless the sliding scale ratio of a "fee" were to pass the % of hashrate deducted from their mining and distributed it evenly amongst those non-funded. Altogther, with 3 miners like that they would be providing about 9 million hashpower (with 9+ million deducted) against smaller miners with 1-500k hashpower(non-funded, without the distribution) I think I see and agree with what you are saying. You are sort of saying that its irrelevant how much HPS the 'non-funded' miners are mining with, that their HPS should really be Boosted by the amount docked from the funded, because in reality, the non-funded miners are supporting the ABNs for 65% of the pool, yet they are not even 10% of the hashpower (IE its not a fair distribution of hashpower compared to the bonus they receive for their tiny contribution in HPS). So another words, we need a better algorithm to provide a bonus for the ones providing the ABNs. Something like : HPS docked from the funded miners gets ADDED to the HPS of the non-funded .... Let me look into the technical feasibility of this. Yes sir, that is exactly it. Exceptional! I hope that it can be done, because I see that miner growing with hashrate (up to 4.1 million now...) and his subsidy reward is over half of what's allotted. Even though he's docked for hashrate for not having coins in his wallet, he's still outmining everybody that is holding coins. Edit: With this idea, it keeps the pool completely competitive even if somebody were determined to attempt to use a botnet. Even with a botnet(people will always try), the additional deducted hashing would still assist the chain and non-funded miners and boost them to a competitive level so that they couldn't game the network no matter the amount of hash they poured in. It might give them second thought to even doing such in the first place, as it would use 100% of their mining power on their end, but distributing most of it to the loyal non-funded miners based on how many funded blocks solved. In this case, it would almost push the idea that buying BBP to fund their mining would be a better choice than deciding to game funded mining. |
|
|
|
Kinda worried that botnets are gaming the system, even with funded ABN.
They have 3m+ hashpower and still gain top subsidy even with a 63% hashrate penalty.
and 65+ machines
Yeah, I see the non funded guys are solving 65% of the blocks, and diff did rise above 7000 recently. I think we should let it play out for 30 days and in the mean time we can discuss it. I'm open to hearing any opinions. On one hand it just means that non funded miners are willing to take a penalty to keep mining, and it sort of points to our funded miners not having as many mining machines (which makes sense as they are different people - probably investors vs. miners). The question is, are we really seeing "bot-net" activity; I would think not really, as those are the miners that just want to mine (as compared to a nefarious group that wants to copy biblepay out to 300 machines in a school, etc). These miners do have to create pool accounts and show up in the leaderboard. So we have to think of are we creating a fair environment for everyone and are the newbies happy also. Understandable. But even for that 65% penalty, if hashrate is in the millions (6 million + to be precise) wouldn't that 65% cascade down to miners WITH abn? I am only seeing maybe a 10-12k increase in hashrate per my one miner according to the pool, (comparing to RPC because of my own abn funding.) I understand it should cascade to all miners using their own abn -- but it doesn't feel like it is calculating fully for other miners. How does it split rewards from funded abn to nonfunded, I guess is what I'm trying to ask. Edit for better example: Big miner is using funded abn to mine across a ton of rigs, produces 6 million hashpower in total but he's solving far more blocks than miners with their own ABN, so his fees get pushed up to 67%. Technically speaking, I believe the pool deducts 67% of his total hashpower and is suppose to divide it evenly to those with ABN mining -- so they can remain competitive against big networks / hash that aren't buying BBP to fund their own wallets. So, if there were 10 miners with their own ABN, and this joe comes and kicks all his miners online producing 6 million hashpower, it should take 67% of that 6 million (3.5 million?) and distribute it evenly to the 10 miners using their own ABN, which would up their hashrate by 350k each (on the pool, giving them part of the distribution correctly), ontop of what their rigs are producing. (since they're getting it from the funded miner) Is that how it works? First let me say this: The pool currently charges zero fees for normal mining (we charge 0 for everything), and additionally, zero fees for the ABN (the abn amount docked from each miner is just passed on to the rest of the pool). (Just to clarify) - I realize you arent insinuating the pool is getting any of the abn fee , just throwing that out there for others. So I think what you are saying is because the Funded ABNs are now the minority, since they have a smaller HPS in total than the pool, they should actually receive even a greater reward because the non-funded miners are getting a greater share of pool total emissions? In my thinking, I'm not sure if it'll take emissions away from the big hashpower coming from funded abn -- as non-funded miners that recieve the "bonus" would simply keep them relevant in their own mining. This gives a person with a single CPU and a wallet full of coins the ability to remain relevant if several big miners suddenly came and threw all their hashrate at once on funded miners, which would game the emission rewards from those non-funded either way. So, if three big miners came online with a total of 6 million hashrate each on funded pool miners, they would most certainly game the network in its current state, choking out small miners of rewards unless the sliding scale ratio of a "fee" were to pass the % of hashrate deducted from their mining and distributed it evenly amongst those non-funded. Altogther, with 3 miners like that they would be providing about 9 million hashpower (with 9+ million deducted) against smaller miners with 1-500k hashpower(non-funded, without the distribution) |
|
|
|
Kinda worried that botnets are gaming the system, even with funded ABN.
They have 3m+ hashpower and still gain top subsidy even with a 63% hashrate penalty.
and 65+ machines
Yeah, I see the non funded guys are solving 65% of the blocks, and diff did rise above 7000 recently. I think we should let it play out for 30 days and in the mean time we can discuss it. I'm open to hearing any opinions. On one hand it just means that non funded miners are willing to take a penalty to keep mining, and it sort of points to our funded miners not having as many mining machines (which makes sense as they are different people - probably investors vs. miners). The question is, are we really seeing "bot-net" activity; I would think not really, as those are the miners that just want to mine (as compared to a nefarious group that wants to copy biblepay out to 300 machines in a school, etc). These miners do have to create pool accounts and show up in the leaderboard. So we have to think of are we creating a fair environment for everyone and are the newbies happy also. Understandable. But even for that 65% penalty, if hashrate is in the millions (6 million + to be precise) wouldn't that 65% cascade down to miners WITH abn? I am only seeing maybe a 10-12k increase in hashrate per my one miner according to the pool, (comparing to RPC because of my own abn funding.) I understand it should cascade to all miners using their own abn -- but it doesn't feel like it is calculating fully for other miners. How does it split rewards from funded abn to nonfunded, I guess is what I'm trying to ask. Edit for better example: Big miner is using funded abn to mine across a ton of rigs, produces 6 million hashpower in total but he's solving far more blocks than miners with their own ABN, so his fees get pushed up to 67%. Technically speaking, I believe the pool deducts 67% of his total hashpower and is suppose to divide it evenly to those with ABN mining -- so they can remain competitive against big networks / hash that aren't buying BBP to fund their own wallets. So, if there were 10 miners with their own ABN, and this joe comes and kicks all his miners online producing 6 million hashpower, it should take 67% of that 6 million (3.5 million?) and distribute it evenly to the 10 miners using their own ABN, which would up their hashrate by 350k each (on the pool, giving them part of the distribution correctly), ontop of what their rigs are producing. (since they're getting it from the funded miner) Is that how it works? |
|
|
|
|
Kinda worried that botnets are gaming the system, even with funded ABN.
They have 3m+ hashpower and still gain top subsidy even with a 63% hashrate penalty.
and 65+ machines
|
|
|
|
I wonder if both cases of our windows 10 crash came from restored wallets with orphaned CPKs?
that's a possibility! I have dual-mining set up and configured, funded ABN kicked right on (because of low weight obviously) So I will watch for the transition from funded to non-funded when my weight re-ups. CPK is created (exec cpk nickname) in RPC, how can I keep a track of the address for that? |
|
|
|
Ok, and one thing that appears weird in your sentgsc report is you don't show any ABNs over the last 7 days. But I believe you said you were testing/spending ABNs. Was this wallet imported with non-conventional commands, or is it the original wallet? Do you have a CPK? Did you 'exec cpk your_nickname' (as I dont see you in the leaderboard). Or long shot, did you join pog and then unjoin, and maybe unjoin your cpk? The sentgsc report uses the CPK to find ABNs and GSCs. (Also, do you have a Christian-Public-Key) set up in your address book? Finally, one more clue - if you go to coin control (click Send Money | Coin Control) - if its not enabled you can enable coin control in Settings. Please see your coins listed by address. Notice how your 397,179 coin has a depth of (most likely 1) now? That means it was spent on something. You should be able to find out on what - but if you cant I can help you with RPC commands, etc. EDIT: Could you please paste your public Christian-public-key receive address? Let me do some reporting from the pool side? I see what you're saying here and I might know the issue actually. I did create a CPK nickname, and join POG before. Since then I've unjoined POG and I no longer see my CPK, or many other of my recieve addresses in my wallet anymore. I did import my wallet from a backup at one point because of a corrupted wallet.dat during an upgrade. So, it appears that my wallet.dat is still recieving transmissions from old recieving keys that are most likely tagged in the wallet itself, but not showing on QT. (I only have 1 recieving key as of now and that was the one created to recieve coin from SouthXchange. Ok, that explains the wonkiness then. Sorry if I came across as harsh, I just want to make sure people don't get the impression we are hiding any BBP in hidden ABNs or doing anything funny here . So, in your case, I highly recommend backing up wallet.dat, creating a brand new wallet.dat, then copy the receive address key from the new one to the clipboard, then send all your balance to your new wallet, and create a brand new exec cpk nickname (you dont necessarily have to join pog)- but this would ensure you have a good CPK address book entry tied to one CPK in the wallet. This is because it would be highly questionable for us to test ABN and edge cases with a wallet that has been modified etc. I was thinking this is the most simple fix. I will try it out! As for sending to a new wallet, if I created a mobile (android) wallet and wrote the phrase down, can I go into my phone and get the (new) wallet.dat from there and move it to my PC? No, the mobile wallet is in a different format, plus its easier to just work with the files right in front of you (in contrast to sending them over the network etc). EDIT: You can do this by closing BBP, renaming wallet.dat to wallet.dat_old, starting bbp, get the new key to the clipboard, close bbp, copy wallet.dat to wallet.dat_new, rename wallet.dat_old back to wallet.dat, starting, send the money to your key by pasting the clipboard value, close bbp, and move to your new wallet.dat, and restart. Or you can send the BBP to your mobile wallet, and delete your old wallet.dat file and then send it from your mobile back to your PC. I went with the first method, hiding the old wallet.dat and then using a new one. Encrypted and backed up, all coins stored on new wallet. What's the best method to insure I get a CPK? |
|
|
|
Made me smile. God bless all of them. |
|
|
|
Ok, and one thing that appears weird in your sentgsc report is you don't show any ABNs over the last 7 days. But I believe you said you were testing/spending ABNs. Was this wallet imported with non-conventional commands, or is it the original wallet? Do you have a CPK? Did you 'exec cpk your_nickname' (as I dont see you in the leaderboard). Or long shot, did you join pog and then unjoin, and maybe unjoin your cpk? The sentgsc report uses the CPK to find ABNs and GSCs. (Also, do you have a Christian-Public-Key) set up in your address book? Finally, one more clue - if you go to coin control (click Send Money | Coin Control) - if its not enabled you can enable coin control in Settings. Please see your coins listed by address. Notice how your 397,179 coin has a depth of (most likely 1) now? That means it was spent on something. You should be able to find out on what - but if you cant I can help you with RPC commands, etc. EDIT: Could you please paste your public Christian-public-key receive address? Let me do some reporting from the pool side? I see what you're saying here and I might know the issue actually. I did create a CPK nickname, and join POG before. Since then I've unjoined POG and I no longer see my CPK, or many other of my recieve addresses in my wallet anymore. I did import my wallet from a backup at one point because of a corrupted wallet.dat during an upgrade. So, it appears that my wallet.dat is still recieving transmissions from old recieving keys that are most likely tagged in the wallet itself, but not showing on QT. (I only have 1 recieving key as of now and that was the one created to recieve coin from SouthXchange. Ok, that explains the wonkiness then. Sorry if I came across as harsh, I just want to make sure people don't get the impression we are hiding any BBP in hidden ABNs or doing anything funny here . So, in your case, I highly recommend backing up wallet.dat, creating a brand new wallet.dat, then copy the receive address key from the new one to the clipboard, then send all your balance to your new wallet, and create a brand new exec cpk nickname (you dont necessarily have to join pog)- but this would ensure you have a good CPK address book entry tied to one CPK in the wallet. This is because it would be highly questionable for us to test ABN and edge cases with a wallet that has been modified etc. I was thinking this is the most simple fix. I will try it out! As for sending to a new wallet, if I created a mobile (android) wallet and wrote the phrase down, can I go into my phone and get the (new) wallet.dat from there and move it to my PC? |
|
|
|
Ok, and one thing that appears weird in your sentgsc report is you don't show any ABNs over the last 7 days. But I believe you said you were testing/spending ABNs. Was this wallet imported with non-conventional commands, or is it the original wallet? Do you have a CPK? Did you 'exec cpk your_nickname' (as I dont see you in the leaderboard). Or long shot, did you join pog and then unjoin, and maybe unjoin your cpk? The sentgsc report uses the CPK to find ABNs and GSCs. (Also, do you have a Christian-Public-Key) set up in your address book? Finally, one more clue - if you go to coin control (click Send Money | Coin Control) - if its not enabled you can enable coin control in Settings. Please see your coins listed by address. Notice how your 397,179 coin has a depth of (most likely 1) now? That means it was spent on something. You should be able to find out on what - but if you cant I can help you with RPC commands, etc. EDIT: Could you please paste your public Christian-public-key receive address? Let me do some reporting from the pool side? I see what you're saying here and I might know the issue actually. I did create a CPK nickname, and join POG before. Since then I've unjoined POG and I no longer see my CPK, or many other of my recieve addresses in my wallet anymore. I did import my wallet from a backup at one point because of a corrupted wallet.dat during an upgrade. So, it appears that my wallet.dat is still recieving transmissions from old recieving keys that are most likely tagged in the wallet itself, but not showing on QT. (I only have 1 recieving key as of now and that was the one created to recieve coin from SouthXchange. |
|
|
|
Good morning, Rob! So far no crashes on the new client, however my ABN has all been eaten and there are no blocks on pool with my name to show proof of it. exec sentgsc also shows nothing. This is what I see in RPC.
09:56:24

getmininginfo
09:56:24

{
"blocks": 131877,
"currentblocksize": 3924,
"currentblocktx": 2,
"difficulty": 4693.118496139644,
"errors": "",
"pooledtx": 2,
"chain": "main",
"genproclimit": 7,
"networkhashps": 546824.3943490735,
"hashps": 114236.3860311637,
"minerstarttime": "07-14-2019 23:54:02",
"hashcounter": 5599995588,
"pooledtx": 2,
"chain": "main",
"biblepay-generate": true,
"poolinfo1": "Pool mining with eyeseven; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ",
"poolinfo2": "RMC_07-15-2019 13:53:34; RMC_07-15-2019 13:53:38; RMC_07-15-2019 13:53:43; RMC_07-15-2019 13:54:06; RMC_07-15-2019 13:53:43; RMC_07-15-2019 13:53:37; RMC_07-15-2019 13:56:14; ",
"poolinfo3": "",
"abninfo": "Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; ",
"gsc_errors": "low abn weight 0",
"poolmining": true,
"pool_url": "https://pool.biblepay.org",
"required_abn_weight": 125000
}
09:56:27

exec sentgsc
09:56:27

{
"Total": 0
}
09:56:30

exec getabnweight
09:56:30

{
"Command": "getabnweight",
"version": 2.5,
"weight": 36073.44414351852,
"total_required": 401154
}
09:56:37

exec createabn 125000 1
09:56:37

{
"Command": "createabn",
"xml": "",
"err": "Sorry, your coin-age is too low to create an anti-botnet transaction.",
"age_data": "0.9870(0.00),194171.3572(83596.91),2507.4500(7426.55),558.0000(1512.18),1000.0000(713.53),1000.0000(722.49),534.8400(3184.28),693.0000(442.74),1000.0000(4717.65),1000.0000(4715.35),0.9914(0.00),194712.4421(131455.39),1000.0000(2714.46),",
"vin_coin_age_data": "\nGetVINCoinAge: ",
"coin_age_data_pre_select": "1000.0000(2.74)=[2738.39] depth=581, <ROW>1000.0000(0.75)=[747.87] depth=160, <ROW>5.2559(7.17)=[35.87] depth=1525, <ROW>0.9840(4.19)=[0.00] depth=890, <ROW>1000.0000(16.52)=[16524.72] depth=3459, <ROW>969.1900(12.99)=[12583.46] depth=2736, <ROW>0.9781(0.01)=[0.00] depth=0, <ROW>397178.0678(0.01)=[3443.13] depth=0, <ROW>",
"total_audited_weight": 0,
"tx_create_error": "Sorry, your coin-age is too low to create an anti-botnet transaction."
}
1) Please paste any long command outputs within code tags - thanks. I just added them above for an example. 2) Other than ABNs spending coin-age, and GSCs spending coin-age, you can also spend coin age by Spending BBP. Notice how your 397,178 was spent one block ago. What was it spent on? (This lowered your coin age down to 36k). Apologies for the code tags! I'm not sure what it was spent on, my balance never leaves my wallet or moves in any way shape or form unless its mined coins moving from pool to my wallet. |
|
|
|
Good morning, Rob! So far no crashes on the new client, however my ABN has all been eaten and there are no blocks on pool with my name to show proof of it. exec sentgsc also shows nothing. This is what I see in RPC. 09:56:24  getmininginfo 09:56:24  { "blocks": 131877, "currentblocksize": 3924, "currentblocktx": 2, "difficulty": 4693.118496139644, "errors": "", "pooledtx": 2, "chain": "main", "genproclimit": 7, "networkhashps": 546824.3943490735, "hashps": 114236.3860311637, "minerstarttime": "07-14-2019 23:54:02", "hashcounter": 5599995588, "pooledtx": 2, "chain": "main", "biblepay-generate": true, "poolinfo1": "Pool mining with eyeseven; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ", "poolinfo2": "RMC_07-15-2019 13:53:34; RMC_07-15-2019 13:53:38; RMC_07-15-2019 13:53:43; RMC_07-15-2019 13:54:06; RMC_07-15-2019 13:53:43; RMC_07-15-2019 13:53:37; RMC_07-15-2019 13:56:14; ", "poolinfo3": "", "abninfo": "Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; Unable to Create ABN: Sorry, your coin-age is too low to create an anti-botnet transaction.; ", "gsc_errors": "low abn weight 0", "poolmining": true, "pool_url": " https://pool.biblepay.org", "required_abn_weight": 125000 } 09:56:27  exec sentgsc 09:56:27  { "Total": 0 } 09:56:30  exec getabnweight 09:56:30  { "Command": "getabnweight", "version": 2.5, "weight": 36073.44414351852, "total_required": 401154 } 09:56:37  exec createabn 125000 1 09:56:37  { "Command": "createabn", "xml": "", "err": "Sorry, your coin-age is too low to create an anti-botnet transaction.", "age_data": "0.9870(0.00),194171.3572(83596.91),2507.4500(7426.55),558.0000(1512.18),1000.0000(713.53),1000.0000(722.49),534.8400(3184.28),693.0000(442.74),1000.0000(4717.65),1000.0000(4715.35),0.9914(0.00),194712.4421(131455.39),1000.0000(2714.46),", "vin_coin_age_data": "\nGetVINCoinAge: ", "coin_age_data_pre_select": "1000.0000(2.74)=[2738.39] depth=581, <ROW>1000.0000(0.75)=[747.87] depth=160, <ROW>5.2559(7.17)=[35.87] depth=1525, <ROW>0.9840(4.19)=[0.00] depth=890, <ROW>1000.0000(16.52)=[16524.72] depth=3459, <ROW>969.1900(12.99)=[12583.46] depth=2736, <ROW>0.9781(0.01)=[0.00] depth=0, <ROW>397178.0678(0.01)=[3443.13] depth=0, <ROW>", "total_audited_weight": 0, "tx_create_error": "Sorry, your coin-age is too low to create an anti-botnet transaction." } |
|
|
|
If there was something I could be curious about, it may be ABN randomly eaten out of my wallet (pool confirms that I didn't have a block found recently) as my weight went from 800k to 400k (not a mining issue, but just curious as to where it went) Is it a part of ABN funding for the funded miners?
When you pool mine, a pool miner could actually use your ABN to solve their block. (So it wouldnt be that you solved the pool block). The only thing I can suggest is if you ask us to write a Spent ABN report, then you could see where they were used. Do you want us to write that? Sure, could it be emailed? Also, it's for the sake of curiosity so don't let it impede with any important matters. I just realized we have a report in the wallet that shows sent GSC transmissions for one day (this shows donations, POG points, Healing points) and used coin age on GSC transmissions. I just modified it to report for the last 7 days on both GSC transmissions and ABN hits. Then you can see anything that consumes coin age, the height, the date and the txid. You can also test the new version at the same time; please give us about 30 mins to release it. I see for example today my ABN was used to solve block 131665 in the pool - but the solver was murof.core7. What you can do is get the height from the 'exec sentgsc' report (when its released) and then compare it to the blocks history report in the pool. OK, windows 1.4.4.2c is out there, please test it: exec sentgsc To see the last 7 days of GSCs & ABNs. Also, please test the dual mining feature again. Also please ensure no crash occurs in windows 10. Updating to 1.4.4.2c now, my miner did experience another crash even in litemode. Will let you know how it goes with the new release. |
|
|
|
If there was something I could be curious about, it may be ABN randomly eaten out of my wallet (pool confirms that I didn't have a block found recently) as my weight went from 800k to 400k (not a mining issue, but just curious as to where it went) Is it a part of ABN funding for the funded miners?
When you pool mine, a pool miner could actually use your ABN to solve their block. (So it wouldnt be that you solved the pool block). The only thing I can suggest is if you ask us to write a Spent ABN report, then you could see where they were used. Do you want us to write that? Sure, could it be emailed? Also, it's for the sake of curiosity so don't let it impede with any important matters. |
|
|
|
|
