That's if you receive a ZC before a previous ZC is mined into a block. I'm aware of this issue but it's low on my priority currently.

Consistency checks and DB initialization take place in parallel. On small wallets (what you and I use for our daily Bitcoin needs) the consistency checks are usually fast enough that it may look like the DB is initialized only after the checks are completed. On massive wallets (10k+ addresses), the DB is usually ready before the check are finished


No, it's the contrary. Once all optimizations are implemented (not all of them will make it for this release), fullnode will achieve acceptable speed on pretty much any PC. Supernode is meant for server backends and will be expectedly slow on any PC. Power users with top of the line CPUs, tons of RAM and SSD raids can expect to get supernode to startup within minutes.

That probably happened when we got rid of the option to hide the wallet (which was one of the possible choices on that dialog). I'm looking at the import issue currently.

You're either not looking at the right folder or the backend is stuck on something.

That's a simple UI signaling miss, easy fix.

As for Armory's maintenance routine: the backend polls the blkxxxxx.dat files to detect new blocks. The part of the UI you are looking at (the dashboard) is updated through both reactor signals (polling the socket to the local Core instance, from the Python side) and backend signals. The state you are observing with the disconnected message in the bottom right corner is reactor failing to maintain the socket to Core. However the backend maintenance thread is still running and doesn't care for the socket's state.

In this situation, the dashboard will report you as disconnected, and you won't get ZC transactions in the ledger, but any new transaction with at least 1 confirmation will be properly displayed in the ledger, since the backend maintenance thread is still doing its job.

The simplest way I found to avoid this state is to add addnode=127.0.0.1 to your bitcoin.conf to guarantee Core will reserve a socket for your local instance of Armory.

Actually, it doesn't need to say that in any mode anymore. I'll nuke that dialog.

I'm not sure what you mean by 1. 1-of-1 multisig address? That would be a simple P2PKH. 1-of-N? You would still need the N addresses to either fund the multisig script or redeem the P2SH script. What you have is probably a P2SH address (starts with 3?). What are the underlying addresses? You would have to import their respective private keys to your wallets and create a lockbox from that.


Addresses starting with 3 are P2SH. Does it do it on addresses starting with 1?



This isn't a technical issue, it's more of a feature. You can spend unconfirmed change, that's all. If you want the ability to spend any unconfirmed tx, start a thread, get some users behind the demand, that should get etotheipi's attention.


Lockboxes have backup strings, you're supposed to save that. If you don't have the backup string, you'll have to find the addresses you used for it. The address book dialog used in lockbox creation only displays addresses in use. If you built your lockbox from unused addresses you'll have to go fish for them in each respective wallets properties window (uncheck hide unused) and copy paste the public keys (not the addresses) manually during lockbox creation.


That's part of the new wallets


Same code is used for address and lockbox ledgers, they don't have the same free space as the main ledger.

That should be fixed in upcoming .6


That would be kind of a pain. A much cheaper alternative would be freezing armoryd (the save way ArmoryQt.py turned into an exe with its Python environment on Windows).

New wallets do use master key encryption. Again, all this is possible and implemented... in the new wallets =P. Alas, the issue at hand is with the current wallets.

I would say Windows since this is what I dev on 95% of the time. However, I do test the finalized code on Debian and go through the bug checklist initially identified on Windows during the development phase. I don't directly test other Linux distros nor OSX.


Yes, comments and labels are saved within the relevant wallet file.

Are you using the testing version?

No instructions. We have this Python script that does the whole cross compilation in a couple commands:

https://github.com/etotheipi/BitcoinArmory/blob/0.93-bugfix/r-pi/crosscompile.py

It's currently hardcoded to grab the armhf Python lib packages off of Rasbpian's package repo and grab the x-compiler binaries from R-Pi's git.

Classic msvc to gcc snafu: can't declare methods in .h with the class name prefix in gcc. I was merging a bunch of changes back and forth and didnt check the build on Debian. I'll get it under control.

