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 - oncoapop

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12
91
Update to non standard port not working

The sanc appears enabled on the list but is unable to connect to the non standard port.

 >sanc status
Code: [Select]
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "104.167.116.179:8080",
  "proTxHash": "71ac8f0a0b11a7070b4aa2e1862c19a8c5d5106bc5172502ebe8ce87772afc5d",
  "collateralHash": "24ba631e105c9f1d1923fe32d9c534e51556cddb15f625a5c42d5c902c868583",
  "collateralIndex": 1,
  "dmnState": {
    "service": "104.167.116.179:8080",
    "registeredHeight": 6092,
    "lastPaidHeight": 6097,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "yQkfqAeFpZzwHmpXti7avavNAu6etwCjAn",
    "votingAddress": "yQkfqAeFpZzwHmpXti7avavNAu6etwCjAn",
    "payoutAddress": "yTwJA2VCYQWpWXH8HS7UvEpqRE3Aj5ciUV",
    "pubKeyOperator": "139234c6a2d2f2f449fe5b25006fef684a5be440372756d903f1c793da49812202933c13a8d750ebeb270ea96b62480d"
  },
  "state": "ERROR",
  "status": "Error. Could not connect to 104.167.116.179:8080"
}

>sudo ufw status
Code: [Select]
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT       Anywhere                 
8080/tcp                   ALLOW       Anywhere                 
40000/tcp                  ALLOW       Anywhere                 
9998/tcp                   ALLOW       Anywhere                 
19998/tcp                  ALLOW       Anywhere                 
40001/tcp                  ALLOW       Anywhere                 
22/tcp (v6)                LIMIT       Anywhere (v6)             
8080/tcp (v6)              ALLOW       Anywhere (v6)             
40000/tcp (v6)             ALLOW       Anywhere (v6)             
9998/tcp (v6)              ALLOW       Anywhere (v6)             
19998/tcp (v6)             ALLOW       Anywhere (v6)             
40001/tcp (v6)             ALLOW       Anywhere (v6) 

92
Well, I think it was the reboot that did it.  After poring through the code yesterday on that non default port stuff, the code uses the testnet default port if its missing the port #.

But more specifically in our case, I think what happens is we set up a sanctuary, we run it, and if the pro-tx is sent after the sanc boots, (I think) the sanc actually starts up and goes to enabled, but -- I could be wrong about this -- but I think the activeMasternodeInfo (this is the struct that displays its status) isnt actually updated until you reboot.

My big question on that will actually need an answer soon for apollon, because they want us to provision a deterministic sanctuary without asking them to reboot the node :).  So we will have to figure this out for sure soon.

Hmm am i on a different chain? I seem to have lost the tBBP you sent....

I had to stop the controller wallet to lock the outputs and when i restarted ( several times), the balanced was not updated.

93
I can see both of your sancs as enabled (however in the phase we are in, we arent in LLMQs yet, so they wont be pose banned anyway until after block 8400). Anyway when I right click on those I can see the Pro-tx.  Did your status ever update in the sancs themselves to Enabled?

I just created 3 sancs.  In my case, one of the three already went to enabled (in the masternode status in the sanc) with all of its info.  In the other 2, I also see waiting for pro-tx to appear on chain.  So Im going to leave mine like this and see if that changes later.

In my case, I used our upgradesanc command.  Heres how I created a deterministic using the legacy with upgrade method:
- Send 4,500,001 to myself using QT wallet
- Type masternode outputs - copy the TXID and ordinal
- Edit the controllers testnet3/masternode.conf file
- Past IP:Port MNP txid ordinal (in the file)
- Type 'upgradesanc sancname 0' .  Verify this will work.
- Type 'upgradesanc sancname 1'.  Copy the masternode bls priv key to the Sanc "biblepay.conf" file.  Also ensure the sanc has masternode=1 in it.
- Reboot the sanc so it uses the bls priv key.

On another note, Im testing an upcoming feature that will let Apollon host deterministic sancs, and let Apollon (or biblepay users) host sancs on nonstandard ports.
I wanted to see - do we need any code changes in testnet (or in the upgradesanc command) to support nonstandard ports.

