Armory - Discussion Thread

[mav]

I have a strange problem.

I'm using the following piece of code (on a watch-only testnet wallet) and am getting no Addr20 value.

Code:

ledger = wlt.getTxLedger()   #wlt is a PyBtcWallet
ledger[0].pprint()

Returns

Code:

LedgerEntry: 
   Addr20  : 
   Value   : 10
   BlkNum  : 71313
   TxHash  : 43b999e0c1df82e83eaf2c4a589d7d8517552c32d4006ad4ae486c09ef42c881
   TxIndex : 1
   isValid : 1
   Coinbase: 0
   sentSelf: 0
   isChange: 0

Also, just for my own sanity check, I found that the type of ledger[0].getAddrStr20() is str with length 0

Any ideas on why this is happening?

[etotheipi]

I reinstalled and python27.dll was installed fine as well, and armory now boots. But it is unresponsive once it loads up. After about 4 minutes it becomes responsive and appears to work fine.

(WARNING) ArmoryQt.py:1273 - Memory pool file was corrupt.  Deleted. (no further action is needed)
(ERROR) ArmoryQt.py:782 - Could not access latest Armory version information
(ERROR) ArmoryQt.py:783 - Tried: https://raw.github.com/etotheipi/BitcoinArmory/logger/versions.txt

I then disabled the version check and restarted armory, this time it was immediately responsive.

Okay, this is clearly very wrong behavior.  I just wish I could reproduce it so that I can figure out how to make it go away.  Any information that might explain why you experience this delay and not me?  It doesn't happen on my Win7-64bit VM.  I don't really want to disable it, but I will have to if I can't figure this out.

I have a strange problem.

I'm using the following piece of code (on a watch-only testnet wallet) and am getting no Addr20 value.

Code:

ledger = wlt.getTxLedger()   #wlt is a PyBtcWallet
ledger[0].pprint()

Returns

Code:

LedgerEntry: 
   Addr20  : 
   Value   : 10
   BlkNum  : 71313
   TxHash  : 43b999e0c1df82e83eaf2c4a589d7d8517552c32d4006ad4ae486c09ef42c881
   TxIndex : 1
   isValid : 1
   Coinbase: 0
   sentSelf: 0
   isChange: 0

Also, just for my own sanity check, I found that the type of ledger[0].getAddrStr20() is str with length 0

Any ideas on why this is happening?

You somehow evaded the code path that sets that addr20 value.  I am looking at the code, but I can't figure out how that would happen.  Could you PM/email the context so I can see how it was created?  Was it created from Armory itself?  Or did you create it from a script on the offline computer using armoryengine?  If I can figure out how it happened, I can either fix that code path, or cut it off to avoid it in the future (I would like people to be able to leverage the library, like you are, without breaking stuff).

[DrFred]

Manually checking for a new version causes the issue too. Locks up for about 5 minutes until it shows error message "Latest Armory Version could not be retrieved, please check..." I can access versions.txt in my browser fine. Checked with wireshark and it doesn't seem to be attempting the connection (although I could be wrong, I don't use it that often). I don't have any firewall except windows which I tried turning off with no effect. I do have python installed separately as well, not sure if that could be causing any issues.

[dooglus]

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!  

I ran my modified copy of sample_armory_code.py twice today.  Both times it failed with "Segmentation fault".  I've not modified the C++ code at all.

I'm now running it in gdb to hopefully get a stack trace for you, though in my experience running it in gdb is often enough to stop the crash from happening.

[etotheipi]

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!  

I ran my modified copy of sample_armory_code.py twice today.  Both times it failed with "Segmentation fault".  I've not modified the C++ code at all.

I'm now running it in gdb to hopefully get a stack trace for you, though in my experience running it in gdb is often enough to stop the crash from happening.

It actually usually is useful, but you might have to compile Armory in debug mode (I manually modify the Makefile [at the top] because I do this so rarely).  And then you have to run "gdb python" because you actually have to debug python in order to hit the stack trace.  So you "gdb python" to get into GDB.  Then you type "run" to start debugging python.  Then you type "import sample_armory_code".  Then the stack trace will extend into the C++ code.  Not to mention, once it's compiled in debug the C++ will provide a little more output.

I have been overwhelmed with work-work, and Armory has fallen in priority this month.  This will settle down in a couple weeks (my real job rarely gets this intense) and I'll be back to part time like before.  So all of you digging into these things for me is fantastic!   Thanks so much!

[dooglus]

