Bible Pay

Recent Posts

Pages: 1 [2] 3 4 5 6 7 8 9 10
11
Production Proposals / Re: Aug 2019 - Block reward breakdown adjustment
« Last post by Rob Andrews on August 08, 2019, 08:11:07 pm »
With the new GSC system that came as an exciting novelty in Biblepay Evolution codebase, the block reward breakdown was substantially changed to

GSC 40%
PoBH 20%
Masternodes 20%

(remaining 20% consists of Charity/IT/PR monthly superblock)
 
I believe that this breakdown strongly discourages MN owners and gives incentive to dismantle MNs and bet for the bigger ROI of GSC.

While we all will benefit from the inflow of new users that GSC brings, at this moment GSC is reported to be 10-12 times more profitable than MNs.

Also, Masternodes operation has associated costs and burdens, and in the near future MNs will have a key role in maintaining the network integrity with LLMQ.

Because of this I would like to propose a more balanced reward breakdown of:

GSC 30%
PoBH 20%
Masternodes 30%


This still leaves GSC room to grow, without eroding too much the original promise of 40% reward for MN owners.

PoBH remains untouched as I believe it's critical for the integrity and the added value of Biblepay chain.

1)
According to our current reward schedule we actually give 20% to charity, 30% to GSC, and then we split the remaining 50% among POBH/Sanc (So Sanc should be receiving 25% right now, and POBH/Heat mining 25% right now).

https://wiki.biblepay.org/Economics

2) Although I agree that security is of the utmost importance, let us remember that since this change would require a mandatory, the very earliest it would be implemented is with or after ChainLocks goes into prod.  ChainLocks technically means we will be immune to 51% attacks (and forks), because each block will be monitored by the Sanc Quorum, giving us more freedom to implement "cool" things without compromising security.

In light of that, I think we might possibly be able to take 5% percent from POBH (simply because it's mostly wasted heat) with the requirement that ChainLocks be in place first.

And take the remaining 5% from the GSC.  This would change it to:

20% - Charity and Governance
25% - GSC
35% - Sanctuary budget
20% - POBH/Security

Do you agree with this, if so could you please edit the OP post for further clarity on what they would be voting on?

If not, please let us know that we should tweak again.

Thanks, this sounds pretty good overall, as what you said about "original plan" resonates with me.  Although I will add that we did vote in GSC's for the extensibilty and flexibility of biblepays future.

Also, we should post this link on bitcointalk and publicize this once its ready.

12
Production Proposals / Aug 2019 - Block reward breakdown adjustment
« Last post by MIP on August 04, 2019, 11:47:41 am »
With the new GSC system that came as an exciting novelty in Biblepay Evolution codebase, the block reward breakdown was substantially changed to

GSC 40%
PoBH 20%
Masternodes 20%

(remaining 20% consists of Charity/IT/PR monthly superblock)
 
I believe that this breakdown strongly discourages MN owners and gives incentive to dismantle MNs and bet for the bigger ROI of GSC.

While we all will benefit from the inflow of new users that GSC brings, at this moment GSC is reported to be 10-12 times more profitable than MNs.

Also, Masternodes operation has associated costs and burdens, and in the near future MNs will have a key role in maintaining the network integrity with LLMQ.

Because of this I would like to propose a more balanced reward breakdown of:

GSC 30%
PoBH 20%
Masternodes 30%


This still leaves GSC room to grow, without eroding too much the original promise of 40% reward for MN owners.

PoBH remains untouched as I believe it's critical for the integrity and the added value of Biblepay chain.

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

Oh good on the reason :), haha, OK.
Yes, I remember the two I had trouble with had the port in there also and yours does not.
It makes me think you could comment out yours, as it might not be used.

14
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.
15
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"
 }

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?

16
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"
 }
17
I just updated the OP with "low hassle sync from zero". 

I also got windows to sync with this method last night, so it will be trivial to make a prod snapshot soon.


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

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?


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

20
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

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


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