Look in the bottom-right corner of Armory, It should say (approx)  "Connected (290474 blocks)".

My guess is that it shows a number far less than 290,474.    Did you move your Bitcoin-Qt/bitcoind datadir recently?  When this happens, it's usually that someone puts Bitcoin-Qt in a different place, but Armory keeps reading the old, stale blockchain in the original directory.  So it will never see new blocks.   Just a hunch...

You're suggesting Armory might be "broken" in your subject.  I'd appreciate if you'd change the top post subject if you don't actually believe that.  

Also, in your example of "If I sell you a laptop"... if you sell me a laptop for secure computing and I don't wipe the OS before I use it, there's always something you can do to compromise it.  Even if I fix the RNG thing as you recommend, there's plenty of other ways you can compromise a system if you have full root access to it for an unlimited amount of time.

Finally, I don't have a GUI method for inputting entropy directly into Armory.  It's not laziness, I'm avoiding users entering "99999999999999" for their entropy because they want a brainwallet and think no one would ever guess that.  So I have simply provided (in other posts) the way this can be done from the Linux shell very quickly, to make it clear it can be done but you accept the risks if you don't do it "right".

Example using a shuffled deck of cards:

In Armory, go to "Restore Wallet" and restore a single-sheet backup.  Enter that:

fntf euji uofg kkhf  ewfe keft uawj garh  twsu
sdwe nift ijso dhgg  ghjf sigo tunw uteu  hafo

You can do everything as you did it before.  Including making a paper backup, which will just show those two lines.  Which of course should be backed up.

Perhaps I misread their comments about it.  Perhaps the different sources I was thinking about were the list of things it does differently on each OS.

Bear in mind that creating the wallet seed only requires 32 bytes of real randomness.  Even an offline computer will have no problem with 32-bytes, and that's far in excess of the really-actually 16 bytes that is considered secure.  This isn't RSA where you have to do a search through a large number of random might-be-primes. 

