This is just an estimate, but the way the price is stabilizing (hovering around 20 satoshis), I think the sactuaries would be approximately 700,000 bbp of escrow each.

Hi,
No, the testnet coins are all worthless; just for testing.

Its slow because its getting hit with 400 requests per second right now, and I can actually see the record count per second.  It can handle about 250 or so and appear to be OK from the user perspective.

We need everyone to upgrade to 1023 until the next version is out.  If anyone is out tonight please upgrade to 1023- this is not the optimal version but its better than 1022 down for the pool.

The pool is getting pounded again.  I had to lower the max supported threadcount to 15 temporarily to give the server room to breathe.

Ill take a look at ways to upgrade the server tomorrow.  We will need to ask everyone to upgrade to the latest version also, as it contains more efficient pool communications.  More on that tomorrow.

Regarding volatility (ie market risk) with dumping the orphan wallet once per month, you guys/girls have convinced me that we should reduce the uncertainty by dumping constantly.  I originally wanted to consolidate that function down to one day per month, so that we could have one person dump, transfer, and sponsor orphans in one day.  But, I fear that we are causing market uncertainty by making people wait until the 3rd friday to buy our tokens.

In light of that, I will ensure we do a constant random dump of the orphan wallet every couple of days, and we will keep the sponsorship of new orphans task for the 3rd friday of each month.

Possibly try to copy your config up to your %appdata%\biblepaycore\biblepay.conf file
instead of the \testnet3 directory.

It is working for me on 2 machines.

If not, try to clone one of your working machines settings or create a new workerid?

Alrighty guys here is what I need help with in testnet currently.
We only have one person in testnet (I think thats Happy).
We need a few pool testers.  Im looking at the current released version of f7000 (for download) and it is 1023.  That client is OK to test in testnet for today, as I primarily just need to test compatibility with the latest pool and the almost latest version of f7000.  The only unreleased feature in 1024 is the enhanced readytomine packet, and we dont need to test that today (that takes 12 hours for a release, and Ill be traveling).
So for now, please grab a linux or win 1023 build or higher, and set it to pool mine against testnet.

I set one box up so far and see myself in the leaderboard.  We also have to ensure the pool payments are correct in f7000, so we have to wait til we (pool) mine one in testnet.

Ill set up one more box against testnet in a few minutes.

Thanks.

 

Thanks JaapG and Happy,

No, I dont have anything except I do want to compile a new windows version, and enable the pool again against testnet, and ensure the poolmining works in f7000.  Thats a huge test, as the entire pool would fail if we issued a mandatory and everyone went down at block 7000.  So let me get that done next and ask for help.

As far as the release, all we really need to do is put a ticket in at ccex, and ask them to shut us down before block 7000.  Then we give them as many days as they feel necessary to upgrade.  So I think what we should do is announce it around block 6200 or so.  Hopefully it wont interfere with Septembers auction.   Either way, that does not give us much time to finish testing here, so lets try to ramp up finalization on f7000 over the next 3 days.

And finally here is one paragraph I pasted earlier:
 Please be honest and open, is there anything that makes you nervous about f7000, or something that I need to triple check while tweaking the final pool settings? The latest code does include the readytomine backoff that shoud allow the pool to breathe much easier.

Thanks a lot for the specs.  That came out of left field.  As of a couple weeks ago, I was assuming the newer intels were 2* faster than the amds (because I have 6 two year old 6 core amds sitting around from a prior project) and they all hash at 87k, while my friends intels hash around 125k (while being 2 years newer), and then we had the xeon server guy hash at 350k on an old quad core xeon (unknown proc count though), causing me to order a couple xeon servers which are not racked yet.  So, basically, the brand new AMD ryzens, pulling about 200 watts, can hash at 450k, making them the fastest the leaderboard has seen. 

  Looks like we will need a wiki page to start logging all this by specific processor type.  I would really like to see a wattage column also (the intel i5 laptop can hash at 100k using a 20w total consumption from a solar panel etc). 

Yeah, we should set up wiki.biblepay.org.


On the bright side, with the algorithm tweak coming at block 7000 (with the f7000 feature) we will have to re-establish everything we know as the hashps will be lower for everyone, and the txid lookup may influence the result slightly differently over machines (due to disk lookups in the mix), although in general I believe everyone will drop an equal percentage overall (due to disk caching).

Nice artwork!  Maybe you can be our twitter presence, that is if you want.  I was thinking eventually, our twitter admin would need to retweet release notices and any happenings we have, and possibly escalate issues users find that we dont know about back to slack.

Nice job- I was able to load it in vs2017.
I dont have bitcoinlib though, but I do have bitnetc#, and I can follow what you did, thats cool.
Ill keep it in case I need it.

Yeah, the relationship is foggy because each mining thread does not consume 100% of the core- due to OS multitasking, etc.  So we just recommend to use more proc, just increase the proclimit higher and the OS will make more than one thread run per core.

Thats a killer hashrate.  What specs is the machine- how many cores, procs, desktop, how many power supplies and what watts does it pull?  Thanks!

Thats just on the web pool admin side - its a setting governed by the pool administrator.
I was thinking about testing that adjustment after doing some hardware upgrades and being closer to opensourcing the pool.

I have a really big server at home, and a network rack, and I might possibly move the pool to that server (its a quad processor xeon, 150 lbs server).  We'll see.  Then we could test raising it.

Im working on a high power linux gitian build machine though, because I want to make fast windows releases- so this will sort of need to unfold when I get back.

Thanks Happy,

I really appreciate the analysis.

