Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 83. (Read 243376 times)

@jsheets1970 from mining the previous method I have multiple copies of my wallet running. some on linux, some on Windows 10.

For those getting errors when running the external miner please be aware that all the wrinkles are not yet ironed out.

This is a normal message if you forgot to unlock your wallet for mining OR your abnweight (minimum 125,000 abnweight) is too low
and the miner is waiting for it to reach the minimum limit of 125k abnweight again:


you will also get this one and a few others that "fix" themselves:


while this one is a mystery to me, I am sure that it will be looked into and resolved soon:
(This is what I found while leaving the external miner running overnight with no abnweight. However it did seem to recover at one point only to error out again later.)


It also seems the external miner could use a "standby" type of connection/message as when the abnweight is too low it keeps thinking the connection to the wallet died and makes new connections every few seconds.

Yeah, this is something on my mind also. 
Preferably, in our next environment, let's look at moving the SendGscTransactions over to our main thread (still at the same frequency), so the user does not need to start the miner.
Lets also look at either zero cost transactions, or sending this from a special purse.

Ill start with a baby item for R&D:  Create a receive address called "ABN", fund it with a small amount, lock the wallet, and send a GSC transaction using "ABN" as the fee source while the wallet is locked.  Once we know the outcome of this we can work on Biblepay 2.0's architecture.

Could you please paste your 'exec getabnweight' , and ensure the "weight" is greater than 125k?  You must have a valid ABN to mine in our current environment.

(See the OP post for Getting Started with Evolution for more about ABNs).

Yes, good job.

It evens out over time - when it first starts it takes more time to get JSON replies but after a while all the threads get pretty equal.

You are probably mining on 40 threads @ 14.4 KHS each.

json_rpc_call failed, retry after 30 seconds
 BBP Core Mining Error:  Wallet Locked/ABN Required


i'm new mining , and after sync wallet , add .conf for mining, use bbminer  , and error  ! how to fix  !

thanks, i just somehow missed info about external miner now i started it on one machine and i need to be sure it is mining first

works for me.

you can also follow BBP news here:
https://bitcointalk.org/index.php?topic=5067231.new#new

am i mining now?

[2019-10-16 08:05:21] thread 11: 861255 hashes, 14.35 khash/s
[2019-10-16 08:05:21] thread 0: 811334 hashes, 13.72 khash/s
[2019-10-16 08:05:21] thread 26: 846296 hashes, 14.11 khash/s
[2019-10-16 08:05:21] thread 22: 840738 hashes, 14.05 khash/s
[2019-10-16 08:05:21] thread 27: 14089 hashes, 14.09 khash/s
[2019-10-16 08:05:21] thread 14: 864796 hashes, 14.41 khash/s
[2019-10-16 08:05:21] thread 34: 864798 hashes, 14.41 khash/s
[2019-10-16 08:05:21] thread 35: 864685 hashes, 14.41 khash/s
[2019-10-16 08:05:21] thread 9: 847776 hashes, 14.13 khash/s
[2019-10-16 08:05:21] thread 15: 864694 hashes, 14.41 khash/s
[2019-10-16 08:05:21] thread 39: 864101 hashes, 14.40 khash/s
[2019-10-16 08:05:21] thread 19: 864101 hashes, 14.40 khash/s
[2019-10-16 08:05:21] thread 6: 14097 hashes, 14.10 khash/s
[2019-10-16 08:05:21] thread 12: 863514 hashes, 14.39 khash/s
[2019-10-16 08:05:21] thread 32: 863383 hashes, 14.39 khash/s
[2019-10-16 08:05:21] thread 29: 847857 hashes, 14.05 khash/s
[2019-10-16 08:05:21] thread 3: 842599 hashes, 14.00 khash/s
[2019-10-16 08:05:21] thread 7: 14059 hashes, 14.09 khash/s
[2019-10-16 08:05:21] thread 1: 14068 hashes, 14.08 khash/s
[2019-10-16 08:05:21] thread 2: 14098 hashes, 14.10 khash/s
[2019-10-16 08:05:22] thread 20: 840877 hashes, 13.95 khash/s
[2019-10-16 08:05:22] thread 4: 847901 hashes, 14.01 khash/s


why some miners have only ~ 14000 hashes? and other 860000?

I just realized I need to keep gen=1 in biblepay.conf for automated tithing for gsc campaigns even if I'm mining externally. No wonder I missed CameroonONE Smart Contract Reward.

What do you mean by "linux miners and a linux wallet".. but that your win 10 wallet posted a notification? Does your stand alone linux miner connect to a linux wallet or a win 10 wallet??

