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

[bible_pay]

Oh ok, I see what you mean, thats a good idea.  ... we need to also allow a lower barrier of entry for say, cpids who have < 500 RAC.

Not just for unbanked, but for all signups. Android miners have Linux/Windows/mac QT desktop wallets already. I seriously doubt there were any unbanked in PoDC 1.0 that only had Android. BBP has been perceived as hard to join, so whatever we can do to make not seem like an exclusive walled off garden is good right?

- MIP looks at making the associate message on the mobile

- I look into making this a zero fee tx (since these are going to be relatively rare, I think they will be included in blocks).

Ill look into implementing these things as I think this helps bring the barriers down.

Awesome, thank you!

I agree for the most part, about not making it a walled off garden, but we do need a rule that authorizes the zero cost fee to keep it from being abused.

I think we can say, if the CPID is in team biblepay, and it has rac > 1 and less than the unbanked threshhold, then we allow the zero tx fee to propagate.

We can allow it for mobiles also in this case.
Its just that, with a CPID with > say 250 RAC, they will by default pay the fee because they need to stake daily stakes from the external purse anyway.

But overall, yes, I think we are making PODC 2.0 much less painless.
The external purse + staking from the main wallet thread just means a user needs to leave one core wallet running but not the pobh miner etc.

Ill also be adding better defaults for cameroon one - so that it only uses .25 bbp in its daily stake by default (in contrast to the coin-age percent).

I believe we already fixed the Healing defaults (to not use up a lot of coin-age).
These two rules above are basically designed to not waste coin-age that will be highly valuable in the external purse for the podc stake each day.

The external purse will still need denominated change for this to work; so we will need to remember to fix exec bankroll.

[bible_pay]

Also, I didn't hear feedback on if you sync from zero when these breakdowns occur; but I do recommend restarting all the governance files from empty - at least once - when these are installed.  This will ensure all the old gobjects are in the cache.

When I set those sancs up, I initially replaced block database from a bootstrap copy that is like 4 weeks old, as well as peers.dat.
But all the other .DAT files including governance files are recreated from empty.

I will try to be awake by the time you say, however it will be around 1-2 am European time, I hope to make it.

Ok if mncache and gov*.dat is recreated from empty - then the node should be doing its mnsync correctly, by default.
So it still points to Germany not having any 'friendly neighbors' as far as peers who peer correctly with governance - which is a very, strange thing to think.

I wouldnt worry about staying up for this.  If you want you can send me your IPs and Ill run the pool report for you at that time, and you can read it tomorrow morning.

I find it hard to believe these can go down this often, but anyway now you  can hone in on the block # of the gsc tomorrow morning if it is out of sync, and verify it went out right at the superblock height.

[bible_pay]

** QT Disabled Permanently **


In the spirit of following our DSS projected-currency-model and the winning vote, QT has been retired permanently.

Congratulations on the raise, miners!

Now you should see a 60% raise, minus the difficulty increase in DGW.

NOTE to investors:  This raise does not cause us to veer away from our original launch parameters.  QT was enacted to temporarily control costs - but - it was not a net success.

[sunk818]

** QT Disabled Permanently **


In the spirit of following our DSS projected-currency-model and the winning vote, QT has been retired permanently.

Congratulations on the raise, miners!

Now you should see a 60% raise, minus the difficulty increase in DGW.

NOTE to investors:  This raise does not cause us to veer away from our original launch parameters.  QT was enacted to temporarily control costs - but - it was not a net success.

Did the change occur as of block 154713?
I looked for qt_pct in raw transaction, but all the blocks appear as qt_pct=0 so I guess the raw block appears as whatever the current status?

[bible_pay]

** QT Disabled Permanently **


In the spirit of following our DSS projected-currency-model and the winning vote, QT has been retired permanently.

Congratulations on the raise, miners!

Now you should see a 60% raise, minus the difficulty increase in DGW.

NOTE to investors:  This raise does not cause us to veer away from our original launch parameters.  QT was enacted to temporarily control costs - but - it was not a net success.

Did the change occur as of block 154713?
I looked for qt_pct in raw transaction, but all the blocks appear as qt_pct=0 so I guess the raw block appears as whatever the current status?

Yes, 154713.

