Topic: [ANN][Actinium][PoW - Lyra2z] - page 10. (Read 34002 times)

A new website for the business looks really cool, I've to say you guys did a good job on the rebranding as well. New logo and banners looks way better then they used before.

New pool for Actinium is now live on:

HOWTOs on Pluggable Transports for TOR.

Useful if you are running Actinium in countries that completely block TOR (like China, Russia etc.).

• OBFS4
• MEEK

Glad to hear that!
Good to know that our Linux users can also participate in the network without crashes. The more different systems we support, the better for us all.
Of course, if you find any other problem, please report. Also via GitHub if you like.

Btw. we have a Bounty Fund which we use to reward people who help the project and I would like to send you some bounties.

If you like to get some ACM, please, send me your address via DM. You can also do this via Discord/Telegram if you are member there.

Best regards, and thanks again!

Thanks for the explanation, that makes sense. The error message made me suspect some issue with Segwit implementation but I did not know or understand the details. You've made it clear.

The latest interpreter-fix branch synced up immediately without crashing and has been running for a while now. So it seems to be fixed at least as far as I can tell. If it crashes again I will post but it has not behaved this well (staying connected, receiving new blocks over time) in all my tests so far. Good work figuring that one out.

Edit:
Still works fine. Also built fine with updated makefile. Problems resolved.
Cannot send you BCT message because newbie status. Cannot send discord message as your server requires phone verification; I won't provide that.
Ultimately you fixed the bug, I just reported it, so ^{PHoKcBCcoWCToPyzh3AFDj1qQ3zZxwYgve} (I think solicited non-incentivized non-giveaway address is fine?) or faucet it. thanks =)

On any of my machines, macOS/Win/Linux, the sync runs without any errors. Actually, it already ran with the normal verison 0.17.4.0, but it's also syncing with the "special edition".

I really don't know what could be the next option to try. I have released the binaries for macOS & Windows in the posting above, so I will wait for user reports before trying anything else as it's simply too dangerous to change the code without more data from different users.

Sorry that I can't help you find a solution but for now I have no other option to try.

--EDIT--
I will now push another variant that is more tolerant towards those few problematic transactions. Another user (windows box) reported a similar issue. However, I didn't get the info on what block, so we will have to test it step-by-step. But I have checked the code and comments from Bitcoin team and according to them, a block could also have Witness Data appended even if there was no SegWit activated. A bit of background info here: We didn't activate SegWit by default, but had a normal voting period. I could have put SegWit to active from the beginning, but I wanted to make it "clean". However, some mining pool operators mistakenly activated the SegWit-option in their mining software (like YIIMP) which of course has nothing to do with our Wallet/daemon or even voting period. And because Witness Data could also be appended when there is no SegWit active, such blocks would look problematic to the wallets. Some time ago I have already informed certain miners to deactivate the settings, if they're running the old Actinium versions, or to update them. However, there are a few blocks which are valid, but also contain "too much" data so to speak. Therefore I will now create a new variant that accepts those redundant data from the past.

--EDIT 2--
The fix is now available on GitHub, same branch. Please, test if you have time (I hope you didn't run away *lol*) and let me know if it works on your side. Many thanks!
 

What I am saying is, is if -reindex is specified at all, Actiniumd will crash at the same block height posted above. txindex does not matter, on or off it will crash. Sometimes I can get an initial sync to work with it but usually it will crash. After initial sync, any future run of the software even without -reindex (as should normally be done) will crash.

I have tried initial sync with -reindex -txindex, only running -txindex later, it eventually crashes / quits shortly after launch just like before.

Have not compiled Linux version of 0.17.5.0, only macOS and Windows. Thanks for the hint with the shared libs. I will later look into it.

When syncing with -reindex did you use -txindex as well?

--EDIT--
After the first start with -txindex -reindex I later remove -reindex and leave only -txindex.

--EDIT 2--
I've added those missing Libs to Makefile.am so you don't have to type them manually.

Was able to build the Synchronization-Fix tag on my system (with shared libs, had to specify LIBS="-lcap -lcrypto -llzma -lseccomp" with Actinium to build with shared Tor), tested, and it works fine after a sync from network. However any use of reindex will cause it to fail again, or fail initially if specified. I am up and running at the moment, but anything that could cause reindexing (daemon crash or unexpected stop, unexpected system reboot, etc) will trigger this again.

Thanks for looking into this.

EDIT: spoke too soon, after a while it crashed with the same error again, with no corresponding debug entries - just connection logs.

Special Release - Synchronization Fix

This release contains a fix which helps to properly synchronize the chain. Several users have reported Script-Parsing Errors during initial blockchain sync.



https://github.com/Actinium-project/Actinium/releases/tag/Sychronization-Fix

What I could offer you for testing is a separate build, made from a branch that has an extra check for the problematic block (actually, it's the TX in this block that is problematic). I have done some local tests here and although my machines never crash I think it would be of advantage to test what happens when you sync with this alternative build that explicitly overcomes the ASSERTION that provokes the crash.

Please, let me know if you'd like to test it.

---EDIT ---
  Here is the branch "interpreter-fix":
  
https://github.com/Actinium-project/Actinium/tree/interpreter-fix

If you have time, please compile it and let me know if you can sync the chain. Many thanks!

---EDIT 2--
Forgot to mention that the above branch is based on the current 0.17.5.0-BETA which contains built-in Tor. This of course has nothing to do with your problem, but just in case you were wondering why the version number changed. Tor itself is inactive by default. You have to activate it with torenabled=1 in Actinium.conf.

I have just tested it again on a few of my machines and each time I sync the chain. I am sorry, I can't help you in this case.

Done
Done

I understand what a command line argument is, and what Actinium.conf is for; regardless, following the above still results in the same outcome: Actiniumd has crashed

Yes, I don't know how I can be any more clear. I would not be posting saying I have done it for several posts now if it worked.

Our BluePaper is now available!

https://github.com/Actinium-project/BluePaper/raw/master/BluePaper.pdf

The term "weird error" was used because most of our users came with this questions to us, in the Discord. It would be very easy for me to write "Assertion Error in C++ Code - Script Parsing Error - while chain sync".

But, we are not here to discuss how we have to talk to our users. Until now every user that had problems with syncing the chain could solve this problem by following the solution I gave you:

a) delete everything in .actinium folder except your wallet.dat (not even Actinium.conf should remain there).
b) Start the Daemon with the flags -daemon -server -txindex -reindex -port=4334 -rpcport=2300 -rpcuser=user1 -rpcpassword=blah -rpcallowip=127.0.0.1
c) Wait for the sync to complete (you can run tail -f $HOME/.actinium/debug.log to watch the sync)

After the sync completes you can send commands to the daemon with Actinium-cli (this is the reason I wrote extra RPC flags, so you can still command the daemon as there is no Actinium.conf).

Have you executed all steps exactly?

I have started Actinium with no flags, with any flags, with no other config - though this should not matter, ultimately it does not matter, it will always crash / quit at the same point. Upon scan of the chain, once this height is reached, the software crashes. This happens from the bootstrap, from the network, or from my old previously working chain. The software does not remain running. Upon relaunching Actiniumd the same issue will occur. The daemon cannot be used with the active chain.

Debug entries before crash:

The issue with the release notes is the language of "weird error" which does not really reflect an actual error. The error is not weird. It is understandable and that is why I am writing about it here, because I have not developed this coin or worked with any Segwit code.

I know that there is no "click" in daemon. I was simply writing for all possible cases (daemon, GUI).
Also, please, try to start the daemon without Actinium.conf and all the flags set I gave you in the example.
I had the same issue on one of my servers and it helped to sync the chain.
Of course it is a segwit-enabled tag, but as I said, there were mining pools that activated the SegWit option (in their pool software, YIIMP, which has nothing to do with Actinium) and this provoked generation of blocks with a different "magic".

The FAQ is available in the Release Notes, in our Discord, and as a separate Wiki entry. I think this is enough to make the information as broadly available as possible.

Also, there is always a possibility to open an Issue on GitHub.

For the record, there is nothing to "click" here - the daemon Actiniumd crashes, and does not post crash information in debug log. The software is not acting normally, it is crashing / quitting. This is not an annoyance; rather, the software is not functioning at all. Just thought I would further clarify, I thought it was clear in the original bug report.

And again, this is a Segwit-enabled tag, with no existing blockchain. This happens on initial sync. This also happened with an existing chain.

Following your instructions, and the FAQ instructions, poses the same problem: the software still crashes, it is still unusable.

Attempting to load with bootstrap.dat, Actiniumd still continues to crash at 64521 height reliably.

Please see the bug report I posted, and let me know if there is anything further I can try / debug. I am competent and willing, do not fear using technical language or tools.

I did not originally notice any instructions regarding this situation, thus my post. I do see now the FAQ entry "My wallet is crashing with a weird message!" but I did not notice because it was not the error message, I am not expecting to look for "weird message" for this issue. Considering the software will not work with the live chain at all (at least on my platform), this seems serious enough to warrant a larger notification surface than the last "FAQ" entry, or figuring out what anomaly is present here.

Hi,

This problem arises when some participants in the network send malformed blocks, like mining pools that have activated SegWit but still using pre-SegWit versions of Actinium. I have already informed the pools to take care of it. Your node behaves "normally" as it simply refuses to accept defect blocks. However, it can be very annoying to click the warning message boxes away, sometimes a dozen of them.

But there is a solution which you can find in our FAQ (on Github release pages), also in our Wiki, and in our Discord (#support channel).
Basically, you let the wallet sync the chain with a prepared, linearised bootstrap.dat while not using any config file. You only have wallet.dat and the bootstrap.dat in the .actinium folder. Then you start the wallet and let it sync, which will take a few minutes.

Another, maybe simpler alternative is to start the Actinium without Actinium.conf but with all flags appended in the command line, like "-daemon -server -rpcport=2300 -rpcuser=YOUR_USER -rpcpassword=blah -rpcallowip=127.0.0.1 -port=4334 -txindex" and let it sync.

If there are still problems, please, come to our Discord (#support channel).

Regards,

I can no longer run Actinium on Linux amd64. I do not know when this issue started happening, but troubleshooting I have not found a solution.

This happens from fresh blockchain sync around ~55K blocks. Have also tried with new wallet with same issue.

Have tried GCC 6.4 and 7.3. Code from github tag v0.17.4.0.

Problem:
Actiniumd crashes while syncing blockchain

Steps to reproduce

Expected outcome
Actiniumd does not crash

Actual outcome
After a while Actinium crashes with the following error