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 ... 134 135 136 137 138 139 140 [141] 142 143 144 145 146 147 148 ... 263
2101
** TestNet Update **

Just to give everyone an update as to what is going on:
Of course our TestNet testing is vital and is not being deprioritized by any means.

We still want to shoot for roughly an end of October timeline to at least have our next codebase ready for deployment (in case something accelerates the need for the release, as its important to be safe and on the ball).

The reason for the recent lack of posts is I've been in 'programming hermit' mode working on some of the promised features for EOQ 3.  For example BIPFS (BiblePay IPFS).

I will be posting a wiki very soon explaining all of this.

The schedule is on-track for an on-time release, so I feel confident we can begin testing chainlocks very soon and get back to more testnet as well.

Some of the code in BIPFS requires some code changes in the core in testnet btw (leisure changes).

Note that Dash recently had to tweak .14 in Prod due to some hackers spamming prod transactions.  We will pull these things in ASAP and ensure we are up to date.


2102
Archived Proposals / FUBT Exchange
« on: August 15, 2019, 06:15:22 PM »
** Deal to List BiblePay with FUBT Exchange - Hong Kong **



I've been in contact with Mr. Yue and Nick Lee from FUBT for one year about potentially listing BiblePay.

A year ago the price quote was too high (IE over 5 bitcoins).

Over the last few months, Mr. Yue had quoted me 3 BTC to list, and I told him we would continue to evaluate their platform as our next exchange and continue to save up funds for our next exchange.

Over the last week, I started talking to Nick.  Nick explained that out of the 3 BTC fee, FUBT will spend a certain amount of money on promoting a new coin (IE they reach out to 50 media companies, and blast a summary of the coin, and promote it for a certain number of days in Asia).  Nick estimates the PR to be worth around $5000~ (or up to 1btc depending on its reception level).

Recently, our coin has been reviewed by FUBT's coin quality assessment group and they consider us to be an "A" grade coin (similar to SouthXChanges ranking system).  They again approached us and re-quoted us a listing for 6btc.  I explained it is out of the ballpark.

Recently, Nick explained to me he can only guarantee the 3 btc fee for a short period of time and we may lose our discount status if we don't try to make an offer soon.

I agreed to take a look at FUBT this month and attempt to create a deal that may possibly work with BiblePay.

FUBT does approx $500 mil per day total volume according to coinmarketcap and coingecko, (not the gecko normalized volume).  From looking at a comparison between Tokok, FUBT, Bittrex and SouthXChange, FUBT appears to be about 50* bigger than southxchange.  Nick explained to me they have 2 million registered traders at FUBT. 

https://www.coingecko.com/en/exchanges/fubt
https://coinmarketcap.com/exchanges/fubt/

Estimating the size of this investment, 3btc ($35,000), I estimate that we would see a potential increase of $5 - $10,000 per day in trading volume (based on similar coins to BiblePay) and this would potentially lead to a market cap increase in BiblePay, *potentially* paying off the investment within a short duration.  (Nick tends to think we would be received well in Asia and coins like us trade more than $20K per day, but this is speculative.)

I feel this move into Asia is something BiblePay currently needs, as we trade almost exclusively in the US.  I think the 2 mil additional accounts complement our needs to a high degree.

In light of this, if the sanctuaries agree, I am offering to help this listing along with the following offer:

If this proposal is voted in and the Security Check passes (this is an internal freshdesk ticket with FUBT senior management to verify the exchange proposal is signed and agreed upon by BiblePay and FUBT):
Rob sends FUBT 3 btc from his personal account (lending BBP 3 btc)
Rob enters a 12 part proposal to recoup .25btc per month until the 3 btc is paid back

FUBT Provides:

- Listing BTC/BBP trading Pair
- 1BTC worth of promotion (Media blitz with 50 media outlets, 1-2* depending on market appreciation)
- At least 4 mandatory upgrades per year with no fees (I verified this with Nick)
- The go live would be towards the end of September 2019 and media blitz around mid September