Yes, blocks prefer the spork setting first, then the chain historical price only if need be.  This is so we don't fork in a reorg (plus for efficiency purposes).

[jaapgvk]

Hi Guys,

I've been out of the loop for a bit because I was in retraite for a month, but I'm having trouble with my sanctuaries. They seem to get stuck and I can only 'unstuck' them with a -reindex, but they get stuck again a little bit later. I'm running 1.4.5.0 I think? (Although the latest release according to GitHub is 1.4.4.8.?)

Code:

 "version": 1040500,
  "protocolversion": 70737,

They are currently stuck on block 154179. It's a 1CPU, 1GB RAM (2GB SWAP), 20GB SSD VPS. SSD is about half-full. Ubuntu Server 16.04 LTS. Are my specs not enough anymore for a Sanctuary? My non-sanctuary wallet has no trouble keeping in sync. Problems started happening about three weeks ago.

Can anyone help me?

Anyone?

I got mine stuck too 8h ago, but it was solved with "exec reassesschains" on each one

I wonder why does your sanc go down so much?  
Looking at mine, still no problems.  

If your sanc goes down more than once a month, we should be drilling into the logs and finding if we have a problem.

I think it was a 'user problem' for me. I have now cleaned my wallet using Togo's guide:
https://www.reddit.com/r/BiblePay/comments/7nmvm8/how_to_update_clean_wallets/

I didn't do that between updates the past few times, so I think it was just some old data getting in the way. But I think it's working fine now

MIP and sunk818: also thanks for your answers

[togoshigekata]

Happy Birthday Bitcoin!

The Bitcoin whitepaper was released 11 years ago today

Thank you Satoshi!

=

Read the Bitcoin Whitepaper:
https://bitcoin.org/bitcoin.pdf
Annotated: https://fermatslibrary.com/s/bitcoin

and if you can, run a Bitcoin full node!
https://www.reddit.com/r/BiblePay/comments/8pabw9/support_bitcoin_run_a_full_node/

=

I recommend everyone read "The Internet of Money" by Andreas Antonopolous and pass it to friends and family!
https://www.reddit.com/r/BiblePay/comments/9iyedj/everyone_should_read_the_internet_of_money_by/

[sunk818]

Now that qt_phrase is 0, does this impact consensus_price? Does CameroonONE orphans get paid based on the consensus_price?

exec price

{
  "Command": "price",
  "consensus_price": 0,
  "qt_phase": 0,
  "qt_prior_phase": 0,
  "qt_future_phase": 0,
  "qt_enabled": true,
  "cur_price": "0.000319340000",
  "BBP/BTC": "0.000000035000",
  "BTC/USD": 9124
}

exec paycameroon xxxxxx 40 test

{
  "Command": "paycameroon",
  "BBP/USD_Price": 1e-005,
  "Error": "BBP Price too low to use feature.  Price must be above .00001USD/BBP Running in dry run mode. ",
  "BBPAmount": 4000000,
  "USDAmount": 40
}

[capulo]

