Kairos added our last inbound letters to a new page:

https://kairoschildrensfund.com/index.php/biblepayphotos/

Up til now, we have had an expanding quantity of videos on youtube.

The question is, will they start taking channels down because they are Christian - using the guise of the extended terms of service.

I guess we'll see what happens starting Dec 10th.

I don't view this as fluffy ponies and conspiracy theories and everything is A-OK.

I didn't realize Gavin was convinced Craig Wright is Satoshi:

http://gavinandresen.ninja/satoshi

Things are heating up in the world... 

Related to the Christian Treasure Trove - and the idea to archive 'non copyrighted and authorized for duplication by permission of the channel' videos, youtube has recently decided they reserve the right to delete ALL ACCOUNTS that are not commercially viable starting on Dec 10th!

https://www.youtube.com/watch?v=tpSfgPONlZk

This is pretty big news, and will cattle prod us to move to the next step with DSQL soon. 

I feel this actually might be one of the places BiblePay will shine in the end-times - by providing an alternate source for Christian content, and archived content.

So next priorities are:  POBH 2.0 in alpha for review by our IT team (and any GPU experts), PODC 2.0 fixes in testnet, then modifying DSQL to be SEO compatible with URLs, then creating the TT archive ability.

Since they are primarily in Africa and the Philipines the only idea I have is asking Todd and Andy if they can ask the local pastor if they will buy Christmas cards and let us give them a native currency gift in cash - like a $10 gift for example for the card.  The local pastor might be able to sign them for us and stuff them.

Im willing to chip in for at least 20 kids.

1) Do we have any GPU programmers available, that understand C and C++ already? 
I'm interested in running the alpha class by you.

2) Do we have any cryptoattorneys available?  To review our DWS?

I'm sorry for your loss too.


We didn't see the trust page.  We have a tendency to 'accidentally' make friends with people of questionable integrity all the time.  I do believe in second and third chances though.  Jesus hung out with the tax collectors and the sinners.  However, we have to be cautious and try to yoke ourselves with ambassadors of God. 

Yeah it was down during the night; its back up now.  I'm trying to find out why BBP was killed (because it is a high end box with plenty of RAM and swap space). 

Anyway its all up now.

I just thought of an interesting idea on the PR front slightly different than the airdrop idea (and the CPID faucet idea).

We could potentially dump the public keys out of the Dash BX, and make a reclamation system to give away BBP faucet rewards to existing public keys, that exist in the public BX as of a certain date (this is so people dont start manipulating them after).

It could potentially be a way to :  attract an existing crypto user, with knowledge, and verify semi unique new users all at once....

Something like :

1000 bbp is offered to new bbp-dash users who are found by public key with a DASH balance > .25 dash as of this date etc.

We can make a DASH-BBP faucet and a PODC faucet next.  Ill work on the PODC faucet asap.

Thanks, I read that one, and now I think we may have enough information to move to the next step.

So out of all these algorithms they all boil down to requiring a large memory footprint, since GPU ram access is slow, trying to require as much overhead as possible (IE requiring the full node for a lot of startup data), and trying to thwart parallelization, and use functions that are fast in the CPU and slow in the GPU.  The RandomX algo is one of the more interesting ones; it requires a virtual machine to be compiled and seems to be executing dynamically created code in the VM, keeping the code theoretically running in a cpu only.

There are certain traps and truths however we can use for pobh 2.0.  It is definitely possible to create an environment that can be proven to be faster on the CPU and either impossible or guaranteed to be slower on the GPU.  So far, I have an idea of making the bible into a dynamically expanding piece of code in c++11 that uses lambda functions and recursive calls, to generate a non-deterministic diagram for each block, that uses a large scratchpad for each mining thread, with heavy string manipulation for the verses (say 65,000 string manipulations recursively called from a self generating bible for that block hash).  This is so far, one that appears to be impossible to port to a GPU, because of the C++11 requirements for one.  Second, if someone did port it, the string functions should theoretically be slower in a gpu (based on the CUDA research papers for certain string functions).  And finally, if we make it a dynamically recursive self creating program, it cant be ported to asic or gpu without porting all of c++11 in.  In addition, the performance of one CPU thread should theoretically enforce and guarantee it must be run on one GPU core thread in serial - because we will dynamically call the hash function in a serial fashion 65,000 times and rely on the prior result of each recursive call branch area (in its own recursive nature) therefore breaking the possibility of parallelization.  I sent this idea to MIP and he is reviewing.


So far this seems the most promising.  I like it because its simpler than RandomX to support (we would have one c++11 hashing class for POBH, not an entire virtual machine).  Then the exchanges, and the core wallet, and the external miner could still use it.

The goal would be to keep the external miner and nomp, add this in to the external miner, and also support solo mining.  If the testing outcome is as expected solo mining would be the same speed in the core client as the external miner after its released.  Then we could raise our bounty for cracking it to 10 mil or so (however, cracking it would mean that it is proven to run *faster* outside of a cpu).

I am still looking at dotnetcore, for valuable Part B functions, but Im thinking to keep us in good standing with the world and with exchanges, we must put that project into DSQL instead and not into the miner.  As then we can theoretically lower the hash reward in the future, guarantee all of our miners are CPU-only (for 10 years!, not forever), and put the impetus on PODC 2.0 rewards (useful work) etc.

Good for them, I hope they make it.
They remind me of our roots.  When we started, we had coinsmarket.com, remember how small they were? 

These exchanges are a hard business.  I think they need to come up with a model that allows key->key trading without custody.
I really liked that idea where we could force all tiny coins to add a github API that we write that is opensource, to facilitate chain to chain trading without custody risk.

Any hacker that gets into their cold wallet - or any bad employee that goes in at night to the cold wallet takes down the entire binance, etc.

What a redicules risk these centralized exchanges have.

Thanks, and Im glad we have successfully started to decentralize, this is very good for resilience and community strength.

Ill try to explain more about the technicalities in the extraNonce and the nTime on the header.

Thats great you have increased efficiency for the time being.

First let me do a little more research on these living CPU algos that are left, like you mentioned above.  I did check into the entire list from cpucoinlist.com last night and their inner workings (btw I asked them to add us to the list), and I didn't see anything new (that we didn't know about), but thanks for mentioning Gulden.  Ill check them out today.

So let me try to explain the way the KJV bible interacts with the hash algo.

Bitcoin uses Sha256 to hash the transactions.  Dash also uses Sha256 to hash the transactions.  We use Sha256 to hash the transactions.
However the blockheader is hashed with X11 in Dash and in BiblePay.
However what is different about BBP, is we use POBH to hash each X11 potential solution (we have a layer on top of X11).
The POBH hash dictates which starting verse (out of the 32,000 bible verses) the winning hash refers to.
Verses N-N+7 are just sequential pointers from the winning hash.
So basically, the miner already knows the sha256 hash of the transactions s/he is mining.  They then pick an X11 hash for the blockheader.
Then they call POBH repeatedly with this new changing X11 hash, and POBH returns a hash (with no verses).

Mining is simply repeating these steps until a POBH hash is found lower than the target.

The verses only come into play when you go to Look at them.  We basically say, what verse is pointed to from this POBH hash?
Then we can display verses 1-7 (using the sequential pointer) from the solved hash from pointer #0.
EDIT:  I forgot to explain something.  We have two levels of verses:  mining verses and display verses.  The Display verses are only accessed when you go to look at them.
The Mining verses however *do* come into play when POBH is trying to calculate its hash.  Depending on the bits inside the X11, the hash function will call certain algos inside the POBH class to calculate a POBH hash based on the text of the verses in play that are referenced by the X11 bits (So yes POBH does use verses, but they are invisible and never seen during the calculation of the POBH hash).


I wish I could look into the server for more root causes of the errors you show, but I am still of the opinion that if the error rate is < 10% we don't really have a problem.
You could potentially ask MIP to look at that but thats if he is free.

I feel my next endeavor has to do with shoring up Two things I don't like to the full extent about POBH (I like POBH from a CPU mining perspective, but Im referring to POBH 2.0):

1) I would like POBH to be absolutely impossible to port to a GPU.  This is something I'm working on in the background, as I feel we need to break any potential white hat hackers who try to crack POBH 1.0.  (Another words, I don't ever want any hackers to be able to earn BBP from a GPU while the rest of us are running on a cpu.  This is a proactive step Id like to take now.)  This is also something I believe every CPU coin went through - and to my knowledge they all eventually failed as cpu algos - if the coin itself became successful (IE successful monetarily speaking) - Im not sure about the status of cryptonote.  Do we have any solid statuses on surviving cpu algos that stood the test of time and still remain cpu algos to this day?
2) I would still like the core client to mine by itself without an external cpuminer, and at the same exact speed as the external miner.  I did like the ability to have a 'full node' with everything in it - the way we had it before.  But we had to go through this current pain to add stratum/nomp to our infrastructure first, to get stratum in the mix.

