My guess is, it's only if Armory tries to open the file for reading during a bitcoin-qt write operation.  The file can be updated all you want after Armory opens it, and it will never be affected by the updates because they are all append operations.  The file will have the same size and content according to Armory regardless of how much data has been added while it is scanning (until I close and reopen it).  So I say 1/1000 because I think a blkfile-write and blkfile-open have to occur at the same time.   The hypothesis is further supported by the fact that I have seen a curious segfault once in the past month similar, and you are the only other report of it (and I open Armory like 50x per day!)

Please let me know if it happens again! 

What you said makes total sense about SatoshiDice... I could see the script misclassifying those bets.  I'll take a look at it a little later, but would rather not clutter this thread with that discussion.  Please PM or reply to the SD thread to talk about it...

P.S.--
It's not like I chose to segfault.  That's not something I have much control over in this case.  If I can prevent phenomenon from happening, then I will try, but I don't have any control over that behavior until I find the precise cause.

Oh, I misunderstood.  I thought you said it used to work and now doesn't.  Sounds like it always works, except for one hard crash recently during loading blockchain.  Is that correct?

In that case, I suspect a very inconveniently timed blk000X.dat update from the Satoshi client may have messed up (reading a partial write).  I always wondered if that would happen, and maybe that's what happened here.  Thus confirming it is possible but rare.

I'm not sure there's a good way to fix it (since Satoshi client always has that file open for writing), and I might just have to take the 1/100 chance of that happening until Armory starts managing its own blockchain file.

Am I understanding you?

The blk0001.dat file just split!    

I've gotten a couple reports similar crashes/freezes, but they have all been users who hadn't upgraded to version 0.81+ which handles the blk file split...  Versions prior to 0.80 will not handle this phenomenon and will crash.

Now, technically the dev branch is 0.81/0.82.  However, it appears that you are using the pre-0.80 blockchain utilities, because when I run the script on that branch unmodified (but with the latest compiled utilities) it crashes later due to blkchain utility calls that are no longer valid in the new code (really, only a couple tiny things).

The first part of the solution is to recompile.  Go into the cppForSwig directory, do a "make swig".

The second part of this is: I updated the sample code to work, by making the following replacements throughout the code:

FROM:
TO:

Additionally, you must replace all calls to "getTxInRef" and "getTxOutRef" with "getTxIn" and "getTxOut". 

I have updated the script in the dev branch, though I suspect you have heavily modified it (based on your satoshidice posts... thanks for keeping that up, btw!).  So I figured you might want to manually update it.  That's all I did just now to modify the script to work with 0.81+ compiled utilities.

Please allow me to share a story with you, about why this seems half-assed.   It's a kind of outlier in Armory's feature set, since most of the other features are very well-developed and stable.

There was high demand for wallet migration just before Bitcoin-Qt 0.6.0.  I implemented it.  It worked.  Flawlessly.  With encrypted wallets, and everything.  I put a lot of time into catching everything that could go wrong: wallets updating mid-migraion, catching duplicate addresses existing in your other wallets, preventing alt-network wallets, and providing notifications and intuitive ways to deal with all of it.  It was a high quality feature.

Then, a month later, the main devs decided to switch to compressed public keys which requires a whole new wallet format for Armory.  I was crushed.   This feature which met all the needs of the users requesting it became basically useless.  However, at the time, most people still were using wallets that were made prior to 0.6.0.  So I added the warning and left the feature in there.

Now it's been many months.  Maybe it's time to remove it, until I update the wallet format.  Most new users will have created their wallets post 0.6.0 so the number of users who benefit from it is small.   But that's why it is the way it is.  And the point has been made that I need to add a warning to the address-import dialog.  So far, you are the first user who has pulled individual keys out of wallet.dat to import (and told me about it). 

I didn't mean to "shift blame".  It's that many users do not recognize the risk of managing addresses from multiple wallets.  They don't realize they could be shooting themselves in the foot.  And on top of it, it's never been something I personally had a use for.  So I was asking to make sure that the users requesting it actually understood it.  Because in the end, supporting this is a a lot of work, and I have a ton of other priorities to balance.

Finally, I had a flurry of nearly identical requests/complaints in the past couple days and I didn't understand why users would say that Armory is "useless" without it.  However, someone posted good information about why this feature is necessary, and I thus conceded.  It will happen.  Although, I am still bothered by the "useless" comment (but the user did say "useless to me", so that's fairly reasonable).

---

For now, if you cannot accept the lack of that feature, then please subscribe to the announcements thread which only triggers notifications on new, final releases (maybe one every few weeks).  When the new wallet format is done, that will surely be announced.

Sorry to be a n00b, but I will use this thread for my own education.  I have never touched Mac/OSX machine in my life.   Just now, I finally got a VM setup that looks like it will work.  But I have no idea where to go...

I got git installed, from what looks like a .dmg file, which opened up in to a .pkg file which actually installed it.  Is this how OSX programs are typically packaged?  If I were to eventually create an installer/uninstaller, what would be the best target format for it?

How am I typically going to install programs and packages in OSX?  Go to website, download some file, double click?  Is there any command-line utility like apt-get for retrieving dependencies?

What is the difference between xcode and brew?  To me, it sounds like to two different flavors of build systems.  I was surprised to find see a lack of google hits for "xcode vs brew", so I suspect they are not simply flavors of the same thing.

Btw, I am running Lion, and plan to compile 64-bit binaries.  I was told that 32-bit OSX is not common at all, is that true?  Can I avoid dealing with 32-bit?  It sounds like what code I compile may not work on 10.4 (Tiger) because of Qt libraries...

Do you think it's possible that Armory could be distributed as a python script like it is in Linux?  It is "installed" by simply copying all the necessary code and binaries into /usr/share/armory, and then the shortcut is just "python /usr/share/armory/ArmoryQt.py".  I say this because I expect issues with creating a real executable out of it (like with the Mac-equiv of py2exe).

I haven't even tried the existing compilation instructions yet.  I'm currently exploring the filesystem structure and how programs work.   I just want to get some base information down about how I'm going to operating in OSX and compiling stuff.

Fair enough.  I just want to make sure that requests are justified for the risks involved.  I think a lot of users want to "import" their Bitcoin-Qt wallets because they don't realize the risks, and don't realize that transferring coins is frequently the safest way to transition to a new wallet, especially for experimenting with Armory.

My own experience is that I have a few payout addresses for my miners.  If I have to change those addresses, oh well.  I didn't realize so many people had such hardened accounts...



I'm making sure that any variable that ever holds private key data is never written to the log-file, even when there's an error.  However, I will serialize all transactions (signed and unsigned) into the logfile.  I was kind of concerned about logging that information, but anyone who has access to your system (and thus the log file) already has access to all the transaction information, so it's redundant information.

If this logic doesn't sound right, please let me know.  I can still adjust the behavior, or at least make it configurable.  I will have a --nologging option to disable it completely..

Fair enough.  I hadn't considered fixed withdrawal addresses.  I mean, they really shouldn't be "fixed", there is a way to change them... but I recognize the inconvenience to the user.  That's in the category of "attached to addresses", but I underestimated the level of "attachment" that some folks have to their Bitcoin-Qt addresses.

On that note, my warning is still valid:

(1) Some keys (like vanitygen, or pre-0.6.0 addresses) can still be imported. Please be careful when doing this.  Locked coins are recoverable, but it's going to be a pain in the ass to fix it.  If you are running in both programs, do not spend from two different programs/wallets using the same address without waiting for a couple confirmations in between.  
(2) Even if you do have an attachment to Bitcoin-Qt addresses, I would not think about migrating unless you are ready to go 100%.  I recommend creating a new Armory wallet, send it some coins, and experiment with that.  At some point, you may decide it's worth the effort to change receiving addresses (email people, change service settings, etc) to use your new wallet.  Because 0.6.X support just cannot happen in the next month or two...

