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 ... 3 4 5 6 7 8 9 [10] 11 12
136
We are now in the final phases of testing.

I think at this time it would be prudent for us to do a dry run - testing the things that will happen soon in prod.

For one I am writing the scripts to build the 32 & 64 bit version for windows and deploy to our website for download.

So far we have been running the 32bit windows version.  Ill build a 64 bit version now, and post the link and lets ensure this 64bit runs on our windows machines against prod.

Oncoapp and I already tested both pool mining pools and HTTPS communication.

I suppose I can be the guinea pig to test a couple Production sancs (using 4.5MM each).
Im currently deleting all the files on a couple VMs readying these VMs for Evo, once this is ready, Ill take the plunge and set up an Evo sanc in prod (in non deterministic mode, btw).

NOTE:  It is very important we make it clear that we Do Not want any sancs in Prod to upgrade to Evo until the announcement and cutover height is posted, as I want our monthly superblock to pay out properly  ;).

MIP, do you think we will have a Mac build available by June 2nd?  It would be nice to give them an upgrade path.

Ive already confirmed with GIN that they are ready to upgrade to Evo.

EDIT:

Ok, if anyone wants to test the 64 bit build on windows:
https://biblepay.org/biblepayevo64.exe

Thank you for your acknowledgement! Glad to be part of this project and the community of believers in Jesus and hence happy to help in this small way!

The UI is great and, as far as I can tell, installs and runs on Windows 10 64-bit (I needed to addnode my own classic sancs for it to find the block source) and it took quite a while to load from scratch. I have currently got it mining on the pool
http://www.purepool.org/main/miner/BFwWN5ohJLcUAn1H9urqUqaA9oqPUBJtbh/

The first one (1.4.2.8 EVO on mainnet compiled in Ubuntu 18.04) is still crunching
http://www.purepool.org/main/miner/BD9gmJ5vmPJtDewo9NyqUT7fJQgV39AW7R/

There appears some typos under "JESUS' CONCISE COMMANDMENTS"
Pure and undefiled religion before our God and Father is to care for orphans and widows in their distress, and to keep oneself from being polluted by the world. (John 1:27) - ref is actually James 1:27

Do not Store up Treasures on Earth where moth and rust destroy, and where thieves break in and steal, but Store up treasures in heaven, For where your treasure is, there your heart will be also. (ref is missing - Matt 6:19,20a,21)

The "Help - About Biblepay" Tab has some unnecessary boxes at the bottom of the screen.


137
There are some differences in the output of the getmininginfo

>EVO -version
BiblePay Core RPC client version 1.4.2.7
>getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 1,
  "networkhashps": 10394307548.78834,
  "hashps": 222.8212327270187,
  "minerstarttime": "05-07-2019 11:16:12",
  "hashcounter": 4675568,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "Submitting Solution 05-07-2019 17:04:52; ",
  "poolinfo3": "",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "required_abn_weight": 0
}

-version
Biblepay Core RPC client version 1.2.0.1
biblepay-cli getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "genproclimit": 2,
  "networkhashps": 1418552.369007834,
  "hashps": 187.8965827796162,
  "minerstarttime": "05-07-2019 14:17:00",
  "hashcounter": 1903566,
  "pooledtx": 1,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 3052,
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "poolmining_use_ssl": true
}

Notice the great differences in networkhasps. Does this mean that early EVO (>v1.4.2.7) upgraders are at a severe disadvantage in terms of POBH mining when competing with v1.2.0.1? Or is this because I am the sole v1.4.2.7 on the mainnet? Difficulty appears to be similar though....

Can you kindly explain? Thank you. Testing is also a good educational experience for us all!



138
I guess the next step is to see if one can create a DIP3 masternode on the mainnet but I am unable to help with that as I do not have the required collateral...

139
~/biblepay-evolution/src/qt/biblepay-qt loads ok but perhaps to be expected crashed when you try to view leaderboard and proposals.

