etotheipi / bitcoinarmory Goto Github PK

Right after startup the Dashboard opens to tell me I'm in offline mode because bitcoind is not yet synced up (which it is, another issue will follow):

http://screencloud.net/v/dDoA

When I want to scroll down in that window, something line every second, it automatically goes back to the top. My guess would be that it happens when Armory checks whether bitcoind is still not fully synced.

I use Armory with Linux, testing branch. Last commit is 8af1b12.

Hey, I just met you, and this is crazy.

But I've cross-built Armory for the RPi, so ping me maybe. ;)

Now it is 3am, I go to sleep, but I'll drop this img.
I'll publish the procedure (incredibly simple) on the forums tomorrow (ah, could you get me out of the newbie thing?)

I recenlty re-installed my MacBook and tried to reinstall Bitcoin Armory using WyseNynja's brew tap. Last time I did it on my own, but I remember that is was kind of a "mess" since I had some trouble with different Python versions.
The brew formula executed without any problems, but when I run "python unittest.py" or other scripts that ran before I get the following error:
"Traceback (most recent call last):
File "unittest.py", line 320, in
BDM_LoadBlockchainFile()
NameError: name 'BDM_LoadBlockchainFile' is not defined"

I also installed BitcoinArmory manually using make and so on. Same result.

Bitcoin client 0.8 is installed and up to date.

Is that a bug in the newest release?

When i trying to open transaction with ź(Polish diacritical mark) in date:
Traceback (most recent call last):
File "ArmoryQt.py", line 2082, in dblClickLedger
txtime = str(self.ledgerView.model().index(row, LEDGERCOLS.DateStr).data().toString())
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017a' in position 7: ordinal not in range(128)

There still is no implementation for multi-signature transactions. What is holding this back?

Trying to install the .deb file on Ubuntu 12.10 I get the following warning:

Testing under windows,, going online causes the Armour process to balloon to over 1.7GB RAM. I assume there is an optimization that could be made here so not everything has to be processed in RAM.

Using version 0.87.2

As far as I can tell, Armory can't be minimized to system tray (leaving no button in the taskbar) yet under Windows. I think it would be a very useful option, especially with the startup time under Windows being what it is.

I had a wallet with a single spendable output. I'm using git version 20124b2. When I tried to spend the full amount in the wallet, I got the following error:

Traceback (most recent call last):
File "/home/x/BitcoinArmory/qtdialogs.py", line 4815, in createTxAndBroadcast
txdp = self.validateInputsGetTxDP()
File "/home/x/BitcoinArmory/qtdialogs.py", line 4969, in validateInputsGetTxDP
utxoSelect = PySelectCoins(utxoList, totalSend, fee)
File "/home/x/BitcoinArmory/armoryengine.py", line 5091, in PySelectCoins
utxos = PySortCoins(unspentTxOutInfo, method)
File "/home/x/BitcoinArmory/armoryengine.py", line 4688, in PySortCoins
utxosNoZC.extend(filter(lambda a: a.getNumConfirm()==0, unspentTxOutInfo))
AttributeError: 'tuple' object has no attribute 'extend'

I was able to "fix" this for now with a hack: utxosNoZC = list(utxosNoZC) right before the call to extend in PySortCoins. But I don't know the code enough to understand where exactly the real bug is. Thanks for any help.

BadInputError is raised in a few places in armoryengine.py, but I can't see it defined anywhere. Shouldn't it be defined along with all other exceptions around lines 266-291 in the same file?

FWIW I caught this doing deliberately silly things using the library directly from a script (from armoryengine import *) - not related to any bug afaik.

When starting armory (using the github version or the ubuntu deb from the site) armory consistently crashes with a segmentation fault.

This seems to happen during the loading of blk002.dat

The standard bitcoin client works fine.

When an input uses a compressed key, Armory labels this input script type as "Unrecognized" instead of "Standard". For example, transaction d035f3afff7a936111e016a2db055a6df7cf112d73bb4711d46df97a1256fe91 uses a compressed address.

Hi there,

first of: Armory is AWESOME!
But: It takes my computer serveral (>5) minutes to launch it (bitcoind is running though).

How can I find out whats taking him so long?
Any debugging/profileing hints?

I am quit new to pyhton

Regards
-- Fabian

EDIT: I just ran it in a console an the resulting lines told me that the loading of the blockchain too 440.0 seconds. blk0001.dat is about 2GB of size. Anyway to accelerate startup? dont want to wait 7 minutes each time i want to do a transaction :-(

I left Armory on for about 24 hours, and when I came back I see a notification every 5-10 seconds saying Armory has lost it's connection to Bitcoin-qt, followed by a bubble saying it has reconnected. These messages repeated popping up until I shut down Armory.

I took a screenshot and grabbed the Armory logs. Is there a way to attach them?

The message in the notification bubble is:

Disconnected
Connection to Bitcoin-QT client lost!
Armory cannot send or receive bitcoins until connection is re-established.

Armory version 0.84.5 on Ubuntu 12.04.1 64bit

I have got wallet with 0.51710237 BTC. When i tried to send 0.5 i got error:
SelectCoins returned a list of size zero. This is problematic and probably not your fault.

When i try to send 0.4 everything is ok.

...

Disregard, I misunderstood how EC signing worked.

Log File: https://gist.github.com/JCRobertson/6b7b82674d11fd4f6486

Windows 8 pro 64-bit

Description:

With Armory and Bitcoin installed on my HDD (I have an SSD with my Windows installation), Armory was unable to locate bitcoin-qt.exe, even though the "Bitcoin Installation Dir:" field in Settings was marked correctly. The Bitcoin program ran correctly.

Steps Taken:

Restarting the machine had no effect. Running as administrator had no effect. Uninstalling and re-installing Bitcoin to different locations on the HDD had no effect. Uninstalling and re-installing Armory to the HDD had no effect.

Resolution:

Installing Bitcoin to the SSD resolved the issue.

I'll admit i'm new to using Bitcoin Armory, even to bitcoin as a whole. I noticed that a new address is added into my wallet each time I press "Receive Bitcoins". I didn't know where else to ask this -- can those "secondary" addresses be deleted; can they be re-used and do I just suck at finding a page that describes this?

Thanks

Generated a receive address and issued transaction, transaction was in ledger but disappeared along with the address from the wallet.

Armory Version 0.82-beta

UPDATE:
Receive address re-appeared after 3rd restart, will continue using with --debug enabled.

Is this a minimum confirmation before a transaction is directly written to the ledger?

I was lucky enough to witness the following: armory was displaying an unconfirmed (not included in a block) transaction that I was waiting for.

The transaction was included in a block which was later orphaned. Armory then removed the transaction from the list, instead of restoring it with a 0-confirmation state. I can confirm that the transaction is still in bitcoind mempool.

The transaction has reappeared when it was again included in a block. But in any case, Armory should not just get rid of the transaction but should return it into the unconfirmed state.

Today, I had the case where a 50 BTC transaction was apparently correctly propagated by armory as it appeared on blockchain.info, but since its only input had only one confirmation (and the transaction had no fee), it was not included right away into a block. I had to manually reinject the transaction after more than 90 minutes without confirmation (while the input had been 6-confirmed in the meantime) to finally get the transaction in a block 108 minutes after its original submission.

Armory should resend transactions with 0 confirmations appearing in the ledger when it receives a new block (because conditions for transaction acceptance, such as number of confirmations on inputs, may have been altered by this new block). That would help include incoming or outgoing transactions into the next block, even if it has since disappeared from the various bitcoind memory pools.

Just installed armory and after syncing bitcoin-qt (latest version) with the network I launched Armory. I get a crash with the following error in the armory.exe.log :

(ERROR) ArmoryQt.py:649 - 3 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:654 - File mempool.bin does not exist. Nothing deleted.
(ERROR) ArmoryQt.py:649 - 4 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:654 - File mempool.bin does not exist. Nothing deleted.
(ERROR) ArmoryQt.py:649 - 5 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:654 - File mempool.bin does not exist. Nothing deleted.
(ERROR) ArmoryQt.py:649 - 6 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:654 - File mempool.bin does not exist. Nothing deleted.
(ERROR) ArmoryQt.py:649 - 7 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:654 - File mempool.bin does not exist. Nothing deleted.
(ERROR) qtdialogs.pyc:3471 - User did not accept the EULA
(WARNING) ArmoryQt.py:115 - Armory startup was aborted. Closing.
(ERROR) armoryengine.pyc:7452 - Requested wallet is for a different blockchain!
(ERROR) armoryengine.pyc:7453 - Wallet is for: Main Network
(ERROR) armoryengine.pyc:7454 - ArmoryEngine: Test Network (testnet3)
(WARNING) armoryengine.pyc:1171 - ***Checksum error! Attempting to fix...
(WARNING) armoryengine.pyc:1195 - Checksum fix failed
Unhandled Error
Traceback (most recent call last):
File "ArmoryQt.py", line 3629, in

File "qt4reactor.pyc", line 329, in iterate

--- ---
File "twisted\internet\base.pyc", line 800, in runUntilCurrent

File "ArmoryQt.py", line 930, in execIntroDialog

File "ArmoryQt.py", line 2427, in execImportWallet

File "ArmoryQt.py", line 2442, in execGetImportWltName

File "armoryengine.pyc", line 7567, in readWalletFile

File "armoryengine.pyc", line 2594, in unserialize

armoryengine.UnserializeError: Checksum mismatch in addrStr
(ERROR) ArmoryQt.py:1042 - Could not access latest Armory version information
(ERROR) ArmoryQt.py:1043 - Tried: http://bitcoinarmory.com/versions.txt
(ERROR) armoryengine.pyc:7452 - Requested wallet is for a different blockchain!
(ERROR) armoryengine.pyc:7453 - Wallet is for: Main Network
(ERROR) armoryengine.pyc:7454 - ArmoryEngine: Test Network (testnet3)
(WARNING) armoryengine.pyc:1171 - ***Checksum error! Attempting to fix...
(WARNING) armoryengine.pyc:1195 - Checksum fix failed
(ERROR) Traceback (most recent call last):
File "ArmoryQt.py", line 2427, in execImportWallet
File "ArmoryQt.py", line 2442, in execGetImportWltName
File "armoryengine.pyc", line 7567, in readWalletFile
File "armoryengine.pyc", line 2594, in unserialize
UnserializeError: Checksum mismatch in addrStr

Traceback (most recent call last):
File "ArmoryQt.py", line 2427, in execImportWallet
self.execGetImportWltName()
File "ArmoryQt.py", line 2442, in execGetImportWltName
doScanNow=False)
File "armoryengine.pyc", line 7567, in readWalletFile
File "armoryengine.pyc", line 2594, in unserialize
armoryengine.UnserializeError: Checksum mismatch in addrStr
(ERROR) ArmoryQt.py:649 - 8 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:654 - File mempool.bin does not exist. Nothing deleted.

Edit: This is on version .82.2-alpha

I have a wallet with multiple addresses in it. I recently created a new receive address in it, copied it and then sent some coins to that address. I got the notice from Armory that coins were received. I noticed in the wallet view however that the unconfirmed amount didn't increase by the coins I sent. The coins did show next to the appropriate address in the wallet. If I close the wallet view and then reopen it, the unconfirmed did update to the appropriate amount. Once there was a confirmation is where things got really weird. One of my other addresses, which had received coins at some point, is actually being credited with above referenced transaction. The new address I just created isn't showing any transactions in armory. blockchain.info does show the new address as having received the coins. My next step was to reload armory to see if that fixed it, which it did. It seems there are display issues. I didn't think to take screen captures until I was already reloading armory.

Armory is not scanning the full block chain. So I do not have access to my full wallet value. Last blockchain block shown by Armory is 230711. Last blockchain block shown by bitcoind is 230937

I have restarted the program multiple times. Scanning always stops at the same block (230711).

No error is indicated by Armory itself.

Configuration
Armory Version 0.87.2 beta
Running on Ubuntu:
uname -a shows "Linux 3.5.0-27-generic #46-Ubuntu SMP Mon Mar 25 19:58:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux"
Bitcoind is running on same computer in version 0.8.1

bitcoind getinfo shows:

{
"version" : 80100,
"protocolversion" : 70001,
"walletversion" : 60000,
"balance" : 0.00000000,
"blocks" : 230937,
"connections" : 24,
"proxy" : "",
"difficulty" : 7672999.92016414,
"testnet" : false,
"keypoololdest" : 1359399334,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"unlocked_until" : 0,
"errors" : ""

}

I'm in the testing branch, so the default behavior is that Armory wants to start bitcoind itself and requires me to close the running one. However, I changed this in the settings.

When I have a bitcoind client running that is fully synced (same getblockcount as blockexplorer.com), Armory keeps thinking it has to wait:

http://screencloud.net/v/dDoA

The "Go Online !" button also doesn't change anything and so seems not to work.

Again, I use Armory with Linux, testing branch. Last commit is 8af1b12.

I tried to compile new version but error has occurred.

[piotrek@localhost BitcoinArmory]$ make
cd cppForSwig; make swig
make[1]: Entering directory /home/piotrek/Apps/Bitcoin/BitcoinArmory/cppForSwig' g++ -shared -lpthread UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a libpython2.6.a CppBlockUtils_wrap.o -o ../_CppBlockUtils.so g++: error: libpython2.6.a: No such file or directory make[1]: *** [swig] Error 1 make[1]: Leaving directory/home/piotrek/Apps/Bitcoin/BitcoinArmory/cppForSwig'
make: *** [all] Error 2

python-libs is installed but this time it might be my fault.

When i try to create a wallet i get this (.armory/armorylog.txt):

2012-11-30 17:45 (INFO) -- qtdialogs.py:332 - KDF takes 60.00 seconds and 8589934592 bytes
2012-11-30 17:45 (INFO) -- armoryengine.py:6505 - ***Creating new deterministic wallet
2012-11-30 17:45 (INFO) -- armoryengine.py:6511 - (with encryption)
2012-11-30 17:45 (INFO) -- armoryengine.py:6513 - Target (time,RAM)=(60.000,8589934592)
2012-11-30 17:45 (ERROR) -- Traceback (most recent call last):
  File "/usr/share/armory/ArmoryQt.py", line 2110, in createNewWallet
    doRegisterWithBDM=False)
  File "/usr/share/armory/armoryengine.py", line 6515, in createNewWallet
    kdfTargSec, kdfMaxMem)
  File "/usr/share/armory/armoryengine.py", line 7082, in computeSystemSpecificKdfParams
    kdf.computeKdfParams(targetSec, long(maxMem))
  File "/usr/share/armory/CppBlockUtils.py", line 1611, in computeKdfParams
    def computeKdfParams(self, targetComputeSec=0.25, maxMemReqtsBytes=32*1024*1024): return _CppBlockUtils.KdfRomix_computeKdfParams(self, targetComputeSec, maxMemReqtsBytes)
NotImplementedError: Wrong number or type of arguments for overloaded function 'KdfRomix_computeKdfParams'.
  Possible C/C++ prototypes are:
    KdfRomix::computeKdfParams(double,uint32_t)
    KdfRomix::computeKdfParams(double)
    KdfRomix::computeKdfParams()

I'd like to be able to include the balance from bitcoin addresses in my Armory BTC total without the need to use the private key.

This would be useful for watching the balance sent to a paper wallet or from a Casascius coin where I don't want to use (or don't have access to yet in the case of Casascius coins) the private key.

Currently, it looks like I can create a watching only wallet, which sounds like it would work, but I don't see a way to do this without using the private key on the offline computer. At the moment, the best way I know to do this is to check a balance by looking up the address on Blockchain.info.

If there is already a way to do this in Armory, I'd love to know how.

It is the 3rd time I try to sent 0.01 BTC to SatoshiDice, to 3 different address...
I restart the Armory client in between, always the same result...

the transaction is not accepted by the Bitcoin Network ...

Why is that ??

2012-12-20 00:04 (INFO) -- qtdialogs.pyc:5275 - Change address behavior: NewAddr
2012-12-20 00:04 (INFO) -- (PPRINT from ArmoryQt.py:2327)

01000000 0125070e 300bceb9 d670ab0d ebeb5035 95aadccf 843c94b0 6a76b2aa
5af4eae2 75000000 008a4730 4402203d 3b90b694 cd4aff9f b0b8da94 1ccb025d
785eef9b e298ae10 47716636 35e19e02 202a559e 491878fd b84b113f 43c711e0
46bfc006 2f896a76 e36659ab ddcaeae0 cf014104 e7485bbc 563e326c 8655470c
45cbf0f5 8dda03c0 54ce86a2 6d67c156 6788befc f0b44241 d931924a 3d6989ca
323c9fc4 88d11d78 f3148b30 9e5f630c c61ca152 ffffffff 0240420f 00000000
001976a9 1406f1b6 71630994 8fa3b07b 0a6b6680 4fdfd687 3188ac95 f7130b00
00000019 76a91496 b724fb00 022be7eb 9757b73d 88fee76b dcfb9a88 ac000000
00
2012-12-20 00:04 (INFO) -- (PPRINT from ArmoryQt.py:2328)
Transaction:
TxHash: 890228277a19d47730ced97e6bebfab34ee39dce414e05f8a5db92bdf0ec80de (BE)
Version: 1
nInputs: 1
nOutputs: 2
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: 75e2eaf45aaab2766ab0943c84cfdcaa953550ebeb0dab70d6b9ce0b300e0725 (BE)
TxOutIndex: 0
Script: (47304402203d3b90b694cd4aff9fb0b8da941ccb025d785eef9be298ae104771)
Sender: 1DsdJxo9bBNwns2YReBTMLwNKQV6fgT3JK
Seq: 4294967295
Outputs:
TxOut:
Value: 1000000 ( 0.01 )
Script: OP_DUP OP_HASH (1diceDCd27Cc22HV3qPNZKwGnZ8QwhLTc) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 185857941 ( 1.85857941 )
Script: OP_DUP OP_HASH (1EjuksiQtzZ3inkeTprTnsyWm9KbjoSHmC) OP_EQUAL OP_CHECKSIG

2012-12-20 00:04 (INFO) -- ArmoryQt.py:2334 - Sending Tx, de80ecf0bd92dba5f8054e41ce9de34eb3faeb6b7ed9ce3077d4197a27280289
2012-12-20 00:04 (INFO) -- armoryengine.pyc:9378 - sendTx called...
2012-12-20 00:04 (INFO) -- ArmoryQt.py:2336 - Transaction sent to Satoshi client...!
2012-12-20 00:05 (ERROR) -- ArmoryQt.py:2361 - Transaction was not accepted by the Satoshi client
2012-12-20 00:05 (ERROR) -- ArmoryQt.py:2362 - Raw transaction:
2012-12-20 00:05 (ERROR) -- (PPRINT from ArmoryQt.py:2363)

01000000 0125070e 300bceb9 d670ab0d ebeb5035 95aadccf 843c94b0 6a76b2aa
5af4eae2 75000000 008a4730 4402203d 3b90b694 cd4aff9f b0b8da94 1ccb025d
785eef9b e298ae10 47716636 35e19e02 202a559e 491878fd b84b113f 43c711e0
46bfc006 2f896a76 e36659ab ddcaeae0 cf014104 e7485bbc 563e326c 8655470c
45cbf0f5 8dda03c0 54ce86a2 6d67c156 6788befc f0b44241 d931924a 3d6989ca
323c9fc4 88d11d78 f3148b30 9e5f630c c61ca152 ffffffff 0240420f 00000000
001976a9 1406f1b6 71630994 8fa3b07b 0a6b6680 4fdfd687 3188ac95 f7130b00
00000019 76a91496 b724fb00 022be7eb 9757b73d 88fee76b dcfb9a88 ac000000
00
2012-12-20 00:05 (ERROR) -- ArmoryQt.py:2364 - Transaction details
2012-12-20 00:05 (ERROR) -- (PPRINT from ArmoryQt.py:2365)
Transaction:
TxHash: 890228277a19d47730ced97e6bebfab34ee39dce414e05f8a5db92bdf0ec80de (BE)
Version: 1
nInputs: 1
nOutputs: 2
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: 75e2eaf45aaab2766ab0943c84cfdcaa953550ebeb0dab70d6b9ce0b300e0725 (BE)
TxOutIndex: 0
Script: (47304402203d3b90b694cd4aff9fb0b8da941ccb025d785eef9be298ae104771)
Sender: 1DsdJxo9bBNwns2YReBTMLwNKQV6fgT3JK
Seq: 4294967295
Outputs:
TxOut:
Value: 1000000 ( 0.01 )
Script: OP_DUP OP_HASH (1diceDCd27Cc22HV3qPNZKwGnZ8QwhLTc) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 185857941 ( 1.85857941 )
Script: OP_DUP OP_HASH (1EjuksiQtzZ3inkeTprTnsyWm9KbjoSHmC) OP_EQUAL OP_CHECKSIG

2012-12-20 00:09 (INFO) -- qtdialogs.pyc:5275 - Change address behavior: NewAddr
2012-12-20 00:09 (INFO) -- (PPRINT from ArmoryQt.py:2327)

01000000 0125070e 300bceb9 d670ab0d ebeb5035 95aadccf 843c94b0 6a76b2aa
5af4eae2 75000000 008a4730 4402205f bc7c7128 963c761a 1cb297e5 916044d4
ee2fabbf 1250e852 34e4dd2e bf996d02 2079b516 99779c29 7f4fe549 42073153
906c0f75 e96ad761 9c9210e5 dd7e1483 0f014104 e7485bbc 563e326c 8655470c
45cbf0f5 8dda03c0 54ce86a2 6d67c156 6788befc f0b44241 d931924a 3d6989ca
323c9fc4 88d11d78 f3148b30 9e5f630c c61ca152 ffffffff 0295f713 0b000000
001976a9 14bdafcd 14a0ac0f 1929a857 c3247208 375c5421 3e88ac40 420f0000
00000019 76a91406 f1b677d2 63b73281 51f1775b 80e83fca 177d1a88 ac000000
00
2012-12-20 00:09 (INFO) -- (PPRINT from ArmoryQt.py:2328)
Transaction:
TxHash: 5301a31ce09a9fa3ee590c246a5be5af64868dbcb2571ebf7cae23a010ee7484 (BE)
Version: 1
nInputs: 1
nOutputs: 2
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: 75e2eaf45aaab2766ab0943c84cfdcaa953550ebeb0dab70d6b9ce0b300e0725 (BE)
TxOutIndex: 0
Script: (47304402205fbc7c7128963c761a1cb297e5916044d4ee2fabbf1250e85234e4)
Sender: 1DsdJxo9bBNwns2YReBTMLwNKQV6fgT3JK
Seq: 4294967295
Outputs:
TxOut:
Value: 185857941 ( 1.85857941 )
Script: OP_DUP OP_HASH (1JHyK8Z8XP5NmUaMqeCS6jBVNmW2jx6cbz) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 1000000 ( 0.01 )
Script: OP_DUP OP_HASH (1dicec9k7KpmQaA8Uc8aCCxfWnwEWzpXE) OP_EQUAL OP_CHECKSIG

2012-12-20 00:09 (INFO) -- ArmoryQt.py:2334 - Sending Tx, 8474ee10a023ae7cbf1e57b2bc8d8664afe55b6a240c59eea39f9ae01ca30153
2012-12-20 00:09 (INFO) -- armoryengine.pyc:9378 - sendTx called...
2012-12-20 00:09 (INFO) -- ArmoryQt.py:2336 - Transaction sent to Satoshi client...!
2012-12-20 00:09 (ERROR) -- ArmoryQt.py:2361 - Transaction was not accepted by the Satoshi client
2012-12-20 00:09 (ERROR) -- ArmoryQt.py:2362 - Raw transaction:
2012-12-20 00:09 (ERROR) -- (PPRINT from ArmoryQt.py:2363)

01000000 0125070e 300bceb9 d670ab0d ebeb5035 95aadccf 843c94b0 6a76b2aa
5af4eae2 75000000 008a4730 4402205f bc7c7128 963c761a 1cb297e5 916044d4
ee2fabbf 1250e852 34e4dd2e bf996d02 2079b516 99779c29 7f4fe549 42073153
906c0f75 e96ad761 9c9210e5 dd7e1483 0f014104 e7485bbc 563e326c 8655470c
45cbf0f5 8dda03c0 54ce86a2 6d67c156 6788befc f0b44241 d931924a 3d6989ca
323c9fc4 88d11d78 f3148b30 9e5f630c c61ca152 ffffffff 0295f713 0b000000
001976a9 14bdafcd 14a0ac0f 1929a857 c3247208 375c5421 3e88ac40 420f0000
00000019 76a91406 f1b677d2 63b73281 51f1775b 80e83fca 177d1a88 ac000000
00
2012-12-20 00:09 (ERROR) -- ArmoryQt.py:2364 - Transaction details
2012-12-20 00:09 (ERROR) -- (PPRINT from ArmoryQt.py:2365)
Transaction:
TxHash: 5301a31ce09a9fa3ee590c246a5be5af64868dbcb2571ebf7cae23a010ee7484 (BE)
Version: 1
nInputs: 1
nOutputs: 2
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: 75e2eaf45aaab2766ab0943c84cfdcaa953550ebeb0dab70d6b9ce0b300e0725 (BE)
TxOutIndex: 0
Script: (47304402205fbc7c7128963c761a1cb297e5916044d4ee2fabbf1250e85234e4)
Sender: 1DsdJxo9bBNwns2YReBTMLwNKQV6fgT3JK
Seq: 4294967295
Outputs:
TxOut:
Value: 185857941 ( 1.85857941 )
Script: OP_DUP OP_HASH (1JHyK8Z8XP5NmUaMqeCS6jBVNmW2jx6cbz) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 1000000 ( 0.01 )
Script: OP_DUP OP_HASH (1dicec9k7KpmQaA8Uc8aCCxfWnwEWzpXE) OP_EQUAL OP_CHECKSIG

Wallets cannot be protected by passphrases containing certain ascii characters.

Example:
Generating a new wallet will fail when using the character "é" (extended ascii code 130). After the third time confirmation of the passphrase Armory will drop back to the "Set Encryption Passphrase"-Dialog.

This occurs also if using other special characters like ascii 127, 131, 132....

Armory 0.88 can't autodetect bitcoin-qt (version v0.8.1.0-g34d62a8-beta). I've also tried using the setup to specify the path "/usr/bin/". The bitcoin-qt binary is in that directory. I installed bitcoin-qt from the bitcoin precise ppa (http://ppa.launchpad.net/bitcoin), and Armory was using this bitcoin-qt installation just fine before the 0.88 update.

When I run Armory on the command line I get this:

(ERROR) ArmoryQt.py:1214 - Failed to setup SDM
Traceback (most recent call last):
File "/usr/share/armory/ArmoryQt.py", line 1210, in startBitcoindIfNecessary
extraExeSearch=self.satoshiExeSearchPath)
File "/usr/share/armory/armoryengine.py", line 10456, in setupSDM
if self.failedFindExe: raise self.BitcoindError, 'bitcoind not found'
BitcoindError: bitcoind not found

If I start bitcoin-qt first, I get a message saying "Please close Bitcoin-Qt".

Using an encrypted wallet, clicking Get Keys From Wallet after entering a wallet address and clicking Calculate does nothing. I think this is because it cannot open the DlgUnlockWallet while the message signing dialog is open. I verified that this is not a problem with an unencrypted wallet.

As discussed via email with Alan Reiner, I am getting this error after a few hours on a fresh install of Win7 Enterprise 64bit.
The crash is after a ramdom number of blocks
I have Satoshi bitcoin-qt 0.6.3 installed
I was running from source but it crashed the same with the normal install version.
I also tried the Logger branch with the same results

D:\Temp\Armory-Git\BitcoinArmory>python ArmoryQt.py

Loading Armory Engine:
Armory Version: 0.81
PyBtcAddress Version: 1.00
PyBtcWallet Version: 1.35
Detected Operating system: Windows
User home-directory : C:\Users\FJ\AppData\Roaming
Satoshi BTC directory : C:\Users\FJ\AppData\Roaming\Bitcoin
Armory home dir : C:\Users\FJ\AppData\Roaming\Armory
Using settings file: C:\Users\FJ\AppData\Roaming\Armory\ArmorySettings.txt
Loading wallets...
Number of wallets read in: 1
Wallet (XXX): "Primary Wallet " (Encrypted)
Internet connection is Available: True
Bitcoin-Qt/bitcoind is Available: True
Loading blockchain
Opening file 1: C:\Users\FJ\AppData\Roaming\Bitcoin/blk0001.dat
Highest blkXXXX.dat file: 1
Attempting to read blockchain from file:
C:\Users\FJ\AppData\Roaming\Bitcoin/blk0001.dat
C:\Users\FJ\AppData\Roaming\Bitcoin/blk0001.dat is 1946.71 MB
Memory pool file was corrupt. Deleted. (no further action is needed)
Syncing wallets with blockchain...
Syncing wallet: XXXXXX
Loading blockchain took 33.7 seconds
Usermode: Expert
Handshake finished, connection open!
Added new blocks to memory pool: 1
New Block! : 187772
Added new blocks to memory pool: 1
New Block! : 187773
**ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
*__ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
*__ERROR: parseNewBlockData did not get enough data...
**ERROR: parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!

When I try to run ArmoryQt.py from the testing branch, I get this error:

Traceback (most recent call last):
  File "ArmoryQt.py", line 28, in <module>
    import psutil
ImportError: No module named psutil

Hi all, I had a weird warning when sending Bitcoins from an offline wallet recovered from paper backup (I was testing the process). After broadcasting the signed transaction via the watch-only wallet, I had a popup and stdout warning:

Added new blocks to memory pool: 1
Signature 0 is valid!
(ERROR) ArmoryQt.py:1922 - Transaction was not accepted by the Satoshi client
(ERROR) ArmoryQt.py:1923 - Raw transaction:
(ERROR) (PPRINT from /usr/share/armory/ArmoryQt.py:1924)

However the transaction seemed to be validated anyway later on, I made an extra transaction to see if I could reproduce this warning, but everything seemed to go fine this second time... Do I have to worry about my wallet?

Thanks,

Camille.

The mentioned sum in the signed file is: 324a2be5c310f3a403f87b34bb2550f2
The md5sum of the downloaded file is: 73fa7b5831fd59f68925ef5ce7493327

But checking the deb with "dpkg-sig" and checking the "armory_0.86-beta_md5.txt.asc" with gpg leads me to correct signatures. Checking the "armory_0.86-beta_windows_all.msi " everything seems fine.

Could you look into that and correct the md5sum if it is incorrect?

Thank you very much.

There is a bug in Crypto++ implementation of Rijndael that causes infinite recursion on some AMD64 systems. Rijndael is used in AutoSeededRandomPool, which is used in Armory. The bug is fixed Crypto++ repository: http://cryptopp.svn.sourceforge.net/viewvc/cryptopp?view=revision&revision=523

Hi,

Well I suppose this question would come up sooner or later so I might as well "break the lance" in favour of it. So, here goes:

With LTC becoming more popular as a lightweight BTC variant, could you consider supporting LTC with Armory?

Reproduce:

1. Need two wallets in Armory, call them W1 and W2. Need some fund in W2.
2. Create a new receiving address in W1, call it A1; do nothing with it (or eg. send it to someone as a payment request by email)
3. Create a new payment from W2 to W1 (I used max, ie. all funds in W2):
   • Click Send Bitcoins in main screen
   • Select W2
   • Under Enter Recipients, Address 1, click Select from Address Book
   • Select W1
   • Send

I would expect a new receiving address in W1 to be generated for this payment. But instead the address A1 is used.

If I then repeat step 3, a new receiving address in W1 is created, as I would expect.

Please make it possible to run Armory without the need for bitcoind or bitcoin-qt by providing credentials to an RPC instance to use as back-end.

For instance, I have a bitcoin server at home, which I could use as a back-end for Armory, instead of having to store the blockchain on my laptop and having to sync it all the time.

While creating a new wallet it is possible to choose the button "Adv. Encrypt Options" and improve encryption parameters. If you import a Paper Backup these options are not available thus you can create an encrypted wallet but with poor encryption parameters. Thanks for all your effort!

BIP10 defined the transaction serialization format, which is implemented by serializeAscii at armoryengine.py#L4704.

This will include the SIG of any TxInputs, so that an offline signer with no blockchain can verify the amount of coin in the OutPoints, to prevent a MITM from giving unexpectedly large unspent outputs to miners.

I have a watch-only wallet on a connected Armory instance on Test-Net which is up-to-date (latest block). I'm sending coins to an address outside the wallet, with change going back into the watch-only wallet. I'm running 0.87.2.

Click 'Prepare Offline Transaction', inside the watch-only wallet. Enter Mojocoin faucet address as the destination, and choose to send 5 coins. Enter an amount and click 'Create Unsigned Transaction'. I'm not seeing any SIG blocks in the output from Armory:

-----BEGIN-TRANSACTION-B9gpPdps-------------------------------------------------
_TXDIST_0b110907_B9gpPdps_0077

_TXINPUT_00_42.99950000
-------END-TRANSACTION-B9gpPdps-------------------------------------------------

I expected to see a SIG line for the _TXINPUT_00, but there is none.

Here's the serializeAscii() function adding signatures...
for s,sig in enumerate(self.signatures[iin]):
if len(sig)==0:
continue
addrB58 = hash160_to_addrStr(self.inAddr20Lists[iin][s])
sigsz = int_to_hex(len(sig), widthBytes=2, endOut=BIGENDIAN)
txdpLines.append('SIG%s_%02d_%s' % (addrB58, iin, sigsz))
sigHex = binary_to_hex(sig)
for byte in range(0,len(sigHex),80):
txdpLines.append( sigHex[byte:byte+80] )

So self.signatures[iin] must not have the signatures. It looks like these are inserted by 'appendSignature' function, which itself does not appear to ever get called.

i haven't tried to reference the a larger input and prove that I can fool the offline signer -- but it seems like if SIG is not there, this is enough evidence of a bug?

Hi,

whenever a new transaction comes in, Armory asks to select Growlhelper via a filechooser from a list of applications.

Regardless of what I am doing (choosing Growl.app, any other app, or simply clicking cancel) Armory crashes after showing that dialogue.

I have Growl 2 installed, am running Lion and tried revision 4 and 5 from Higuieses armory-build.

I tried it with Growl running and not running.

If I can provide any more information, please let me know (:

Hi, thanks for this nice piece of software!

I would like to suggest few features to enforce the physical protection of the data for both offline digital wallets and paper wallets.

The current design works if no one gets its hands (or eyes!) on the paper backup, but if someone does, they can easily "steal" it without anyone noticing (writing down the code, taking a picture of the paper, etc.) because the paper is still there, in its safe place, where it's supposed to be... While the wrong doers can instantiate a copy of the wallet, watch funds coming, and runaway with it when there is enough for them :-p

So, the first feature I would suggest is an option not to print the Armory logo, I have nothing against the logo, but if it's not there no one can really know what this random piece of paper with (QR)codes stands for, so they might just leave it there (the word "wallet" and things that might help identifying the purpose of the paper should IMHO be optional as well)...

The second feature would be for a worst case scenario: where the wrong doers know what the paper stands for. In that case, I think it might be useful to allow the data to be encrypted (simple password+AES for example), thus it would be useless for them.

I think these are the major breaches in physical data protection.

But, I also think that there are minor breaches on the computer data as well... The wallet can be encrypted, right, that's the most important, but what about the temp files? For example, I tried to edit a PDF paper wallet with Inkscape before printing it, so there is unencrypted data standing on the filesystem (even on the harddrive after deletion), and, after printing it with CUPS there is probably some PostScript temporary files around in the system that can be exploited (on some installations you can simply go to the CUPS interface http://localhost:631/ to restart a printing job without having the source, etc.). There is also the step to restore a paper wallet that directly writes an unencrypted version of the wallet, it can be encrypted after, right, but I guess that unencrypted data remains on the hard drive from the initial restore? I think that some of these breaches can be worked around outside Armory (e.g. using a tmpfs partition and reboot) but some could/should be within Armory (e.g. atomic "zero fill" of an unencrypted file before deletion, etc.).

I hope this is helpful, I didn't dive into the code yet, but I can participate if anyone wants to start implementing some of these feature requests.

Bests,

Camille.

[piotrek@piotrek cppForSwig]$ make swig
Makefile:44: uwaga: polecenia zakrywające dla obiektu UniversalTimer.o' Makefile:41: uwaga: ignoruję stare polecenia dla obiektuUniversalTimer.o'
g++ -c -O2 -pipe -fPIC -Icryptopp -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS UniversalTimer.cpp
g++ -c -O2 -pipe -fPIC -Icryptopp -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS BinaryData.cpp
In file included from cryptopp/filters.h:7:0,
from cryptopp/randpool.h:5,
from cryptopp/osrng.h:10,
from BinaryData.h:63,
from BinaryData.cpp:9:
cryptopp/secblock.h: In instantiation of ‘CryptoPP::AllocatorWithCleanup<T, T_Align16>::pointer CryptoPP::AllocatorWithCleanup<T, T_Align16>::allocate(CryptoPP::AllocatorWithCleanup<T, T_Align16>::size_type, const void_) [with T = unsigned char; bool T_Align16 = false; CryptoPP::AllocatorWithCleanup<T, T_Align16>::pointer = unsigned char_; CryptoPP::AllocatorWithCleanup<T, T_Align16>::size_type = long unsigned int]’:
cryptopp/secblock.h:247:19: required from ‘CryptoPP::SecBlock<T, A>::SecBlock(CryptoPP::SecBlock<T, A>::size_type) [with T = unsigned char; A = CryptoPP::AllocatorWithCleanup; CryptoPP::SecBlock<T, A>::size_type = long unsigned int]’
cryptopp/algparam.h:17:2: required from here
cryptopp/secblock.h:91:3: error: ‘CheckSize’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
cryptopp/secblock.h:91:3: note: declarations in dependent base ‘CryptoPP::AllocatorBase’ are not found by unqualified lookup
cryptopp/secblock.h:91:3: note: use ‘this->CheckSize’ instead
make: *** [BinaryData.o] Błąd 1

I removed a wallet that has had transactions in it, and Armory gave me an exception:

Unhandled Error
Traceback (most recent call last):
  File "/opt/BitcoinArmory/ArmoryQt.py", line 2618, in <module>
    os._exit(QAPP.exec_())
  File "/opt/BitcoinArmory/qt4reactor.py", line 231, in _iterate
    self.runUntilCurrent()
--- <exception caught here> ---
  File "/usr/lib/python2.7/site-packages/twisted/internet/base.py", line 800, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/opt/BitcoinArmory/ArmoryQt.py", line 2373, in Heartbeat
    func()
  File "/opt/BitcoinArmory/ArmoryQt.py", line 2412, in doTheSystemTrayThing
    wlt = self.walletMap[wltID]
exceptions.KeyError: 'yeo6QvH5'

I'm using Kubuntu 12.04 32bit, latest bit and the .deb from armory site v. 0.82.2

Armory does not accept a password with any of the three letters ä, ö, or å. Likewise, a wallet name with any of the three letters will crash the wallet creation. Other letters may also be accepted but I only tested the three.

How to reproduce:
Click "Create New Wallet" on armory main screen.
Type in wallet name and click Accept.
Type in a password with ä, ö or å in it. Click Accept.
Type the same password third time to confirm it.

Expected outcome:
Creation of new wallet.

Actual Outcome:
Crashing of the confirmation dialog.

If you have given a wallet address a label, that name appears in the transaction and help to track transactions. You can also give any transaction a custom comment. But I think what is missing is a possibility to delete a comment and restore the 'automated' comment. Right now, if you change/delete a transaction comment then it'll just remain blank.

I hope this makes sense and if possible I'd like this feature to be added...

Since more and more usb-key viruses appear, it would be great to securely transfer transactions between online and offline wallets. Since these transactions don't consist of much data it could be possible to transfer them as QR-Code. This is almost implemented.

• The online client would create a QR of the unsinged transaction.
• The QR-Code could be read with a cam on the offline computer. The QR could be either read by an external program and saved as file which is then opened by the offline client, or it could be read directly into the offline client if armory would support that cam.
• We can use the same method to get that signed transaction back into the online client.

This way direct data exchange between these computers is not needed and thus more secure.

So long,
b52

Sorry for my previous 2 issues, I forgot to re-build the project.

Now I got a real one. After starting, Armory started scanning the transaction history.
For some reason it stopped at 96% and when it hung there for a while I noticed that python was taking up 100% of its CPU thread.
That's now already for 5-10 minutes, so I think it will last indefinitely, I will restart in a second if it persists.

This is how it looks like: http://screencloud.net/v/CMo4

I don't see a problem in the log file: https://gist.github.com/stevenroose/6bef26278802ee2d6fd4

Btw, just a question, is the transaction checking sequential or parallel? I noticed that now it takes only 1 thread on my CPU, so I'd guess it's sequential. Can't this check be done in a parallel way?