The f8000 algo starts at block 21350.  So we should see a decrease overall at that point.

Wow, that is quite extensive!  Great job!   I see you are starting to cover proposals also.

If you dont upgrade your node will go off on its own fork after the cutover height.

BiblePay - v1.0.6.5 - Mandatory Upgrade


- F8000 (Proof-of-Bible-Hash) Starts at block #21350
- Sanctuaries go live at Block #21350
- Sanctuary payments go live at block #21551
- Superblocks start at block 30001
- Superblock are monthly
- Amazon integration (in wallet e-commerce) goes live at block 21350
- Proposals and Budgets go live at block 21551



Alright, 1.0.6.5 is out there for windows.  The release is ready for everyone to upgrade.

Now lets test our cold sanctuaries....

Two more small gotchas with deploying Prod Sanctuaries:

http://wiki.biblepay.org/Create_Sanctuary

This guide had the Testnet port #.  I just corrected it to be 40000 (prod).
Note: This comes into play when you create your masternode.conf file on your Cold controller wallet.  Ensure you have IP:40000 in there.

The other gotcha:
If you already installed watchman-on-the-wall and were part of testnet, please update your watchman.conf with the Prod configuration.
Test it by running the
venv/bin/python bin/watchman.py
command on that node to be sure no error is posted.

(You will actually receive an error until the cold Sanctuary is synced with an mnsync status 999).

On a side note: Once we deploy windows, dont try to start your cold Sanctuaries until each of them say:
mnsync status
= 999 - that will save you some trouble.

Since we are releasing so many changes at once, I am really wanting to slow down just a little and have us verify the Sanctuary Payment (to the first few lucky Sanctuaries), verify those are working, and then verify the superblock system appears to be "ready" and we are still syncing on Monday the 18th.  Then if we feel good about it, Ill let c-cex know.  They technically have up to 9 days to bring us back on after that, but its usually within a few days...

This way if something goes wrong while we are down, we can just fix it here and now.

(Rare luxury)...

Well if your debug.log is not being created that is a major roadblock you must fix that first or you would be flying blind when changing the config.  Your basically running a copy with a datadir somewhere else but making changes to a copy that never gets executed so try to find your debug.log first.

How about doing the find command for debug.log - its usually in (~/.biblepaycore), and once you find it, that is the place to modify your biblepay.conf file (if you will run as that user).

Then all these pool commands will work fine

Good luck.

Our blockchain size is only 17 Megs right now with 21000 blocks, with our small blockchain size and 7 minute blocks, we should technically sync fast and stay small for a long time ... Knock on wood....

Update:  You can only complete about 60% of the cold sanctuary deployment process with the current (old) windows release.  You can create your masternode.conf, send the escrow, add the private key and spin up your linux Sanctuary side, but you cannot actually start the sanctuary from the old windows version.

This is because the old version does not have the correct sanctuary collateral args compiled in.  So yes, for the start-many command etc, we will have to wait a couple more hours for the windows release to finish Firing up your Cold Sanctuaries....

If you are currently trying to set up a cold sanctuary, yet the windows release is not ready for 3 more hours:

* You can use the current windows version to set up your masternode (IE getaccountaddress, sendtoaddress, etc).

http://wiki.biblepay.org/Create_Sanctuary

The mandatory upgrade should be ready for windows in about 4 hours.  In the mean time could I get some linux nodes to upgrade?


Let's install a couple sanctuaries and ensure things are working....

Looks like we are in maintenance now.  Mandatory upgrade is on the way.  The block number is going to be approx 21350 with the goal being to test our masternode sync tomorrow night into Saturday morning, then receive masternode payments starting Sunday.  Once I know things are finalized then we can stay with this new version.

More info will be available soon.



 

C-CEX is our exchange... Once they take us down we can work on our mandatory upgrade.

You can run your own sanctuary even on home dynamic IP, as long as its on linux running watchman on the wall, however you have two big risks:
1) If you do go down, you will lose your sanctuary payment, and if you fall out of the payment queue it might take 24 hours to get back in.
2) If your dynamic IP changes, you will have to re-create your whole sanctuary!  The Escrow is tied to the static IP.  <- This is a real pain...

Im still waiting for c-cex to put us in maintenance, so we are in a holding pattern until they do this (regarding the timing of the mandatory upgrade).

Yeah, I see MUE.  It does simplify the whole idea.  It would be a lot simpler for the investors to only have to deal with the fractional share part of it.

Im kind of worried about all of the other related problems this particular service deals with however.  It requires me to hold cold wallet escrow somewhere outside of the pool, handle lease terminations, be responsible for outages, be responsible for fractional investments, be potentially viewed as a person who issues securities (IE what if someone views a fractional masternode as a share in an investment)?, and requires the software to be written and maintained.   (The big one for me is holding sanctuary related escrow in one concentrated place, its something I dont want to deal with).  The second biggest is if the maintenance of all of the moving parts of this system turn out to be as complicated as a PO/Project management system.

Im thinking this idea might take away from our core focus of adding gospel features in, and making the stratis proof of concept.

Sorry about that guys but I think Im going to have to deprioritize this one.  If you guys can come up with an IT solution among each other, you could have your own subdomain for this....

Here is the guide again btw:
http://wiki.biblepay.org/Create_Sanctuary

They are linux only, primarily because the proof-of-service software we use only runs on linux.

No windows solution is currently scheduled, unless our stratis Proof-of-concept is really well received.  If it is, Ill port watchman-on-the-wall to c# so that then you can run a Pose-enabled biblepay node in c#.

Static ip is required, thats primarily why we recommend web hosts for this.  If your node fails to vote when its asked to you lose your sanctuary payment.

Very low bandwidth is required, only 10% more than a normal node, Except since you are a full PoSE node you would be servicing inbound connections, however these are split among all the nodes.  Im running one with 1023 connections and its taking 40kbps so its pretty low.  You can see the network graph in the qt wallet btw (Tools | Network Traffic).

Now we are #1:

https://coinmarketcap.com/gainers-losers/

Recently Znffal came up with an idea for us to lease out franctional sanctuaries to those who cant afford a full sanctuary.
I was thinking of potential ways to make this happen and here is what I have so far:

The pool could offer two new services: Sanctuary technology leasing, and Fractional Sanctuary leases with Dividends.
For STL, you spin up a node on a provider like vultr and set it up per the information given by the pool, the pool provides the data on the config page.     Then you are paid weekly for the technology lease.

The second side of this, is the FSL.  (This is for the average end user who wants the investment..  So we have a one-to-many relationship from FSL->STL.  It might take 40 FSLs to fill up an STL).   In this case you sign up for a certain quantity of 1000's that you can afford, (that is BBP * 1000),
and you become a leaseholder on record assigned to an STL ID, and you send this fractional escrow to the address the pool provides on the page, and at that point, you start receiving dividend  payments based on your investment amount
automatically as long as the escrow remains in the investment.

The pool then combines all the BBP received for an STL into one transaction and creates an escrow vout for it and saves it (this is used to populate the page for the next STL).

So my first question is, what do you think is fair compensation for the STL?  They would pay $5-$10 a month to lease the vultr node, and they only have to set it up once, but then they do have to reboot it every time they see new start required.  So I was thinking maybe $30 for setup + $20 a month for the vultr lease renumeration + $10 a month for restarts = $60 a month.   We could then convert that to a percentage, maybe that is 30% of the average deal.  Once we know the percentage we could do something like this:  30/60/10: 30% to the STL, 60% to the FSL pool, and 10% to the pool....

Anyway, I think it would be a pretty cool hit-- also we could offer this as a way to "park" extra BBP for extra investments that happen to be laying around.

One thing I wanted to note:  The STL would be the one to vote for the sanctuary, so that would be part of their responsibility.

Yeah, I agree, besides we are doing so much for the orphans, maybe we should call the CEO of the top #1 exchange and tell him to repent and then list us for free!

Hello?
"Repent, for the Kingdom of Heaven is Nigh!"