BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[bible_pay]

I know the botnet is not back, because we have a 125K abn requirement.

One other nice hack the external miner relieves us of is the issue where we copy the wallet.dat out to many machines - with one bbp running node you can mine on multiple miners without copying wallet.dat.

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.

Can you explain a little more about not needing to copy the wallet.dat ?

We still need to run a node (biblepay-qt or biblepayd) but a blank wallet.dat is okay as long as one BiblePay wallet is running with the required ABN stake? That is news to me and sounds like a more secure way to mine. If mining is easier, I'm thinking it'll be easier for botnets to be set up too... if you set ABN to 5k, it wouldn't take much to mine continuously. Is there some way to keep botnets away without needing to stake BBP for ABN?

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.  

[1714868932]

1714868932

[bible_pay]

also remember to comment out the setting in biblepay.conf that refer to the pool if you want to run the external miner.

Another thing: I mined a block with the external in Production but the .biblepayevolution/debug.log and the output of bbpminer -D never acknowledged that it found a block or that the wallet being used to mine with was the recipient of the mined block.

We could use a message saying: "You found block block_number"
Stratum pools often use the miner identifier on the end of the payout address as an argument for --coinbase-addr= and that could be useful for us too.
   payout_address/minerid

This would be helpful to see which miner got it and how you are doing.
So far only my non-mining Windows 10 wallet acknowledged the mined block (871.x bbp) but non of the linux miners did.
However, the linux wallet did immediately dock me the abnweight as normal.

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.

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.

[Nipar]

@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.

[sunk818]

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

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.  

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!

[bible_pay]

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

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.  

Yes, solo, 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. I don't think I've ever seen workerid included for 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!

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.

[jsheets1970]

@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.

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??

[sunk818]

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.

[capulo]

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?

[coinsinspect]

external miner? i was a bit off last weeks, but when i checked quickly forum i found nothing about external miner hmm

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

[coinsinspect]

Did the latest BiblePay newsletter work? Its showing they were all sent and over 120 have been opened so far
It was just a link to the medium article, I want confirmation that it worked

works for me.

[capulo]

external miner? i was a bit off last weeks, but when i checked quickly forum i found nothing about external miner hmm

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

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

[evilbaby]

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  !

Code:

server=1

rpcport=14000

rpcallowip=127.0.0.1

rpcuser=myuser

rpcpassword=randompassword 

[bible_pay]

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?

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.

[bible_pay]

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  !

Code:

server=1

rpcport=14000

rpcallowip=127.0.0.1

rpcuser=myuser

rpcpassword=randompassword 

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).

[bible_pay]

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.

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.

[Nipar]

@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:

Code:

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

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

Code:

[2019-10-15 21:06:09] HTTP request failed: Send failure: Broken pipe

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.)

Code:

KJV Loaded
Using bbpminer version 1004

Erroring out

Erroring out

Erroring out

Erroring out

Erroring out

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.

[sunk818]

I compiled bbpminer on macOS with a few tweaks. I'm getting 7.15kh/s on single thread of MacBook Pro (2011). So, 8 threads theretically would be 56kh/s. I'm not going to push it because laptops aren't ideal due to poor thermal cooling.

Changing subject, when I run: bbpminer-x86.exe --version   , I see binary is compiled with AVX2 support. What happens if the CPU doesn't support AVX2 because it is older CPU?

[jsheets1970]

@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:

Code:

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

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

Code:

[2019-10-15 21:06:09] HTTP request failed: Send failure: Broken pipe

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.)

Code:

KJV Loaded
Using bbpminer version 1004

Erroring out

Erroring out

Erroring out

Erroring out

Erroring out

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.

So I did find one with Linux miner and Linux wallet so I am sure that is working well.

Sunk made a great point about AVX/AVX2.. We definitely do not want to rule out the people that might have older machines that do not support AVX2.. I believe other miners have handled this issue as I believe, and I might be mistaken, some AMD chips do not support AVX2

[sunk818]

What is a “daily” superblock in BiblePay?
https://whitewalr.us/2019/biblepay-daily-superblock.html

[bible_pay]

I compiled bbpminer on macOS with a few tweaks. I'm getting 7.15kh/s on single thread of MacBook Pro (2011). So, 8 threads theretically would be 56kh/s. I'm not going to push it because laptops aren't ideal due to poor thermal cooling.

Changing subject, when I run: bbpminer-x86.exe --version   , I see binary is compiled with AVX2 support. What happens if the CPU doesn't support AVX2 because it is older CPU?

Looking at the code, we only use AVX for Sha256d 8-way-hashing, which should only be hit when mining bitcoin.
We use X11 and POBH when mining, so AVX should not actually be hit in our case.