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 - vuli

Pages: [1] 2 3
1
General Support - Solved / Re: wallet 1.5.1.4 hi cpu usage
« on: June 08, 2020, 04:16:38 AM »
ok, thanks for the info.

2
General Support - Solved / Re: wallet 1.5.1.4 hi cpu usage
« on: June 05, 2020, 12:05:41 PM »
yah, i see. I have gen=1
Now it doesnt make sense to have gen=1 in biblepay.conf since its mining xmr?  I wasnt here for a while and I am a bit  :o

3
General Support - Solved / wallet 1.5.1.4 hi cpu usage
« on: June 04, 2020, 01:07:55 PM »
wallet 1.5.1.4 is eating a lot of cpu power 30% on a 16 thread cpu. Is this normal?

4
 gen=0 is the first thing I did.

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

6
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

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

8
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.
ha, to late. I deleted everything and now I have a problem, no peers

9
I've been having a hard time resyncing every time we have a mandatory upgrade.  I know part of the problem is when we force a new protocol version, it knocks all the sancs offline.  (I have an old biblepay classic feature I am going to port that prevents that, allowing us to sync easier but still forces us to upgrade), so I will need to put this in today.

Two other things, I have realized one of the reasons we have trouble syncing when the diff is < .02 is because the wallet is having a hard time figuring out which fork is valid (in its diff calculator).  I believe we will need a couple consensus rules added.  For one, we should only add and enforce ABNs when the diff is > 1.0 in testnet (and a higher number in prod).  I think this would help us immensely (coming to consensus).  The other is the same with anti-gpu.  We shouldnt really be monitoring or enforcing that if the diff < 1.0.
what about checkpoints? I saw in some wallets using checkpoints for easier sync or what.

10
i have the same hash

11
I send you some "change"

12
After resyncing my sancs and starting them I see this hash:

11:21:31

getblockhash 40668


11:21:31

9c1b6d67d8737b9976eed162b8edce7018430a9f2d16cfd97e4c83b14943baf6


Anyone agree with mine?

well I resynced and my last block is 34929

13
I had to delete everything, than it synced headers as well.

14
I am stuck the whole day at Syncing Headers 96,3% , progress bar  is  2sec behind.

19:25:02
getblockhash 36743

19:25:02
d7d64e0701e5480e3b53429d7015b03ae0351c025dfd6d4de9c86f05f8294bd6

15
emm, I have differnet hash on that block like yesterday-

10:31:55

getblockhash 25354

10:31:55

ce7fbfd5dfbab275f35984dac4b447db7866d1bd38eac7c19010764b1f603085

Pages: [1] 2 3