Yeah, I don't plan on doing anything unconventional for p2pool (other than our abn reqs); I meant I would fix coinbase-addr for the sake of solo mining - and for the sake of passing it into stratum for the payout address.  We can still leave it work the same way with the pool user and password as it does for dash.

The only difference in biblepay, will be the code we need to add to handle funded vs non funded abns.  I have to investigate that further - as Id like to simplify it - to not require the user to do so much and if they make a mistake it should still work etc.

Glad to hear p2pool splits payment that way. It does provide a nice decentralized feel to it and makes truly p2p.


Yes, getblock, getblocktemplate, and stratum+tcp are all supported by minerd. I just meant that for workerid, I usually see implemented via user and/or password. MPOS requires registration and you set your workerid much like your pool. YIIMP is anonymous but the coin base address and workerid goes in the user field.  I don't think I've ever seen workerid appended to coinbase-addr. I suppose it is possible but you would need to custom code that in. Seems counterproductive though if pool miners understand your put workerid inside user or password though.

You're doing an awesome job -- thanks for all your efforts!

@jsheets1970 I found 2 blocks today on linux miners and a linux wallet  
but I only knew it because my Win 10 wallet posted a  notification.

Well, from what Ive learned from the history of the minerd code, it fully supports multiple types of mining : solo, getblock, and stratum/pool.  The usage is still up to the user.  Bitcoin/Dash removed getblock a while back in favor of 'getblocktemplate', allowing the core wallet to work with stratum/long polling. 

We have solo mining now, but the only slight issue we have is we read the coinbase address from biblepay cores new block that is created (and ignore the --coinbase-addr) switch - but I plan on fixing that for both solo/pool mining while looking at the pool.

The p2pool does always split the entire block reward among the participants in the sharechain for every block (it never stores a balance).  I believe I will be working on p2pool first, just to be mostly dash compatible for the future.

Then I will attempt to store some p2pool metrics on the server and report on them in pool.biblepay.org as long as its up for orphan letter writing.

1) On the one biblepay node, multiple miners, like Nipar explained you can do that - the key is in the biblepay.conf on the single running node to do the :rpcallowip=ipv4 - one entry row per mining machine.  On the ABN question, yes that single node would need to have a high enough balance to cover all the ABN activity (IE 10 mining machines might need 1.25MM etc).  That particular wallet still needs unlocked, so that it can generate ABN's for the miners.  Its the same as required now, except concentrated against one node.  The nice thing about it though is we dont tell people to copy wallet.dat out to mining machines, and, its a little more efficient as you dont run multiple biblepays just to mine (I suppose thats better for our governance data and bandwidth consumption also).

2)
"
Do you think a higher difficulty warrants high ABN? It sounded like you want to reduce ABN so the mining would not need much BBP to stake.
"
->  Well, this is a definite conundrum.  On one hand, higher difficulty would dictate a higher ABN requirement if we go the "common sense route", but, the 'cryptocurrency economy model' is starting to explain to us that in order to attract many new users/miners, we have to lower the barrier.  This means we have to choose between these dimensions:  Less users/low diff/lower investor buying activity/more profit for a few - and risk of a collapse of the coin, or  b: more users/higher diff/higher buying activity/less profit per mined block/a more stable community.  So, I also realize, we are trying to protect our miners interests by blocking the botnet also - so it sounds as if a zero ABN is not good either.  Maybe we keep thinking about it - and ideas where we block the botnet - but increase user count.  All I have so far is the idea it might be good to lower the ABN req. to 10,000 or whatever, something that is a low barrier but would still afford some protection against a person who might install biblepay in a school system etc.  

minerid is usually for pool and it is not supported for solo mining since your pay to address is not valid. coinbase sig could used in place if it was supported. I think you set custom receive to address and that'll be how you measure which miner won the block. Rob said coinbase addr may be supported in a future version.

I've also seen a few pools split the mined block transaction immediately based on the split algorithm and pay out in the same block that it was mined at. This way, the pool never keeps a positive balance.

Ok, yes, I can make sure we have that in the biblepaycore wallet.  I know the external miner prints a line (a Yay/Boo and a tally) when it finds a block - but - its lost after the page clears, but you can pipe the output of the miner to the debug log optionally; but yes, good idea, I will make sure we do this during the pool set up.

I found a lot on linux against testnet, so I believe its working, but Ill let others comment for sure.

Interesting.. I am testing on Linux and wondered if anyone had found a block on linux at all.. Anyone??