So I did this:  In the sanctuary itself, in the biblepay.conf, add "port=nnnn" where nnnn is your non standard port #.  In my case I used 39998 (as you can see from the sanctuary list now).
Then in the masternode.conf file, I changed 40001 to 39998 (in my controller wallet).
I see our upgradesanc command did honor that without any changes, and - because we have recently merged in a change that allows nonstandard ports for pro-tx the tx was broadcast.

I was able to successfully create two more sancs on non standard ports.

So now you all should be able to see in the masternode list:  ports 40001, 39998, 39999.  Lets see if these nodes survive.

Thank you for the advice.

All mine were still waiting for ProTx but when i added the port to the IP and restarted it immediately went to ready, so the port ( even if default 40001) is needed in the conf.

I’ll try a non standard port later tonight.

94
Thats awesome you are firing up 5!  Thanks!  Yeah, Im firing up 3 sancs + 1 controller, so we should have most of the bases covered this time.

I sent something like 12 mil-13 mil I believe to you.

EDIT:

I forgot an important note for everyone; Oncoa can you please do this also;
please delete your SAN/prayers*.* files and restart (just delete the whole directory SAN if you want), and then you will see that ABN isn't required.

This is because in testnet, our sporks are cached (until they get replaced with a new value).  Since we restarted the chain, the wallet thinks its still in ABN required mode.

(ABN is currently not required in testnet).

EDIT 2:

Yes, our hashes match, great job!

Thank you for the tBBP - I have set up 2 DIP3 sancs.

104.167.118.24:40001
45.62.239.200:40001

Although they both appear to be enabled on the masternode list (and both receiving block rewards on consecutive blocks 5802,3), masternode status on both say
"state": "WAITING_FOR_PROTX",
"status": "Waiting for ProTx to appear on-chain"

