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

[sunk818]

2) On changing the receive address, it does change the blockhash, but then it also reveals the "key" to breaking the idea you posted about choosing the winner.  
Timestamp wont help either.  Either one can be manipulated by the miner, and make themselves the winner based on the table.

Maybe take sanctuary recipient address instead? Or a combination of sanctuary and miner? Or include BibleHash... Or taking the last two digits/letters (16^2) and you have 1 in 256 chance miner will get the block. I'm sure there's a sweet spot between complexity and hack proof. If you can distribute rewards to different solo miners more often, you may not even need a pool. Then One Click Miner Configuration is all that you need

@jsheets the One Click Miner Configuration line ending issues should be all fixed now. I'll do some more testing, but I can confirm 1.4.4.9 works great under macOS .

[1715032352]

1715032352

[1715032352]

1715032352

[1715032352]

1715032352

[bible_pay]

EDIT: Please confirm the BBP Version is 1.4.4.8+ in the about page?  Pre 1448 will get rejected by the network.



We don't have an rpm, but you can still compile it from here:
https://github.com/biblepay/biblepay-evolution

Thanks!


Oh yes, it's for a raspberry pi. I just clone the master branch, but it seems to have no effect and me node remains rejected as if it was the pure 1448 version. (not 1448+). Are the last commits in the master branch or some other? Sorry to bother with these newbie doubts.

Yeah, the last commits are there in master, so it might be that you were temporarily banned.
Please ensure your system time is correct within 10 seconds and your timezone is correct.

Here is an addnode:

addnode 198.46.160.252 onetry

Once you have a good addnode, you should be able to sync until the ban drops off.

EDIT: Btw, from the cli, you can do a getinfo and see if its 1.4.4.8+.

[bible_pay]

2) On changing the receive address, it does change the blockhash, but then it also reveals the "key" to breaking the idea you posted about choosing the winner.  
Timestamp wont help either.  Either one can be manipulated by the miner, and make themselves the winner based on the table.

Maybe take sanctuary recipient address instead? Or a combination of sanctuary and miner? Or include BibleHash... Or taking the last two digits/letters (16^2) and you have 1 in 256 chance miner will get the block. I'm sure there's a sweet spot between complexity and hack proof. If you can distribute rewards to different solo miners more often, you may not even need a pool. Then One Click Miner Configuration is all that you need

@jsheets the One Click Miner Configuration line ending issues should be all fixed now. I'll do some more testing, but I can confirm 1.4.4.9 works great under macOS .

We must have a misconception here.
Anti-Bot-Net:  Limits "rich kids with too many computers" or a rogue hacker who installed 300 copies of biblepay in the school system.

ABN with UTXO:  Limits miners to those that hold 125K min abn weight.  Basically fulfilling the above fully.

I thought earlier, when you were discussing ideas of distribution you were trying to limit the reward to One block per distinct receive address (which wont work because it can be hacked). 
Trying to limit rewards equally across segments using biblehashes or blocks or sanc addresses is just a fallacy; I dont see how a miner would not be able to hack that; they just increase hashpower when they know their block is going to win;  this equals the same we have now: the random luck of a winning hash based on hashpower.

Earlier when I mentioned CPIDs, I used them because you have to *work* hard to build up RAC and then sign the cpid - so you truly are limiting the reward to a worthy recipient (similar to how we are rewarding through minimum UTXOs now - you must prove you have a stake in BBP to mine).

Please think about it, and if you have a full method to limit rewards to single entities feel free to post; but I dont believe one exists in *open source software*; Manna uses telephone numbers (SMS codes) - but that can be hacked by buying multiple phone cards etc.

[s1mbad]

[/quote]

Yeah, the last commits are there in master, so it might be that you were temporarily banned.
Please ensure your system time is correct within 10 seconds and your timezone is correct.

Here is an addnode:

addnode 198.46.160.252 onetry

Once you have a good addnode, you should be able to sync until the ban drops off.

EDIT: Btw, from the cli, you can do a getinfo and see if its 1.4.4.8+.


[/quote]

Thank you! I had just wgeted the .gz file from the last release. Now with git clone the commits came up and it's all right.

[sunk818]

We must have a misconception here.
Anti-Bot-Net:  Limits "rich kids with too many computers" or a rogue hacker who installed 300 copies of biblepay in the school system.
...
Earlier when I mentioned CPIDs, I used them because you have to *work* hard to build up RAC and then sign the cpid - so you truly are limiting the reward to a worthy recipient (similar to how we are rewarding through minimum UTXOs now - you must prove you have a stake in BBP to mine).

