On the increasing letter fee:  There will be zero letter fees on other pools, because there will not be letters.  The other pools offer mining only.

The other pools that pop up dont have the ability to send the letters to compassion through the API.  Only the "biblepay-central" website can do that (that is currently pool.biblepay.org).

I am increasing the fee because we are not receiving one new outbound letter per day to the orphans.

I dont think you understand the feature.  The feature gets shut off once we have more than 105 outbound letters in a 60 day period, then the pool fees return to zero, until orphans need written to again.

I appreciate your concern that a child might want a new pair of shoes, and that is understandable if you dont currently have an account with compassion.  The compassion letters from pastors constantly remind me that I should be writing one letter per month to each child.  That is why the feature is so important. 

Regarding the retirement account feature, that is an add-on feature, and it is designed to enhance biblepay.  It does not change the original vision.  The original vision is going to be extended until I realize we provide real world value to the blockchain.  I would suggest trying to help us add value instead of trying to hamper our growth efforts.

One way you can help, is to realize we are a grass roots organization that needs your help, not your management of others.  For example, it would be helpful if you would create an entire wiki page describing how the pool works and then asking us to add it to the help section of the pool (instead of trying to direct me to add snippets to the pool help section). 

Yes you got the general idea, but it would not be entirely without speculation effects in BBP and market price changes.  The financial ecosystem of biblepay changes slightly:
- A block reward of 10,000 biblepay would include something like 2,000 retirement coins (that 2000 rBBP component of the reward would decrease by 1% per day - forever)
- The retirement coins can only be spent by sending a certain colored tx to another user OR by trading them in the BiblePay trading system in the wallet (for BBP! not rBBP)
- The price of BiblePay *would* be affected in as much as : Outside users may buy BBP on an exchange for BTC in order to run the wallet in order to buy rBBP inside the wallet
- If a person nears retirement wants to dump 10 million rBBP, they will crash the in-wallet market, and therefore lower the price of BBP temporarily as the outside market absorbs the shock (normal arbitrage)

Security considerations:
- The colored coins cannot be sent outside the wallet and cashed in on an exchange, even if the keys are compromised - because the coins will be colored, and they have a value of 1/10000 of a BBP and less per satoshi inside the wallet internally
- Rules will be added to only allow colored->colored transactions
- Colored coins are not selected for payment from AvailableCoins or in Coin Control
- Tx with colored coins are only allowed to be 2 vouts (no complex tx allowed) and all outputs must be colored

Market makers will be available to cross a transaction (this would be one chosen sanctuary at the time the trade is placed).  So basically, User A wants to Buy 1000 rBBP for normal BBP, user B wants to SELL 1000 rBBP for BBP, Market Maker C jumps in and receives the escrow from both parties while putting up the equivalent amount of escrow, then crosses the trade and then completes the transaction.  Resulting in one person buying retirement coins for normal BBP and one with less retirement coins and more BBP.

The goal is that some participants view this deflationary retirement asset as something they want to hold for a longer period therefore they tie up BBP in rBBP for a longer period of time.

Interesting coin...  Kind of wild...

Telnet is connecting successfully right now- we may have overloaded the connection count at that time on the seed nodes.
(Windows can only handle 1024 connections).
You can also try:  Biblepay.inspect.network is another good one to add as a seed node.

From a command line try this
telnet biblepay.inspect.network 40000

If that connects you should be able to add the addnode= to your config file and restart.
Also:
addnode=node.biblepay.org

I just wanted to mention that I have been a little busy lately (other than being interrupted to upload the pool, which is a huge necessity), with a brand new cryptocurrency feature for biblepay.  I think it might be "the" feature for us that gives us the edge to the top 50.

I'm thinking about adding colored coins into biblepay with an integrated 401k or retirement account fund inside the wallet.  And in-wallet trading.

I'm thinking maybe we can be the first coin with the ability to trade BiblePay for our second asset inside the wallet (other than Ripple, but technically, Ripple is a network of market makers making existing markets).  This is a little different.

I'm thinking we emit a new deflationary colored currency (called either retirement coins or 401k coins) inside the wallet on a schedule decreasing by 1% per day.  Then, the wallet will keep track of both normal balance and "colored coin" balances.  So you would have your BBP balance and your rBBP balance. 

   Starting on the day we have retirement coins, the retirement system would emit 1 million retirement coins per day equally divided over 202 daily blocks to the miners who mine the blocks.  However each day, the emission rate would decrease by 1% .  So on day 2 we would emit 10,000 coins less (or 990,000 retirement coins over 202 blocks).  Each block solver would receive normal BBP, plus a separate share of colored retirement coins.  If you mined 4,000 retirement coins on day #1, your balance would now be:  1,000,000 BBP and 4,000 rBBP (retirement bbp). 

You cannot send colored coins to an exchange to sell them and cannot buy colored coins on an exchange.
All colored coins must be sent in a transaction that includes a reference to the root of the colored coins (another words, the colored indicator on the tx, the previous output is colored, and the new vout for the receiver is colored).

