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
General Support - Solved / Re: wallet hi cpu usage
« on: June 08, 2020, 04:16:38 AM »
ok, thanks for the info.

General Support - Solved / Re: wallet 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

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

 gen=0 is the first thing I did.

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

no, there is no reason. didnt even know I am hiding it.
I uncomment this below and now it got the connection.

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.

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

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.

i have the same hash

I send you some "change"

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


getblockhash 40668



Anyone agree with mine?

well I resynced and my last block is 34929

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

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

getblockhash 36743


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


getblockhash 25354



Pages: [1] 2 3