Note:  I see the SSL cert expired on pool.biblepay.org.  It has been updated today.

Could everyone please withdraw their funds from pool.biblepay.org?  I'd like to start locking it down so we dont have the liability.

We can still have letter writing and rewards, but Im going to disable unecessary features and refactor the site so it is more secure.

I agree with you Togo and Sun, they started making centralized decisions when they should have built an algorithm for that de-listing and listing operation internally.

Also, they should have honored our 1 btc payment for a longer period.  For $9,000 all we got was one year of service.  (And for half of those months, they were down -- because they would not upgrade our software unless we paid a $4,500 fee).  So we told them to keep us down til the cooloff period is over and give us the free upgrade.  So we basically got junk service for $9K and then delisted.

Also, this KYC was sprung on everyone out of the blue- If they are decentralized they should place the servers in areas of the world that do not require KYCs.

The biggest punch in the gut though is we didn't even get our 2 month notice before de-listing.  That's a breach of the original covenant.  People can see that from the original listing thread that Togo posted.

I took a look at how hard we worked to raise the 1btc.  This was when Jaap was saving our New Exchange funds.  We should not be treated like a red headed stepchild as a charity coin.  InBlue made the comment : Can they list us for half, because we are a charity coin, but it appears we paid the full rate.  No discount!  Anyway, this $9K could have been spent on 200 orphans!  

So at the very least I think we should be given a 6 month notice, and given a chance for volume to increase.

I agree with you Togo, this is very, very bad.

Yeah, I think we should get a full refund.  For breach of contract. 

Be rest assured that the normal mining pool won't even be able to check our hash solution without the KJV bible, but nevertheless I would not mind talking to them.

If Togo or Dimarzio finds someone that appears to list a lot of coins in a multipool feel free to forward them and Ill at least have a few chats with them to see where the stumbling blocks are.

Im not personally as worried about sell pressure because I think anything that expands our relationship has both a pro and con side.  Basically from the DSS model, I feel that mining rewards are positive, because a certain amount of latent bbp sits on peoples computers, but, it is good for PR.  And a certain % of users always end up becoming investors naturally, etc.

1) I've tested your bbpminer-x86 external miner config and it seems OK, it works for me.  I dont think you need the "-p x" at the end, but it should not be a concern.
2) I don't think its your hashrate; it doesn't sound like you ever get to the point where the miner is showing the hashmeter.  After a couple minutes you should see 'thread 1: nn KH/S'.  You can try adding "-t1" to mine on a single core (this would put more availability to one thread) and see if anything happens, but imo I dont think its the hashrate.
3) You can take out the workerid, workeridfunded, and pool settings in the biblepay.conf as currently pool.biblepay.org is out of play in favor of nomp.  Basically the internal miner in the core wallet is not being used for mining, but we are using the external miner now.  (I do have a side project to fix that, so they are equal, but for now lets all use the external miner to be equal in speed).
4) You do not need to register any workerid now, you can just use a valid BBP receive address.  Please do verify the receive address you use is valid (you get it from the core client Receiving address, or, from 'getnewaddress' . <- I would look at this as this could be the problem, nomp may be hanging up on you if its a bad address.
5) You don't need to have boinc on *yet*, but, we are going to require users to be on team BBP for WCG very soon - IE within 30 days - to earn PODC2.0 credits.  See this thread if you want to help us:  https://forum.biblepay.org/index.php?topic=465.msg6515#msg6515

6)  If none of this helps, please try the external miner on another machine and see if it works with the same settings.  If it does, you might have a bad binary on win10, just re-download it.
7) You can also try this:  telnet nomp.biblepay.org 3032
Verify the screen clears.  This shows you have a connection to the stratum port.  There is a remote chance you have a blocked firewall in win10?

I was listening to a prophet on The Lord is my Shepherd, and she said Jesus told her to tell the people:
"If you die in an unrepentant state, you will NOT enter into my Kingdom."

REPENT!

Could you please paste your external miner startup configuration, and I will try to reproduce?