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 9 ... 127
16
Before I draft an upgrade plan to transition to Evo I thought I would share my idea here first.

Please comment if you have any questions concerns or possible enhancements.
Also, I haven't heard any negative comments on POG/Healing or the payment system, and I assume everyone is happy with the payments compared to the coin age and the tithe levels.

Upgrade to Evo Plan of Action:

Around June 2nd 2019 (this is after our May monthly superblock pays out in biblepay-classic): (Height approx 124000):
At this height, all Sanctuaries must upgrade to Evo, and re-lock 4.5MM in Legacy Sanc mode.
Notify entire network to upgrade to Evo (also at 124,000).  Note: The entire network will be running in classic mode in Evo, with non-deterministic sancs.
Notify exchanges to upgrade at height 124,000 (this is Optional, but I think for best practices, we will ask them to upgrade along with us at 124,000).
Pools upgrade at 124,000 also.

The goal from blocks 124,000 through blocks 131,000 will be to finish upgrading all sancs to non-deterministic sancs, and through this entire period we will be in POBH (classic mode) - this will also give a little extra time for late upgraders who are running classic.  This plan also ensures that we do not break biblepay classics block structure while we upgrade to non-deterministic.  (Note that sanctuary payments will start as soon as approx 10 sancs upgrade (this will most likely happen the first day - IE June 2nd).

At block 131,000 (after the June superblock budget is paid in Evo with non-deterministic sancs), we start upgrading to deterministic sancs (this should be a transparent change as we will not flip dip15 until block 138,000). 

At approx block 132,000, we will also enable GSCs, and QT.  ABN & Anti-GPU will be enabled around block 134,000 if the network is healthy in small phases.

After the July superblock (height 139,000) - we enable dip15 (which makes deterministic sancs permanent).


17
gen=0 is the first thing I did.
Well you will know if that is the problem if your node syncs to a certain height and stops syncing (as it tries to prefer the block you solved).  If you get enough connections it will recover though.

Let us know if you still have a problem.  I can always check my logs for your ip if you provide it.


18
Hi Guys,

I've upgraded to 1.4.2.8. My sanc says the following:
My controller wallet shows the Sanc in the DIP3 tab though, and I've been getting payments?

I'm sorry. I don't have much time to dive into the Dash documentation :(

Yeah, the payments will start deterministically based on this new algo, and continue until your node is PosE banned.  PosE happens if your node is Off for a certain amount of time (and gets voted down), or if your node isnt participating in the new LLMQs (long living masternode quorums).

As far as the node itself, it cant find its own proreg tx on the chain.
Most likely because the masternodeblsprivkey is missing.

Please copy the key from the deterministic.conf to the node and reboot it and see?

19
v1.4.2.8b, both Ubuntu, both command line daemon, one Ubuntu 16.04, other Ubuntu 18.04,

I was checking the log that didnt have debug=1 in it and couldnt see anything stick out,

by crash, I mean it started up and I typically keep entering "biblepay-cli getinfo" to check its progress, but it would give me some RPC error and biblepayd wouldnt be inside "ps -ef", and Id have to start it up again, and then it would crash again

I just downloaded the one that had debug=1 on, about to go through it, 80mb debug file

=

I believe this is the relevant section of the debug.log, hopefully it is and Im not wasting your time
(uploaded it to file hosting site, 4.7MB)
https://ufile.io/pqaao2vj

=

Code: [Select]
2019-05-08 04:50:28  ABN OK: 1.000000 LoadExternalBlockFile: Processing out of order child 7d37aaa250a86221b5ba434365aec3dc127183af7ccbabdec9367b7e9fa14719 of 4e5bcad04e7082d25315cfc964b463c70f8053de1e68013e532ce38f43d78d95
2019-05-08 04:50:28 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at CBlockDiskPos(nFile=0, nPos=39353)
2019-05-08 04:50:28 *** Failed to read block
2019-05-08 04:50:28 Error: Error: A fatal internal error occurred, see debug.log for details
...
2019-05-08 04:50:28 Interrupting HTTP server
2019-05-08 04:50:28 Interrupting HTTP RPC server
2019-05-08 04:50:28 Interrupting RPC
2019-05-08 04:50:28 Exited http event loop
2019-05-08 04:50:28 addcon thread exit
2019-05-08 04:50:28 mncon thread exit
...
2019-05-08 04:50:28 PrepareShutdown: In progress...
2019-05-08 04:50:28 Stopping HTTP RPC server
2019-05-08 04:50:28 Unregistering HTTP handler for / (exactmatch 1)
2019-05-08 04:50:28 Stopping RPC
2019-05-08 04:50:28 RPC stopped.
2019-05-08 04:50:28 Stopping HTTP server
2019-05-08 04:50:28 Waiting for HTTP worker threads to exit
2019-05-08 04:50:28 Waiting for HTTP event thread to exit
2019-05-08 04:50:28 Stopped HTTP server
2019-05-08 04:50:28 CDBEnv::Flush: Flush(false)
2019-05-08 04:50:28 CDBEnv::Flush: wallet.dat checkpoint
2019-05-08 04:50:28 CDBEnv::Flush: wallet.dat detach
2019-05-08 04:50:28
BiblepayMiner -- terminated
 0CDBEnv::Flush: wallet.dat closed

Is this the culprit?
Code: [Select]
2019-05-08 04:50:28 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at CBlockDiskPos(nFile=0, nPos=39353)
2019-05-08 04:50:28 *** Failed to read block
2019-05-08 04:50:28 Error: Error: A fatal internal error occurred, see debug.log for details

=

From other logs it seems typically theres:
Code: [Select]
ThreadRPCServer method=stopor with GUI
Code: [Select]
GUI: requestShutdown : Requesting shutdown
GUI: shutdown : Running Shutdown in thread


Thanks, got it (downloaded the file and analyzed).
At least I can tell you what exactly happened (that its not a systemic problem preventing release).

So in your case, your node ran and flushed the blocks db correctly on the prior run.
You ran it with reindex and it made it to height 21598 when it ran into a bad serialized block (IE the length pointer was longer than the maximum allowed data) meaning to biblepay, it believed the blocks database was corrupted.  This obviously was probably not corrupted but something the reindex did to the file instead.  For one it was reading the blocks out of order since height 1100, which is not too good for biblepay because of our contextual checkblock rules.

I personally have had a lot of problems with -reindex, so much that I stopped doing it (I always just sync from the network now). 
My non-optimal solution is to create a blocks file download in prod weekly or monthly for our users who want high performance download of the initial blocks from biblepay.org/snapshot for example.  We can make that a possibility when we hit around block 150K. 

In this case, the program handled the exception but obviously exited and that left you with no choice but to resync the chain.
Note that -reindex does work when the blocks are read in sequentially, but they are not guaranteed to be sequential in berkeleydb.




20
I saw in debug " 0 addresses found from DNS seeds" so I was planning in adding them manualy but ok.
 
prict from previus post


We add them in a non-conforming way (we force them in).

Usually they kick in after 15 mins if your IP was temporarily banned.
That happens very easily when you are on your own chain, your client forwards block headers to the seed nodes, they ddos you and build up a certain amount of minutes ban, then they allow you in again after you stop the activity and try to start from zero.


One other problem with syncing from zero is you may need gen=0 to get started as in testnet its suuuuper easy to solve a block and get on your own chain (I had to do the gen=0 today to sync properly).



21
Upgraded both wallets to v1.4.2.8b yesterday

I tried to just run them normally, but they would crash right away, tried to reindex and same thing, didnt see anything in the log (may have forgotten to add debug=1), so I wanted till today and tried again with reindex, both worked a couple hours ago

getblockhash 69207
6e40d8f*

Are you sure the terminal window didnt say "assertion failed" when you ran it?

(Thats not a crash - thats an ungraceful exit).  That happens when evo chain pindex != pindexbest.  (Ive seen that a few times).  That happens when the database exits uncleanly without a flush.  We put in a fix for that in classic, but we left it the way it is in Dash since they have it in there I figured it was good enough for us, but its obviously a 6 1/2 dozen other conundrum type issue.


22
no, there is no reason. didnt even know I am hiding it.
I uncomment this below and now it got the connection.
#rpcuser=
#rpcpassword=
#rpcallowip=127.0.0.1
#rpcport=40001
#listen=0

Ok good, I was only asking because yesterday I saw some strange activity that looked like someone was sending things from a fraudulent client (IE a self compiled fraudulent client).

Yeah the addresses are:  dns1.biblepay.org, dns2.biblepay.org and dns3.biblepay.org


23
So I have a few pieces of advice for anyone creating new deterministic sancs:

1) Do not lose your masternodeblsprivkey (or pubkey).  Keep a copy of your deterministic.conf somewhere.  If you lose your wallet.dat, your sanc will keep running as long as the collateral is locked, and you will not be able to change its IP or its collateral without that blsprivkey and owner privkey.
2) However, I did a test today and found a way to immediately kill your old sanctuary (and allow upgrading).  If you spend your collateral, within minutes the sanctuary will dissapear from the active sancs list! 
3) You cannot re-register the same IP with a new sanc until you either Revoke your old sanctuary (with a proUpRevTx), or if you spend your collateral.