i'm not able to rejoin pog...

}
capo@xeon4:~$ biblepay-cli exec cpk capulinko true
{
  "Command": "cpk",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"
}
capo@xeon4:~$ biblepay-cli exec join pog true
{
  "Command": "join",
  "Results": false,
  "Error": "ALREADY_IN_CHAIN"

how to fix this, seems force is not working for me

cpk command works, but join or sendgscc still not:

09:28:50
?
exec join pog



09:29:07
?
sendgscc pog 2000




how to force join? i'm sure i did several unjoin so i should not be joined yet

Well if you did an 'unjoin pog' and waited 5 blocks then did a 'join pog' that should have done it; but anyway, please send me the output of 'exec sentgsc'.
If you sent a gsc with 'sendgscc pog 2000', then received an empty response (that means success), then we should see the txid of the sent GSC and be able to track it.

00:21:51
?
exec sentgsc


sendgscc returns empy, but nothing is sent, i think i need somehow rejoin pog but dont know how

So Im double checking our code, and it appears a person could get out and in like this (for future reference) - say we joined with nickname 'cap' - if you did : exec cpk cap, then exec join pog, then we have "cap" being used.  If you did a new force on the cpk without unjoining pog: exec cpk cap2 email user true, then exec unjoin pog, then exec join pog, you would be fine (as far as I can see).  But just ignore this part for now lets move on to your two accounts.

As far as 'capulinko2' I dont see a config issue:  I see BHKIV* being used for the CPK - and it looks fine, it has your sig, then we have the exec join pog being successful also for the BHIV* (capulinko2).  (On a side note I also see a successful BLUL capulo and BLUL pog capulo).  But moving back to capulinko2, I dont see anything stopping your pog.

Could you please do this - try erasing debug.log, and after a restart, unlock the wallet and try the 'sendgscc pog 2000' again and look in the log and see if there is a specific error message?  It could just be at the time you had < 5 in depth.  And maybe that error was only in the log.

If that does not work, tonight while we are sleeping you can try:  exec unjoin pog, wait 5 blocks, then exec join pog and re-report.  (But I dont see that helping the situation).

only this is in log  after trying to tithe
2019-10-30 21:39:52
Tithing 2000.000000 BBP into the Orphan Foundation for POG, because expected ROI is 2394.548592 percent.Misbehaving: 107.172.188.132:40000 peer=20 (0 -> 1)
2019-10-30 21:40:08 Misbehaving: 107.172.188.132:40000 peer=20 (1 -> 2)

and when i try unjoin and then join i get error; already in chain...
i still think i'm not joined, how to force join cmd?

I'm sooo surprised that unjoin join did not work.  Well at least we know your CPK is in.
I'm also surprised you don't receive an error or anything after the confirmation that it will tithe.

Let me add an RPC option for you to force a 'join' and Ill report back in a bit.

Capulo,

I released this just now for windows:
https://github.com/biblepay/biblepay-evolution/commit/a63bab6a14717dbaf4bcb8e634ae9c3a58d522a7

Hopefully this will solve your problem.

MIP is building the Linux version, but I'm not sure yet of the eta.

To use the command please type:
exec join pog nickname true



Good luck.

coool thanks, this one finaly works

[bible_pay]

Now that qt_phrase is 0, does this impact consensus_price? Does CameroonONE orphans get paid based on the consensus_price?

exec price

{
  "Command": "price",
  "consensus_price": 0,
  "qt_phase": 0,
  "qt_prior_phase": 0,
  "qt_future_phase": 0,
  "qt_enabled": true,
  "cur_price": "0.000319340000",
  "BBP/BTC": "0.000000035000",
  "BTC/USD": 9124
}

exec paycameroon xxxxxx 40 test

{
  "Command": "paycameroon",
  "BBP/USD_Price": 1e-005,
  "Error": "BBP Price too low to use feature.  Price must be above .00001USD/BBP Running in dry run mode. ",
  "BBPAmount": 4000000,
  "USDAmount": 40
}

What?  Yesterday, I checked the cameroon GSC related code to make sure turning off QT wouldnt affect the generation of GSCs, and they look good, but I forgot we had pay cameroon.

Apparently my life is still not going to get any simpler.

Ill check that out next, thanks....

[bible_pay]

** Nomp Pool Admins update **


We have successfully decreased invalid shares < 10%.
To grab on to this method, please update the pool first (per the document below section on updating the pool).

Then please see this new section added for the recommended config settings called "Recommended Settings to decrease...".

I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me.
The biggest change that brought the invalids down is the last section on banning abusive node behavior.

Source:
https://raw.githubusercontent.com/biblepay/node-open-mining-portal/master/Deploy%20a%20Nomp%20BiblePay%20Pool.txt
https://github.com/biblepay/node-open-mining-portal/blob/master/Deploy%20a%20Nomp%20BiblePay%20Pool.txt

[sunk818]

** Nomp Pool Admins update **

We have successfully decreased invalid shares < 10%.
...
I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me.

1) I got three blocks last night, so hopefully those pay out to their respective miners correctly today. Without ABN, the miners who win the block seem to be consolidated. Its okay as PoDC 2.0 will change the dynamic again I think.

2) Re: pool -- I'm beginning to think the threshold to submit an acceptable nonce on the lower end causes more resubmission of the duplicate shares. So, I'll try your minimum of diff 4 and see how it goes.

[bible_pay]

** Nomp Pool Admins update **

We have successfully decreased invalid shares < 10%.
...
I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me.

