Ok....I think I know where I went wrong. I re-used the old CPK from PODC 1.0. According to my exec rac, my CPK is BEnG96E4bTH9JDXhnDUFMnZ6k1XCnMXq8o but I sent everything to BB2BwSbDCqCqNsfc7FgWFJn4sRgnUt4tsM. I feel a bit sheepish now... Edit - I got it to work now by sending to the correct CPK address. Now I noticed that my coins are actually still in my wallet after sending to the CPK. Is there a safeguard to prevent sending the same coins over and over again to the CPK? Thanks! Great, glad you see how the back & forth works now (since its always being sent to and from your own addresses, so it never leaves your wallet). As far as safeguards, the way it works is we scan your wallet.dat's receive address book, for the name 'Christian-Public-Key', and our daily gsc always sends to the one that belongs to that wallet.dat (so it will never send to one outside your wallet that was registered a long time ago). However if the user deleted the CPK, or edited the name, the wallet creates a new one and uses that one. So yeah your coins will never be sent outside of the wallet.dat receive addresses. Note that 'exec bankroll qty denom' does the same thing - it *always* sends it to your internal cpk. |
|
|
|
Cool, ok now one last thing about withdrawing the funds from CPK. I don't see the way to select CPK from the Send tab, even with coin control enabled. Am I missing something?
Try list view instead of tree view  Ok, opened the Inputs menu and selected list view. I do see an address there for CPK but it only shows 4bbp in it, when I sent over 1500. Can you give me the txid of the tx where you sent 1500 please? 27840f8b2a13bb69c00c5da453fcf3f8501ea1b2fef04879a031687b55da5e90 Thanks! Sun mentioned that this was resolved. |
|
|
|
When Doge did it with LTC it looks like it helped DOGE to get popular also.
With merged mining, what would be the chance of earning Monero at say 10 MH/s of PoBH? What kind of difficulty do you envision BBP will have with PoBH + RandomX? If difficulty climbs, won't that impact the BBP rewards and we hit the floor for the reward value? https://cointelegraph.com/news/dogecoin-adopts-merged-mining-with-litecoinDogecoin was facing the possibility of a 51 % attack. The coin is rapidly lowering it reward rate for miners. That obviously is resulting in fewer miners which means a lower hash rate and a less secure network. The coin's community has decided to go forward with merged mining.
...
But, with 95 % of the world's Dogecoin set to be released by block 600,000 there will then be very little incentive for miners to process transactions and secure the network. If Dogecoin's price jump dramatically and compensated the drop in price, then the network would stay secure, but that appears unlikely. Good point on the DGW variable reward... instead of taking out the protection we could put a limit on it, to govern it at say half (at least for 6 months just to watch everything in prod), rather than remove it. Actually though this implementation would require a specific BBP miner exe, and bbp's diff would be independent of moneros diff completely (even multiple monero blocks can pass between each one of ours), as this implementation is slightly different than other merge implementations. So our diff would be a product of how many miners find it profitable to mine both at once; its a very interesting problem. I really have no idea what our diff would be! Theoretically, we could support 1000 miners right off the bat, because they get full rewards (plus bbp). Of course when I ran the monero mining calculator today it appeared to me to sort of break even , so its not all roses , but it is a breakeven for electricity. Maybe if we are lucky we can create 840 more pages for monero-merged mining also  . |
|
|
|
What would happen if Monero decided to hard fork to another algorithm? Would we be able fall back to PoBH mining only again?
whether someone would hodl or sell bbp is hard to say. if I were a miners miner, I might sell bbp. if I were a bbp miner, vice versa. I do see your point about hodling bbp for the chance it may increase in value more than Monero.
I own some Monero, but I wonder if I'd need a Monero wallet as a new user to pool mine BBP? If Monero was auto sold on an exchange and paid out as BBP from the pool, that'd mean you'd only need one wallet. If the pool miner hodls BBP, then the buying of BBP with Monero could offset some of the charity sell pressure? I know it means centralizing the effort on a pool to auto sell, but if there's an exchange API, I wonder how automated this process could become...
If Monero hard forked, we could either keep randomX and keep going, or change to POBH with a mandatory upgrade, or follow their lead and schedule a mandatory on the same date (to follow their new algo). Although no one can predict which pair would be sold, in pairs trading, its usually the higher priced coin that gets sold. Especially if we have something on the roadmap that leads to a future higher price (in my case Id be selling monero and holding bbp). Additionally we are the one with the sancs, so it would be even more beneficial to hold the bbp. There are a couple ways you could participate in this without having a monero wallet. EDIT: Scratch this. I just realized the top 3 monero pools mine to your home wallet. In this case, I think we will need to look at hardware wallets and monero vaults. Maybe we can find a cheap hardware wallet we can mine to. Im liking the idea so far, one thing that is nice about it is it theoretically lowers the mining burden on BBP to something very manageable. When Doge did it with LTC it looks like it helped DOGE to get popular also. Looks like we can expiriment with this project using something like this for a while: https://mymonero.com/(This is similar to our iphone wallet - SPV only). Once one wants to store more than $100 or so they can move to the ledger nano s or a hardware wallet etc. (Then we dont have to ask people to run the monero wallet). I believe this will be the case... |
|
|
|
What would happen if Monero decided to hard fork to another algorithm? Would we be able fall back to PoBH mining only again?
whether someone would hodl or sell bbp is hard to say. if I were a miners miner, I might sell bbp. if I were a bbp miner, vice versa. I do see your point about hodling bbp for the chance it may increase in value more than Monero.
I own some Monero, but I wonder if I'd need a Monero wallet as a new user to pool mine BBP? If Monero was auto sold on an exchange and paid out as BBP from the pool, that'd mean you'd only need one wallet. If the pool miner hodls BBP, then the buying of BBP with Monero could offset some of the charity sell pressure? I know it means centralizing the effort on a pool to auto sell, but if there's an exchange API, I wonder how automated this process could become...
If Monero hard forked, we could either keep randomX and keep going, or change to POBH with a mandatory upgrade, or follow their lead and schedule a mandatory on the same date (to follow their new algo). Although no one can predict which pair would be sold, in pairs trading, its usually the higher priced coin that gets sold. Especially if we have something on the roadmap that leads to a future higher price (in my case Id be selling monero and holding bbp). Additionally we are the one with the sancs, so it would be even more beneficial to hold the bbp. There are a couple ways you could participate in this without having a monero wallet. EDIT: Scratch this. I just realized the top 3 monero pools mine to your home wallet. In this case, I think we will need to look at hardware wallets and monero vaults. Maybe we can find a cheap hardware wallet we can mine to. Im liking the idea so far, one thing that is nice about it is it theoretically lowers the mining burden on BBP to something very manageable. When Doge did it with LTC it looks like it helped DOGE to get popular also. |
|
|
|
So I've been thinking about another potential possibility for our next replacement POBH miner for heat mining.
I'm thinking of possibly using RandomX as our next POW algo and creating compatibility in BBP for merge mining XMR from BBP.
(Up til today, I was primarily considering a new POW protocol that would do some type of useful work, until the idea was considered, that the useful work might be the *mining revenue* from XMR - where miners could earn the electricity from (XMR) but still fully secure the chain with randomx). This idea made me think of the benefits of less sell pressure and more income for the miners.
Im also thinking it would open up the possibility of all XMR users to have a desire to mine and be exposed to BBP.
The way it would work is this (potentially):
- BBP adopts RandomX as its core hash algorithm
- BBP creates a new pool that is both RandomX, Monero, and BBP compatible
- Miners mine BBP with RandomX as full fledged CPU miners with more arguments in the miner (IE multiple receive addresses)
- The pool has the capability to forward 100% of the solutions into Monero using the miners supplied monero address
I've been evaluating this today, and it appears to be 100% efficient (another words, it would not be as if you are merge mining and switching between protocols with inefficient losses).
Basically, the pool miner would win the XMR round anytime the miners difficulty is below the pool target, but for every XMR hash, we would test for an equal BBP solution like this:
must equal X11(PrevBlockHash + RandomXHash) < BBP_DIFF, plus block.RandomXsource must match RandomX hash (ensuring our prevBlockHash is the one in the round), and, the core wallet ensures this randomX set meets the difficulty of the BBP block. This basically means it would be possible for BBP miners to earn 100% of the revenue from randomx hashes, while still hashing BBP with an equal chance of solving the current BBP block using the same spent hashpower for the current hash minus a tiny bit of overhead (for checking each one, which I assume to be 10% or less).
Some of the potential upsides I see to this:
- More BBP exposure
- More Revenue for the miners
- Less sell pressure
- Monero users get exposed to BBP and the gospel
I thought I would throw this out there, so if anyone has any downsides or questions please pose them. In the mean time, Ill do some thorough investigation and consider making a proof of concept for this to ensure this is feasible.
From the high level, it appears to be a good solution for us on the heat side. We would of course make the POBH verses compatible and keep the bible in, for biblical reference.
Wow - by far the most exciting idea I heard over here for a while ! Double-sided exposure on the latest cpu-favoring algo around, and more income for miners - simply great. I have played with randomx for a bit, and it definitely puts less stress on the cpus since it typically uses half (or less than half) of the possible threads. Less heat produced = less energy wasted. There is one risk I see, though. Merge mining tends to create sell pressure on one of the coins in the pair - if miners would rather hodl the other one (that is, if they are hodling at all). You can check out the case of LOKI and TURTLECOIN; they recently abandoned the merged mining option. The only precaution I can think of is introducing some sort of ABN requirement (perhaps even dynamically changing as diff changes) to make sure some BBP has to be locked in. Oh, that would also deter possible botnets?? Thanks, I do see the Loki + turtlecoin expiriment. I assume that Lokis market cap started dropping as turtle sold the coins on the loki side. Interesting. Well in our case, its BBP, the flea on the back of XMR. So I guess it would be a case of miners being able to sell some XMR to recoup electric and they would hold BBP (most likely) when our price is low, and thats basically the problem we have now, since we spent so much on charity. When would it work in reverse, I suppose if we had a nice run up from this (which would be a good problem to have). Yeah, you bring up a good point on the botnet, simply because up til now, since we are proprietary, there is no mass desire to make a botnet out of BBP with our low price, but otoh, if we did this new project, we would have 10 million potential miners with the potential of being in a botnet. I think that will be solved 90% of the way, because the reqs for us to do this require a specialized BBP miner (it cant be done with the plain old XMR miner), so that knocks out most of the botnet, but otoh we have to consider the risk of if our price is rising. Im not sure how easy we could implement ABN, but I think we can raise the bar pretty high: Must run specialized bbp miner, must pool mine to receive the merged revenue, and, we could check in the pool for something from BBP (possibly a CPID), if we want to cut down botnets that way. Great points! I dont think this part will be a showstopper either. |
|
|
|
|
So I've been thinking about another potential possibility for our next replacement POBH miner for heat mining.
I'm thinking of possibly using RandomX as our next POW algo and creating compatibility in BBP for merge mining XMR from BBP.
(Up til today, I was primarily considering a new POW protocol that would do some type of useful work, until the idea was considered, that the useful work might be the *mining revenue* from XMR - where miners could earn the electricity from (XMR) but still fully secure the chain with randomx). This idea made me think of the benefits of less sell pressure and more income for the miners.
Im also thinking it would open up the possibility of all XMR users to have a desire to mine and be exposed to BBP.
The way it would work is this (potentially):
- BBP adopts RandomX as its core hash algorithm
- BBP creates a new pool that is both RandomX, Monero, and BBP compatible
- Miners mine BBP with RandomX as full fledged CPU miners with more arguments in the miner (IE multiple receive addresses)
- The pool has the capability to forward 100% of the solutions into Monero using the miners supplied monero address
I've been evaluating this today, and it appears to be 100% efficient (another words, it would not be as if you are merge mining and switching between protocols with inefficient losses).
Basically, the pool miner would win the XMR round anytime the miners difficulty is below the pool target, but for every XMR hash, we would test for an equal BBP solution like this:
must equal X11(PrevBlockHash + RandomXHash) < BBP_DIFF, plus block.RandomXsource must match RandomX hash (ensuring our prevBlockHash is the one in the round), and, the core wallet ensures this randomX set meets the difficulty of the BBP block. This basically means it would be possible for BBP miners to earn 100% of the revenue from randomx hashes, while still hashing BBP with an equal chance of solving the current BBP block using the same spent hashpower for the current hash minus a tiny bit of overhead (for checking each one, which I assume to be 10% or less).
Some of the potential upsides I see to this:
- More BBP exposure
- More Revenue for the miners
- Less sell pressure
- Monero users get exposed to BBP and the gospel
I thought I would throw this out there, so if anyone has any downsides or questions please pose them. In the mean time, Ill do some thorough investigation and consider making a proof of concept for this to ensure this is feasible.
From the high level, it appears to be a good solution for us on the heat side. We would of course make the POBH verses compatible and keep the bible in, for biblical reference.
|
|
|
|
Cool, ok now one last thing about withdrawing the funds from CPK. I don't see the way to select CPK from the Send tab, even with coin control enabled. Am I missing something?
Try list view instead of tree view Ok, opened the Inputs menu and selected list view. I do see an address there for CPK but it only shows 4bbp in it, when I sent over 1500. Can you give me the txid of the tx where you sent 1500 please? |
|
|
|
And then if you want to fund your cpk again you can type 'exec bankroll qty denomination'. This gives you some distinct denominated bills for coin age to accrue on each one individually.
To send only *from* your CPK (to recover the funds) you can enable coin control, and send from the CPK to yourself.
Gotcha, now just to be clear, earlier you said that we no longer source the sendgscc funds from the main wallet. Does that mean I absolutely must send funds to the CPK in order to participate in PODC 2.0? Thanks! Well this is primarily designed so we don't have to tell people to unlock the wallet (we don't need the hack of requiring some people to script the wallet unlock command etc). So yes in the current version its only capable of sending the escrow from the CPK. 2) Btw, you never really have to manually send the sendgscc, it is sent automatically once per day at the height in 'exec rac'. The manual send is just helpful for getting in the leaderboard earlier, or, diagnosing issues. |
|
|
|
|
Out of curiosity, do we have any programmers here interested in a side project?
I'm looking for someone who knows both c# and c++ who is interested in porting a fairly large program from c++ to c#.
(One of my goals for the next gen miner is to give us a shot at solving one of the 7 greatest unsolved math problems in the world, for the 1 million $ prize. I am thinking this might be a good side effect in the new miner, to have a chance at logging the solution, and it would also help build popularity).
The programmer needs to have at least 5 years of experience and be very good at math, and confident the ported solution would be tested to behave the same as the original. The program has about 10 c++ classes. I could pay a bounty of between 1 and 10 million bbp depending on how long it takes.
|
|
|
|
You have to send the funds to your CPK (as that is your external purse address), and that will let the (sendgscc) process succeed even if the wallet is locked.
(exec rac pulls its values from the CPK balance btw).
We no longer source the sendgscc funds from the main wallet.
The stake is returned to your CPK as you spend it (it spends it back to itself) and breaks it into 10 pieces of change.
Is there a way to recover the funds from the cpk and put them back into the main wallet? Thanks! Certainly, just open the "send" tab and select any or all of the coins listed in your CPK address and then send them to any one of your receiving addresses in the same wallet. And then if you want to fund your cpk again you can type 'exec bankroll qty denomination'. This gives you some distinct denominated bills for coin age to accrue on each one individually. To send only *from* your CPK (to recover the funds) you can enable coin control, and send from the CPK to yourself. |
|
|
|
Ok, I opened issues and commits, try again. And I do realize we still have a high reject rate on the nomp pools; I'm going to be looking at that again. |
|
|
|
 Far different than the love of Mammon, Jezebel or Hollywood. |
