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 ... 137
1
Pre-Proposal Discussion / Re: Exchange Listing - p2pb2b.io
« on: October 04, 2019, 08:16:30 am »
It looks like they offered us a quote for 4 btc.

But how would we pay that fee?

I think looking at the budget, we have a deficit of about $2000 per month for the next year (as this month we had to skip the compassion payment), not enough for payroll (I have to start taking a 50% pay cut now), and also BBP owes me almost 1.9 btc for tokok still.

So I think we have a budget of more like .25 btc for a new exchange until we pay off the tokok deficit; and be candid I think the .25 would have to spread out over at least 6 months (.25 is too much for us to handle in one month even in our current condition).  In reality unless we get a really killer deal, I dont think we can afford another exchange, or any new payments unfortunately. 





2
Production Proposals / Re: Lower ABN Requirement?
« on: October 02, 2019, 08:50:54 pm »
Rob,

So if we lower the ABN requirement, do you have any concerns that could lead to more forking? I know that was one of the concerns when you first implemented this functionality. Also would a lower ABN then lead to higher difficulties on blocks? Thoughts?

Well I have pretty great news in that dept!

The great news is we found the cause of the fork (luckily because of a few smoking guns between different broken down sancs over the 3 or so we experienced).
I had a network of sancs for a while (before apollon) and I was able to run a report - similar to the sanctuary health report we have now.
Basically, our code (prior to 1447) had a gobject propagation issue - primarily because 40% of the network did not upgrade during the *last* mandatory (the one 75 days ago).

Anyway - I believe *all forking* was a result of bad GSC vote propagation.

Heres the scenario:
When the contract came up, 40% of the network who didnt have the votes didnt honor the superblock.

Another words, our ABNs work fine at any level.

The other evidence I have, is testnet is rock solid now - and it has a diff below 1.
So not only are ABNs ok at any level, but Diff is OK at any level.

On another side note, once we implement chainlocks we also wont have to worry about 51% attacks either.


So basically it should not matter.


3
Production Proposals / Lower ABN Requirement?
« on: October 02, 2019, 05:13:58 pm »
Shall we change the ABN requirements, Saints?

To be more friendly to new users?


4
Hi Everyone,

So with DSQL/Christian Spaces coming out, we have a lot related to the Develop QT wallet we can test in the DSQL thread.

Im going to keep both threads open, but I invite you all to join me here for a while:
https://bitcointalk.org/index.php?topic=5188626.0

Because we will be having a new testnet develop release tonight with some new features and you all can help test those in the bitcointalk thread.

Thanks!


5
Thats great!  I'll be back after we release this mandatory in mainnet.

Things look pretty solid in testnet so far.


6
Thank you. It was not working with ip:port but adding port=8080 as an extra line in the config works. Now shows ready.

Syncing was not the issue. I accidentally deleted the entire .biblepayevolution folder but I learnt my lesson from before and restored from a backup wallet.dat. So all 3 sancs synced and ready.

Thats great!  I'll be back after we release this mandatory in mainnet.


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

1) It appears your remote sanc node is not listening on 8080 (I tried to telnet to it).
Try to add "port=8080" to your sanctuary config file and restart it.

2) Were you able to resolve not being synced yesterday, was it a non issue?


8

Will instructions differ for someone who creates a sanctuary after having bought 4.55M from an exchange and want to self-host?


The upgradesanc only applies if a 4.55M sanctuary already exists but upgrading to a newer version?


I want to write a sanctuary set up guide but it is not clear what the sanctuary creation options are.


Well, its not that the instructions change based on receiving the funds, its more of which route you want to go when you create the deterministic sanc:

Route A)  If you follow the Dash instructions, they are a full page and pretty complicated. 

Route B)  We ask you to create the sanctuary the legacy way, and that allows you to implement the first phase of the deterministic sanc.  Then we ask you to run the upgradesanc command to finish it. 

One other thing to consider is Apollon is actually adding a new twist to this - they are having us add a couple RPC commands for them - one that will allow them to generate the bls privkey first and give it to the user- so there is a great chance we can make a special command that is different than upgradesanc soon, once I hear back from them.

So best bet is to wait for this info.


9
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.

Im still in sync on all my nodes:


15:20:49

getblockhash 5888


15:20:49

e66d1015bc4847c20fae2e73d9bd6d9655d0ceca85e0c0e9b0cc5bda9267b735



10
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.

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.


11
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.

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.













12
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.

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!


