Armory - Discussion Thread

[etotheipi]

UPDATE:

I just found out that some users report instability being fixed by using the 64-bit version.  It slipped my mind that it might be one of the problems being faced, but it makes sense given the high RAM usage. 

So I re-linked it on the download page.  If you were previously experiencing problems, please try the 64-bit version!


@Ente

There's a setting to disable auto-bitcoind.  Just disable it, and you can run Armory like you used to.

[1713281964]

1713281964

[1713281964]

1713281964

[1713281964]

1713281964

[1713281964]

1713281964

[oakpacific]

How difficult would it be to create a "lite mode" which only stores block headers, like Multibit does? I have also read your idea about the blockchain compression using radix tree structure, any chance for to implement it in the Armory? If you think we should get someone else to do it,  I can contribute part of the bounty.

[etotheipi]

How difficult would it be to create a "lite mode" which only stores block headers, like Multibit does? I have also read your idea about the blockchain compression using radix tree structure, any chance for to implement it in the Armory? If you think we should get someone else to do it,  I can contribute part of the bounty.

It's on the medium-term plans.  In fact, the database that I'm implementing right now is intended to be flexible to accommodate any level of storage:  from total lite-node to the radix-tree stuff.  It won't all be implemented now, but I'm trying to leave room for it so that when I want to do that, I'll at least have a lot of the details worked out already, even if I missed something and have to rewrite parts of it later.

In the long run, I'd like to have a server version that uses a real database.  By that, I mean a hardcore database with all the ACID robustness in it, to be run by those that really want to run a server.  Right now, I'm constrained by the requirement that the database I choose must be easy to distribute, run in isolation, and have a license agreeable with distribution with Armory.  LevelDB is a great choice for the end-user version of the software.  But for the server version, I can have something more heavyweight.  And I don't have much experience with that, so I wouldn't mind offloading that somehow. but definitely can't even think about it for a few weeks until after the conference.

[gweedo]

In the long run, I'd like to have a server version that uses a real database.  By that, I mean a hardcore database with all the ACID robustness in it, to be run by those that really want to run a server.  Right now, I'm constrained by the requirement that the database I choose must be easy to distribute, run in isolation, and have a license agreeable with distribution with Armory.  LevelDB is a great choice for the end-user version of the software.  But for the server version, I can have something more heavyweight.  And I don't have much experience with that, so I wouldn't mind offloading that somehow. but definitely can't even think about it for a few weeks until after the conference.

This scares me a lot. The reason I like armory so much is that it was the closes thing to a full node we currently have for home users. I hope you can still keep it as much as to a trust-less system as possible.

[etotheipi]

In the long run, I'd like to have a server version that uses a real database.  By that, I mean a hardcore database with all the ACID robustness in it, to be run by those that really want to run a server.  Right now, I'm constrained by the requirement that the database I choose must be easy to distribute, run in isolation, and have a license agreeable with distribution with Armory.  LevelDB is a great choice for the end-user version of the software.  But for the server version, I can have something more heavyweight.  And I don't have much experience with that, so I wouldn't mind offloading that somehow. but definitely can't even think about it for a few weeks until after the conference.

This scares me a lot. The reason I like armory so much is that it was the closes thing to a full node we currently have for home users. I hope you can still keep it as much as to a trust-less system as possible.

I plan to keep the full version.  And keep it "encouraged,", but there's gotta be a lighter version of it for the non-power-users.  There's only so much impact Armory can have in its current incarnation of making users wait 8+ hours to download the blockchain (and it will be much longer as time goes on).  I have a few directions I want to go with it, but there will always be a full-node version of it.  And the server/super-node is for the radix-tree stuff, so it can act as an oracle for arbitrary wallets, much like Electrum servers do right now.

Also, the radix-tree stuff has the goal of eventually improving the network in a lot of different ways.  It will make lite nodes almost as secure as full nodes.   And it looks like it may not be an excessive amount of extra work for full (but pruned) nodes.  If it's successful, I think it can change the network.  amiller/socrates actually believes there's a way to expand it to allow lite-nodes to do full verification.. I'm not sure I believe him,  but I haven't had the time to try to grok his proposal.  I just know it's something I'm looking forward to looking into when I get all the immediate priorities out of the way.

[oakpacific]

In the long run, I'd like to have a server version that uses a real database.  By that, I mean a hardcore database with all the ACID robustness in it, to be run by those that really want to run a server.  Right now, I'm constrained by the requirement that the database I choose must be easy to distribute, run in isolation, and have a license agreeable with distribution with Armory.  LevelDB is a great choice for the end-user version of the software.  But for the server version, I can have something more heavyweight.  And I don't have much experience with that, so I wouldn't mind offloading that somehow. but definitely can't even think about it for a few weeks until after the conference.

This scares me a lot. The reason I like armory so much is that it was the closes thing to a full node we currently have for home users. I hope you can still keep it as much as to a trust-less system as possible.

I plan to keep the full version.  And keep it "encouraged,", but there's gotta be a lighter version of it for the non-power-users.  There's only so much impact Armory can have in its current incarnation of making users wait 8+ hours to download the blockchain (and it will be much longer as time goes on).  I have a few directions I want to go with it, but there will always be a full-node version of it.  And the server/super-node is for the radix-tree stuff, so it can act as an oracle for arbitrary wallets, much like Electrum servers do right now.

Also, the radix-tree stuff has the goal of eventually improving the network in a lot of different ways.  It will make lite nodes almost as secure as full nodes.   And it looks like it may not be an excessive amount of extra work for full (but pruned) nodes.  If it's successful, I think it can change the network.  amiller/socrates actually believes there's a way to expand it to allow lite-nodes to do full verification.. I'm not sure I believe him,  but I haven't had the time to try to grok his proposal.  I just know it's something I'm looking forward to looking into when I get all the immediate priorities out of the way.

Just curious, do you see any unusual growth in the number of downloads/pageviews in the last two days? The state-controlled television in China did a half-hour program on bitcoin, which may have driven the daily bitcoin-qt download count of China to go up by about 20 times, putting it ahead of U.S, by a 1000% margin, I wonder if the impact can also be felt by Armory.

[LvM]

In bitcoind appdata dir is a file "bitcoin.conf"
containing:

rpcuser=generated_by_armory
rpcpassword= (an alphanumeric string, length 44 bytes)

Found no explication for that.
May a ask wether this is my (encrypted) password and a security risk?

[Ente]

In bitcoind appdata dir is a file "bitcoin.conf"
containing:

rpcuser=generated_by_armory
rpcpassword= (an alphanumeric string, length 44 bytes)

Found no explication for that.
May a ask wether this is my (encrypted) password and a security risk?

This "rpcuser" and "rpcpassword" is for bitcoin-qt and bitcoind, it sets which other users/computers/programs may connect to bitcoin-qt and bitcoind. Everyone connected via rpc may send bitcoins from bitcoind's (!) wallet.
Armory uses its own wallet(s). So you may remove all original bitcoind wallets.
As Armory depends on bitcoind's blockchain-handling, it must be able to connect via rpc.
Any random user and password will enable bitcoind to be connectable, and Armory will simply read the right user and password right from that config.

That's how I understand it, anyway :-)

tl:dr:
It's perfectly safe and normal. Don't leave bitcoins in bitcoin-qt's original wallet though.

Ente

[rottenchris]

Good morning,

today, Armory 0.88.1, 32bit+64bit, Windows 8 (64bit), stopped working for me. It just terminates with a runtime error after scanning 98% of the blockchain.

I have tried a couple of things including reinstalling it, doing a fresh install on a fresh Win8 VM (8GB RAM if it matters), redownloading the blockchain and so on.

There seems to be only ONE solution to this for me : Using the 64bit ONLY Version of Armory.

May this helps someone with the same problem!

[picobit]

Just theoretically, it may be that the block chain has just grown so much that one of the arrays in Armory is now over 2 GB.  Such an object cannot be addresses in a 32-bit executable, and if that is the case all 32-bit versions of Armory have just stopped working.  That would be pretty bad, so let us hope I am wrong.

[Sc@rF@c3]

Running offline Armory, unexpected crash, Bitcoind  closes sometimes
Ram:16GB
64bit
i7 processsor

Faulting application name: bitcoind.exe, version: 0.0.0.0, time stamp: 0x4d44aa00
Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722
Exception code: 0x40000015
Fault offset: 0x0006680c
Faulting process id: 0x15ec
Faulting application start time: 0x01ce4c4f259cdee0
Faulting application path: C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe
Faulting module path: C:\Windows\syswow64\msvcrt.dll
Report Id: bad46c8f-b842-11e2-9b76-005056c00008
--------------------------------------------------------
Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: _CppBlockUtils.pyd, version: 0.0.0.0, time stamp: 0x5171c531
Exception code: 0xc0000005
Fault offset: 0x000e0508
Faulting process id: 0xf34
Faulting application start time: 0x01ce4c37e500f4be
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\_CppBlockUtils.pyd
Report Id: 5c030b55-b82f-11e2-9af5-005056c00008
--------------------------------------------------------

Hope this helps

[etotheipi]

Running offline Armory, unexpected crash, Bitcoind  closes sometimes
Ram:16GB
64bit
i7 processsor

Faulting application name: bitcoind.exe, version: 0.0.0.0, time stamp: 0x4d44aa00
Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722
Exception code: 0x40000015
Fault offset: 0x0006680c
Faulting process id: 0x15ec
Faulting application start time: 0x01ce4c4f259cdee0
Faulting application path: C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe
Faulting module path: C:\Windows\syswow64\msvcrt.dll
Report Id: bad46c8f-b842-11e2-9b76-005056c00008
--------------------------------------------------------
Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: _CppBlockUtils.pyd, version: 0.0.0.0, time stamp: 0x5171c531
Exception code: 0xc0000005
Fault offset: 0x000e0508
Faulting process id: 0xf34
Faulting application start time: 0x01ce4c37e500f4be
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\_CppBlockUtils.pyd
Report Id: 5c030b55-b82f-11e2-9af5-005056c00008
--------------------------------------------------------

Hope this helps

Unfortunately, that error isn't terribly useful, except for noting that bitcoind.exe seems to have triggered the error.  Can you run Bitcoin-Qt standalone? 

Also, have you downloaded the 64-bit version of Armory?  I've noticed a lot of these crashing issues go away with the latest 64-bit version.  I actually just removed the 32-bit link from the webpage for that reason.

[etotheipi]

Wait... you're running this on the offline computer?  You don't need Bitcoin-Qt on the offline computer.  Please uninstall it so Armory isn't even tempted to try to run it.  You only need Armory on the offline computer, and the offline computer can be any PoS with 256 MB of RAM or more.  The online computer is the one that needs all the RAM and bitcoin-qt.

[Sc@rF@c3]

Sorry, I meant online Armory, offline read only wallet.

I am running 64bit Armory.

If I get another crash, I will export an Armory log after the event.

Thank you for the great work...

[LvM]

Using Windows 7/64, 8 GB RAM, 100 Mbps Internet

I like Armory very much, but its "speed" when starting (Synchronizing and Scanning transaction history) is really not tolerable.

My Armory-win32 version crashed also, first hanging around, then after killing and restart runtime error.

After trying quite a lot I deleted the bitcoin AppData dir (blockchain...) as described in the
outdated(!)
https://bitcoinarmory.com/troubleshooting-armory/

I shouldn't have done that, since as I see here, the new instruction is to use Armory-win64 only.
So I try that. Download and installation is done within seconds.

Now I restart Armory-win64 and cannot believe it.
Armory is Reading/saving not even 100 bytes of the 10 GB blockchain etc. in a minute.
Can see this using Total Commander for my dir management.

Even bitcoin-qt (very,very slow also) is much faster doing the same.
So I stopped armory and now bitcoin-qt is reloading the deleted blockchain.
40000 blocks left in moment. 07:39:45 PM
Compared with that, Electrum doing nothing like that is a dream.

[etotheipi]

Using Windows 7/64, 8 GB RAM, 100 Mbps Internet

I like Armory very much, but its "speed" when starting (Synchronizing and Scanning transaction history) is really not tolerable.

My Armory-win32 version crashed also, first hanging around, then after killing and restart runtime error.

After trying quite a lot I deleted the bitcoin AppData dir (blockchain...) as described in the
outdated(!)
https://bitcoinarmory.com/troubleshooting-armory/

I shouldn't have done that, since as I see here, the new instruction is to use Armory-win64 only.
So I try that. Download and installation is done within seconds.

Now I restart Armory-win64 and cannot believe it.
Armory is Reading/saving not even 100 bytes of the 10 GB blockchain etc. in a minute.
Can see this using Total Commander for my dir management.

Even bitcoin-qt (very,very slow also) is much faster doing the same.
So I stopped armory and now bitcoin-qt is reloading the deleted blockchain.
40000 blocks left in moment. 07:39:45 PM
Compared with that, Electrum doing nothing like that is a dream.

This has been discussed many times.  There was a nice robustness and simplicity by not saving data between loads.  But obviously not sustainable, and it's becoming too much trouble for users.

I'm working on it now.  It should be done in a couple weeks.

[LvM]

Just as Info:
Bitcoin-qt was ready rereading the complete blockchain at 11:55 PM
Started new installed Armory-win64, worked now, ready 10 minutes later.

[OpenYourEyes]

Any chance of being able to add the option to show the mtgox price in the tray?
I know it's not the role of Armory, but it would be useful to have.

I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add threaded timers (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).

[etotheipi]

Any chance of being able to add the option to show the mtgox price in the tray?
I know it's not the role of Armory, but it would be useful to have.

I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add timers which work in the background (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).

This is what the "heartbeat" functions are for  

-- Add a widget somewhere that will show the price (we'll call it self.goxWidget = QLabel(''))
-- Create a function like below
-- Add it to the extraHeartbeatAlways list  (extraHeartbeatAlways.append(getGoxPrice))

Code:

def getGoxPrice():
   # Return instantly if current time is not a multiple of 900 sec
   if not (RightNow() % (15*MINUTE)) == 0:
      return

   try:
      import urllib2
      import ast
      theData = urllib2.urlopen('http://data.mtgox.com/api/1/BTCUSD/ticker').read()
      dataMap = ast.literal_eval(theData)
      lastValueStr = dataMap['return']['last']['display']
      self.goxWidget.setText(lastValueStr)
   except:
      self.goxWidget.setText('???')
      LOGEXCEPT('Could not access Gox data')  # dumps exception to log

You could set the modulo to 10*SECOND for testing.

[OpenYourEyes]

Any chance of being able to add the option to show the mtgox price in the tray?
I know it's not the role of Armory, but it would be useful to have.

I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add timers which work in the background (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).

This is what the "heartbeat" functions are for  

-- Add a widget somewhere that will show the price (we'll call it self.goxWidget = QLabel(''))
-- Create a function like below
-- Add it to the extraHeartbeatAlways list  (extraHeartbeatAlways.append(getGoxPrice))

Code:

def getGoxPrice():
   # Return instantly if current time is not a multiple of 900 sec
   if not (RightNow() % (15*MINUTE)) == 0:
      return

   try:
      import urllib2
      import ast
      theData = urllib2.urlopen('http://data.mtgox.com/api/1/BTCUSD/ticker').read()
      dataMap = ast.literal_eval(theData)
      lastValueStr = dataMap['return']['last']['display']
      self.goxWidget.setText(lastValueStr)
   except:
      self.goxWidget.setText('???')
      LOGEXCEPT('Could not access Gox data')  # dumps exception to log

You could set the modulo to 10*SECOND for testing.

Nice one. I did see the heartbeat function but didn't play with it much.

I'll have a look to see if I can get it working.