Thanks for bringing this up to me via PM, utahjohn.

I originally said that whatever returned after using uname -a was fine because we were talking about Raspberry Pis (1 and 2) and the makefile supports both armv6l and armv7l (which are actually identical). It's just not working with any of the previous architecture commands because of the 64-bit OS (see below).


It looks like you guys in the thread have already figured it out: someone will need to write a scrypt-aarch64.S file for everything to work smoothly.

Alternatively, I could probably have the wallet fall back to a C++ implementation on unsupported architectures. It would just need to be transparent to the users that their architecture does not perform as well as it might with its own assembly implementation. (That is to say that the performance would be really bad compared to a native solution.)

Speaking of performance hits, though, I'm pretty sure one could the ARM version of QEMU to run a 32-bit binary if you just want to run the wallet on an arm64 board. At least until a more robust solution is found. A guide for setting QEMU up on a Raspberry Pi can be found here, but I'm not sure how well that translates to ODROID's boards. You might have to set up ODROID's boards for virtualization (if they support it) and compile QEMU yourself to get things working.

Ah, yeah, I should have made sure that make all built the libraries and the tests, rather than just the tests.

That being said, is Qt Creator linking the leveldb and boost libraries properly? I've never used Qt Creator because command line compilation is just: qmake && make . But, from your pastebin, it looks like it can't find leveldb or boost... so perhaps making sure Qt Creator knows where the libraries are is the answer.

Because leveldb is part of the sources.

To answer the original question, it looks like QT Creator isn't compiling leveldb for you, so it's probably easiest to pop open your terminal, navigate to vertcoin/src/leveldb, and run a make all.

Basically, Bootstrap.dat allows you to import a portion of the blockchain incredibly quickly by bypassing the peer downloading requirement. It's essentially identical to someone posting their copy of the blockchain for you to download. When all the blocks are "bootstrapped" in, your client continues downloading blocks (newer than those in the bootstrap file) from peers as it normally would.

For a slightly more in-depth explanation, here's the Litecoin wiki page for Bootstrap.dat.

According to their thread:

I feel like this would appeal to a fairly small market. In my mind, dolls and clothing and whatnot work out for established brands because they are based on an already popular franchise (as you see with TV/movie -> toy/game/clothing line transitions). Coming into it with just the idea that it exists is probably not going to bring in any significant income.

So... If you want to make something out of your idea, I would suggest creating enjoyable content and publicizing that before monetizing it.

Since no one has given more helpful advice, have you tried the "Run as Administrator" option from the context (right-click) menu?

There are a couple of extra v's floating around in this: cryptcash.conf.

You may be able to stake, but syncing from zero still orphans every block, from what I can see. (http://pastebin.com/9u9RzXeG)

Also, there's an issue with main.h under Linux because G++ is angry about a lack of parentheses around one of the if statements' arguments. (main.h, line 693)

You're using Git... I've always wondered why you don't fiddle in a testing branch. Grab yourself a group for testing on testnet and fiddle there, perhaps?

One of the reasons the Qt wallet doesn't compile on Linux is because Niitassin undid one of the changes that I made to the Qt pro file. No idea why. The other reason is that he didn't include hamsi_helper.c. I think I have that version compiling, but I'm going to do a clean build after I make sure it's not going to implode as is.

I haven't looked at the headless wallet yet, but I'll check it out after I'm done with the Qt clean build (as long as the logs look good).

Edit: the logs don't look good. He changed something that makes all previous blocks appear to be orphaned.

Edit 2: I can't even figure out what the bad change was because Niitassin's important commits changed far too many things at the same time for me to make sense of them. So I'm not going to waste my time trying to fix this - I'm calling it dead.

Just looking at the device they're selling... I think it *is* a Raspberry Pi. The outputs are identical to my B+ model. So it looks like they're just adding a case with a sticker on it and some (probably) open source software on top.

This is correct - I just checked the code because I believe it's unfair ask someone to run a masternode without compensation.

There is currently code to pay masternodes in GetProofOfStakeReward() and none in GetProofOfWorkReward(). This means that until POS is fixed, no masternodes will be paid.

Edit:
Actually, looking into spork.cpp, it looks like masternodes wouldn't be paid anyway because CBlock::CheckBlock() in main.cpp sends IsSporkActive() the defines SPORK_1_MASTERNODE_PAYMENTS_ENFORCEMENT_DEFAULT and SPORK_1_MASTERNODE_PAYMENTS_ENFORCEMENT. Looking into those, (SPORK_1_MASTERNODE_PAYMENTS_ENFORCEMENT  = 10000) and (SPORK_1_MASTERNODE_PAYMENTS_ENFORCEMENT_DEFAULT = 2428537599).

Because IsSporkActive() translates the former into the latter, we're really just looking at SPORK_1_MASTERNODE_PAYMENTS_ENFORCEMENT_DEFAULT. I think. I could be wrong.

If that is indeed the case, the wallet is comparing the current date against the "default" masternode UTC timecode to determine if masternodes should be started. Common sense says "check the comment to see what date that is". The comment suggests "2015-4-8 23:59:59 GMT". However, if you actually check the value, 2428537599 = Sun, 16 Dec 2046 01:46:39 GMT.

I don't really want to spend too much time looking into this issue, but if fixing POS doesn't fix masternodes, this is a great place to check.

This can probably be resolved by running litecoind with the -rescan option. Possibly the Qt version as well, but I'm not sure if that works.

Might want to make a backup of your wallet.dat beforehand as well, just to be safe.

You already received a Proof of Burn reward (CJgPhnUu8D4ruJp4UoakAWE7d44wgsDYND - 148620.0).
Niitassin clearly stated you are only allowed one burn in his rules: 1) You are only allowed to do it one request.
So I don't think he will send you anything else.

Edit: your sent amount isn't a multiple of 5 either, which he stated is necessary.

No, your client looks like it has a memory leak. Check to make sure you're calling delete for staking-relevant dynamic allocations.

Also, SeedBit's wallet works for staking without annihilating RAM, so it's probably not Quark's fault.

std::bad_alloc usually indicates a memory overflow or that, somewhere, an iterator is trying to access an element outside of a container's index. It'll take quite a while to debug without other information. The debug log might help, but running cryptcashd through gdb and posting the information you get when it fails will definitely do some good.

If you really want to email him directly, he has an email address listed on GitHub.

He says 24 hours in the thread he made about Proof of Burn. So I'd assume sometime within 24 hours.

However, Taiga, you've sent in three separate PoB attempts which is against the rules. You should probably PM niitassin to take care of that.

Just FYI, your total coin supply of 1 Trillion coins causes an integer overflow "like a boss" on line 85 of main.h.

And to anyone compiling on Linux, it's Qt5. export QT_SELECT=qt5 is your friend unless it's your default version already.

Aside from that, Qt and headless compile on Linux (with only a few changes), which is nice. Anyone using Windows that wants a headless wallet, though, is out of luck because there's no makefile.

Edit: Ctgiant beat me to the overflow warning, but, yeah, you should take care of that.