13
BiblePay - TestNet
1.4.6.3-Mandatory upgrade for TestNet

- Add checkpoint @ 5000 to enforce new testnet chain
- Make enforcement of sanctuary port # configurable.  Set sanctuary port enforcement to OFF (false).  This allows us to test creation of new sancs on non-standard ports in both Mainnet & Testnet.
- Implement Sanctuary Raise (from 25% to 35%) and GSC budget reduction to 25% from 30% (https://forum.biblepay.org/index.php?topic=435.0) @ block 8400 in testnet & TBD in MainNet
- Merge Prod changes into Develop up to 1.4.4.7
- Switch TestNet to 7 minute blocks (1 min blocks up to block 5000 to get us started quickly)
- Change chainparams to enable deterministic DIPS at block 5000, QT at 5000, ABN at 5000, however DIP3 enforcement is set at block 8400 (this gives us 3400 blocks to set up deterministic sancs after block 5000); we must have 3 sanc LLMQ quorums after 8400
- Added Chinese bible reader to QT
- Added exec masterclock RPC command
- Added masternode genkey legacy command for Apollon - to help support deterministic sancs in this branch


We are on block 5500~ or so.



14
Production Proposals / September Payroll (May 2019)
« on: September 21, 2019, 10:16:11 am »
Commits on May 31, 2019
OneClickSanctuary EVO instructions

 
 
masternode setup script for Evo

 
1.4.3.1d-Leisure Upgrade …

@biblepay
biblepay committed on May 31
 
Commits on May 27, 2019
1.4.3.1c-Leisure Upgrade …

@biblepay
biblepay committed on May 27
 
1.4.3.1b-Leisure Upgrade …

@biblepay
biblepay committed on May 27
 
1.4.3.1b-Leisure Upgrade …

@biblepay
biblepay committed on May 27
 
Commits on May 20, 2019
1.4.3.1 - Evo RC6 - fix for MacOS compile …

 
Commits on May 19, 2019
1.4.3.1 - Evo RC6 …

@biblepay
biblepay committed on May 19
 
Commits on May 18, 2019
1.4.2.9-Evo RC5 …

@biblepay
biblepay committed on May 18
 
Commits on May 17, 2019
1.4.2.9-Evo RC4 …

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC3 …

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC2 …

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC1 …

@biblepay
biblepay committed on May 17
 Commits on May 7, 2019
1.4.2.8b-Leisure upgrade for TestNet …

@biblepay
biblepay committed on May 7
 
1.4.2.8-Mandatory upgrade for TestNet …

@biblepay
biblepay committed on May 7
 
Commits on May 4, 2019
1.4.2.7-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on May 4
 
Commits on May 3, 2019
1.4.2.6-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on May 3
 
1.4.2.5-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on May 3
 
Merge branch 'master' into develop …

MIP
MIP committed on May 3
 
Commits on May 2, 2019
1.4.2.4-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on May 2


Capping at 1.25 MM



15
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?

So I was working on reviving my testnet nodes, and I agree, they all look banned.  The only reason I see 2 non-banned, is the local GUI on one of my banned sancs still has the old list. 

Anyway, I would like to notify everyone of this command.  I believe this is the command we need to unban a deterministic sanc without recreating it:

protx update_service proTxHash newIP:new_port masternodeblsprivKey


You can actually get all this info from the banned sanc itself (you can type masternode status, and get the IP, port, and original proTx hash, and you can get the blsPrivKey from the biblepay.conf on the sanc).  On a side note, if you want to do this from the controller, you can get the IP, port, blsPrivKey, and ProTxHash from the deterministic.conf.  So either should work to unban the node.  This command is also the one we use to Update an IP address for a non-banned sanc.

So, looking at the state of affairs, the reason the rest of the sancs are banned is because we failed to make the LLMQs correctly (with no minimum quorums).  The chain was in sync on 2 of my 3, so I believe we "would have" stayed in sync if we didnt lose the supermajority of our sancs.

Since MIP shut his down, and Oncoas is down, and mine need revived, I think we should take this opportunity to reset the testnet chain.
Primarily because I dont like the "666" trash that some joker transmitted, and of course, because we have 200,000 empty testnet blocks (therefore its harder to manage when we are away).

I think it would be best for us to slow the chain down to prod length blocks, and reset it and have us re-create our sancs at this point.

So in light of this please wait until the next version - it will need to be a mandatory upgrade (for testnet).

Thanks everyone for what you have already done!



Pages: [1] 2 3 4 5 6 7 8 ... 137