|
sunk818
|
 |
October 02, 2019, 07:58:42 PM |
|
im tested over 70+ coins with mining for last 8-9 years= no problems with this coins,, BIBLEPAY? nonstop problems, im ran this wallet for my friend, no mine 24hours  21:40:48  exec getabnweight 125000 1 21:40:48  { "Command": "getabnweight", "version": 2.7, "weight": 6499.35, "total_required": 259975, "coin_age_data_pre_select": "25997.7751(0.03)=[649.93] depth=7, <ROW>233977.4686(0.03)=[5849.43] depth=7, <ROW><TOTALREQ>259975.24</TOTALREQ><TOTALAGE>6499</TOTALAGE>", "weight 125000.00": 6499.35, "total_required 125000.00": 259975 } Share your biblepay.conf file please as well as a print out of your worker list. Your ABN is LOW as is clear from weight of 6499.35 which is less than 125000 Ask him to clear up his language on our forum or he will be re-banned. Slovakia, if you continue to bash us you will be gone again - as you are in every other forum and system. We don't deserve your foul and negative posts while you sit back in your armchair and you never contribute anything except complaints. There is a 2.5 BBP sent to Orphan Foundation that reset the coin age back to 0. If your friend does not want to participate in GSC (PoG, Healing, CameroonONE), then add this to biblepay.conf and restart wallet: disablegsctransmission=1 This will disable sending out BBP |
|
|
|
bible_pay (OP)
Full Member
 Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 08:03:35 PM |
|
You have been re-banned Slovakia.
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 08:06:52 PM
Last edit: October 02, 2019, 08:26:32 PM by bible_pay |
|
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. |
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 08:31:05 PM |
|
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. |
|
|
|
|
sunk818
|
|
October 02, 2019, 08:36:18 PM |
|
Maybe we vote to turn off ABNs. How would you prevent botnets? Are you familiar with pinball and at the end where match two digits gets you a free replay? I thought perhaps to enter some chance and randomness into mining, the miner can only create an acceptable block if they match last digit/letter from the previous 10 block hash, merkleroot, biblehash, or something else in the blockchain. - 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. |
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 08:43:31 PM |
|
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. |
|
|
|
|
sunk818
|
|
October 02, 2019, 08:52:35 PM |
|
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. |
|
|
|
jsheets1970
Newbie
Offline
Activity: 60
Merit: 0
|
|
October 02, 2019, 09:01:20 PM |
|
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? |
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 09:07:03 PM |
|
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). |
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 09:08:33 PM |
|
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? |
|
|
|
|
sunk818
|
|
October 02, 2019, 09:27:26 PM |
|
> 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"?
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 09:40:39 PM |
|
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). |
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 09:43:48 PM |
|
> 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. |
|
|
|
|
sunk818
|
|
October 02, 2019, 09:52:13 PM |
|
> 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. Encrypted wallets are a necessary evil. You need it for operational security. I wouldn't mess with it. If you do it for ABN, what about for GSC? 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. |
|
|
|
s1mbad
Newbie
Offline
Activity: 5
Merit: 0
|
|
October 02, 2019, 10:01:59 PM |
|
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! |
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 10:03:46 PM |
|
> 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. |
|
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 10:05:10 PM |
|
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! |
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
October 02, 2019, 10:15:32 PM |
|
|
|
|
|
s1mbad
Newbie
Offline
Activity: 5
Merit: 0
|
|
October 02, 2019, 10:32:37 PM |
|
EDIT: Please confirm the BBP Version is 1.4.4.8+ in the about page? Pre 1448 will get rejected by the network. [/quote] Please, where can I find this 1448+ version to be able to compile again on RPi? Thank you in advance! [/quote] We don't have an rpm, but you can still compile it from here: https://github.com/biblepay/biblepay-evolutionThanks! [/quote] 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. |
|
|
|
|
|
