Armory - Discussion Thread

[nhodges]

I probably should have read all the way 'til the RAM requirement before I tried it out. Going to try this out on my Windows PC tomorrow.

[runeks]

Now I just need enough bitcoins to actually make me want to spend that much time on securing them. Can you help me with that too?

Do you have more than one BTC? I would bet that either the world will have forgotten about bitcoin or the value went up x10000 in 10 years from now. There is barely any alternative in between, so imagine you knowing there is a car's worth of money on that disc that you forgot the password of.

I'll take that bet.

[dani147624]

Hmmm... I got an error message when trying to send 5 BTC with more than 1252 BTC fee. Interestingly, when I decreased the 5 BTC by 1, I could add 1 BTC to the fee. I forgot to write down the error message, but I can try again in 120 blocks when I get back the 1257 BTC. (This was in testnet, of course.)
Not that it really matters (who the hell sends transactions with >1000BTC fees?), but I thought it was worth sharing.

[etotheipi]

I think you've convinced me.

Now I just need enough bitcoins to actually make me want to spend that much time on securing them. Can you help me with that too?

I just added a section to the bottom my the offline-wallets tutorial, called I'm Scared!.  I did this because I realized that me (the author of the program) was even uneasy about what could go wrong with the offline wallets.  So I came up with the 4-step process on that page to prove to myself that it really works!

The gist of it is:  prepare the offline wallet, back it up, delete it, and restore from backup before you do anything else.  Then give it 0.5 BTC and periodically ask yourself whether you trust it to hold lots of Bitcoins.  If the answer is no, just pull out your USB key and transfer for 0.01 BTC somewhere.  Even if it takes you 100 times, you'll eventually figure out that there's nothing to be scared of!  (hence the title of the section)

[runeks]

I am scared! That's exactly what I'm looking for!

I don't own a printer though, so I went about it the old paper-and-pen way. I made a backup of the wallet on paper, and kept the wallet file backed up as well. I get this error though when trying to import the wallet though:

Code:

***Checksum error!  Attempting to fix... fixed!
Traceback (most recent call last):
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 2406, in verifyUserInput
    rawStr = easyType16_to_binary( str(self.lineEdits[i].text()).replace(' ','') )
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 2537, in easyType16_to_binary
    return hex_to_binary(''.join([base16_to_hex_map[c] for c in b16str]))
KeyError: 'y'

[etotheipi]

I am scared! That's exactly what I'm looking for!

Code:

...
KeyError: 'y'

Ahhh!   Thanks for identifying where I can improve my error catching.  I catch&correct errors only if they are part of the alphabet I used on the paper backup.  In your case, you must've accidentally typed the letter 'y' which is not part of that alphabet.  For reference, the data on the paper backup is simply hexadecimal, but using 

Code:

asdf ghjk wert uion

instead of

Code:

0123 4567 89ab cdef

because it should be a lot easier to type (at least for me, typing numbers requires looking at the keyboard, where as the alphabet can be done by regular touch-typers without ever looking away).  I'll add this to my list of stuff to polish before alpha!

[runeks]

Now it works. Turns out I made no fewer than four errors when typing back in the letters from my self-written paper backup (good thing I kept a screenshot).

On a related note, have you considered using a dictionary when making paper backups, instead of letters?

There is a total entropy of about 342 bits in both the root and chain key as far as I can figure out. The same entropy is offered by 22 words from a ~50,000 word dictionary. When using a printer this would cause fewer errors when typing the keys back in, and if you're writing the keys down too it'll cause fewer errors in both writing down and typing back in.

The example 50k word dictionary is available on Ubuntu (and probably other Linux distributions) via this command:

Code:

grep -v "s$" /usr/share/dict/words

(which excludes words ending in "s" in the dictionary /usr/share/dict/words)

We can easily get 22 random words with this command:

Code:

grep -v "s$" /usr/share/dict/words|shuf -n 22 --random-source=/dev/random

which will produce series of words like the following:

lofted dazzling Dorothea wrangling purist mellow indirection windsurfed patrolman recalcitrance curtly valor pane cagey parodying freewheeled reverting jaunted haltingly shuddering biodegradable telephoned

browning masquerade oiling prevaricate clemency groggy steeling macerating unpleasantly sea chaplain rifted extension purulence Wake ventilation Meghan shipshape retaking cleverest substantiated Christensen

irresistible steering narced pricked joker gunpowder dangling oceanic Mariano hybridized barreled hob baleen backslide quarrelsome interlocutory Pauline stratify caribou Zen Adrienne confederating

owing windswept Morrow fathead papoose scallion streaking dissenting Gray overact pendent Freemason cannoned horsy volumed arise Wicca wrong assaulter sapping entropy miked

So we could have a paper wallet like this:

Root key: irresistible steering narced pricked joker gunpowder dangling oceanic Mariano hybridized barreled hob baleen backslide quarrelsome interlocutory Pauline stratify caribou Zen Adrienne confederating
Chain code: owing windswept Morrow fathead papoose scallion streaking dissenting Gray overact pendent Freemason cannoned horsy volumed arise Wicca wrong assaulter sapping entropy miked

[etotheipi]

Now it works. Turns out I made no fewer than four errors when typing back in the letters from my self-written paper backup (good thing I kept a screenshot).

On a related note, have you considered using a dictionary when making paper backups, instead of letters?

There is a total entropy of about 342 bits in both the root and chain key as far as I can figure out. The same entropy is offered by 22 words from a ~50,000 word dictionary. When using a printer this would cause fewer errors when typing the keys back in, and if you're writing the keys down too it'll cause fewer errors in both writing down and typing back in.

The example 50k word dictionary is available on Ubuntu (and probably other Linux distributions) via this command:

Code:

grep -v "s$" /usr/share/dict/words

(which excludes words ending in "s" in the dictionary /usr/share/dict/words)

We can easily get 22 random words with this command:

Code:

grep -v "s$" /usr/share/dict/words|shuf -n 22 --random-source=/dev/random

which will produce series of words like the following:

lofted dazzling Dorothea wrangling purist mellow indirection windsurfed patrolman recalcitrance curtly valor pane cagey parodying freewheeled reverting jaunted haltingly shuddering biodegradable telephoned
browning masquerade oiling prevaricate clemency groggy steeling macerating unpleasantly sea chaplain rifted extension purulence Wake ventilation Meghan shipshape retaking cleverest substantiated Christensen
irresistible steering narced pricked joker gunpowder dangling oceanic Mariano hybridized barreled hob baleen backslide quarrelsome interlocutory Pauline stratify caribou Zen Adrienne confederating
owing windswept Morrow fathead papoose scallion streaking dissenting Gray overact pendent Freemason cannoned horsy volumed arise Wicca wrong assaulter sapping entropy miked

So we could have a paper wallet like this:

Root key: irresistible steering narced pricked joker gunpowder dangling oceanic Mariano hybridized barreled hob baleen backslide quarrelsome interlocutory Pauline stratify caribou Zen Adrienne confederating
Chain code: owing windswept Morrow fathead papoose scallion streaking dissenting Gray overact pendent Freemason cannoned horsy volumed arise Wicca wrong assaulter sapping entropy miked

Runeks, I have considered this.  Given the amount of error correction I already built into the restore-paper-backup dialog, I wasn't too worried.  But it's something I'll keep in mind.  Perhaps I'll add an option to save it in whichever form you want.  Glad it worked, and thanks for the recommendation!

[runeks]

Cool. I guess it might be sufficient to just replace all y's with g's in the input (that's the mistake I made) if you have sufficient redundancy built into the current system as it is.

[runeks]

Now I get the same error that I mentioned before when trying to send a donation to you via Armory. This time I'm trying to send some coins from the wallet restored from a paper backup, to the wallet from the Satoshi client. This time I know the original Bitcoin client is running.

Code:

Coin Selection:  (Total =         0.19950000 BTC)
    Owner Address                                  TxOutValue      NumConf       PriorityFactor
    1GCLvcWM4ZDnDkfAm8vtJsb5E6TV5EMUmU             0.19950000 BTC          868                 1.20
19950000
19950000.0
[('\x9a\xb0@\xfe\xaa3\xc9~\xa8\xc3\xde\xa1\x05\xd0\x1a\xfd2\xfa\x814', 10000000)]
['test to Bitcoin-QT']
test to Bitcoin-QT
Total number of inputs in transaction:   1
Number of inputs that you can sign for:  1
Signature 0 is valid!
{'\xc4\x83a8\x8d\xb8\x90\x94\xf8\xc0T\x85\x1b?8\xf3\xd0\xadB>\xd0\x95Y\x88\x96O\xd1\xf8\xad\xd4p\xd9': 'test to Bitcoin-QT'}



0100000001649a8b8b8342958c451e96dbd530838de6578fcca3c478a286bdc06900864933000000008c4930460221002f9893a4e867bf2088b495f8bbb13121706c312c2d4080160be5178fb20b2c1a022100813313dd0d9fb9dffbed1d02590c5ea1471213e42ce88d619b44c06a05c895dd0141047d68779b0eb093c4fae8e705301cb8b0f65d22d340b76680005d73553d05fefc0e728840ebb3d9e1355841a98d10cc47b2acd43c4828d630fb47e7279693881dffffffff0280969800000000001976a9149ab040feaa33c97ea8c3dea105d01afd32fa813488ac30d39700000000001976a914296d9311c923837fb4e33a5ce272c64b584865c288ac00000000
-----BEGIN-TRANSACTION-Xuj1Frxy-------------------------------------------------
_TXDIST_f9beb4d9_Xuj1Frxy_0090
0100000001649a8b8b8342958c451e96dbd530838de6578fcca3c478a286bdc06900864933000000
001976a914a6af1826f2addcf1132244ae5a9eee91decdb54088acffffffff028096980000000000
1976a9149ab040feaa33c97ea8c3dea105d01afd32fa813488ac30d39700000000001976a914296d
9311c923837fb4e33a5ce272c64b584865c288ac00000000
_TXINPUT_00_0.19950000
_SIG_1GCLvcWM4ZDnDkfAm8vtJsb5E6TV5EMUmU_00_008c
4930460221002f9893a4e867bf2088b495f8bbb13121706c312c2d4080160be5178fb20b2c1a0221
00813313dd0d9fb9dffbed1d02590c5ea1471213e42ce88d619b44c06a05c895dd0141047d68779b
0eb093c4fae8e705301cb8b0f65d22d340b76680005d73553d05fefc0e728840ebb3d9e1355841a9
8d10cc47b2acd43c4828d630fb47e7279693881d
-------END-TRANSACTION-Xuj1Frxy-------------------------------------------------
Pretty tx:  Transaction:
   TxHash:    d970d4adf8d14f96885995d03e42add0f3383f1b8554c0f89490b88d386183c4 (BE)
   Version:   1
   nInputs:   1
   nOutputs:  2
   LockTime:  0
   Inputs: 
      PyTxIn:
         PrevTxHash: 3349860069c0bd86a278c4a3cc8f57e68d8330d5db961e458c9542838b8b9a64 (BE)
         TxOutIndex: 0
         Script:     (4930460221002f9893a4e867bf2088b495f8bbb13121706c312c2d4080160be5)
         Sender:     1GCLvcWM4ZDnDkfAm8vtJsb5E6TV5EMUmU
         Seq:        4294967295
   Outputs: 
      TxOut:
         Value:    10000000 ( 0.1 )
         Script:   OP_DUP OP_HASH (1F6vCsqmwn95mdgYPAqs2EK3h2zq6S5CXw) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    9950000 ( 0.0995 )
         Script:   OP_DUP OP_HASH (14n3yEaVRGnTv9SW3DYMqBFmPehyfBG3Pp) OP_EQUAL OP_CHECKSIG
None
Raw serialize tx:  0100000001649a8b8b8342958c451e96dbd530838de6578fcca3c478a286bdc06900864933000000008c4930460221002f9893a4e867bf2088b495f8bbb13121706c312c2d4080160be5178fb20b2c1a022100813313dd0d9fb9dffbed1d02590c5ea1471213e42ce88d619b44c06a05c895dd0141047d68779b0eb093c4fae8e705301cb8b0f65d22d340b76680005d73553d05fefc0e728840ebb3d9e1355841a98d10cc47b2acd43c4828d630fb47e7279693881dffffffff0280969800000000001976a9149ab040feaa33c97ea8c3dea105d01afd32fa813488ac30d39700000000001976a914296d9311c923837fb4e33a5ce272c64b584865c288ac00000000
Sending Tx, c48361388db89094f8c054851b3f38f3d0ad423ed0955988964fd1f8add470d9
Issue sending!
Traceback (most recent call last):
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 3558, in createTxAndBroadcast
    self.main.broadcastTransaction(finalTx)
  File "/home/rune/Programming/BitcoinArmory/ArmoryQt.py", line 1359, in broadcastTransaction
    self.NetworkingFactory.sendTx(pytx)
  File "/home/rune/Programming/BitcoinArmory/armoryengine.py", line 8531, in sendTx
    raise ConnectionError, 'Connection to localhost DNE.'
armoryengine.ConnectionError: Connection to localhost DNE.

EDIT: I'm going to bed now. I'll be able to look into this further at a later time.

[etotheipi]

Now I get the same error that I mentioned before when trying to send a donation to you via Armory. This time I'm trying to send some coins from the wallet restored from a paper backup, to the wallet from the Satoshi client. This time I know the original Bitcoin client is running.

Code:

....
Traceback (most recent call last):
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 3558, in createTxAndBroadcast
    self.main.broadcastTransaction(finalTx)
  File "/home/rune/Programming/BitcoinArmory/ArmoryQt.py", line 1359, in broadcastTransaction
    self.NetworkingFactory.sendTx(pytx)
  File "/home/rune/Programming/BitcoinArmory/armoryengine.py", line 8531, in sendTx
    raise ConnectionError, 'Connection to localhost DNE.'
armoryengine.ConnectionError: Connection to localhost DNE.

Runeks,

That does still look like a connection issue.   Unfortunately, Armory only initiates the connection when it first starts up.  If it can't connect on startup, it won't connect until you restart Armory.  If it does connect, you'll see on the console output something about "Handshake finished!  Connection Open.".  

At the moment, I can't find a way to recreate that problem on my own machine.  If the Satoshi client is open, and restarting doesn't help... then I'll have to defer this because of a lack of ability for me investigate it.  However, if nothing else works, you can always copy the raw tx from the console output into Nibor's webtool for broadcasting tx:  http://bitsend.rowit.co.uk/  .   (it's all the hex right after "Raw serialize tx:" right after you click "Send").  In the short term, I'll make a note to add a real pop-up message box about this error, and even refer the user to Nibor's tool (speaking of which, I should send him a donation!)

[nhodges]

Having trouble on W7 VS2010, does it require 2005?

[etotheipi]

Having trouble on W7 VS2010, does it require 2005?

MSVS 2008 works for sure (that's what I've been using).  Someone else way earlier in the thread said they got it working with MSVS 2010, but I remember having trouble with it when I tried once (but didn't try too hard). 

[runeks]

That does still look like a connection issue.   Unfortunately, Armory only initiates the connection when it first starts up.  If it can't connect on startup, it won't connect until you restart Armory.  If it does connect, you'll see on the console output something about "Handshake finished!  Connection Open.".  

How does Armory connect to the local bitcoin client? Via the RPC interface on port 8332?

[etotheipi]

That does still look like a connection issue.   Unfortunately, Armory only initiates the connection when it first starts up.  If it can't connect on startup, it won't connect until you restart Armory.  If it does connect, you'll see on the console output something about "Handshake finished!  Connection Open.".  

How does Armory connect to the local bitcoin client? Via the RPC interface on port 8332?

It connects as a regular peer, but through localhost.  Port is 8333.  It does the handshake, and then regresses to nothing but a leech:  it ignores all messages except for new tx, which it requests (to get zero-conf tx), and sends tx that you create (which is then broadcasted if it is valid).  No other communication is used.

[runeks]

^ Can you point me to the place in the code where it tries to make this connection? I'd like to try to debug it if possible.

[etotheipi]

^ Can you point me to the place in the code where it tries to make this connection? I'd like to try to debug it if possible.

It's using python-twisted, which can be awfully bizarre/confusing if you're not familiar with it, but it doesn't hurt to look at it.  Please PM me to discuss specifics if you need clarification or if you identify an improvement.

The code is in ArmoryQt.py, search for the function "setupNetworking" (around line 500).  The twisted protocol/client/factory definitions are located in armoryengine.py around line 8350.  Let me know if you find something!  (just so you know, I haven't gotten any other reports of network problems... because if the networking is botched at the beginning, it goes into offline mode, or in online mode it's pretty successful at reconnecting if it gets disconnected.  somehow you are getting into online mode, but then losing the connection and it's failing to reconnect...?)

[nhodges]

Trying to build solution on W7 w/ VS2012, however seem to be getting about 85 of these types of errors:

error LNK2001: unresolved external symbol __imp_Py*

I definitely have python installed and in my path, as well as all the other requirements. Any thoughts?

[fornit]

Having trouble on W7 VS2010, does it require 2005?

MSVS 2008 works for sure (that's what I've been using).  Someone else way earlier in the thread said they got it working with MSVS 2010, but I remember having trouble with it when I tried once (but didn't try too hard). 

i use vs2010 and followed the build instructions. worked from the start without adjustments (except converting the .sln file of course)

[etotheipi]

Trying to build solution on W7 w/ VS2012, however seem to be getting about 85 of these types of errors:

error LNK2001: unresolved external symbol __imp_Py*

I definitely have python installed and in my path, as well as all the other requirements. Any thoughts?

It's possible that you are trying to compile for the wrong architecture.  Make sure you're selecting "Release" and "x64" at the top of MSVS (if you are on a 64-bit system) and make sure you have 64-bit python installed.  In my case, I got errors (albeit, different ones) if I tried compiling in 32-bit, because my installed C:\Python27\python27.lib file is only for 64-bit systems.

I suppose it could also be a SWIG problem, but it sounds like you got all the way to the linking phase, so SWIG had probably done it's job by then...