Please think about it, and if you have a full method to limit rewards to single entities feel free to post; but I dont believe one exists in *open source software*; Manna uses telephone numbers (SMS codes) - but that can be hacked by buying multiple phone cards etc.

If you think ABN is better to keep in BiblePay, I have no objection. I personally like ABN.  Weren't you just considering removing it though? I offered a potential alternative. Matching last 2 digit of block hash helps distribute the mining rewards which has a similar result to ABN without the staking requirements.

BOINC w/ CPID is a great alternative as well (since the oracle issue is minimal). If a CPID wins a block, maybe they can't win a block for the next 10 blocks? What's your reasoning for 16 tiers? Why not 10, or 7 tiers? I used to think science & BiblePay don't mix, but I've changed my mind after meeting oncoapop3. I see science and Christianity as a powerful and peaceful combination.

[bible_pay]

2) On changing the receive address, it does change the blockhash, but then it also reveals the "key" to breaking the idea you posted about choosing the winner.  
Timestamp wont help either.  Either one can be manipulated by the miner, and make themselves the winner based on the table.

Maybe take sanctuary recipient address instead? Or a combination of sanctuary and miner? Or include BibleHash... Or taking the last two digits/letters (16^2) and you have 1 in 256 chance miner will get the block. I'm sure there's a sweet spot between complexity and hack proof. If you can distribute rewards to different solo miners more often, you may not even need a pool. Then One Click Miner Configuration is all that you need

@jsheets the One Click Miner Configuration line ending issues should be all fixed now. I'll do some more testing, but I can confirm 1.4.4.9 works great under macOS .

We must have a misconception here.
Anti-Bot-Net:  Limits "rich kids with too many computers" or a rogue hacker who installed 300 copies of biblepay in the school system.

ABN with UTXO:  Limits miners to those that hold 125K min abn weight.  Basically fulfilling the above fully.

I thought earlier, when you were discussing ideas of distribution you were trying to limit the reward to One block per distinct receive address (which wont work because it can be hacked).  
Trying to limit rewards equally across segments using biblehashes or blocks or sanc addresses is just a fallacy; I dont see how a miner would not be able to hack that; they just increase hashpower when they know their block is going to win;  this equals the same we have now: the random luck of a winning hash based on hashpower.

Earlier when I mentioned CPIDs, I used them because you have to *work* hard to build up RAC and then sign the cpid - so you truly are limiting the reward to a worthy recipient (similar to how we are rewarding through minimum UTXOs now - you must prove you have a stake in BBP to mine).

Please think about it, and if you have a full method to limit rewards to single entities feel free to post; but I dont believe one exists in *open source software*; Manna uses telephone numbers (SMS codes) - but that can be hacked by buying multiple phone cards etc.

Curious, why are we talking about ABN? Weren't you just considering removing ABN? I offered a potential alternative. If you think ABN is better to have in BiblePay, I have no objection. I personally like ABN. I think CPID w/ BOINC is very reliable and a great alternative as well. I used to think science & BiblePay don't mix, but after meeting people like oncoapop3, I see science and Christianity as a powerful and peaceful combination.

LOL, I never said I disliked abn.  I like it.  I said maybe the fact that we are "too clubby" right now (an exclusive club) to have the privilege of mining BBP, and I feel we have a low user count, it might warrant consideration in disabling it until we have more than 100 miners, and I brought up the discussion with the very clear statement that "Is it better to be clubby with no users" or "be with a botnet and a lot of new users".  I'm trying to grow the user base, so please don't say Im contradicting myself.  If we had one new user per day, I would not raise lowering the ABN value.  

You offered a potential alternative?  LOL, no-- you didn't - I have answered every one of your posts, and you offered only fallacies (no alternatives).  I said Quote unquote: In open source software I dont know of an alternative (to regulate botnets) other than :  UTXOs or CPIDs.  I mentioned phone numbers, but with Manna I dont believe thats an alternative.

