Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rob Andrews

Pages: 1 2 3 [4] 5 6 7 8 9 10 11 ... 127
I already put the 'masternodeblsprivkey' in the biblepay.conf when I set-up my Sanctuary. I'm don't remember it exactly, but I think there was something in the set-up notes about it (maybe in Togo's) and I think that my (legacy) Sanctuary didn't even want to start when I didn't have it in there?

Anyway, I'm om the right chain, my Sanctuary is in DIP3, so I'm ready to roll  8)

Dash's notes have the instructions to do it, but those notes are very complicated (to create a deterministic sanc from scratch).
Yes, the sanc throws a warning right now if the masternodeblsprivkey is missing, but it still starts. (Using the masternodeprivkey).

For cold masternode setup, we will need to:
1. Local/Controller Wallet:
replace the masternodeprivkey value in masternode.conf with masternodeblsprivkey?

do we need to also:
2. Remote/Masternode Wallet:
A. replace the masternodeprivkey value in biblepay.conf with masternodeblsprivkey?
B. or add new line masternodeblsprivkey=?

Since deterministic sancs only support cold sancs, you do not need to do #1 (otherwise the controller could only support one sanc which wouldnt be too nifty).

We need to add the masternodeblsprivkey to the Sanctuary side.
The masternodeprivkey is still needed until after the cutover, so we can leave those in there until reason comes to start fresh.

Since we all appear to be on the correct chain now, let's ask everyone to upgrade to deterministic sancs by tomorrow - and Ill flip to dip15 tomorrow.

Remember to add your blsprivkey to your sanc.

This way we can see as of tomorrow afternoon if things are going to work.

Btw, although we had a rug yank, I think Watchman worked correctly:
getrawtransaction f04a7c58940972fb4784033e926f07b90d9647a9d0ad9ee5904efff0e4ec5f92 1

If I remember right, the 1 mil proposal was either voted down or had the least votes.

I was able to set up a cold masternode successfully,
and was able to upgrade to a dip3 masternode successfully!

Masternode IP:
Thats great!

Hey everyone I want to mention something important.

Before we enable dip15 (deterministic masternodes), we need to copy our 'masternodeblsprivkey' to our cold sanctuary biblepay.conf file (just like we usually copy the masternodeprivkey over there).

This is not used until we flip dip15.  As I believe the moment we flip dip15 the sancs will rely on this privkey to sign all the messages (and thats likely why we had hundreds of failed votes yesterday once I flipped it for a couple mins). 

So either way its mandatory that we copy the key to the sanc before dip15, so lets make that part of the upgrade to deterministic process.

I also forgot to mention this is the main reason I added the deterministicsanctuary.conf file - so you can open it back up and get the value out of it (or write a script to copy the value to the sanc).

what about checkpoints? I saw in some wallets using checkpoints for easier sync or what.

A checkpoint will help the wallet get on the right chain after one particular block in history at a certain mandatory height that passed.

But what I wrote explains a things in a lot greater detail than a checkpoint.

We do use checkpoints in our wallet (we have about 10 in classic etc), I added one to testnet but I havent been adding them because they dont address the problem fully, but Ill add one during the next mandatory.

Setup another wallet, Upgraded both my wallets to v1.4.2.7

getblockhash 63152

I still have an old hot masternode (1 wallet), setting up cold masternode now (2 wallets)

I agree with you.  Ill stick it out for a while and keep the chain, lets see how we do.

(I'll still put these 3 new features in however, for the next mandatory).

I've been having a hard time resyncing every time we have a mandatory upgrade.  I know part of the problem is when we force a new protocol version, it knocks all the sancs offline.  (I have an old biblepay classic feature I am going to port that prevents that, allowing us to sync easier but still forces us to upgrade), so I will need to put this in today.

Two other things, I have realized one of the reasons we have trouble syncing when the diff is < .02 is because the wallet is having a hard time figuring out which fork is valid (in its diff calculator).  I believe we will need a couple consensus rules added.  For one, we should only add and enforce ABNs when the diff is > 1.0 in testnet (and a higher number in prod).  I think this would help us immensely (coming to consensus).  The other is the same with anti-gpu.  We shouldnt really be monitoring or enforcing that if the diff < 1.0.

54 Upgrade for TestNet

- Prevent memory pool tithe attacks

Our amateur hacker is back online - it seems to be the same person who likes to send 666 to SX.  Probably Slovakia or Noko.

Anyway I have a mandatory upgrade coming in 30 mins, please shut off the miners.

They are going to lose this cat & mouse game- I've been through this before, but this time I'm working for God.

As founder I am keeping a very serious eye on any potential forks, as one of the goals of Evo is to eliminate forks with extra prevention layers.

So far we have had a reason for every fork: a mandatory upgrade with half of the sancs running on the old version forced on the network.

I just want to make everyone aware that something we did today should have caused a fork:  Enabling dip15 erases all of the old sancs votes (meaning the daily gsc superblock could fail and I see in the logs the one after that height did fail), then we picked back up later but I see a lot of ddos going on.

We will have to remember, when we are about to go live, we should plan on upgrading all of the sancs in Evo before the cutover height to GSC, have the spork enabled, then start GSC in deterministic mode to prevent this risk in prod.

I forgot to mention, we have to wait until everyone upgrades their legacy sancs first, then we flip dip15 to on, then we can check to see if the deterministic rewards start coming into the new address.

Cool! Seems to have worked for me. My sanc is now in the dip3 tab :)

Thats awesome man!  So to elaborate a little more:
1) Dash allows a sanctuary owner to specify where future rewards go (IE they allow you to tell the wallet a specific address to receive sanc rewards).  This is useful if you are trying to make an untraceable wallet.
2) Dash allows any designated public key to be a voting delegate.  This means a friend can vote on a sanc poll for you if you provide their pubkey.

To make this easy to start, the upgradesanc command fills those two things in for you.

To find out how we filled them in, go to receiving addresses, look for:
Yoursancname-D and Yoursancname-V.

The D is the address biblepay set up for your rewards.
The V is the address we created for your voting.

The vote-many and vote-alias automatically finds your V address to vote from (no changes are necessary there).

The rewards will start coming in to the D address (theoretically), lets check that.


Guys, go ahead and try this.
1.  You must have a *cold* sanc (that means your sanctuary doesn't have the locked funds in it and you have a controller wallet with the funds locked, and the old sanctuary works (IE its probably ENABLED right now), and your controller wallet has a masternode.conf file.

2.  From your controller wallet, go to the RPC terminal and type:
Code: [Select]
exec upgradesanc sanctuary_name 0(where 0 means dry run, and sanctuary_name is the name of the sanctuary (the first field) in the masternode.conf file).

3.  Check the output of that command and make sure there are no errors.  If so continue to the next step.

4.  From the controller wallet, RPC terminal type:
Code: [Select]
exec upgradesanc sanctuary_name 1Ensure this command does not throw an error.

If the results are successful, you will be in the dip3 sanctuary tab (from the Sanctuaries page | Dip3 sancs).

Note that we create a deterministicsanctuary.conf file for your convenience (this is a biblepay feature).  We automatically add all your dip3 sancs to that file.
This will be useful if you have more than say 10, then you can write a script to pull values from this file and do things like update remote configs, run remote commands etc.  Its also highly useful if you need to access your BLSprivkey or BLSpubkey, or voting information.

Hey Rob, what are the steps to upgrade to a deterministic masternode?

From some digging, looks like you added a command in v1.4.1.7:
Code: [Select]
exec upgradesanc sancname

Yeah, I just upgraded one of my sancs and it worked.

Lets go ahead and upgrade some, one sec.

Pages: 1 2 3 [4] 5 6 7 8 9 10 11 ... 127