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 ... 134
1
Production Proposals / Re: Aug 2019 - Block reward breakdown adjustment
« on: August 17, 2019, 07:04:27 pm »
For some reason I cannot edit posts (not even OP)

But yes, I do agree with your proposed reward distribution
20% - Charity and Governance
25% - GSC
35% - Sanctuary budget
20% - POBH/Security

I also agree that, if approved, it must be deployed whenever is best for the coin's interest, not immediately.

Ok, sounds good.


2
Production Proposals / Re: FUBT Exchange
« on: August 17, 2019, 06:49:08 pm »
I'm doing some testing to see if I feel warm and fuzzy about this proposal.

So far I've created an account with FUBT, and found US customers need to have a KYC to trade.
However, after asking Nick about this, he explained due to the "94" regulation(s) in China, KYC is required for every exchange going forward.

EDIT:

Here are the instructions that US users need to go through to trade on FUBT.
First its critical you choose USA as the Country when you join.
If your Account Settings say China, you can still send a KYC by populating your Drivers License # and then contacting Support to fix the Country.

Instructions to link KYC into your FUBT Account:
http://pool.biblepay.org/SAN/Integration/FUBTKYC.pdf






3
Production Proposals / August payroll (Apr) 2019
« on: August 17, 2019, 10:23:39 am »
ommits on Apr 29, 2019
1.4.2.3-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 29
 
Commits on Apr 28, 2019
1.4.2.2b-Leisure Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 28
 
1.4.2.2-Mandatory upgrade for TestNet  …

@biblepay
biblepay committed on Apr 28
 
Commits on Apr 26, 2019
1.4.2.1b-Mandatory upgrade for TestNet  …

@biblepay
biblepay committed on Apr 26
 
1.4.2.1-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 26
 
Commits on Apr 25, 2019
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 25
 
Commits on Apr 23, 2019
1.4.2.0-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 23
 
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 23


Commits on Apr 22, 2019
1.4.1.9-Leisure upgrade for TestNet  …

@biblepay
biblepay committed on Apr 22
 
Commits on Apr 21, 2019
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 21
 
Commits on Apr 20, 2019
1.4.1.8-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 20
 
Commits on Apr 18, 2019
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 18
 
Commits on Apr 17, 2019
1.4.1.7 - Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 17
 
Commits on Apr 12, 2019
1.4.1.6-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 12
 
Commits on Apr 10, 2019
1.4.1.5b-Leisure Upgrade  …

@biblepay
biblepay committed on Apr 10
 
1.4.1.5-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 10
 
Commits on Apr 9, 2019
1.4.1.4-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 9
 
Commits on Apr 5, 2019
1.4.1.3-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 5
 
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 5
 
Commits on Apr 4, 2019
1.4.1.2b-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 4
 
1.4.1.2-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 4
 
1.4.1.1-Mandatory Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 4
 
Commits on Apr 3, 2019
1.4.1.0-Leisure Upgrade for TestNet  …

@biblepay
biblepay committed on Apr 3
 
1.4.0.9d-TestNet Leisure Upgrade  …

@biblepay
biblepay committed on Apr 3
 
Commits on Apr 2, 2019
1.4.0.9c-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 2
 
1.4.0.9b-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 2
 
1.4.0.9-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 2
 
Merge branch 'master' into develop  …

MIP
MIP committed on Apr 2
 
Commits on Apr 1, 2019
1.4.0.8-TestNet Mandatory Upgrade  …

@biblepay
biblepay committed on Apr 1


This was approx 120 hours - capping @ 1.5 MM this month due to budget constraints.


4
Production Proposals / Exchange Listing on Tokok.com
« on: August 17, 2019, 10:08:04 am »
We have an offer to be listed from Paul at Tokok.com for 2btc.

Tokok does 442 MM per day - see CoinGecko:
https://www.coingecko.com/en/exchanges/tokok
CMC:
https://coinmarketcap.com/exchanges/tokok/

If listed, Rob would provide the initial funding by loaning BBP the 2btc.
BBP would remunerate Rob in 12 payments of .16 btc each.

This is a competing proposal to provide entrance into the Asian market.
Impho, I recommend the sancs to vote on either one or the other (but not both) as I don't think we can afford both proposals.

Please evaluate Tokok, as we want the most honest and liquid exchange in Asia for BBP.


Payments:

Payment 1 - .16 btc - 2,430,939


** Help:  If anyone has anything negative to report about TOKOK, please report it now **

5
** 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.


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



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


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


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


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



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



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



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



14
** 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.


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


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