Its just an upgrade to keep you from crashing, so at your leisure. |
|
|
|
** BiblePay - New NOMP Pool - Opening in BETA mode for testing **
I am proud to announce our new NOMP pool is now opening in Beta mode. You must use the BBP external miner to mine against our NOMP pool (as nomp requires stratum). Note, that ABN's are going to be supported, however today all the shares temporarily pay the same amount (as ABN is not configured on the server side yet). The goal today is to ensure the shares are being accepted in prod, the miners do not crash in stratum mode, the miners continually receive new work, and that we can actually solve blocks in prod. Also, we need to ensure payouts work correctly from the NOMP side. Regarding payouts: NOMP pays every 15 minutes, but does require each solved block to be fully matured; here is an example of how your payout would work: Miner A solves block 100,000. NOMP records this miners shares and BBP address in the database (even if you stop mining, NOMP will remember your work). At block 100,120, NOMP will see the block has matured. Within 30 minutes, it will distribute all of the payouts (for every share that participated in that block). So from a high level, you will be paid about 12 hours later for shares you solved. WEB SITE URL: http://nomp.biblepay.orgI have added some preliminary instructions on how to mine against NOMP on the home page. Please see the wiki. Basic configuration from our external miner: https://wiki.biblepay.org/Nomp_mining(See the Easy setup section) As soon as ABN is configured on the server, I will post and explain how you can see your ABN status and ABN payout information, etc.
|
|
|
|
hmm few minutes ago, all miners on all wallets on all PCs crashed... also on wallet copies... so it must have something to do with data from wallets
"abninfo": "ABN: OK; ",
"gsc_errors": "low abn weight 0",
but abn is ok
"weight": 560430.9543402777,
and
"weight": 1419968.982430556,
edit2: now i can start miners again, maybe chain moved to another block or what... maybe there was some weird block around 152537
I got the same thing at the same time. Segmentation faults, bus errors. Miners did core dump (cannot find the dump file....) and then couldn't be restarted for almost half an hour without aborting. Strangely, after restarting the wallet the miners were fine until I unlocked the wallet. Then they immediately crashed again. I see I am late to the party... oh well lol Yeah, if you are trying to mine the same block that is too big for the miner, it will continually crash until the block passes. |
|
|
|
my miner crashed too about 3.5 hours https://chainz.cryptoid.info/bbp/tx.dws?1162443.htmCan the miner handle a tx this big? 71kB! says it was a heap corruption Faulting application name: bbpminer-x86.exe, version: 0.0.0.0, time stamp: 0x5da4aacd Faulting module name: ntdll.dll, version: 10.0.17763.802, time stamp: 0x125ac1e8 Exception code: 0xc0000374 Fault offset: 0x00000000000fb049 Faulting process id: 0xc60 Faulting application start time: 0x01d585e05653251f Faulting application path: C:\bbp\bbpminer-x86.exe Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll Report Id: 5df0bfb2-9e13-4ecc-bde0-6b60db36bff6 Faulting package full name: Faulting package-relative application ID: Im starting to look at some of these external miner issues - but I have a lot going on- but I think you found the problem Sun - I believe our buffer is 65K - and if we sent out transactions bigger than that, I think that would crash the external miner. Thats pretty huge. Will look. For some reason the CSS isnt showing up on bitcointalk and its hard to see quotes. Ok, I think I see the problem- that big transaction is bigger than the buffer for the external miner. I think thats why we all crashed at the same time - everyone was trying to mine it at the same time. So, I am very close to deploying NOMP (I think within 24 hours I should have a test setup ready for prod)- at the same time, we need an upgrade for the miner anyway; so Ill increase the buffer to the size of our block size. I think this will need to be done by tomorrow by noon. In the mean time the core client should be mining OK. |
|
|
|
my miner crashed too about 3.5 hours https://chainz.cryptoid.info/bbp/tx.dws?1162443.htmCan the miner handle a tx this big? 71kB! says it was a heap corruption Faulting application name: bbpminer-x86.exe, version: 0.0.0.0, time stamp: 0x5da4aacd Faulting module name: ntdll.dll, version: 10.0.17763.802, time stamp: 0x125ac1e8 Exception code: 0xc0000374 Fault offset: 0x00000000000fb049 Faulting process id: 0xc60 Faulting application start time: 0x01d585e05653251f Faulting application path: C:\bbp\bbpminer-x86.exe Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll Report Id: 5df0bfb2-9e13-4ecc-bde0-6b60db36bff6 Faulting package full name: Faulting package-relative application ID: Im starting to look at some of these external miner issues - but I have a lot going on- but I think you found the problem Sun - I believe our buffer is 65K - and if we sent out transactions bigger than that, I think that would crash the external miner. Thats pretty huge. Will look. For some reason the CSS isnt showing up on bitcointalk and its hard to see quotes. |
|
|
|
|
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.
|
|
|
|
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  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. |
|
|
|
- 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
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). |
|
|
|
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
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. |
|
|
|
- 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
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. |
|
|
|
Rob, what do you think of BiblePay sanctuaries serving as a VPN tunnel? Chinese Christians can get past the Great Firewall and look at Christian content (among other things) without being censored. It could be free as a way to build user base. Or if there was a charge, maybe there could be a way to lock funds or send to a reserve account until you pay the sanctuaries that served you VPN bandwidth.
Part of it sounds like a really good idea (the part about sharing Christian content directly to the user who can't get to the blocked content). The part about a Chinese user getting in trouble for using a VPN, or getting the machine confiscated (or BBP to be blamed for creating a circumventing policy to their laws) seems like the downside. Maybe if we strictly filter the access to be high quality Christian content, it would work, but in general it sounds like a very good idea - possibly if it was not a full fledged VPN - if it was more of a Christian content browser. Maybe when we get the treasure trove up, we can point them to that landing page in DSQL, etc. We should keep thinking about it. |
|
|
|
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 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. |
|
|
|
So as you all know I've been starting to work on a new pool that will give us stratum support. I spent a couple days looking at p2pool, but I got slightly dissapointed with certain aspects of it. (I don't really like all the hardcoded literals in the code). At first I thought having python would be OK, because its a popular standard codebase. But then I read some comments by the author of nomp, and I started checking out nomp. I really like how nomp is written in Node.js and the code behind gives me a warm and fuzzy feeling that it will be easier to support in the long run. Anyway, its mostly X11/darkcoin compatible already, so it shouldn't be a problem to make a BiblePay/NOMP pool. From what I can see we don't lose anything with this approach - we still get stratum, we get a nice UI (the web presence is nice), and the code is clean. So I took a new direction and will be porting a flavor of bbp into nomp: https://github.com/zone117x/node-open-mining-portalAfter all, our next pool should be an improvement for our users. I reiterate, there is really nothing wrong with our c# pool, and we could have refactored it more, but I feel adding stratum to it at this stage would make it a redheaded stepchild, especially since many coins rely on Nomp and its support (as compared to a one off) - so I believe we are making a good move in embracing a standardized codebase for biblepay pools. In addition, Nomp looks like its going to be easy for new devs to set one up when we need to scale to numerous pools. I set one up last night and it was really pain free to get started. =-=-=-=-=-=-=-=-=- Regarding the 'cryptocurrency economy' simulation project, that is going very well. I created two graphs so far, and things are pointing towards the truth in the posts a few pages back (about making assumptions based on theoretical economic outcomes). That project needs a couple more days of work. When its done Im going to publish the results in a new forum proposal thread, and summarize them, and - use that proposal for the potential changes. Ill also upload the code into the contrib folder when its done. |
|
|
|
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 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. |
|
|
|
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 Yes, it stops mining when ABN is out; and - it doesn't crash anymore. |
|
|
|
I compiled bbpminer on macOS with a few tweaks. I'm getting 7.15kh/s on single thread of MacBook Pro (2011). So, 8 threads theretically would be 56kh/s. I'm not going to push it because laptops aren't ideal due to poor thermal cooling.
Changing subject, when I run: bbpminer-x86.exe --version , I see binary is compiled with AVX2 support. What happens if the CPU doesn't support AVX2 because it is older CPU?
Looking at the code, we only use AVX for Sha256d 8-way-hashing, which should only be hit when mining bitcoin. We use X11 and POBH when mining, so AVX should not actually be hit in our case. |
|
|
|
I just realized I need to keep gen=1 in biblepay.conf for automated tithing for gsc campaigns even if I'm mining externally. No wonder I missed CameroonONE Smart Contract Reward.
Yeah, this is something on my mind also. Preferably, in our next environment, let's look at moving the SendGscTransactions over to our main thread (still at the same frequency), so the user does not need to start the miner. Lets also look at either zero cost transactions, or sending this from a special purse. Ill start with a baby item for R&D: Create a receive address called "ABN", fund it with a small amount, lock the wallet, and send a GSC transaction using "ABN" as the fee source while the wallet is locked. Once we know the outcome of this we can work on Biblepay 2.0's architecture. |
|
|
|
json_rpc_call failed, retry after 30 seconds BBP Core Mining Error: Wallet Locked/ABN Required i'm new mining , and after sync wallet , add .conf for mining, use bbminer , and error  ! how to fix ! server=1
rpcport=14000
rpcallowip=127.0.0.1
rpcuser=myuser
rpcpassword=randompassword Could you please paste your 'exec getabnweight' , and ensure the "weight" is greater than 125k? You must have a valid ABN to mine in our current environment. (See the OP post for Getting Started with Evolution for more about ABNs). |
|
|
|
|
Show Posts
