My i5 gives aprox 230k, my friends ryzen 1700 give 500-600k.
I run 10-11 threads and he run 30-35.
And did you find any blocks? For example, for your friend's 550k, he should find one block every 2 hours on average. Or maybe 3 hours because there are less blocks per day than it should be. But if he's finding much less than one block per 3 hours (8 blocks a day), I think something is wrong. He is finding much less. Im also getting less than anticipated. It almost seems like hashps doesnt matter, still i run it at high as i do not know if il get even less with lower hash. Hope biblepay can clarify for us soon what is going on, and that pool will be up. But understandably it takes time for him with pool design form scratch and checking what is the issue. Rome was not built in a day either. The potential here is so big it is worth mining even now before more discover the project. Hash is increasing rapidly every day. And yes we should have Slack/Discord. My opinion is a faster hash rate really is a faster hash rate; the wildcard is luck, and there is nothing wrong with the hashmeter. The person with the 600k hashps should find 3* the blocks as the person with 200k hashps over a long period (over a couple months). I do want the pool to come out, but I want it to come out without bugs. We are now testing an alternate shares based submitting system, and also happy_merchant found a bug where once per night or so (not a severe bug) he drops out of the pool and misses the rewards for the block, working on that also, and also there is a long behind the scenes test cycle for windows. Regarding the algorithm quick solved blocks back to back, its definitely something we can address when we gather the needs for a future mandatory. We can retarget difficulty every block, and lower the stuck_block threshhold down to 30 minutes. Its relatively minor problem for now so I have it on my punchlist for the next mandatory. Regarding solo mining being dead, I am of the opinion that solo mining is still worth it for now, as long as a miner can find a block once per month, and we are still in the range of once per week or so. I do apreciate your work and that it takes time to do things properly. However, i have a hard time seing how we can all have bad luck? No one here have commented on having good luck, just getting 1/10th ish of what they should if anything. Still blocks are being found, but by who  There are over 500 connections on my external node; that leads me to believe by 500 distinct users, thats where they are going. Happy_merchant should be able to help answer, that would mean that the block explorer will show distinct keys for almost every block. |
|
|
|
My i5 gives aprox 230k, my friends ryzen 1700 give 500-600k.
I run 10-11 threads and he run 30-35.
And did you find any blocks? For example, for your friend's 550k, he should find one block every 2 hours on average. Or maybe 3 hours because there are less blocks per day than it should be. But if he's finding much less than one block per 3 hours (8 blocks a day), I think something is wrong. He is finding much less. Im also getting less than anticipated. It almost seems like hashps doesnt matter, still i run it at high as i do not know if il get even less with lower hash. Hope biblepay can clarify for us soon what is going on, and that pool will be up. But understandably it takes time for him with pool design form scratch and checking what is the issue. Rome was not built in a day either. The potential here is so big it is worth mining even now before more discover the project. Hash is increasing rapidly every day. And yes we should have Slack/Discord. My opinion is a faster hash rate really is a faster hash rate; the wildcard is luck, and there is nothing wrong with the hashmeter. The person with the 600k hashps should find 3* the blocks as the person with 200k hashps over a long period (over a couple months). I do want the pool to come out, but I want it to come out without bugs. We are now testing an alternate shares based submitting system, and also happy_merchant found a bug where once per night or so (not a severe bug) he drops out of the pool and misses the rewards for the block, working on that also, and also there is a long behind the scenes test cycle for windows. Regarding the algorithm quick solved blocks back to back, its definitely something we can address when we gather the needs for a future mandatory. We can retarget difficulty every block, and lower the stuck_block threshhold down to 30 minutes. Its relatively minor problem for now so I have it on my punchlist for the next mandatory. Regarding solo mining being dead, I am of the opinion that solo mining is still worth it for now, as long as a miner can find a block once per month, and we are still in the range of once per week or so. |
|
|
|
bible_pay, do you have any plans to create a Slack team so the community can contribute to development needs?
Yes, absolutely. Once things settle down here, I will do it. |
|
|
|
I took a look at the logs, and I believe the issue is on the pool side predominantly, but what happens occasionally, is the threads on the miner side get tied up with work that is too hard to solve for longer than the duration of the block, and 0 shares are submitted by the miner that count toward the block, even if the miner submitted the solution, the stats didnt update in time before the block was solved and paid. I think its probably more productive for us to test out the shares based payment and see if this results in a more frequent and accurate HPS reading and then we can re-test this again overnight. Im going to try to work on the shares today. |
|
|
|
I made a second account to test some stuff out. One thing that I noticed is that I seemed to get paid in full for doing very little work on block 773. According to my logs, I connected to the pool on happy_merchant_alt at 1:45:16. Block 773 took 55 minutes 5 seconds to mine. So, I worked on the block for roughly 10% of the block time, but I received credit as though I had worked on the entire block: 82624506-2b5f-436e-a5e1-bf6c4ee5101b jc12345 773 19999.0000 8211.6667 8/11/2017 1:49:45 AM 27192.68 0.301980800376851 8/11/2017 1:49:45 AM jc12345.1: 30898 (27193)
bd593ffa-497a-4b32-982c-19ef459d90ae bible_pay 773 19999.0000 5367.8276 8/11/2017 1:49:45 AM 17775.39 0.301980800376851 8/11/2017 1:49:45 AM lastleg: 27541 (17775)
beca7599-b7af-40fb-ba50-3ca1a7a23955 testbible 773 19999.0000 3773.2580 8/11/2017 1:49:45 AM 12495.03 0.301980800376851 8/11/2017 1:49:45 AM testbible: 16941 (12495)
f9b00f4c-1515-43c5-861d-a05f5ca4db55 happy_merchant_alt 773 19999.0000 2646.2477 8/11/2017 1:49:45 AM 8762.97 0.301980800376851 8/11/2017 1:49:45 AM happy_merchant_alt00: 12539 (8763)
45f169b3-51c1-4a0c-8f5c-ee8b09a1afd6 jc12345 772 19999.0000 6589.6708 8/11/2017 12:54:40 AM 24509.38 0.268863219343847 8/11/2017 12:54:40 AM jc12345.1: 30855 (24509)
e5fa7538-29a6-40de-9818-51d12ba68463 bible_pay 772 19999.0000 6359.3726 8/11/2017 12:54:40 AM 23652.82 0.268863219343847 8/11/2017 12:54:40 AM lastleg: 27602 (23653)
605dd1aa-8b70-4cee-905c-3e530b8f401b testbible 772 19999.0000 4357.7661 8/11/2017 12:54:40 AM 16208.12 0.268863219343847 8/11/2017 12:54:40 AM testbible: 16923 (16208)
d80c2584-34de-4df7-8ba0-94a1273df69a happy_merchant 772 19999.0000 2692.1905 8/11/2017 12:54:40 AM 10013.23 0.268863219343847 8/11/2017 12:54:40 AM happy_merchant00: 12911 (10013)
MINING_CREDIT 773 e35c1d44-0b03-4476-b9b8-34888baecc36 f9b00f4c-1515-43c5-861d-a05f5ca4db55 2646.2477 2646.2477 8/11/2017 1:49:45 AM
I had been working on block 773 on my original account at the same IP address up till then, so I don't know if that influenced somehow. --edit-- Actually, looking at subsequent blocks, the HPS was a little lower so maybe mining time was taken into consideration for the calculation? Just didn't seem to make much difference in the payout. Realistically I doubt it's something that could be effectively abused in any case. Yeah, the current pool does try to take account HPS on miners that pool hop, but the synthetic HPS of the pool is not always accurate per block- but I think over time it would be a good average. The payout for 773 was based on 8763 hash ps, but your _alt miner generally did about 10500 hash ps. I wonder if you worked on at least 50% of the block or if you really got lucky. I also wonder, how many threads are you running on this miner? In any case, I am working on adding a share based system in, instead of the synthetic HPS reading to see if that works better, and Im trying to make it to where I can switch over to it but yet have both columns in all the reports. Something like TotalShares and SharesSolved or something per row. Im still looking at the other posts with the logs you sent. |
|
|
|
|
So I was just looking over the interfaces at compassion.com (thats the org we started initially partnering with to sponsor orphans. Each longest waiting child is $40 a month, btw.). So I reached out to May the director of the region I am in, and she expressed interest in holding meetings with conf calls for IT integration (ideas like an API to sponsor an orphan, a query for the sponsored orphan list, etc).
This morning, I found an interface where we can electronically write a letter (with pictures) to an orphan that we sponsor, and we can receive a list of incoming letters from the orphans who write to us. I was thinking we should look into adding this ability to the wallet, so the community can take over this function. (Since normally, to have a social media presence, we have someone manually manning twitter, facebook, and handling the correspondence between the orphans and the community. (We would probably need one full time volunteer just to write to our orphans!).
So trying to do this in a more efficient way, if we clone our Send BBP page, and make a write to sponsored orphan page, we could make a multiline textbox with a space for a letter to a child, and let anyone on the blockchain write a letter to one of our current sponsored orphans, and shoot it through the Compassion API. This may sound funny or rife for abuse, but otoh, its important, because these children are waiting for us and some are depressed, and just waiting for letters. The interface is already there, and that would take one function off of a full time volunteer. As far as receiving letters from our orphans back to the community, we could potentially insert those letters back in the chain and allow our community to view them in the wallet.
|
|
|
|
Why is god only valued at 30 satoshi?
I mean I will even have to buy some bags for cheap god
777 satoshi should be target ok , thank you.
I think some of the bigger whales are waiting on the sidelines to ensure we do what we say we will do: We will dump the orphan cold wallet, spend 100% on orphans, and provide an orphan database that is auditable on the expense side, then when they feel more comfortable that this is 100% legit I think we will get a lot more attention. It should become very clear to them within 60 days. |
|
|
|
A minor issue on the website, since I spammed all those withdrawals the transaction history page doesn't seem to be updating any longer. It stops on block 547 after listing a few hundred of the withdrawals. BBP from mining is still being credited and I can still make withdrawals, though, so it looks like it's just a display error.
It just shows the last 512 transactions in the transaction log to keep the pages list short, however it was ordered by UPDATED not UPDATED Desc, so that change will be in the *next* pool release, however in the mean time, I deleted the 1200 transactions < .05 BBP from your account so you should be able to see the list now. |
|
|
|
|
The pool now recovers from errors where the user tries to hit pages and is no longer logged in.
I added the requested anonymous user feature, if you go to account and click 'cloak' user and save the record.
Regarding my testnet pool miner crashing, I added a global csection that *may* fix that, now I am burning it in tonight, good night.
|
|
|
|
I noticed that my miner wasn't showing up in the block distribution history at times. Here's an example where it's registering fine up to block 575, disappears during blocks 576 and 577, then returns at block 578. 3d99591e-5790-4b7a-b219-ab22d2eef382 jc12345 578 19994.0000 1668.9717 8/9/2017 2:42:30 PM 23283.17 0.0716814584926104 8/9/2017 2:42:30 PM jc12345.1: 32152 (23283)
bcbefc8a-c366-48ce-b7d5-47a3380536ed seriestoo 578 19994.0000 9074.4408 8/9/2017 2:42:30 PM 126593.98 0.0716814584926104 8/9/2017 2:42:30 PM intel7700k: 150311 (126594)
seriestoo: 61240 (126594)
2cba286c-0e95-443b-b1af-878621dcda79 testbible 578 19994.0000 891.2757 8/9/2017 2:42:30 PM 12433.84 0.0716814584926104 8/9/2017 2:42:30 PM testbible: 17715 (12434)
eba0fbab-978f-4a75-8c25-8b2033d8538f jumpinbunny 578 19994.0000 5615.1193 8/9/2017 2:42:30 PM 78334.33 0.0716814584926104 8/9/2017 2:42:30 PM Jesus777: 113712 (78334)
0879d8c7-7e38-47d0-8cc2-7d974354def8 tiras 578 19994.0000 2042.6564 8/9/2017 2:42:30 PM 28496.3 0.0716814584926104 8/9/2017 2:42:30 PM tirasworks: 45371 (28496)
0f649be8-eddc-402c-ae62-1f2152327349 happy_merchant 578 19994.0000 701.5361 8/9/2017 2:42:30 PM 9786.86 0.0716814584926104 8/9/2017 2:42:30 PM happy_merchant00: 13033 (9787)
6f4dc4a8-549d-4e13-b688-07a9b00ac03c jc12345 577 19995.0000 1453.3782 8/9/2017 2:39:26 PM 23963.58 0.0606494680929861 8/9/2017 2:39:26 PM jc12345.1: 32154 (23964)
ff81fe6d-0d05-4986-9eff-a594c3cefd39 bible_pay 577 19995.0000 3954.7030 8/9/2017 2:39:26 PM 65205.9 0.0606494680929861 8/9/2017 2:39:26 PM r15: 87462 (65206)
f3798682-34b9-493b-9750-d2ef2041e71c seriestoo 577 19995.0000 8053.6146 8/9/2017 2:39:26 PM 132789.53 0.0606494680929861 8/9/2017 2:39:26 PM intel7700k: 145944 (132790)
seriestoo: 61148 (132790)
89cfbc27-b5a8-47c6-ba6c-8498af2f9a90 jumpinbunny 577 19995.0000 4805.0187 8/9/2017 2:39:26 PM 79226.07 0.0606494680929861 8/9/2017 2:39:26 PM Jesus777: 113412 (79226)
4ba7e54d-ec4e-4a6f-8003-79fc5cad2487 tiras 577 19995.0000 1728.2855 8/9/2017 2:39:26 PM 28496.3 0.0606494680929861 8/9/2017 2:39:26 PM tirasworks: 45371 (28496)
6619ecfd-a25f-4393-b90c-196de1cb7f75 jc12345 576 19995.0000 2326.7319 8/9/2017 2:12:48 PM 19874.89 0.117068924354683 8/9/2017 2:12:48 PM jc12345.1: 32167 (19875)
4fe90646-5b5f-49bf-9c64-f8a913b973e4 bible_pay 576 19995.0000 7585.3988 8/9/2017 2:12:48 PM 64794.3 0.117068924354683 8/9/2017 2:12:48 PM r15: 88098 (64794)
b289e23d-1d97-4149-ba45-6677ba962b8f jumpinbunny 576 19995.0000 6335.1291 8/9/2017 2:12:48 PM 54114.52 0.117068924354683 8/9/2017 2:12:48 PM Jesus777: 55290 (54115)
900716bb-62ca-4cae-b143-89d104cd2d88 tiras 576 19995.0000 3747.7403 8/9/2017 2:12:48 PM 32013.11 0.117068924354683 8/9/2017 2:12:48 PM tirasworks: 47576 (32013)
b7b2a89d-67e1-408b-8a58-5d713a621301 jc12345 575 19998.0000 3293.6308 8/9/2017 2:02:33 PM 25604.32 0.128635734486599 8/9/2017 2:02:33 PM jc12345.1: 32126 (25604)
9e8e72a9-c884-40f6-bef9-c6ce61d7cba2 bible_pay 575 19998.0000 8441.5605 8/9/2017 2:02:33 PM 65623.76 0.128635734486599 8/9/2017 2:02:33 PM r15: 88472 (65624)
31f15a64-61c3-41b2-b380-225442389aa3 testbible 575 19998.0000 2051.2566 8/9/2017 2:02:33 PM 15946.24 0.128635734486599 8/9/2017 2:02:33 PM testbible: 17689 (15946)
7c9d586e-d28c-4309-a320-5c668a441a7d tiras 575 19998.0000 5023.1974 8/9/2017 2:02:33 PM 39049.78 0.128635734486599 8/9/2017 2:02:33 PM tirasworks: 47415 (39050)
8cd55983-1c1f-4be7-b98c-ef836ade429f happy_merchant 575 19998.0000 1188.3547 8/9/2017 2:02:33 PM 9238.14 0.128635734486599 8/9/2017 2:02:33 PM happy_merchant00: 13011 (9238)
The debug log at the time shows nothing abnormal: 2017-08-09 19:01:39 UpdateTip: new best=000013b3e09a5ace4c8d87dcadbd6f1a97d61004ea5b3d7cb46dce501c68871a height=575 log2_work=26.339499 tx=2067 date=2017-08-09 19:01:36 progress=0.002851 cache=0.4MiB(1915tx)
2017-08-09 19:01:39 ProcessNewBlock : ACCEPTED
2017-08-09 19:11:51 UpdateTip: new best=000001d53cbb572419d76001b3742a27bcee8f8c0030e3bef9bcb4239b8ba630 height=576 log2_work=26.350153 tx=2068 date=2017-08-09 19:11:49 progress=0.002852 cache=0.4MiB(1916tx)
2017-08-09 19:11:51 ProcessNewBlock : ACCEPTED
2017-08-09 19:38:31 UpdateTip: new best=0000076b78a8fc0bb351b2ca2854b55bde5430d9397c3c2fc45173630de023ee height=577 log2_work=26.362141 tx=2069 date=2017-08-09 19:38:28 progress=0.002854 cache=0.4MiB(1917tx)
2017-08-09 19:38:31 ProcessNewBlock : ACCEPTED
2017-08-09 19:41:36 UpdateTip: new best=00001de0c00c110c5893479e1036ee5dcdf14ab2c8f04b7e66977a849bb9dea7 height=578 log2_work=26.367812 tx=2070 date=2017-08-09 19:41:35 progress=0.002855 cache=0.4MiB(1918tx)
2017-08-09 19:41:36 ProcessNewBlock : ACCEPTED
Also happened at block 582, but this time there was an error: 2017-08-09 19:46:40 UpdateTip: new best=00000ff5d8a60182a69ac948a8cfec4c6b028950f59d3ee970d3ad95b1644ff7 height=581 log2_work=26.392701 tx=2073 date=2017-08-09 19:46:32 progress=0.002859 cache=0.4MiB(1921tx)
2017-08-09 19:46:40 ProcessNewBlock : ACCEPTED
2017-08-09 20:08:59 UpdateTip: new best=000012a13b09357a7d8f6f67ea01af0e7b44ffee11a2c5434e2e129f85018007 height=582 log2_work=26.407361 tx=2074 date=2017-08-09 20:08:58 progress=0.002860 cache=0.4MiB(1922tx)
2017-08-09 20:08:59 ProcessNewBlock : ACCEPTED
2017-08-09 20:09:21 socket recv error An existing connection was forcibly closed by the remote host. (10054)
2017-08-09 20:20:50 UpdateTip: new best=00001b2d31c2c126ccba466a8d001ab77c767e72bed697e1027de02be741ad2b height=583 log2_work=26.416523 tx=2075 date=2017-08-09 20:20:46 progress=0.002862 cache=0.4MiB(1923tx)
2017-08-09 20:20:50 ProcessNewBlock : ACCEPTED
And finally blocks 584 and 585, with a different error occuring at block 584 (I think the transaction in block 586 is just a payout on a solo mined block from a while back): 2017-08-09 20:20:50 UpdateTip: new best=00001b2d31c2c126ccba466a8d001ab77c767e72bed697e1027de02be741ad2b height=583 log2_work=26.416523 tx=2075 date=2017-08-09 20:20:46 progress=0.002862 cache=0.4MiB(1923tx)
2017-08-09 20:20:50 ProcessNewBlock : ACCEPTED
2017-08-09 20:27:54 UpdateTip: new best=000027558d313d80cad64a45db74624beec59967ba6868793eec6046eb01c6f3 height=584 log2_work=26.423361 tx=2076 date=2017-08-09 20:27:36 progress=0.002863 cache=0.4MiB(1924tx)
2017-08-09 20:27:57
** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **
2017-08-09 20:27:58
BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed: (code 0)
2017-08-09 20:27:58 ProcessNewBlock : ACCEPTED
2017-08-09 20:29:51 UpdateTip: new best=00001972088e7933fa642467a8b1b51aa68c55913797c879e714cfc30311ed81 height=585 log2_work=26.429534 tx=2077 date=2017-08-09 20:29:47 progress=0.002864 cache=0.4MiB(1925tx)
2017-08-09 20:29:51 ProcessNewBlock : ACCEPTED
2017-08-09 20:41:46 CBlock(hash=000006dc7eb7c0ed050bb64c295d1cd5e5e530e3b8514a8282e4d7dfd8149fb4, ver=536870912, hashPrevBlock=00001972088e7933fa642467a8b1b51aa68c55913797c879e714cfc30311ed81, hashMerkleRoot=7f41015fd0af276794ee02c2fd083a1b87965d628dfb34c3c263b61111b5892d, nTime=1502311305, nBits=1e19f652, nNonce=17734, vtx=1)
CTransaction(hash=7f41015fd0, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 024a02022e01)
CTxOut(nValue=19997.00000000, scriptPubKey=76a9149cff090c148949e19f4ed915)
2017-08-09 20:41:46 generated 19997.00
2017-08-09 20:41:46 UpdateTip: new best=000006dc7eb7c0ed050bb64c295d1cd5e5e530e3b8514a8282e4d7dfd8149fb4 height=586 log2_work=26.439813 tx=2078 date=2017-08-09 20:41:45 progress=0.002866 cache=0.4MiB(1926tx)
2017-08-09 20:41:46 ProcessNewBlock : ACCEPTED
576 through 578 seem to be right at the same time you were spamming the pool. Its possible the timespan where you killed the app pool caused the pool to kick you out of that round (it does that if it doesnt hear from you for 3 minutes), and at the same time, the client itself starts signing the blocks with your address, so it shouldnt technically be a concern as the block is either signed into the pool, or signed solo but never both. I guess its possible that a straggling thread kept signing the blocks for the pool and the pool kicked out the miner, but solving the block under that is a longshot. I think the main thing we should do is now that we have anti d-dos turned on the pool, let it run for 24 hours and see if you are not in any block reward. If not we will need to add logging to show what the client did during that span (IE was it solo mining because it thought the pool was down?). If you want you can edit your config and put in 'debugmaster=true' tonight and let it run all night. But that will be a HUGE amount of spam, but might be revealing tomorrow if we find a lapse. |
|
|
|
I believe when happy spammed it, it went down until Microsoft restarted the app pool automatically. Ill work on spam prevention also. Its up. test coins have no value . right ? None at all. |
|
|
|
Not really related to the test pool, but this is an issue I see a lot even on the main blockchain: Block Timestamp
548 8/9/2017 9:45:08 AM
549 8/9/2017 10:44:51 AM
550 8/9/2017 10:44:51 AM
551 8/9/2017 10:44:51 AM
It'll go about an hour with no blocks, then that fail-safe difficulty reduction kicks in and you often see it followed by 2-3 blocks that are mined instantly. Do you think this is something that will work itself out when the network hashrate starts going up? I don't really know enough about blockchains to speculate on any security issues that might arise from the low difficulty blocks, but at the very least the inconsistency in block time might have an affect on widespread adoption of Biblepay since it directly affects the speed of transactions. I have observed this also on all the chains. I believe the issue is (the chain) eventually selects a difficulty for the next block that is slightly too hard for the miners, probably due to either them getting lucky on the last block, or, maybe some extra miners piling in the wallet. Anyway, I doubt more hash rate will solve the problem, it might make it less frequent. I think what we need to do is when we have another mandatory, add in two features in it: - Retarget difficulty once per block instead of once per 4 blocks - Lower the threshold for the stuck blocks from one hour to say 35 minutes. It has to be well over 15 minutes, because the timedrift function for getting the network adjusted time is 15 minutes, and that enforced block drift for disallowing future mining (IE clocks could be off, per se, up to say 7 minutes or so) is used, but we could probably go with 35 minutes for stuck blocks, and that would keep our chain running smoother, and not have people hanging around waiting for confirms. |
|
|
|
Im having trouble with linux as well (Ubuntu 16.04) ==== References: https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt https://michael.mckinnon.id.au/2016/05/13/building-a-namecoin-server-with-ubuntu-16-04/https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md==== Step by Step Commands (not sure if this is all correct, please someone point out any issues) sudo apt-get install g++ sudo apt install make sudo apt-get install build-essential sudo apt-get install autoconf libtool pkg-config sudo apt-get install libboost-all-dev libssl-dev libevent-dev sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler cd /home/yourname git clone https://github.com/biblepay/biblepayBP_ROOT=$(pwd) BDB_PREFIX="${BP_ROOT}/db4" mkdir -p $BDB_PREFIX wget ' http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz' echo '12edc0df75bf9abd7f82f821795bcee50f42cb2e5f76a6a281b85732798364ef db-4.8.30.NC.tar.gz' | sha256sum -c tar -xzvf db-4.8.30.NC.tar.gz cd db-4.8.30.NC/build_unix ../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX make install cd $BP_ROOT ./autogen.sh ./configure LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/" sudo make =================== And then it freezes on last command sudo make, last output: CXX libbitcoin_server_a-init.o Ive been waiting 20 minutes, is it frozen?, did I do something wrong? or do I need to wait longer? (Its just a one core machine Im testing/building on, I have very little Linux experience and almost no mining experience) The very first compile takes over an hour on a fast machine as it has to build all the obj files and moc stuff for qt. |
|
|
|
Every time I recompile from source I end up with version 1.0.7 not the latest, what am I missing/doing wrong?
I simply backed up the wallet, removed all trace of Biblepay and recompiled..
System is Linux Mint.
Finally, great coin, great project i'll be here for the long haul!
I think that is a rare issue, last time that happened to me I did a git reset --hard HEAD and then I was able to see the latest commit. You should see 1.0.1.9 now. Still unable to solve this issue, also be aware I am a novice at linux. Maybe someone else besides the main dev could help me out with this? Make a new git clone and install correctly. There are tutorial thats works for biblepay too https://michael.mckinnon.id.au/2016/05/13/building-a-namecoin-server-with-ubuntu-16-04/Thanks for chipping in. I have attempted to remove all trace of bible pay (biblepay & .biblepaycore in /home directory) Then tried both reinstalling from source & from directly downloading the git source, everytime I reinstall it comes back at 1.0.1.7... Hmm, you could either try deleting a lot of the .cpp files in /src, and doing a git, then comparing the hex hash from the git head at github.com/biblepay/biblepay (its 5fdd), and re-building. It could be having trouble overwriting your files. Maybe you can chown user -R then redo the git, and recompile. Anyway you can also try git clone master over again into a whole new directory - and obviously that should give you something to compare to isolate the problem. |
|
|
|
|
Go ahead and try to spam the pool now.
Got to jump out for a little while; spam prevention should be enabled on miner actions, ips, and withdraws.
|
|
|
|
I believe when happy spammed it, it went down until Microsoft restarted the app pool automatically. Ill work on spam prevention also. Its up. |
|
|
|
Updated to new wallet. What am wondering. On previous coins when setting mining active it did not mine/use CPU power before blocks were synced.
Here it is showing mining as active when there is no block source available / not yet synced and it utilize cpu 100%.
I am asuming mining done until sync is waste, but will it start mining real blocks when synced?
We have a setting in our consensus params that will stop the wallet from mining on a dead chain. Right now, that setting is Off since we allow debugging. We can turn that On when we enable the sanctuaries. As far as syncing, I belive the problem is the external node just hit 501 connections this morning and thats more than it can handle. Please try: addnode=biblepay.inspect.network In the mean time I will raise our limit here to 800 connections. Thank you for the response. It synced shortly after, but i let the question stay for the next time i reboot and others. If i start mining before sync it mines a dead chain. When it is synced, will it then auto go for the live chain? I waited for sync to be sure and restartet mining. Exciting to hear you have contacted bittrex! If it goes live there we can see a nice increase in volume, and probably big pumps of price. More for the miners, but also more for charity! Yeah, the miner actually checks the tip of the chain every 15 seconds and creates a new block based on the active chain, so no worries there. 10-4 on Bittrex. So, I think for us to run a fair and transparent charitable DAO, I would like to add a ground rule for BiblePay dumping the foundation orphan wallet on the exchange, so that we are fair for investors and miners. We will dump the orphanage wallet on the third Friday of every month through the day. That is August 18th this month, all coins get dumped. So buyers be ready. 100% of the resulting BTC goes to sponsor orphans at compassion.com. (We will have a dedicated compassion account, so it is easier for us to post the pictures and orphan IDs back on the site and in-wallet within approx 7 days of the dump- this will give us time to set up our database with orphan IDs and pictures, etc). |
|
|
|
Some feedback:
1. When you click on switch to testnet it toggles to switch to mainnet. When you click on another like like home, the link switch to mainnet defaults back to switch to testnet which is not correct.
2. There is no page to see stats on the blocks found, who found them, when found, the block's status etc.
3. No anonymous mining option.
4. Pool hash indicator is very close to client side hash
Hi JC, Thanks for the detailed info. I agree, #1 is a nuisance, however, the reason it made it so far is the affinity to main_chain, so Im not sure if that will stay that way or not. The thing is in my experience, once we finish testing we will really for all intents and purposes always be in the main chain. (To fix this I need to move the setting for your selected chain to Account to a drop down, and then put the indicator (of the active chain) somewhere else- Ill see what I can do). On #2, check out block distribution history report. It should have very good details. On #3, nice idea.... Hmmm, thinking about it. #4, cool. And I have a new bug to add: I think others might have experienced this also. I have a few nodes solo mining and they are unaffected by this bug. At 02:45 am this morning we have 5 miners on testnet pool mining. Myself and I believe 2 others fell off at the time the tithe block hit. I believe our testnet miners crashed. I believe the issue is, whatever is sent back to the client (either HTTP error, or possibly since the tithe block was mined, an ERROR type response) was handled in a way that caused an unhandled exception to close the whole client. I will look into this today, and believe this Only affects pool miners. |
|
|
|
running a test with a laptop since it looks like im going to need pool mining before i ever get a coin. Spun up an 8 core azure machine with free credits and still nothing so far.
Anyway only thing i noticed so far is in your portal you are not checking for logged in status. I left and came back and clicked on a link and got a hard error instead of sending me back to the log in screen.
We check for logged in status- please paste the error so we can debug. Invalid column name 'threads'. Invalid column name 'BoxHPS'. Thanks a lot dude! So of course when we go live, we can turn off verbose debug info. But this helps, as this is basically a spoof URL security item, in a way. On a side note, this happens when the users session auto-expires and then they try to spoof a URL. Ill jump on this. |
|
|
|
Should also get BiblePay on coinmarketcap if possible  Yes, good idea. Can someone reach out to the owner of coinmarketcap? |
|
|
|
|
Show Posts
