Bible Pay

Recent Posts

Pages: 1 2 3 [4] 5 6 7 8 9 10
31
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.

32
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?
33
Hi Guys,

I've upgraded to 1.4.2.8. My sanc says the following:
Quote
10:07:01

masternode status


10:07:01

{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "84.29.XXX.XXX:40001",
  "state": "WAITING_FOR_PROTX",
  "status": "Waiting for ProTx to appear on-chain"
}


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 :(
34
 gen=0 is the first thing I did.
35
Mining / mining, may 2019
« Last post by fahq420 on May 08, 2019, 11:25:24 pm »
Is the PODC portion done? ive been mining on it (reinstalled last night) the heat mining paid in, but i see no magnitude on the wallet or any recent references to CPID or Boinc..
36
Thank you for looking into it Rob!
37
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.



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


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

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