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

Pages: [1] 2 3 4 5 6 7 8 ... 81
1
So I added some more handling to the area of "ancestor not found".  I found a bug in Contact Add - fixed - will be in the next testnet version.

Im working on automating BOINC setup for brand new cancer miners. 

Let's pause for a little bit until the next version is ready, then we can test all this together.


2
Oh one more thing I just remembered, if anyone does receive that 'block has no ancestor' and crash, you can also make a copy of your testnet chainstate and blocks folders, and zip it and send to me, or simply keep it in order to have it to reproduce the error again in valgrind.


3
Sorry, I already -reindexed it :(

But I've installed valgrind in case it ever happens again. Can't seem to get it working in all my noobness though... Could you tell me what specific command I should use?
Sure, it should be easy as the defaults usually work.  Once you have valgrind installed, depending on how you launch biblepay (IE either "./biblepay-qt" or "./biblepayd") replace that string with this:

cd ~/biblepay
valgrind ./biblepay-qt

For example would start the QT wallet with valgrind running.  You can put all your normal parameters after the ./biblepay-qt also.  It might be easier to pipe the output to a log file since the log would be long (like  >vallog.txt) etc.  If you dont pipe to a log you can scroll back through the end of the trace and see functions and line numbers.  We usually need the last stack trace (the whole section to see how it was called).  Since some functions call other functions etc.


4
After restarting the 85.29 node I got the same 'Segmentation fault' error that Togo got:

Code: [Select]
ERROR: Found block with no ancestor
2018-09-19 21:17:36 ERROR: Block has no ancestor.

2018-09-19 21:17:36 ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-09-19 21:17:36 Misbehaving: 47.189.72.5:58842 (0 -> 3)
2018-09-19 21:17:36 ProcessNewBlock : ACCEPTED


Thats kind of cool; if you still have that node in that state, could you sudo apt-get install valgrind,  valgrind ./biblepay and see what line it breaks on?

If not we'll eventually figure it out, but you will probably have to reindex to get past it.

I seem to be back to normal on all nodes now.

I'll do my best to find that bug.  I know we fixed the major fork issue in this version, now we need a couple more minor things... checking.

5
Hmmm, my wallet crashed, v1.1.5.4b, I had upgraded, cleaned and reindexed
Code: [Select]
Segmentation fault (core dumped)
tail debug.log
Code: [Select]
ERROR: Block has no ancestor
Misbehaving: 84.29.208.33:62767
ERROR: invalid header received bd9004da***6d0fea
ERROR: Found block with no ancestor
ERROR: Block has no ancestor.
ERROR: ProcessNewBlock: AcceptBlock FAILED
Misbehaving: 84.29.208.33:62767

Im going to clean and reindex again

84.29 is running 1154.  I know that area of code, we crashed a couple times there in the past - there is even some code in there to try to prevent the crash.  Its really elusive because every time I hear this and try to valgrind it, there is no way to reproduce the exact situation again - I know it has something to do with having a lot of forks in your getchaintips.  I think one of the forks best block hashes is NULL to the wallet.  But we dont save NULL blocks in the map.  I did check Dash to see if they changed that but not yet.



6
I have three wallets. Only one was syncing to the tip (and had the same blockhash as you have), but that one didn't have a CPID associated with it. I just associated a CPID with that one, so let's wait and see if that's going to work.

The other two I'll try to resync...

Something is starting to happen now... I think.


Yes- all the wallets are clicking up now in tandem.  We had some type of problem based on where we sputtered out (right at the block before the last boinc superblock) and since our masternodes were all dead, the wallet couldnt come to consensus on that superblock.  Now we are past it and we have 6 or so testers online.  We just need to bring up our sancs now.


7
Alright, I've updated all my wallets and deleted the .dat's you suggested. Resynching now...

Thanks all - Ive relaunched 4 nodes and 2 are mining.  Although each block I solve is having trouble being added to the other nodes.
But, I believe we are back in the same state we were in prior to the QT fiasco, so Im thinking we just need another miner online now.

Lets be patient and see if another miner allows us to sync.  Im on block :
getblockhash 67726
35fa0d84e64d0fb0b4ec6a05588d8b38b42967e5acbebaa5384e780d10f55728

8
Oops, after I removed QT, I just realized one of the chain parameters in testnet was adjusted to look back 30 days for the QT 'governanceinfo' prior total (this was for future qt).... Sorry...

Please all, upgrade to 1.1.5.4b....

Building windows now.


We can talk about the cpids solving ability tomorrow after we resync again.

Thanks.

When you guys re-sync today, please delete your mnc*.* and mnp*.* files and the banlist.dat also first.

I have found that we may be caching a superblock (in the govobj system) with a bad payment - and I believe that will fix our sync issue in testnet.



9
Production Proposals / Re: Proposal - listing BBP on GIN MN platform
« on: September 19, 2018, 03:41:35 am »
I think we need to look past the price of $14 on this one, and have a hosted service (like GIN) available in our arsenal for the Non Technical users.

I see we have the same sort of arguments in this thread repeating (people with closed minds who view things one way).  We need to start thinking out of the box, and thinking of newbies.

(A technical minded entrepeneur may go out and start their own version of Gin and charge $1 a month and see if you can live on that, but it may go out of business).

I support this proposal, but our budget is too small this month.


10
All - I decided to remove QT (quant tightening) due to lack of popularity.

Please get 1.1.5.4, and resync the chain.

Windows is compiling...

Oops, after I removed QT, I just realized one of the chain parameters in testnet was adjusted to look back 30 days for the QT 'governanceinfo' prior total (this was for future qt).... Sorry...

Please all, upgrade to 1.1.5.4b....

Building windows now.


We can talk about the cpids solving ability tomorrow after we resync again.

Thanks.


11
All - I decided to remove QT (quant tightening) due to lack of popularity.

Please get 1.1.5.4, and resync the chain.

Windows is compiling...

12
So on the positive side we broke through the chain, and we are rolling.

But the thing Togo mentioned in his log he has solved prior blocks; so I set up two distinct CPIDs in testned and they are both synced to the top.
Whats very, very strange is they both also say they solved prior blocks (like Togo).

In addition, I took a look at the code, and it looks fine, and we havent changed anything related to mining with this QT feature, so Im confused how we introduced a failure in this respect.  Im also mining at .80 hps.

So, let me add some special logging for this and Ill get to the root of the problem.



13
My Sanctuary is synched with the proper hash, but it's not linked to a CPID and I don't have tBBP on that wallet to link it.

The wallet I have all my tBBP on doesn't synch yet (it can't find any peers), so I can't send tBBP to my Sanctuary :,)

Can someone send tBBP to my Sanctuary:
yjZ91KimqJp7jdpPpZv6G93BNjLmUGcM83

Thanks!

I sent 1 mil a block back, but we are stuck til we find another cpid :).


14
Upgraded to v1.1.5.3, Reindexed, Masternode stuck trying to sync, tail debug.log shows my CPID cant solve more blocks haha

Yeah, I see that mining issue.  I took a look at the code - and basically the state we are in testnet is each cpid can solve every other block (the lookback is 1 but in prod its 4).  So I was able to solve the block after yours, 67135, but I think maybe you just stopped mining?  Looks like were' stuck, anyone have any good cpids out there?

Let me take a look at all my other wallets and see if I can find an old cpid.  (I cant reassocate one new one if the chain isnt moving, :) )


15
Also please reindex your chains. 

Proper blockhash is:
getblockhash 67134
535412acfe3f3efd39830edc8f82b70c9e7cca32950e9866f10b5fbaea800069


PS We need a miner to start mining on 1153 - my only testnet cpid just solved 4 in a row so it cant continue.




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