Armory - Discussion Thread

[gweedo]

Just a future note, when the time comes, please have a build of armory for the mac OSX system that has no plugin capabilities as I look to armory as a fort knox for my bitcoins and a plugin system would make it very unsafe.

[1714047481]

1714047481

[1714047481]

1714047481

[1714047481]

1714047481

[1714047481]

1714047481

[Corelianer]

Just a future note, when the time comes, please have a build of armory for the mac OSX system that has no plugin capabilities as I look to armory as a fort knox for my bitcoins and a plugin system would make it very unsafe.

They don't need to create a plugin-free edition. Per default you have no-plugins. And if its "fort knox" for you, then you work with a watch only wallet anyway.

With a watch only wallet, your private key is not on the online computer, so there is no thread to it.

[Ente]

Good morning!

I had Armory segfault problems, it works now after a 'git pull'.
Now it says one of my wallets are corrupt, but the "repair tool" is grayed out here. Suggestions?
It is still scanning the tx history for another 15 mins, so I can't say if the balance is as I expect.

Now, after a restart(?), the wallet fix tool opens.
Somewhere it says that you don't have to enter the passphrase for wallet fixing, but then it fails to run the fix tool.
When entering the passphrase, it works, until it hangs at "18 of 107 address entries". After that, I have to forcibly end Armory.

Is this of any interest? Or shall I just grab a backup and forget about this?

Ente

Any suggestions on this?
There's no new git stuff to pull, and I'd prefer to not use a backup, as I would lose the descriptions of all tx (I guess).

Ente

[etotheipi]

Good morning!

I had Armory segfault problems, it works now after a 'git pull'.
Now it says one of my wallets are corrupt, but the "repair tool" is grayed out here. Suggestions?
It is still scanning the tx history for another 15 mins, so I can't say if the balance is as I expect.

Now, after a restart(?), the wallet fix tool opens.
Somewhere it says that you don't have to enter the passphrase for wallet fixing, but then it fails to run the fix tool.
When entering the passphrase, it works, until it hangs at "18 of 107 address entries". After that, I have to forcibly end Armory.

Is this of any interest? Or shall I just grab a backup and forget about this?

Ente

Any suggestions on this?
There's no new git stuff to pull, and I'd prefer to not use a backup, as I would lose the descriptions of all tx (I guess).

Ente

Sorry Ente,

I totally overlooked this.  The latest version (0.91.3) shouldn't freeze any more.  I think that's on the testing branch.   

[bitpop]

Just a future note, when the time comes, please have a build of armory for the mac OSX system that has no plugin capabilities as I look to armory as a fort knox for my bitcoins and a plugin system would make it very unsafe.

They don't need to create a plugin-free edition. Per default you have no-plugins. And if its "fort knox" for you, then you work with a watch only wallet anyway.

With a watch only wallet, your private key is not on the online computer, so there is no thread to it.

Plugin systems bring a whole set of new problems. Armory was a secure wallet but now people like you will make it into some Facebook wallet kinda sad. Stop requesting things that compromise the secure.

Online is screwed no matter what, offline shouldnt matter what they add

[gweedo]

Just a future note, when the time comes, please have a build of armory for the mac OSX system that has no plugin capabilities as I look to armory as a fort knox for my bitcoins and a plugin system would make it very unsafe.

They don't need to create a plugin-free edition. Per default you have no-plugins. And if its "fort knox" for you, then you work with a watch only wallet anyway.

With a watch only wallet, your private key is not on the online computer, so there is no thread to it.

Plugin systems bring a whole set of new problems. Armory was a secure wallet but now people like you will make it into some Facebook wallet kinda sad. Stop requesting things that compromise the secure.

Online is screwed no matter what, offline shouldnt matter what they add

Well it does matter, I keep a small amount online and large amount offline. To have them build something as good as armory is, and what it does well, to be brought down by a stupid idea of a plugin system. That is why it is open sourced, so people like that can build and add stupid features of price checkers and other ideas. That is the real plugin system, not some that that will open open bugs and holes.

Armory the company needs to focus on security, coinjoin, mutli-sig (which lockbox looks amazing) these are the features that will keep wealth around. Not these facebook users.

[etotheipi]

Just a future note, when the time comes, please have a build of armory for the mac OSX system that has no plugin capabilities as I look to armory as a fort knox for my bitcoins and a plugin system would make it very unsafe.

They don't need to create a plugin-free edition. Per default you have no-plugins. And if its "fort knox" for you, then you work with a watch only wallet anyway.

With a watch only wallet, your private key is not on the online computer, so there is no thread to it.

Plugin systems bring a whole set of new problems. Armory was a secure wallet but now people like you will make it into some Facebook wallet kinda sad. Stop requesting things that compromise the secure.

Calm down.  I still have control over this, and I wouldn't implement it in a way that would compromise its security.  The goal is to make the app extensible OPT-IN without requiring new builds all the time.  This is important for users that want things like, special export capability to read the wallet history and export in proprietary formats they need (perhaps, exporting each wallet with exchange rates and queries to other LAN resources).   But nothing would be enabled by default, and it would be very isolated.

The plan to was to allow the user to add extra python files that describe extra tabs on the main window, and those python files must be signed by ATI and/or you must sign them yourself with one of your local full wallets.  Without it, Armory will refuse to even parse the file.  There would be a way to disable these checks if you want to use "unsigned" extensions, which some people would optionally do.  But the idea is that nothing will be enabled by default, and most of the app will not be affected by the simple ability to add a new tab to main screen.  You will have to do something explicit to enable them.

In this case, the term "plugin system" is used loosely.  Usually plugin systems do have a high degree of "threading" through the app to give plugsin the ability to modify just about any part of the app (add menu options, extra functions to execute when you send transactions, etc).  Instead, this will simply be a way for users to add new tabs that enable new functionality, without having to build Armory yourself.  We consider this important especially for business users which want to be able to tie in some application-specific functionality that needs access to the wallets, bitcoin network, blockchain, etc.

[Ente]

Just a future note, when the time comes, please have a build of armory for the mac OSX system that has no plugin capabilities as I look to armory as a fort knox for my bitcoins and a plugin system would make it very unsafe.

They don't need to create a plugin-free edition. Per default you have no-plugins. And if its "fort knox" for you, then you work with a watch only wallet anyway.

With a watch only wallet, your private key is not on the online computer, so there is no thread to it.

Plugin systems bring a whole set of new problems. Armory was a secure wallet but now people like you will make it into some Facebook wallet kinda sad. Stop requesting things that compromise the secure.

Calm down.  I still have control over this, and I wouldn't implement it in a way that would compromise its security.  The goal is to make the app extensible OPT-IN without requiring new builds all the time.  This is important for users that want things like, special export capability to read the wallet history and export in proprietary formats they need (perhaps, exporting each wallet with exchange rates and queries to other LAN resources).   But nothing would be enabled by default, and it would be very isolated.

The plan to was to allow the user to add extra python files that describe extra tabs on the main window, and those python files must be signed by ATI and/or you must sign them yourself with one of your local full wallets.  Without it, Armory will refuse to even parse the file.  There would be a way to disable these checks if you want to use "unsigned" extensions, which some people would optionally do.  But the idea is that nothing will be enabled by default, and most of the app will not be affected by the simple ability to add a new tab to main screen.  You will have to do something explicit to enable them.

In this case, the term "plugin system" is used loosely.  Usually plugin systems do have a high degree of "threading" through the app to give plugsin the ability to modify just about any part of the app (add menu options, extra functions to execute when you send transactions, etc).  Instead, this will simply be a way for users to add new tabs that enable new functionality, without having to build Armory yourself.  We consider this important especially for business users which want to be able to tie in some application-specific functionality that needs access to the wallets, bitcoin network, blockchain, etc.

I like! I like a lot!
Addons, in python, and ATI/self signing, that sounds great!
I already have ideas for "addons" :-)

Ente

[gweedo]

But nothing would be enabled by default, and it would be very isolated.

I get it, but that is why you need to create a build without a plugin system. Bitcoin is attracting more and more black hats and things like this just give them a playground, the money and motivation is there.

Also please don't say you going to isolate things, that is how a project fails. Sandboxing apps are not secure, chrome's sandboxing has been hacked a couple times and lets not talk about java applets...

[Ente]

Good morning!