I was successfully able to re-create a new sanc today after I spent my collateral and did a new upgradesanc command.

If otoh you do an upgradesanc before spending and revoking, you will receive an error (duplicate service IP).


24
Upgraded both wallets to v1.4.2.8b yesterday

I tried to just run them normally, but they would crash right away, tried to reindex and same thing, didnt see anything in the log (may have forgotten to add debug=1), so I wanted till today and tried again with reindex, both worked a couple hours ago

getblockhash 69207
6e40d8f*

Synced


25
nope, something doesnt work at all. Like I am on my own


what are the nodes, i saw them in previus version, but cant remeber. ns.biblepay.org?
Like I alluded to in the prior message, they would be compiled in if they are seed nodes so you dont need them, and I synced today with a node.

Is there a reason you are hiding your ip?


26
Upgraded both wallets to v1.4.2.8b yesterday

I tried to just run them normally, but they would crash right away, tried to reindex and same thing, didnt see anything in the log (may have forgotten to add debug=1), so I wanted till today and tried again with reindex, both worked a couple hours ago

getblockhash 69207
6e40d8f*

When you say crash, what do you mean, and what version are you running (qt or non) and what platform (unix linux mac)?

Yeah, since I have not seen a crash yet except clicking on leaderboard in prod (which was fixed in the last version) I would really like to know how to reproduce.