And then you have to run "gdb python" because you actually have to debug python in order to hit the stack trace.  So you "gdb python" to get into GDB.  Then you type "run" to start debugging python.  Then you type "import sample_armory_code".  Then the stack trace will extend into the C++ code.  Not to mention, once it's compiled in debug the C++ will provide a little more output.

I've just been doing "gdb python" then "run sample_armory_code.py".  That should be enough, right?  gdb's "run" command takes arguments and passes them to the process it's debugging - in this case "python".

As predicted the crash is no longer happening of course...

When I get my faster laptop back from having it repaired I'll try running it using valgrind.  That usually finds the source of intermittent crashes.

[dooglus]

Incidentally, when I modified the Makefile in cppForSwig/ my editor complained that lines 23 and 73 were "suspicious".  Both those lines contain only a single tab character.  Tab is significant in Makefiles, so it's probably better to delete those two tabs.

[etotheipi]

And then you have to run "gdb python" because you actually have to debug python in order to hit the stack trace.  So you "gdb python" to get into GDB.  Then you type "run" to start debugging python.  Then you type "import sample_armory_code".  Then the stack trace will extend into the C++ code.  Not to mention, once it's compiled in debug the C++ will provide a little more output.

I've just been doing "gdb python" then "run sample_armory_code.py".  That should be enough, right?  gdb's "run" command takes arguments and passes them to the process it's debugging - in this case "python".

As predicted the crash is no longer happening of course...

When I get my faster laptop back from having it repaired I'll try running it using valgrind.  That usually finds the source of intermittent crashes.

Oh good call!  I haven't run valgrind on the C++ codebase in months!  Since I've changed so much of the underlying code since then, I should probably check it again.

I hope you find something.  I haven't yet experienced any crashes, but many other users have, and I'm hoping they're all related to the same thing...

[dooglus]

Oh good call!  I haven't run valgrind on the C++ codebase in months!  Since I've changed so much of the underlying code since then, I should probably check it again.

I hope you find something.  I haven't yet experienced any crashes, but many other users have, and I'm hoping they're all related to the same thing...

Do you have a 'suppressions' file from when you ran it before?  There are usually a bunch of memory read/write errors in the libraries you link with which need suppressing before you can notice the errors in your own code.

[dooglus]

I'm now running it in gdb to hopefully get a stack trace for you, though in my experience running it in gdb is often enough to stop the crash from happening.

I finally got a crash from the version I built with debugging symbols.  Here's the backtrace:

Let's look at all the bets ever placed at SatoshiDice.com
there are 27 bet types
lessthan 64000 is listed
first SD Tx is in block 176627

Program received signal SIGSEGV, Segmentation fault.
0xb735eb18 in BtcUtils::readVarInt (strmPtr=0x4 <Address 0x4 out of bounds>, lenOutPtr=0xbffff1bc) at BtcUtils.h:243
243         uint8_t firstByte = strmPtr[0];
(gdb) where
#0  0xb735eb18 in BtcUtils::readVarInt (strmPtr=0x4 <Address 0x4 out of bounds>, lenOutPtr=0xbffff1bc) at BtcUtils.h:243
#1  0xb735e446 in BinaryRefReader::get_var_int (this=0xbffff1e8, nRead=0x0) at BinaryData.cpp:203
#2  0xb736afd0 in BtcUtils::TxCalcLength (ptr=0x0, offsetsIn=0xbffff31c, offsetsOut=0xbffff328) at BtcUtils.h:564
#3  0xb736683d in Tx::unserialize (this=0xbffff2f8, ptr=0x0) at BlockObj.cpp:529
#4  0xb736bc24 in Tx::Tx (this=0xbffff2f8, ptr=0x0) at BlockObj.h:348
#5  0xb7367a58 in TxRef::getTxCopy (this=0x20b092b4) at BlockObj.cpp:718
#6  0xb74f0944 in _wrap_TxRef_getTxCopy (args=0xb7b4f34c) at CppBlockUtils_wrap.cxx:33750
#7  0x080f77c3 in PyEval_EvalFrameEx ()
#8  0x080f7e20 in PyEval_EvalFrameEx ()
#9  0x080fd804 in PyEval_EvalCodeEx ()
#10 0x080fe177 in PyEval_EvalCode ()
#11 0x0811acd0 in ?? ()
#12 0x0811b8e9 in PyRun_FileExFlags ()
#13 0x0811c4cc in PyRun_SimpleFileExFlags ()
#14 0x0812c7c6 in Py_Main ()
#15 0x0805da0b in main ()
(gdb)