140
Interesting, I managed to send funds (BBP not tBBP) from my wallet on the mainnet to the wallet running EVO!

~/biblepay-evolution/src/biblepay-cli getinfo
{
  "version": 1040207,
  "protocolversion": 70732,
  "walletversion": 61000,
  "balance": 100.00000000,
  "privatesend_balance": 0.00000000,
  "blocks": 117804,
  "timeoffset": 0,
  "connections": 11,
  "proxy": "",
  "difficulty": 9338.691900918453,
  "testnet": false,
  "keypoololdest": 1557217142,
  "keypoolsize": 999,
  "paytxfee": 0.00000000,
  "relayfee": 0.01000000,
  "errors": ""
}

~/biblepay-evolution/src/biblepay-cli listtransactions
  {
    "account": "",
    "address": "BC2RsquwDER8sCKcMmDCy9rgKSusWLZpGn",
    "category": "receive",
    "amount": 100.00000000,
    "label": "",
    "vout": 1,
    "confirmations": 2,
    "instantlock": false,
    "blockhash": "49d1f7e4d26f8547da3ae9c25a40232080706293a95859f2e0c0770aa05d5270",
    "blockindex": 1,
    "blocktime": 1557225899,
    "txid": "29f1b61e84d4f6eae1ef9eb49b8ef3f9f49366576b3eeb57282e2e7367f9c917",
    "walletconflicts": [
    ],
    "time": 1557225892,
    "timereceived": 1557225892
  }


141
Oh btw, I did test Evo against prod last month, and also tested Pool mining (in prod mode).

If anyone feels up for it, please sync in prod, and verify you can sync to the top in prod.
Then configure the miner to be pointed at a pool, and ensure pool mining is working.
Note:  It would be very helpful if someone could test Purepool.  I only tested mining in evo in prod against pool.biblepay.org (successfully).

$ ~/biblepay-evolution/src/biblepay-cli getblockcount
117799

$ ~/biblepay-evolution/src/biblepay-cli getblockhash 117799
1a038e93b4046038444f7a98abd546aa2a7a8580ade7771224a73685b79314b5

I don't know what exactly is required but here is the output of getmininginfo of EVO on the main chain pointed to purepool.

{
  "blocks": 117798,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 10211.68938254838,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 1,
  "networkhashps": 14937188254.95241,
  "hashps": 28.84073865488929,
  "minerstarttime": "05-07-2019 10:24:22",
  "hashcounter": 4865,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "required_abn_weight": 0
}


The progress can be followed here http://www.purepool.org/main/miner/BD9gmJ5vmPJtDewo9NyqUT7fJQgV39AW7R

142
Yeah this is by design (part of Dash).  Basically you can do one of two things:
Either send yourself 4,500,001, then go to coin control and right click and Lock the funds you just sent to yourself, Or
B) You can add the entry to your masternode.conf file, and then restart the wallet, and the funds will be locked, then create the next sanc.

Thank you for your advice, Rob. (2) worked for me. For (1), when I tried to lock the "unlocked" coins using "toggle lock state" button, the "locked" become "unlocked" and vice versa.

I thought I would try multiple sancs in testnet since it I would not be able make any on the mainnet with the new requirements....  :'(

We should all be on the same chain as I can see all 10 testnet sancs.

getblockhash 59604
3e5dffdc3509a0d4e32915fe2a7b7025b998591e2a0303d1df3b47e52cc0dc61



143
I cleaned wallet and reindexed, and restarted masternode

getblockhash 58859
6a0005b2*

Do I match?

6a0005b24145a7bdcfb9e7c245342f400a48f18d12a8a9f8b5cd7052190f99a8

matches with my sanc. I seem not to be able to bring more than one sanc online as each time I send create a new address and send the locked funds to the (self) address on the controlling wallet, when I type masternode outputs, the previous output is overwritten and my previously enabled sanc goes missing...

144
I have an error from my VPS which I am sure does not have a GPU, but does not appear to have any consequences as I am still able to receive immature 3500 tBBP payments which I presume to be mining rewards.

from getmininginfo:

{
  "blocks": 58834,
  "currentblocksize": 1842,
  "currentblocktx": 2,
  "difficulty": 0.05928717518932814,
  "errors": "",
  "pooledtx": 0,
  "chain": "test",
  "genproclimit": 6,
  "networkhashps": 877889.1198299188,
  "hashps": 306.3897603130411,
  "minerstarttime": "05-02-2019 19:13:20",
  "hashcounter": 2062114,
  "pooledtx": 0,
  "chain": "test",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "gsc_errors": "anti-gpu triggered on my CPK",
  "poolmining": false,
  "pool_url": "",
  "required_abn_weight": 1000
}

145
Archived Proposals / Re: Consolidation of Sanctuaries
« on: April 11, 2019, 04:58:18 PM »
I wonder if the consolidation can be achieved in an alternative way (as maybe others have suggested in other forums) that is to allow for multiple masternodes on a single host? That would mean allowing each sanc to use a different port. I don’t know if that is worth considering or even technically possible.

146
1) We had synced from 23234 up to about 23336 but with a difficulty of .10 (IE very low).
The wallet will reorganize back to 23234 if it finds a chain with greater total chain work (which is possible since 23234 had a diff of 20.)

(As long as the re-org block is valid).

2) ABN tries to prevent single rich kiddies (IE someone who has 20 servers) from solving an inordinate amount of blocks personally.  It does this by using up their coin-age.  But in testnet this 20 diff could come from a few high powered machines, although more likely 4-5 miners running full speed right up to that block (so you are correct abn might have helped, but in testnet everyone has a lot of coin age also).

2a.  We actually don't have ABN turned on right now :), I disabled it so we can test one feature at a time.  I planned on enabling qt next then abn later, but now we have to figure out this sync problem first.

3.  I am also rolled back to 23234 right now, so you are experiencing the same thing as me (another words the hash I posted is no longer valid).

Ill do some poking around.  We probably need to turn up our miners to more threads to solve the next block.

Ok thank you for that explanation!  We seem to be moving along.

147
Seems that all my sanc are went out of sync and are unable to sync up to that block. Stuck at 23234 when I initially got one sanc to sync with your 3 even after resync.

isn’t the ABN feature supposed to prevent these sorts of attacks? Please help me understand in layperson terms what is happening and how did that bypass ABN?

Thank you.


148
Good job so far. I have a question:

1/3 sancs that I have reports a different health output:

 "votes": 1,
  "required_votes": 3,
  "last_superblock": 14985,
  "next_superblock": 15190,
  "next_superblock_triggered": true,
  "Healthy": true,
  "GSC_Voted_In": false
mastenode outputs
{
  "626a61b0dfa151374bb42f1c432853efacb1742292318f9389c121f51b3310e4": "1"
}

-------------------------
2/3 report this:
  "votes": 5,
  "required_votes": 3,
  "last_superblock": 14985,
  "next_superblock": 15190,
  "next_superblock_triggered": true,
  "Healthy": true,
  "GSC_Voted_In": true

Is that normal behaviour?

149
I think things are OK on the back end, but we might need another field - but first whats your sanc Ip, I can check some things to make sure I see your vote?

Btw, no - you should not have to vote manually, this is all automatic.

Thanks.