I had Armory segfault problems, it works now after a 'git pull'.
Now it says one of my wallets are corrupt, but the "repair tool" is grayed out here. Suggestions?
It is still scanning the tx history for another 15 mins, so I can't say if the balance is as I expect.

Now, after a restart(?), the wallet fix tool opens.
Somewhere it says that you don't have to enter the passphrase for wallet fixing, but then it fails to run the fix tool.
When entering the passphrase, it works, until it hangs at "18 of 107 address entries". After that, I have to forcibly end Armory.

Is this of any interest? Or shall I just grab a backup and forget about this?

Ente

Any suggestions on this?
There's no new git stuff to pull, and I'd prefer to not use a backup, as I would lose the descriptions of all tx (I guess).

Ente

Sorry Ente,

I totally overlooked this.  The latest version (0.91.3) shouldn't freeze any more.  I think that's on the testing branch.  

Uhm, general GIT question: Is it possible to accidently commit changes to the GIT project, with no account and all?

My local copy diverged from the GIT version, and now I get confused with all that stuff.. oops


edit:
I think I didn't actually commit any garbage upstream.. oops again.
The testing version scanned through the corrupted(?) wallet, I sent you all info via the report function.

Ente

[etotheipi]

But nothing would be enabled by default, and it would be very isolated.

I get it, but that is why you need to create a build without a plugin system. Bitcoin is attracting more and more black hats and things like this just give them a playground, the money and motivation is there.

Also please don't say you going to isolate things, that is how a project fails. Sandboxing apps are not secure, chrome's sandboxing has been hacked a couple times and lets not talk about java applets...

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).

I understand your hesitation, but do keep in mind that I have spent the past 3 years being really careful with Armory's security profile, and I'm not going to recklessly "destroy" it.  I am certainly open to suggestions for improving things like this, but we are very comfortable that this will be airtight as-is (i.e. the overall security profile of the app is the same before and after the change).


@ Ente: 

If you haven't modified anything that you want to keep the changes, just do "git reset --hard", then do a "git fetch", then "git checkout testing" , "git pull origin testing".   Probably have to do a "make" (though that may not actually be necessary if you're already running 0.91.2.

[Corelianer]

But nothing would be enabled by default, and it would be very isolated.

I get it, but that is why you need to create a build without a plugin system. Bitcoin is attracting more and more black hats and things like this just give them a playground, the money and motivation is there.

Also please don't say you going to isolate things, that is how a project fails. Sandboxing apps are not secure, chrome's sandboxing has been hacked a couple times and lets not talk about java applets...

By creating two builds you add extra work to the developpers and slow deveopment down. The only rocksolid solution is keeping your coins offline.

[gweedo]

But nothing would be enabled by default, and it would be very isolated.

I get it, but that is why you need to create a build without a plugin system. Bitcoin is attracting more and more black hats and things like this just give them a playground, the money and motivation is there.

Also please don't say you going to isolate things, that is how a project fails. Sandboxing apps are not secure, chrome's sandboxing has been hacked a couple times and lets not talk about java applets...

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).

I understand your hesitation, but do keep in mind that I have spent the past 3 years being really careful with Armory's security profile, and I'm not going to recklessly "destroy" it.  I am certainly open to suggestions for improving things like this, but we are very comfortable that this will be airtight as-is (i.e. the overall security profile of the app is the same before and after the change).

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

But nothing would be enabled by default, and it would be very isolated.

I get it, but that is why you need to create a build without a plugin system. Bitcoin is attracting more and more black hats and things like this just give them a playground, the money and motivation is there.

Also please don't say you going to isolate things, that is how a project fails. Sandboxing apps are not secure, chrome's sandboxing has been hacked a couple times and lets not talk about java applets...

By creating two builds you add extra work to the developpers and slow deveopment down. The only rocksolid solution is keeping your coins offline.

How does that slow down development down? They could just have a switch in the make files, that build it without that code. This would also help them keep it separated from the actually armory code.

[Corelianer]

@gweedo

Ok maybe it's not much work to create two builds but an online system has hundrets of vaunerabilities.
You can't deny that only an offline system is secure.

If you have a virus on your computer, a keylogger, or screen-capture software Armory can't do nothing about it.
So there is no point making something extra secure that only a offline computer can provide.

