First of all, 0.96.0.4 does not build on OSX cause of some 1 line of code issue. That's been fixed in testing, but testing doesn't build atm cause reasons.

As for getting through autoconf, right now it's laying out the stuff packages you are missing. You may want to check with other OSX users how to deal with those. These checks should pass on OSX.

https://github.com/goatpig/BitcoinArmory/blob/testing/cppForSwig/cryptopp/Makefile.am#L15

That stuff is completely disabled on OSX. This ought to be something else. Building yourself is always preferable at any rate, autotools should make that more accessible.

You can update to 0.14.2

.

tag 0.96.0.4 is broken on OSX. That's been in testing but testing is broken atm for other reasons, so you'll have to wait.


That shouldn't not matter, none of these ASM optimizations are enabled on the OSX builds.


The changelog in testing, but I have not updated it in a while. Crawl the commit history comments if you want to get an idea.

~/.armory

I do plan on pushing out an offline package for 0.96.1 if it's what you are referring to.

It's failing to see new blocks. You need 0.96.0.4 for the fix. Otherwise, rebuild & rescan.

What build are you using?

You are better off sweeping the funds than importing.

The most efficient way forward is to create a short term wallet, import the private keys into that, sync it then move the coins out on a low fee/during low traffic. This way you keep the private keys offline while side stepping the priority fee rake. You can even RBF with this setup (allows you to start on a really low fee and increment as needed).

The sweeping interface is too streamlined to allow for this level of control, and it would require you to expose the private keys to the online machine to begin with.

Once this all done, you can get rid of the short term wallet.

You are getting outright crashes, you should build the binaries against your actual hardware, that would at least isolate the issue somewhat. If it persist, you can then debug build and show me the traceback of the actual crash.

Be careful not to mix several blockchain folders against the same DB. The DB is tied to the block files layout and that's an easy way to corrupt it.

Your offline machine only needs Armory.


Depends what OS your offline signer runs. If it's Windows or OSX, you only need the respective release package. For Linux, you will need to install the dependencies as well. The 0.93 offline packages have that stuff in there, so you could look at these.

Try with your own build.

Are you pointing your Node to different blockchain folders?

No idea. Are you building the binaries yourself?

If you still don't see your balance, post your logs again.

It means it does not maintain the dataset to resolve arbitrary tx hashes. On the GUI side that means you can't input tx nor fee of incoming transactions (people paying you). This is the state 0.94 was in.


Well yes and no. You can keep on using this DB type but due to a mess up on my end, you have to specify the --db-type on each run. I fixed that issue but there's no build out with it yet. You're not supposed to be able to swap types once a DB is instantiated, but again, I messed up the check.

If you don't specify it, it will corrupt the DB on the next run. You can use armoryqt.conf to force that arg for now. Once the fix goes into the next build, you won't have to worry about the arg after bootstrapping.


I can't tell. Clearly there is an issue that only exists with slow/old machines, since I never run into it, and all cases I can remember like yours are on old/weak machines. For now there seems to be a critical point at which a machine is too aged/weak and can't bootstrap the DB off of defaults. Until the point I figure out what's going on, you are stuck with using custom settings. What you ran is basically the fail safe setting.

I don't think the issue is related to block size but rather block load. Smaller blocks with lighter transactions (up around block #350k) are easy enough to parse. It's the recent stuff that's grinding some machines to a halt. Seeing you eventually got past it, I'm gonna guess your machine can keep on going.


False positives. A bunch of debug verbose I left there cause people on OSX are complaining about slow shutdowns. This helps me figure out what's going on. Ignore on anything but OSX.

I want you to run only the DB. Do not run the GUI nor your node.

No, I want you to only run the DB, GUI or Core.

Yes.

Try again from the top with --thread-count=2