Also, if anyone else has ever crashed in evo in testnet it would be really nice to have more info so we can fix it before we go to prod (thats what testnet is for).


27
ha, to late. I deleted everything and now I have a problem, no peers

Check system clock ensure its correct within 5 mins and timezone is correct.

Delete banlist.dat, restart.

If you arent synced after 15 mins post IP address here and Ill search my log for the reason for your ban as we have 3 seed nodes in testnet.

28
We should technically re-sync better on this version (I mean the initial sync after upgrading only), as now we have classic's code for mandatory upgrades in.

BTW:  Please dont erase any files, just upgrade.


29
1.4.2.8b-Mandatory upgrade for TestNet

- Add testnet checkpoint
- Enhance ABN consensus rule to only require ABN when diff is greater
than threshhold (this should improve the SetBestChain business logic)
- Port biblepay-classic peer disconnect rules (enforcing network time
and minimum version)
- Ensure wallet does not crash in Prod when people click on Leaderboard
or Proposals

30
There are some differences in the output of the getmininginfo

>EVO -version
BiblePay Core RPC client version 1.4.2.7
>
Code: [Select]
getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "pooledtx": 0,
  "chain": "[b]main[/b]",
  "genproclimit": 1,
  "networkhashps": [u][b]10394307548.78834[/b][/u],
  "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 [u][b]1.2.0.1[/b][/u]
biblepay-cli getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "genproclimit": 2,
  "networkhashps": [u][b]1418552.369007834[/b][/u],
  "hashps": 187.8965827796162,
  "minerstarttime": "05-07-2019 14:17:00",
  "hashcounter": 1903566,
  "pooledtx": 1,
  "testnet": false,
  "chain": "[b]main[/b]",
  "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!

First of all, know that mining in Evo against prod (solo or against the pool) is virtually the same as mining in classic (as far as HPS, efficiency, and fairness) - there is no advantage to either client (except Evo might be 1% better due to its more optimized compiler and Depends environment etc).

Regarding the Network HashPS, first let me try to explain how Bitcoin calculates it.  Its a trailing average of chain hashpersecond found in the last 10 blocks or so (the blocks contain this data because we track the nonce req count and chain weight etc).  But, where this discrepency starts occuring is back in POBH v3, Alex and I were doing some testing and we realized due to our very unique hash algorithm we put waaaay more hashes in per hash than the networkhashps reported so we tweaked it in classic to be our new fangled estimate.

So the answer is in Evo its too low.  I remember now why this was not updated:  POBH changed in Evo.  I just made a punchlist item to fix this.
But in summary, its a barometer being affected by the wrong multiplier currently.

EDIT:  Actually Evo looks pretty accurate as-is (it seems this fig is too high in Classic).  Since I have the exact HPS in the pool, and the % of blocks solved by pool.bibepay.org, we really are doing about the Evo-hps right now in prod.








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