Available coins for spending will never select colored coins for spending (IE They cannot be spent). But they can be Traded for BBP with other holders through Trade transactions.

A new RPC command will allow you to send colored coins back and forth among others, if you want to give them to others.

Now here is where it gets interesting.  If we view the colored coins as a deflationary retirement account (assuming that IF they are becoming scarcer, storing FIAT in rBBP would theoretically result in a gain in value).

We implement in-wallet trading to allow trading from BBP to rBBP.  So we would have RPC commands to "execute order SELL 9000 rBBP for 1100 BBP" for example.  Other in-wallet users would "execute order BUY rBBP 5000 for 700 BBP".  When the matching engine matches an order over the nodes, one masternode  who is the chosen winner of the round (chosen winner meaning which masternode has the closest hash to the center of the blockhash for the current BBP block, can be active market maker for this tx).

At this point, the masternode jumps in, Locks the trade, grabs the collateral from the seller and the buyer, crosses the trade, then unlocks it and it is completed.  We will have a Trading log in biblepay, so you can go into your separate debug file and monitor STEPS that occur during trading.  (In case something goes wrong partially through).

Lastly, partially executed orders would be changed via a MODIFY - so if only 1000 got filled your order would readvertise with the partial amount left.

In this way, we would have in-wallet trading, colored coins, and a second deflationary asset inside biblepay.

My projection shows that the retirement coins would deflate for 4000 days before reaching a floor where they would be emitted at approximately 1 per day (if we start with a million per day).  I think at that point, I would like the system to reverse split the coins and start over, so that we perpetually have a deflationary retirement asset inside BBP.

One benefit of having this particular feature is we would attract outside investors that would need to buy BBP in order to have the ability to buy rBBP and they also potentially download the wallet and be users and might have a tendency to be long term holders.

Yes, someone here on the forum said they were compiling biblepay on arm the other day, and said they would be excited to post the HPS of the pi.  Anyone?

Afaik, to do this, there are about 50 lines of code that might need to be added- things that hint the compiler to do certain things.
When we get to the stage of having a PPM for linux, we can ask our configuration manager to create a compile step for arm and for mac.

I think once we attract a few devs into our slack team, this would be a good fit for someone who really likes to maintain our releases as a volunteer.
Once we have our IT voting running, we could put that person on payroll.

Even though the firewall is open on the windows 2012 server, check AWS master console to see if you are subject to the AWS default firewall policy. I remember at work we had to clone it and modify it.

Then from the server you can install telnet client and try the same test from the command line through the public IP.

Also you can install the block explorer as an add node, but I doubt thats it.


** I uploaded the SQL database creation scripts to github **
Now you can run schema create and then data create.

 

Hi,
First on the daemon inside the AWS cloud (or wherver you want to run biblepayd as the pool hot wallet) ensure this is in biblepay.conf:

rpcuser=myuser
rpcpassword=mypass
rpcallowip=your_public_ip
rpcallowip=your_home_ip
rpcallowip=127.0.0.1
rpcport=30000
server=1
daemon=1


Then go to home computer and ensure you can 'telnet daemon_public_ip 30000' ensure that that answers?

Ok, I will start working on that biblepay.bak file for you to see also.

Thanks.

Yeah, that looks 100* better.  Thanks a lot! 

Now we are moving forward again.

Thanks for the spreadsheet, thats a nice sheet, and it appears to cover all of the processors.
It would be nice for us to have a smaller subset of it (maybe the top 50 variants for example).

I dont want to give anyone the impression that I dont care about hash speed measurements.  I do care- however you have to realize I am taking into account an element of a moving target, a feature merge, and a potential defense mechanism.

I have to prioritize the far future value of Biblepay, and right now the highest impact to Biblepay includes two major issues:  Integrating sanctuary proposals and budgets and integrating our in-wallet retirement system. 

The reason the final HPS is still a moving target is if we ever need to program in a defense system (IE we feel the wallet is being attacked by GPUs or ASICs) then we can build a feature into the sanctuary to provide a mining key to other miners and allow the sanctuary to measure the HPS per solution.  Maybe it will be that we make participants create keys for others (IE share the love, instead of the greed) thereby requiring a certain amount of time to elapse between a request by a greedy node who mines really fast to actually receive another key to mine more. 

The bottom line is I feel the actual measurements are consistent with work being done and yes, being a node algorithm it is quirky, but not in a way that would prevent one from setting up equipment to mine as fast as others.  Thats why I set the priority level of this as lower currently than everything else that is going on.  The retirement account feature is very exciting, and I feel it has the ability to make our community much more vibrant, so I am currently focused on that.

Lets not forget to integrate God into every one of our processes every day.