I struggled for quite a while in the set up as unlike previously, this time the VoteAdd must be the same as the OwnAdd.  As can be seen from my post (on Jul 31, 2019, for example, my last sancs had different addresses for both, as I set them up from scratch using the dash method.

Thank you also for the tip about the deletion of the SAN directory, the VPS are now mining without ABN.

95
Starting testnet from scratch

cli getblockhash 5682
42358d51bdb4eba605c37d78c623b68febb3126f2bcaf77c9e5db92429ea603a

New address:
ye4XGGwV9wWupZMV1Fqaxi3KLoHmxKB27G

I cannot mine and accumulate tBBP due to ABN. Can you please send enough for setting up of Sancs if that’s required. Thank you.

I have 5 VPS synced and ready.

http://oncoapop.sdf.org/biblepaytest/testnet_chainstate.shtml


96
Starting testnet from scratch

cli getblockhash 5682
42358d51bdb4eba605c37d78c623b68febb3126f2bcaf77c9e5db92429ea603a

New address:
ye4XGGwV9wWupZMV1Fqaxi3KLoHmxKB27G

I cannot mine and accumulate tBBP due to ABN. Can you please send enough for setting up of Sancs if that’s required. Thank you.


97
Dear Rob,

Based on published data Ref: http://wiki.biblepay.org/Emission_Schedule
And the approx current output, I have calculated the approx BBP allocation based on current QT, can you please confirm? Thank you.

Planned emission   

                %                BBP
Total monthly    51,914,467.00
Per day                  1,730,482.23
Curr QT    0.6        1,038,289.34

Sanc          0.25         259,572.34
PoBHv2    0.25         259,572.34
SB(?)         0.10         103,828.93
GSC           0.40          415,315.74

GSC breakdown:
POG            0.475     197,274.97
POOM        0.475     197,274.97
HEALING    0.050      20,765.79

98
Thanks guys!

Yeah, one of my 3 was pose banned too.  I have been deliberately waiting to see if it revives by itself.

As the Dash-Evo code hints at an automatic revival process; but - when I read about people who were POSE banned, they generally recreate their nodes.  But that doesnt make too much sense to me, because there is a strict control on not being able to re-use the same IP.

I have one well known working method to undo a POSE ban - but its like using a cannon - you can spend the output and recreate the sanc using upgradesanc - and that is allowed - because the network sees it as spent and undoes the lock on it first - and allows recreation.

Before I recreate my third sanc, let me do some more expirimentation.

Thank you. Initially, the testnet sancs were enabled even when the entire VPS was off for extended periods of time; now when they temporarily drop connection, all of the sancs appear to be banned and none appear to gave recovered without intervention.

 sanc count
{
  "total": 6,
  "enabled": 0
}

Am I on the same chain as you, as all the sancs on this testnet chain appear banned?

99
I believe Im the only 2 sancs left; MIP & Oncoapop are you guys still participating?

Jaap said he would, but we havent heard back from him after that.  I havent seen Togo here either despite coming back on the payroll.

I have the following machines on testnet but all my sancs have been pose banned so i need to reactivate them but this back-to-school week is a bit busy for me.

http://oncoapop.sdf.org/biblepaytest/testnet_chainstate.shtml

100
Thats awesome.  I see .181 in my sanc list now also, with 0 POSE.
Just a guess, but maybe it was your masternodeblsprivkey on the old one, not matching?  In both of my cases it was using externalip=.  I found after I recreated without that, they stay up. 

Yes, good to know you were able to use the Dash method.  The pro for the dash method is you have more control over the operator and voting keys (which, we can expose in the future in our upgradesanc command, for more versatility).  The con is you have to remember to save those private keys in a file by yourself.  (In the case of a person who has a lot of sancs, the deterministic.conf might be convenient.  In my case, the deterministic was more useful for me to write a monitoring program to manage the sancs later - I need to loop through them and control them, etc.)

Great, we have 5 sancs now enabled!  We can start testing chainlocks pretty soon.
MIP, is yours up?

Have I forgotten to answer any questions about .14 other than making a test-list?

Btw, how did you lose your testnet controller wallet, was it a rabid animal, or a mad family member?

Hmm, my sanc has the external IP in the biblepay.conf:

Code: [Select]
addnode=testnet.biblepay.org
addnode=dns1.biblepay.org
addnode=dns2.biblepay.org
addnode=dns3.biblepay.org

rpcuser=XXX
rpcpassword=XXX
rpcallowip=127.0.0.1
rpcport=9998
daemon=1
listen=1
server=1
daemon=1
externalip=104.167.113.181
maxconnections=256
masternode=1
masternodeblsprivkey=XXXX

Not that exciting, I’m afraid. I thought each time in testnet we start from scratch so I didn’t pay much attention to the wallets. Anyway, I managed to resurrect the 239.200 as the VPS was still around.

101
Oh ok, yeah you can't spend the collateral then, so you cant free that node the easy way, right.

Well, anyway, the other way to do it is if you have the deterministic.conf file (this has the bls private and public key in it and the original pro-tx-txid), you could send a  ProUpServTx, (because sending a new pro-register-tx with the same IP results in bad-protx-dup-key error), but you could only do this if you had all the pieces saved from deterministic.conf (proTxHash, blsPrivKey) - see this section for future reference :  https://docs.dash.org/en/stable/masternodes/maintenance.html#updating-masternode-information


Well anyway I hope you have a Vultr Snapshot then you can rebuild without all that work.  Good luck.


PS: Can you please try the quick sync from zero when you rebuild so we can test that?

Set it up using the binaries from MIP and the quick sync script and it was fast and effortless! Used the Dash method from scratch (bit more complicated) and here it is...
 
Code: [Select]
"33ff087061fad94af7e4f1f73ff56af47f9b34e802cd845f5cf765b13944d453-1": {
   "proTxHash": "520ebc4e8fb36d335e89d3527c88e0096bb605983efbd339f78d17be12ce453e",
   "address": "104.167.113.181:40001",
   "payee": "yXhRHuA2YsV44K5VZJyQSxZurQ8s7diKbq",
   "status": "ENABLED",
   "posescore": 100,
   "posescoretries": 0,
   "posescoresuccesscount": 0,
   "lastpaidtime": 1564615177,
   "lastpaidblock": 182751,
   "owneraddress": "ygXsP7NRxDJtKKqRc2i1JXvxKZmXysYf76",
   "votingaddress": "ya5TqeZC7GRbibSzT8jbfHCLEQNTKT6LDL",
   "collateraladdress": "ydbZ7ppEEbq28Awyt2iQXTnM3JSn5fxKHF",
   "pubkeyoperator": "90856729abbe57866ec136e1505b59bf2fb5c399e04581df8264ba0ce49709cccd8c3e74c45ea1815e71572d602110c0"
 }

102
Hi Oncoa,

Nice hashes, so it looks like we are in agreement on that block hash (for your 3) plus mine.

As far as getting pose banned, you can get banned if:  Your masternodeblsprivkey does not match your deterministic.conf private key, or if you transmitted the same IP on more than one pro-tx, or if you are using the 'externalip=' setting in your wallet, or if your node is out of sync and acting strange in the quorums.  You would have to defer to the dash docs I pasted above for the rest of the reasons (as I am not familiar with the others yet).

If your not sure after reading this, I have found it is very easy to do this to recover:

Spent your collateral Tx in the controller wallet
Create a new public key for a new sanc
Create a new legacy sanc using the new address
Perform the upgradesanc command on it

I did that and Im chugging fine.

You can use the same address as long as you spend the old sanc funds first.  (Unlock them to spend them, spend them, then spend a new amount for the new sanc).

This would only happen in testnet but i lost / destroyed my controller wallet with my VPS and hence the collateral is locked and hence I cannot recreate the sancs using the same IP as you mentioned without spending the collateral which is not possible without the wallet!

I’ll have to destroy the VPS and recreate it with new A fresh IP and start from scratch. This might take awhile... sorry.


103
So can we get a little update from everyone on testnet, do you all agree:


getblockhash 180650
28383ec96296dbee95f45a0240cae97ef8ef06ff8fd3fe4e90552eb2cbe72d6e

Id like to see all 5 of our sancs in agreement before we talk about testing chainlocks.
I see my 3 non-pose banned sancs are in agreement.

MIP, Oncoapop we could use feedback - and anyone else that wants to test chainlocks.
Dear Rob,

I just have three VPS running in TESTNET. I did have one sanc but it is now banned, I have no idea how to get it unbanned. I restarted it to no avail. How does one get banned, other than not running bbp daemon?

Code: [Select]
{
 "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
 "service": "45.62.239.200:40001",
 "state": "POSE_BANNED",
 "status": "Masternode was PoSe banned"
}

The VPS is up and running and port appears to be open
Code: [Select]
telnet 45.62.239.200 40001
Trying 45.62.239.200...
Connected to sanc2.myseqtools.com<http://sanc2.myseqtools.com>.

mnsync status
{
 "AssetID": 999,
 "AssetName": "MASTERNODE_SYNC_FINISHED",
 "AssetStartTime": 1564531134,
 "Attempt": 0,
 "IsBlockchainSynced": true,
 "IsSynced": true,
 "IsFailed": false
}

If you want to check my machines, you can see the automatically polled hashes of my three machines at any time on:
http://oncoapop.sdf.org/biblepaytest/testnet_chainstate.shtml

They are pretty puny VPS  so one or more may be offline syncing or updating…

Cheers,
Oncoapop



104
Dear Rob,

Given your stressing the importance in testnet of the sancs testing of LLMQ (kindly remind me what this is again?), I have (surprisingly) resurrected one of my initial DIP3 sancs (just using old biblepay.conf and masternode.conf files left on the server WITHOUT the controlling wallet which I may have destroyed....), so I am hoping that it will be okay.

Let's test this to ensure, as far as we are able with a fraction of the network in testnet, we roll out a stable product in mainnet. Could you kindly help us to assist you in this by providing a checklist  (in simple layman's terms, please. Thanks  :) )  so that we can test specific aspects and report on.

Blessings,
oncoapop


Code: [Select]
{
  "outpoint": "51a7d0cdb93fb3377d274f1b448af3c260618eb23c145a52c6c2fc081192b4dc-1",
  "service": "45.62.239.200:40001",
  "proTxHash": "3fdfa35533185427856e07d7a966714d118c7434994b5d6a349c11558e79e290",
  "collateralHash": "51a7d0cdb93fb3377d274f1b448af3c260618eb23c145a52c6c2fc081192b4dc",
  "collateralIndex": 1,
  "dmnState": {
    "service": "45.62.239.200:40001",
    "registeredHeight": 65387,
    "lastPaidHeight": 171297,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "yhDJCUZq19CVLiuDa4wEoY4PxWg17bZuTx",
    "votingAddress": "yhDJCUZq19CVLiuDa4wEoY4PxWg17bZuTx",
    "payoutAddress": "yRKdex8fFcDyjqx618Cz4hsQcQFjp55jRg",
    "pubKeyOperator": "05f58c1b79e898cf31a0375ded7a8e5bb6b0e5aacb48dc79f7c87e38eb0533bdf85c610cee5cf94b79c425c20f423cc4"
  },
  "state": "READY",
  "status": "Ready"
}

Again I notice that all the sancs appear to be "valid" although I know that only one of my sancs (45.62.239.200) is online and the other (64.180.194.238) is  not (see below). Would this affect the quorum if we have zombie sancs?

