Ginzink
|
|
August 17, 2017, 10:42:03 AM |
|
Wow i think there is a massive increase in miners. Good thing we have a pool, even there i dont get very much but at least some! But, it is a good thing. This is a good project and to evolve it needs a large community. Would strongly advise against selling with the current diff you will not be able to mine it back easy
|
|
|
|
MostlyGhostly
|
|
August 17, 2017, 10:48:50 AM |
|
Man the diff is now so high its not even mineable anymore.
Guess ill need to switch on the pool when i get back!
Could a huge piece of fat with autonomous nervous system engage into mining shitcoin crap? No, not even unanimated piece of fat taken from human buttox will dare to do it. The era of fattenized and obese chains is coming along, what you really should do now is buckle up your fat assess and wait for bitcoin flippening.
|
|
|
|
inblue
|
|
August 17, 2017, 10:53:55 AM |
|
Good thing we have a pool, even there i dont get very much but at least some!
I was just looking at the block distribution history in the pool and there is no your name for the block 3493, but you are there on all the other ones. Were you off at that time or the pool didn't count your shares for some reason?
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 17, 2017, 01:23:36 PM |
|
Good thing we have a pool, even there i dont get very much but at least some!
I was just looking at the block distribution history in the pool and there is no your name for the block 3493, but you are there on all the other ones. Were you off at that time or the pool didn't count your shares for some reason? The issue with one 12khs miner entry is that in the current model, if the 12khs miner has trouble solving some of the shares consecutively for over 15 mins, they can fall out of the pool and not be paid when the block distribution hits at the time of the solve. We are actively working on this in testnet to make it more likely the miner stays in (by ratcheting up the diff more slowly for the miner). The next version that has not been announced yet helps take care of this. There are some testnet issues going on - through the night but progress is still being made.
|
|
|
|
smoosh
Newbie
Offline
Activity: 33
Merit: 0
|
|
August 17, 2017, 06:03:22 PM |
|
Been trying to build this on a VPS but the build always fails on the make step. Is it possible to build just 'biblepayd' only? For context, I've been building other wallet daemons with a 'make -f makefile.unix' without problem.
Do you mean to build Biblepay wallet in Linux? I have tried to build biblepay in Ubuntu 14.04 but failed with openssl version issue. Then I built again in Ubuntu 16.04 without problem. Just follow the instructions of a file named something like "build biblepayforlinux.txt" in the git will do. Do you need to run it desktop or can you run it command line. I followed the instructions to install the wallet but i can not figure out how to run it but im new to the world of linux Mod can you answer this please. thanks
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 17, 2017, 06:44:07 PM |
|
Been trying to build this on a VPS but the build always fails on the make step. Is it possible to build just 'biblepayd' only? For context, I've been building other wallet daemons with a 'make -f makefile.unix' without problem.
Do you mean to build Biblepay wallet in Linux? I have tried to build biblepay in Ubuntu 14.04 but failed with openssl version issue. Then I built again in Ubuntu 16.04 without problem. Just follow the instructions of a file named something like "build biblepayforlinux.txt" in the git will do. Do you need to run it desktop or can you run it command line. I followed the instructions to install the wallet but i can not figure out how to run it but im new to the world of linux Mod can you answer this please. thanks If you want to run the qt (gui) version: cd src ./biblepay-qt We also have a biblepayd daemon, you can find more by googling about bitcoind if you want to run the daemon.
|
|
|
|
smoosh
Newbie
Offline
Activity: 33
Merit: 0
|
|
August 17, 2017, 08:31:14 PM |
|
Been trying to build this on a VPS but the build always fails on the make step. Is it possible to build just 'biblepayd' only? For context, I've been building other wallet daemons with a 'make -f makefile.unix' without problem.
Do you mean to build Biblepay wallet in Linux? I have tried to build biblepay in Ubuntu 14.04 but failed with openssl version issue. Then I built again in Ubuntu 16.04 without problem. Just follow the instructions of a file named something like "build biblepayforlinux.txt" in the git will do. Do you need to run it desktop or can you run it command line. I followed the instructions to install the wallet but i can not figure out how to run it but im new to the world of linux Mod can you answer this please. thanks If you want to run the qt (gui) version: cd src ./biblepay-qt We also have a biblepayd daemon, you can find more by googling about bitcoind if you want to run the daemon. thanks its running now
|
|
|
|
inblue
|
|
August 17, 2017, 09:32:18 PM |
|
1.0.2.1d for Windows reports a fatal error at shutdown when not using the -testnet flag. Debug.log: 2017-08-17 21:28:22 *** System error while flushing: CDB: Error -30974, can't open database wallet.dat 2017-08-17 21:28:24 CDBEnv::EnvShutdown: Error -30974 shutting down database environment: DB_RUNRECOVERY: Fatal error, run database recovery 2017-08-17 21:28:24 Shutdown: done It started in a clean folder, I deleted everything except wallet.dat.
|
|
|
|
Victory33
|
|
August 17, 2017, 11:32:46 PM |
|
Very good work with the pool dev. I already see a small movement on c-cex. Lots of people can't see really significant things with development (they will realize later)
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 18, 2017, 12:12:06 AM |
|
Very good work with the pool dev. I already see a small movement on c-cex. Lots of people can't see really significant things with development (they will realize later) Thanks a lot, and thanks to the others also. This is a long road but I think once we have our slack team, we will have plenty of help in various areas. One of my next priorities is to add an orphan subdomain for BiblePay with pages that exist with the ability to write letters to the active orphans we sponsor. I just received a letter today from an orphan, and she said she was praying for me and my family. I was thinking, this is one of the most underestimated functions (sort of like manning the twitter or facebook account), but, the most rewarding experience in the life of an orphan is the hope of receiving one of our letters. I will also make an attempt to receive letters from the compassion API and import them back into biblepay (that may take a while). I believe we can do the outgoing letters, based on looking at the interface. So, one minor change to our flow, I was speaking to a director at compassion today about some things regarding sponsorships, and one warning she gave us is that its frowned upon to sponsor and dump a child. I was explaining to her that we have a Group called BiblePay, and we intended on auto-sponsoring the longest waiting children, and if we could not afford to sponsor them the next month we would only sponsor as many as we could afford each month (I was thinking along the lines that our orphan foundation wallet bears $2000 one month, and $1000 the next month, IE a declining scenario). She said it is highly recommended that we create a system with an affinity to keep paying the premiums for already sponsored children, as multiple issues happen when we drop them. One, they are no longer the longest waiting child. Two, it breaks their hearts. Among other things. So in light of this, Im going to program this in a way that the sponsorship occurs and allows for recurring charges per orphan ID, unless we run out of money for the last orphan IDs on the list, another words, the system will distribute the orphan disbursement allocations to Orphan IDs that exist first, before sponsoring new IDs, and, if we do have less capital month over month, the remaining orphans will be dropped. She also explained that letters to the children *may* come from the wallet, as long as the sender is BiblePay. So we will work on that behind the scenes to make that happen.
|
|
|
|
happy_merchant
Member
Offline
Activity: 70
Merit: 10
|
|
August 18, 2017, 12:39:19 AM |
|
Thanks a lot, and thanks to the others also. This is a long road but I think once we have our slack team, we will have plenty of help in various areas.
One of my next priorities is to add an orphan subdomain for BiblePay with pages that exist with the ability to write letters to the active orphans we sponsor. I just received a letter today from an orphan, and she said she was praying for me and my family. I was thinking, this is one of the most underestimated functions (sort of like manning the twitter or facebook account), but, the most rewarding experience in the life of an orphan is the hope of receiving one of our letters. I will also make an attempt to receive letters from the compassion API and import them back into biblepay (that may take a while). I believe we can do the outgoing letters, based on looking at the interface.
So, one minor change to our flow, I was speaking to a director at compassion today about some things regarding sponsorships, and one warning she gave us is that its frowned upon to sponsor and dump a child. I was explaining to her that we have a Group called BiblePay, and we intended on auto-sponsoring the longest waiting children, and if we could not afford to sponsor them the next month we would only sponsor as many as we could afford each month (I was thinking along the lines that our orphan foundation wallet bears $2000 one month, and $1000 the next month, IE a declining scenario). She said it is highly recommended that we create a system with an affinity to keep paying the premiums for already sponsored children, as multiple issues happen when we drop them. One, they are no longer the longest waiting child. Two, it breaks their hearts. Among other things.
So in light of this, Im going to program this in a way that the sponsorship occurs and allows for recurring charges per orphan ID, unless we run out of money for the last orphan IDs on the list, another words, the system will distribute the orphan disbursement allocations to Orphan IDs that exist first, before sponsoring new IDs, and, if we do have less capital month over month, the remaining orphans will be dropped.
She also explained that letters to the children *may* come from the wallet, as long as the sender is BiblePay. So we will work on that behind the scenes to make that happen.
Hmm, it seems like it'd be inevitable that orphans would be dropped occasionally at that rate. Any month where less money is raised than the month before, someone would be cut. Would it be possible to set up some sort of a buffer? Say, only 80% of the orphan foundation wallet is dumped every month, and the remaining 20% is carried over unless it's also required to be dumped to fund existing sponsorships? That'd give at least a little tolerance for normal market fluctuations.
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 18, 2017, 12:45:37 AM |
|
Thanks a lot, and thanks to the others also. This is a long road but I think once we have our slack team, we will have plenty of help in various areas.
One of my next priorities is to add an orphan subdomain for BiblePay with pages that exist with the ability to write letters to the active orphans we sponsor. I just received a letter today from an orphan, and she said she was praying for me and my family. I was thinking, this is one of the most underestimated functions (sort of like manning the twitter or facebook account), but, the most rewarding experience in the life of an orphan is the hope of receiving one of our letters. I will also make an attempt to receive letters from the compassion API and import them back into biblepay (that may take a while). I believe we can do the outgoing letters, based on looking at the interface.
So, one minor change to our flow, I was speaking to a director at compassion today about some things regarding sponsorships, and one warning she gave us is that its frowned upon to sponsor and dump a child. I was explaining to her that we have a Group called BiblePay, and we intended on auto-sponsoring the longest waiting children, and if we could not afford to sponsor them the next month we would only sponsor as many as we could afford each month (I was thinking along the lines that our orphan foundation wallet bears $2000 one month, and $1000 the next month, IE a declining scenario). She said it is highly recommended that we create a system with an affinity to keep paying the premiums for already sponsored children, as multiple issues happen when we drop them. One, they are no longer the longest waiting child. Two, it breaks their hearts. Among other things.
So in light of this, Im going to program this in a way that the sponsorship occurs and allows for recurring charges per orphan ID, unless we run out of money for the last orphan IDs on the list, another words, the system will distribute the orphan disbursement allocations to Orphan IDs that exist first, before sponsoring new IDs, and, if we do have less capital month over month, the remaining orphans will be dropped.
She also explained that letters to the children *may* come from the wallet, as long as the sender is BiblePay. So we will work on that behind the scenes to make that happen.
Hmm, it seems like it'd be inevitable that orphans would be dropped occasionally at that rate. Any month where less money is raised than the month before, someone would be cut. Would it be possible to set up some sort of a buffer? Say, only 80% of the orphan foundation wallet is dumped every month, and the remaining 20% is carried over unless it's also required to be dumped to fund existing sponsorships? That'd give at least a little tolerance for normal market fluctuations. Yes, a buffer is a good idea, we should think about that before next months liquidation. We should have some type of report we can run before the 10th or so, so we can take a look at it.
|
|
|
|
smoosh
Newbie
Offline
Activity: 33
Merit: 0
|
|
August 18, 2017, 12:56:14 AM |
|
Have 2 linux machines hashing. One has a lot more power then the other but smaller one when started shows up in the account section of the pool but has since dropped off. When i run getmininginfo this is what i get. Any idea why its not showing up
./biblepay-cli getmininginfo { "blocks": 3586, "currentblocksize": 1000, "currentblocktx": 0, "difficulty": 0.03282969256960386, "errors": "", "genproclimit": 10, "networkhashps": 263656366.7425968, "hashps": 4036.079335872465, "minerstarttime": "08-17-2017 22:40:42", "pooledtx": 0, "testnet": false, "chain": "main", "biblepay-generate": true, "poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ", "poolinfo2": "RM_08-18-2017 00:42:52; RM_08-18-2017 00:44:03; RM_08-18-2017 00:43:49; RM_08-18-2017 00:43:14; RM_08-18-2017 00:43:06; RM_08-18-2017 00:45:35; RM_08-18-2017 00:46:02; RM_08-18-2017 00:44:45; RM_08-18-2017 00:43:39; ", "poolinfo3": "CFW 08-18-2017 00:42:50; CFW 08-18-2017 00:44:01; CFW 08-18-2017 00:43:47; CFW 08-18-2017 00:43:13; CFW 08-18-2017 00:43:05; CFW 08-18-2017 00:45:34; CFW 08-18-2017 00:46:00; CFW 08-18-2017 00:44:43; CFW 08-18-2017 00:43:37; ", "miningpulse": 948, "poolmining": true }
|
|
|
|
Charloz24
|
|
August 18, 2017, 01:05:45 AM |
|
Thanks a lot, and thanks to the others also. This is a long road but I think once we have our slack team, we will have plenty of help in various areas.
One of my next priorities is to add an orphan subdomain for BiblePay with pages that exist with the ability to write letters to the active orphans we sponsor. I just received a letter today from an orphan, and she said she was praying for me and my family. I was thinking, this is one of the most underestimated functions (sort of like manning the twitter or facebook account), but, the most rewarding experience in the life of an orphan is the hope of receiving one of our letters. I will also make an attempt to receive letters from the compassion API and import them back into biblepay (that may take a while). I believe we can do the outgoing letters, based on looking at the interface.
So, one minor change to our flow, I was speaking to a director at compassion today about some things regarding sponsorships, and one warning she gave us is that its frowned upon to sponsor and dump a child. I was explaining to her that we have a Group called BiblePay, and we intended on auto-sponsoring the longest waiting children, and if we could not afford to sponsor them the next month we would only sponsor as many as we could afford each month (I was thinking along the lines that our orphan foundation wallet bears $2000 one month, and $1000 the next month, IE a declining scenario). She said it is highly recommended that we create a system with an affinity to keep paying the premiums for already sponsored children, as multiple issues happen when we drop them. One, they are no longer the longest waiting child. Two, it breaks their hearts. Among other things.
So in light of this, Im going to program this in a way that the sponsorship occurs and allows for recurring charges per orphan ID, unless we run out of money for the last orphan IDs on the list, another words, the system will distribute the orphan disbursement allocations to Orphan IDs that exist first, before sponsoring new IDs, and, if we do have less capital month over month, the remaining orphans will be dropped.
She also explained that letters to the children *may* come from the wallet, as long as the sender is BiblePay. So we will work on that behind the scenes to make that happen.
Hmm, it seems like it'd be inevitable that orphans would be dropped occasionally at that rate. Any month where less money is raised than the month before, someone would be cut. Would it be possible to set up some sort of a buffer? Say, only 80% of the orphan foundation wallet is dumped every month, and the remaining 20% is carried over unless it's also required to be dumped to fund existing sponsorships? That'd give at least a little tolerance for normal market fluctuations. Yes, a buffer is a good idea, we should think about that before next months liquidation. We should have some type of report we can run before the 10th or so, so we can take a look at it. All I have to say is keep up the good work and I really think it will go upward, so orphan being dumped will not occur I hope. But of course it is really wise to think IF it go down, what could be done. What about keeping a reserve like mentionned in a previous post.
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
August 18, 2017, 01:16:47 AM |
|
Have 2 linux machines hashing. One has a lot more power then the other but smaller one when started shows up in the account section of the pool but has since dropped off. When i run getmininginfo this is what i get. Any idea why its not showing up
./biblepay-cli getmininginfo { "blocks": 3586, "currentblocksize": 1000, "currentblocktx": 0, "difficulty": 0.03282969256960386, "errors": "", "genproclimit": 10, "networkhashps": 263656366.7425968, "hashps": 4036.079335872465, "minerstarttime": "08-17-2017 22:40:42", "pooledtx": 0, "testnet": false, "chain": "main", "biblepay-generate": true, "poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ", "poolinfo2": "RM_08-18-2017 00:42:52; RM_08-18-2017 00:44:03; RM_08-18-2017 00:43:49; RM_08-18-2017 00:43:14; RM_08-18-2017 00:43:06; RM_08-18-2017 00:45:35; RM_08-18-2017 00:46:02; RM_08-18-2017 00:44:45; RM_08-18-2017 00:43:39; ", "poolinfo3": "CFW 08-18-2017 00:42:50; CFW 08-18-2017 00:44:01; CFW 08-18-2017 00:43:47; CFW 08-18-2017 00:43:13; CFW 08-18-2017 00:43:05; CFW 08-18-2017 00:45:34; CFW 08-18-2017 00:46:00; CFW 08-18-2017 00:44:43; CFW 08-18-2017 00:43:37; ", "miningpulse": 948, "poolmining": true }
Hi Smoosh, Try running with setgenerate 5 for a while and see if it stays on the board. If you have a slower processor, the shares are distributed across 10 threads and could be too hard to solve so that means a higher chance all 10 cant be solved before 15 minutes is up. 5 however will give you double the chance of staying in.
|
|
|
|
togoshigekata
|
|
August 18, 2017, 02:15:26 AM |
|
I dont think there is a surefire way to minimize orphan donation risk 100%, but we can probably minimize it a good amount? the future value of BiblePay coins could be very volatile I googled how long a sponorship lasts, and it lasts until an orphan is 18-22 years old https://www.compassion.com/sponsor_a_child/sponsorship-faq.htm#faq-tcm:5-308790so orphans are ages 0 to 22, to be certain our donation would never falter, we wouldn't want to sponsor an orphan until we could pay for the whole X years worth of their full remaining sponsorship, which could be on average 11 years, or potentially more or less depending on the age distribution of orphans Im not sure if its possible to pay up front?, and even if it was, would it be better for the worth to be stored in coins? or exchanged into dollars? This is all very interesting
|
|
|
|
m4tsby
Member
Offline
Activity: 126
Merit: 10
|
|
August 18, 2017, 02:20:22 AM |
|
Would also be cool if during the month of Nov there is a small pool of additional funds for the children's Christmas gift. My family sponsors a couple children through Compassion already and i know Christmas time / Birthday is a time you can provide more than the monthly allocation. Just thinking out loud.
Great work Dev .. I really see Colossians 3:23 being walked out here.
|
|
|
|
Ginzink
|
|
August 18, 2017, 05:07:43 AM |
|
Good thing we have a pool, even there i dont get very much but at least some!
I was just looking at the block distribution history in the pool and there is no your name for the block 3493, but you are there on all the other ones. Were you off at that time or the pool didn't count your shares for some reason? I am using the computer for gaming aswell, and then i turn off cpu mining. And mine with only 2 gpu on other coins while my gpu connected to screen dont mine. So that could explain it Btw, funfact - my computer got 17 fans to stay cool :p
|
|
|
|
616westwarmoth
|
|
August 18, 2017, 06:19:30 AM |
|
First, let me say once again, this coin is amazing. Great new algo that is groundbreaking, great team (hidden at this point) that has a great heart for the world. I don't think there is a surefire way to minimize orphan donation risk 100%, but we can probably minimize it a good amount? the future value of BiblePay coins could be very volatile I googled how long a sponsorship lasts, and it lasts until an orphan is 18-22 years old https://www.compassion.com/sponsor_a_child/sponsorship-faq.htm#faq-tcm:5-308790to be certain our donation would never falter, we wouldn't want to sponsor an orphan until we could pay for the whole X years worth of their full remaining sponsorship, which could be on average 11 years, or potentially more or less depending on the age distribution of orphans Im not sure if its possible to pay up front?, and even if it was, would it be better for the worth to be stored in coins? or exchanged into dollars? My thought would be along these same lines. According to https://support.compassion.com/compassion/topics/can-i-pay-in-advance-for-the-entire-year-of-sponsorship, it is possible to pay any number of months in advance. I would think it best, due to the uncertain markets that instead of selling every batch of $40 once per month on the markets you instead offer the entire batch once per week internally to the users at market rate or slightly higher. Then you avoid the TX fees of the exchanges and I for one would be willing to pay slightly more to enrich the program rather than the money lenders in the temple. You could basically say (on the biblepay site or via some core functionality) "The August 1st week lot is up, it is 55,000 BBL, market rate is 9 satoshi/BBL, this lot goes to the first offer of at least 605,000 satoshi or will be sold at exchange on tomorrow" Then, if there was enough to sponsor one child for their entire remaining term, that be done. Otherwise, that money would float to the next week and the additional funds from that sale added...so on, and so forth until the entire term could be paid at once, minimizing the risk of starting a sponsorship that could not be completed.
|
|
|
|
|
|