|
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.
|
|
|
|
"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. |
|
|
|
"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. |
|
|
|
"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. |
|
|
|
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 |
|
|
|
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. |
|
|
|
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-evolutionThanks! 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+. |
|
|
|
Hello MIP. I'm reaching out this way as this seems to be a re-occurring issue. My BBP client was happy until this last mandatory upgrade. After upgrading, it will not connect to any peers. I have gone as far as completely removing BBP off of my system and deleting the residual files/folders and then re-installing as if I were a new user. Even without my wallet.dat and config file, it will not connect to any peers. I have attempted disabling Windows Defender firewall (Win10) and have also added the two IP addresses in my config file for the nodes you mentioned the last time I had connection issues. Any ideas what to try next? Thank you for you time and consideration on this matter.
Have you ensured the system time and timezone is correct within 10 seconds also? After doing that - *If* its still not working, try this from the rpc type: addnode 95.216.127.254 onetry Please post the log if it still does not work. EDIT: Please confirm the BBP Version is 1.4.4.8+ in the about page? Pre 1448 will get rejected by the network. Please, where can I find this 1448+ version to be able to compile again on RPi? Thank you in advance! We don't have an rpm, but you can still compile it from here: https://github.com/biblepay/biblepay-evolutionThanks! |
|
|
|
> When time permits we can also look into removing the need to unlock the wallet - I think thats a hindrance also (for mining)
> by storing the ABN funds in a separate wallet.dat. Maybe we make a keypair for ABNs, and ask the user to pre-fund the keypair etc.
Don't you have a parameter "headlesspassword"?
We do, but I was thinking maybe other communities are laughing at this. Because basically we are saying: to mine BBP with an encrypted wallet, you have to script your "headlesspassword" command in order to mine. I just feel like its a weak point - as then mining fails if you don't know about this command- and the other communities wonder what are we doing? LOL. So I was thinking we offer an alternative - to fund your own purse for an abn - then mining always works regardless of wallet lock state. I think encrypted wallets are a necessary evil. You need it for operational security. I wouldn't suggest messing with it. That might invite more ridicule I think. Hmm.... I think this scheme would only work if a miner cannot change the reward address mid-block. How do you guarantee a miner is not creating more receive addresses while mining a block - by pre-testing the solution with the first createblock to see if its going to "win"? What mechanism could be used to pre-determine a registered miners entry point into that block? Even if we made each miner pre-register to mine the next block, what would stop a miner from pre-creating 16 receive addresses and starting the miner with all, and as soon as they discover which address will be rewarded, they increase the hashpower on that address midblock?
Even if we made each miner pre-register to mine the next block, what would stop a miner from pre-creating 16 receive addresses and starting the miner with all, and as soon as they discover which address will be rewarded, they increase the hashpower on that address midblock? I'm not a blockchain dev so I'm going off of my research: 1) since the coinbase transaction is included in the merkleroothash, changing the receiving address changes the blockhash overall https://bitcoin.stackexchange.com/questions/71659/is-the-hash-of-the-coinbase-transaction-needed-for-the-merkle-root2) timestamp is another input: https://en.bitcoin.it/wiki/Block_hashing_algorithmUnless you know exactly what second you will hit a block with a high enough difficulty, it seems difficult to game. You'd need to have a hash that matches exactly, then wait for blockhash to change to match your receiving address and risk another miner doesn't beat you to the punch. Maybe a cryptodev like you could do it, but you'd still need the CPU power to generate an acceptable nonce. So, you'd still need the computing power even before having the other elements match up perfectly. PoDC & CPID This runs into the oracle potential issue relying on a third-party. You already do with Quantitative Tightening and commands exec price. Not saying using an oracle can't work (because QT has been running well for many months), I'm just saying the alternative to use blockchain data points offers more reliability. 1) Not suggesting we remove encrypted wallets. I was offering an alternative to store 256K in a non encrypted place. Besides, theoretically the ABN could be made up front, then the wallet locked and the abn stored as that cant be stolen by a hacker (it goes back to you when its cashed in). 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. 3) I am against the oracle, thats why Im not jumping on it. Although I said this before: I dont consider exec price an untrusted oracle. Its a "trusted" oracle. Because one, we only use it as a flag to know if our QT "state" changes. We dont use it to pay out 250K per day in rewards. Big differences. A state change occurs when our price sits above 1 sat for 24 hours. If the "trusted" oracle is wrong, everyone points the finger at our own foundation. And - the state change occurs like once every 2 years. PODC was different - it occurred daily, and, *all* of our blockchain emissions were at stake. Notice I mentioned above, in the "tier" idea, and its just a concept, really the heat miners earn this reward. But your right in the sense that it would still drive some heat rewards over to a "semi-trustworthy" oracle - thats enough for me to pause and put that idea on hold. We can talk about this later, but if we ever discuss cancer mining more - it could be that we simply flatten the rosetta data down to one chance of a heat mined block per cancer miner who has recent rac - something that removes the blockchain reward ratio out of the equation - *but* it may not be possible to do that. |
|
|
|
> When time permits we can also look into removing the need to unlock the wallet - I think thats a hindrance also (for mining)
> by storing the ABN funds in a separate wallet.dat. Maybe we make a keypair for ABNs, and ask the user to pre-fund the keypair etc.
Don't you have a parameter "headlesspassword"?
We do, but I was thinking maybe other communities are laughing at this. Because basically we are saying: to mine BBP with an encrypted wallet, you have to script your "headlesspassword" command in order to mine. I just feel like its a weak point - as then mining fails if you don't know about this command- and the other communities wonder what are we doing? LOL. So I was thinking we offer an alternative - to fund your own purse for an abn - then mining always works regardless of wallet lock state. |
|
|
|
You have to completely explain your idea about random digits- I have no idea what you mean - please explain. You have to realize, when I read that, I take it as : A) The user is typing something when they mine, or B) You are trying to hash suffixes in a block. I think we need the verbose description of the idea.
Sorry I am not explaining myself. You take the hash of the miner's reward address. The last number/letter of the hash has to match the block that will be generated. That gives you 1 in 16 chances that you mine the block. On Block 148755, the miner is BBpD9ZBUQVh2SUVWnAsYY8XtPKfZBtvL7b The SHA256 of that address is 97a86de22f791f1a95df46b560ca09f504cd3d607ea1473720563b340f370bbe . The last letter in hash is e, so that candidate block hash also has to match. If the block hash was 2852066294dd96f8e1709686dd5fdbf3501e1f9ef95b4e753d299660ec78e480 , the block would have been rejected under this rule. I know Ill get some backlash for this but as far as the scope of the conversation goes, where I think this blockhash idea would work relatively nicely, is if we brought back Cancer Mining (Rosetta). Lets assume we have all boinc RAC per CPID stored in the chain each day (just for Rosetta), just for CPIDs with > 20 RAC. (As we dont want spam). Lets say during each block, we can now access CPID and RAC values (from the historical block). We could place the CPIDs in ranked tiers by RAC - determining chance levels for 16 tiers with the highest rac in the higher tiers. We could choose a CPID from the applicable tier commensurate with their RAC level (IE a RAC of 100,000 would be in the highest tier, with a 25% chance of hitting a block, while a RAC of 5 would be in the lowest tier with a 1% chance of hitting a block). (Not sure but of course these tiers would need to add up to 100%). This would allow the full subsidy to be paid to the winner. Its sort of interesting because it certainly would be a nice PODC alternative for heat mining and POBH. (Of course the block would be signed with the CPIDs signature, where it matches the registered owner of the cpid). (BTW, to determine the winner, we would take the modulus of the prior uint256 blockhash, and determine its tier and then the cpid winner). |
|
|
|
08:41:46  { "blocks": 148626, "currentblocksize": 1193, "currentblocktx": 1, "difficulty": 3089.850267970606, "errors": "", "pooledtx": 1, "chain": "main", "genproclimit": 30, "networkhashps": 422039.041587423, "hashps": 0, "minerstarttime": "10-02-2019 05:52:50", "hashcounter": 0, "pooledtx": 1, "chain": "main", "biblepay-generate": true, "poolinfo1": "Pool mining with canopus; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ", "poolinfo2": "RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; ", "poolinfo3": "", "poolinfo5": "Internal ABN: Invalid 1569998449; ", "abninfo": "No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; ", "gsc_errors": "low abn weight 0", "poolmining": true, "pool_url": " https://pool.biblepay.org", "required_abn_weight": 125000 } im sent 250k bbp to friends wallet yesterday, wallet is unlocked. We must wait for coinage? Yes, if you sent 250K, you would need to wait about 12 hours to have 125K coin-age. Just keep typed 'exec getabnweight 125000' until the ABN says OK. This right here is a perfect example of one of the things that is holding back this project from achieving the success that it should be seeing. This exact scenario has been discussed a lot but I am not sure if the documentation is hard to find or hard to understand. Slovakia, I believe the issue here is in the configuration of your friends machine. Yes they have been sent 250K but it has not aged enough to mine with their own funding. So, what needs to happen in my mind is not to wait for it to age, but rather modify the miner configuration. This user is mining on the pool but is mining with a worker that is setup with a Funded value of 0.. In that case it is a self funded miner. What needs to happen is create a second user that has a funded value of 1 in the worker list and then modify the conf file to look like this workerid=Worker name with value of 0 in worker list workeridfunded=Worker name with value of 1 in worker list I call this configuration the hybrid configuration as it allows the user to bounce automatically back and forth between self funded and pool funded mining. This user should be mining right now with the workeridfunded user id and getting a percentage of their hash based on the pools dynamic calculations and then when ABN reaches the required 125000 it will automnatically switch to workerid and use self funding. IM me directly if you have any questions. Yes, I agree with you. I've been looking at some of the elements of this project that make it hard on newbies: - Being unable to mine with encrypted wallets - unless they know how to set the unlock phrase (maybe we should 'escrow' the ABN in a specific purse, so the wallet does not need unlocked - by the miner ever) <- This is a little nauseating/embarassing anyway I think - Not understanding the nature of the ABN requirements - Maybe we are becoming too "clubby". You have to be in the exclusive club to mine BBP (since we require funded ABNs). Maybe we vote to turn off ABNs. - Nonstandard pool. I'm taking a look at the official dash pool (p2pool) now; I may take a look at the work effort in porting POBHs requirements into P2Pool. The advantage here would be the people that complained about not understanding how to deploy a pool could them deploy p2pool for POBH. - Should we go back to the most simple environment possible, where we can mine out of the box. I'm sure there are more things like this in our other areas, but this "feels" like the extent of the barrier on the POBH (heat mining side). As far as GSC's go, I still like how veterans can earn a reward for latent BBP - its similar to earning interest - and right now the only ones who get it are those who tithe something (and with QT on, thats important because we need to pay compassion every month). The POOM project is still in its infancy. So far, I feel thats relatively good and successful although it does emit a lot of selling pressure, but we are making a big impact with POOM. So I feel the GSC side is pretty positive for BBP - regardless of the learning curve of what a CPK is and how to join a project. I've discovered a couple large bugs in DSQL, so please hold off on testing in that thread until we fix these. All interesting ideas for sure and things to think about.. I am not sure I would eliminate ABN but perhaps lower the amount. The feature is a nice to have for sure and think it keeps away some elements. Perhaps what we need to do on some of these things is have a more structured repository with Configuration files and examples. Better documents to explain setup.. And possibly remove the 1 click mining feature as it seems to cause more harm then good. Also a way to not have to resync from the beginning of the block chain for when people get some strange behaviors. The project is good and the features implemented are good, but I feel like we are trying to put in too many new features without first ensuring the community and new people know how to use the existing features.. Just my 2 cents I think we consider lowering ABN for a little while until we have > 100 active miners in the pool. 10-4 on the other points. I'll look into p2pool next to see if helps us "standardize" our pools. It might be a big boon to have a dash-evo compatible codebase - just in case all the devs get raptured and BBP is forced to bring on a new set of devs during the Great Tribulation. When time permits we can also look into removing the need to unlock the wallet - I think thats a hindrance also (for mining) - by storing the ABN funds in a separate wallet.dat. Maybe we make a keypair for ABNs, and ask the user to pre-fund the keypair etc. Perhaps think about making ABN requirement something like say 54 or 10K right now.. Then there is still some ABN protection.. Thought? Whatever you guys think is best; I could open a poll? |
|
|
|
You have to completely explain your idea about random digits- I have no idea what you mean - please explain. You have to realize, when I read that, I take it as : A) The user is typing something when they mine, or B) You are trying to hash suffixes in a block. I think we need the verbose description of the idea.
Sorry I am not explaining myself. You take the hash of the miner's reward address. The last number/letter of the hash has to match the block that will be generated. That gives you 1 in 16 chances that you mine the block. Hmm.... I think this scheme would only work if a miner cannot change the reward address mid-block. How do you guarantee a miner is not creating more receive addresses while mining a block - by pre-testing the solution with the first createblock to see if its going to "win"? What mechanism could be used to pre-determine a registered miners entry point into that block? Even if we made each miner pre-register to mine the next block, what would stop a miner from pre-creating 16 receive addresses and starting the miner with all, and as soon as they discover which address will be rewarded, they increase the hashpower on that address midblock? EDIT: This is why we keep coming back to UTXOs (and CPIDs) - these are the only things that so far seem to hold up. (CPIDs less so, but generally, people want to keep their RAC and its work to add a new CPID and generate RAC - of course under certain circumstances). |
|
|
|
Maybe we vote to turn off ABNs. How would you prevent botnets? I have thought of having to match the last digit/letter when creating a new block so there is some randomness involved. It would be like a pinball machine game at the end where you have to match the last 2 digits in order to get a free replay. - Nonstandard pool. I'm taking a look at the official dash pool (p2pool) now; The biggest gain is that it takes the burden off of you to run and maintain a pool. Another option is YIIMP pool ( https://github.com/tpruvot/yiimp). No set up for miner other than the receive address. Im going to look at P2pool first because Dash is primarily p2pool (I read their threads last night), and I feel acclimated with the code allowing us to deal with: Specific Subsidies (dash has a specific subsidy), specific deflation and DGW, Governance rules (superblocks and payments), Block size (all the commits to the p2pool-dash branch), and - the hashing algorithm (x11 and pobh). Btw, I asked Todd about specifically sponsoring Chinese children or Israeli children : No on Chinese - they dont have anything in place yet but he will notify us if that changes, and Mostly No on Israel (although he is checking on a lost tribe of Israel that lives in Africa still). On Botnet - the plain answer is - are we better with more users and a botnet, or, no botnet and a club. Your right though, we need to think about this and if we can still make it resistant to botnets and less of a club, thats fine also. I sort of agree with Sheets the most so far, lower the fee to 5000 for a while, and we work on making the wallet store the ABN in an unlocked purse for a while (leaving us with turnkey mining but a 5K requirement). You have to completely explain your idea about random digits- I have no idea what you mean - please explain. You have to realize, when I read that, I take it as : A) The user is typing something when they mine, or B) You are trying to hash suffixes in a block. I think we need the verbose description of the idea. |
|
|
|
08:41:46  { "blocks": 148626, "currentblocksize": 1193, "currentblocktx": 1, "difficulty": 3089.850267970606, "errors": "", "pooledtx": 1, "chain": "main", "genproclimit": 30, "networkhashps": 422039.041587423, "hashps": 0, "minerstarttime": "10-02-2019 05:52:50", "hashcounter": 0, "pooledtx": 1, "chain": "main", "biblepay-generate": true, "poolinfo1": "Pool mining with canopus; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; BALKgP9NgQqurufJJCDqN4r7y6fhUUCLcj; ", "poolinfo2": "RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:49; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; RMC_10-02-2019 06:40:48; ", "poolinfo3": "", "poolinfo5": "Internal ABN: Invalid 1569998449; ", "abninfo": "No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998512; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998511; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; No block to mine... Please wait... 1569998510; ", "gsc_errors": "low abn weight 0", "poolmining": true, "pool_url": " https://pool.biblepay.org", "required_abn_weight": 125000 } im sent 250k bbp to friends wallet yesterday, wallet is unlocked. We must wait for coinage? Yes, if you sent 250K, you would need to wait about 12 hours to have 125K coin-age. Just keep typed 'exec getabnweight 125000' until the ABN says OK. This right here is a perfect example of one of the things that is holding back this project from achieving the success that it should be seeing. This exact scenario has been discussed a lot but I am not sure if the documentation is hard to find or hard to understand. Slovakia, I believe the issue here is in the configuration of your friends machine. Yes they have been sent 250K but it has not aged enough to mine with their own funding. So, what needs to happen in my mind is not to wait for it to age, but rather modify the miner configuration. This user is mining on the pool but is mining with a worker that is setup with a Funded value of 0.. In that case it is a self funded miner. What needs to happen is create a second user that has a funded value of 1 in the worker list and then modify the conf file to look like this workerid=Worker name with value of 0 in worker list workeridfunded=Worker name with value of 1 in worker list I call this configuration the hybrid configuration as it allows the user to bounce automatically back and forth between self funded and pool funded mining. This user should be mining right now with the workeridfunded user id and getting a percentage of their hash based on the pools dynamic calculations and then when ABN reaches the required 125000 it will automnatically switch to workerid and use self funding. IM me directly if you have any questions. Yes, I agree with you. I've been looking at some of the elements of this project that make it hard on newbies: - Being unable to mine with encrypted wallets - unless they know how to set the unlock phrase (maybe we should 'escrow' the ABN in a specific purse, so the wallet does not need unlocked - by the miner ever) <- This is a little nauseating/embarassing anyway I think - Not understanding the nature of the ABN requirements - Maybe we are becoming too "clubby". You have to be in the exclusive club to mine BBP (since we require funded ABNs). Maybe we vote to turn off ABNs. - Nonstandard pool. I'm taking a look at the official dash pool (p2pool) now; I may take a look at the work effort in porting POBHs requirements into P2Pool. The advantage here would be the people that complained about not understanding how to deploy a pool could them deploy p2pool for POBH. - Should we go back to the most simple environment possible, where we can mine out of the box. I'm sure there are more things like this in our other areas, but this "feels" like the extent of the barrier on the POBH (heat mining side). As far as GSC's go, I still like how veterans can earn a reward for latent BBP - its similar to earning interest - and right now the only ones who get it are those who tithe something (and with QT on, thats important because we need to pay compassion every month). The POOM project is still in its infancy. So far, I feel thats relatively good and successful although it does emit a lot of selling pressure, but we are making a big impact with POOM. So I feel the GSC side is pretty positive for BBP - regardless of the learning curve of what a CPK is and how to join a project. I've discovered a couple large bugs in DSQL, so please hold off on testing in that thread until we fix these. All interesting ideas for sure and things to think about.. I am not sure I would eliminate ABN but perhaps lower the amount. The feature is a nice to have for sure and think it keeps away some elements. Perhaps what we need to do on some of these things is have a more structured repository with Configuration files and examples. Better documents to explain setup.. And possibly remove the 1 click mining feature as it seems to cause more harm then good. Also a way to not have to resync from the beginning of the block chain for when people get some strange behaviors. The project is good and the features implemented are good, but I feel like we are trying to put in too many new features without first ensuring the community and new people know how to use the existing features.. Just my 2 cents I think we consider lowering ABN for a little while until we have > 100 active miners in the pool. 10-4 on the other points. I'll look into p2pool next to see if helps us "standardize" our pools. It might be a big boon to have a dash-evo compatible codebase - just in case all the devs get raptured and BBP is forced to bring on a new set of devs during the Great Tribulation. When time permits we can also look into removing the need to unlock the wallet - I think thats a hindrance also (for mining) - by storing the ABN funds in a separate wallet.dat. Maybe we make a keypair for ABNs, and ask the user to pre-fund the keypair etc. |
|
|
|
go to hell with your biblepain
SUN thanks
OP Post updated. E-mail me at rob@biblepay.org if you want to know more about Jesus or the mortal sins. We also have the sins in the wallet (in the rpc console under : sins). I don't receive pleasure out of seeing people in disharmony with me or any of our community members, or in being banned. This is supposed to be a pleasurable place, acceptable for children. It gets on my nerves when you make posts that are not family friendly. You need to repent - apologize - ask for forgiveness - strive to be a good person - contribute to our community. Accept with the benefit of the doubt that I'm here to help you - and that "maybe" you made a mistake. |
|
|
|
|
You have been re-banned Slovakia.
|
|
|
|
|
Slovakia, this is your final warning. The OP post explains that you can't swear here.
Post with love, or leave.
|
|
|
|
|
Slovakia, this is your 2nd warning, don't repost with "manufactured lies" embedded from your prior posts of FUD.
|
|
|
|
|
Show Posts
