Armory - Discussion Thread

[etotheipi]

ethotheipi,

i already have a non encrypted wallet generated offline stored on my Ironkey.

what would be the best way to get it tx'd into Armory on an offline computer?

Cypherdoc,

I am actually avoiding having anyone move existing keys over to Armory wallets yet.  This is why I haven't explicitly created a bulk-import function for private keys (you can enter them one-by-one through the Import-Address dialog).  Plus, I don't have a good way to pull private key data out of the wallet.dat files, even if I did.  I have a script that gets some keys out of the unencrypted Satoshi wallets, but I don't know if it gets all of them.  I heard sipa has a bitcoin branch that allows you dump your private keys, but I think it requires compiling Bitcoin, which can be even more daunting than compiling Armory :|

For now, I recommend you make a new, offline wallet, and transfer a small amount of funds to one of its addresses.  Make sure it works, and that you can move money in and out of the offline wallet as you'd expect (and that you have a copy of the keys saved somewhere in case Armory/HDD fails).  By the time you're comfortable with that functionality, then I might be better prepared to help with this.  I'm still a little uncomfortable with people putting all their eggs in the Armory basket yet, at least until I get some wider testing done.

[etotheipi]

P.S. - For future build-issue discussions, rather than posting here, please join the armory-dev IRC channel (I just created it).  I'd prefer not to clutter this thread with build-issues.  If IRC is not your thing, email or PM works, too!   

[etotheipi]

So, I completely botched the Win32 settings in the MSVS project.  I just went through the compile process in Windows XP and got the project into order.  I also updated the build instructions on the webpage, to reflect the feedback I've gotten so far for all building.  I tried to make them more explicit, to clarify things that developers should probably know already, but not everybody here is a developer

Unfortunately, I wasn't able to load the full blockchain for the main-network in WinXP 32-bit.  But Win 7, 32-bit did work.  I am sure it has to do with the memory requirements.  Trust me, the non-full-RAM version is my first priority after the first release!  However, using it with " --testnet" did work.  So you can still help test, but not with the real network :|

[Brunic]

Amazing!

The RAM kills me, but dude, THAT is still amazing!

[runeks]

This is amazing! Well done. I just sent you 5 BTC (2 of them from your own app!).

By the way, I was only able to send the 2 BTC using your app in a non-intended (I presume) way. When I open the Send dialog, and press the "Donate to Armory Developers!" button, a new set of recipient address/amount/comment fields are added below the already-present set of blank ones. If I just press the "Send!"-button, it tells me that the top set of blank fields contain an invalid address, but I can't delete this top, blank field, only the second field (with your developer donate address in it). So I had to manually copy the developer donate address from the field that is added when I press the "Donate to Armory Developers!"-button into the top field, then remove the bottom field, and then it worked. Thought you might want to know.

I must admit though, that I won't be using any of the very useful features for a long time due to security reasons. The only thing I really trust at the moment is a Truecrypt container with a wallet in it (doesn't matter what format). The private key leach from encrypted wallets in the Satoshi client only confirmed to me that this approach is sensible, if only for larger savings.

I've heard good things about the Ironkey.  For the offline wallet interface, the biggest threat is hidden USB-key viruses, so something with built-in-AV probably helps.

Interesting. I thought this was a Windows-only issue, but again I find myself taken to school by YouTube: http://www.youtube.com/watch?v=ovfYBa1EHm4

Also, I just found out your app doesn't subtract the balance of a transaction from the wallet until the transaction is in a block, so I've tried to double spend some coins in my wallet with your app, just for testing purposes . We'll see what happens.