So thats great news, I think we tackled the biggest problems.  There are no clumps, there are no easily solved blocks other than tithe blocks, and I can clearly see the 30 minute late block threshhold is working, bringing down the primary average to closer to 7 mins as it should be (instead of 15).  Also, this appears to be forming a reliable network - to send money across and expect a 49 minute confirmation time (if not using instantsend) as opposed to 'praying that the coins confirm between 40-200 minutes' as we currently have in prod.

Also, I feel pretty good about the quality of the blocks and biblehash chained verses.  The security descriptor, biblehash1 still guards the integrity of cold boots and external block files, while both biblehashes  together guard the solution itself (AcceptBlock), while x11 stores the pindex map hash key.  Its not a bad solution, and the bar is pretty high now to try to replicate this in either GPU or ASIC, imo.  I think this might be fairly complete for f7000 for this particular mandatory.  Im thinking once we have a slack group, we can brainstorm yet an even tougher rule to keep BBP at the top: something where the masternodes inject random keypairs, and keep breaking the ability to farm this to asic.  Something like that might work, OR, if the masternodes provide a mining key every 60 seconds to the device, and we ensure the private key executes in-wallet code that can only be known by the wallet Live in the miner to mine that block, or something, we can deal with all that once we have a real IT department.

Anyway I wanted to ask you, and the high stakeholders, please be honest and open, is there anything that makes you nervous about f7000, or something that I need to triple check while tweaking the final pool settings?  Im going to adjust networkhashps, and subsidy tail as its a little off with this latest double biblehash, just to be consistent with our promises from go live, etc, but thats all I have in this next version.  (Along with the pool reliability feature for readytomine).

Im looking into adding a feature to allow us to name our sanctuary.  Maybe people will name some of the 12 tribes of Israel.  Instant Payment sent through Judah.  LOL.

Regarding Westworths independent audit, Im for it, but I think it will be fruitless to pass one and be an ongoing org for a year with no frequent audits.  I was thinking, in our accountability domain, we could post the phone # and orgID of BiblePay and let people make random calls and verify the orphan is sponsored by us.  Then it will be a perpetual audit, forever.  On that note, I applied for a bible_pay org ID from compassion.  Its required for an org to write to children.  And it makes our children sponsored under the name of the Org.  Making it auditable.  But what happened was I applied for it one day before I sponsored 74 children, and they explained it takes up to 30 days to receive the number.  In the mail.  So, I currently sponsored these 74 under my name temporarily.  However, I did verify with them that I will be able to transfer these children to our org as soon as I receive the orgid.  So Ive been waiting for that to happen, and of course that precedes the ability to audit the org also.  Ill be updating the web site once that is done and people can have freedom to audit as they wish.

Regarding pulling in the VP of Finance and IT people at compassion, I love the idea of having them run the wallet and asking if they can accept our payments and auto-apply them.  The only issue I have with this is I feel its highly positive PR for us to have sponsored individual orphan IDs, of high quantity, with auditability by anyone.  What I am saying is if we have to transfer a monthly flat 'dump' of coins, and all we get is a Thank you, and lose all the orphan IDs in exchange for a blanket contribution, Id rather then do it the hard way.  What I would push for is the ability for someone at compassion to apply payments to our account using BBP for us once per month.  That would be the sweet outcome.

Not really.  In 1023, we do an addl test to support the upcoming features, but its only a boolean, so I believe the hashps against prod should be the same.

I would increase the proclimit by a couple and just see if you realize the same hashps as before.

In the next version (Im calling it f7000, due out at block 7000), the hashps will be about 90% less, but it will be doing 2 biblehash rounds and only one x11, with txindex lookup in one biblehash (we are raising the bar and removing the x11 weight). 

Happy_merchant,
Do you think you can run your tool again on this round of testing for the blockspacing report?  That is if you synced in testnet.  I have on other testnet peer, thats probably you lol?

So far regarding the f7000 feature, everything seems OK.  We still need to adjust networkhashps.  But Ive rebooted and scanned the chain, and it appears the deterministic tx lookup is working (where it picks one of 3 types) and adds this piece of info to the tail end of the bible hash chained verses, and does not cause corruption, and allows itself to be rebuilt etc.

Heads up for pool users:  Once we are close to wrapping up the testnet testing for f7000, we will have a mandatory with a pool feature at the same time.  One of the major inefficiencies can be solved by enhancing the readytomine packet in the miner.

Its probably the space you have between http: and //.  Try removing the whitespaces. Also just make workerid:
workerid=love

Then try again.  Its up for everyone else and no funny things in the logs last night.

Like Westwarmoth said it was a bad day for the pool, but its been partially upgraded to handle the load now.  Please hit it now.  We will look into either adding a second or increasing the server power next week.

-> Regarding the password manager: We cant support debugging the pool with that on.  I went as far as renaming the password field behind the scenes, to something unrelated to passwords, but thats as far as I can go with that.  However, what I did do is I debugged the issue in a browser without a password cache, and verified that we absolutely do not populate the password field with any text on the page load now - (text was being populated before into the control - but that was a bug).  Now when you go to the page, the pass is initially blank.  If you populate it, it saves the new pass.  So I consider this fixed now.

-> Firefoxs extremely convoluted view is fixed (I had no idea it was like that).

-> Regarding nav links, thats a microsoft thing- they are rendering a whole bunch of stuff down with the aspx page.

-> Other fields not populating on account- Yes, you found a bug there.  The page has been upgraded to use the simple framework now, and is cleaner, and now populates all the fields every time.

-> On UserText1, btw, that is just a storage field for the user (the pool doesnt use it).  What I meant was, if you navigate to Account, ensure the password field is empty, and only change usertext1, and save the record, then you can logoff and back on and know that it did not update the password but it does update usertext1.