I agree it wouldn't hurt to add extra entropy sources, but I think it's quite a stretch to call it insecure.  This is FIPS standard for generating random numbers for cryptographic purposes (but, I know you're talking about the seeding instead of the algorithm).  When we make an Android app, we absolutely will be supplementing the entropy sources since we have a plethora of entropy sources such as audio and video.  For now, I've been recommending that if people are paranoid, they can actually use dice or a deck of cards to do their own entropy.

Crypto++ pulls entropy from /dev/random or /dev/urandom, but that is not it's only source of entropy.  Their docs are pretty explicit that it uses multiple sources.  Plus, /dev/random actually is extremely reliable, but it's also a very scarce resource: it can't generate a lot of random numbers.

Look at the section on AutoSeededX917RNG:
http://www.codeproject.com/Articles/16982/Applied-Crypto-Pseudo-Random-Number-Generators

Specifically this table from that article:



For more information look up

FIPS PUB 171 Key Management Using ANSI X9.17

Sweet!  That's very encouraging, considering it wasn't compiled on a pi.  It will be really easy to add it to my regular release scripts now. 

When you say you had to install those things, it occurred to me I think I forgot to post the RPi dependencies.  I had some issues with those three packages, and would love to know if I resolved them.  But I guess I didn't bundle them with it...

If it's easy, can you wipe the pi and try it again with just the packages in the following tar.gz?

https://s3.amazonaws.com/bitcoinarmory-releases/armory_rpi_dependencies_armhf.tar.gz

Those last numbers are just a timestamp -- i.e. when the package was signed.  The example on the website is probably for a different package, which was signed at a different time.  It's nothing to be worried about. As long as the last 8-16 characters before it match what you expect, it's good.

The relevance of the timestamp is that one day in the future, I might lose control of that GPG private key.  If that happens, I would revoke the key, which should notify people not to trust anything signed from then forward.  ANything with an earlier timestamp would be safe, because you knew that the key was still secure at that point.

In practice, this is kind of useless without a trusted timestamp server, because the attacker could sign with any timestamp they want.  If you use a timestamp server, you can prove that the signature existed before the given timestamp.

We are interested in the feedback, though we are already aware that there is a large learning curve, and barrier to entry for the app.  We are working on ironing out the current state to make sure it is the best thing out there for the power-users, and now that we have a real team, we can devote resources to making an easier-to-user version.

With that in mind, feel free to provide feedback.  Just don't be surprised when I inundate you with a list of things already in the woodwork to address most of it

Search for "Type 2 deterministic wallets".  You'll find it

Actually, you should be able to do a "sudo make install" to put Armory into your system folders, but it won't update your applications menus, etc.  You'll still have to run from terminal, or create your own shortcut.  Thinking about it -- we really should integrate those things into the make-install operations...

The problem with Bitcoin-Qt is not normal.  Given what you said, you should have to do nothing else.  If you haven't messed with any settings, don't start Bitcoin-Qt, and Armory will start it for you.  If you have installed Bitcoin-Qt in the standard location (i.e. through the PPA/package manager), then it should just work.  If you downloaded that separately and unpacked it such as in your downloads folder, you'll have to adjust the "Bitcoin Install Dir" in settings to point to it.

If you want to run it yourself, go into settings, disable the first checkbox, then close Armory and start Bitcoin-Qt/bitcoind.  Once it is finished synchronizing, then start Armory.

Hope that helps.

We need to see a logfile to know for sure what's going on.  But there's no reason to mess with your bitcoin.conf unless you already have a custom one.  If you never setup a bitcoin.conf, you don't need to mess with it.  If Armory is running bitcoind  (auto-bitcoind), it will create one.  If you are running Bitcoin-Qt or bitcoind yourself (manual bitcoind), it's not even necessary because Armory doesn't even use RPC (it communicates solely via P2P with bitcoin-qt as one of its peers).

When you compile from source, you are not installing Armory.  It creates it locally.  As such, you get nothing in your applications menu, and URI-registration won't work.  If you want to start it from a terminal and later close the terminal, run it using "nohup python ArmoryQt.py &".  Or create a shortcut in your app bar that simply does "python /home/<user>/BitcoinArmory/ArmoryQt.py" (it will essentially do the nohup thing for you).  Without it, Armory is linked to the terminal which was used to open it, and will close when the terminal is closed.  nohup tells it not to "hang up" when the terminal is closed, essentially detaching the two of them.

Multisig transactions bigger than 3-of-3 are valid but not standard.  This means that doing such transactions is technically valid, and if they show up in the blockchain, they will be accepted by all peers on the network.  However, no peers running unmodified Bitcoin clients will even forward the transactions, and miners will not mine them if they see them.  If you broadcast a 5-of-7 multi-sig transaction (create or spend), it will be DOA to most/all of your peers.

If you want to use them, you must seek out a miner who will agree to mine these transactions for you, and it will take a very long time for it to get into the blockchain.  i.e. if you make an agreement with a miner that represents 0.5% of the total network mining power, it will take an average of 200 blocks (1.3 days) for it to be mined.  It may take a few hours, or a week, depending on that miner's short-term luck.

By the way, I am not posting the next testing version for a couple days, but it would be stellar if someone with a fresh Raspberry Pi could test the Raspbian build I posted a couple weeks ago.  I don't need a full report on functionality, etc... just want to know if I got the dependencies right and if it runs at all on a fresh Raspbian install.  I'm not very confident that it will, but I'm ready to be surprised!

https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.90.99-testing_rpibuild.tar.gz

HorseRider:  So one of the issues with the current wallet implementation is that wallet.unlock() will unlock and verify all the private keys in the wallet.  The verification is there to catch money-losing bugs, but it necessarily is too slow for wallets of that size.  I suspect that's what the issue is... you can use wallets of that size for everything except for signing... and you can sign with them but you'll be waiting for 100k ECDSA calculations each time you try to sign something.

The new wallet format I keep talking about solves that problem.  It only unlocks and verifies what it needs to.  But that new wallet format is a ways out (it's high priority after 0.91-beta, but it will still take a while to iron out the design and test it).

Armory won't even let you create the transaction though.  However, you should be able to change the behavior by simply adding a "No" button to the dialog that says "Do you agree to a fee of %s?":

https://github.com/etotheipi/BitcoinArmory/blob/master/qtdialogs.py#L5471

Change


to


The logic is already there to ignore the warning if "No" is clicked, but I disabled the "No" button for the reasons already mentioned.  However, to actually use this, you'll have to create-unsigned, then use the offline-signing window to sign the transaction and then "Copy Raw Tx (hex)" (in expert mode).  Then you can copy the tx into one of those push-tx tools. 

One problem is that Armory will not see it until it's included in a block.  It may propagate, but your local Bitcoin-Qt/bitcoind will not forward it to your Armory instance, so you'll have to watch the tx using something else, perhaps blockchain.info.

Just to reiterate picobit's point:  Armory's hands are tied on this one.  You can use a modified version of Bitcoin-Qt to broadcast a tx to dozens of peers with sub-standard fee, and you are pretty comfortable that at least a couple of peers will accept and propagate.  If you don't mind waiting, that's okay.

The problem here is that Armory doesn't have dozens of peers.  It is connected to the network through exactly one peer: your own Bitcoin-Qt/bitcoind -- and one that is usually following the rules.  When I first created Armory, I tried putting in a min-fee-override, but quickly found out it's pointless.  The tx has to go through that bitcoind, and it will be DOA if it doesn't have enough fee for relay.  100% failure rate, guaranteed.  So I had to disable it, because it was pointless, since 99%+ users don't have a setup capable of doing it.

Technically it can be done if you run a modified version of Bitcoin-Qt or bitcoind that will forward it in addition to modifying Armory to do it, which should be pretty easy.  It's just that few people will actually do this so it's disabled.

Glad to hear it's working well!

If your computers are stolen, you only need to install Armory on a new computer, restore your wallet from your paper backup, and immediate sweep the coins out of it to a wallet that only you control (perhaps create a new wallet at that time, create a backup, and then send the maximum amount from the old wallet to the new one).

The wallet encryption that Armory uses could take a computer millions of years to break.  Even if your password is really weak, it should still hold off the attacker for 72 hours, giving you time to sweep your coins before they get access.

The bitcoin scripts are pretty simple, but making sure you're doing the right thing can be challenging -- for instance, you can create multi-sig script for receiving the money, but most tools don't display and validate the script properly.  You'll have to make sure you do that part correctly, too.  Luckily, if you do it wrong, the network likely won't propagate it (just don't mine it yourself!).

If you want to use P2SH, you would hash the output script and construct the address string using 0x05 instead of 0x00 as you would for a normal address.  But this is irrelevant if you're manually creating transactions, since the network never sees that prefix byte -- it's only an identifier for the address strings that are passed around between humans, but are not included in the actual scripts inserted into the blockchain.  

But if you're doing a lot of one-off multi-sig transactions, and not necessarily interacting with others (for now, maybe you just want to protect your own money with this tool you're creating), then I would recommend using vanilla multi-sig without P2SH.  This will make it easier to find your money if you later need to search the blockchain for multi-sig addresses that are relevant to your wallets (P2SH will hide those details).  A full-featured multi-sig solution (like Armory will hopefully do soon) will use multiple wallets with meta-data and a structured key selection that makes P2SH safe in this respect.  Until then, you can use plain multisig scripts which are standard up to 3-of-3.

Finally, I recommend you do all your testing on testnet.  Everything is identical, except if you do use P2SH, use the following prefix bytes for generating address strings:

   Regular Addresses = '\x6f'
   P2SH Addresses = '\xc4'

---

Onto the fun part -- this can all be done with armoryengine.  And the latest version of armoryengine also recognizes and displays P2SH addresses (on the "testing" branch), though it doesn't quite know what to do with multisig scripts.  Nonetheless, you can manually put together the pieces using https://bitcoinarmory.com/developers/python-scripting/ as a guide.

If I was going to do it, I would use regular multisig: I would probably use Armory GUI to create a transaction sending X coins to a regular address, but don't send it yet, create an unsigned transaction.  Then go hex-diving into that transaction and replace the TxOut script (and var_int preceeding it) with the multisig script.  In fact, you can create the script with my untested function pubkeylist_to_multisig_script(pubKeyList, Mreq).  Though, it's a very simple script:


If you're doing 2-of-3, get the three public keys, and put the binary forms of them into a list, something like:

Now remove the var_int and script from the recipient txout (don't mess with the change output!), and put this varInt and script in there.  Unless I missed something, this should be a valid transaction.  You should be able to sign and broadcast it (you might even be able to do it with Armory as if it was an offline transaction, though it also might choke on the form of the receipient "address" -- let me know!).  

Spending it, is more challenging with the available tools, but it can be done.  The gist of it is that you will create the spending transaction, using as an input the unspent multi-sig (or P2SH) TxOut.  You will create the TxIn script using the standard form


You will need the code here to produce the hash that needs to be signed for OP_CHECKSIG/OP_CHECKMULTSIG.  You will sign that hash with each of 2 of the 3 private keys, and put an empty string (OP_0?) in the other location (they need to be in same order as the keys in the TxOut script).  That should be a valid spend script.

Of course, I probably missed all sorts of small details, but it's late, so I'll have to defer discussion of those details until later.  Hopefully that's at least enough to get you started.

Although I wouldn't normally recommend this, I think it's no so bad to do that as long as it's your online computer with watching-only wallets.  Anything stupid that the online computer does will be caught by the offline computer (as long as you actually check all the transaction details before continuing).

Of course, I may be neglecting some corner case situation, so I still wouldn't put an official endorsement behind it.  But having a stable version that does the reviewing and signing certainly reduces the risk considerably.  (but definitely don't use it for your offline computer yet, unless it's tiny amounts of money)

Thanks for the positive feedback!   Understandably, most people post and communicate with us when things don't work, and it's not a high priority to contact us when it does work.  It makes me feel like it doesn't work for anyone, even though it obviously does -- we had more than 20k downloads last month...and less than 20,000 nasty emails     So, it feels good to hear a success story occasionally.

---

Just an update on the new version:  I decided there was a new feature I wanted integrated that was too good to wait for the next version.  So I pushed this next round of testing back a couple weeks while we iron this out, which also gives us more time for some internal testing.  Hope to have it finished by mid next week!

Getting armoryd working on windows will be much more challenging than linux (which is five commands plus getting txjsonrpc).  I'm not sure we've even tried armoryd.py in Windows without having the whole build environment setup.   As CircusPeanut said, you might only need to get the _CppBlockUtils.pyd and .py from a preinstalled version of Armory, but there might be other .dlls you need as well.  Maybe just copy those two files plus all the .dlls from the installed Armory dir, into your checkout directory.  Or use Linux... which is dramatically easier to setup.


We should have a function in there that gets you an unsigned transaction for a list of recipients.  To make the signing process easier, you can look at extras/cli_sign_txdp.py which is a full-featured, command-line interface for signing offline transactions.  The two arguments for it are wallet file and a unsigned.tx files from Armory. 

Be aware that the master branch may not have all the armoryd.py features implemented.  The testing branch will have all the updated features, but of course is the unstable version.  Hopefully we'll have that ironed out in a couple weeks.