It would have been better if the name weren't obviously linked to the bible or to christianity. With the name its usage in the real world will be grossly limited
In my opinion it should have had the very same vision but with a different name that wont limit its real world usage to "bible associated stuff"
Yeah, I was wondering about that too. You are also potentially restricting the number of adopters for this coin, as atheists and non-christian religious people might not want to use this coin out of principle... Fine. Lets be the salt and the light, and be restricted with integrity. |
|
|
|
I think the pool site is still finicky, i was unable to save a letter I wrote. First one worked, the second letter wouldnt save. I also thought at one point you could upvote letters...but maybe im misinterpreting something.
Agree with changing the boolean values for beginners sake. My wife would have no idea what to do, especially with no labels. Would be cool if I could sort on those values as well so unwritten can float to the top. Thanks!
Yesterday, I was able to login and set up my workers, no problem. In the evening it wasn't possible anymore to login or do anything on the website. I fill in my username + password, click on 'Login' and then nothing happens. No error message, nothing. It seems like everything is irresponsive. I've tried the same thing in Safari, Firefox and Chrome but none of them work :/ If I fill in a wrong password, it shows me: 'Invalid Username or Password'. If I then switch back to my correct password, nothing happens. Is it maybe because I use quite some special characters? I don't understand why it worked yesterday in that case and not today. Yeah, Ive received 3 complaints about this on the new pool so far, so it sounds like an emergency at this point to fix. Let me take a look at this now. |
|
|
|
I think the pool site is still finicky, i was unable to save a letter I wrote. First one worked, the second letter wouldnt save. I also thought at one point you could upvote letters...but maybe im misinterpreting something.
Agree with changing the boolean values for beginners sake. My wife would have no idea what to do, especially with no labels. Would be cool if I could sort on those values as well so unwritten can float to the top. Thanks!
Just in the mean time, copy any text to notepad so you dont lose anything; Cant see a problem with Save though, worked every time for me so far. As far as boolean, yes, 1 means True or Yes and 0 means false/no. We will label the values asap. Rome was not built in a day LOL. You should be able to sort any web list by any column. Click it twice if it doesnt work. The first click is "memory" the second is Sort. copy that, i did email it to myself. No worries, I wasnt complaining, more just making notes. Maybe it was my browser, I was using Opera. Take your time Dev, experts built the titanic; Proficient built the ark. Thanks, good point on Noahs Ark. Anyway, I just labeled the NeedWritten column True/False that Blue reported, and most columns can be sorted if you click the header twice, although I admit, some columns in certain weblists dont sort as we have to manually set a configuration setting in the dictionary so if you find one you really want to sort on let us know. I also fixed the Ticket send and ticket edit functions to fill the Submitted By with any user who has a pool balance (IE so the list is not unbearably long) and actually works (yesterday, submitted by and assigned to were blank). =-=-=-=-= |
|
|
|
I think the pool site is still finicky, i was unable to save a letter I wrote. First one worked, the second letter wouldnt save. I also thought at one point you could upvote letters...but maybe im misinterpreting something.
Agree with changing the boolean values for beginners sake. My wife would have no idea what to do, especially with no labels. Would be cool if I could sort on those values as well so unwritten can float to the top. Thanks!
Just in the mean time, copy any text to notepad so you dont lose anything; Cant see a problem with Save though, worked every time for me so far. As far as boolean, yes, 1 means True or Yes and 0 means false/no. We will label the values asap. Rome was not built in a day LOL. You should be able to sort any web list by any column. Click it twice if it doesnt work. The first click is "memory" the second is Sort. |
|
|
|
|
C-CEX has upgraded to 1.0.2.9 and deposits and withdraws are back open again!
We are eagerly awaiting F7000 to come to pass now.
I have deployed the Inbound Orphan API in the Pool. Now you can automatically see the inbound orphan letters written to us as they come in, a translator (at Compassion) scans both pages of the letter and sends to us electronically. We have a service running in the pool that pulls the image and stores the images in our SAN.
Therefore now you can click: Orphan Inbound Letters, and view them.
In the near future, I will work to have these changed over to PDF so we can view each letter with one click. And add a 'reply' option.
We released the feature where the Orphan List now supports a row click to show the orphan Bio without navigating away.
The Writing to Orphan also supports a 'Letter writing tips' insitu Dialog now.
There has been a boolean added over to the Orphan Active sponsor list that reports if the child still needs written to. 1=Needs Written, 0=Already written to. We made the feature not take into account "approved" letters by design so the group can quickly start using the feature.
Im still working on the "Sent" process. I believe once per month (probably the same day that I release the foundation wallet payments to compassion to pay the premiums), I run a program that will send our outbound letters out and mark the row as sent. You will all know when it happens when the Sent flag = 1.
There is now a bounty paid by the pool for approved letters. You will see a LETTER_WRITING_BOUNTY appear in your transaction list. This occurs when we send out the approved outbound letters, the pool account then pays premiums for approved letters automatically. Just look for the credit after the letters SENT flag is set to 1. This bounty is based on the letter writing fees collected divided by letters required. (Its roughly the amount shown in the announce section).
|
|
|
|
Im not mining this coin. Im just buying.
But, where do u write to the children?
And do they write back?
Thx ^^
If you create a pool.biblepay.org account, you can click on Orphan outbound letters, and write to the children. Yes, they are writing back, so I am currently under the gun adding support for the inbound Orphan API. It should be up at least in the most basic sense by tomorrow. |
|
|
|
Could we have a feature so that in the orphan list we can see which child has already been written to? Because it's a cumbersome task to compare all the names from the letters page to the list page, especially when there will be dozens of names, so I think it can either deter people from writing letters or they will at some point unavoidably write to someone who has already been written to, which is not an efficient way to fulfill the quota. I mean, anyone could still write another letter if they wish (and it's great for one child to receive more letters), but the ones with 0 letters should obviously be prioritized and somehow marked in the list. By the way, it has been talked earlier about separating orphan functionalities and moving them away from the pool website. It seems like it's almost time to do that, but since the current user accounts are tied to the pool users, which is not the complete set of BiblePay users, I wonder how will you incorporate user accounts for writing letters and voting, while ensuring that the letters stay free from spam and vote manipulation. [...] and we will figure a way to designate Who is responsible for moving the escrow into action every month also, so as to alleviate myself from day to day activities. I would also like to make it so if someone runs off with the monthly escrow funds (IE they dont perform their function), the community can recover by itself and choose a different owner for that activity. (IE we might make it generate a new address and keypair when the panic button is pushed by the lead devs, etc).
Just an idea, maybe this can be solved (or at least the risk minimized) with some kind of a multisig setup? Yes, first, on seeing which child is not written to yet, definitely, I am working on that. Part of the next feature is giving the ability to click on a Bio and show it in a window without navigating away. Im working on both of those things. As far as moving the functions out of the pool, I have plans to move the orphan functionality eventually to a different subdomain, but, currently the support functions of the pool tie the behavior together, and, I really want to see what needs to be added to the pool for the masternodes before we go and start disconnecting everything (things like support for masternode polls and voting). This is a case where its more straightforward for us to harvest the IT requirements of the masternodes first, and then start splitting things out. So lets wait a couple weeks for the sanctuary features to start being merged into testnet and Ill do a re-discovery of IT requirements and look at that. In the mean time, view it as pool.biblepay.org is the "super pool" at the foundation, and Wests pool is the standard pool. I will work with him on having the ability to disable the orphan features on his end (we have a data driven menu). I like the idea of the multisig. Right now, Im working on the Inbound Orphan API. |
|
|
|
Im a little dissapointed on how many outgoing letters we have to our orphans. (We only had one person write one, and it doesnt even have enough upvotes to send it through the API).
I cant stress how important it is for us to send ONE letter to each distinct orphan every 60 days. We are supposed to be a compassionate organization - not a mining organization.
In light of this, a temporary solution (until we have a permanent sanctuary solution in place) is to encourage letter writing in the pool by charging a pool fee of 2% to any account holder who has not written a letter once per 60 days, unless, we have over N (being the distinct orphan count) of upvoted letters ready to be sent through the API at any given time.
So just to prepare everyone in advance, the rule would be something like this:
We have 74 orphans. If we have 74 positively upvoted outgoing letters over the last 60 days, there are no pool fees as the feature is not enabled. Once we are lacking, the feature is in force. When the feature is in force, any account holder who has not written one letter in the last 60 days is charged a 2% pool fee during block rewards. Users who have written a letter are skipped by.
This will be in effect by tomorrow.
I have been working with the API on facilitating inbound letters. We will have even more features once you have the ability to read the inbound letter and reply to it. These are things I simply cant manage myself - I am receiving mail from over 155 orphans in the mailbox - the entire bottom of my coffee table is full of 50 lbs of orphan welcome packets, pastor letters, crayon drawings, translator letters, orphan moving receipts, name changes, relatives of orphans moving down the street, something is coming every 15 minutes now, so I cant possibly keep up with all this so it must be automated and I need your help.
Once we have a little more time, I will enable the ability to add pictures to your outbound letters. In the mean time just write text letters as it is better to have something than nothing.
@bible_pay The column to write letters is missing from http://pool.biblepay.org/ >>> Orphans tab >>> Sponsored Orphan List? EDIT: OH, you have to right click the row and select Write Hmm how can we make that more intuitive / user friendly? Ill put a label on the page saying some functions require a right click. That brings up a good point; we should look for a volunteer to write a pool help guide, then I can put the PDF in the Help menu option. Pool is changing right now though. |
|
|
|
BiblePay - Mandatory Upgrade
v1.0.2.9- F7000 PoBh algorithm (Raising the Bar) - Starts @ block 7000 - Fixed Menu | Help | Read the Bible | Genesis, and Read the bible Lag - Efficient pool communication (Up to 200 mining threads) ** Please upgrade before block 7000 ** ** C-Cex is now in maintenance mode ** (posted on the Official forum: http://forum.biblepay.org) Noted, will upgrade all my wallets soon. BTW, I noticed that some workers with low "Hashes Per Second2" but higher "shares", the distribution based on "shares", right? What is the reason that high "Hashes Per Second2" but lower "shares"? Thats because the pool ratchets up miner difficulty as it solves shares, so the diff of each share is determined by how much horsepower the miner has. And partially luck also per share solved. |
|
|
|
|
Btw, I believe we will be able to make the pool track letter assessed fees into a letter writing bounty account, and reward upvoted letters after they pass the approval threshold.
|
|
|
|
|
Im a little dissapointed on how many outgoing letters we have to our orphans. (We only had one person write one, and it doesnt even have enough upvotes to send it through the API).
I cant stress how important it is for us to send ONE letter to each distinct orphan every 60 days. We are supposed to be a compassionate organization - not a mining organization.
In light of this, a temporary solution (until we have a permanent sanctuary solution in place) is to encourage letter writing in the pool by charging a pool fee of 2% to any account holder who has not written a letter once per 60 days, unless, we have over N (being the distinct orphan count) of upvoted letters ready to be sent through the API at any given time.
So just to prepare everyone in advance, the rule would be something like this:
We have 74 orphans. If we have 74 positively upvoted outgoing letters over the last 60 days, there are no pool fees as the feature is not enabled. Once we are lacking, the feature is in force. When the feature is in force, any account holder who has not written one letter in the last 60 days is charged a 2% pool fee during block rewards. Users who have written a letter are skipped by.
This will be in effect by tomorrow.
I have been working with the API on facilitating inbound letters. We will have even more features once you have the ability to read the inbound letter and reply to it. These are things I simply cant manage myself - I am receiving mail from over 155 orphans in the mailbox - the entire bottom of my coffee table is full of 50 lbs of orphan welcome packets, pastor letters, crayon drawings, translator letters, orphan moving receipts, name changes, relatives of orphans moving down the street, something is coming every 15 minutes now, so I cant possibly keep up with all this so it must be automated and I need your help.
Once we have a little more time, I will enable the ability to add pictures to your outbound letters. In the mean time just write text letters as it is better to have something than nothing.
|
|
|
|
Is there a plan to fix the "0 hours behind" qt bug in some future wallet version? If you don't transact and just mine or have a full node, it's not a problem, but if you want to send/receive coins and encounter that bug, then you will have to wait until the next block for the interface to update, which can be a bad user experience as it seems like nothing happened, you don't know if you sent the coins correctly or not.
For example, when I click to withdraw coins from the pool, in the normal circumstances I get a wallet receive notification literally less than 1 second later and the pending balance updates to that amount. But when the bug is present, nothing happens and I don't see anything until the next block, and even then there is no notification, the wallet just updates the available balance when it syncs the next block (so pending balance is never seen).
I'm not sure what steps are needed to reproduce the bug, but for me it'll happen around half of the time when I open my wallet, after it has been closed for at least one block so that it needs to sync.
I believe this is already fixed in f7000. The issue was the progressbar appears when the block is over 30 mins old. In f7000, we reduce late blocks to 30 minutes meaning we should not see the progress bar unless a block is late... This can be verified in testnet. |
|
|
|
I was doing a little research in the BBP Explorer and I'm somewhat worried by the current wealth distribution. The top two addresses each hold nearly 10% of the supply (12,509,890 and 11,585,552) http://biblepay.inspect.network/richlistBased on the transaction amounts in those addresses I would assume both are big miners. There isn't nearly enough liquidity on C-CEX to sustain large sells if either of those addresses decided to dump... There also must be some serious equipment working for those addresses to have that many block rewards. I'm a long-term holder so I'm not going to panic but I thought it should be mentioned here for your input. One of those I believe is the c-cex receiving address that the charity wallet gets dumped to every so often. You could pretty much just think of it as being c-cex, since it probably represents the majority of the BBP supply currently listed on (or just held at) c-cex. Trades on an exchange don't affect the distribution on the blockchain until funds are actually withdrawn. The other is probably a mining operation. Not much you can do about that, happens with every coin. Even BTC and ETH have wallets out there with massive balances that could disrupt the market if dumped all at once. In any case, as more miners join the network, the proportion of the hash contributed by any single mining organization will be smaller relative to the network hash rate and the percentage of the total BBP supply held by any single miner or group will shrink (unless they invest a lot of money into additional hardware to keep up, which would also mean they'd be less likely to dump for a low price). You nailed it, sorry I missed it before I replied! |
|
|
|
What are the advantages by running an masternode/sanctuaries ?
What kind of cpu's/pc it is necessary for running one?
I'm not sure what the devs have in mind, but it should be pretty similar to a Dash masternode which you can read about at https://www.dash.org/masternodes2/. Note that in Biblepay, masternodes will only receive 10% of the block rewards as opposed to Dash's 45% (if I'm reading the example in the original announcement correctly). I'm sure some of the other numbers will be tweaked as well since this is primarily a charity coin, but it should give you a general idea of what's involved. Correct, if you run a masternode, you can earn mining income for one to offset the cost of the VM, and also a monthly masternode superblock reward for holding the BBP in escrow, and the breakdown should end up being very close to this: BBP Subsidy of 20000: 10% to masternodes as mastnode monthly compensation 75% to the miner of the block 5% to IT escrow address (this covers IT issues, IT support and PR and IT payroll) 10% to charity escrow address (this will cover charity and charity rewards such as letter writing) Masternodes will govern how and where the 15% collected escrow is actually spent by conducting monthly votes and we will figure a way to designate Who is responsible for moving the escrow into action every month also, so as to alleviate myself from day to day activities. I would also like to make it so if someone runs off with the monthly escrow funds (IE they dont perform their function), the community can recover by itself and choose a different owner for that activity. (IE we might make it generate a new address and keypair when the panic button is pushed by the lead devs, etc). |
|
|
|
I was doing a little research in the BBP Explorer and I'm somewhat worried by the current wealth distribution. The top two addresses each hold nearly 10% of the supply (12,509,890 and 11,585,552) http://biblepay.inspect.network/richlistBased on the transaction amounts in those addresses I would assume both are big miners. There isn't nearly enough liquidity on C-CEX to sustain large sells if either of those addresses decided to dump... There also must be some serious equipment working for those addresses to have that many block rewards. I'm a long-term holder so I'm not going to panic but I thought it should be mentioned here for your input. I wouldnt worry too much, as one of those addresses is the public c-cex receiving address (the b6 address) for coins deposited from the orphan foundation. Whats happening is we are sending 10% of the block chain tithe funds into c-cex, selling the BBP for BTC, and c-cex is then showing an 'increasing' BBP amount on one address, but people buying with BTC against their house account are consuming some of that supply, so it looks bad from the richlist but in reality that address is getting depleted by buyers on c-cex. The other assumption I would clarify is some of us are accumulating BBP by buying it, not mining it, like me, Im not doing much mining. |
|
|
|
BiblePay - Mandatory Upgrade
v1.0.2.9- F7000 PoBh algorithm (Raising the Bar) - Starts @ block 7000 - Fixed Menu | Help | Read the Bible | Genesis, and Read the bible Lag - Efficient pool communication (Up to 200 mining threads) ** Please upgrade before block 7000 ** ** C-Cex is now in maintenance mode ** (posted on the Official forum: http://forum.biblepay.org)
|
|
|
|
Pool UPDATE:
In order to find out if a Vultr Win 2012 R2 server can run a pool, I have shut down pool2.biblepay.org, and migrated pool.biblepay.org to Vultr.
Lets see how the performance is overnight and this will tell us if this particular config will be able to be cloned.
I still can't login on the normal pool.biblepay.org page, I'm getting this error: Invalid Username or Password I reset your password to Null, so try logging in with empty, then changing it. |
|
|
|
|
Pool UPDATE:
In order to find out if a Vultr Win 2012 R2 server can run a pool, I have shut down pool2.biblepay.org, and migrated pool.biblepay.org to Vultr.
Lets see how the performance is overnight and this will tell us if this particular config will be able to be cloned.
|
|
|
|
I have yet another question. When mining on pool 2, the "amounts and rounds" section on the wallet UI says 1000/2. When I mine on normal pool, the "amounts and rounds" section is all zeros. Any input on that. Thanks for being active on the thread by the way.
Thats most likely just a coincidence as those arent used until sanctuaries are enabled. =-=-=-=-=-= As far as Pool2, it will be going away soon, once we find stability in pool1 for 7 consecutive days. They share the same database. |
|
|
|
Target Audience
Cryptologists, Scientists, Engineers, Financial Analysts, Accountants,
Investors, Programmers, and crypto-coin enthusiasts. Wait, but what about Christians? Also orphan sponsors, charity donors/givers? Shouldn't these even be first on the list? was thinking the same thing Forgive me if I misunderstood, but isn't it the job of the main node holders to decide who gets what once the coin is actually set in its ways? Or what list are we talking about? Yes, mostly, but I think its important to set the ground rules now before I hand the reigns over. I basically say up front that I wont accept: Not communicating to our orphans or receiving their communication, providing bad customer service, a greed based ecosystem, hashing outside of full nodes, being ashamed of integrating our Christian features, using charities of less than 75% efficiency, and keeping the initial parameters (such as 10% to tithes), etc. Then once the masternodes go live, the community can make changes within the bounds of these parameters, but, to be clear to our investors, not outside the bounds of the initial parameters. Just to be 100% transparent, the only parameter than I feel actually should be changed during go live of sanctuaries, and I believe I will push for this when we start our slack channel: a 5% allocation back to IT for the welfare and well being of our future. I think we need to carve out 5% out of our sanctuary superblocks for allocation to be split between IT, PR, and Charity ops support (charity support being rewards to people who write to our orphans). This imo, will be well spent and will guarantee the bright future of day to day operation. The payroll would be in the form that sanctuaries approve the expense, but the renumeration goes back to our 7 or so developers and 5-7 or so helpers in the field manning certain positions. I feel that we could merge that change in at the time we go live with sanctuaries, update the OP, and live with those parameters permanently going forward in a decentralized fashion. |
|
|
|
|
Show Posts