The reorg itself wouldn't add transactions out of nowhere. As long as the transaction in a out of the main chain, it won't be visible to the user anymore. This can account for transactions appearing then disappearing, although usually the miners on the winning chain would have integrated the same transactions anyways, so the reorg would go entirely unnoticed by the user, since his transaction ledger doesn't change in this case.

There is however the rare case where the original spend was not included in the good chain and that canceled the next transaction as well, so the reorg could explain why the transactions disappeared from the ledger, as they simply disappeared from the blockchain. It looks like these transactions don't pay a fee so it's entirely possible the miners on the good chain ignored the first one.

It doesn't account for transactions the user has no recollection of performing to begin with. Then again if the transaction is the result of moving the same amount of coins out of the wallet then back in within a couple blocks, it looks like a refund or something similar, so I'm not particularly worried.

We currently have good cause the believe our OSX related GUI issues would go away with Qt5. Qt5 would require Python3 and that is desirable on its own. The move the Python3 is expensive but something we eventually need to do. It's more a matter of "when" and priorities than "should we". The move to Qt5 should be rather cheap past that point.

Now, if we get through all of this and OSX is still not behaving, our stance towards this OS could very well change. Our current position hinges on our assumption that a strong solution to the OSX snafu exists, and that there are a lot of other benefits to leverage from that change.


I say whim as opposed to an informed decision, respectful of professional development idioms. Then again, whim is somehow part of their business model. I just don't get why their customers like to get treated that way.


Haha, sure

Not gonna happen. Some of our investors and publicly prominent users run on OSX. And generally, while we'd like to stop supporting some outdated OSes eventually, OSX doesn't fall in that basket and we can't just outright pull the rug.


I know Microsoft deserves a lot of the heat it gets, but that one is a bit harsh. MS has a long history of maintaining backwards compatibility and supporting deprecated calls for... pretty much ever. Also consider that the upcoming Windows 10 still runs on the same kernel (6.x) as Vista. On top of that, maybe 99% of the basic GUI WinAPI calls are shared with kernel 5.x (WinXP and 2k). What's stopping me from running Armory on Win2k is its very lack luster threading API, not the GUI code.

Compared to that, Apple likes to bin certain GUI API calls from a minor version to another. Not playing in the same league at all.

There is something the be said about that. While MS chooses to integrate its GDE its closed source kernel, at least they have the common sense of insuring a lot of backwards compatibility between builds. Apple on the other hand takes an open source kernel without a GDE and instead the proper hooks in place to support any, forces its GDE on it and breaks GUI interoperability mechanics from version to version, on what I can only call a whim.

He answered your question properly, but for further reference, I'll make this a simple yes/no.


Yes


No


Yes

From the timestamp and ledger order it looks like you ultimately received these coins (deposited then withdrawn from an online service? or refunded a purchase maybe?).

If you are indeed using a watching-only wallet with an offline signer, then I do not expect your coins to be in danger. As I said, weird ledger behavior and particularly transactions disappearing is symptomatic of database corruption. However, transactions appearing out of nowhere usually isn't.

If you really can't remember how these coins got to move, maybe you'd like to open a ticket and provide us with more details as to how you came across this issue to begin with:

https://support.bitcoinarmory.com/home

You currently haven't provided enough information to conclude anything. However, we never had a case of stolen coins with offline wallets, and as you can see, those coins came back to you, so I don't think there is too much cause for worry.

If you would regardless prefer to stay on safe side, you can create a new wallet on your offline signer (or a different one if you are really paranoid) and move your coins to that in the mean time

The transaction disappeared from your ledger? Usually a DB corruption. Either rebuild and rescan, or try the test release for the upcoming version

LMDB detects its page size from the OS it is running under, not it's meta data. If the different OS have different page size, it will completely fail to align the meta pages (remember, it's a mapped DB, it does every thing by address and offsets) and corrupt them. Then your DB will go kebab.

That or it could be something entirely different. I'm not 100% familiar with LMDB's code base, more like 70%. And I've also never tried what you suggested. I remember remember doing it with our LevelDB database between Windows Host and Linux client however, and that worked fine. But I also remember that LevelDB will stick to the page size it finds in its meta data regardless of the supporting OS (for having played with the feature), so this is my prime suspect.