Hopefully, rebooting the server (or redis-cli shutdown) reset the stats and the pool payout mechanism. I was the only one mining, so the first block belonged to me anyway... LOL  I got three blocks last night, so hopefully those pay out to their respective miners. Lots of changes... but without ABN, the non BBP owners are really hogging all the blocks. Its okay, it is only temporary as PoDC 2.0 comes online.

Re: pool -- I'm beginning to think the threshold to submit an acceptable nonce on the lower end causes more resubmission of the duplicate shares. So, I'll try your minimum of diff 4 and see how it goes.

Reboot should not clear redis, but if you want to start over you can do the 'redis-cli flushall'
To erase certain stats:
redis-cli
HGETALL biblepay:stats
hset biblepay:stats validShares 0
hset biblepay:stats invalidShares 0

I don't know about the other keys; this is all Ive changed so far to get it to this point.

[sunk818]

** Nomp Pool Admins update **

We have successfully decreased invalid shares < 10%.
...
I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me.

Hopefully, rebooting the server (or redis-cli shutdown) reset the stats and the pool payout mechanism. I was the only one mining, so the first block belonged to me anyway... LOL  I got three blocks last night, so hopefully those pay out to their respective miners. Lots of changes... but without ABN, the non BBP owners are really hogging all the blocks. Its okay, it is only temporary as PoDC 2.0 comes online.

Re: pool -- I'm beginning to think the threshold to submit an acceptable nonce on the lower end causes more resubmission of the duplicate shares. So, I'll try your minimum of diff 4 and see how it goes.

Reboot should not clear redis, but if you want to start over you can do the 'redis-cli flushall'
To erase certain stats:
redis-cli
HGETALL biblepay:stats
hset biblepay:stats validShares 0
hset biblepay:stats invalidShares 0

I don't know about the other keys; this is all Ive changed so far to get it to this point.

I tried redis-cli shutdown and removing /var/lib/dump.rdb instead - Maybe that was a bit harsh but I didn't know how to get rid of the bad pool address error.


Did you notice historical data is not from most recent block height? The numbers are out of order sometimes.
for nomp.biblepay.org 154814 and then it is 154869

I'm going to leave my min diff 0.777 but set the difficulty retarget low so high hashers should move up in difficulty quickly. This way, computers with low power can participate more regularly and be encouraged by accepted shares (yay!!!) realizing that they may get more rejected shares from duplicates.

Code:

       "3032": {
            "diff": 0.777,
            "varDiff": {
                "minDiff": 0.777,
                "maxDiff": 64,
                "targetTime": 90,
                "retargetTime": 6,
                "variancePercent": 1
            }
        },

[bible_pay]

BiblePay
1.4.5.2-Leisure Upgrade

- Fix exec paycameroon feature to use current bbp price
- Fix exec price to show current bbp price

** This is the windows release.  MIP will update when linux is ready **

[bible_pay]

** Nomp Pool Admins update **

We have successfully decreased invalid shares < 10%.
...
I realize some of you might want to lower the vardiff below 4, and that is fine, you can do that -- I'm only posting what worked for me.

Hopefully, rebooting the server (or redis-cli shutdown) reset the stats and the pool payout mechanism. I was the only one mining, so the first block belonged to me anyway... LOL  I got three blocks last night, so hopefully those pay out to their respective miners. Lots of changes... but without ABN, the non BBP owners are really hogging all the blocks. Its okay, it is only temporary as PoDC 2.0 comes online.

Re: pool -- I'm beginning to think the threshold to submit an acceptable nonce on the lower end causes more resubmission of the duplicate shares. So, I'll try your minimum of diff 4 and see how it goes.

Reboot should not clear redis, but if you want to start over you can do the 'redis-cli flushall'
To erase certain stats:
redis-cli
HGETALL biblepay:stats
hset biblepay:stats validShares 0
hset biblepay:stats invalidShares 0

I don't know about the other keys; this is all Ive changed so far to get it to this point.

I tried redis-cli shutdown and removing /var/lib/dump.rdb instead - Maybe that was a bit harsh but I didn't know how to get rid of the bad pool address error.


Did you notice historical data is not from most recent block height? The numbers are out of order sometimes.
for nomp.biblepay.org 154814 and then it is 154869