Code: [Select]
telnet 45.62.239.200 40001
Trying 45.62.239.200...
Connected to 45.62.239.200.

telnet 64.180.194.238 40001
Trying 64.180.194.238...
telnet: Unable to connect to remote host: Connection refused

105
As a side tip for anyone who is upgrading, remember you can do the 'exec reassesschains' if you end up at a lower height than us (it worked for me) due to LLMQ errors.

In the latest version I increased the LLMQ start height to 170,000.

Starting up LLMQ is much trickier (and dangerous) than I expected.

Since LLMQ drives chainlocks, the wallet is going to throw a bad block error, mark the block as dirty and put the wallet in a non recoverable state if it finds any block greater than 170,000 that is not in a quorum.

What this means is either the network has a lot of sancs, and a healthy quorum environment, or absolutely fails with a nightmare scenario.

This is obviously a decision Dash made to ensure there are no exceptions to the quorums once they are up and running. 

So in the current state of testnet, we would need to try to bring one more sanc on before 170,000 and see if a quorum forms, otherwise we need to keep increasing the LLMQ height.

What frightens me is if we start the quorums and then take down 70% of the nodes.  I think that means, we will need to regroup and bring the sancs back online. 

But from what I see, if lets say we lose those sancs VMs, and recreate them all, then the sigs will be new and the old quorums will be invalid (and I think that means a chain rollback).  We will cross that bridge when we come to it as our prod environment should be OK, as its always going to have for the most part more than 100 reliable sancs, so theoretically the quorums will never fail.

Dear Rob,

Given your stressing the importance in testnet of the sancs testing of LLMQ (kindly remind me what this is again?), I have (surprisingly) resurrected one of my initial DIP3 sancs (just using old biblepay.conf and masternode.conf files left on the server WITHOUT the controlling wallet which I may have destroyed....), so I am hoping that it will be okay.

Let's test this to ensure, as far as we are able with a fraction of the network in testnet, we roll out a stable product in mainnet. Could you kindly help us to assist you in this by providing a checklist  (in simple layman's terms, please. Thanks  :) )  so that we can test specific aspects and report on.

Blessings,
oncoapop


Code: [Select]
{
  "outpoint": "51a7d0cdb93fb3377d274f1b448af3c260618eb23c145a52c6c2fc081192b4dc-1",
  "service": "45.62.239.200:40001",
  "proTxHash": "3fdfa35533185427856e07d7a966714d118c7434994b5d6a349c11558e79e290",
  "collateralHash": "51a7d0cdb93fb3377d274f1b448af3c260618eb23c145a52c6c2fc081192b4dc",
  "collateralIndex": 1,
  "dmnState": {
    "service": "45.62.239.200:40001",
    "registeredHeight": 65387,
    "lastPaidHeight": 171297,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "yhDJCUZq19CVLiuDa4wEoY4PxWg17bZuTx",
    "votingAddress": "yhDJCUZq19CVLiuDa4wEoY4PxWg17bZuTx",
    "payoutAddress": "yRKdex8fFcDyjqx618Cz4hsQcQFjp55jRg",
    "pubKeyOperator": "05f58c1b79e898cf31a0375ded7a8e5bb6b0e5aacb48dc79f7c87e38eb0533bdf85c610cee5cf94b79c425c20f423cc4"
  },
  "state": "READY",
  "status": "Ready"
}


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