I fully agree that BOINC could potentially augment BiblePay - especially from the perspective that we *welcome* sinners and scientists to be saved (I'm not accusing scientists of being atheist, I realize a lot of Christian scientists and Messianic Jews are out there, not a problem, you are saved and welcome too).  Thats the whole idea; to expose blockchain geeks to the gospel!  The more the merrier.  I primarily stopped PODC when I felt like we couldnt support it because it was detracting from our gospel development (with only 2 active devs - MIP and I).  Its not impossible to add cancer mining someday, but we have to fully think that through before we commit to it.  I dont want to do it at the expense of a new prayer forum and DSQL ecosystem, etc.

I recommend re-reading this post:
https://bitcointalk.org/index.php?topic=2388064.msg52633073#msg52633073

[sunk818]

"Is it better to be clubby with no users" or "be with a botnet and a lot of new users"

I'm sure there's in between the continuum. It doesn't have to be one or the other.

[bible_pay]

"Is it better to be clubby with no users" or "be with a botnet and a lot of new users"

I'm sure there's in between the continuum. It doesn't have to be one or the other.

I think thats the vote to lower ABN.

I just want reiterate, there is no other known way to distribute rewards, other than UTXO or CPID.  Blockhash schemes wont work; if you have one you believe would work feel free to re-post the entire idea.

[jsheets1970]

"Is it better to be clubby with no users" or "be with a botnet and a lot of new users"

I'm sure there's in between the continuum. It doesn't have to be one or the other.

I think thats the vote to lower ABN.

I just want reiterate, there is no other known way to distribute rewards, other than UTXO or CPID.  Blockhash schemes wont work; if you have one you believe would work feel free to re-post the entire idea.

One point I would make is that lowering the ABN by itself does not solve our issue unless ABN is 0.. The configuration file and setup of workers is confusing to people. Just look at slovakia's issue today. We need to ensure that there is CLEAR documentation setup out there on the 2 worker ID values and how to set up those workers on the pool page and how to put them in the configuration file. I for one believe that there should be another download out on the wallet page which has both a sample configuration file and a readme/PDF on how to setup workers. If people do not understand the setup and configured their worker improperly they will not be able to take advantage of pool funded mining.

[bible_pay]

"Is it better to be clubby with no users" or "be with a botnet and a lot of new users"

I'm sure there's in between the continuum. It doesn't have to be one or the other.

I think thats the vote to lower ABN.

I just want reiterate, there is no other known way to distribute rewards, other than UTXO or CPID.  Blockhash schemes wont work; if you have one you believe would work feel free to re-post the entire idea.

One point I would make is that lowering the ABN by itself does not solve our issue unless ABN is 0.. The configuration file and setup of workers is confusing to people. Just look at slovakia's issue today. We need to ensure that there is CLEAR documentation setup out there on the 2 worker ID values and how to set up those workers on the pool page and how to put them in the configuration file. I for one believe that there should be another download out on the wallet page which has both a sample configuration file and a readme/PDF on how to setup workers. If people do not understand the setup and configured their worker improperly they will not be able to take advantage of pool funded mining.

Yeah, we could use a dedicated single page PDF for ABN-Funded (turnkey) mining, and maybe a separate simple single page PDF for Non-funded (standard ABN) mining.

Thats where the help of the community should come in.

I'm working on the technical issues; if we could have these guides re-written we will have them added to the OP post, the pool and the website.

Remember we do have a Getting Started with Evo guide (and your probably aware of that) and its a little complicated.  Togo recently added a couple more guide links to the OP post (for mining also).  But they may be the same Evo links.

[jsheets1970]

"Is it better to be clubby with no users" or "be with a botnet and a lot of new users"

I'm sure there's in between the continuum. It doesn't have to be one or the other.

I think thats the vote to lower ABN.

I just want reiterate, there is no other known way to distribute rewards, other than UTXO or CPID.  Blockhash schemes wont work; if you have one you believe would work feel free to re-post the entire idea.

One point I would make is that lowering the ABN by itself does not solve our issue unless ABN is 0.. The configuration file and setup of workers is confusing to people. Just look at slovakia's issue today. We need to ensure that there is CLEAR documentation setup out there on the 2 worker ID values and how to set up those workers on the pool page and how to put them in the configuration file. I for one believe that there should be another download out on the wallet page which has both a sample configuration file and a readme/PDF on how to setup workers. If people do not understand the setup and configured their worker improperly they will not be able to take advantage of pool funded mining.

Yeah, we could use a dedicated single page PDF for ABN-Funded (turnkey) mining, and maybe a separate simple single page PDF for Non-funded (standard ABN) mining.

Thats where the help of the community should come in.

I'm working on the technical issues; if we could have these guides re-written we will have them added to the OP post, the pool and the website.

Remember we do have a Getting Started with Evo guide (and your probably aware of that) and its a little complicated.  Togo recently added a couple more guide links to the OP post (for mining also).  But they may be the same Evo links.

Well... This is going to sound funny but I have never even known of these guides that were out there and have been part of the community for close to 4 months. I really just picked up on various components and configurations through reading this forum and asking questions. That might intimidate some. Where are these guides, could you post a link.. I have fought through a lot of this stuff and might be able to put together a simple guide or help others with my knowledge. Please share the links and will see what is there.

[bible_pay]

"Is it better to be clubby with no users" or "be with a botnet and a lot of new users"

I'm sure there's in between the continuum. It doesn't have to be one or the other.

I think thats the vote to lower ABN.

I just want reiterate, there is no other known way to distribute rewards, other than UTXO or CPID.  Blockhash schemes wont work; if you have one you believe would work feel free to re-post the entire idea.

One point I would make is that lowering the ABN by itself does not solve our issue unless ABN is 0.. The configuration file and setup of workers is confusing to people. Just look at slovakia's issue today. We need to ensure that there is CLEAR documentation setup out there on the 2 worker ID values and how to set up those workers on the pool page and how to put them in the configuration file. I for one believe that there should be another download out on the wallet page which has both a sample configuration file and a readme/PDF on how to setup workers. If people do not understand the setup and configured their worker improperly they will not be able to take advantage of pool funded mining.

Yeah, we could use a dedicated single page PDF for ABN-Funded (turnkey) mining, and maybe a separate simple single page PDF for Non-funded (standard ABN) mining.

Thats where the help of the community should come in.

I'm working on the technical issues; if we could have these guides re-written we will have them added to the OP post, the pool and the website.

Remember we do have a Getting Started with Evo guide (and your probably aware of that) and its a little complicated.  Togo recently added a couple more guide links to the OP post (for mining also).  But they may be the same Evo links.

Well... This is going to sound funny but I have never even known of these guides that were out there and have been part of the community for close to 4 months. I really just picked up on various components and configurations through reading this forum and asking questions. That might intimidate some. Where are these guides, could you post a link.. I have fought through a lot of this stuff and might be able to put together a simple guide or help others with my knowledge. Please share the links and will see what is there.

Although there is one on biblepay.org under mining, the two in the OP post here (Mining Guides) are a little better:

Mining Guides:

Quick Start
wiki.biblepay.org/Quick_Start

Windows
reddit.com/r/BiblePay/comments/6umlqq/how_to_mine_biblepay_on_windows/

Linux
reddit.com/r/BiblePay/comments/6ummuj/how_to_mine_biblepay_on_linux/


I have been giving out the Getting started with Evo guide on the wiki, (see in mining biblepay on windows, the wiki guides).


Thanks, I appreciate it also.

[bible_pay]

Btw, while on the subject of newbies entering BBP, Sun made the brilliant suggestion of somehow capping returns on GSCs on the rich - I think the original suggestion was cap coinage at 1 day.

Now the underlying motive is good - spread the daily 250K GSC reward out to more users, and therefore attract more people.

But the contention is that if we cap coin*age with any type of limit then it could be gamed.

So, I have the identical view here:  I'm completely open to ideas that distribute rewards further to newbies, but, I know of no possible way to actually do that.

[sunk818]

But the contention is that if we cap coin*age with any type of limit then it could be gamed.

Anything can be gamed, but make it hard enough and hopefully you'll get a 80/20 split (80% of people will not intentionally cheat).

"Is it better to be clubby with no users" or "be with a botnet and a lot of new users"

If you want to make it easy for people to participate, remove the barriers. New BBP member should be ready to go in less than 7 minutes after wallet download and sync. No ABN, no set up for pool mining. Provide a default biblepay.conf that has everything they need to start mining. GSC could be easier to setup too, but it'd be at the cost of other features. Documentation is good up to point, but making it so easy documentation is minimal.

Well... This is going to sound funny but I have never even known of these guides that were out there and have been part of the community for close to 4 months.

Let's put a readme.txt that points to all the relevant links. Include this in the same folder as biblepay-qt.exe is. Last part of the Windows installation is a checkbox (default on) that asks to open the readme.txt

Put FAQ items on a screen on in overview. Mining yes/no, abninfo, solo vs pool mining, hash per second, current abn weight (exec getabnweight 125000 1), etc.

Here's a sample biblepay.conf I would use.

Code:

# -------
# mining
# fill this in explaining what each settings and numbers mean
# ------
gen=1
genproclimit=-1
minersleep=325

# -----
# generic smart contract (gsc)
# -----
disablegsctransmission=1
pog_coinagepercentage=-1
pog_foundationdonation=-1
healing_coinagepercentage=-1
healing_foundationdonation=-1
cameroon-one_coinagepercentage=-1
cameroon-one_foundationdonation=-1
gscclientminerfrequency=43200
changequantity=10

[bible_pay]

But the contention is that if we cap coin*age with any type of limit then it could be gamed.

Anything can be gamed, but make it hard enough and hopefully you'll get a 80/20 split (80% of people will not intentionally cheat).

"Is it better to be clubby with no users" or "be with a botnet and a lot of new users"

If you want to make it easy for people to participate, remove the barriers. New BBP member should be ready to go in less than 7 minutes after wallet download and sync. No ABN, no set up for pool mining. Provide a default biblepay.conf that has everything they need to start mining. GSC could be easier to setup too, but it'd be at the cost of other features. Documentation is good up to point, but making it so easy documentation is minimal.

Well... This is going to sound funny but I have never even known of these guides that were out there and have been part of the community for close to 4 months.

Let's put a readme.txt that points to all the relevant links. Include this in the same folder as biblepay-qt.exe is. Last part of the Windows installation is a checkbox (default on) that asks to open the readme.txt

Put FAQ items on a screen on in overview. Mining yes/no, abninfo, solo vs pool mining, hash per second, current abn weight (exec getabnweight 125000 1), etc.

Here's a sample biblepay.conf I would use.

Code:

# -------
# mining
# fill this in explaining what each settings and numbers mean
# ------
gen=1
genproclimit=-1
minersleep=325

# -----
# generic smart contract (gsc)
# -----
disablegsctransmission=1
pog_coinagepercentage=-1
pog_foundationdonation=-1
healing_coinagepercentage=-1
healing_foundationdonation=-1
cameroon-one_coinagepercentage=-1
cameroon-one_foundationdonation=-1
gscclientminerfrequency=43200
changequantity=10

I agree with everything in this post after the first sentence, I think this is a very good post and very valuable advice.

However I have a very strong disagreement with this:
Rob: But the contention is that if we cap coin*age with any type of limit then it could be gamed.
Sun: Anything can be gamed, but make it hard enough and hopefully you'll get a 80/20 split (80% of people will not intentionally cheat).

No, we cannot do that.  The element that you underestimate within that logic allows one single bad actor (and they will come) to circumvent the entire reward set for all the rest, and that ends up lowering the integrity of the entire coin (and once that happens it has no value at all, and then people dont trust you).

Right now, we have fully reconcilable emissions going in a hard way to sanctuaries who provide service, to heat miners who officially mined real POBH blocks, to POOM miners who really sponsored children, and finally to POG users who really tithed.  All coin*age given back is reconcilable 100%.  So the environment is 100% trustworthy right now.  I would never want it any other way.  However, the environment has the barriers you mentioned above, and the financial entry barriers.  

So another words, I assert that a coin distribution model cannot be "leaky" or "hackable" with any less than 100% integrity.  Im still open to ideas for spreading the money from the rich to the poor (similar to the coin*age cap idea etc), but so far there hasnt been any.

Also, on the "anything can be gamed" comment:  Not true.  We cannot be gamed right now, because the model is not flawed. 

[MIP]

***Mobile wallets update***

For Android and iOS:
Added compatibilities with 1.4.4.8 protocol

Available now in Google Play and App Store.

[bible_pay]

**** LIQUIDATION REMINDER for CoinExchange.IO ****


All - Please remember to withdraw all your assets from CoinExchange.IO within the next 10 days.

[slovakia]

that smart contracts=POG working with bugs
exec roi showed bad informations for rewards

tried send different amounts with different 1-10 days and received different rewards    still in negative rewards.....omg ... who getting huge rewards then?

any experiences with this bug?

[bible_pay]

that smart contracts=POG working with bugs
exec roi showed bad informations for rewards

tried send different amounts with different 1-10 days and received different rewards    still in negative rewards.....omg ... who getting huge rewards then?

any experiences with this bug?

No, its not a bug, its user error (I believe).

Could you explain one bug we have in more detail?

I didnt think so.

Please don't take the Lord's name in vain anymore on this channel.

[sunk818]

that smart contracts=POG working with bugs

No, its not a bug, its user error (I believe).

It is not a bug, just takes some extra reading to understand.

Rob -- I bet its not easy to gather up all the PoG tithes from 149055 to 149259 and pay it out on 149260?