EDIT: Hmm, it seems none of the transaction I have sent using your application has made it in a block yet. It's been at least an hour. Is the send dialog supposed to disappear when I press the "Send!" button? It doesn't do that for me, I have to close it manually (and it appears it doesn't send the coins).

EDIT2: I fired it up in a terminal. I get this error after pressing the "Send!" button, entering my password and waiting a second or two:

Code:

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

(here's the entire output)

Code:

rune@runescomp:~/Programming/BitcoinArmory$ ./ArmoryQt.py 
********************************************************************************
Loading Armory Engine:
   Armory Version:       0.50
   PyBtcAddress Version: 1.00
   PyBtcWallet  Version: 1.35
Detected Operating system: Linux
   User home-directory   : /home/rune
   Satoshi BTC directory : /home/rune/.bitcoin/
   Satoshi blk0001.dat   : /home/rune/.bitcoin/blk0001.dat
   Armory home dir       : /home/rune/.armory/
Using settings file: /home/rune/.armory/ArmorySettings.txt
Loading wallets...
Reading wallet file: /home/rune/.armory/armory_v9VUBhAP_.wallet
/home/rune/.armory/armory_v9VUBhAP_.wallet
Number of wallets read in: 1
   Wallet (v9VUBhAP):      "test"    (Encrypted)
Loading blockchain
Attempting to read blockchain from file: /home/rune/.bitcoin/blk0001.dat
/home/rune/.bitcoin/blk0001.dat is 1651.95 MB
Syncing wallets with blockchain...
Syncing v9VUBhAP
Ledger entries: 2 Max Block: 163501
Developer
Coin Selection:  (Total =         2.20000000 BTC)
    Owner Address                                  TxOutValue      NumConf       PriorityFactor
    1BR7hwpWjCeVfudoTwqQWYVSXzr91dcLY5             1.20000000 BTC           20                 0.17
    1BR7hwpWjCeVfudoTwqQWYVSXzr91dcLY5             1.00000000 BTC           16                 0.11
220000000
219950000.0
[('l"\xeb\x00\xe3\xf9:\xca\xc5\xae]\x81\xa9\xdbx\xa6E\xdf\xc9\xc7', 200000000)]
['Donation to Armory developers']
Donation to Armory developers
Total number of inputs in transaction:   2
Number of inputs that you can sign for:  2
Signatures for input 0 are valid!
Signatures for input 1 are valid!
{'d\x9a\x8b\x8b\x83B\x95\x8cE\x1e\x96\xdb\xd50\x83\x8d\xe6W\x8f\xcc\xa3\xc4x\xa2\x86\xbd\xc0i\x00\x86I3': 'Donation to Armory developers', ';\xb5\xc6\xf5Z>\xabb\x9a\x88\x84\x87\xb6\xaa\xe9C"Q\x86]\x18\xf0=\xe1\xc5\x00\xb5w;\xe1\xe4K': 'Donation to Armory developers.  Thank you for your generosity!', '\xb8\x0bB\xec\xb5|x$M\xd4\xa6\xd2o\xf2\x9f0U\xb0s\x1dL\x10\xce\xb9\xb57\x86M\x83\x04\\A': 'Donation to Armory developers.  Thank you for your generosity!', "\xa0\xc7\x06\xc3\x94\xa0]\xe6\xba=\xafg9\xd3\xcd\xaf\x0c\xc0\xb9,+e\x10$\xe7\xed'\xef\xd5 a\x82": 'double spend test', 't\xbb6MC\xd0Mly\xd6\xf8\xf3\x16\xc4\x82\x97\xd04\x9b;\x82a\x8dzm^\xec?\xc0\xf0\xf1/': 'Donation to Armory developers.  Thank you for your generosity!'}



01000000022774519f5aa3c14e806899c3a23b96025e578f9df08c4359b96c08a87ac3e760010000008c4930460221001103aa8a810d57bf470b1e710cdb8bd97a73e7426ee7ac355366be30ca778e0d0221007ac10b8594fd6837c0682dfbce3984241a928234a5d5a78310b149733834871e01410493a916a08a1b6ef0d8f226078df6dc5185f87ce5316816ee132dd81631e77c7019b0846a40e4ccc88957e900024ede8ab4c73bf92fe8e9921179fbb6b3c51347ffffffff5ca16f3187b99b76dc82d1dabcc18b11af143b81c4502d6b3442616125ccb4c9010000008c493046022100e783f861249c2ce5fa18cd91d4a58280c2227ec480719464048a475d4796aa930221009903d5415c39c2e8602d316e79bf7c881462805c802a866677af488bb71b393301410493a916a08a1b6ef0d8f226078df6dc5185f87ce5316816ee132dd81631e77c7019b0846a40e4ccc88957e900024ede8ab4c73bf92fe8e9921179fbb6b3c51347ffffffff02b0693001000000001976a914a6af1826f2addcf1132244ae5a9eee91decdb54088ac00c2eb0b000000001976a9146c22eb00e3f93acac5ae5d81a9db78a645dfc9c788ac00000000
-----BEGIN-TRANSACTION-4UWrJegd-------------------------------------------------
_TXDIST_f9beb4d9_4UWrJegd_00d2
01000000022774519f5aa3c14e806899c3a23b96025e578f9df08c4359b96c08a87ac3e760010000
001976a9147240d6b96a4e689f03695feefc2ebb76304beba088acffffffff5ca16f3187b99b76dc
82d1dabcc18b11af143b81c4502d6b3442616125ccb4c9010000001976a9147240d6b96a4e689f03
695feefc2ebb76304beba088acffffffff02b0693001000000001976a914a6af1826f2addcf11322
44ae5a9eee91decdb54088ac00c2eb0b000000001976a9146c22eb00e3f93acac5ae5d81a9db78a6
45dfc9c788ac00000000
_TXINPUT_00_1.20000000
_SIG_1BR7hwpWjCeVfudoTwqQWYVSXzr91dcLY5_00_008c
4930460221001103aa8a810d57bf470b1e710cdb8bd97a73e7426ee7ac355366be30ca778e0d0221
007ac10b8594fd6837c0682dfbce3984241a928234a5d5a78310b149733834871e01410493a916a0
8a1b6ef0d8f226078df6dc5185f87ce5316816ee132dd81631e77c7019b0846a40e4ccc88957e900
024ede8ab4c73bf92fe8e9921179fbb6b3c51347
_TXINPUT_01_1.00000000
_SIG_1BR7hwpWjCeVfudoTwqQWYVSXzr91dcLY5_01_008c
493046022100e783f861249c2ce5fa18cd91d4a58280c2227ec480719464048a475d4796aa930221
009903d5415c39c2e8602d316e79bf7c881462805c802a866677af488bb71b393301410493a916a0
8a1b6ef0d8f226078df6dc5185f87ce5316816ee132dd81631e77c7019b0846a40e4ccc88957e900
024ede8ab4c73bf92fe8e9921179fbb6b3c51347
-------END-TRANSACTION-4UWrJegd-------------------------------------------------
Pretty tx:  Transaction:
   TxHash:    3349860069c0bd86a278c4a3cc8f57e68d8330d5db961e458c9542838b8b9a64 (BE)
   Version:   1
   nInputs:   2
   nOutputs:  2
   LockTime:  0
   Inputs: 
      PyTxIn:
         PrevTxHash: 60e7c37aa8086cb959438cf09d8f575e02963ba2c39968804ec1a35a9f517427 (BE)
         TxOutIndex: 1
         Script:     (4930460221001103aa8a810d57bf470b1e710cdb8bd97a73e7426ee7ac355366)
         Sender:     1BR7hwpWjCeVfudoTwqQWYVSXzr91dcLY5
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: c9b4cc25616142346b2d50c4813b14af118bc1bcdad182dc769bb987316fa15c (BE)
         TxOutIndex: 1
         Script:     (493046022100e783f861249c2ce5fa18cd91d4a58280c2227ec480719464048a)
         Sender:     1BR7hwpWjCeVfudoTwqQWYVSXzr91dcLY5
         Seq:        4294967295
   Outputs: 
      TxOut:
         Value:    19950000 ( 0.1995 )
         Script:   OP_DUP OP_HASH (1GCLvcWM4ZDnDkfAm8vtJsb5E6TV5EMUmU) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    200000000 ( 2.0 )
         Script:   OP_DUP OP_HASH (1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv) OP_EQUAL OP_CHECKSIG
None
Raw serialize tx:  01000000022774519f5aa3c14e806899c3a23b96025e578f9df08c4359b96c08a87ac3e760010000008c4930460221001103aa8a810d57bf470b1e710cdb8bd97a73e7426ee7ac355366be30ca778e0d0221007ac10b8594fd6837c0682dfbce3984241a928234a5d5a78310b149733834871e01410493a916a08a1b6ef0d8f226078df6dc5185f87ce5316816ee132dd81631e77c7019b0846a40e4ccc88957e900024ede8ab4c73bf92fe8e9921179fbb6b3c51347ffffffff5ca16f3187b99b76dc82d1dabcc18b11af143b81c4502d6b3442616125ccb4c9010000008c493046022100e783f861249c2ce5fa18cd91d4a58280c2227ec480719464048a475d4796aa930221009903d5415c39c2e8602d316e79bf7c881462805c802a866677af488bb71b393301410493a916a08a1b6ef0d8f226078df6dc5185f87ce5316816ee132dd81631e77c7019b0846a40e4ccc88957e900024ede8ab4c73bf92fe8e9921179fbb6b3c51347ffffffff02b0693001000000001976a914a6af1826f2addcf1132244ae5a9eee91decdb54088ac00c2eb0b000000001976a9146c22eb00e3f93acac5ae5d81a9db78a645dfc9c788ac00000000
Sending Tx, 649a8b8b8342958c451e96dbd530838de6578fcca3c478a286bdc06900864933
Issue sending!
Traceback (most recent call last):
  File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 3558, in createTxAndBroadcast
    self.main.broadcastTransaction(finalTx)
  File "./ArmoryQt.py", line 1359, in broadcastTransaction
    self.NetworkingFactory.sendTx(pytx)
  File "/home/rune/Programming/BitcoinArmory/armoryengine.py", line 8531, in sendTx
    raise ConnectionError, 'Connection to localhost DNE.'
armoryengine.ConnectionError: Connection to localhost DNE.
f9beb4d9
Added new blocks to memory pool: 1
New Block! : 163502
f9beb4d9
Added new blocks to memory pool: 1
New Block! : 163503

[etotheipi]

This is amazing! Well done. I just sent you 5 BTC (2 of them from your own app!).

Also, I just found out your app doesn't subtract the balance of a transaction from the wallet until the transaction is in a block, so I've tried to double spend some coins in my wallet with your app, just for testing purposes . We'll see what happens.

Hi runeks,

Thanks so much for the donation!  I'm glad the program is working out for you.

First of all, I am about one day from having a complete fix to the zero-confirmation issue.  I am successfully pulling tx that aren't in the blockchain, and locking outputs that are on their way.  Literally, every single issue that Armory has right now with sending transactions, is all fixed in the update  (including being able to spend your own change outputs immediately).  It is a major robustness upgrade and I knew it was critical to get done before alpha.  I just have a bug still with the way Armory counts the balance, and then this will be completely fixed.

By the way, I was only able to send the 2 BTC using your app in a non-intended (I presume) way. When I open the Send dialog, and press the "Donate to Armory Developers!" button, a new set of recipient address/amount/comment fields are added below the already-present set of blank ones. If I just press the "Send!"-button, it tells me that the top set of blank fields contain an invalid address, but I can't delete this top, blank field, only the second field (with your developer donate address in it). So I had to manually copy the developer donate address from the field that is added when I press the "Donate to Armory Developers!"-button into the top field, then remove the bottom field, and then it worked. Thought you might want to know.

I had expected people would only "tack on" donations to existing transactions, which is why I did it that way (to be non-intrusive).  I should've considered the possibility that they would want to make a donation-only transaction (imagine that!).  Perhaps I'll put the donation in the first empty slot, and add a new slot only if there isn't an empty one.  

I must admit though, that I won't be using any of the very useful features for a long time due to security reasons. The only thing I really trust at the moment is a Truecrypt container with a wallet in it (doesn't matter what format). The private key leach from encrypted wallets in the Satoshi client only confirmed to me that this approach is sensible, if only for larger savings.

Just so you know, I was the one that actually found the encryption flaw in 0.4.0.   It was part of my justification for designing the wallet the way I did, which was with in-place file I/O, among other features.  If you are concerned about larger savings, please test out the offline wallets!   That's my holy grail feature, and I spent a lot of time trying to get the process to be self-explanatory.   The various ways to screw up encryption don't apply if the private keys aren't even on your computer!

As for the double-spend thing... the tx will just silently fail.  I would spend more time debating/discussing/debugging this, but when I've got a complete fix within arms-reach, I'll just postpone that until it's in.  Hopefully tonight.

[etotheipi]

runeks,

Just a comment... I glanced at your debugging output anyway... and noticed the Connection does not exist error.  Do you have the Satoshi client (or bitcoind) running in the background?  Is it sync'd with the network?  

nibor created a great tool for broadcasting transactions:

http://bitsend.rowit.co.uk/

I just pasted your tx (from debugging output) into that website, and it appears it was accepted.   Armory created a valid transaction, but it didn't have the connection to broadcast it.  I will add something to detect this error condition, and pop up a window, instead.

As for closing the send dialog: qt4reactor catches all exceptions, and then skips over and continues as normal.  The error caused the "send" function to abort before "dialog.accept()" call that would normally close the dialog, but the program continues to run.  If you see a button that does nothing, check the terminal output, it's usually due to an error.  However, if the Satoshi client is running, this should be a rare occurence.

On that note, I hope you don't mind that I broadcast that tx.  If you already re-sent it from a different source, I'll send you the 2 BTC back.  

[jimbobway]

Just so you know, I was the one that actually found the encryption flaw in 0.4.0.

Thumbs up!

[runeks]

Just a comment... I glanced at your debugging output anyway... and noticed the Connection does not exist error.  Do you have the Satoshi client (or bitcoind) running in the background?  Is it sync'd with the network?

Hmm, I might have closed it accidentally, but I'm not sure. I'll be sure to check if I experience the error again.

I haven't sent the 2 BTC from anywhere else, so it's fine that you have broadcast the transaction.

Wrt. to a safe storage of BTC, I'm still unsure of what to do. I'd like to do it really properly, so I'm sure they're safe. Nothing would be worse than discovering 10 years down the line that some hacker has run off with my savings. And that the coins I'e been sending to that wallet are irretrievable. I don't feel safe creating my savings wallet with an alpha version application. You warned against using it for larger amounts yourself, if I recall correctly. I'll see what I decide upon. Maybe my bitcoins will get stolen while I'm figuring out how to protect them properly...

[etotheipi]

Wrt. to a safe storage of BTC, I'm still unsure of what to do. I'd like to do it really properly, so I'm sure they're safe. Nothing would be worse than discovering 10 years down the line that some hacker has run off with my savings. And that the coins I'e been sending to that wallet are irretrievable. I don't feel safe creating my savings wallet with an alpha version application. You warned against using it for larger amounts yourself, if I recall correctly. I'll see what I decide upon. Maybe my bitcoins will get stolen while I'm figuring out how to protect them properly...

I agree, don't put a lot of money into the software just yet.  But it will never gain any credibility if no one ever tries it for fear that it's new .  Perhaps put a 1/20th of it into an offline wallet, make paper backups, and try using it.  In 3 months and a dozen small transactions, you'll find out how comfortable you are with it (personally, I have tested it a dozen times, and can't even find a hint of a problem, but maybe I'm too gentle with the program).    And, most importantly (and selfishly) I want people to help test it and provide feedback  

P.S. - And it would be great for people to test the paper backup printing and recovery (recover using the "Import Wallet..." dialog).  It's another feature that you feel most comfortable with after you see it work a couple times.

[runeks]

I think I'm more comfortable with the encrypt-and-spread-all-over-the-internet-so-it-doesn't-get-lost method (if you know that method). I'm not going to buy a separate PC just for storing a wallet on, and CDs and USB sticks aren't fault-proof, so I don't trust them to keep the keys forever. I guess I could just create a wallet offline using Armory, encrypt it with Truecrypt and store in my Gmail account, Dropbox folder and Ubuntu One folder, and a couple of other places. And then create a watching-only wallet of that and import it into Armory.

Do you have an easy way of converting to/from Bitcoin-QT wallets?

[etotheipi]

Just for reference, I sent out an email where I work, and got 20 responses about old laptops.  Someone gave me one, with 512 MB, for free.  Put 10.04 on it and I'm holding a large chunk of my money there offline (I don't mind taking the risk, myself, I just don't recommend others to do it yet )

Why not paper backups?  Sounds like that's exactly what you want.  I've never been a fan of storing valuable, encrypted data all over the internet, and I know how uncomfortable digital media can be.  Plus, I feel like, if it's password has "enough" entropy to be protected from interthugs, you'd have to write it down --> then you might as well just make a paper backup and keep it on your bookshelf .   

I recommend, you make a new wallet, generate a few addresses (take note of them), but don't send ANY money to it yet.  Then print a paper backup, delete the wallet (there's an option in the wallet-properties), then go to wallet-import and recover from paper backup.  You'll have to type in the 64-byte by hand, but it will be worth it.  If you get the same first couple addresses, you're nerves should be calmed.  You know, if nothing else, Armory version from Jan 25, 2012, will ALWAYS work to recover your paper backup.   Then you don't need to trust USB keys or CDs --> you can visually verify the integrity of that paper backup.  Print a couple copies and scatter them throughout your house.  Even if a jet engine crashed into your house, at least one of those backups would survive.

Joric just recently got pywallet working with encrypted wallets.  I may leverage his work to learn how to convert Satoshi-client wallets, but for now I'm avoiding that for a couple reasons. I recommend any money be moved through the network.  My biggest concern is both satoshi and Armory using the same addresses at the same time...

[etotheipi]

Zero-confirmation transactions fixed!  (well 95%)    See top post for more information. 

I will be ready to release alpha (including binaries) as soon as I get some folks to help me test the latest commit in the qtdev branch!   I have properly tested offline wallets with a new wifi-less laptop and have already sent multiple tx via USB key.  It's about 1 min per tx if the laptop is right next to you.  Error correction works, watching-only wallets produce the same addresses as reg wallets, offline wallet transactions are smooth as a baby's butt, and paper-backups are easy to hide in a book on your bookshelf!   I can't find a hint of a problem anywhere! (besides a couple zero-conf issues with individual addresse ledgers: they are purely a display problem, and Armory restart will resolve those)

As a reminder, build instructions are here.

I also updated the screenshots page on bitcoinarmory.com:  http://bitcoinarmory.com/index.php/start-page/sample-page/screenshots

[casascius]

Random idea: if I didn't live in the US, I might be bugged by the US spelling of "Armory", and almost would want to be able for the logo and everything to appear as "Armoury".  A low priority by all means, but something bound to be requested if it hasn't come up already.

