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.
Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 84. (Read 243376 times)
October 15, 2019, 04:27:51 PM
October 15, 2019, 04:11:49 PM
external miner? i was a bit off last weeks, but when i checked quickly forum i found nothing about external miner hmm
*** External POBH (Heat/POW) miner being released now for testing in Prod or TestNet ***
Remember you will need to upgrade biblepay to 1.4.5.0+ first before you can use this miner.
And, this release will only work in solo mining mode (so please comment out the pool entries).
And, you will need a self-funded abn, and the wallet unlocked for mining (so the internal core can create ABNs when needed).
1) Repo for the new bbp-miner.exe:
https://github.com/biblepay/cpuminer
2) To build it yourself:
https://github.com/biblepay/cpuminer/blob/master/BuildingBBPMiner.txt
3) Binaries for Windows and for Linux (x86_64):
https://github.com/biblepay/cpuminer/tree/master/binaries
Windows Link:
https://github.com/biblepay/cpuminer/blob/master/binaries/bbpminer-x86.exe
Linux link:
https://github.com/biblepay/cpuminer/blob/master/binaries/bbpminer_linux
For more distros we will need to ask MIP to help us.
USAGE INSTRUCTIONS (SOLO MINING):
./bbpminer -o127.0.0.1:rpc_port_number -uYour_RPC_Username -pYour_RPC_Password --no-longpoll
BiblePay Configuration file (biblepay.conf):
server=1
rpcport=14000 (or your own number)
rpcallowip=127.0.0.1
rpcuser=your_rpc_username
rpcpassword=your_rpc_password
Please post if you have any trouble and we can all try to help.
Remember you will need to upgrade biblepay to 1.4.5.0+ first before you can use this miner.
And, this release will only work in solo mining mode (so please comment out the pool entries).
And, you will need a self-funded abn, and the wallet unlocked for mining (so the internal core can create ABNs when needed).
1) Repo for the new bbp-miner.exe:
https://github.com/biblepay/cpuminer
2) To build it yourself:
https://github.com/biblepay/cpuminer/blob/master/BuildingBBPMiner.txt
3) Binaries for Windows and for Linux (x86_64):
https://github.com/biblepay/cpuminer/tree/master/binaries
Windows Link:
https://github.com/biblepay/cpuminer/blob/master/binaries/bbpminer-x86.exe
Linux link:
https://github.com/biblepay/cpuminer/blob/master/binaries/bbpminer_linux
For more distros we will need to ask MIP to help us.
USAGE INSTRUCTIONS (SOLO MINING):
./bbpminer -o127.0.0.1:rpc_port_number -uYour_RPC_Username -pYour_RPC_Password --no-longpoll
BiblePay Configuration file (biblepay.conf):
server=1
rpcport=14000 (or your own number)
rpcallowip=127.0.0.1
rpcuser=your_rpc_username
rpcpassword=your_rpc_password
Please post if you have any trouble and we can all try to help.
October 15, 2019, 03:52:14 PM
You can set for each mining machine rpcallowip=yourlocalnetworkip in your biblepay.conf on the only machine running the wallet. Then set the command line for bbpminer -o localnetworkipwherethewalletisrunning:rpcport along with all the other settings you need and you will mine with many out of the one copy of wallet.... I hope that wasn't too unclear 
This is one of the definite advantages of the external miner and it gets better when Rob implements stratum pools.
This is one of the definite advantages of the external miner and it gets better when Rob implements stratum pools.
October 15, 2019, 03:37:02 PM
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.
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?
October 15, 2019, 03:14:11 PM
external miner? i was a bit off last weeks, but when i checked quickly forum i found nothing about external miner hmm
Did you see this one:
https://bitcointalksearch.org/topic/m.52758236
Also to read about it just go back a few pages before that and look for POBH external miner.
October 15, 2019, 03:12:21 PM
external miner? i was a bit off last weeks, but when i checked quickly forum i found nothing about external miner hmm
October 15, 2019, 02:39:24 PM
diff was before between 2k-max 5k now? 
Diff is also not linear. October 15, 2019, 02:38:29 PM
BOTNET is back guys!!!!
extern miner is a evil
diff was 90k
ROBERTKO stop talking about me and my mining, OK? stop to lie a daj si 50 zdravasov a 20 otcenasov pre Tvoj smrtelny hriech= ZAVIST!!!!!
a ked toto vymazes, postihne Ta ukrutna pomsta za vsetko co robis ludom na tomto webe,ze im mazes texty
extern miner is a evil
diff was 90k
ROBERTKO stop talking about me and my mining, OK? stop to lie a daj si 50 zdravasov a 20 otcenasov pre Tvoj smrtelny hriech= ZAVIST!!!!!
a ked toto vymazes, postihne Ta ukrutna pomsta za vsetko co robis ludom na tomto webe,ze im mazes texty
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.
October 15, 2019, 02:20:18 PM
diff was before between 2k-max 5k now?
October 15, 2019, 02:19:34 PM
BOTNET is back guys!!!!
Why do you say BotNet is back? The external miner is faster with same hardware so I expect difficulty to go up.
The change is good because you can see more solo miner get blocks than before...
That means more decentralization instead of pool mining.
https://chainz.cryptoid.info/bbp/#!extraction
October 15, 2019, 01:59:40 PM
BOTNET is back guys!!!!
extern miner is a evil
diff was 90k
ROBERTKO stop talking about me and my mining, OK? stop to lie a daj si 50 zdravasov a 20 otcenasov pre Tvoj smrtelny hriech= ZAVIST!!!!!
a ked toto vymazes, postihne Ta ukrutna pomsta za vsetko co robis ludom na tomto webe,ze im mazes texty
extern miner is a evil
diff was 90k
ROBERTKO stop talking about me and my mining, OK? stop to lie a daj si 50 zdravasov a 20 otcenasov pre Tvoj smrtelny hriech= ZAVIST!!!!!
a ked toto vymazes, postihne Ta ukrutna pomsta za vsetko co robis ludom na tomto webe,ze im mazes texty
October 15, 2019, 01:33:18 PM
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
It was just a link to the medium article, I want confirmation that it worked
October 15, 2019, 11:08:25 AM
I'm writing a program to model the cryptocurrency economy.
I can already see its going to be fascinating and worth the time - as just doing the mental gymnastics on this has already started to reveal some of the "secrets" of success in other cryptoprojects. This I think will be invaluable in helping us re-evaluate where we are and future decision making.
"Secrets being discovered" in the cryptoworld:
Imagine a double component in each emission type (whether spent on governance, charity, mining, electric) for propensity for liquidation.
- Miner emissions : A certain % of the electric paid by miners to mine a currency are paid for already - by the household. Imagine basement hackers who cant afford the electric bill running a miner in the basement. Let us assume 50% of the basement hackers running ASIC/GPU's - the parents are paying the electric bill.
- Locked coins in sanctuary investments: Those who hold sanctuaries are reluctant to cash out the investment, unless its already profitable (by a large %).
- Coins rewarded for governance projects or charity: These coins are immediately sold on the exchange, driving down the price. We must mark elements of the project causing downward pressure, and identify every place or decision that causes a faster deceleration. (IE maintain our original goal of 10% to orphan charity).
- Miners and relationship to electric cost. The mined coins will not be sold at a loss. The low barrier is the cost of mining the coin as related to electric costs - so it is to our benefit to make it as hard/expensive as possible to mine a coin, but as user friendly as possible.
- QT and its effect on user count. This project is revealing the true nature of QT. QT tightens our emissions, and therefore controls our expenses in the short term, but it also drives away miners. As seen in #1 and 4, driving away miners is not a good thing, if the miners are doing the PR, the investing, and the word of mouth. And in #4, it is starting to reveal that coins spent for mining are not a bad thing (because miners wont sell unless they can make a profit).
This is just the beginning, and the model isn't 15% complete yet, so don't take this post with any sort of value yet.
But what I believe this project is going to reveal is something like this:
- QT could be reduced or eliminated to drive more miners in
- ABN could be reduced to drive more miners in
- PODC-GSC could be added and re-enacted, to raise the cost of mining each BBP coin (and allow us to have cancer mining)
- POOM could be reduced in total size to reestablish/cap our *governance charity* emissions at 10%
- Our orphan emissions should be completely decentralized by relying on sancs - make the sancs work for their pay
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
- We should be motivated to ensure the currency is still friendly for anonymous users - and anonymous sancs who have to pay charity bills (they can make biblepay branch office PO Box etc for their share of compassion). We should have a github page to allow anon users to complain of anything we did and honor their wishes also.
Now to finish writing the model and test these theories and rank them, and come up with more for the list.
I can already see its going to be fascinating and worth the time - as just doing the mental gymnastics on this has already started to reveal some of the "secrets" of success in other cryptoprojects. This I think will be invaluable in helping us re-evaluate where we are and future decision making.
"Secrets being discovered" in the cryptoworld:
Imagine a double component in each emission type (whether spent on governance, charity, mining, electric) for propensity for liquidation.
- Miner emissions : A certain % of the electric paid by miners to mine a currency are paid for already - by the household. Imagine basement hackers who cant afford the electric bill running a miner in the basement. Let us assume 50% of the basement hackers running ASIC/GPU's - the parents are paying the electric bill.
- Locked coins in sanctuary investments: Those who hold sanctuaries are reluctant to cash out the investment, unless its already profitable (by a large %).
- Coins rewarded for governance projects or charity: These coins are immediately sold on the exchange, driving down the price. We must mark elements of the project causing downward pressure, and identify every place or decision that causes a faster deceleration. (IE maintain our original goal of 10% to orphan charity).
- Miners and relationship to electric cost. The mined coins will not be sold at a loss. The low barrier is the cost of mining the coin as related to electric costs - so it is to our benefit to make it as hard/expensive as possible to mine a coin, but as user friendly as possible.
- QT and its effect on user count. This project is revealing the true nature of QT. QT tightens our emissions, and therefore controls our expenses in the short term, but it also drives away miners. As seen in #1 and 4, driving away miners is not a good thing, if the miners are doing the PR, the investing, and the word of mouth. And in #4, it is starting to reveal that coins spent for mining are not a bad thing (because miners wont sell unless they can make a profit).
This is just the beginning, and the model isn't 15% complete yet, so don't take this post with any sort of value yet.
But what I believe this project is going to reveal is something like this:
- QT could be reduced or eliminated to drive more miners in
- ABN could be reduced to drive more miners in
- PODC-GSC could be added and re-enacted, to raise the cost of mining each BBP coin (and allow us to have cancer mining)
- POOM could be reduced in total size to reestablish/cap our *governance charity* emissions at 10%
- Our orphan emissions should be completely decentralized by relying on sancs - make the sancs work for their pay
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
- We should be motivated to ensure the currency is still friendly for anonymous users - and anonymous sancs who have to pay charity bills (they can make biblepay branch office PO Box etc for their share of compassion). We should have a github page to allow anon users to complain of anything we did and honor their wishes also.
Now to finish writing the model and test these theories and rank them, and come up with more for the list.
October 15, 2019, 09:37:01 AM
This is just an idea, but in the vein of completely decentralizing biblepay, where we create a true DAC (decentralized autonomous orphan charity), (as we currently give 10% of our blockchain emissions to orphan charities who are > 75% efficient), it would be an interesting idea if we held each individual sanctuary to be responsible for liquidating their "share percentage" of our monthly emissions and maintaining a compassion account and paying their own share of the compassion bill.
For example, we could require a sanctuary to handle the receipt of 50,000 bbp each, so a person who owns 3 sancs would be responsible for receiving 150,000 bbp per month in orphan emissions, liquidating these on SX, and paying for that number of orphans. Since the sanctuary is technically Biblepay property (in some respects) we could require the ability to audit the account and require the sanc to upload the PDF each month (of the payment to compassion) along with the orphan IDs.
A sanctuary who does not comply gets POSE banned.
Just wondering if this idea would help decentralize biblepay to the point where our operations would be fully decentralized.
EDIT: For sanctuaries who live in countries where they cant pay the compassion bill in USD, they could sponsor the required number of orphans through Cameroon-One and pay the monthly fee in BBP. We could be flexible in filling compassion, then cameroon, and Kairos with Sancs who would rather deal with BBP. Kairos also accepts BBP as a form of payment. We may even be able to use the sanctuary keypair to allow access to store the DSQL record (signed by the sanc) - that would give a really nice touch to the authenticity of the expense per month in DSQL.
(It would also allow us to control the permissions to upload the record).
EDIT2: Thinking about theft of the BBP by the sanctuary (say they set up a sanc just to steal the orphan funds), I think we can control that by establishing a sanctuary start date, and requiring the 'number of sancs owned' by CPK - IE the monthly commitment controlled by that party - to first establish the orphans and upload the *first* PDF of the payment before starting to pay the sanc rewards. IE, we would modify the core wallet to know if a sanc is "in good standing" or not by linking the sanc to its DSQL payment screen. Sancs in good standing start receiving rewards and they continue as long as the orphan expenses are in good standing. If this ceases to be - the sanc stops being paid - and we are always remunerating the sancs monthly orphan expenses in arrears (another words, they cant steal that months budget because they paid that months orphans commitments first - perpetually) til the last month. When the sanc terminates, we allow the last payment to be paid from governance to the terminated sanc.
For example, we could require a sanctuary to handle the receipt of 50,000 bbp each, so a person who owns 3 sancs would be responsible for receiving 150,000 bbp per month in orphan emissions, liquidating these on SX, and paying for that number of orphans. Since the sanctuary is technically Biblepay property (in some respects) we could require the ability to audit the account and require the sanc to upload the PDF each month (of the payment to compassion) along with the orphan IDs.
A sanctuary who does not comply gets POSE banned.
Just wondering if this idea would help decentralize biblepay to the point where our operations would be fully decentralized.
EDIT: For sanctuaries who live in countries where they cant pay the compassion bill in USD, they could sponsor the required number of orphans through Cameroon-One and pay the monthly fee in BBP. We could be flexible in filling compassion, then cameroon, and Kairos with Sancs who would rather deal with BBP. Kairos also accepts BBP as a form of payment. We may even be able to use the sanctuary keypair to allow access to store the DSQL record (signed by the sanc) - that would give a really nice touch to the authenticity of the expense per month in DSQL.
(It would also allow us to control the permissions to upload the record).
EDIT2: Thinking about theft of the BBP by the sanctuary (say they set up a sanc just to steal the orphan funds), I think we can control that by establishing a sanctuary start date, and requiring the 'number of sancs owned' by CPK - IE the monthly commitment controlled by that party - to first establish the orphans and upload the *first* PDF of the payment before starting to pay the sanc rewards. IE, we would modify the core wallet to know if a sanc is "in good standing" or not by linking the sanc to its DSQL payment screen. Sancs in good standing start receiving rewards and they continue as long as the orphan expenses are in good standing. If this ceases to be - the sanc stops being paid - and we are always remunerating the sancs monthly orphan expenses in arrears (another words, they cant steal that months budget because they paid that months orphans commitments first - perpetually) til the last month. When the sanc terminates, we allow the last payment to be paid from governance to the terminated sanc.
October 15, 2019, 08:10:58 AM
Wow what a project this looks so fascinating. I think people have forgotten religion because of money and cryptocurrencies but I think this project will definitely increase the contributions done by people in Charity and religious programs. I am surely going to invest in this project can someone help me with the procedure?
We have a lot of coins for sale on:
https://www.southxchange.com/Market/Book/BBP/BTC
Some liquidity algo over there has really built up a lot to sell (by being our biggest buyer and taking advantage of the monthly orphan liquidation).
Hopefully they will cease to do this eventually, or may God strengthen this project to overcome the bot.
Anyway, "theoretically" in the long run, as long as we increase our user base, with our deflation we will overcome our low price and rise.
We have a 19.5% annual deflation rate.
=-=-=-=-=-=-=-=
On a side note all, now that our POBH external miner appears to be working (I ran all night, yay), I'm going to start making a model of a cryptocurrency economy, where we can plug in different values for theoretical effects, and try to reverse engineer Dash's success in the model. Then we can see the pros and cons of our decisions (theoretically). And this might lead us to tweak/adjust something we did to grow Biblepay.
October 15, 2019, 08:06:04 AM
diff is pretty high last days, what happens? new miners?
new miners?I think maybe Slovakia has plugged the rack back in...
October 15, 2019, 06:12:45 AM
Wow what a project this looks so fascinating. I think people have forgotten religion because of money and cryptocurrencies but I think this project will definitely increase the contributions done by people in Charity and religious programs. I am surely going to invest in this project can someone help me with the procedure?
October 14, 2019, 11:51:00 PM
diff is pretty high last days, what happens? new miners?
new miners? October 14, 2019, 01:37:40 PM
BBPMiner
1.0.0.4-Leisure Upgrade
- Added -x to display current version (added version at start also)
- Handle JSON nowork condition
- Expand buffer size of Work to attempt to prevent crash
- Remove --coinbase-sig (incompatible option with Evo)
- Remove dead variables
- Ensure nonces are separated
** I'm still not 100% sure if we got it, but we got the bug Orbis reported (invalid json), and we handled the new stack trace, please re-test **
Binaries:
https://github.com/biblepay/cpuminer/tree/master/binaries
EDIT: We will get the coinbase address working when we start working on the pool side. First lets address the crash.
1.0.0.4-Leisure Upgrade
- Added -x to display current version (added version at start also)
- Handle JSON nowork condition
- Expand buffer size of Work to attempt to prevent crash
- Remove --coinbase-sig (incompatible option with Evo)
- Remove dead variables
- Ensure nonces are separated
** I'm still not 100% sure if we got it, but we got the bug Orbis reported (invalid json), and we handled the new stack trace, please re-test **
Binaries:
https://github.com/biblepay/cpuminer/tree/master/binaries
EDIT: We will get the coinbase address working when we start working on the pool side. First lets address the crash.
Thanks Rob.
I'm already testing this version and hope to solve the crash or stuck problem.
October 14, 2019, 12:11:30 PM
BBPMiner
1.0.0.4-Leisure Upgrade
- Added -x to display current version (added version at start also)
- Handle JSON nowork condition
- Expand buffer size of Work to attempt to prevent crash
- Remove --coinbase-sig (incompatible option with Evo)
- Remove dead variables
- Ensure nonces are separated
** I'm still not 100% sure if we got it, but we got the bug Orbis reported (invalid json), and we handled the new stack trace, please re-test **
Binaries:
https://github.com/biblepay/cpuminer/tree/master/binaries
EDIT: We will get the coinbase address working when we start working on the pool side. First lets address the crash.
1.0.0.4-Leisure Upgrade
- Added -x to display current version (added version at start also)
- Handle JSON nowork condition
- Expand buffer size of Work to attempt to prevent crash
- Remove --coinbase-sig (incompatible option with Evo)
- Remove dead variables
- Ensure nonces are separated
** I'm still not 100% sure if we got it, but we got the bug Orbis reported (invalid json), and we handled the new stack trace, please re-test **
Binaries:
https://github.com/biblepay/cpuminer/tree/master/binaries
EDIT: We will get the coinbase address working when we start working on the pool side. First lets address the crash.
Jump to: