Topic: BiblePay - New Coin Launch - Official Thread - page 29. (Read 119833 times)
Pay the sins for posiblility of mining... that have nothing common with chairity. Even worse it doesn't have anything common with christianity. Or wait it has, but if we will be in middleages... deus vult!
But I'm of the opinion that forcing any activity is going to be alienating and damaging to the coin.
Agree! The "repent" will make this coin only for religion instead of charity. The dev should use pos instead of pow since he is strong against mining. So Ive been researching the difference between X11 and F7000 and have uncovered some more info related to HPS consistency across all processors platforms and instance counts.
Some of you have really been hard on me, especially those who cant grasp the distinction between a "node level mutex" and a "processor" mutex. You even went as far as to say the BibleHash itself is inconsistent. One thing Ive learned over 30 years in software, is nothing about a computer or its software is inconsistent. (Unless someone puts a rand() statement in the code). Another words, every "hard" problem that Ive seen over the years, in the end, always has a very clear reason.
Let me explain the difference between a node mutex and a processor mutex. A node mutex is one where an instance of the software is forced to wait somewhere in the
*instance* of a program for a memory space to be available. A processor mutex is one that consumes the entire processor and it does not have to wait except for new work, and the entire server is frozen in what appears to be a locked state (btw, a crash is very different than a consumed processor).
So with BiblePay, with Pre-F7000, we had a processor mutex, in the sense that one had to buy more hash power to hash against the money supply. With F7000, the goal was originally more of a much stronger line of defense against GPU porting, hence the reason we added the node mutex. Ill stop here and explain. There are two places in BibleHash that are extremely hard or impossible to run on a GPU: asking the node to go back in the chain for a block index hash, or for example a transaction hash. Since the node level instance stops hashing while it waits for the data, the other mining threads slow down. Otoh, if you run multiple degraded instances on one server, you have parallel stops. However, what I dont like about that is it encourages low quality instances whereas I believe it is healther for us as a community to have higher quality instances.
So in light of this, the basic explanation is that F7000 does do its job in preventing BibleHash from running on a GPU, but it promotes the user to run as many low quality nodes as possible to squeeze as many BBP per hour from our community.
I think the answer to this is during the Christmas update (Sanctuaries), we release F8000 with a few more enhancements to fix the problem (we can test these in testnet as soon as available). #1: Add a math problem to BibleHash. This would force the processor to execute a few hundred K of instructions deterministically but unknown at the time of the hash (IE Block hash + timestamp hashed) so no one can predetermine the problem, and this solution would be similar to executing N X11's hashes for a second or so, thereby changing the state of the nodes miner back to a processor mutex level, thereby solving the degrading network problem.
The other thing I would like to introduce before Christmas update is making mining more of a privilege. I was thinking, instead of asking BiblePay to pay you simply because you plug a computer in and *want* to hash, what if BiblePay wants you to contribute to the community? I was thinking at the very least, the node will somehow need to ask the miner to Repent for sins and make a blog of progress. Maybe we make the mining software require a Repentant sin in the block, (IE Think of the 40 mortal sins listed in Send Money (in the wallet) | check Repent | Look at the dropdown values), maybe each week, the miner must repent of a sin, and describe how they are doing in their walk of repenting for sins in the message. If no repentance is being given, no mining is awarded. But each week, either a new description in the walk of a sin free life must be added, or - a new sin to be worked on, this way we can hash the repentance information and ensure it is changing once every 7 days (this way, if its done once a week, its similar to keeping the Sabbath). So our miner would help you Keep the Sabbath. You will wonder, how will we enforce it? I think we can have a REST URI built in, and have the sanctuaries run the RESTful web service, and ban miners who arent repenting coherently. Their miners would be shutdown. It could be a service we require of the sanctuaries.
I think these two features would make BiblePay consistent across all platforms, and require a level of participation to weed & feed out the wheat from the chaff in the community.
Some of you have really been hard on me, especially those who cant grasp the distinction between a "node level mutex" and a "processor" mutex. You even went as far as to say the BibleHash itself is inconsistent. One thing Ive learned over 30 years in software, is nothing about a computer or its software is inconsistent. (Unless someone puts a rand() statement in the code). Another words, every "hard" problem that Ive seen over the years, in the end, always has a very clear reason.
Let me explain the difference between a node mutex and a processor mutex. A node mutex is one where an instance of the software is forced to wait somewhere in the
*instance* of a program for a memory space to be available. A processor mutex is one that consumes the entire processor and it does not have to wait except for new work, and the entire server is frozen in what appears to be a locked state (btw, a crash is very different than a consumed processor).
So with BiblePay, with Pre-F7000, we had a processor mutex, in the sense that one had to buy more hash power to hash against the money supply. With F7000, the goal was originally more of a much stronger line of defense against GPU porting, hence the reason we added the node mutex. Ill stop here and explain. There are two places in BibleHash that are extremely hard or impossible to run on a GPU: asking the node to go back in the chain for a block index hash, or for example a transaction hash. Since the node level instance stops hashing while it waits for the data, the other mining threads slow down. Otoh, if you run multiple degraded instances on one server, you have parallel stops. However, what I dont like about that is it encourages low quality instances whereas I believe it is healther for us as a community to have higher quality instances.
So in light of this, the basic explanation is that F7000 does do its job in preventing BibleHash from running on a GPU, but it promotes the user to run as many low quality nodes as possible to squeeze as many BBP per hour from our community.
I think the answer to this is during the Christmas update (Sanctuaries), we release F8000 with a few more enhancements to fix the problem (we can test these in testnet as soon as available). #1: Add a math problem to BibleHash. This would force the processor to execute a few hundred K of instructions deterministically but unknown at the time of the hash (IE Block hash + timestamp hashed) so no one can predetermine the problem, and this solution would be similar to executing N X11's hashes for a second or so, thereby changing the state of the nodes miner back to a processor mutex level, thereby solving the degrading network problem.
The other thing I would like to introduce before Christmas update is making mining more of a privilege. I was thinking, instead of asking BiblePay to pay you simply because you plug a computer in and *want* to hash, what if BiblePay wants you to contribute to the community? I was thinking at the very least, the node will somehow need to ask the miner to Repent for sins and make a blog of progress. Maybe we make the mining software require a Repentant sin in the block, (IE Think of the 40 mortal sins listed in Send Money (in the wallet) | check Repent | Look at the dropdown values), maybe each week, the miner must repent of a sin, and describe how they are doing in their walk of repenting for sins in the message. If no repentance is being given, no mining is awarded. But each week, either a new description in the walk of a sin free life must be added, or - a new sin to be worked on, this way we can hash the repentance information and ensure it is changing once every 7 days (this way, if its done once a week, its similar to keeping the Sabbath). So our miner would help you Keep the Sabbath. You will wonder, how will we enforce it? I think we can have a REST URI built in, and have the sanctuaries run the RESTful web service, and ban miners who arent repenting coherently. Their miners would be shutdown. It could be a service we require of the sanctuaries.
I think these two features would make BiblePay consistent across all platforms, and require a level of participation to weed & feed out the wheat from the chaff in the community.
Thank you for the clear explanation of the changes.
One risk to the "repent" to mine is that you would encourage "false repentance" which in some circles is tantamount to encouraging additional sin. You also run the risk of alienating the people who are non-religious but have a spirit to help. If I'm an honest person but agnostic, but I enjoy the idea that a large portion of this coin benefits the less fortunate, a forced repentance puts one in a tough situation. Do you be honest and say, "I'm agnostic and there is good and evil but no metric for sin", do you go against your moral code and lie saying "today I ate shellfish" or do you drop the coin? Furthermore, depending on who is the arbiter of if the repentance is coherent, you risk the gatekeepers deciding what is and isn't a sin, which is a pretty complex thought seeing as how most people pretty much pick and choose what parts of the Bible are "right" (no adultery) and "outdated" (no shellfish).
In the end, I think the repentance concept is interesting but you would end up alienating a good portion of the user base or at a minimum not have the desired results. A better option might be for there to be some task to do. Any task is going to be "gamed" at rate that is directly proportional to the inconvenience of it and you have to consider the number of users that will be running from the command line. Having repentance as an option in the wallet is good, much like prayer requests. But I'm of the opinion that forcing any activity is going to be alienating and damaging to the coin.
I'm not being able to sync the wallet. There are no any block source. Is there any nodes I'm missing to add? I'm using Biblepay Core version 1.0.2.2 (64-bit) which is the latest I got from website.
Looks like the external node max connections is pegged @ 1024 (Windows limit) maybe thats why (this only affects a brand new user before they sync peers.dat). I think I will need to set up multiple seed nodes resolved by node.biblepay.org. Anyway try to add:
addnode=inspect.biblepay.network
To your config file and then restart.
(The node.biblepay.org is compiled in already).
One thing I forgot to mention for new users: We have the Tools | One Click Mining config menu option in the wallet. It automatically creates the config file and some addnodes for you. If someone will please test it out, and see if it works properly.
The wallet fills this in for me:
Code:
addnode=biblepay.inspect.network
genproclimit=4
poolport=80
workerid=
pool=http://pool2.biblepay.org
gen=1
genproclimit=4
poolport=80
workerid=
pool=http://pool2.biblepay.org
gen=1
Glad to see this coin is still under development
So Ive been researching the difference between X11 and F7000 and have uncovered some more info related to HPS consistency across all processors platforms and instance counts.
Some of you have really been hard on me, especially those who cant grasp the distinction between a "node level mutex" and a "processor" mutex. You even went as far as to say the BibleHash itself is inconsistent. One thing Ive learned over 30 years in software, is nothing about a computer or its software is inconsistent. (Unless someone puts a rand() statement in the code). Another words, every "hard" problem that Ive seen over the years, in the end, always has a very clear reason.
Let me explain the difference between a node mutex and a processor mutex. A node mutex is one where an instance of the software is forced to wait somewhere in the
*instance* of a program for a memory space to be available. A processor mutex is one that consumes the entire processor and it does not have to wait except for new work, and the entire server is frozen in what appears to be a locked state (btw, a crash is very different than a consumed processor).
So with BiblePay, with Pre-F7000, we had a processor mutex, in the sense that one had to buy more hash power to hash against the money supply. With F7000, the goal was originally more of a much stronger line of defense against GPU porting, hence the reason we added the node mutex. Ill stop here and explain. There are two places in BibleHash that are extremely hard or impossible to run on a GPU: asking the node to go back in the chain for a block index hash, or for example a transaction hash. Since the node level instance stops hashing while it waits for the data, the other mining threads slow down. Otoh, if you run multiple degraded instances on one server, you have parallel stops. However, what I dont like about that is it encourages low quality instances whereas I believe it is healther for us as a community to have higher quality instances.
So in light of this, the basic explanation is that F7000 does do its job in preventing BibleHash from running on a GPU, but it promotes the user to run as many low quality nodes as possible to squeeze as many BBP per hour from our community.
I think the answer to this is during the Christmas update (Sanctuaries), we release F8000 with a few more enhancements to fix the problem (we can test these in testnet as soon as available). #1: Add a math problem to BibleHash. This would force the processor to execute a few hundred K of instructions deterministically but unknown at the time of the hash (IE Block hash + timestamp hashed) so no one can predetermine the problem, and this solution would be similar to executing N X11's hashes for a second or so, thereby changing the state of the nodes miner back to a processor mutex level, thereby solving the degrading network problem.
The other thing I would like to introduce before Christmas update is making mining more of a privilege. I was thinking, instead of asking BiblePay to pay you simply because you plug a computer in and *want* to hash, what if BiblePay wants you to contribute to the community? I was thinking at the very least, the node will somehow need to ask the miner to Repent for sins and make a blog of progress. Maybe we make the mining software require a Repentant sin in the block, (IE Think of the 40 mortal sins listed in Send Money (in the wallet) | check Repent | Look at the dropdown values), maybe each week, the miner must repent of a sin, and describe how they are doing in their walk of repenting for sins in the message. If no repentance is being given, no mining is awarded. But each week, either a new description in the walk of a sin free life must be added, or - a new sin to be worked on, this way we can hash the repentance information and ensure it is changing once every 7 days (this way, if its done once a week, its similar to keeping the Sabbath). So our miner would help you Keep the Sabbath. You will wonder, how will we enforce it? I think we can have a REST URI built in, and have the sanctuaries run the RESTful web service, and ban miners who arent repenting coherently. Their miners would be shutdown. It could be a service we require of the sanctuaries.
I think these two features would make BiblePay consistent across all platforms, and require a level of participation to weed & feed out the wheat from the chaff in the community.
Some of you have really been hard on me, especially those who cant grasp the distinction between a "node level mutex" and a "processor" mutex. You even went as far as to say the BibleHash itself is inconsistent. One thing Ive learned over 30 years in software, is nothing about a computer or its software is inconsistent. (Unless someone puts a rand() statement in the code). Another words, every "hard" problem that Ive seen over the years, in the end, always has a very clear reason.
Let me explain the difference between a node mutex and a processor mutex. A node mutex is one where an instance of the software is forced to wait somewhere in the
*instance* of a program for a memory space to be available. A processor mutex is one that consumes the entire processor and it does not have to wait except for new work, and the entire server is frozen in what appears to be a locked state (btw, a crash is very different than a consumed processor).
So with BiblePay, with Pre-F7000, we had a processor mutex, in the sense that one had to buy more hash power to hash against the money supply. With F7000, the goal was originally more of a much stronger line of defense against GPU porting, hence the reason we added the node mutex. Ill stop here and explain. There are two places in BibleHash that are extremely hard or impossible to run on a GPU: asking the node to go back in the chain for a block index hash, or for example a transaction hash. Since the node level instance stops hashing while it waits for the data, the other mining threads slow down. Otoh, if you run multiple degraded instances on one server, you have parallel stops. However, what I dont like about that is it encourages low quality instances whereas I believe it is healther for us as a community to have higher quality instances.
So in light of this, the basic explanation is that F7000 does do its job in preventing BibleHash from running on a GPU, but it promotes the user to run as many low quality nodes as possible to squeeze as many BBP per hour from our community.
I think the answer to this is during the Christmas update (Sanctuaries), we release F8000 with a few more enhancements to fix the problem (we can test these in testnet as soon as available). #1: Add a math problem to BibleHash. This would force the processor to execute a few hundred K of instructions deterministically but unknown at the time of the hash (IE Block hash + timestamp hashed) so no one can predetermine the problem, and this solution would be similar to executing N X11's hashes for a second or so, thereby changing the state of the nodes miner back to a processor mutex level, thereby solving the degrading network problem.
The other thing I would like to introduce before Christmas update is making mining more of a privilege. I was thinking, instead of asking BiblePay to pay you simply because you plug a computer in and *want* to hash, what if BiblePay wants you to contribute to the community? I was thinking at the very least, the node will somehow need to ask the miner to Repent for sins and make a blog of progress. Maybe we make the mining software require a Repentant sin in the block, (IE Think of the 40 mortal sins listed in Send Money (in the wallet) | check Repent | Look at the dropdown values), maybe each week, the miner must repent of a sin, and describe how they are doing in their walk of repenting for sins in the message. If no repentance is being given, no mining is awarded. But each week, either a new description in the walk of a sin free life must be added, or - a new sin to be worked on, this way we can hash the repentance information and ensure it is changing once every 7 days (this way, if its done once a week, its similar to keeping the Sabbath). So our miner would help you Keep the Sabbath. You will wonder, how will we enforce it? I think we can have a REST URI built in, and have the sanctuaries run the RESTful web service, and ban miners who arent repenting coherently. Their miners would be shutdown. It could be a service we require of the sanctuaries.
I think these two features would make BiblePay consistent across all platforms, and require a level of participation to weed & feed out the wheat from the chaff in the community.
I'm not being able to sync the wallet. There are no any block source. Is there any nodes I'm missing to add? I'm using Biblepay Core version 1.0.2.2 (64-bit) which is the latest I got from website.
Looks like the external node max connections is pegged @ 1024 (Windows limit) maybe thats why (this only affects a brand new user before they sync peers.dat). I think I will need to set up multiple seed nodes resolved by node.biblepay.org. Anyway try to add:
addnode=inspect.biblepay.network
To your config file and then restart.
(The node.biblepay.org is compiled in already).
One thing I forgot to mention for new users: We have the Tools | One Click Mining config menu option in the wallet. It automatically creates the config file and some addnodes for you. If someone will please test it out, and see if it works properly.
I'm not being able to sync the wallet. There are no any block source. Is there any nodes I'm missing to add? I'm using Biblepay Core version 1.0.2.2 (64-bit) which is the latest I got from website.
Looks like the external node max connections is pegged @ 1024 (Windows limit) maybe thats why (this only affects a brand new user before they sync peers.dat). I think I will need to set up multiple seed nodes resolved by node.biblepay.org. Anyway try to add:
addnode=inspect.biblepay.network
To your config file and then restart.
(The node.biblepay.org is compiled in already).
I'm not being able to sync the wallet. There are no any block source. Is there any nodes I'm missing to add? I'm using Biblepay Core version 1.0.2.2 (64-bit) which is the latest I got from website.
That's not quite right... The latest version on the website is 1.0.4.8
If you have the latest version and can't connect, you could try:
addnode=97.99.69.33:40000
I'm not being able to sync the wallet. There are no any block source. Is there any nodes I'm missing to add? I'm using Biblepay Core version 1.0.2.2 (64-bit) which is the latest I got from website.
What's that? a scam coin, a speculative coin, a shit or a stupid coin?
I just read your latest posts. Had to read keywords "stupid" "stupid" "stupid" "scam" "scam" "big project". Poor boy you also defend one of the coin which is or was in ICO stage? I hope you the best with your coin which might be even real.
What's that? a scam coin, a speculative coin, a shit or a stupid coin?
With over 100 pages of discussion in three months, if that is your assessment of things you must think everything other than Bitcoin is a scam.
If you're genuinely asking but just grew up in an environment where you never learned how to articulate your thoughts, then no, not a scam, speculative or otherwise junk coin, but one that is bringing some novel concepts to the table, an active Dev and a robust and growing community.
What's that? a scam coin, a speculative coin, a shit or a stupid coin?
I just had trouble adding a picture of a lamb to a letter. If anyone is having trouble adding a picture to a letter in chrome try this:
Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration. Then I was able to add the picture successfully in chrome. It should already work in other browsers.
Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration. Then I was able to add the picture successfully in chrome. It should already work in other browsers.
Has this 'bug' always been present? Because I've added a picture with Chrome in the past with - I just checked - hardware acceleration enabled.
I'll write another letter later this evening to check...
Yeah I had hw acceleration enabled and did it before too, so I guess just change it if its a last resort.
Its on google product forums as a known bug for the "File" container.
Yeah, tried it again, and this time it didn't work with hw acceleration enabled...
Thanks! Good to know.
I just had trouble adding a picture of a lamb to a letter. If anyone is having trouble adding a picture to a letter in chrome try this:
Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration. Then I was able to add the picture successfully in chrome. It should already work in other browsers.
Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration. Then I was able to add the picture successfully in chrome. It should already work in other browsers.
Has this 'bug' always been present? Because I've added a picture with Chrome in the past with - I just checked - hardware acceleration enabled.
I'll write another letter later this evening to check...
Yeah I had hw acceleration enabled and did it before too, so I guess just change it if its a last resort.
Its on google product forums as a known bug for the "File" container.
Yeah, tried it again, and this time it didn't work with hw acceleration enabled...
For those of you testing Masternodes (Sanctuaries) on the Testnet - over half of them need restarting:
Will the retirement rBBP coins be solely for the miners or will it too be split between the miner and masternode?
The rBBP goes to the miner who found the block, this way the security still works. The pool will receive some rBBP also, so we will have to add retirement fields in the pool so you can withdraw your share of retirement coins also.
Will the retirement rBBP coins be solely for the miners or will it too be split between the miner and masternode?
I just had trouble adding a picture of a lamb to a letter. If anyone is having trouble adding a picture to a letter in chrome try this:
Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration. Then I was able to add the picture successfully in chrome. It should already work in other browsers.
Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration. Then I was able to add the picture successfully in chrome. It should already work in other browsers.
Has this 'bug' always been present? Because I've added a picture with Chrome in the past with - I just checked - hardware acceleration enabled.
I'll write another letter later this evening to check...
Yeah I had hw acceleration enabled and did it before too, so I guess just change it if its a last resort.
Its on google product forums as a known bug for the "File" container.
I just had trouble adding a picture of a lamb to a letter. If anyone is having trouble adding a picture to a letter in chrome try this:
Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration. Then I was able to add the picture successfully in chrome. It should already work in other browsers.
Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration. Then I was able to add the picture successfully in chrome. It should already work in other browsers.
Has this 'bug' always been present? Because I've added a picture with Chrome in the past with - I just checked - hardware acceleration enabled.
I'll write another letter later this evening to check...
Jump to: