Welcome Watermine,

From the RPC, you can do a 'getnewaddress' and see it (and on a side note you can type validateaddress BBPADDRESS to see all the key info about it), then sendtoaddress address amount, to send coins from the command line.

On #2, There is only one dev currently committing to github, but I have a separate slack channel with other cryptocoin devs working on another cryptocoin project that has been around for years.  Its not clear if that same slack group will eventually merge with us.  In the mean time, I created a new slack team for this coin and we have 3 members (a technical writer and PR and a project manager).  We are now starting to look for official Biblepay devs, in hopes to bring them in for new development and maintenance after the Christmas release.

The timing on this is sort of deliberate, as I found its much more productive for us to sort of set a standard and a development template, and then open the floodgates and allow the other devs to help out after the rollout.  (IE to prevent too many cooks in the kitchen in the very beginning).  Im very optimistic about the github commit model.  We will open a testnet (staging branch) by the new year and let the new commits go in there (from the new devs), and have someone compile testnet wallets and that will allow the community to test the testnet version, a config manager will push commits that pass to prod- I will approve them and merge them into prod at which point our config manager will make an official build.

Yeah, I like the gentle route myself.


I agree now, lets try to keep it simple and not add anything that makes it harder to mine.


But I still believe we should consider integrating God in, and be a God oriented community - one that at least witnesses and promotes a community that is growing closer to God.  One of the original visions was to make this a place where Christians can easily find each other, yet we will have a high percent of geeks.

Ok cool, we will just add F8000 to fix the 'processor mutex', add retirement accounts to have a highly deflationary sweep account, God nodes (super sanctuaries) with their actual use TBD, Blockchain News rebranded as multi-type objects, and Sanctuaries at Christmas.   And in-wallet trading from savings account to Biblepay.  And slack devs at Christmas.


Should keep us busy for a little while anyway.

Yeah, we were going to calibrate it after we figured the pool total hps.  Now that we have two pools, someone should be able to figure out the current HPS.

Who wants to take this on?  Then send me the results and Ill tweak the rpc command.

Thanks.

On a side note all, West started testing the news feature in testnet and then made the good point about the DAO being open to a copyright lawsuit if someone copies a news article fro mainstream news, so we sort of stopped testing the feature until we find out if there is a way to maybe have the user click a box that says I relinquish all legal ramifications held against BiblePay.   I was wondering if a few testnet users could please test this anyway with a harmless article in testnet now that testnet has 8 participants?  The reason why is we might use this for orphan letters or compiled in help guides:

http://forum.biblepay.org/index.php?topic=14.0

(On a side note the lull in sanctuary testnet is because I am adding a feature to the pool and working on the retirement accounts at night.  I would think 1-2 more days max and I will be back with the next thing to test in the sanctuary thread).

Anyway, first I do disagree that "any change we make" will be disruptive and hurt the coin.  Not true.  Ive been around the block 8* (actually Im still going around the block every day actively - right now - in the day time).  The more innovation in this coin, the better.  And, we are in our infancy, and starting from the bottom of the barrel right now.

However I agree that if we make it a nuisance, or too hard to mine BiblePay, we risk curbing the user base and I really dont want to do that. 
And I do agree that it might be too strong to try to police miners, and levy and major fee (like you all said over 15% or so).

I really like the idea of having forum URLs to mine however, I think its one thing that would set us apart as the light from the dark, in that we could promote high quality character to our community and the ones that see it as too big of a nuisance will just not take the effort to do it, leaving more coins for the true biblepayers.  We could Recommend a walk-in-Faith page, but in reality, accept any forum URL content that is "edifying" to the community.  The only content that would be "policed" per se would be something like this: Anonymous miner sets up a forum URL, and writes one unrecongnizable sentence in the blog, and its obviously not "edifying" to us.  So maybe we make the acid test Edifying/Not Edifying.  If a blog URL is "not edifying" the sanctuaries hold a vote to mark the URL as neutered.  At that point the mining activity on it is rejected.