[etotheipi]

Random idea: if I didn't live in the US, I might be bugged by the US spelling of "Armory", and almost would want to be able for the logo and everything to appear as "Armoury".  A low priority by all means, but something bound to be requested if it hasn't come up already.

Ehh, I don't agree.  That's like saying that that my name, "Alan" should be changed to "Allen" if I were to move to the West coast (where that spelling might be more common).  "Armory" is the name of the software.  If we were talking about a generic armory somewhere, I'd agree with you. 

Plus, I don't really want a variable-spelling name if I ever get a copyright/trademark/LLC.   That's complicated...

[casascius]

Ehh, I don't agree.

You have a decent shot at being the de-facto client for a worldwide currency, because I'll bet people abandon the Satoshi client in droves at the first sign of real competition.

I live in the US too, so "Armory" is the preferred spelling for me as well, and such a change is a feature that would not benefit me at all.  The least I suggest is this might come up again, especially if the code attracts other contributors interested in localizing for other languages.

[etotheipi]

Ehh, I don't agree.

I live in the US too, so "Armory" is the preferred spelling for me as well, and such a change is a feature that would not benefit me at all.  The least I suggest is this might come up again, especially if the code attracts other contributors interested in localizing for other languages.

Actually, translations are something I want to support.  In fact, maybe I should make that a high priority, given your optimism about widespread adoption

The easiest way I can think of, would be to offload basically every string/message in the program, to a dictionary in a separate file (i.e. msgWarnDeleteWallet['en']="...").  Then users can replace the file with translated versions, which can be bundled with the program and selected through command-line options.  

Is there an "official" way to do/support this?  Or is my theoretical technique sufficient?

[ZodiacDragon84]

might be something to look into etotheipi

https://bitcointalk.org/index.php?topic=61044.0

[btc_artist]

Watching..

Any chance of switching to an MIT or BSD-style license?

[Stemby]

Is there an "official" way to do/support this?

Armory is Qt-based, isn't it?

http://developer.qt.nokia.com/doc/qt-4.8/linguist-manual.html

Ciao!