First of all, it's going to be a little while.  I need a new wallet format.  Read a few messages back in this thread for more info.

Second of all, why is this such a dealbreaker for folks?  I'm not looking down on anyone for this, I just don't understand why this feature is so critical -- in fact, it's going to cause so many problems for people I don't even want to do it.  Bitcoin-Qt is especially not suited for multiple programs using the same addresses at the same time -- users will end up with locked coins and incorrect balances and it's really difficult to fix.

(1) Even if you can import your whole bitcoin-qt wallet, only the exact addresses you import will be useful.  All new addresses produced by Armory and Bitcoin-qt will be different.  This is one reason that, if you are going to import any Bitcoin-qt addresses, you should import all of them and then remove the wallet from Bitcoin-qt.
(2) If you're dealing with Vanitygen addresses:  those are in the correct format already, so there's not problem there.
(3) If you're not sure yet whether you want to make the move, then you shouldn't be migrating anything.  Please just create a new Armory wallet and move some/all of your coins to it.  Move them back if you don't like Armory.  So much heartache can be avoided this way.

I know that some people are attached to some of their addresses and that's why some people must have a migration feature.  And some users want to be able to migrate your keys from an offline wallet without bringing it online.  Those are two reasons that wallet migration should be a dealbreaker, but I thought it was a small percentage of users.  What other reasons are there?