In my oppinion the offline computer (or cold storage, paper backup) should be the "fort knox".
The online computer should add some convinience to manage my funds.

You can not expect a fort knox of your online computer because it has a broadband connection.

[gweedo]

@gweedo

Ok maybe it's not much work to create two builds but an online system has hundrets of vaunerabilities.
You can't deny that only an offline system is secure.

If you have a virus on your computer, a keylogger, or screen-capture software Armory can't do nothing about it.
So there is no point making something extra secure that only a offline computer can provide.

You are completely missing the point, it would open up even more holes, on an already sensitive platform. Everyone to certain degree keeps some money in a hot wallet, but yes most of my funds are offline. Just cause I keep $100 in hot wallet doesn't mean I want it to be stolen, or don't care, it is just worth less to me than my entire holdings. Doesn't mean I don't want it protected. Sandboxed plugins are the not the answer, the answer is if you want that to be insecure then you fork it and add prices and anything else. Not the other way around, security should be first.

Investors always === bottom line, glad to see nothing has changed.

[etotheipi]

Investors always === bottom line, glad to see nothing has changed.

This has nothing to do with investors.  This is about making Armory usable for a wider array of power users and businesses that would like to use it.  If there's no way to hook their local systems/resources into it, it has limited use to them.  If we felt that there was a compromise of security involved, we'd be looking at other options.

[Corelianer]

Investors always === bottom line, glad to see nothing has changed.

This has nothing to do with investors.  This is about making Armory usable for a wider array of power users and businesses that would like to use it.  If there's no way to hook their local systems/resources into it, it has limited use to them.  If we felt that there was a compromise of security involved, we'd be looking at other options.

I agree, it needs some openness to compete with the current systems and other wallet softwares.
Multibit has already an Exchange Rate system but misses the watch only feature. (as far as I know)

@gweedo Ok, lets agree that we have a different opinion about where the jurney goes

[SebastianJu]

I found this line

Code:

#parser.add_option("--bitcoind-path",   dest="bitcoindPath",default='DEFAULT', type="str",          help="Path to the location of bitcoind on your system")

at https://raw.githubusercontent.com/etotheipi/BitcoinArmory/rrld_planB/armoryengine.py is commented out. The same goes for the lines that use that flag

Code:

# Change the settings file to use
#BITCOIND_PATH = None
#if not CLI_OPTIONS.bitcoindPath.lower()=='default':
   #BITCOIND_PATH = CLI_OPTIONS.bitcoindPath

It looks like its meant to change the bitcoind/qt exe path. Im not sure though if it works for bitcoinqt and not only bitcoind but i guess yes.

Can this be made valid again since it looks like the only way to make armory automatically find and start a portable bitcoin-qt-version.

But when i think about it... it doesnt make sense if armory simply starts the bitcoin-qt.exe in the directory one could specify when bitcoinqt is portable. It would mean it would download the blockchain again and create a new directory in roaming-dir.

So either bitcoinqt can be started and is using the directory by some conf-file that specifies where the blockchain is stored or armory needs to use the shortcut to start bitcoinqt with the flag included that specifies the blockchain-dir for bitcoin-qt.

Someone knows a solution?

[gweedo]

Investors always === bottom line, glad to see nothing has changed.

This has nothing to do with investors.  This is about making Armory usable for a wider array of power users and businesses that would like to use it.  If there's no way to hook their local systems/resources into it, it has limited use to them.  If we felt that there was a compromise of security involved, we'd be looking at other options.

See that is where you are wrong, you say businesses want to tap into armory, but instead you should be saying business want to tap into bitcoin, if armory allows them to access that network the easiest and best way possible then so be it. That is where armoryd should be coming into play for them, not a function client and believe me you will be turning off power users like myself.

[doug_armory]

Is the mac version any more stabler?
Does any one have a link to the latest change logs for the mac version?
I couldn't bear with the hours and hours of rebuilding databases just to get my wallet to work so I moved back to the original Bitcoin client
Hopefully armory has improved since then so I can protect my coins again

When was the last time you used it? v0.91 introduced many stability fixes. There are still some Qt-related issues that need to be resolved but Armory is usable.