I'm going to leave my min diff 0.777 but set the difficulty retarget low so high hashers should move up in difficulty quickly. This way, computers with low power can participate more regularly and be encouraged by accepted shares (yay!!!) realizing that they may get more rejected shares from duplicates.

Code:

       "3032": {
            "diff": 0.777,
            "varDiff": {
                "minDiff": 0.777,
                "maxDiff": 64,
                "targetTime": 90,
                "retargetTime": 6,
                "variancePercent": 1
            }
        },

Well the history doesn't backfill until the block gets confirmed (I believe its the value they use for solved vs. confirmed) - so I think that part is OK.

The page just needs a javascript sort on the block height descending, one of us can add that as a pool issue once we get the github enabled.

Edit:  The diff idea is cool, as long as your rejects stay relatively low then thats good.

[sunk818]

in the nomp pool, I see shares rejected with this error message:

Code:

ntime out of range nTime 1572528879, rpctime 1572528877

what does this mean and why does it happen?

That means the share was rejected due to being out of range - we have a window of -320 seconds and +7200 (IE the standard for asic).  Please check the server and ensure the timezone is correct and the time is correct?

Is it only happening on your mining against your own server, or ....

I checked the servers and the date time and time zone are in sync. They all happened within a few minutes of each other. The servers all can't have the wrong date/time can they?

I know you want to work on PoDC 2.0. If you're busy, I can live with the pool as-is.

2019-11-01 09:03:46 [Pool]      [biblepay] (Thread 2)
ntime out of range nTime 1572623794, rpctime 1572623793, blockhex [truncated]

2019-11-01 09:03:55 [Pool]      [biblepay] (Thread 4) Share rejected: {"job":"f","ip":"::ffff:37.187.5.xxx","worker":"xxx","difficulty":0.777,"error":"ntime out of range"}

2019-11-01 09:04:01 [Pool]      [biblepay] (Thread 3)
ntime out of range nTime 1572623798, rpctime 1572623793, blockhex [truncated]

2019-11-01 09:04:32 [Pool]      [biblepay] (Thread 4) Share rejected: {"job":"f","ip":"::ffff:78.128.99.xxx","worker":"xxx","difficulty":2.35209323,"error":"ntime out of range"}

2019-11-01 09:06:23 [Pool]      [biblepay] (Thread 3)
ntime out of range nTime 1572623854, rpctime 1572623853, blockhex [truncated]

2019-11-01 09:06:29 [Pool]      [biblepay] (Thread 4) Share rejected: {"job":"10","ip":"::ffff:78.128.99.xxx","worker":"xxx","difficulty":7.26545455,"error":"ntime out of range"}

[coinsinspect]

Hi,
I changed my Sanctuary station IP, and copy the content of one station to another.

Now I get this after starting Sanctuary:

bbp@stationu1:~/zminer$ ./biblepay-cli masternode status
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "78.47.86.179:40000",
  "status": "Not capable masternode: Masternode collateral is a ProTx and ProTx address does not match local address"
}


How can I fix it ?

By the way, the DIP3 link is not working :
https://wiki.biblepay.org/Evolution_Upgrade

[sunk818]

Hi,
I changed my Sanctuary station IP, and copy the content of one station to another.

Now I get this after starting Sanctuary:

bbp@stationu1:~/zminer$ ./biblepay-cli masternode status
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "78.47.86.179:40000",
  "status": "Not capable masternode: Masternode collateral is a ProTx and ProTx address does not match local address"
}


How can I fix it ?

By the way, the DIP3 link is not working :
https://wiki.biblepay.org/Evolution_Upgrade

When I set up my sanctuary (masternode), I didn't have to do upgradesanc to receive daily payments. I don't think DIP3 is required yet.

[togoshigekata]

By the way, the DIP3 link is not working :
https://wiki.biblepay.org/Evolution_Upgrade

Here is a working link:
https://docs.dash.org/en/0.13.0/masternodes/dip3-upgrade.html

Are these the steps to upgrade masternode to deterministic?
https://bitcointalk.org/index.php?topic=2388064.msg51695886#msg51695886
https://www.reddit.com/r/BiblePay/comments/clyxyc/upgrading_masternodes_sanctuaries_to/
https://forum.biblepay.org/index.php?topic=391.msg5968#msg5968