I am seriously frustrated, because I feel like migration feature is going to cause endless heartache and customer-support issues (locked coins are always a crisis).  I just want to know why people are requesting this feature, and make sure that users who actually should not be using the migrate feature anyway, aren't passing up Armory because it's not there.    (it sounds like I'm going to have to add all sorts of warnings to the program, akin to what I just warned in this post)

@ Gladamas

FYI, my Win7-64bit VM with 2GB of RAM and Bitcoin-Qt 0.6.3 has had Armory open for 2 days and has not crashed yet.  So, unless there is a specific trigger someone can point me to, I'm going to have to let this bug through for now.  Please let me know more details about the crashing, and hopefully I'll find a way to replicate it in the future.

However, I'm very close to a 0.82.1 version with full logging.  This will improve the situation a lot, since every crash can now be accompanied by a full log file of every informational message and error message, without the user even doing anything.   I will hopefully have that out tonight, and those of you experiencing crashes will only have to send me your armorylog.txt file after the crash.

@ kuzetsa

Are you waiting for address migration to try out Armory at all?  I highly recommend, even if migration was working, that you still create new addresses and send coins to them instead of importing just a couple addresses.  When you "migrate" addresses to Armory, you should really stop using those addresses in bitcoin-qt.  It really needs to be all-or-nothing.  This will avoid lots of issues with maintaining the same address in multiple programs (coins can get locked, and balances will be incorrect in both programs).  This is not an Armory limitation, it's an issue with Bitcoin-Qt which assumes no other program is using the same addresses.

Until then, you should create a new Armory wallet, send some coins to it, and if you want to go back, just send the coins back to your Bitcoin-Qt wallet.

I forgot we were talking about brainwallets (or at least one aspect of them).  Towards this purpose, Armory is not the best-suited tool.  I was more targeting the offline-wallet management use-case, in which case you expect to have the data on a hard-drive or USB key (encrypted of course), it just won't ever touch the internet. 

However, Armory could be great for this if I made brainwallets easier.  I'm hesitant to do that, though... but that's another discussion.  However, the gist is still possible:  you boot into your live session, and "restore from paper backup", and you use your brain-wallet passphrase to "restore" your brainwallet.  It will create a wallet and all the addresses with it in a "file", but since it's a live session, that file is in RAM and will disappear along with the power.   You'll have to make a watching-only copy of this ethereal wallet to be transferred to the online computer.  But once you have that, you have full control from online Armory: maintaining balances, confirming incoming payments, constructing transactions, etc.

So it is very possible, you just have to have an extra utility on the offline system to convert your brainphrase to an Armory wallet seed.

And btw, nothing sensitive ever touches the USB key that is used to shuttle transaction data for signing.

Just for reference, the requirements to run Armory on an offline computer are basically nil.  You don't need the blockchain, you don't need Bitcoin-Qt/bitcoind.  You only need to install the library dependencies, which are all conveniently packaged with the Linux installer on the downloads page (use Armory_0.77_Offline_ALL_Ubuntu_10.04-32bit.zip).  I run this on an ancient laptop with a 1.6 GHz proc and 512 MB of RAM.  It runs fine.

However, using it on the online computer is not so lightweight.  Armory 0.81+ will use about 600 MB RAM on the online computer.  But you already have Bitcoin-Qt/bitcoind installed and running there and the blockchain file is auto-detected, so there's really nothing else to do except make sure it's running.  (btw, any version of Armory can be installed on the offline computer, regardless of the version on the online computer)

Once you have it, all this command-line stuff becomes completely unnecessary.  Blockchain.info/blockexplorer are unnecessary.  Downloading necessary transaction data is done by Armory on the online computer, from the Bitcoin network directly and it's completely automated.  Just get a USB key and the rest is point-and-click.  There is [a lot] more information in the Using offline wallets in Armory tutorial.

I know this thread is about not using Armory for this.  But I want to make sure that your desire not to use Armory isn't due to misunderstandings about how it works.  Really, I'm not sure if offline transactions can get any simpler, and any computer that boots can be used for the offline system.  The only bottleneck is the online system.

I have a completely new wallet format in the works that will be able to support these private keys.  It will have a plethora of other advantages (such as, it was developed by the Bitcoin-Qt devs to go into version 0.8.0 or something, so Armory will be natively compatible).  However, this new format is going to take a while, because Armory  wallet-handling code requires the utmost stability, and it requires testing up the wazoo.  It may be a couple months before I can actually finish the implementation and confirm its stability. 

And even if I wanted to make it highest priority right now, I also have to wait until the Bitcoin-Qt devs agree on the precise specification for the wallet algorithms, and I don't think that's been done yet.  That's a variable I can't really control.  And it is way too much work to re-do the wallet format just for compressed public keys.

So... I wouldn't hold your breath     

Oh, I need to add a warning about this.  Private keys from Bitcoin-Qt version 0.6.0 and newer cannot be imported into Armory!.  It's because they use "compressed public keys" which Armory doesn't support yet.  I suspect that the key you tried to import was one of these compressed keys.

There is a warning about that when you try to migrate your entire Bitcoin-Qt wallet, and I need to add one here.  I forgot that some users manually pull private keys out of their Bitcoin-Qt wallet...

For now you'll just have to wait for compressed public key support (might be a couple months), or just create a new address in Armory and send some funds to it.  I recommend that anyway, because sharing private keys between apps can cause all sorts of weird problems...

Sorry for the inconvenience!

Do you mean, "when Armory is getting ready to crash, it no longer shows any new transactions until you restart?"   Someone else was able to get some debugging output for me that is useful.  It sounds like the crashes may be related (his crash definitely would cause the same behavior).    Please post more info if you get any more.  I need to crash my own Armory instance!

So I loaded Armory in my Win7-64bit VM with 2GB of RAM in online mode.  I executed one transaction, then went to my development desktop and forgot about it.  7 hours later, no crash.   Anyone who is experiencing this crash have any hints about what I can do to trigger it?  Are you doing anything before it crashes?  This is going to be a tough bug without any way to replicate it!

This is the not the first report of this behavior, so this must be a real bug in the software.  But it must be a Windows thing, because I've had 0.81 open in Linux for days without issue.

Unfortunately, these types of crash reports are really not very useful.  I really need the console output from Armory to be able to figure out what happened (which is not available without running Armory from the console).  As such, I'm currently implementing a proper logging system, to go into ... 0.82?  Probably 0.82.1.  Then when Armory crashes, there will be an armorylog.txt file that you can send me.  I've been procrastinating on this for months, but now I think it's finally time to do it. 

While I work on updating 20k lines of python code with proper logging calls, I'll load up Armory in my Windows VM and leave it running to see if I can replicate the behavior in the debugger. 

Hey, at least it works for a couple hours before crashing!  It's obviously not convenient, but it sounds like you still have access to all the features...

Glad to see folks like the new features

Version 0.80 was a reworking of the underlying blockchain engine, whereby I had to change some of the interfaces slightly to be more scalable.  As such, "TxRef" objects are mainly just pointers to blk000X.dat file locations.  All the methods are now part of "Tx" objects which are copies of the tx-data.   As such, the following code needs to change

FROM


TO



And I notice you are tracking my address in your example...

You're getting ahead of yourself.  You're looking at the forward compatibility section that helps URI handlers recognize that they are outdated.  The issue here is about what programs handle basic URIs and how do they handle them.

It's funny that the Bitcoin-Qt devs were part of the BIP 21 process, and apparently even implemented BIP 21 in Bitcoin-Qt, but disabled registering it with the OS for reasons I don't remember.  As such, it's only supported by these alternative clients, but it is compatible between them because of BIP 21.  And when Bitcoin-Qt enables it, it should then be a universal functionality.

However, I took into account that even when it is widely supported, it won't be 100%.  That's why I added the line: "Use the following payment information if the link does not work on your system", and included the info as plaintext, so that it would accommodate all users.  Even if their program supports links, they probably would like to glance at the payment info before switching to their Bitcoin app.

I had ideas to expand BIP 21 to support message signing, too, and that could be a separate BIP (so someone can say, "This merchandise was purchased using funds from address 1xYzQ3, please send your shipping address signed by that address").  But that's another topic altogether...

---

@ Molecular:

The change-address-behavior was inspired mostly by you (but there have been other requests made).  The idea was that you can select to have change sent back to one of the input addresses, and then it will save that setting for future transactions so that you don't have to think about it after the first time.  This means that if your wallet is made up of imported addresses, no new addresses will be created for change -- it will be recycled back into the imported addresses.  I think that should solve the use case 100%.  Please let me know if something is missing or not right about it...

Armory 0.82-alpha Testing Release!

No joke: Tons of new features and polishing!  After having spent so much time on the new blockchain engine, it was time to do some serious feel-good upgrades.

• URI Creator:  Screenshot in the previous post -- right click on an address in your address book, or press "Create Clickable Link" when you get a new address (in the "Receive Coins" window).  This should give you everything you need to email payment requests to others, or post payment information on webpages.
• Minimize-to-system-tray:  The file menu now has a "Minimize" option, and you can now set it to minimize-by-default when you click the "x" on the top window bar.
• New "MAX" button:  One button for each recipient in the send-bitcoins dialog.  It takes your spendable balance, subtracts the amount filled out for other recipients and subtracts the specified tx fee, then puts that value in for the current recipient.  Useful for sweeping a wallet without typing in 8 decimal places, or a variety of other uses...  
• Specify change address:  (Expert Mode Only!)  This legitimately deserves to be in Expert mode and not Adv mode.  I have spent a ton of time polishing the interaction of these options and making sure that it has memory between tx and between loads.  I think it's pretty solid!
• Lots of polishing:  Nothing in particular, but I was testing lots of features, and spent some time figuring out better ways for some dialogs to interact with the user.  Hopefully it just feels better

Please help test!  Please PM or email your email address if you want to help test and haven't already (you can still test based on these posts, I just want to know who/how many people are actively helping)

Download:  (remember, these are just testing releases)

• v0.82 for Win64
• v0.82 for Win32
• v0.82 for Linux64
• v0.82 for Linux32

For those that are compiling from source, the testing version is on the "dev" branch.

It's the magic bytes for the main network isn't it?  "f9beb4d9"

EDIT:  nm, I was rushing to get the right answer and thought I saw pieces of the magic number.  But now that I actually see all possible rotations of the string, I'm not seeing the magic number...

But that wouldn't be a bad 4 bytes to use...