With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse? Thanks!
So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp). If they are in team bbp, we do not have a minimum rac. There should be no minimum coin*age reqt either. The only minimum I am aware of is if a person generates less than .005% of the GSC contract - then due to rounding, our payment system leaves off the payment (because it considers it zero). But in this case you should still see some RAC in the leaderboard. The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row. Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0. Thanks! You can try to force out an 'exec sendgscc wcg' and see if it gives an error? If you are still not in the leaderboard please send me the exec rac output. It might be that you don't have enough coin age for .005% of the rac. 09:06:17  sendgscc wcg 09:06:17  { "Error!": "CreateGSCTransmission::Fail::(Create Transaction) Insufficient funds.", "Warning!": "WARNING! PODC is using 0.99% of your coin age. This means your RAC will be reduced, resulting in a lower PODC reward. (Team BiblePay requires 62999 in coin-age, while Non-BiblePay teams require 806996.) " } Can you paste your exec rac so I can look at the internal wallet calcs and see if there is a limit? |
|
|
|
With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse? Thanks!
So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp). If they are in team bbp, we do not have a minimum rac. There should be no minimum coin*age reqt either. The only minimum I am aware of is if a person generates less than .005% of the GSC contract - then due to rounding, our payment system leaves off the payment (because it considers it zero). But in this case you should still see some RAC in the leaderboard. The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row. Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0. Thanks! Oh btw, be sure you have coins in your CPK address. You can do that with 'exec bankroll qty denom'. Then let them age. You can see how much is in there in exec rac, and compare that balance to your total wallet balance, etc. |
|
|
|
Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)
My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.
This release for ( trying to ) block gpu is just a bunch of crap ...
"bunch of crap": -> No, I'm afraid you don't know what you are talking about. Could you provide one piece of evidence of a way to get around it with a gpu? Or, you can surely win the 2 mil bounty if you care to? Please explain. All I'm asking for is for you to explain your position in detail. I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint). For sure I'm complaining ! With the last release I can't anymore use my Ryzen 2600x ! You're trying to lock gpus, it's fine I'm correct with that. But your modification is too restrictive, "high" cpu hashrate is locked too ! And there's a BIG difference between a Ryzen doing something like 190kHs and a GTX 1070 doing 7MHs no ? Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)
My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.
This release for ( trying to ) block gpu is just a bunch of crap ...
"bunch of crap": -> No, I'm afraid you don't know what you are talking about. Could you provide one piece of evidence of a way to get around it with a gpu? Or, you can surely win the 2 mil bounty if you care to? Please explain. All I'm asking for is for you to explain your position in detail. I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint). @Rob: his problem is NOT a hypothetical ability to mine with GPU, but a now existing INability to mine with a high power CPU. @whyme: why don't you redirect your ryzen against WCG and do some PODC instead of simple "heat mining"?  Just finding 1 solo block per day pays more than WCG. And it's winter here, so just doing heat is fine. Just to clarify my position, I'm not against you complaining  ... I was under the impression your position was that our GPU restricition was fake. I just want to clarify that our GPU restriction has been tested from 2017-2018 and it works fine (the logic is sound). So your talking more about the heat mining environment itself not working, OK, I will look at that now. Sorry to ruffle your feathers. Checking. We are here to provide a quality environment for the miners- we will not tolerate broken software; if something is broken I was not aware of it. I'll run each of the miners on my windows machine first. So far I have only tested nomp mining on my ryzen windows box and I found a couple problems. The pool difficulty was not set correctly for pobh 2.0, and there was an issue where we complain too often about invalid shares. These things have just been adjusted. Its not 'perfect' yet but it appears to be working now (that is pool mining against nomp.biblepay.org). If you have problems, try increasing the thread count with "-t40" for example in the command line string. Then wait a while and look at the nomp leaderboard. When time permits Ill try to hone in on lowering the reject rate to be more like 90% like we had in 1.0. In the mean time Ill check out solo mining against the wallet using the external miner. The internal miner seems to be fine (solo mining with setgenerate true 40 for example, gives me 225KHPS, and the nonce was tested in unit testing mode yesterday, so I know the internal miner is working). Ill test the external miner in solo mode. |
|
|
|
With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse? Thanks!
So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp). If they are in team bbp, we do not have a minimum rac. There should be no minimum coin*age reqt either. The only minimum I am aware of is if a person generates less than .005% of the GSC contract - then due to rounding, our payment system leaves off the payment (because it considers it zero). But in this case you should still see some RAC in the leaderboard. The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row. Exec rac shows I have 0.99 necessary coin age but my points on the leaderboard are still showing 0. Thanks! You can try to force out an 'exec sendgscc wcg' and see if it gives an error? If you are still not in the leaderboard please send me the exec rac output. It might be that you don't have enough coin age for .005% of the rac. |
|
|
|
Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)
My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.
This release for ( trying to ) block gpu is just a bunch of crap ...
"bunch of crap": -> No, I'm afraid you don't know what you are talking about. Could you provide one piece of evidence of a way to get around it with a gpu? Or, you can surely win the 2 mil bounty if you care to? Please explain. All I'm asking for is for you to explain your position in detail. I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint). For sure I'm complaining ! With the last release I can't anymore use my Ryzen 2600x ! You're trying to lock gpus, it's fine I'm correct with that. But your modification is too restrictive, "high" cpu hashrate is locked too ! And there's a BIG difference between a Ryzen doing something like 190kHs and a GTX 1070 doing 7MHs no ? Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)
My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.
This release for ( trying to ) block gpu is just a bunch of crap ...
"bunch of crap": -> No, I'm afraid you don't know what you are talking about. Could you provide one piece of evidence of a way to get around it with a gpu? Or, you can surely win the 2 mil bounty if you care to? Please explain. All I'm asking for is for you to explain your position in detail. I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint). @Rob: his problem is NOT a hypothetical ability to mine with GPU, but a now existing INability to mine with a high power CPU. @whyme: why don't you redirect your ryzen against WCG and do some PODC instead of simple "heat mining"? Just finding 1 solo block per day pays more than WCG. And it's winter here, so just doing heat is fine. Just to clarify my position, I'm not against you complaining ... I was under the impression your position was that our GPU restricition was fake. I just want to clarify that our GPU restriction has been tested from 2017-2018 and it works fine (the logic is sound). So your talking more about the heat mining environment itself not working, OK, I will look at that now. Sorry to ruffle your feathers. Checking. We are here to provide a quality environment for the miners- we will not tolerate broken software; if something is broken I was not aware of it. I'll run each of the miners on my windows machine first. |
|
|
|
give a link to the wallet
Biblepay.org || OP Post |
|
|
|
With PODC 2.0, is there a minimum external purse age we need to have to receive fractional payments, or will we get some (a very tiny amount) even if we have very little coin age in our purse? Thanks!
So on a side note, the new rule is in effect, so everyone should get the correct commensurate rac, regardless of team, as long as they have more than 256 RAC (if they are not in team bbp). If they are in team bbp, we do not have a minimum rac. There should be no minimum coin*age reqt either. The only minimum I am aware of is if a person generates less than .005% of the GSC contract - then due to rounding, our payment system leaves off the payment (because it considers it zero). But in this case you should still see some RAC in the leaderboard. The easiest way to check all this out is look at the leaderboard "details" and see what we have for the -wcg row. |
|
|
|
Solo mining with a Ryzen, 8 threads doing each 24kHs, 192kHs combined, now considered as gpu mining !? Are you serious ?
2020-01-22 01:00:49 ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: 57786e9e872bfaeff5d2d5a020d68c71eea849fbe9c242b7a2d86612938eef06, high-hash, proof of work failed (code 16)
My server with 16 threads doing each 10kHs, 160kHs combined is running fine and finding blocks.
This release for ( trying to ) block gpu is just a bunch of crap ...
"bunch of crap": -> No, I'm afraid you don't know what you are talking about. Could you provide one piece of evidence of a way to get around it with a gpu? Or, you can surely win the 2 mil bounty if you care to? Please explain. All I'm asking for is for you to explain your position in detail. I've been answering your posts but this seems to be a one way endeavor (you just complain more with a baseless complaint). |
|
|
|
|
** DYNAMIC WHALE STAKING **
I see we have 916K of burns today (exec dwsquote).
I think this is going to be a good feature for potential new baghodlers. Hopefully more people from the outside world will join biblepay and try this.
|
|
|
|
I'm not killing the process, just waiting it close itself.
Still processing blocks, will see result in few minutes.
Ohh ok, sorry, I think I am seeing the picture now; anyone who is still live on the old fork is making a long chain of bad blocks; Yes, if you simply restart and have a lot of bad blocks in the blockindex, the plain-vanilla block checker during boot incorrectly assumes you have a corrupt chain... OK, yes, if that is the case, please restart like Sun mentioned: "-erasechain=1" at the end of biblepay-qt. Btw, if we do crash during reindex (Would you like to rebuild block index now? <YES>), if that actually crashes, please enter a github issue. |
|
|
|
Same problem on another machine. Upgrading from 1.4.8.5 to 1.4.8.7
Rebuild in progress, and after I'm pretty sure wallet will crash.
Also, if you have been, please avoid killing the biblepay-qt process from task manager, please do not do that. That is a big no no in crypto. If you kill the wallet without gracefully exiting, you will corrupt all of your databases - both berkeley DB and the underlying blocks and chainstate and wallet and you will be in for nothing but trouble in the future. I've had a good 1 year run now with the same database and no corruption simply by exiting from the menu. - Just to clarify - that is not a crash. That is a notification that you have a corrupt database file. (A crash is an unhandled exit in the program, this was handled). |
|
|
|
PoDC 2.0 payment issues from Dec 25, 2019 to Jan 16, 2020, I've identified 518,639 BBP (122 line items) that are candidates for reimbursement.
Option 1: Shall I submit sanctuary proposals for each CPK, detailing the payouts?
Option 2: Send me 518,639 BBP and I'll distribute it, with documentation. BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw
Option 3: There's 146k BBP in the bounty wallet I can use. Remainder 372,639 BKdkszSubBe9cNurd2LoBjPuaFhTL7utYw
Full details and methodology is available to anyone wanting to review out of curiosity or validate my work.
Based on the payout each day, I created median value of BBP to RAC ratio per day. This is the multiplier I used based on the RAC of the cpid I retrieved from boincstats (same as WCG). If the CPK was overpaid overall (total payments equal more than 110% of estimated payments) then there is no reimbursement for that CPK since they received more already.
Some caveats in my analysis:
* the RAC to BBP multiplier is best effort and not always best value. If a RAC whale was underpaid, this can throw off the ratio
* GSC payments are lumped into one (PoDC, Healing, POOM, etc) making it difficult to separate out non-PODC payment without performing more analysis. I looked at leaderboard but some prominence seems to be current day not on gsc block day?
* I counted the BBP balance of the CPK when the GSC reward was transmitted. If their balance had enough stake based on the team they were on (BBP = ^1.3 and non-BBP = ^1.6), then I assumed they had enough stake. I realize balance may not reflect full coin age transmission.
* Some small incidents where the GSC transmission was not sent for the CPK automatically using RAC & BBP balance day of was the best way to be inclusive
* Since the code did not offer partial payments, I did not adjust for this and respected what the code was written to do
I sent you 518,640 from my wallet, please distribute it any way you want, and thank you for taking on this endeavor. |
|
|
|
Seems to be working, wallet is synching now, thanks.
But we can't upgrade from 1.4.8.5 ?
From what I understand we already released the binaries, could you please ensure you are running the right bitness? If not please post the URL and platform-bitness? Im running windows 64 here and Im on 1487. I never uninstall the old version; I just install the latest and it works. Hi Rob, dns4.biblepay.org is still on version 1.4.8.4 - Could you please upgrade that one? Thats someone elses node; I will repoint that one right now. |
|
|
|
Just found a solo block. Seems the new miner try sending xx times the same share. I've replaced the params value by ... for best reading, but was the same value for each. So it's 1 accepted and 12 rejected. Running on 12 cores, probably a relationship. [2020-01-20 14:27:15] DEBUG: got new work in 3 ms
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:20] accepted: 1/1 (100.00%), 159.00 khash/s (yay!!!)
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:25] accepted: 1/2 (50.00%), 151.49 khash/s (booooo)
[2020-01-20 14:27:25] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:29] accepted: 1/3 (33.33%), 141.08 khash/s (booooo)
[2020-01-20 14:27:29] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:34] accepted: 1/4 (25.00%), 144.30 khash/s (booooo)
[2020-01-20 14:27:34] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:38] accepted: 1/5 (20.00%), 158.82 khash/s (booooo)
[2020-01-20 14:27:38] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:42] accepted: 1/6 (16.67%), 157.78 khash/s (booooo)
[2020-01-20 14:27:42] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:47] accepted: 1/7 (14.29%), 157.52 khash/s (booooo)
[2020-01-20 14:27:47] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:51] accepted: 1/8 (12.50%), 158.96 khash/s (booooo)
[2020-01-20 14:27:51] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:27:56] accepted: 1/9 (11.11%), 157.34 khash/s (booooo)
[2020-01-20 14:27:56] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:28:00] accepted: 1/10 (10.00%), 159.26 khash/s (booooo)
[2020-01-20 14:28:00] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:28:05] accepted: 1/11 (9.09%), 153.30 khash/s (booooo)
[2020-01-20 14:28:05] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:28:09] accepted: 1/12 (8.33%), 144.01 khash/s (booooo)
[2020-01-20 14:28:09] DEBUG2: reject reason: duplicate
!!
SOLUTION FOUND !!!!
x11 - HASH [01b958f15c8b407316342e64b2ba05ed31da3922d94e18d943fd99cded7b4e96]
!! bbphash
- HASH [00000000036dbc4ae5b068513f3393d8907f46504572123dcb06e697fc7fe9e3]
SUBMITTING RPC1 [{"method": "submitblock", "params": ["..."], "id":1}
]
[2020-01-20 14:28:17] accepted: 1/13 (7.69%), 149.78 khash/s (booooo)
[2020-01-20 14:28:17] DEBUG2: reject reason: duplicate
[2020-01-20 14:28:17] DEBUG: got new work in 9 ms [2020-01-20 14:29:17] DEBUG: got new work in 13 ms Please - only paste long pastes if they are surrounded by code tags. I corrected this one as an example. Can you please confirm you are synced with the chainz block explorer? |
|
|
|
Seems to be working, wallet is synching now, thanks.
But we can't upgrade from 1.4.8.5 ?
From what I understand we already released the binaries, could you please ensure you are running the right bitness? If not please post the URL and platform-bitness? Im running windows 64 here and Im on 1487. I never uninstall the old version; I just install the latest and it works. |
|
|
|
You use a standard x11 hash, then you use it in your pobh layer.
But it stays a true x11 hash, which is gpu and asic mineable since years ...
1) No, we don't 2) I am aware of randomX and its entire virtual machine and its code; and this is already taken into account for our dotnetcore version. If you would like to give an example as to how you would run POBH in an asic or gpu, feel free to continue the discussion, but you cant. Please review the code again in kjv.cpp. Just to give more clarity on this, let me explain how a POBH hash is computed and why you cant run POBH in a GPU (because you claimed 'this x11 was gpu and asic mineable for years'): 1) The hash of the block header is hashed with X11 first, but not used in the core wallet 2) The X11 hash is hashed with POBH 3) The POBH hash is used in the wallet Therefore, you can't hash it in a GPU, and skip over the POBH hash and use it in BBP. Of course Marcino, who ported POBH v1.0 to GPU actually *ported* the whole KJV and all of our code *into CUDA*, so he didnt simply run X11 in a GPU to mine bbp. The new version released today is a *Stopgap* version. It I believe, is going to be fine until we release our next-gen miner. I want to stress, we are still working on something cooler that will do useful work while it mines in POW mode. But POBH 2.0 is still very good- because it still produces bible verses, and cant run in an gpu due to the new rules. I'm sure Marcino can certify this as he tries to hack it. Because it will take the hacker more clock cycles to circumvent security than to create a new block in parallel. The new security is based on the fact that a GPU miner must create more blocks than they care to per second of hashing. |
|
|
|
New wallet is crashing. Installed on previous version.
Error was 2020-01-20 16:06:52 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at CBlockDiskPos(nFile=0, nPos=11296509)
I deleted my blocks directory to force rescan, now is crashing with no error in log.
Have you tried restarting with the "-erasechain=1" switch? |
|
|
|
|
** Compassion Update **
So I just want to give a compassion.com transparency update.
We've spent $177,224 at compassion (which is btw, 82% of our total charity expenses since inception). We sponsored 4,657 orphan months of charity with them! An amazing accomplishment! Thank you everyone, this has certainly aligned a lot of our users with God by fulfilling James 1:27 for them.
Anyway, I gave them the 30 day notice to cancel all of our 81 children as of Jan 20th 2020 (to give us close to a zero balance).
However what's nice about Compassion is they not only have an insurance program to continue to cover a canceled child. But also they sometimes give us a credit balance back for the extra days. So we still have something like a $1,600 credit available to spend; and I was originally going to suggest Compassion for Babies, but since then I have come up with a better idea (also babies don't allow us to generate bios so there is less accountability).
I think what we can do for the most impact is go ahead and sponsor 10 more children with compassion, and this will give us approx 4 more months of positive impact then I will repeat the process and cancel those 10 around the beginning of May.
Praise Jesus.
|
|
|
|
You use a standard x11 hash, then you use it in your pobh layer.
But it stays a true x11 hash, which is gpu and asic mineable since years ...
1) No, we don't 2) I am aware of randomX and its entire virtual machine and its code; and this is already taken into account for our dotnetcore version. If you would like to give an example as to how you would run POBH in an asic or gpu, feel free to continue the discussion, but you cant. Please review the code again in kjv.cpp. |
|
|
|
Why continue using standard x11 hash if you don't want gpu ? If you don't want gpu taking advantage, why not migrate to randomX for example ?
Ours is far different than x11: We have POBH, which has the KJV bible in it, and it has anti-gpu features on top of it. The new bounty will be reinstated that POBH 2.0 cannot function better in a GPU than in a CPU. EDIT: The x11 you see in nomp is just the label (its there because we also use x11 below pobh). I'll edit it. |
|
|
|
|
Show Posts