I'll leave the gdb session running, so if there are any commands you want me to type at it, I can do so.

strmPtr=0x4 doesn't look good though.  Pointers usually have high values, not 4...

[unclescrooge]

Hello etotheipi,

I'm testing the 0.82 and currently found no real bug. There's only one minor tiny improvements that could be made:

I transferred some coins from one address to another in the same wallet. Armory understand this is the same wallet and so balance doesn't change.

But when I export the CSV, the transaction is set in the "Total credit" column only, with no mention of fees paid. So it looks like we received the whole amount instead of sending and receiving it at the same time. Could make the column "Total debit" mention the debit as well?

Thanks a lot for your great work

[etotheipi]

Hello etotheipi,

I'm testing the 0.82 and currently found no real bug. There's only one minor tiny improvements that could be made:

I transferred some coins from one address to another in the same wallet. Armory understand this is the same wallet and so balance doesn't change.

But when I export the CSV, the transaction is set in the "Total credit" column only, with no mention of fees paid. So it looks like we received the whole amount instead of sending and receiving it at the same time. Could make the column "Total debit" mention the debit as well?

Thanks a lot for your great work

Fwhew!  It's so nice to hear that at least one person is not having a problem with Armory!  A lot of Armory problems reported in the last couple weeks and I've been swamped at my real job.    So, I won't get to address the major issues for another couple weeks (such as switching Armory to maintain its own blockdata files).

By the way, I went down to 30 hrs/week after crowdfunding back in March so that I could work on Armory more.  And I will be back to that in a month.  Until then, I get to work 50+ per week and only get paid for 30   Armory development is slow right now...

I just looked at the export-tx-history code and it does seem to be an error.  Sent-to-self transactions are not reflected properly in the .csv.  That should be an easy fix.

Also I am finally able to reproduce the version-check-freeze.  And so far nothing I do fixes it.  It must be related to github, since urllib2.urlopen works with google & microsoft.com fine, despite freezing for 4 min on github... I'll try to host the version check file somewhere else and see if that fixes it.  Hopefully tomorrow I'll have a re-release of 0.82.1 with a few other bug fixes too, and then I'll dig into the segfaults...

[wachtwoord]

Hello, thanks for creating Armory looks pretty damn good so far. I wanted to try it out because I am looking for a bit more freedom than the standard client provides and it seems like the software is getting more secure. I have two questions:

1) How would you rate security (i the sense of absence of bugs which could cause a user to lose money) in relation to the default client? I am contemplating which client to use for Walets containing the majority of my Bitcoins

2) I have created a new wallet and made a digital backup. Am I correct in understanding that this backup will be sufficient always and never has to be recreated due to the deterministic nature of the armory wallets? (For the default client I have recreated my backups monthly to avoid losing coins sent to newly generated addresses).

Thank you

[etotheipi]

Hello, thanks for creating Armory looks pretty damn good so far. I wanted to try it out because I am looking for a bit more freedom than the standard client provides and it seems like the software is getting more secure. I have two questions:

1) How would you rate security (i the sense of absence of bugs which could cause a user to lose money) in relation to the default client? I am contemplating which client to use for Walets containing the majority of my Bitcoins

2) I have created a new wallet and made a digital backup. Am I correct in understanding that this backup will be sufficient always and never has to be recreated due to the deterministic nature of the armory wallets? (For the default client I have recreated my backups monthly to avoid losing coins sent to newly generated addresses).

Thank you

Hi watchwood,

(1) So far, even while Armory has been in alpha for six months, I have received no reports of anyone losing money with Armory.  Ever.  I spent days testing and ironing out the wallets when I started, and there's never been a hint of a problem!  Even I am impressed that the wallets have been so reliable through the infancy of the program.
--Offline wallets are the holy grail feature, and they work.  Even though they use USB keys, they are orders of magnitude better than regular encrypted wallets.
--When you do maintain encrypted wallets online, Armory uses a scrypt-like key-stretching function to make it difficult for someone to brute-force the password even with GPUs.
--If you make a paper/digital backup, all coins are always recoverable (after all, I think HDD failure is a bigger risk for most users than theft).

(2)  The digital and paper backups are essentially the same.  They are deterministic wallets and all keys ever produced by them are recoverable from the first address & chaincode in the wallet.  The only caveat is imported keys, which will have to be backed up separately.  However, you can "Backup Individual Keys" in order to create a unified backup of all imported addresses.  You can even use it to get the private keys of all your addresses (used so far) in case you want to import them into another program/servicce.

Thanks for your interest!  I'm always happy to answer more questions about Armory

[traderjoe]

...Even though they use USB keys, they are orders of magnitude better than regular encrypted wallets....
I'm always happy to answer more questions about Armory

Passing an unwanted guest to the offline wallet and back again over the USB key, seems like the one main vulnerability of Armory.  I was thinking of re-partitioning an old USB flash drive to be just large enough to store most transactions one might make to/from the offline wallet. 

I was wondering if that sounds like a very good idea and, if it does, if the developer had any idea about how much space might be a good compromise between usability (key not usable if too small) and enhanced security (space for unwanted guests if key partition too large).  As the wallet is offline, I don't anticipate ever sending to multiple addresses, or having especially long blockchain entries.  I have imported private keys for this just in case anything were to go wrong with the armory wallet or if support on Armory were to end abruptly.

[etotheipi]

Passing an unwanted guest to the offline wallet and back again over the USB key, seems like the one main vulnerability of Armory.  I was thinking of re-partitioning an old USB flash drive to be just large enough to store most transactions one might make to/from the offline wallet.  

This is definitely a non-perfect situation, but it's pretty damned good given the usability requirements.  The process is already complicated for some new users, and they may not yet fully understand what's going on.  I'd rather them use offline wallets with a USB key than not use offline wallets at all (which is a significant risk if it's too complicated).  In that sense, everyone understands USB keys, so it serves its purpose well, and if you take precautions (like disabling USB autorun services, etc), it's very safe.

If you are ultra-paranoid, one thing you can do, is buy a USB key that has a write-protect switch.  Write the transaction to the USB key (which may be many kB), then turn on write-protect and insert it into the offline system.  If you sign the transaction and observe the difference between the original and the signed version, it's only ~140 bytes for each input at the bottom of the TxDP: (in bold)

-----BEGIN-TRANSACTION-FygKQ1EY-------------------------------------------------
_TXDIST_fabfb5da_FygKQ1EY_00a0
01000000023f4c47217647372132666fc1ae28d03508c8688a20273b255fbbf9b115b455e601000 0
0000ffffffff2224b044061b79b7af49c0df6c431dc600259fd5b222b3e25ebeb6001a7bc1d0000 0
...
_TXINPUT_00_19.59950000
_SIG_myiqg9jzUJ3TFi2dXaMBth1dDEcGuWuyRf_00_008c
4930460221007c746bf76bd6f8b3f60f62a8afd2dd653f66e87c90482fb4bea79118109bf1d1022 1
003d5ea4fe5223c7cc060f4f197208b4c8551195a6a1618065ef44cecba9405ec201410440ecb35 a
d63922d4d11314705a47372d63bc8bbc52f38c6abfba9c9fc5b1f230d432b7023687fda21c8a1f5 5
bf6c779cfd691917d4cb00b706b7a0df7d3af360
_TXINPUT_01_21.11110000
_SIG_mxUVS4fhnxD7jm5yjozuwkeMVDYakMueHB_01_008c
4930460221007db2bfb26234265781b7ca224f637a59fd4d1cb3b2f54330a1a075237f5ce09b022 1
00e05ce4dc9e3fcbc167d748da5286d26aabb3c0ad3874e2d4d8792b0e86208147014104f347f5a 0
3fa446972313e1df4e1596410bcfbaddaea90a8dd7cce01ff4f9575f34ed5b0e185fe1b36279e6f a
b0e219a72090de2d703b4df8d35df5af661f4fe5
-------END-TRANSACTION-FygKQ1EY-------------------------------------------------

This is quite a bit of data, but theoretically it could be copied by hand or scanned+OCR on the online computer.  If you only do it a couple times a year and holding a ton of money, it might be worth it.  I was looking into serial cable solutions, but the hard wire connecting the two computers made me uncomfortable (not to mention that it takes quite a bit of setup to make sure that the serial line is secure).

I was wondering if that sounds like a very good idea and, if it does, if the developer had any idea about how much space might be a good compromise between usability (key not usable if too small) and enhanced security (space for unwanted guests if key partition too large).  As the wallet is offline, I don't anticipate ever sending to multiple addresses, or having especially long blockchain entries.  I have imported private keys for this just in case anything were to go wrong with the armory wallet or if support on Armory were to end abruptly.

Luckily, Armory wallets have been the same since day one, and will continue to support the same deterministic structure even with the new wallet format coming up.  As such, any version of Armory since January will be sufficient at producing any number of keys from any Armory wallet you've ever created.  Even if support were to disappear, you'll be able to get those back with any version.  

As for the small USB key partition:  I like the idea a lot better if there was a way to bound the transaction size.  Unfortunately, these sizes are highly variable -- since I need to store previous transactoins in the TxDP (what is sent to the offline computer) there could be 100 kB in a single transaction.  However, most transactions, for simple users, will only include a couple inputs and will only be a few kB.  As such, the gap between smallest and largest is big enough that something sufficiently advanced could hide there

[traderjoe]

Thanks for the suggestions.  The small usb idea, was just for me, not something I was advocating for all armory users to mess with.  Don't get me wrong, I really like Armory.  After spending a long time looking at alternatives, I decided Armory is the closest alternative to a perfect solution that is out there.  Most of the paper wallet solutions available, really are not truly "offline" solutions to me when the private keys have to, eventually, enter something that runs online where, practically speaking, the environment cannot be guaranteed to always be 100% secure.  Only using the paper wallets to send once & then sending the change to a new one, was one idea, but that seemed like it would get confusing to me after doing it for a while.  Armory is the only easy-to-use solution I could find, that doesn't have you trusting an online environment, or relying on a web page that might not be there someday, to transmit the signed transaction.

Having thought about the weakest point though, I would like armory a little better if it printed OCR codes to return the signed transaction to the online wallet to transmit.

For a USB, I'm happy trying a solution that will work for *most* transactions I might make, maybe enlarging the partition or moving to new keys with no transaction history, as my previous transactions eventually grow too long.  I will give it a try.

[molecular]

Armory is the only easy-to-use solution I could find, that doesn't have you trusting an online environment, or relying on a web page that might not be there someday, to transmit the signed transaction.

While I love armory, I disagree on your point.

#> echo -ne "verylongandsecurenondictionarybasedpw#0" | sha256sum
ba1bb46eb35f1f4854a574f0fb4ca1b6256b58d1ac0fc776b399f2f74deb6f5f  -

is what I do to generate private keys for cold storage savings. Import that into armory (on the offline secure machine) and generate a watch-only copy of the wallet for use on insecure online machines to watch the funds still being there. Delete the real wallet again, it's not needed (this whole armory-step could be skipped, it's merely for the convenience of being able to monitor savings and have an easy-to-access list of the addresses. the address can be computed from the private )

To get to the funds, use a copy of StrongCoins offline transaction generation/signing javascript code (generate tx (moving all funds from one of the savings addresses to an address in my everyday wallet) on insecure machine, sign it on the secure always-offline machine and inject it into the network using the insecure machine again (shuffling data using a usb stick))

https://www.strongcoin.com/blog/the_easiest_way_to_create_secure_offline_bitcoin_transactions

took me some balls to do it, but now my savings are secure from both theft and loss in my brainwallet as long as I can manage to remember the passphrase.

One can also do it with armory instead of strongcoin-offlinetx-script, but firefox+strongcoin-offlinetx-script seem simpler to install onto an offline machine than armory (took me multiple sessions of 1-2 hours to get armory onto the offline ubuntu machine).

I know it would be possible to integrate private-key-import by sha256(passphrase) into armory but I agree with etoteipi that it should not be standard practice, because people can't be trusted to choose good passphrases. However, I like this method because sha256 implementations will always be available and nothing else is needed (except some bitcoin-related infrastructure, which will also be there unless my bitcoins are worthless anyways). Regarding the injection of the signed tx into the network: assuming bitcoin remains opensource, this can rather easily be coded up by someone or myself in case push comes to shove and no service for this should exist... or: if available, I can still use armory to do everything I just described doing with strongcoin-offlinetx-scripts

So go ahead, beam me to Mars naked, I'll have my coins as long as there's bitcoin infrastructure and some air to breathe

[jim618]

So go ahead, beam me to Mars naked, I'll have my coins as long as there's bitcoin infrastructure and some air to breathe

The average temperature on Mars is -55 C (-67 F) so I advise wearing one of these: Omega down suit

[molecular]

So go ahead, beam me to Mars naked, I'll have my coins as long as there's bitcoin infrastructure and some air to breathe

The average temperature on Mars is -55 C (-67 F) so I advise wearing one of these: Omega down suit

Damnit, no dancing naked on Mars in sulfur rain? Ok, I change my mind: beam me naked to any place that has bitcoin infrastructure, drugs postal service and hookers.