So let me propose a new idea- one that would work by default:
- Mining URL would be Required for all, otherwise no blocks would be mined (something like URL=http://  in config file)
- If one sets up a blog that is Not edifying and links to it, and is not caught, the mining works but blocks pay at 75% level
- If one runs a non-edifying blog and Is caught by a sanctuary, and vote is entered to ban that URL, blocks start paying at 0% level after the vote
- If one runs an edifying URL, payment starts increasing from 75-100% over 60 days, until full seniority is reached.  One must just continue to add something edifying one a month to the blog to maintain 100%.

So blocks would always pay 75-100% with a valid URL, depending on seniority level, and 0% with a Banned URL or a missing URL.

The sanctuaries would have a command to 'vote against URL' and if supermajority pushes the command, the URL is then banned.

What Im thinking is this would end up giving us a Huge, positive web presence, and a closer loving community.

Also this opens up wide avenues for PR.  If the forum blogs are all biblepay it would be very easy for this to help with PR.

I believe thats what is happening with steemit- with all the paid posts, they drive their own popularity and hence total market cap.

I forgot to mention another potential nuance to upkeep (as its not fair to have one miner writing a letter and another creating a blog and never updating it).
If they write a letter in the chain, they get the full block reward.

If they maintain a blog, the hashed key of the URL gradually pays from 25% to 100% of the block over time, if the blog is growing.  If it becomes static, the meter starts declining again.  So the idea is they have to blog at least once a month to maintain the 100% pay level of the mining reward.  This way if someone decides to delete the key and start a new blog, they relinquish all seniority and start back at 25% again.  Maybe it takes 1 day per percent to gain seniority to 100%, and then as long as they add more to the blog, the % stays at 100%.

I thought about POS in the beginning, but I read so many negative comments about people getting tired of waiting for their investment to grow, and others seem to like POW due to the exciting nature of finding a block.  So I thought, you know, we can adapt POW to work with almost any complicated input.  Our sanctuaries do act as a 50% POS buffer (they are an investment).  Now we are more flexible as we have both.  

Yes, I really like what you and West had to say about the risk of repentance.  On a side note though, I didnt mean to suggest that it was definitely related to Christian repentance, but yes I did mean to suggest it was Bible based repentance. 

Lets definitely entertain more ideas, and break this down into even a more basic idea.  One that has to do with the privilege to mine to begin with.

Im thinking first of all, this is technically the opposite of one click web mining.  Its more of an added step for the privilege to receive biblepay coins from mining, and something that has to be maintained on a regular basis by the miner.  Although this might be counter to the popularity argument, I actually think the benefits of this outweigh the risk. 

What ends up happening is I think the true believers in BiblePay will stay and maintain the miner, and more coins will then be available for them to mine.  These are the people most apt to invest in biblepay.  This actually increases our value (making it have intrinsic value) in contrast to bitcoins energy arb equation (when you have just miners with black boxes, the price is related to how much energy it costs to mine a block).  That to me sounds like a winning attribute to start with.

So, lets shift the idea a bit.  Maybe we let you choose to either maintain a "walk in faith" URL (from forum.biblepay.org) that genuinely explains your walk with God as a miner on your personal URL page on the forum (using minername), IE your sinner testimony +  your spiritual encounters  and how you grew closer to the Lord.  That URL would be mining argument #1 to mine biblepay.  It would be policed by BiblePay police department (sanctuaries).  For incoherent pages and bad character- who would then lose the mining key.

Alternatively Option #2 is you could prove that you wrote a letter to an orphan within 30 days.  One or the other.  All others dont successfully mine the block the miner just keeps running.

Orphan letters cannot be reused.

We could potentially change the news creator page to our new letter writer page in-wallet, hash the orphan letter, and use that txid as the input for your mined block (for 30 days).

The URL for your walk-in-Christ or walk-in-God page could be created by you on our forum, and then linked in the mining config setup.

So Ive been researching the difference between X11 and F7000 and have uncovered some more info related to HPS consistency across all processors platforms and instance counts.

Some of you have really been hard on me, especially those who cant grasp the distinction between a "node level mutex" and a "processor" mutex.  You even went as far as to say the BibleHash itself is inconsistent.  One thing Ive learned over 30 years in software, is nothing about a computer or its software is inconsistent.  (Unless someone puts a rand() statement in the code).  Another words, every "hard" problem that Ive seen over the years, in the end, always has a very clear reason. 

Let me explain the difference between a node mutex and a processor mutex.  A node mutex is one where an instance of the software is forced to wait somewhere in the
 *instance* of a program for a memory space to be available.  A processor mutex is one that consumes the entire processor and it does not have to wait except for new work, and the entire server is frozen in what appears to be a locked state (btw, a crash is very different than a consumed processor).

So with BiblePay, with Pre-F7000, we had a processor mutex, in the sense that one had to buy more hash power to hash against the money supply.  With F7000, the goal was originally more of a much stronger line of defense against GPU porting, hence the reason we added the node mutex.  Ill stop here and explain.  There are two places in BibleHash that are extremely hard or impossible to run on a GPU: asking the node to go back in the chain for a block index hash, or for example a transaction hash.  Since the node level instance stops hashing while it waits for the data, the other mining threads slow down.  Otoh, if you run multiple degraded instances on one server, you have parallel stops.  However, what I dont like about that is it encourages low quality instances whereas I believe it is healther for us as a community to have higher quality instances.

So in light of this, the basic explanation is that F7000 does do its job in preventing BibleHash from running on a GPU, but it promotes the user to run as many low quality nodes as possible to squeeze as many BBP per hour from our community. 

I think the answer to this is during the Christmas update (Sanctuaries), we release F8000 with a few more enhancements to fix the problem (we can test these in testnet as soon as available).  #1:  Add a math problem to BibleHash.  This would force the processor to execute a few hundred K of instructions deterministically but unknown at the time of the hash (IE Block hash + timestamp  hashed) so no one can predetermine the problem, and this solution would be similar to executing N X11's hashes for a second or so, thereby changing the state of the nodes miner back to a processor mutex level, thereby solving the degrading network problem. 

The other thing I would like to introduce before Christmas update is making mining more of a privilege.  I was thinking, instead of asking BiblePay to pay you simply because you plug a computer in and *want* to hash, what if BiblePay wants you to contribute to the community?  I was thinking at the very least, the node will somehow need to ask the miner to Repent for sins and make a blog of progress.  Maybe we make the mining software require a Repentant sin in the block, (IE Think of the 40 mortal sins listed in Send Money (in the wallet) | check Repent | Look at the dropdown values), maybe each week, the miner must repent of a sin, and describe how they are doing in their walk of repenting for sins in the message.  If no repentance is being given, no mining is awarded.  But each week, either a new description in the walk of a sin free life must be added, or - a new sin to be worked on, this way we can hash the repentance information and ensure it is changing once every 7 days (this way, if its done once a week, its similar to keeping the Sabbath).  So our miner would help you Keep the Sabbath.  You will wonder, how will we enforce it?  I think we can have a REST URI built in, and have the sanctuaries run the RESTful web service, and ban miners who arent repenting coherently.  Their miners would be shutdown.  It could be a service we require of the sanctuaries.

I think these two features would make BiblePay consistent across all platforms, and require a level of participation to weed & feed out the wheat from the chaff in the community.

One thing I forgot to mention for new users: We have the Tools | One Click Mining config menu option in the wallet.  It automatically creates the config file and some addnodes for you.  If someone will please test it out, and see if it works properly.

Looks like the external node max connections is pegged @ 1024 (Windows limit) maybe thats why (this only affects a brand new user before they sync peers.dat).  I think I will need to set up multiple seed nodes resolved by node.biblepay.org. 

Anyway try to add:
addnode=inspect.biblepay.network

To your config file and then restart.


(The node.biblepay.org is compiled in already).

Thanks!  Good to know.

The rBBP goes to the miner who found the block, this way the security still works.  The pool will receive some rBBP also, so we will have to add retirement fields in the pool so you can withdraw your share of retirement coins also.

Yeah I had hw acceleration enabled and did it before too, so I guess just change it if its a last resort.

Its on google product forums as a known bug for the "File" container.

I just had trouble adding a picture of a lamb to a letter.  If anyone is having trouble adding a picture to a letter in chrome try this:

Click the Menu Ellipsis | Settings | Scroll Down to Advanced and open | Scroll to the System Menu Div | Disable Use hardware acceleration.  Then I was able to add the picture successfully in chrome.  It should already work in other browsers.

I recreated the emission schedule and created these two pages:


EMISSION SCHEDULE PROJECTION: http://wiki.biblepay.org/Emission_Schedule

ECONOMICS: http://wiki.biblepay.org/Economics


I will update the OP and the website.

No, not really, we had one complaint over the whole thread that I was going to be bent on changing emissions after Christmas, and that is simply not true.


  I feel the integrity of our economics is paramount and will be set in stone.  The enhancements created between go live and Christmas I think are of such a value add to the coin, they simply had to be added in for our community to finalize the emission schedule while Sanctuaries go live (The sanctuary event at Christmas is a mandatory change) so it was our last chance to finalize the emissions.  The things added to the original design are:  Better budget allocation (see below), 1.5% monthly deflationary schedule in emissions, and a 50-50 split between Sanctuaries and Miners to promote long term biblepay sanctuaries.

Therefore I would like to reiterate the proposed economics now, and modify the first page with the changes (as I think everyone agrees, these few changes are very, very positive).

Let me outline the major points of the economics proposed for the Christmas version of BiblePay, and say that you have my word this is the final version, with no major changes forever (all of the devs will agree that no changes will be made to the emissions or block subsidy after Christmas, so that our investors are comfortable in what they are investing in):

- Block Emission Level: Variable rate between 20000 and 5000, based on the network difficulty level (higher diff, lower block subsidy)
- 10% is given to Charity (IE compassion.com) through the sanctuary voted budget
- 5% is given to IT (through sanctuary voted IT expenses, such as IT payroll, letter writing, PR etc)
- Out of the 85% remaining it is split between one cold chosen sanctuary, who provides POSE (proof of service) that has waited longest to get paid, and the miner who found the block

- The deflation rate of our emission will be 1.5% Per Month after Christmas
- Each block rewards 10% in retirement coins to the miner who found the block, in colored coins called rBBP.  These can be traded on the secondary
market inside the wallet with other biblepay participants for BBP.  The retirement coins emission rate drops by 1% Per Day.

With these economics, our official projection up to 2050 will have to be re-created (I will take care of that Now).

Due to the higher deflation rate chosen when sanctuaries come online, and the effect of the difficulty on the schedule, the schedule will produce only about half of the coins over the long term as we originally projected (That is because the original projection didnt take into account the 1.5% monthly deflation rate that we added in as a bonus feature
for sanctuary go live, nor did it take into account the huge block difficulty the algorithm is experiencing which reduces each block reward significantly).

I will take care of that projection recreation today and repost everywhere and also update the OP with all of this so that we are exactly what we say we are.

Btw, Up to the block at Christmas, we currently have a tithe block - this is one block out of every 10 - which we give to compassion.com.  That block no longer will be created after Christmas.  It is then up to sanctuaries to vote on the Charity Budget for those expenses to be generated into superblocks.



[/b]

This would be a good thing for someone to take on.  Someone to write a professional Help Guide for the entire pool, and then we can link to it from the pool.

Hps1 may be removed in the future, after we finalize the algorithm.  For now I would add it to the help Guide.

SeasonW, in the mean time it would be very helpful for you to add a wiki page about HPS, you can find the place I spoke about it and elaborate on it.

Its not your job to give work to me, its your job to ask what you can do for BiblePay.

Im working for free and trying to create a loving community.

I will add a much more descriptive paragraph to the pool on how to write a letter to an orphan later today. 

I wanted to throw this out there for the Zealous:  something I would do if I had more time, but Im currently writing a script language extension.

One use case for BiblePay is potentially a Bible Pay store.  Maybe we start with bibles and coffee mugs.  It would just be cool to be able to click on the item and buy it with bible pay.    One of the things I do on one of my sites is I give away bibles.  One of the cheaper ways to buy a good bible is to search for "NKJV" bible on Amazon, and you can usually pick up 3 at a time for $4 each and free shipping if you are prime member.  If I were taking a stab at this I would try to integrate "drop shipments" from the amazon API to drop ship your order directly to the end user.  So the idea is something like this:

Your new storefront offers Product 1: $8 for a NKJV bible, and say 10,000 in BBP.
User checks out.
Your API connects to amazon and drop ships to the user.

It would be sweet huh?

Try it if you are zealous!  Some day I will add a couple products to the pool, and add the shipping address fields to the user account.

This is the best post I read in the last two days.  You can see the positive vision from every degree in this case.

Without it I was thinking of closing down this thread, but thanks Ferohers, I will keep it open longer and see what we can do to create a utopia here.


I want to formally invite a c++ dev to the slack channel that has worked before on one of the top 100 cryptocoins.  I want to collaborate with you on a few things, one being improving the multithreading in the biblehash algorithm to make it more consistent for everyone.  If you are interested please send me an email to rob@biblepay.org.


In the mean time, Im working on extending the bitcoin script language to add BiblePay contingent transaction types for retirement accounts.