** If anyone has anything negative to report about FUBT please report it now **



Proposal Payment dispursement breakdown:

Payment 1 of 12:
BTC @ 10567 : .25BTC * 10567 / .000724 = 3,647,790 BBP

(Note, as each month occurs I will update the remaining payments until we hit 3 btc)



2103
Archived Proposals / Re: Aug 2019 - Block reward breakdown adjustment
« 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.


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


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


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



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



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



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



2110
** Low hassle Syncing from Zero **

As our blockchain gets bigger it will be useful for us to release utilities to allow one click syncing from zero.
This first version is only for testnet and linux.  Later, I will extend this to windows and prod.

Is anyone interested in testing?  I just tested this from my ubuntu remote box and I was able to sync in a couple minutes.

I will check this into github later, but for now, let me give manual instructions to use the script:

From your linux box:

cd ~/biblepay-evolution
(This is where your source starts, ie /src is one folder down)
wget biblepay.org/syncblocks_testnet.sh
chmod 777 syncblocks_testnet.sh

Now to get in sync for TestNet only, the script automatically deletes just the data files (dont worry, it wont delete anything else), then it pulls down the snapshot of the blocks gzipped and unzips them into the correct places (including the llmq and all necessary governance files), then its up to you re-launch the wallet.  The script does close biblepay as long as your machine supports pkill.

To sync from 0 type:
./syncblocks_testnet.sh

EDIT:

I just created a windows version and tested it on windows 7 and it works.  Will check-in during the next Develop release.


2111
I had one, I just updated but I think I may be in the wrong chain, I will resync.

Im writing a script now to do a one-click sync, but it wont be ready til next version as I have to upload a file into github.


2112
Great news!

It looks like the latest version is POSE banning people!

POSE, here we come!

EDIT:  Wait, one of my own sancs got POSE banned.
Guys, please ensure your Masternodeblsprivkey is set correctly btw.

In my case it was not the masternodeblsprivkey (but that is still the most common cause of POSE bans).
In my case I had the externalip= set (to the correct IP) but for some reason the other nodes didnt like that, so I recreated my sanc. (without an externalip).

Now Im back in the list with 0 pose ban.

Im interested in seeing who else gets POSE banned.

LLMQ is enabled now.

MIP do you have a sanc also?  I know Oncoapop just added one so we should have 5 total if MIP has one.


2113
Great news!

It looks like the latest version is POSE banning people!

POSE, here we come!

EDIT:  Wait, one of my own sancs got POSE banned.
Guys, please ensure your Masternodeblsprivkey is set correctly btw.


2114
BiblePay
1.4.6.1-Mandatory Upgrade for TestNet

- Bump protocol version up to 70740 for Sancs (to force upgrade)
- Modify minimum LLMQ for testnet to be a size of 3 with a threshhold of 2
- Use Testnet LLMQ for instantsend and for ChainLocks
- Increase LLMQ height to 175000 in testnet

2115
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

So I took at look at the "bottleneck" in TestNet (with POSE not working) - IE in laymans terms, Sancs are not banning each other.
Also we have an issue in TestNet where LLMQs are failing.

So, the problem is our LLMQ in TestNet is pointing to params that are for the wrong quorum.  (I did update them at one point, and triple checked them, but Dash's testnet is bigger than ours, and that led me to believe we were using RegTest in TestNet and they were using 5_60 in TestNet but in reality, Dash was requiring 7 masternodes in TestNet minimum, and our RegTest params were only being used in RegTest LOL).  So thats good this was discovered and makes sense, and explains why our LLMQ quorums have all failed so far.

So, we will need a mandatory in TestNet (I need to force a protocol version increase) in order to release this next test.

So MIP, lets build a new testnet release.

We will announce asap.

EDIT:  Please remember to erase your debug.log before starting the new version.


Pages: 1 ... 134 135 136 137 138 139 140 [141] 142 143 144 145 146 147 148 ... 263