Its Doom, Hamputer, Vader and Vader 2. Vader and Vader 2 are the same machine, one worker is funded and then other not. Thanks!
Oh OK that explains it! Yeah, I think the issue is this: The pool can only support One funding type per user at a given time. So all your active workers have to be in funded mode at the same time (or they work against the non-funded). They are allowed to switch to non-funded, but then the non-funded work against the funded. (You can accomplish this synchronization by sending the wallet.dat out to the miners). This limitation will be removed very soon (IE within a week) when we get the new protoversion out. Are you trying to mine in funded and non funded at the same time across workers? |
|
|
|
This morning I woke up to find that half of my miners that were using funded ABN had stopped mining. When I ran getmininginfo, it said that I had received a stale block, please wait. Restarting the Bible pay client did not seem to resolve this and it is still waiting. Any idea what could be causing this? Thanks!
No need to restart them ; this is normal. I do see you mining, so it probably resolved itself within 5 minutes. You can check the log to get the timestamps if you want to ensure this didnt happen more than 10 minutes in total per night. Seems to still be happening, here is my latest getmininginfo: "poolinfo5": "Internal ABN: Invalid 1563554225; ", "abninfo": "Received a stale block from the pool... Please wait... ; Received a stale block from the pool... Please wait... ; Received a stale block from the pool... Please wait... ; Received a stale block from the pool... Please wait... ; ", And here is the most recent entry from my debug log: IsValidForPayment - Sanctuary 157.230.152.110:40000 running old protoversion 70734, required version 70735.000000 ContextualCheckBlockHeader::FAILED incorrect proof of work at 132693, block.nbits 459722672.000000, next work 470301215.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132693, block.nbits 459722672.000000, next work 470301215.000000 (code 16) Hmm, I see you mining on 3 machines. Do me a favor and click on the drill in from the leaderboard; the only 2 that seem to be down is Hamputer & Vader. Is it one of those or are those 2 down? |
|
|
|
This morning I woke up to find that half of my miners that were using funded ABN had stopped mining. When I ran getmininginfo, it said that I had received a stale block, please wait. Restarting the Bible pay client did not seem to resolve this and it is still waiting. Any idea what could be causing this? Thanks!
No need to restart them ; this is normal. I do see you mining, so it probably resolved itself within 5 minutes. You can check the log to get the timestamps if you want to ensure this didnt happen more than 10 minutes in total per night. |
|
|
|
is this ok?
User Name Miner Name Hashes Per Second Shares Reported
capulo capulo_bur_f 67194.26 9 7/18/2019 4:14:13 PM
capulo capulo_x6_f 181923.8 19 7/18/2019 4:16:25 PM
leaderboard:
capulo 26220.18 28 7/18/2019 4:16:25 PM 2 0 1
so in home or wallet i have about 260k hps but in leaderboard ~20k
Yeah, the _x6 is showing an issue on 32 threads out of 40, out of curiosity which version is the miner? it has latest what i got with wget https://biblepay.org/biblepayd-evo-x86_64-pc-linux-gnu.tar.gz{
"version": 1040403,
"protocolversion": 70735,
"walletversion": 61000,
"balance": 0.00000000,
"privatesend_balance": 0.00000000,
"blocks": 132674,
"timeoffset": 0,
"connections": 9,
"proxy": "",
"difficulty": 1430.504774897681,
"testnet": false,
"keypoololdest": 1563437775,
"keypoolsize": 999,
"paytxfee": 0.00000000,
"relayfee": 0.01000000,
"errors": ""
}
{
"blocks": 132674,
"currentblocksize": 1000,
"currentblocktx": 0,
"difficulty": 1430.504774897681,
"errors": "",
"pooledtx": 0,
"chain": "main",
"genproclimit": 40,
"networkhashps": 581017.2917500157,
"hashps": 203525.6342764059,
"minerstarttime": "07-18-2019 20:34:24",
"hashcounter": 8387056927,
"pooledtx": 0,
"chain": "main",
"biblepay-generate": true,
"poolinfo1": "BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ",
"poolinfo2": "Submitting Solution 07-19-2019 08:00:46; Submitting Solution 07-19-2019 07:59:18; Submitting Solution 07-19-2019 07:59:21; Submitting Solution 07-19-2019 07:59:17; Submitting Solution 07-19-2019 07:59:17; Submitting Solut
ion 07-19-2019 07:59:20; ",
"poolinfo3": "",
"poolinfo5": "",
"abninfo": "Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f
82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c1098120331
d1bf5b50fa48a; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN 9f39b297ea2e1648157b7faad35a362b7b824685ea0b9d3ba74840468b340584; Mining with funded Valid ABN f91
f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0
ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f9
1f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e
0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN 50398ca35b713ed82709f8fd636c6f387da19cbb078ef29c09b40a1cf06cea70; Mining with funded Valid ABN f
91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39
e0ff4efdf7641c00; Mining with funded Valid ABN 50398ca35b713ed82709f8fd636c6f387da19cbb078ef29c09b40a1cf06cea70; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN
f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c109812
0331d1bf5b50fa48a; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN 50398ca35b713ed82709f8fd636c6f387da19cbb078ef29c09b40a1cf06cea70; Mining with funded Valid ABN
f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c1098120331d1bf5b50fa48a; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a
39e0ff4efdf7641c00; Mining with funded Valid ABN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c1098120331d1bf5b50fa48a; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid AB
N f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b88a39e0ff4efdf7641c00; Mining with funded Valid ABN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c1098
120331d1bf5b50fa48a; Mining with funded Valid ABN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c1098120331d1bf5b50fa48a; Mining with funded Valid ABN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c1098120331d1bf5b50fa48a; Mining with funded Valid A
BN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c1098120331d1bf5b50fa48a; Mining with funded Valid ABN 1c869937e61c7e8cafd5f07bb6e5b2e9e91940f1c1098120331d1bf5b50fa48a; Mining with funded Valid ABN f91f82eef998100dcdfcdb694f8989d2a1726581f8b8
8a39e0ff4efdf7641c00; ",
"gsc_errors": "",
"poolmining": true,
"pool_url": "https://pool.biblepay.org",
"required_abn_weight": 125000
}
Ok, looking at it a little closer, now that we have had time to "fill in the potholes", I see on my end you are mining at 200K on the _x6 and 60K on the _bur, which is pretty close to what you show. The reason the board has you at 70K is the 50% debit in HPS for being funded. 260 - 130K = 70KHPS. But I will add : We are close to releasing a more advanced protocol, and when this is released you will be able to drill in and see the summary per miner and see any missing shares per core which will be nice, but you are currently mining at over 90% efficiency (I only show a couple missing shares on 2 cores). |
|
|
|
is this ok?
User Name Miner Name Hashes Per Second Shares Reported
capulo capulo_bur_f 67194.26 9 7/18/2019 4:14:13 PM
capulo capulo_x6_f 181923.8 19 7/18/2019 4:16:25 PM
leaderboard:
capulo 26220.18 28 7/18/2019 4:16:25 PM 2 0 1
so in home or wallet i have about 260k hps but in leaderboard ~20k
Yeah, the _x6 is showing an issue on 32 threads out of 40, out of curiosity which version is the miner? |
|
|
|
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/ogu3qq1) Thats not a crash - an assertion means it was a handled exit - the message shows the assertion. 2) The message means you have a corrupted block database. (Your evodb is corrupted). 3) The only way around this is to start with -erasechain=1. 4) This is caused by Ungracefully Exiting the wallet. I highly recommend you do not kill BiblePay from the command line or task manager, as this will corrupt the database files and could corrupt your wallet.dat. Only exit the wallet with the File | Exit command. 5) If you start with a locked wallet, you have to give it time to transition from having a bad cached ABN (from a locked wallet) to a good ABN. 6) If anyone else has an inconsistency in the miner please post and we will fix it immediately. So far I don't see any bug to be fixed except the log spam should not be that frequent. |
|
|
|
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..."
}
1) It looks like the pool communication is fine - the wallet is deliberately not communicating with the pool further because it thinks the wallet is locked. 2) Can you please look in the log, and get the earliest timestamp of "Sorry, the wallet must be unlocked" and the latest? Can you see if this has been happening for more than 10 minutes? 3) Does the problem eventually go away by itself and it resumes mining? Can you leave it in this state for at least 20 minutes to see if it recovers? I realize your wallet is not locked, but it can take up to 7 extra minutes after the last error for the wallet to clear errors and retry creation of an abn. Even though your RPC shows that you have 1mil weight, the miner won't know that until 7 minutes passes and it clears the buffers. EDIT: Please don't delete the log; if this is not self resolved, can you please e-mail me the log? |
|
|
|
|
** Pool.biblepay.org **
Today I'm looking at the state of the pool, funded miners vs non funded and hashrates and investigating areas where we might improve the pool, and its doing relatively well, I would say its currently meeting the objective by more than 90%, but there are a couple areas that can use some improvement. One area is the edge case where miners have multiple machines, each using a funded and non-funded workerid and when they switch from funded to non-funded we have a lag (and some confusion). So we will be addressing that with a better communication mechanism per thread in the near future (we will be adding some fields to biblepaycore to handle this). (The other is internally handling this in the pool). So what this means is soon we will have a leisure upgrade with the extended fields, and after a certain number of days the pool will enforce the new protocol version.
** Cameroon One **
Yesterday I had a conference call with Cameroon, and gave Todd the director, a demo of testnet. We went over the API, and made a few changes to the integration in testnet and we set a go-live target of August 17th 2019. We both agreed to push for this in each of our respective areas. Cameroon IT is now working with us to make the deadline. They are working on exposing children BIOs to the internet and exposing the API by next month so we can do a test in Prod.
|
|
|
|
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.) The windows download link is in the OP post; it would be good to run testnet from a machine that has crashed for you before; then you can mine against prod with that machine using the testnet binary. But yes, you can start with any machine you want to get acclimated to testnet also. |
|
|
|
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!  Thanks, and thanks for all your help! We will eventually need to bite the bullet anyway and do full stack traces across all platforms, so at your convenience, please sync up in testnet and test mining against prod and then make a post there, and I will reply with instructions on how to generate a stack trace in windows using our testnet-develop version. (Once a stack trace is generated it will give us the exact line of code that needs fixed to prevent the crash in the future version). |
|
|
|
*** BIBLEPAY QUICK START GUIDE ***
Use this guide to get started with biblepay! (Similar to unpacking a new lawnmower): https://wiki.biblepay.org/Quick_Start- I see we picked up a few new users over the last 24 hours! We are now on our way towards the top 500! Congratulations!
|
|
|
|
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. |
|
|
|
|
I've been getting a lot of complaints about the cloak feature in the pool, so I think we need to remove it.
(Some users think the highest rewarded users are non-funded ABNs).
I think its better to error on the side of transparency in the pool than give the impression we are hiding something.
First I will uncloak the users, then we will remove the checkbox in the user account settings.
|
|
|
|
|
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).
|
|
|
|
Also: Pool leaderboard seems to be missing a 0/digit somewhere. Just noticed it, not sure if you are working on it currently.
After updating the pool code, some other things needed updated over the last few hours; finally I believe these are resolved. Now please check the non funded vs funded, and they should be correct now. |
|
|
|
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. |
|
|
|
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. |
|
|
|
shorty reported in Discord: I thought the latest wallet would not consolidate all coins when a new block was found?
I had more than 430k ABN, divided into 150k bills, and all were swept after pool found a block [funded by me]
Shorty's ABN funding tx in block 132094 http://explorer.biblepay.org:3001/api/getrawtransaction?txid=964dc8190d4645085dce08f55594b9293d465b08728c0754ec4264e58b720036&decrypt=1Contains many VINs, many of them are 150k bankroll denominations he prepared some time ago: Example of one: ...
{
"txid": "3fcadb7d380bbc59a436e6e4f4690ad4631afbac8d983bcec64c5a9e669ecee0",
"vout": 16,
"scriptSig": {
"asm": "3045022100e2927cbe6ccc5512b8b2a29aae170141cdbf81b51ef19fcf404e510a904f7a06022062729303a3de816b88021b8557c7631bdb645a94fb450dca2a4448d1c2bf71c7[ALL] 021e1dd50712f9662f2c5ef37286f1fe8f761663b32ac5529ce6c49486e6b606ad",
"hex": "483045022100e2927cbe6ccc5512b8b2a29aae170141cdbf81b51ef19fcf404e510a904f7a06022062729303a3de816b88021b8557c7631bdb645a94fb450dca2a4448d1c2bf71c70121021e1dd50712f9662f2c5ef37286f1fe8f761663b32ac5529ce6c49486e6b606ad"
},
"sequence": 4294967294
},
...
Looking at 3fcadb7d380bbc59a436e6e4f4690ad4631afbac8d983bcec64c5a9e669ecee0 http://explorer.biblepay.org:3001/api/getrawtransaction?txid=3fcadb7d380bbc59a436e6e4f4690ad4631afbac8d983bcec64c5a9e669ecee0&decrypt=1So he asks if this is correct behavior (sweeping way more coins for ABN than the ones necessary). EDIT: I saw those coins had low age so it might be correct that all of them were used for the ABN tx, but still the coins in all have far more weight than necessary. Let me analyze this in great detail. So I took a look at this in great detail. First of all, I just want to say this particular issue is related entirely to our coin selection algo on the input side of the ABN (the chooser that chooses coin age to spend in the GSC or in the ABN). The enhancement we added yesterday was related to creation of bankroll denominations for 'change' (IE creating more small outputs when we create GSC transmissions). So for example, on the output side, if the wallet needs to break a 1 million BBP coin, as of yesterday, it will break this up automatically into 10 outputs of 100K each, so that each will age, and give the user more individual future inputs. But lets hone in on this particular issue from Shorty: The inputs chosen for an ABN. The issue is BiblePay - the way it is today - can choose any coin in the wallet, because the default sort order is not based on coin-age. So the crux of this boils down to this: We should sort the entire wallet by coin*age ascending first when creating GSCs or ABNs. That would give the GSC/ABN creator the ability to use up the smallest coin age coins first, and never skip by and spend a big coin (or a coin with high coin age). I'll prioritize this change next, and we will make the wallet sort by coin age when choosing coins for ABN or for GSC. |
|
|
|
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? |
|
|
|
shorty reported in Discord: I thought the latest wallet would not consolidate all coins when a new block was found?
I had more than 430k ABN, divided into 150k bills, and all were swept after pool found a block [funded by me]
Shorty's ABN funding tx in block 132094 http://explorer.biblepay.org:3001/api/getrawtransaction?txid=964dc8190d4645085dce08f55594b9293d465b08728c0754ec4264e58b720036&decrypt=1Contains many VINs, many of them are 150k bankroll denominations he prepared some time ago: Example of one: ...
{
"txid": "3fcadb7d380bbc59a436e6e4f4690ad4631afbac8d983bcec64c5a9e669ecee0",
"vout": 16,
"scriptSig": {
"asm": "3045022100e2927cbe6ccc5512b8b2a29aae170141cdbf81b51ef19fcf404e510a904f7a06022062729303a3de816b88021b8557c7631bdb645a94fb450dca2a4448d1c2bf71c7[ALL] 021e1dd50712f9662f2c5ef37286f1fe8f761663b32ac5529ce6c49486e6b606ad",
"hex": "483045022100e2927cbe6ccc5512b8b2a29aae170141cdbf81b51ef19fcf404e510a904f7a06022062729303a3de816b88021b8557c7631bdb645a94fb450dca2a4448d1c2bf71c70121021e1dd50712f9662f2c5ef37286f1fe8f761663b32ac5529ce6c49486e6b606ad"
},
"sequence": 4294967294
},
...
Looking at 3fcadb7d380bbc59a436e6e4f4690ad4631afbac8d983bcec64c5a9e669ecee0 http://explorer.biblepay.org:3001/api/getrawtransaction?txid=3fcadb7d380bbc59a436e6e4f4690ad4631afbac8d983bcec64c5a9e669ecee0&decrypt=1So he asks if this is correct behavior (sweeping way more coins for ABN than the ones necessary). EDIT: I saw those coins had low age so it might be correct that all of them were used for the ABN tx, but still the coins in all have far more weight than necessary. Let me analyze this in great detail. |
|
|
|
|
Show Posts
