The book of Micah provides one of the most significant prophecies of Jesus Christ’s birth in all the Old Testament, pointing some seven hundred years before Christ’s birth to His birthplace of Bethlehem and to His eternal nature (Micah 5:2).
Proverbs (30:4):
Who has ascended to heaven and come down? Who has gathered the wind in His hands? Who has bound up the waters in His cloak? Who has established all the ends of the earth? What is His name, and what is the name of His Son— surely you know!
Many examples in the Old Testament show clear evidence that Jesus is the Messiah, and existed with God, before he was born in the flesh.
Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 81. (Read 243437 times)
October 20, 2019, 11:13:32 AM
October 20, 2019, 11:08:15 AM
Rob, also external miner is showing ABN low but getmininginfo and exec getabnweight 125000 1 says there is enough
https://imgur.com/a/77GKYac
rpc call failed, seems you have some conectivity issue from miner to wallethttps://imgur.com/a/77GKYac
wallet and miner same computer. maybe I'll reboot. wallet is unlocked and enough abn. mining internally works okay as I tested
October 20, 2019, 11:00:32 AM
Rob, also external miner is showing ABN low but getmininginfo and exec getabnweight 125000 1 says there is enough
https://imgur.com/a/77GKYac
rpc call failed, seems you have some conectivity issue from miner to wallethttps://imgur.com/a/77GKYac
You will also get that issue if the wallet is locked. If unlocked and ABN weight is enough it will resolve itself.
October 20, 2019, 08:30:19 AM
Rob, also external miner is showing ABN low but getmininginfo and exec getabnweight 125000 1 says there is enough
https://imgur.com/a/77GKYac
rpc call failed, seems you have some conectivity issue from miner to wallet https://imgur.com/a/77GKYac
October 20, 2019, 01:54:46 AM
Rob, also external miner is showing ABN low but getmininginfo and exec getabnweight 125000 1 says there is enough
https://imgur.com/a/77GKYac
https://imgur.com/a/77GKYac
October 20, 2019, 01:34:14 AM
I think charity and crypto is bad to mix together. Using crypto to give is ok but making it an actual project your just trashing btc. Please show us proof of these orphans you are helping thanks.
Are you reaching a foolish conclusion before you researched even a little bit and have the facts?
Over $200k USD has been donated to charity thus far.
pool.biblepay.org under accountability (registration required)
October 19, 2019, 09:36:27 PM
I think charity and crypto is bad to mix together. Using crypto to give is ok but making it an actual project your just trashing btc. Please show us proof of these orphans you are helping thanks.
October 19, 2019, 07:02:42 PM
** SANCTUARIES **
(and community members):
Please read the new proposals:
DSS proposed changes:
https://forum.biblepay.org/index.php?topic=461.msg6381#msg6381
Coinsbit Exchange proposal:
https://forum.biblepay.org/index.php?topic=460.new#new
(and community members):
Please read the new proposals:
DSS proposed changes:
https://forum.biblepay.org/index.php?topic=461.msg6381#msg6381
Coinsbit Exchange proposal:
https://forum.biblepay.org/index.php?topic=460.new#new
October 19, 2019, 07:00:33 PM
is external miner also power saving when abn is low?
i'm not sure, because everytime i checked miner, it goes at full speed
it drops to 0 only when it crashed
i'm not sure, because everytime i checked miner, it goes at full speed
it drops to 0 only when it crashed
Yes, it stops mining when ABN is out; and - it doesn't crash anymore.
is this idle?
Erroring out
[2019-10-17 08:55:57] json_rpc_call failed, retry after 30 seconds
[2019-10-17 08:56:27] BBP Core Mining Error: Wallet Locked/ABN Required
it seems so, but miner is still consuming two cores... sometimes 3 cores
11263 capo 20 0 3125160 17060 9344 S 200.0 0.0 21825:34 bbpminer_linux
Yes - thats idle on that particular thread. And of course, erroring out is not a crash (We can take that message out).
Each thread takes a certain amount of seconds to quit hashing the current best block if its still a valid block to hash and has not asked for new work.
Has your processor utilization gone to zero after waiting for a block to pass while you have an invalid ABN?
Yes, you can set gen=0 now, as long as you don't need to send GSCs out.
i know this is not crash, when it was crash there was some libraries dump or what, not remember. but it does not happens again..
and it does not goes to zero, it using 1-3 cores at 100% so 100 or 200 or 300% when abn is low
Oh, I wasn't aware of that.
Do me a favor, since Im working on some other things, please type 'getmininginfo' and when you see your ABN is out for sure, and the miner is still running more than 5 mins after the abn is out, type 'getblockforstratum' into the console of biblepay and tell me if it shows an Error: ABN weight low (or not).
This will point me in the right direction if its the biblepay client or the miner.
i started more wallets and more bbp miners to see better behaviour and after day i stopped completely all wallets and some miners goes to 0%, some stayed on 50% or 100% or 200%... etc, but max i see 300% (3 cores). same as i had when abn was low
all miners just saying: [2019-10-19 23:51:45] HTTP request failed: Failed to connect to 192.168.0.50 port 39003: Connection refused
[2019-10-19 23:51:45] json_rpc_call failed, retry after 30 seconds
i dont have idea what they are doing...
anyone else experiencing same behaviour?
ps: is it possible somehow allow whole subnet? like rpcallowip=192.168.0.*
ps: is it possible somehow allow whole subnet? like rpcallowip=192.168.0.*"
-> They used to allow wildcards. It looks like bitcoin upgraded the code to require subnet-mask notation. Try this: rpcallowip=192.168.0.0/24
As far as the latent mining after a pause, I did notice an issue yesterday while testing the pool. I added a sleep in there (only when its not hashing) and this might fix it.
It should be checked in within a couple days; give me a chance to check in the pool first and ill make a post on that.
October 19, 2019, 05:19:01 PM
Android mobile app update (1.4.5.0)
Bug fixes:
- bug in showing send-to or receive-from addresses
- bug when switching from manual node to automatic mode (keeps manual mode until app restart).
- amount overflow bug when sweeping paper key
Bug fixes:
- bug in showing send-to or receive-from addresses
- bug when switching from manual node to automatic mode (keeps manual mode until app restart).
- amount overflow bug when sweeping paper key
October 19, 2019, 05:08:25 PM
is external miner also power saving when abn is low?
i'm not sure, because everytime i checked miner, it goes at full speed
it drops to 0 only when it crashed
i'm not sure, because everytime i checked miner, it goes at full speed
it drops to 0 only when it crashed
Yes, it stops mining when ABN is out; and - it doesn't crash anymore.
is this idle?
Erroring out
[2019-10-17 08:55:57] json_rpc_call failed, retry after 30 seconds
[2019-10-17 08:56:27] BBP Core Mining Error: Wallet Locked/ABN Required
it seems so, but miner is still consuming two cores... sometimes 3 cores
11263 capo 20 0 3125160 17060 9344 S 200.0 0.0 21825:34 bbpminer_linux
Yes - thats idle on that particular thread. And of course, erroring out is not a crash (We can take that message out).
Each thread takes a certain amount of seconds to quit hashing the current best block if its still a valid block to hash and has not asked for new work.
Has your processor utilization gone to zero after waiting for a block to pass while you have an invalid ABN?
Yes, you can set gen=0 now, as long as you don't need to send GSCs out.
i know this is not crash, when it was crash there was some libraries dump or what, not remember. but it does not happens again..
and it does not goes to zero, it using 1-3 cores at 100% so 100 or 200 or 300% when abn is low
Oh, I wasn't aware of that.
Do me a favor, since Im working on some other things, please type 'getmininginfo' and when you see your ABN is out for sure, and the miner is still running more than 5 mins after the abn is out, type 'getblockforstratum' into the console of biblepay and tell me if it shows an Error: ABN weight low (or not).
This will point me in the right direction if its the biblepay client or the miner.
i started more wallets and more bbp miners to see better behaviour and after day i stopped completely all wallets and some miners goes to 0%, some stayed on 50% or 100% or 200%... etc, but max i see 300% (3 cores). same as i had when abn was low
all miners just saying: [2019-10-19 23:51:45] HTTP request failed: Failed to connect to 192.168.0.50 port 39003: Connection refused
[2019-10-19 23:51:45] json_rpc_call failed, retry after 30 seconds
i dont have idea what they are doing...
anyone else experiencing same behaviour?
ps: is it possible somehow allow whole subnet? like rpcallowip=192.168.0.*
October 19, 2019, 11:41:02 AM
October 18, 2019, 08:42:45 PM
- POOM could be reduced in total size to reestablish/cap our *governance charity* emissions at 10%
...
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
...
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
POOM: I wrote about the sustainability of POOM: https://whitewalr.us/2019/biblepay-poom-sustainable.html - I'll have to revisit this if the percentages change.
Sanc payout: With the rise in difficulty, sanc reward dips below 1000 BBP. You mentioned turning off Quantitative Tightening (QT). Can you expound on what the impact of QT off, external miner release, changing sanc payout percentage will do overall to profitability for sanctuary holders? This means subsidy (miner) and sanctuary_reward values will diverge in the future?
On the potential proposed changes, let me see if I can generate the data (for the forum thread) and attempt to create the thread before the weekend is over, and Ill include the above in that post.
Right now, I finally was able to get NOMP running in my dev environment with the external miner hashing against it, and there are some issues with ABN, so Im trying to address these today, then I can clear out some normal time to focus on that asap.
Did this block miss a sanctuary payment?
height subsidy
145076 2752
I noticed the subsidy values and sanctuary_reward in raw block don't match up. are these rewards (for miner & sanctuary) forfeited and the daily superblock takes priority? Or do the rewards get rolled into the daily superblock reward amount?
145160 2764
145365 2738
...
151720 2063
151925 2114
Since the beginning, Dash does not pay the sanctuary during the monthly superblock budget.
Only the heat miner gets paid.
No, the sanc payment does not get added to the governance budget - the gov budget cap is accurate.
(I.E. This is the way it is in the dash community also).
October 18, 2019, 08:15:30 PM
#3 is v2 xeon, #1-2 is v1 thats all magic
and also it has 40 threads, 1-2 have 32 threads
thats all magicand also it has 40 threads, 1-2 have 32 threads
You can change governance on CPU to high performance if you don't mind the extra heat and electricity use.
https://askubuntu.com/questions/604720/setting-to-high-performance
October 18, 2019, 07:50:28 PM
- POOM could be reduced in total size to reestablish/cap our *governance charity* emissions at 10%
...
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
...
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
POOM: I wrote about the sustainability of POOM: https://whitewalr.us/2019/biblepay-poom-sustainable.html - I'll have to revisit this if the percentages change.
Sanc payout: With the rise in difficulty, sanc reward dips below 1000 BBP. You mentioned turning off Quantitative Tightening (QT). Can you expound on what the impact of QT off, external miner release, changing sanc payout percentage will do overall to profitability for sanctuary holders? This means subsidy (miner) and sanctuary_reward values will diverge in the future?
On the potential proposed changes, let me see if I can generate the data (for the forum thread) and attempt to create the thread before the weekend is over, and Ill include the above in that post.
Right now, I finally was able to get NOMP running in my dev environment with the external miner hashing against it, and there are some issues with ABN, so Im trying to address these today, then I can clear out some normal time to focus on that asap.
Did this block miss a sanctuary payment?
height subsidy
145076 2752
I noticed the subsidy values and sanctuary_reward in raw block don't match up. are these rewards (for miner & sanctuary) forfeited and the daily superblock takes priority? Or do the rewards get rolled into the daily superblock reward amount?
145160 2764
145365 2738
...
151720 2063
151925 2114
October 18, 2019, 07:18:07 PM
i just found that lscpu is not always showing real frequency. when turbo is controlled by bios itself (not os) then it is showing wrong numbers - like turbo is not working ... but turbo was on
so i recheck and here is updated list. ~2.90 means that it was not stable at this freq. but avg was somewhere there
1. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
32 threads running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-154-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 391.81 khash/s
2. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
32 threads running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-31-generic x86_64)
96GB (6x 16GB @ 1600MHz)
Total: 390.72 khash/s
3. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
40 threads running @ 3.10GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-164-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 574.62 khash/s
4. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2650L v2 @ 1.70GHz
40 threads running @ 1.70GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
32GB (8x 4GB @ 1333MHz)
Total: 318.01 khash/s
5. HP DL160 G6
Dual Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
16 threads running @ 2.40GHz
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-154-generic x86_64)
8GB (2x 4GB @ 1066MHz)
Total: 161.14 khash/s
6. Intel SR1625URSAS
Dual Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
24 threads running @ ~2.75GHz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 274.16 khash/s
7. IBM System x3550 M3
Dual Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
24 threads running @ ~2.90GHz
Ubuntu 17.10 (GNU/Linux 4.13.0-16-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 288.88 khash/s
8. HP DL360e G8
Dual Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
24 threads running @ 2.50Ghz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
24GB (12x 2GB @ 1333Mhz)
Total: 281.21 khash/s
seems that memory speed or configuration (dual/quad channel...) does not have big effect
bonus:
9. laptop Thinkpad P52s
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
8 threads running somewhere @ 2.5-2.8GHz
Win10 Enterprise
16GB (2x 8GB @ 2400MHz)
Total: 133.21 khash/s
so i recheck and here is updated list. ~2.90 means that it was not stable at this freq. but avg was somewhere there
1. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
32 threads running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-154-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 391.81 khash/s
2. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
32 threads running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-31-generic x86_64)
96GB (6x 16GB @ 1600MHz)
Total: 390.72 khash/s
3. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
40 threads running @ 3.10GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-164-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 574.62 khash/s
4. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2650L v2 @ 1.70GHz
40 threads running @ 1.70GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
32GB (8x 4GB @ 1333MHz)
Total: 318.01 khash/s
5. HP DL160 G6
Dual Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
16 threads running @ 2.40GHz
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-154-generic x86_64)
8GB (2x 4GB @ 1066MHz)
Total: 161.14 khash/s
6. Intel SR1625URSAS
Dual Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
24 threads running @ ~2.75GHz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 274.16 khash/s
7. IBM System x3550 M3
Dual Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
24 threads running @ ~2.90GHz
Ubuntu 17.10 (GNU/Linux 4.13.0-16-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 288.88 khash/s
8. HP DL360e G8
Dual Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
24 threads running @ 2.50Ghz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
24GB (12x 2GB @ 1333Mhz)
Total: 281.21 khash/s
seems that memory speed or configuration (dual/quad channel...) does not have big effect
bonus:
9. laptop Thinkpad P52s
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
8 threads running somewhere @ 2.5-2.8GHz
Win10 Enterprise
16GB (2x 8GB @ 2400MHz)
Total: 133.21 khash/s
October 18, 2019, 04:52:22 PM
#3 is v2 xeon, #1-2 is v1 thats all magic
and also it has 40 threads, 1-2 have 32 threads
thats all magicand also it has 40 threads, 1-2 have 32 threads
October 18, 2019, 03:42:55 PM
#3 is a hyperthreading 10 core times 2
it still averages about the same as other avx2 enabled processors.
it still averages about the same as other avx2 enabled processors.
October 18, 2019, 02:52:40 PM
i did few benchmarks with external miner (--benchmark parameter)
1. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-154-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 391.81 khash/s
2. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-31-generic x86_64)
96GB (6x 16GB @ 1600MHz)
Total: 390.72 khash/s
3. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
running @ 3.10GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-164-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 574.62 khash/s
4. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2650L v2 @ 1.70GHz
running @ 1.70GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
32GB (8x 4GB @ 1333MHz)
Total: 318.01 khash/s
5. HP DL160 G6
Dual Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
running @ 2.27GHz
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-154-generic x86_64)
8GB (2x 4GB @ 1066MHz)
Total: 161.14 khash/s
6. Intel SR1625URSAS
Dual Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
running @ 2.67GHz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 274.16 khash/s
7. IBM System x3550 M3
Dual Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
running @ 2.80GHz
Ubuntu 17.10 (GNU/Linux 4.13.0-16-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 288.88 khash/s
8. HP DL360e G8
Dual Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
running @ 2.20Ghz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
24GB (12x 2GB @ 1333Mhz)
Total: 281.21 khash/s
seems that memory speed or configuration (dual/quad channel...) does not have big effect
bonus:
9. laptop Thinkpad P52s
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
running somewhere @ 2.5-2.8GHz
Win10 Enterprise
16GB (2x 8GB @ 2400MHz)
Total: 133.21 khash/s
1. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-154-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 391.81 khash/s
2. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
running @ 2.90GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-31-generic x86_64)
96GB (6x 16GB @ 1600MHz)
Total: 390.72 khash/s
3. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
running @ 3.10GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-164-generic x86_64)
128GB (8x 16GB @ 1600MHz)
Total: 574.62 khash/s
4. Lenovo C30
Dual Intel(R) Xeon(R) CPU E5-2650L v2 @ 1.70GHz
running @ 1.70GHz
Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-142-generic x86_64)
32GB (8x 4GB @ 1333MHz)
Total: 318.01 khash/s
5. HP DL160 G6
Dual Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
running @ 2.27GHz
Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-154-generic x86_64)
8GB (2x 4GB @ 1066MHz)
Total: 161.14 khash/s
6. Intel SR1625URSAS
Dual Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
running @ 2.67GHz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 274.16 khash/s
7. IBM System x3550 M3
Dual Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
running @ 2.80GHz
Ubuntu 17.10 (GNU/Linux 4.13.0-16-generic x86_64)
8GB (2x 4GB @ 1333MHz)
Total: 288.88 khash/s
8. HP DL360e G8
Dual Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
running @ 2.20Ghz
Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)
24GB (12x 2GB @ 1333Mhz)
Total: 281.21 khash/s
seems that memory speed or configuration (dual/quad channel...) does not have big effect
bonus:
9. laptop Thinkpad P52s
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
running somewhere @ 2.5-2.8GHz
Win10 Enterprise
16GB (2x 8GB @ 2400MHz)
Total: 133.21 khash/s
Nice work!
I see #3 really stands out. I wonder why its almost 2* the speed yet the procs are only .20 ghz faster each?
#2, I do wonder if windows running on one of those high power boxes (like #3) will hash at approx the same speed.....
I assume it will, based on my ryzen windows desktop machine hashing at 350KHS.
October 18, 2019, 02:48:20 PM
- POOM could be reduced in total size to reestablish/cap our *governance charity* emissions at 10%
...
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
...
- The increase in sanc payout coming soon is OK - because they lock the coins and hold them usually
POOM: I wrote about the sustainability of POOM: https://whitewalr.us/2019/biblepay-poom-sustainable.html - I'll have to revisit this if the percentages change.
Sanc payout: With the rise in difficulty, sanc reward dips below 1000 BBP. You mentioned turning off Quantitative Tightening (QT). Can you expound on what the impact of QT off, external miner release, changing sanc payout percentage will do overall to profitability for sanctuary holders? This means subsidy (miner) and sanctuary_reward values will diverge in the future?
On the potential proposed changes, let me see if I can generate the data (for the forum thread) and attempt to create the thread before the weekend is over, and Ill include the above in that post.
Right now, I finally was able to get NOMP running in my dev environment with the external miner hashing against it, and there are some issues with ABN, so Im trying to address these today, then I can clear out some normal time to focus on that asap.
Jump to: