Armory - Discussion Thread

[goatpig]

Hi Folks!

Question for Armoryd / Armoryengine

I noticed that some transactions are not getting to mainbranch, and for this reason the Tx never gets confirmed.
At this moment I dont know why it happens. Over 25.000 transactions on Testnet and maybe 50 cases on which happens the mainbranch issue.

Is there a way to detect the "scrap" items on armory core?
At this moment the one and only working solution I got is to restart the watching only wallet service.
After restarting armory service the TxId just dissapears and I mark them as "Scrap" in database and reissue the Tx creating a new one.


Is there a way to ask Armory core if the transaction is really a "scrap" item?
And how can it happen that the Tx does not get into the Mainbranch? (all tests are done over testnet so far)

Best regards

Submitting a Tx doesn't guarantee it will be mined, even if the network accepts it as valid. Im not sure the concept of "scrap" is part of Armory. What you should be doing is monitoring the number on confirmations of your broadcasted transactions against ("current top block" - "block the tx was broadcasted at"). This is how you will know whether your txn are getting mined or not.

[1714805973]

1714805973

[1714805973]

1714805973

[1714805973]

1714805973

[po0kie]

yeah the problem is when goes armory to discard the tx?
As the next tx for the same address will spend the same outputs.
How can we discard the previous spent outputs, to be submitted a new time?
At this moment the one and only possibility I have is to restart the service
then the spended outputs are getting "unspent" again, is there a way to mark them as unspent
in a "manual / programmatic" way?

[goatpig]

yeah the problem is when goes armory to discard the tx?
As the next tx for the same address will spend the same outputs.
How can we discard the previous spent outputs, to be submitted a new time?
At this moment the one and only possibility I have is to restart the service
then the spended outputs are getting "unspent" again, is there a way to mark them as unspent
in a "manual / programmatic" way?

There is currently no code in Armory core for the user to cherry pick ZC transactions in the backend container. You either wipe the entire container or use it as a whole. Granted it would be very easy to add, Im not sure that would fix your issue.

Bitcoin Core will not let you broadcast a transaction that spends a UTXO already consumed by a ZC transaction. You'd have to restart Bitcoin Core or somehow clear its ZC pool.

[Nathonas]

Hello everyone, I've been using Armory since last year and I was just wondering what is the best way to update the client? I currently have version 0.88. Do I have to uninstall it and download the latest version? Or is there a way to update it?

edit: Also my Armory folder under app data/Roaming is 30 gbs. Is that normal?

[bitpop]

Hello everyone, I've been using Armory since last year and I was just wondering what is the best way to update the client? I currently have version 0.88. Do I have to uninstall it and download the latest version? Or is there a way to update it?

edit: Also my Armory folder under app data/Roaming is 30 gbs. Is that normal?

Just download

New version will download for you

Yes that's normal

[acegilz]

is there any way yo bulk transfer to multiple recipients?

I mean, I am developing a web application and would like to have the possibility of export some kind of list instead of process one transaction at each time.. thanks

[bitpop]

is there any way yo bulk transfer to multiple recipients?

I mean, I am developing a web application and would like to have the possibility of export some kind of list instead of process one transaction at each time.. thanks

Try armoryd

[acegilz]

is there any way yo bulk transfer to multiple recipients?

I mean, I am developing a web application and would like to have the possibility of export some kind of list instead of process one transaction at each time.. thanks

Try armoryd

thanks for reply but I would like to use some GUI managed by windows, any chance?

[bitpop]

is there any way yo bulk transfer to multiple recipients?

I mean, I am developing a web application and would like to have the possibility of export some kind of list instead of process one transaction at each time.. thanks

Try armoryd

thanks for reply but I would like to use some GUI managed by windows, any chance?

No but you can donate asking for csv

[teste]

Hi,

I have a problem:

1- I hibernate the laptop with Armory opened.
2- I back from hibernate.
3- Armory doesnt syncronize. (To syncronize again I need to restart Armory).

OS: Ubuntu 64

[goatpig]

Hi,

I have a problem:

1- I hibernate the laptop with Armory opened.
2- I back from hibernate.
3- Armory doesnt syncronize. (To syncronize again I need to restart Armory).

OS: Ubuntu 64

Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.

[teste]

Hi,

I have a problem:

1- I hibernate the laptop with Armory opened.
2- I back from hibernate.
3- Armory doesnt syncronize. (To syncronize again I need to restart Armory).

OS: Ubuntu 64

Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.

 

[teste]

Hi,

I have a problem:

1- I hibernate the laptop with Armory opened.
2- I back from hibernate.
3- Armory doesnt syncronize. (To syncronize again I need to restart Armory).

OS: Ubuntu 64

Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.

Why Bitcoin-Qt Core is able to recover syncronization from hibernation and Armory cant?

[teste]

Hi,

I have a problem:

1- I hibernate the laptop with Armory opened.
2- I back from hibernate.
3- Armory doesnt syncronize. (To syncronize again I need to restart Armory).

OS: Ubuntu 64

Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.

Why Bitcoin-Qt Core is able to recover syncronization from hibernation and Armory cant?

When this be implemented, will help in any way?: https://github.com/bitcoin/bitcoin/issues/4124

[chrisrico]

Why Bitcoin-Qt Core is able to recover syncronization from hibernation and Armory cant?

When this be implemented, will help in any way?: https://github.com/bitcoin/bitcoin/issues/4124

No, that won't help. Armory is using mlock to help store your keys securely.

mlock() locks part of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area

The goal here is that your unencrypted private keys are never written to disk (swap) where they could more easily be recovered.

[HowlingMad]

I noticed a problem with 0.91.2 -
I had recently re-installed everything on my computer and rebuilt everything.  With Armory, I had loaded the first two wallets that I have and processed the block chain until the balances were shown. 

I added a fourth wallet and Armory has sat at "Scanning Transaction History" and "100%" for almost an hour.  The last entries in the log are:
INFO  - 1402836130: (..\BlockUtils.cpp:4567) Scanning Wallet #1 from height 0
-INFO  - 1402836131: (..\BlockUtils.cpp:4567) Scanning Wallet #2 from height 0
-INFO  - 1402836138: (..\BlockUtils.cpp:4567) Scanning Wallet #3 from height 0
-INFO  - 1402836145: (..\BlockUtils.cpp:4567) Scanning Wallet #4 from height 0
-INFO  - 1402836146: (..\BlockUtils.cpp:4888) Saving wallet history to DB
-INFO  - 1402836146: (..\BlockUtils.cpp:5920) Enabling zero-conf tracking (lite)
-DEBUG - 1402836657: (..\BlockUtils.cpp:5599) Organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5723) Done organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5599) Organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5723) Done organizing chain
-INFO  - 1402836657: (..\BlockUtils.cpp:5143) Added new blocks to memory pool: 2
-INFO  - 1402836657: (..\BlockUtils.cpp:4888) Saving wallet history to DB

I am using a Lenovo V570 laptop with Win 7 Home x64.   Cpu 25% utilized and 5Gb RAM free.  If I restart Armory, it states 18 minutes to scan transactions. 

Is there are problem in using Bitcoin Core?  or something else going on?
Thanks,

[K1773R]

Hi,

I have a problem:

1- I hibernate the laptop with Armory opened.
2- I back from hibernate.
3- Armory doesnt syncronize. (To syncronize again I need to restart Armory).

OS: Ubuntu 64

Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.

Im happy to see this

[goatpig]

I noticed a problem with 0.91.2 -
I had recently re-installed everything on my computer and rebuilt everything.  With Armory, I had loaded the first two wallets that I have and processed the block chain until the balances were shown. 

I added a fourth wallet and Armory has sat at "Scanning Transaction History" and "100%" for almost an hour.  The last entries in the log are:
INFO  - 1402836130: (..\BlockUtils.cpp:4567) Scanning Wallet #1 from height 0
-INFO  - 1402836131: (..\BlockUtils.cpp:4567) Scanning Wallet #2 from height 0
-INFO  - 1402836138: (..\BlockUtils.cpp:4567) Scanning Wallet #3 from height 0
-INFO  - 1402836145: (..\BlockUtils.cpp:4567) Scanning Wallet #4 from height 0
-INFO  - 1402836146: (..\BlockUtils.cpp:4888) Saving wallet history to DB
-INFO  - 1402836146: (..\BlockUtils.cpp:5920) Enabling zero-conf tracking (lite)
-DEBUG - 1402836657: (..\BlockUtils.cpp:5599) Organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5723) Done organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5599) Organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5723) Done organizing chain
-INFO  - 1402836657: (..\BlockUtils.cpp:5143) Added new blocks to memory pool: 2
-INFO  - 1402836657: (..\BlockUtils.cpp:4888) Saving wallet history to DB

I am using a Lenovo V570 laptop with Win 7 Home x64.   Cpu 25% utilized and 5Gb RAM free.  If I restart Armory, it states 18 minutes to scan transactions. 

Is there are problem in using Bitcoin Core?  or something else going on?
Thanks,

https://bitcoinarmory.com:8443

Make a ticket and attach your log file (the whole thing)

Why Bitcoin-Qt Core is able to recover syncronization from hibernation and Armory cant?

When this be implemented, will help in any way?: https://github.com/bitcoin/bitcoin/issues/4124

No, that won't help. Armory is using mlock to help store your keys securely.

mlock() locks part of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area

The goal here is that your unencrypted private keys are never written to disk (swap) where they could more easily be recovered.

Thats the gist of it, but it isnt limited to unencrypted private key. Pretty much anything crypto (public keys included) is held in mlock'ed memory. 

[teste]

Hi,

I have a problem:

1- I hibernate the laptop with Armory opened.
2- I back from hibernate.
3- Armory doesnt syncronize. (To syncronize again I need to restart Armory).

OS: Ubuntu 64

Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.

Why Bitcoin-Qt Core is able to recover syncronization from hibernation and Armory cant?

Is it possible at least when coming back from hibernation, Armory show a message asking to restart Armory to syncronize again.

[etotheipi]

Nothing can be done about this. Some of Armory's stack is forced in the RAM through mlock. Hibernation copies the entire RAM into the swap partition. Since that would defeat mlock's purpose, mlock'ed memory is not copied imaged in on hibernation. Armory won't be able to recover from that.

I wish this were true, but it's a common misperception about mlock().  mlock() actually cannot prevent keys from getting swapped, and it is pretty much guaranteed if you hibernate.  It's one reason we recommend that high-security device disable swap space entirely -- it's not like you're going to need it running offline Armory, anyway, which has a very limited resource footprint.  And hibernate as well, but I'm not sure hibernate works without a swap partition (good question, but go ahead and disable both). 
 

       Cryptographic  security  software  often  handles  critical bytes like passwords or secret keys as data
       structures.  As a result of paging, these secrets could be transferred onto a persistent swap store medium,  where
       they  might  be  accessible to the enemy long after the security software has erased the secrets in RAM and termi‐
       nated. (But be aware that the suspend mode on laptops and some desktop computers will save a copy of the system's
       RAM to disk, regardless of memory locks.)

Even worse, mlock() cannot guarantee that key material is not paged even outside of hibernate.  mlock() is simply a very strong suggestion not to swap that key data, but if your really stress your system, it might happen.  This is why Armory guarantees that key material stays in RAM self-destructs after 5 seconds of being unlocked.  This pretty much guarantees that the user can't accidentally end up with key data in swap, unless they hibernate within 5 seconds of signing a transaction.  Luckily, Armory enforces a 5 sec delay before showing you if a transaction succeeded