bbpd@sanc2:~$ ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 45.62.239.200  netmask 255.255.255.0  broadcast 45.62.239.255
        inet6 fe80::250:56ff:fe95:4682  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:95:46:82  txqueuelen 1000  (Ethernet)
        RX packets 600708  bytes 190734759 (190.7 MB)
        RX errors 0  dropped 276  overruns 0  frame 0
        TX packets 530771  bytes 225023604 (225.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

150
** Update **

So for the last few re-releases the common theme has been:
- No signs of a problem with abn weight, or gsc client side transactions, or creation of the pog points
- No signs of problems with actual POBH heat mining (IE no forks resulting from POW)
- No signs of problems on the *monthly* superblock budget system or its creation of budget data

- Every re-release so far and enhancement resulted from a problem related to the Daily superblock contract
 (not a problem with the actual contract, a problem with the sancs not *finding* the contract, some find it, some lose it)

So I've been trying to hone in on this for the last 2 days - because at first I believed running only 3 sancs meant that one sanc out of 3 was not syncing properly- so we added rules to strengthen the minimum requirements of the voting required for a superblock to pass.  Yesterday however, all 3 sancs could see the votes on the superblock (we had 4), but only 2 of them had the actual gobject in memory (that is obviously a problem).

Let me explain this a different way, so we can all understand how a soft consensus can still fork the chain in testnet.
Sanc #1 and Sanc #2 had the gobject in memory (this is the GSC contract with its payments and addresses).  Sanc 1,2,and 3 had the *vote* for the gobject in memory and they all agreed the superblock was good and should pass.

Here is what happened on block 6990:

Sanc #1 found both the gobject and the trigger votes, and it said:  Valid, accepted
Sanc #2 found the votes only, and said "valid superblock at this height" but actually rejected the block because:  IsBlockValueValid, too few superblock payments <-- this is because it was missing the gobject with the hex data

So lets see what happens; Sanc #2 goes on its own chain now, Sanc 1 and 3 continue on the chain with the higher work.  This actually splits the testnet network because now Sanctuary votes for 1 cause (mnpayments to decrease), IE do to our mnpayments relying on chainheights- this becomes a hard split - and in a small
 testnet network we cant have this, so therefore we have to fix the root of the problem.

This ends up causing a hard fork, because #2 will never re-correct its view of this block until completely resynced as it has now marked the block as a fail.

First, lets stop testing again until I can release a plan to fix this.
(It does not appear to be watchman).
It appears to be more of a timing issue.  In Dash, the gobjects are synced over a longer time span (as we normally have a month to get all the data for the monthly votes), but in our case, we are trying to sync (with 2 minute blocks) all the superblock data within 190 blocks (IE < 3 hours)-- so I can see if one sanc misses a gobject, its going to make a bad call on the next superblock.

So, my plan is this next:
1. I will investigate all code that syncs gobjects, and see if we are lacking something (Ie timing issues) and beef this up
2. I will do something special to allow us to Monitor the next daily gsc superblock, like a command line that will alert us that a node is going to make a bad call on the next block
3. We will make the sanc go out of its way to Pull the data it needs to make a good call on the block manually

Then we regroup here and do an in-depth analysis on the actual superblock heights as they are about to tick by and post something on the forum to see what the state of each one is as they occur. 

Please hang on for the next version, it might take a day, it might take less depending on how complex the timing issue is.

I appear to be on the correct chain by as far as I can tell (checking manually), I have not seen my sanc (the 4th) vote for any superblock. Does this have to be done manually?

bbpd@sanc2:~/Sanctuary$ cli getblockhash 10120
e13331a79a04776297f1ef66634525bb3d16aca8c9ff8d61a5be21f2c5202caf
bbpd@sanc2:~/Sanctuary$ cli exec health
{
  "Command": "health",
  "govobjhash": "9ff38ea222d3bb56085b2c696a10ddf02d16548cdb23beec3db828ae5ed8b929",
  "Amounts": "736194.00|180067.00|173696.00|101790.00|23491.00|37641.00",
  "Addresses": "yR26BVwFeGTnkgdfw1RRNgVF2LyPnrZqaT|yS9YaCFpQuE6xpBrTvUbnPyJgwaXZep8C8|yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|ygavD5YuAJXpHDMLRyiiJ199YM5y9fTWfB|yiWrpMBA8YXfVmxntAgZZ1dh18ueaBerbW",
  "votes": 2,
  "required_votes": 3,
  "last_superblock": 10680,
  "next_superblock": 10885,
  "next_superblock_triggered": true,
  "Healthy": true,
  "GSC_Voted_In": false
}

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