Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 123. (Read 243386 times)
July 09, 2019, 08:13:10 AM
How to multiple mine? would I simply sync my wallet.dat to new PC? (Windows platform)
July 08, 2019, 11:10:24 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
Guess what, a PC found a block and all three miners continued onward with no ABN issues!
Nice! (I also see a huge surge in pool blocks solved: 35 in only 12 hours - maybe this is what was missing).
Now we need more Christians to find out about the wallet.
I'm thinking about making a one page startup guide like someone here suggested a couple weeks ago. (To get started with a CPK & POG).
We should also look into turnkey mining; maybe a pool option that charges a higher percentage but fronts the ABN weight for the miner would be good.
(It might be a pretty high percentage, like 20% pool fees for no-abn, and 0-1% for with-abn, etc).
I really like the idea of a pool with no/low abn requirements. This would allow for the adoption of the project by the small christian miners. Again though you would run into the issue of bots hammering the pool, so perhaps abn requirement in the pool is setup to the value of the faucet on the pool. This way you can eliminate the bots while achieving the goal of larger adoption. The higher percentage fee of 20% works fine in my mind and simply have a flag that can be set on the miner to indicate no-abn or use-abn. Just my 2 cents.
Who would supply the ABN for the non-abn miners? Could this be a potential setup to "stake" for "interest" aka fees from the little miners? Some people just hodl and don't want to mine.
So far the only idea I have is potentially dropping an extra 200K in the pool (from my pocket) and adding a checkbox to the user settings (if they want to be a funded miner or not) , and if these miners on training wheels solve too many blocks Id have to drop more in the pool to keep up, etc.
But I have to think about this all the way through to ensure its technically feasible, because it requires us to change the client to support full block emission to be shot from the pool into the miner and back to the pool etc.
I dont know about the interest; except that I know we cant lend crypto or they will steal it
. We have to lend the ABN transaction out to N miners at once etc.Funding it yourself to start off isnt' a bad idea, but why not opening up everybody to have the ability to make a GSC and fund it using their own like POGing, but without giving anything other than ABN. Fees can be collected and distributed appropriately to those offering ABN
Wait, do you mean make it so "funded miners" (lets call them Funded Miners when they check the funded miners checkbox because they cant afford the ABN weight yet, or we can call them newbies), so funded miners will borrow an existing miners ABN, and if the pool receives a solution from a funded miner, we debit their block by 20% and reward it to the rest of the pool that has valid abns and who are mining? Thats not a bad idea, because the rich miners could then make more rewards and the poor miners could still mine.
Maybe we make it automatic, so we share ABNs, but those who keep supplying a valid non-spent ABN make the block + bonus, those with no ABN get a block - debit.
That sounds great, it benefits ABN miners, and edge cases like me as well. Perhaps an auto-switch could be implemented, if I run out of ABN or my miner throws out a low ABN signal, it could switch to being a funded miner, at that point it would borrow excess ABN from the bigger miners and take the 20% payout from my earned rewards to pay the ABN miners.
edit: but also an auto-switch back from being a funded miner, to being an ABN miner. Once my miner stops throwing low ABN signals it would switch back to the ABN pool? Just a thought.
July 08, 2019, 11:00:35 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
Guess what, a PC found a block and all three miners continued onward with no ABN issues!
Nice! (I also see a huge surge in pool blocks solved: 35 in only 12 hours - maybe this is what was missing).
Now we need more Christians to find out about the wallet.
I'm thinking about making a one page startup guide like someone here suggested a couple weeks ago. (To get started with a CPK & POG).
We should also look into turnkey mining; maybe a pool option that charges a higher percentage but fronts the ABN weight for the miner would be good.
(It might be a pretty high percentage, like 20% pool fees for no-abn, and 0-1% for with-abn, etc).
I really like the idea of a pool with no/low abn requirements. This would allow for the adoption of the project by the small christian miners. Again though you would run into the issue of bots hammering the pool, so perhaps abn requirement in the pool is setup to the value of the faucet on the pool. This way you can eliminate the bots while achieving the goal of larger adoption. The higher percentage fee of 20% works fine in my mind and simply have a flag that can be set on the miner to indicate no-abn or use-abn. Just my 2 cents.
Who would supply the ABN for the non-abn miners? Could this be a potential setup to "stake" for "interest" aka fees from the little miners? Some people just hodl and don't want to mine.
So far the only idea I have is potentially dropping an extra 200K in the pool (from my pocket) and adding a checkbox to the user settings (if they want to be a funded miner or not) , and if these miners on training wheels solve too many blocks Id have to drop more in the pool to keep up, etc.
But I have to think about this all the way through to ensure its technically feasible, because it requires us to change the client to support full block emission to be shot from the pool into the miner and back to the pool etc.
I dont know about the interest; except that I know we cant lend crypto or they will steal it
. We have to lend the ABN transaction out to N miners at once etc.Funding it yourself to start off isnt' a bad idea, but why not opening up everybody to have the ability to make a GSC and fund it using their own like POGing, but without giving anything other than ABN. Fees can be collected and distributed appropriately to those offering ABN
Wait, do you mean make it so "funded miners" (lets call them Funded Miners when they check the funded miners checkbox because they cant afford the ABN weight yet, or we can call them newbies), so funded miners will borrow an existing miners ABN, and if the pool receives a solution from a funded miner, we debit their block by 20% and reward it to the rest of the pool that has valid abns and who are mining? Thats not a bad idea, because the rich miners could then make more rewards and the poor miners could still mine.
Maybe we make it automatic, so we share ABNs, but those who keep supplying a valid non-spent ABN make the block + bonus, those with no ABN get a block - debit.
July 08, 2019, 10:52:48 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
Guess what, a PC found a block and all three miners continued onward with no ABN issues!
Nice! (I also see a huge surge in pool blocks solved: 35 in only 12 hours - maybe this is what was missing).
Now we need more Christians to find out about the wallet.
I'm thinking about making a one page startup guide like someone here suggested a couple weeks ago. (To get started with a CPK & POG).
We should also look into turnkey mining; maybe a pool option that charges a higher percentage but fronts the ABN weight for the miner would be good.
(It might be a pretty high percentage, like 20% pool fees for no-abn, and 0-1% for with-abn, etc).
I really like the idea of a pool with no/low abn requirements. This would allow for the adoption of the project by the small christian miners. Again though you would run into the issue of bots hammering the pool, so perhaps abn requirement in the pool is setup to the value of the faucet on the pool. This way you can eliminate the bots while achieving the goal of larger adoption. The higher percentage fee of 20% works fine in my mind and simply have a flag that can be set on the miner to indicate no-abn or use-abn. Just my 2 cents.
Who would supply the ABN for the non-abn miners? Could this be a potential setup to "stake" for "interest" aka fees from the little miners? Some people just hodl and don't want to mine.
So far the only idea I have is potentially dropping an extra 200K in the pool (from my pocket) and adding a checkbox to the user settings (if they want to be a funded miner or not) , and if these miners on training wheels solve too many blocks Id have to drop more in the pool to keep up, etc.
But I have to think about this all the way through to ensure its technically feasible, because it requires us to change the client to support full block emission to be shot from the pool into the miner and back to the pool etc.
I dont know about the interest; except that I know we cant lend crypto or they will steal it
. We have to lend the ABN transaction out to N miners at once etc.Funding it yourself to start off isnt' a bad idea, but why not opening up everybody to have the ability to make a GSC and fund it using their own like POGing, but without giving anything other than ABN. Fees can be collected and distributed appropriately to those offering ABN
July 08, 2019, 10:49:55 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
Guess what, a PC found a block and all three miners continued onward with no ABN issues!
Nice! (I also see a huge surge in pool blocks solved: 35 in only 12 hours - maybe this is what was missing).
Now we need more Christians to find out about the wallet.
I'm thinking about making a one page startup guide like someone here suggested a couple weeks ago. (To get started with a CPK & POG).
We should also look into turnkey mining; maybe a pool option that charges a higher percentage but fronts the ABN weight for the miner would be good.
(It might be a pretty high percentage, like 20% pool fees for no-abn, and 0-1% for with-abn, etc).
I really like the idea of a pool with no/low abn requirements. This would allow for the adoption of the project by the small christian miners. Again though you would run into the issue of bots hammering the pool, so perhaps abn requirement in the pool is setup to the value of the faucet on the pool. This way you can eliminate the bots while achieving the goal of larger adoption. The higher percentage fee of 20% works fine in my mind and simply have a flag that can be set on the miner to indicate no-abn or use-abn. Just my 2 cents.
Who would supply the ABN for the non-abn miners? Could this be a potential setup to "stake" for "interest" aka fees from the little miners? Some people just hodl and don't want to mine.
So far the only idea I have is potentially dropping an extra 200K in the pool (from my pocket) and adding a checkbox to the user settings (if they want to be a funded miner or not) , and if these miners on training wheels solve too many blocks Id have to drop more in the pool to keep up, etc.
But I have to think about this all the way through to ensure its technically feasible, because it requires us to change the client to support full block emission to be shot from the pool into the miner and back to the pool etc.
I dont know about the interest; except that I know we cant lend crypto or they will steal it
. We have to lend the ABN transaction out to N miners at once etc. July 08, 2019, 10:45:40 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
Guess what, a PC found a block and all three miners continued onward with no ABN issues!
Nice! (I also see a huge surge in pool blocks solved: 35 in only 12 hours - maybe this is what was missing).
Now we need more Christians to find out about the wallet.
I'm thinking about making a one page startup guide like someone here suggested a couple weeks ago. (To get started with a CPK & POG).
We should also look into turnkey mining; maybe a pool option that charges a higher percentage but fronts the ABN weight for the miner would be good.
(It might be a pretty high percentage, like 20% pool fees for no-abn, and 0-1% for with-abn, etc).
I really like the idea of a pool with no/low abn requirements. This would allow for the adoption of the project by the small christian miners. Again though you would run into the issue of bots hammering the pool, so perhaps abn requirement in the pool is setup to the value of the faucet on the pool. This way you can eliminate the bots while achieving the goal of larger adoption. The higher percentage fee of 20% works fine in my mind and simply have a flag that can be set on the miner to indicate no-abn or use-abn. Just my 2 cents.
Who would supply the ABN for the non-abn miners? Could this be a potential setup to "stake" for "interest" aka fees from the little miners? Some people just hodl and don't want to mine. In this case, the hodler would have a safe way of locking a portion of his weight to a contract to the miner, the miner can mine and build their own capital, and the hodler reaps the fees?
July 08, 2019, 10:31:23 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
Guess what, a PC found a block and all three miners continued onward with no ABN issues!
Nice! (I also see a huge surge in pool blocks solved: 35 in only 12 hours - maybe this is what was missing).
Now we need more Christians to find out about the wallet.
I'm thinking about making a one page startup guide like someone here suggested a couple weeks ago. (To get started with a CPK & POG).
We should also look into turnkey mining; maybe a pool option that charges a higher percentage but fronts the ABN weight for the miner would be good.
(It might be a pretty high percentage, like 20% pool fees for no-abn, and 0-1% for with-abn, etc).
I really like the idea of a pool with no/low abn requirements. This would allow for the adoption of the project by the small christian miners. Again though you would run into the issue of bots hammering the pool, so perhaps abn requirement in the pool is setup to the value of the faucet on the pool. This way you can eliminate the bots while achieving the goal of larger adoption. The higher percentage fee of 20% works fine in my mind and simply have a flag that can be set on the miner to indicate no-abn or use-abn. Just my 2 cents.
July 08, 2019, 10:03:40 PM
if you are out of sync, your nodes health and PAM hash won't agree with the other nodes. Try to restart with 'erasechain=1'. People talked about the wallet repair option for resyncing, but there is a bug in the reindex routine. Erasechain kills the gobjects and thats what we want to be clear.
I believe the problem is when we forced the sancs to upgrade twice this week, we've had a lot of failed votes and bad gobject traffic floating around.Please restart with -erasechain=1 and see if it sync to the top. Going forward I think we will be OK now that all the sancs upgraded and traffic is dying down.
Can you explain the difference between -reindex vs -erasechain?
Reindex tries to rebuild the chain using the blk* index files. This works well for bitcoin but not as well for us, because the governance files arent rebuilt.
Erasechain erases the chainstate, blocks, and masternode payments and governance and resyncs from 0. This gives the node the most chance to resync cleanly.
I second having some out of sync issues the past few days,
(started leaving my wallet on to try out mining and poging)
Trying out erasechain for the first time now!
July 08, 2019, 08:22:06 PM
Could we also have a little more participation in testnet please?
Specifically, not for rushing out our next release or testing 0.14, but more specifically for testing Cameroon-One and POG.
Id like to certify that POG & Cameroon work properly within 30 days, so I can get back to Cameroon with Integration testing, and this will allow us to merge cameroon-one into prod as a Leisure release in .13 (our current branch) and get started with POOM mining.
(This will allow miners to sponsor children at home and be rewarded in BBP).
https://forum.biblepay.org/index.php?topic=391.new#new
Specifically, not for rushing out our next release or testing 0.14, but more specifically for testing Cameroon-One and POG.
Id like to certify that POG & Cameroon work properly within 30 days, so I can get back to Cameroon with Integration testing, and this will allow us to merge cameroon-one into prod as a Leisure release in .13 (our current branch) and get started with POOM mining.
(This will allow miners to sponsor children at home and be rewarded in BBP).
https://forum.biblepay.org/index.php?topic=391.new#new
July 08, 2019, 08:16:45 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
Guess what, a PC found a block and all three miners continued onward with no ABN issues!
Nice! (I also see a huge surge in pool blocks solved: 35 in only 12 hours - maybe this is what was missing).
Now we need more Christians to find out about the wallet.
I'm thinking about making a one page startup guide like someone here suggested a couple weeks ago. (To get started with a CPK & POG).
We should also look into turnkey mining; maybe a pool option that charges a higher percentage but fronts the ABN weight for the miner would be good.
(It might be a pretty high percentage, like 20% pool fees for no-abn, and 0-1% for with-abn, etc).
July 08, 2019, 06:53:40 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
Guess what, a PC found a block and all three miners continued onward with no ABN issues!
July 08, 2019, 06:47:52 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
Thanks, that sounds promising.
July 08, 2019, 06:45:52 PM
BiblePay
1.4.4.1 - Leisure Upgrade
- Enhance biblepay-miner to allow it to detect a stagnant share
condition when pool mining and recover.
1.4.4.1 - Leisure Upgrade
- Enhance biblepay-miner to allow it to detect a stagnant share
condition when pool mining and recover.
Since I installed the BBP wallet on a second machine to split up my coins and try to get a little extra mining in, my main wallet has had issues where it would get stuck on a block and will fall farther and farther behind my second wallet. The only fix is to rebuild from the blockchain. It sounds similar to this issue, so I can try the update myself and see what happens, but having two wallets on separate machines shouldn't be an issue, should it? Both machines are mining to the pool by the way. Thanks!
I believe the problem is when we forced the sancs to upgrade twice this week, we've had a lot of failed votes and bad gobject traffic floating around.
Please restart with -erasechain=1 and see if it sync to the top. Going forward I think we will be OK now that all the sancs upgraded and traffic is dying down.
July 08, 2019, 06:43:10 PM
1) On exec health: No - that just means your local node assesses a different contract than the sancs (this is because 1440 is slightly different on the sanc side) - but if you upgrade your local node will assess the same contract and the warning will go away. Its harmless however, as long as the sancs have an agreed quorum.
2) Since your txid in block 129991 was actually One block higher than the previous superblock, you were paid in 130400 (exec analyze 129900 dave_bbp). The payment is in block 130400 vout 24 (for 3875). So basically payment occurs in the superblock following the superblock window the tithe occurred in (IE 129991 + 205 + 205 % 205) = 130400.
Yeah, if you are out of sync, your nodes health and PAM hash won't agree with the other nodes. Try to restart with 'erasechain=1'. People talked about the wallet repair option for resyncing, but there is a bug in the reindex routine. Erasechain kills the gobjects and thats what we want to be clear.
July 08, 2019, 05:43:39 PM
Just wanted to let you know my miners have been going without issue since 1.4.4.1 upgrade, will keep an eye for when my ABN gets eaten and if the miner has any issue re-connecting to the pool once ABN weight is re-established.
July 08, 2019, 05:21:11 PM
BiblePay
1.4.4.1 - Leisure Upgrade
- Enhance biblepay-miner to allow it to detect a stagnant share
condition when pool mining and recover.
1.4.4.1 - Leisure Upgrade
- Enhance biblepay-miner to allow it to detect a stagnant share
condition when pool mining and recover.
Since I installed the BBP wallet on a second machine to split up my coins and try to get a little extra mining in, my main wallet has had issues where it would get stuck on a block and will fall farther and farther behind my second wallet. The only fix is to rebuild from the blockchain. It sounds similar to this issue, so I can try the update myself and see what happens, but having two wallets on separate machines shouldn't be an issue, should it? Both machines are mining to the pool by the way. Thanks!
July 08, 2019, 05:03:13 PM
1) On exec health: No - that just means your local node assesses a different contract than the sancs (this is because 1440 is slightly different on the sanc side) - but if you upgrade your local node will assess the same contract and the warning will go away. Its harmless however, as long as the sancs have an agreed quorum.
2) Since your txid in block 129991 was actually One block higher than the previous superblock, you were paid in 130400 (exec analyze 129900 dave_bbp). The payment is in block 130400 vout 24 (for 3875). So basically payment occurs in the superblock following the superblock window the tithe occurred in (IE 129991 + 205 + 205 % 205) = 130400.
July 08, 2019, 04:51:28 PM
Do you happen to have the TXID of that transmission? We missed a GSC payment this week due to broken-rule sanc issue (that 1440 addressed).
To answer your question though, exec health shows the next superblock at 130605 (the future). This contract contains all GSC transmissions from 130196-130400.
Sure, this is it:To answer your question though, exec health shows the next superblock at 130605 (the future). This contract contains all GSC transmissions from 130196-130400.
Code:
Date: 06.07.2019 17:38
Source: GSC-Transmission
To: POG_donations BB2BwSbDCqCqNsfc7FgWFJn4sRgnUt4tsM
Debit: -2000.00000000 BBP
Transaction fee: -0.01483000 BBP
Net amount: -2000.01483000 BBP
Transaction ID: 276f5be64fa20f72cad78420ca1aa67897a71ea97a128108955a4480dab92db9
Output index: 1
Transaction total size: 1477 bytes
Height: 129991
Difficulty: 20442.75
Time: 07-06-2019 15:45:45
Subsidy: 2348.3544
btw: exec health for me shows "WARNING": "Our internal PAM hash disagrees with the network. " Could this be the problem?
1) On exec health: No - that just means your local node assesses a different contract than the sancs (this is because 1440 is slightly different on the sanc side) - but if you upgrade your local node will assess the same contract and the warning will go away. Its harmless however, as long as the sancs have an agreed quorum.
2) Since your txid in block 129991 was actually One block higher than the previous superblock, you were paid in 130400 (exec analyze 129900 dave_bbp). The payment is in block 130400 vout 24 (for 3875). So basically payment occurs in the superblock following the superblock window the tithe occurred in (IE 129991 + 205 + 205 % 205) = 130400.
July 08, 2019, 04:29:09 PM
Do you happen to have the TXID of that transmission? We missed a GSC payment this week due to broken-rule sanc issue (that 1440 addressed).
To answer your question though, exec health shows the next superblock at 130605 (the future). This contract contains all GSC transmissions from 130196-130400.
Sure, this is it:To answer your question though, exec health shows the next superblock at 130605 (the future). This contract contains all GSC transmissions from 130196-130400.
Code:
Date: 06.07.2019 17:38
Source: GSC-Transmission
To: POG_donations BB2BwSbDCqCqNsfc7FgWFJn4sRgnUt4tsM
Debit: -2000.00000000 BBP
Transaction fee: -0.01483000 BBP
Net amount: -2000.01483000 BBP
Transaction ID: 276f5be64fa20f72cad78420ca1aa67897a71ea97a128108955a4480dab92db9
Output index: 1
Transaction total size: 1477 bytes
Height: 129991
Difficulty: 20442.75
Time: 07-06-2019 15:45:45
Subsidy: 2348.3544
btw: exec health for me shows "WARNING": "Our internal PAM hash disagrees with the network. " Could this be the problem?
July 08, 2019, 04:02:43 PM
Quick question: How far behind are the POG (Smart Contract Rewards) after the POG (GSC Transmission) one makes?
I made my last GSC Transmission 2 days ago (block 129991). After that I appeared in the leaderboard for approx. a day and then disappeared (which is not unusual, as you explained earlier). I excpected some payment at block 130400 (at the latest), which went by 2 hours ago, but received nothing. Was I just "skipped" completely? Exec Roi stated a positive roi ...
I made my last GSC Transmission 2 days ago (block 129991). After that I appeared in the leaderboard for approx. a day and then disappeared (which is not unusual, as you explained earlier). I excpected some payment at block 130400 (at the latest), which went by 2 hours ago, but received nothing. Was I just "skipped" completely? Exec Roi stated a positive roi ...
Do you happen to have the TXID of that transmission? We missed a GSC payment this week due to broken-rule sanc issue (that 1440 addressed).
To answer your question though, exec health shows the next superblock at 130605 (the future). This contract contains all GSC transmissions from 130196-130400.
Jump to: