Armory - Discussion Thread

[Justin00]

I've been involved in bitcoins for 2 years. realy realy want to play around with armoury but i find I have no time, or no coins lol.
definetly a must for the next few weeks. Maybe when I have some time off work next.
offline mode seems killer!

[1714121626]

1714121626

[1714121626]

1714121626

[1714121626]

1714121626

[1714121626]

1714121626

[SebastianJu]

Have you yet developed an option to remove the 6 confirmation limit?
if you are a frequent user of your wallet, waiting for 6 confirmations to spend coins can be a huge waiting process.

What does this mean? Cant one spend coins that dont have 6 confs already? That would be a huge downside of armory if true. Maybe you mean something different.

[goatpig]

Only coinbase transactions are subject to an enforced confirmation delay (100 or 120, not so sure anymore). Armory depends on BitcoinQt so it bends by its rules. You can even spend 0 confirmation transactions with Armory, unless you force it to ignore ZC.

While transactions will require a depth of 6 blocks to be displayed as confirmed in the UI, Armory won't prevent you from creating a transactions with low confirmation UTXO. Generally, the coin selection algorithm prefers older UTXO, so unless you have very few available outputs in your wallet, you will most likely never spend off of a low conf transactions.

[goatpig]

Hi

Today I tried to send a payment but am getting the error "SelectCoins returned a list of size zero. This is problematic and probably not your fault.".
I've tried restarting Armory but the error persists.

I was on Version 0.9 and I have just installed Version 0.91.2. I have not tried it with 0.91.2 yet.

Make a ticket, add in your log files.

[milkshoe]

I imported a watchonlywalllet and now Armory 0.9.12 on Mac OS 10.9.3 keeps crashing on startup. Cant use it, what can I do? Switch back to 0.9.11 ?!

-INFO  - 1402126750: (BlockUtils.cpp:4527) Starting scan from block height: 0
-ERROR - 1402126750: (leveldb_wrapper.cpp:1787) Invalid txIndex at height 0 index 269
-ERROR - 1402126750: (StoredBlockObj.cpp:1082) Cannot get tx copy, because don't have full StoredTx!

[btchris]

By "isolated" I mean that the new channels enabled by the "plugin" system would be isolated.  Any extensions would requiring signing, and virtually no code within Armory would be any different with or without the extension (there would simply be one extra loop that checks the directory for python files and signatures, and then adds a new tab for each one).  Everything to do with it could be disabled by simply deleting the extensions directory or giving it root permissions that prevent reading or writing (then that loop would skipped and Armory would run identically to a version that doesn't have this).

Apple does the same thing with code signing pretty sure that has been broken since day one.

Would such a plugin directory be located in an only-root-writable location by default, e.g. /usr/lib/armory/plugins or \Program Files (x86)\Armory\plugins? If so, I don't see how it could compromise security unless root was already compromised (in which case all bets are off anyways), correct?

You could still allow a per-user preference to enable/disable individual plugins, but require root/Admin to initially install them.

[goatpig]

I imported a watchonlywalllet and now Armory 0.9.12 on Mac OS 10.9.3 keeps crashing on startup. Cant use it, what can I do? Switch back to 0.9.11 ?!

-INFO  - 1402126750: (BlockUtils.cpp:4527) Starting scan from block height: 0
-ERROR - 1402126750: (leveldb_wrapper.cpp:1787) Invalid txIndex at height 0 index 269
-ERROR - 1402126750: (StoredBlockObj.cpp:1082) Cannot get tx copy, because don't have full StoredTx!

Start in offline mode, do a Help -> Rebuild and Rescan Database, then restart in online mode.

Would such a plugin directory be located in an only-root-writable location by default, e.g. /usr/lib/armory/plugins or \Program Files (x86)\Armory\plugins?

That's the idea

[teste]

Suggestion:

I think when right clicking on an address that was imported, the menu should have an option to sweep the private keys to an address of the armory deterministic wallet.

[Muhammed Zakir]

Only coinbase transactions are subject to an enforced confirmation delay (100 or 120, not so sure anymore). Armory depends on BitcoinQt so it bends by its rules. You can even spend 0 confirmation transactions with Armory, unless you force it to ignore ZC.

While transactions will require a depth of 6 blocks to be displayed as confirmed in the UI, Armory won't prevent you from creating a transactions with low confirmation UTXO. Generally, the coin selection algorithm prefers older UTXO, so unless you have very few available outputs in your wallet, you will most likely never spend off of a low conf transactions.

Thanks for telling that! When I saw the below post, I was thinking not to use Armory.

Have you yet developed an option to remove the 6 confirmation limit?
if you are a frequent user of your wallet, waiting for 6 confirmations to spend coins can be a huge waiting process.

Kindly,
        Muhammed Zakhir

[gweedo]

By "isolated" I mean that the new channels enabled by the "plugin" system would be isolated.  Any extensions would requiring signing, and virtually no code within Armory would be any different with or without the extension (there would simply be one extra loop that checks the directory for python files and signatures, and then adds a new tab for each one).  Everything to do with it could be disabled by simply deleting the extensions directory or giving it root permissions that prevent reading or writing (then that loop would skipped and Armory would run identically to a version that doesn't have this).

Apple does the same thing with code signing pretty sure that has been broken since day one.

Would such a plugin directory be located in an only-root-writable location by default, e.g. /usr/lib/armory/plugins or \Program Files (x86)\Armory\plugins? If so, I don't see how it could compromise security unless root was already compromised (in which case all bets are off anyways), correct?

You could still allow a per-user preference to enable/disable individual plugins, but require root/Admin to initially install them.

Please reread what etothepi said, he wants it to be in a sandbox, you are talking about plugins run directly on the machine. Those are two different things both have different cons and pros.

Also as I said before look at apple, code signing doesn't always work, it is easy to spoof the signed code. On a computer someone can change your dns/proxy tunnel all armory traffic, then tell armory that plugin was signed. Then you don't need root to have access to the funds.

Plugins are not made for this type of software, bitcoin-core team even said they will never have plugins or auto updates, we are DEALING WITH MONEY. Not WoW tokens or anything else. Don't forget that, plugins for your music player great idea, plugins for a basically a bank application NOT A GOOD IDEA!

[etotheipi]

Please reread what etothepi said, he wants it to be in a sandbox, you are talking about plugins run directly on the machine. Those are two different things both have different cons and pros.

Also as I said before look at apple, code signing doesn't always work, it is easy to spoof the signed code. On a computer someone can change your dns/proxy tunnel all armory traffic, then tell armory that plugin was signed. Then you don't need root to have access to the funds.

Plugins are not made for this type of software, bitcoin-core team even said they will never have plugins or auto updates, we are DEALING WITH MONEY. Not WoW tokens or anything else. Don't forget that, plugins for your music player great idea, plugins for a basically a bank application NOT A GOOD IDEA!

Well the exact implementation details were still half-baked at the time I originally posted it.  Since then, I have decided that the best way to do it is to put the plugins directly in a root-only locations, such as the install path.  As btchris said, this means that only someone with root can insert them, which if compromised is already game over.

gweedo:  here's the reason this is a good idea:  there's a lot of "edgy" things we'd like to provide to people.  We can have payment scheduling, exchange rate converters and custom history export options, customized backup/restore systems, direct links to APIs of various services, synchronization of multi-sig partially-signed transactions, custom encryption utilities.  Dozens of more things can be done.  These are things that not everyone needs, but a lot of people really want it.  Many of these things are candidates to put into mainline Armory, but then you'd be complaining about bloat and too many features opening up more attack vectors.  

With this system you don't have to have those features unless you explicitly want them.  It allows us to keep Armory lean and we can make all the edgy things--especially those with external network connections--opt-in-only instead of forced-onto-everyone.

And I don't know what you're talking about with the signing hacks.  We use the same scheme for signing Armory releases which is basically the same thing Bitcoin itself uses to authorize transactions.  The offline public key is hardcoded in Armory (requiring root to modify the app), and the signature verification happens on-load every time, and doesn't depend on the source of the data.  It only depends on whether a signature is included over the hash of the source-code itself , and the code is never even run unless the signature verifies.

[bitpop]

Gweedo listen very carefully

Once you have physical access, you can do anything. That's why you can jail break an Apple in your hand but not remotely.

[gweedo]

here's the reason this is a good idea:  there's a lot of "edgy" things we'd like to provide to people.

This is investor talk right now... Armory isn't even out of beta, and lets just put a huge open hole right in the middle of it. Lets not even talk about attacks what if someone builds the greatest plugin ever, but hey they have a bug, then BAM coins gone. I hope you have a good lawyer because this now money we are talking... and when people lose money they gain lawyers

Also I disabled that security downloader, and announcement thing, I don't know if you are tracking ips and stuff like that. My firewall blocks any outgoing or incoming communication with armory.

I will not be using armory anymore, I just sent all my coins from armory to paper wallets until I find a new wallet. This is exactly what happens when you get investors, I thought it be different but no it is the same, bottom line. I hope Trace makes a lot of money from this instead of just keeping what was a good project going.

[etotheipi]

here's the reason this is a good idea:  there's a lot of "edgy" things we'd like to provide to people.

This is investor talk right now... Armory isn't even out of beta, and lets just put a huge open hole right in the middle of it. Lets not even talk about attacks what if someone builds the greatest plugin ever, but hey they have a bug, then BAM coins gone. I hope you have a good lawyer because this now money we are talking... and when people lose money they gain lawyers

Also I disabled that security downloader, and announcement thing, I don't know if you are tracking ips and stuff like that. My firewall blocks any outgoing or incoming communication with armory.

I will not be using armory anymore, I just sent all my coins from armory to paper wallets until I find a new wallet. This is exactly what happens when you get investors, I thought it be different but no it is the same, bottom line. I hope Trace makes a lot of money from this instead of just keeping what was a good project going.

Holy moly.  No one is forcing you to install any plugins, and any plugins that we make optionally available will have same distribution and verification security as the software releases themselves (using our offline signing key).  As for the secure downloader: it was integrated to make it easier for users to care about security, because GPG isn't the most friendly thing to use, yet people want to be able to verify their downloads.  It also gives us a secure channel to issue notifications in the event of hard forks where people could lose money.  Everything is offline signed and verified at the time of execution.  It's as secure as the offline GPG signing key you already trust.

This is nothing to do with investors.  It simply gives us a channel to help out individuals and organizations (or for them to help themselves) expand Armory to meet their needs.  Should we ignore our users needs?  Should we not expand the app in ways we see extremely useful with no visible security downsides?  This is about making Armory more modular (than it already is) so we can provide useful features to portions of our usebase that want us to provide it for security reasons.  And allows others to extend Armory for themselves.

We have operated as a for-profit company without any revenue for a long time because we legitimately care about making a rock solid, secure app, and not compromising that process by having to prioritize revenue.  You think I will wildly and recklessly disregard all security judgment just to add useful feature?  I have explained to you the way this will be implemented in a known, secure manner.  You have disregarded it all under the explanation that some organizations have failed to implement security properly, without regard to the differences of the situations.  And with no regard for our [Armory's] history of extreme rigor and conservatism to provide you something that is secure first, then as useful as possible.

I think your reaction is extraordinary and the reasons you state are not backed by the technical details.  If trust is gone, nothing I can do about that, but I hope you will look at this conversation with a fresh set of eyes and realize that I have always aimed to maximize security before all other factors, and this is no different.

[bitpop]

Don't feed the trolls

[etotheipi]

Don't feed the trolls

gweedo has been part of this discussion and using Armory for a loooong time.  I'm fairly certain he donated, too.  I never considered him a troll, despite his reaction here. 

[bitpop]

Don't feed the trolls

gweedo has been part of this discussion and using Armory for a loooong time.  I'm fairly certain he donated, too.  I never considered him a troll, despite his reaction here.  

Ok just defending you

Trolling was referring to certain of his information rather than him directly

[gweedo]

Don't feed the trolls

gweedo has been part of this discussion and using Armory for a loooong time.  I'm fairly certain he donated, too.  I never considered him a troll, despite his reaction here.  

Ok just defending you

Trolling was referring to certain of his information rather than him directly

Trolls are people that attack people with no bases of opinion. While I will always have great respect for Etothepi as with most people around here, it shouldn't matter if I have a different opinion. If I think plugins are bad, then that is my choice, not me trolling. I am a verbose person that likes to make my opinions heard especially when it comes to security.

I was using armory on mac when you had to brew tap Red emerald tap (It sounds like something else to windows users but it is mac thing I promise we were both dressed). I love armory and will probably use it up until the plugin system. I donated both to armory so we could get Armory on mac as an application, as well as to red emerald when he had to field my pms about stuff not working.

Just cause I am changing to a new wallet system doesn't mean anything it just means I am not happy with the current situation and I want to vote literally with my wallet. Who knows I maybe using a fork of armory, that people have been pming me about.

Trust me you will know when I am trolling going ask other people.

[bitpop]

I guess itll cost you more but why trust anyone else to fork

Just donate enough for them to fork themselves and they'll make you an armory lite

[po0kie]

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