Armory - Discussion Thread

[jim618]

Congratulations on your engagement Alan !

:-)

I can imagine on the wedding invite:
      All wedding presents to be AES encrypted using scrypt as the KDF and a password with at least 200 bits of entropy

[1713940058]

1713940058

[1713940058]

1713940058

[wachtwoord]

Congratulations on your engagement Alan !

This. Congrats dude!

[ragnard]

I just installed 0.82.2 and, after encountering, and fixing, the error with connecting to bitcoin-qt which is running via TOR, I succesfully launched Armory Client.  I am running Win7 x86 on Virtual Box.  It took Armory quite some time to load up, as indicated on the Armory website.  Once it launched, it says it is Connected but only (117519 blocks).  There are currently over 195,000 blocks.  So, I sent a test .05 BTC from my main wallet (not in Armory) to the newly created wallet in Armory.  It came through nearly immediately.

I was still concerned with Armory still only showing 117519 blocks, so I closed it and rebooted Windows.  Now that everything is back up and running (bitcoin-qt and Armory), Armory still only shows 117519 blocks and my wallet balance is 0.  What happened to that .05 BTC?

Also, Armory somewhat regularly locks at 90-100% CPU usage for a minute or two.  Windows says it is Not Responding, but if I wait the couple minutes it comes back to life only to do it again later.

Unfortunately, I can't comment on how Armory behaves behind proxies and/or Tor.  However, if it stops loading at the same block every time, my guess is it's reading an old blk0001.dat file, and actually has nothing to do with the proxy.  Do you keep your bitcoind/-qt datadir somewhere other than the default location?  If I had to guess, I'd say you used to have bitcoin-qt in the default location, and later moved it out. 

If so, use the " --satoshi-datadir=/path/to/bitcoinqt/homedir" to tell Armory where to find it.  This is because Armory requires the blk000X.dat files created by the currently-running version of bitcoin-qt. 

The transaction showed up in Armory because it saw the zero-confirmation tx forwarded by bitcoind.  But it will never see it enter the blockchain, because it's stuck on block 117,519, and obviously your tx is going to enter the blockchain much later than that.

Yeah, if Armory could specify the port it uses to connect to bitcoin-qt, I think we could continue to use Tor and Armory.  Anyway, that wasn't the cause of my problem.  I hadn't changed the datadir, but it looks like my blkxxxx.dat files must have been corrupt.  I wiped out my datadir, redownloaded the whole blockchain (what a PITA!!) and now Armory comes up Online with the correct number of blocks.  And, it shows my 0.05 BTC balance.  Now I can start digging into this app.  So far, it looks very impressive.

[etotheipi]

Yeah, if Armory could specify the port it uses to connect to bitcoin-qt, I think we could continue to use Tor and Armory.  Anyway, that wasn't the cause of my problem.  I hadn't changed the datadir, but it looks like my blkxxxx.dat files must have been corrupt.  I wiped out my datadir, redownloaded the whole blockchain (what a PITA!!) and now Armory comes up Online with the correct number of blocks.  And, it shows my 0.05 BTC balance.  Now I can start digging into this app.  So far, it looks very impressive.

I've already added a " --satoshi-port=X" option to the command-line arguments.  It's in one of my development branches and will be part of the next release.  Please PM/email/post any feedback you have about the program.  I'm always interested in how people are using it and what could be improved.

Update: I've got most of the code-reshaping done.  Armory will now readily switch between online, offline, and rescanning modes, and will start up immediately in rescanning mode (also will go into rescan mode when you import wallets or addresses).  Appropriate functionality will be enabled or disabled based on the mode. 

I shouldn't be bragging about it until I finish implementation, but I'm pretty excited about it.  Usability will improve by one order of magnitude! 

[runeks]

Armory will open immediately and operate like offline mode while the blockchain data is loading.  Then switch to online mode when it's done.  I already have a proof-of-concept for this, I just need to redesign some of the interface to accommodate mixed-online-offline mode.

This is perfect! Splash screens are a strange concept, I think. It definitely adds to the user experience to see the user interface as soon as possible.

One thing you could do when the app shows up immediately, but hasn't loaded the block chain, is disable (grey out) all the items in the GUI that show information that hasn't been loaded yet, and then superimpose some sort of animation on top of it. I like this type of animation (but maybe that's just because I'm used to Linux):

Animations, in my opinion, lets the user know that something is going on, and, coupled with a time estimate, it will provide a greater user experience. I already think your client has the best GUI of all clients, and this would really add to it.

On a different note: how is it going with making Armory independant of the Satoshi client? I remember you mentioned something about it being a lot of work. I guess the better solution would be for the Satoshi client-developers to separate out the protocol-specific functionality into a library, so other clients can use it. Developing your own implementation seems like a waste of time, if you ask me (although it might be an interesting/fun experience).
Do you know if the developers have any plans on doing this? Separating out the protocol implementation from the GUI of the Satoshi client? I think this would really spur development of alternative clients, including yours.

[etotheipi]

Armory will open immediately and operate like offline mode while the blockchain data is loading.  Then switch to online mode when it's done.  I already have a proof-of-concept for this, I just need to redesign some of the interface to accommodate mixed-online-offline mode.

This is perfect! Splash screens are a strange concept, I think. It definitely adds to the user experience to see the user interface as soon as possible.

One thing you could do when the app shows up immediately, but hasn't loaded the block chain, is disable (grey out) all the items in the GUI that show information that hasn't been loaded yet, and then superimpose some sort of animation on top of it. I like this type of animation (but maybe that's just because I'm used to Linux):
...
Animations, in my opinion, lets the user know that something is going on, and, coupled with a time estimate, it will provide a greater user experience. I already think your client has the best GUI of all clients, and this would really add to it.

On a different note: how is it going with making Armory independant of the Satoshi client? I remember you mentioned something about it being a lot of work. I guess the better solution would be for the Satoshi client-developers to separate out the protocol-specific functionality into a library, so other clients can use it. Developing your own implementation seems like a waste of time, if you ask me (although it might be an interesting/fun experience).
Do you know if the developers have any plans on doing this? Separating out the protocol implementation from the GUI of the Satoshi client? I think this would really spur development of alternative clients, including yours.

I'll look into doing some kind of animation.  I was actually thinking I'd have a progress bar, based on MB of blockchain read so far, but the C++ code would need some modification to make that work (currently a C++ black box that python has no internal access to).

I just talked to gmaxwell today about this very topic (networking&validation engine).  I really don't want to reimplement that part of the protocol and was hoping that I could cannibalize pieces of the bitcoind library.  gmaxwell suggested that they are considering doing something similar with bitcoin-qt:  abstract out the wallet from everything else, and have a lite-weight daemon running in the background for any wallet application to use (via sockets and RPC).  I have a tough time believing they'll be able to get the non-wallet pieces of it to be "light-weight" enough that people won't complain... but if it is that could great for all developers.  I'm envisioning it would be like like the .NET libraries:  it's a prerequisite that needs to be installed for other Bitcoin apps to functions -- users will grumble about it, but they'll do it and then forget about it once everything is working.  

For now, I'm going to work on a better loading experience, OSX support, and update wallets to support multi-sig, compressed keys, branched wallets, etc.  I think that will add more value right now than independent networking -- and maybe this landscape will look a little easier by that time

[runeks]

I just talked to gmaxwell today about this very topic (networking&validation engine).  I really don't want to reimplement that part of the protocol and was hoping that I could cannibalize pieces of the bitcoind library.  gmaxwell suggested that they are considering doing something similar with bitcoin-qt:  abstract out the wallet from everything else, and have a lite-weight daemon running in the background for any wallet application to use (via sockets and RPC).

This is really good news. I actually think this is one of the most important projects for bitcoin-qt at all. Developers who are good at writing protocols are generally fairly poor at writing UIs. If this comes true, it won't take long before someone writes a Python wrapper around these libraries. And Ruby, and Perl, and Haskell etc.

I have a tough time believing they'll be able to get the non-wallet pieces of it to be "light-weight" enough that people won't complain... but if it is that could great for all developers.  I'm envisioning it would be like like the .NET libraries:  it's a prerequisite that needs to be installed for other Bitcoin apps to functions -- users will grumble about it, but they'll do it and then forget about it once everything is working.

One step at a time .
I imagine the first separation of GUI and protocol will be somewhat messy, but it's a start. I think it would be a good idea to further separate the various libraries after the initial, rough separation. Ie. remove the hard dependency on, for example, RPC, and implement this in a separate module that is part of bitcoin-qt. If this is done with all the performance-critical dependencies, I imagine we could get a quite fast library to work with. It will take time, of course, but it's really nice to see the first steps being taken.
Far down the road, the transaction verification module - for example - could be separate, and someone proficient in Haskell could write a replacement for this, that automatically can scale to multiple cores.

[ErebusBat]

I attempted to follow the OSX build instructions on the site; however I keep getting an odd error:

Code:

Generating wrappers...
BlockUtils.h:326: Warning 472: Overloaded method AddressBookEntry::AddressBookEntry(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:414: Warning 509: Overloaded method BtcAddress::addTxIO(TxIOPair &) effectively ignored,
BlockUtils.h:413: Warning 509: as it is shadowed by BtcAddress::addTxIO(TxIOPair *).
BlockUtils.h:413: Warning 509: Overloaded method BtcAddress::addTxIO(TxIOPair *,bool) effectively ignored,
BlockUtils.h:414: Warning 509: as it is shadowed by BtcAddress::addTxIO(TxIOPair &,bool).
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BtcUtils.h:956: Warning 472: Overloaded method BtcUtils::verifyProofOfWork(BinaryDataRef,BinaryDataRef) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
g++  -I"/usr/include/python`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`" -c -O2 -pipe -fPIC  -Icryptopp -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS  -lpthread  CppBlockUtils_wrap.cxx
In file included from /usr/include/python2.7/Python.h:126,
                 from CppBlockUtils_wrap.cxx:150:
/usr/include/python2.7/modsupport.h:27: warning: ‘PyArg_ParseTuple’ is an unrecognized format function type
i686-apple-darwin11-llvm-g++-4.2: -lpthread: linker input file unused because linking not done
g++ -shared -lpthread  UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a "/usr/lib/libpython`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`.a" CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
i686-apple-darwin11-llvm-g++-4.2: /usr/lib/libpython2.7.a: No such file or directory
make: *** [swig] Error 1
╭─aburns@aab  ~/src/bitcoin/BitcoinArmory/cppForSwig ‹› ‹master› 
╰─[12:29:34]$ ls -lh /usr/lib/libpython2.7*                                                                                                      1 ↵ 
lrwxr-xr-x  1 root  wheel    65B Aug 25 12:27 /usr/lib/libpython2.7.a -> usr/local/Cellar/python/2.7.3/lib/python2.7/config/libpython2.7.a
lrwxr-xr-x  1 root  wheel    53B Aug 24 20:59 /usr/lib/libpython2.7.dylib -> /usr/local/Cellar/python/2.7.3/lib/libpython2.7.dylib
lrwxr-xr-x  1 root  wheel    68B Aug 22  2011 /usr/lib/libpython2.7.dylib.orig -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/Python
╭─aburns@aab  ~/src/bitcoin/BitcoinArmory/cppForSwig ‹› ‹master› 
╰─[12:29:35]$ 

As you can see libpython2.7.a does indeed exist (although I had to manually symlink it).

My gut feeling is that it has something to do with the PyArg_ParseTuple erro, but I do not have the skills to troubleshoot this.

Thanks.

[etotheipi]

I attempted to follow the OSX build instructions on the site; however I keep getting an odd error:

Code:

...
i686-apple-darwin11-llvm-g++-4.2: /usr/lib/libpython2.7.a: No such file or directory
...

As you can see libpython2.7.a does indeed exist (although I had to manually symlink it).

My gut feeling is that it has something to do with the PyArg_ParseTuple erro, but I do not have the skills to troubleshoot this.

Thanks.

I may not be much help here.  I just wanted to add a frustrating lesson I learned recently that made me think I was going insane:  I was trying to execute a binary file that very obviously existed.  Asked a Linux guru of mine about the issue, and he did all sorts of tracing on the error and discovered it was an architecture thing -- I was trying to run a 32-bit binary on a system that had only 64-bit libraries installed.  The "No such file or directory" error was actually referring to the absence of the 32-bit glibc binaries needed to run the 32-bit app.

[Lumpy]

I'm new to Armory, but been watching it for a while.  I have a "Brainwallet" savings address based on a very long password. I'm having trouble figuring out how to make it work in a watching-only wallet. What I want to do is import only the PUBLIC key into Armory without exposing the private key. I originally generated the private key on a non-networked boot of Ubuntu Privacy Remix and it has never been used on a networked computer. Now it seems my current options are:

1) Boot my computer into non-networked Linux to generate the Armory wallet (but I would have to go online to download libraries and build from source).
2) Boot my computer into my normal Windows install without networking to generate the Armory wallet (but I strongly distrust Windows and the security of doing this).
3) Boot some other non-networked Windows install to generate the Armory wallet and wipe the disk (but I have no such "expendable" installations on hand).

So is there a better way to do this? With Electrum I was able to import a "junk" keypair and then replace the public key only with my savings address to accomplish the same thing. However, it looks like the Armory wallet format is not human readable.

[etotheipi]

I'm new to Armory, but been watching it for a while.  I have a "Brainwallet" savings address based on a very long password. I'm having trouble figuring out how to make it work in a watching-only wallet. What I want to do is import only the PUBLIC key into Armory without exposing the private key. I originally generated the private key on a non-networked boot of Ubuntu Privacy Remix and it has never been used on a networked computer. Now it seems my current options are:

1) Boot my computer into non-networked Linux to generate the Armory wallet (but I would have to go online to download libraries and build from source).
2) Boot my computer into my normal Windows install without networking to generate the Armory wallet (but I strongly distrust Windows and the security of doing this).
3) Boot some other non-networked Windows install to generate the Armory wallet and wipe the disk (but I have no such "expendable" installations on hand).

So is there a better way to do this? With Electrum I was able to import a "junk" keypair and then replace the public key only with my savings address to accomplish the same thing. However, it looks like the Armory wallet format is not human readable.

There's some security issues with being able to import arbitrary public keys for watching-only purposes.  The best thing to do is to import it into your offline wallet and then re-make your watching only wallet.  Remove the old watching-only wallet from your online system, and re-import the new one.  It will destroy any comments you currently have in the file, but that is something I'm going to fix in the upcoming wallet format.

Alternatively, I kind of like your idea for over-writing a junk key pair.  I documented the file format, here: http://bitcoinarmory.com/index.php/armory-wallet-files

Though, to do it your way you have to start with a watching-only wallet with a junk keypair.  I would recommend make a new wallet, import a junk address, then make a watching only wallet, and remove the full wallet.  The imported key will be at the end of the file.  You have to change the first 24 bytes to be [Address20 + checksum] and change the 65+4 bytes where the public key is (the last four is also a checksum).  The checksums are just the first four bytes of the double-sha256 hash of the data. 

That's probably not what you were hoping for.  Sorry I couldn't make this easier...

[Lumpy]

I'm new to Armory, but been watching it for a while.  I have a "Brainwallet" savings address based on a very long password. I'm having trouble figuring out how to make it work in a watching-only wallet. What I want to do is import only the PUBLIC key into Armory without exposing the private key. I originally generated the private key on a non-networked boot of Ubuntu Privacy Remix and it has never been used on a networked computer. Now it seems my current options are:

1) Boot my computer into non-networked Linux to generate the Armory wallet (but I would have to go online to download libraries and build from source).
2) Boot my computer into my normal Windows install without networking to generate the Armory wallet (but I strongly distrust Windows and the security of doing this).
3) Boot some other non-networked Windows install to generate the Armory wallet and wipe the disk (but I have no such "expendable" installations on hand).

So is there a better way to do this? With Electrum I was able to import a "junk" keypair and then replace the public key only with my savings address to accomplish the same thing. However, it looks like the Armory wallet format is not human readable.

There's some security issues with being able to import arbitrary public keys for watching-only purposes.  The best thing to do is to import it into your offline wallet and then re-make your watching only wallet.  Remove the old watching-only wallet from your online system, and re-import the new one.  It will destroy any comments you currently have in the file, but that is something I'm going to fix in the upcoming wallet format.

Alternatively, I kind of like your idea for over-writing a junk key pair.  I documented the file format, here: http://bitcoinarmory.com/index.php/armory-wallet-files

Though, to do it your way you have to start with a watching-only wallet with a junk keypair.  I would recommend make a new wallet, import a junk address, then make a watching only wallet, and remove the full wallet.  The imported key will be at the end of the file.  You have to change the first 24 bytes to be [Address20 + checksum] and change the 65+4 bytes where the public key is (the last four is also a checksum).  The checksums are just the first four bytes of the double-sha256 hash of the data. 

That's probably not what you were hoping for.  Sorry I couldn't make this easier...

This seems to have worked! I'm new to hex editing so it took me a bit to figure out what to do. Some comments:

-The public key info seemed only about 10% into the file. Maybe I'm misunderstanding "The imported key will be at the end of the file"? After browsing around a bit I used a search to find it.
-There was an Address20 + Address20 + 4 so I changed both Address20's and then the 65 + 4. I used an online tool to do binary checksums.

Many thanks!

[etotheipi]

Unofficial Version 0.82.3

I just committed two minor fixes (major for some) to the master branch.  I'm not going to do an official release of it, because most users don't have a problem with it.

Fixes:  

• URI handling: The new logging system broke another feature... complex "bitcoin:" URIs.  Basic URIs were handled correctly, but anything requiring percent-encoding was failing.  It's fixed.
• Rare networking issue:  Wachtwood helped me track down a rare networking issue.  He confirmed that it's fixed.  If you have networking problems, use this version!

    Armory 0.82.3 *.deb for 64-bit Linux

This seems to have worked! I'm new to hex editing so it took me a bit to figure out what to do. Some comments:

-The public key info seemed only about 10% into the file. Maybe I'm misunderstanding "The imported key will be at the end of the file"? After browsing around a bit I used a search to find it.
-There was an Address20 + Address20 + 4 so I changed both Address20's and then the 65 + 4. I used an online tool to do binary checksums.

Many thanks!

Wow.  You are very resourceful  I didn't expect you to dig into, and succeed, so quickly!  All I was trying to say is that when you import a key, it will append it to the end of the wallet file.  You should then be able to look at the binary map on the link I sent, and see exactly how many bytes offset from the end you need to seek to, to change the relevant fields.  It seems you figured it out, anyway.

P.S. - What do you use for editing binary files as hex?

[Lumpy]

This seems to have worked! I'm new to hex editing so it took me a bit to figure out what to do. Some comments:

-The public key info seemed only about 10% into the file. Maybe I'm misunderstanding "The imported key will be at the end of the file"? After browsing around a bit I used a search to find it.
-There was an Address20 + Address20 + 4 so I changed both Address20's and then the 65 + 4. I used an online tool to do binary checksums.

Many thanks!

Wow.  You are very resourceful  I didn't expect you to dig into, and succeed, so quickly!  All I was trying to say is that when you import a key, it will append it to the end of the wallet file.  You should then be able to look at the binary map on the link I sent, and see exactly how many bytes offset from the end you need to seek to, to change the relevant fields.  It seems you figured it out, anyway.

P.S. - What do you use for editing binary files as hex?

I just looked for a free/portable hex editor and grabbed this one:

http://mh-nexus.de/en/hxd/

Not sure how it compares to others but it did the trick.

Another question: Is it possible to choose inputs in Armory -- e.g. if I want to spend coins from a specific address?

As an aside, I'm laughing at the results of a test send -- "Your Bitcoins just did a lap!"

[etotheipi]

Another question: Is it possible to choose inputs in Armory -- e.g. if I want to spend coins from a specific address?

I haven't implemented coin-selection yet, though it's on my list of things to do.  There is demand for it, but I have some other priorities that need to happen first.

Glad you are enjoying the program

[etotheipi]

Completely random update about Armory because I was "bored" on a Sunday night (trying to figure out this multi-threading...)

• (1) Armory has had a steady stream of 1,500 downloads per month for the last three months
• • (1a) Many downloads might be duplicates -- users downloading for online and offline
  • (1b) Many other users checkout the project from github and don't use the installers -- I don't know how many (probably offsets 1a a bit)
• (2) Using the "wc" command gives me a raw 37,000 newlines in all of code files I've written myself (*.py, *.cpp, *.h)
• • (2a) Empty lines make up about 15% of that
  • (2b) Comments make up about 20% of the remaining (yes, I write a lot of comments!)
• (3) My first commit to PyBtcEngine was July 11, 2011.  So I have been working on Armory for 13.5 months

So:

• It's probably fair to say Armory is getting at least 1,000 per month.
• So, I have written about 25,000 lines of executable code!  (Approx 17k python, 8k C++)

And here's a random assortment of commit messages from the history that amuse me:

• Endianness disaster averted
• Major Thunderstorm!  Backup push!
• Another thunderstorm!
• Working engine without any known memory bugs!
• Got a useless GUI on screen
• DO NOT use list[:] to copy a SWIG vector<type>!
• Working donation button (most important feature!)
• 'ff'*32 is not a valid private key!  Whoops!  [I was using 'aa'*32 and 'bb'*32 for months, and then I use 'ff'*32 and Armory started crashing...hard.  I wasted 2 days trying to figure out why seg faults started spontaneously occurring everywhere]
• I think zero-conf is fixed!
• I think zero-confirmation tx's are fixed!
• Almost fixed zero-conf (I know I keep saying that...)
• Okay, I think it's finally fixed!  All ledgers correct!
• I swear, I think it's fixed now, 100%!
• Polishing... in the wrong branch... gah!
• Added extra bytes to sign/verify to prevent evil
• Nasty Merge:  Probably broke everything...
• Crisis!  Rescan on every new block?!?  Fixing...
• FINALLY figured out the lpcwstr BS that all these windows.h functions use.  Multi-byte, long-pointers, wide strings.  WTF  [seriously, windows.h blows]
• Fixed table sorting bugs!  All of them!
• Destroying everything.  Putting back together...

I hope you enjoyed this posting...

EDIT: I should just start a blog

[ErebusBat]

I hope you enjoyed this posting...

EDIT: I should just start a blog

I did and you should.

[ErebusBat]

Found a bug...


Either your labels are swapped or my squirrel successfully created Yesterday Mail™

[etotheipi]

Found a bug...


Either your labels are swapped or my squirrel successfully created Yesterday Mail™

That is a bug! Not sure why that happened, though...

Also, not sure how you got version 0.82.5...  I had a lapse of version numbering judgment when creating a test-installer for wachtwood to help with network debugging.  I guess I left that running on the "dev" branch.  If you know how, I would suggest switching to the master branch (this goes for anyone else compiling from github).

I'll look into what caused the version number issue... obviously that shouldn't happen!

EDIT: looks like the same issue with 0.82.3... I just didn't notice because I had clicked on "Don't remind me again".  Maybe I should reset my settings to default so that I find stupid things like this .   It appears I didn't consider the case where I don't have version entries for the current version... I assumed you are either at the latest version, or behind.  This should be an easy fix.

EDIT2: Just fixed it in the master branch.  I was doing a really dumb version comparison check.  Now, it's much more intelligent!

[ErebusBat]

I installed from red emerald hombrew formula so I am not sure whIch branch it is.