|
|
|
Ok, I opened issues and commits, try again. |
|
|
|
So basically what its saying is with 4918 RAC in team GRC, we require 806,996 coin age. But in your purse you only have 32 total coin age.
You would need at least 4,030 coin_age (roughly) to earn more than 1 bbp in the leaderboard (IE .005% of the gsc contract) so you just need to increase your coin age.
If you send yourself a couple hundred K of BBP into your CPK that should fix the problem. Then the .99 coin_age_percent required would drop to something like .50.
Then the sendgscc will work.
Is sending to the CPK required or can I just leave my wallet unlocked? Also, when are the funds from the CPK returned? You have to send the funds to your CPK (as that is your external purse address), and that will let the (sendgscc) process succeed even if the wallet is locked. (exec rac pulls its values from the CPK balance btw). We no longer source the sendgscc funds from the main wallet. The stake is returned to your CPK as you spend it (it spends it back to itself) and breaks it into 10 pieces of change. |
|
|
|
I gave Capulo his missing payment out of my pocket the other day. |
|
|
|
"256 hashes per second, per distinct block. A distinct block has a miners address and a distinct merkle root."
Isn't it too low value ?
No, because when you run out of nonces, your biblepaycore client will create a new block for you. Or, you can run more threads. |
|
|
|
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? 09:10:50  { "Command": "rac", "cpid": "54d2a30e96db342462808e0bed89228d", "CPK": "BEnG96E4bTH9JDXhnDUFMnZ6k1XCnMXq8o", "wcg_teamid": 30513, "next_podc_gsc_transmission": 171482, "team_name": "Gridcoin", "external_purse_total_coin_age": 32.52513888888889, "coin_age_percent_required": 0.99, "NOTE!": "Coins must have a maturity of at least 5 confirms for your coin*age to count. (See current depth in coin control).", "WARNING!": "BiblePay requires staking collateral to be stored in your Christian-Public-Key (External Purse) to be available for GSC transmissions. You currently do not have enough coin age in your external purse. This means your PODC reward will be reduced to a commensurate amount of RAC. Please read our PODC 2.0 guide about sending bankroll notes to yourself. ", "coin_age_required": 806996.2736964496, "wcg_id": 122894, "rac": 4918.07 } Thanks! So basically what its saying is with 4918 RAC in team GRC, we require 806,996 coin age. But in your purse you only have 32 total coin age. You would need at least 4,030 coin_age (roughly) to earn more than 1 bbp in the leaderboard (IE .005% of the gsc contract) so you just need to increase your coin age. If you send yourself a couple hundred K of BBP into your CPK that should fix the problem. Then the .99 coin_age_percent required would drop to something like .50. Then the sendgscc will work. |
|
|
|
Rob if you're busy, you can ignore this post - no offense taken. https://github.com/biblepay/biblepay-evolution/blob/fb8279c0db82db2ff1d8777894b299e1ebd3cda0/src/rpcpog.cpp#L1066Could explain how the nonce check works? Do I understand this correctly? Nonce check passes because current time minus last block time is past 30 minutes? Floor value for nonce is 512 unless nElapsed * 256 (nonce_factor) is greater? So, I see this error in the debug.log: 2020-01-22 16:30:36 ERROR: CheckProofOfWork: ERROR: High Nonce, PrevTime 1579518261, Time 1579518587, Nonce 4047435024 (1579518587-1579518261)*256 = 83456 . Since the nonce was 4047435024 , the submit block was rejected? The nonce had to be less than 83456? So as time passes, the submitted nonce value can be a greater? How does the nonce value translate to the "difficulty" sent to the pool? bool CheckNonce(bool f9000, unsigned int nNonce, int nPrevHeight, int64_t nPrevBlockTime, int64_t nBlockTime, const Consensus::Params& params)
{
if (!f9000 || nPrevHeight > params.EVOLUTION_CUTOVER_HEIGHT && nPrevHeight <= params.ANTI_GPU_HEIGHT)
return true;
int64_t MAX_AGE = 30 * 60;
int NONCE_FACTOR = 256;
int MAX_NONCE = 512;
int64_t nElapsed = nBlockTime - nPrevBlockTime;
if (nElapsed > MAX_AGE)
return true;
int64_t nMaxNonce = nElapsed * NONCE_FACTOR;
if (nMaxNonce < MAX_NONCE) nMaxNonce = MAX_NONCE;
return (nNonce > nMaxNonce) ? false : true;
} First let me explain the logic. Every block has an embedded timestamp that is hard (IE it cant be falsified). The block time also is part of what gets hashed, so it affects the pobh hash. We also must know the block time of the prior block. We check the elapsed time by subtracting the previous block time from the *to be submitted hard block time*. Then we allow up to 256 hashes per second, per distinct block. A distinct block has a miners address and a distinct merkle root. As time passes, we allow more and more total hashes. So if you multiply 256 * 60 * 7, we allow up to 107,520 hashes for that created block in 7 minutes. After 30 minutes (MAX_AGE), we allow any number of hashes (IE even GPUs could win that block). So the idea is, between 1-7 mins, everyone has an equal chance of winning. As the time draws longer, more and more chance is given to the ones with the most brute hashes done. So yes, you could argue that a GPU would have an advantage after 20 mins or so, but this is pretty fair as it requires quite a bit of block recreation in the first 7 minutes. As far as the pool, the pool is just enforcing what is in the core client. If someone had a high nonce its probably because they are running the old miner. The core client and the external miner automatically create new blocks when they run out of nonces. |
|
|
|
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. Ok now Im testing my external miner on my ryzen windows box (bbpminer64.exe -o http://127.0.0.1:12000 -uusername -ppass -t40) and its working. In task manager I see 99% cpu utilization. Two days ago, I tested the external miner against testnet using pobh 2.0. To address your concern about finding a share, and then seeing the other threads reject the same share, thats because in solo mode, if you find a block, the other threads have not joined the main thread yet and the other submissions are stale. We do explicitly restart the work request (see the code) and let them join - so that is not a bug, its just a lagging display which gets cleared from the page in about 10 more seconds. I don't see a problem. I confirmed that this miner can solo mine against testnet and find blocks, and its running at full speed. You might just need to add the parameter "-t40" to the end of your string. Otherwise please tell us what problem you are having with heat mining. |
|
|
|
|
Show Posts