Who wants to volunteer to start and run this campaign?  If I do it, its going to be after Christmas, so id rather personally have someone else take the initiative to baby this and manage it all the way through in a dedicated thread.  Ill give you admin access to forum.biblepay.org to manage the whole topic.  You would be responsible for putting up a downpayment with a credit card to start their campaign and starting a fundraiser for BBP for the total cost in the new forum thread.

Who wants to volunteer to fix this page:

http://wiki.biblepay.org/Main_Page

We need to make it more professional, take out the html characters and add anything to it that makes it more consistent?

I think we need to put our logo on the right inside the table on the second row also.

Just let me know when you get the ASPX compiled and "almost" running (IE pool starts in debug mode and you cannot login).  At that point I will upload the SQL backup file of the empty database into github.  (I will get to it hopefully tomorrow).  So dont waste time recreating the schema as I have all of it.

Here is the source for the BiblePay Pool:

https://github.com/biblepay/BiblePayPool


Please see the document titled "Deploying a BiblePay Pool.docx" in order to understand the technology required to provision and deploy a pool.

  On the badmouthing I agree, I know you are not, Im referring to some people who make posts here with foul language, and I really think that goes against our spirit.

Thats cool, we can work these issues out.  Lets start over on all this.

Let me find the pool creation document and see if it is uploaded yet and see if I can answer your questions.  Did you create four topics with questions about the pool on forum.biblepay.org about the pool and delete all of them?

I also wonder, can you find a Gen II or Gen III wallet designer?

(Not a logo designer, a Gen II pro-themer).

Take a look at this thread:

https://cryptocurrencytalk.com/topic/14745-fundraiser-for-gen2-wallet-theme/

They went through it and it looks like a really FUN process!  We could put links for Exchanges, for Prayers, (CBN.COM! in wallet), for Block Explorer, and take care of the theme all at the same time.  Im willing to put up $500 of biblepay for this too.  And $500 of biblepay for the logo. 

All I ask is some contributions from the community for the remainder to the themer, and the community gets to choose the final designs, colors, etc.

No, the pool is not closed and proprietary, its open source along with the github wallet.

If you think I am "lying" on this forum about Anything then this wallet is not for you.    Have I lied about anything here?  What kind of dev would I be?

Running a pool that forces the majority of the hashrate?  Only one person has come forward to run a pool, and he is currently following the instructions. West do you want to send him the same instructions?  Am I hiding anything? 

This is a project for the orphans. 

Alienating?  Ive been working with everyone who doesnt have a bad mouth and a bad attitude.  Id rather work with Christians.  I replied with my view, and no one has posted anything yet that is a higher priority than sanctuary code and our orphans.  The bible hash is doing its job and Im very happy of that.

Yeah, I did agree that we should have a logo contest also at least 30 pages back.  I am willing to stake the first $500 for it, and let the community vote on the logo files.

Keep in mind, I want an entire logo pack : the scalables, the pngs, the jpegs, the svgs, all of it, so this is a $750 job.

Just to reiterate this again:
- All shares issued by the pool are the same difficulty
- HPS2 is supposed to be different than HPS
- HPS2 is based on how many shares you solved in the current round, while HPS is based on your CPU clock hashes per sec.
- The pool is not behind and is able to handle the load (I know because I wrote it, deployed it, and I monitor the performance counters)

You can see clearly that when viewing the leaderboard, the same machines are at the top- and we have a consistent list of users per hashpersec2 reported in the same places. (IE randomness is not a primary factor).

There are certain people here on this thread that are unhappy that lower end processors achieve a higher HPS than their proc.  That is a personal problem.
All the code is public domain, you are all free to download it from github and run variations of the miner on your bench if you think there is some inconsistency with your processor.

The KEY ISSUE that some people are not grasping with biblepay is this:

A high percentage of processor power in the biblehash algorithm is going to querying the node vector itself, not wasting CPU cycles on the hashing.  So if you want to look at this another way, you are being comepensated 60% for running a node, and the rest for the speed.  Im happy we ended up like this as it gives everyone a chance to jump in and receive some BBP.

My main concern is to ensure the algo does not get ported to an ASIC or a GPU.  Im busy over in our other forum deploying code to enable governance.
We need to ensure that we can service our 100+ orphans and create a full decentralized IT infrastructure to support the orphans far far into the future. 

No this is not the case (LOL, what kind of pool would that be).  No the pool hands out equal difficulty work to everyone.  As you solve the shares, the work is checked against biblepay to make sure your solution is not only a good hash, but matches the solution in biblepay for the original problem.  Then you receive credit for the share.

If you were to ask me if we have a speed inconsistency problem, let me say this:  I see absolutely no problem in the measurement of HPS or the reward in HPS2 per CPU class in the pool.  What I find unusual is how windows machines can achieve an HPS2 of almost as high as linux machines, with HPS showing much lower than than linux HPS.  That is it that is my only inconsistency on my mind.  Everything else Im happy with, as we are promoting fair mining shares per node.

As far as the pool helping, I think the pool provides a fair avenue for mining.  Without it you would be out there solo mining.