Topic: Armory - Discussion Thread - page 170. (Read 521749 times)

Thanks for the awesome instructions. Now I, too have Armory running on my Pi! I sent half a bitcoin to your donation address.

etothepi, is it currently possible or would it difficult to implement command line transaction signing? For instance...


Prompting for the encryption password if encrypted, and wallet ID if it can't determine that on its own.

It could then either prompt to sign with information about the transaction, or just sign it and display that information.

Otherwise I have to get a USB hub, because with mouse and keyboard plugged in to the Pi, I have no USB ports left for transferring the files on USB drive.

now that is a cool solution.  just to make sure i understand; when you boot from the USB, its like a Live CD session where everything is in RAM.  nothing touches the hard drive, right?

Ack!  This is an unfortunate situation -- one I haven't figured out how to handle yet (gracefully) with Armory.  The problem is that Armory sends the tx to Bitcoin-Qt, which then adds it to its memory pool and "forwards" it to all its peers.  If that happens to be zero peers because connection is bad, then tough luck.

The issue is that if Armory tries to re-send the tx, it sends it to the Satoshi client which says "Oh, I've already seen this" and drops it immediately without re-forwarding.  So far, I haven't figured out a graceful way to get around this.  No matter what Armory does, ibitcoind/-qt won't re-broadcast it.

The non-graceful way is to restart Bitcoin-Qt (which should clear its memory pool), and stop Armory, delete armoryhomedir/mempool.bin and then restart Armory.  Then try again.

If you are familiar with the RPC interface to Bitcoin-Qt, I haven't tried the following, but I understand it should work:  double-click on the transaction in the Armory ledger, and if you are in advanced or expert user mode, there should be a "Copy Raw Transaction" button at the bottom.  You can copy this into the bitcoind/-qt RPC interface using "sendrawtransaction".  I've never done it, but gmaxwell tells me that will always re-broadcast, even if the tx is already in the bitcoind/-qt memory pool.

I really want to find a good way to resolve this issue, but I haven't found it yet...

Quick question... I sent a transaction at roughly the same time my modem lost its connection, now it's sitting there in sent/unconfirmed status. Is there any way to force a transaction to be rebroadcast? That could be a useful advanced feature to have.

Also, it just so happens the transaction in question was to address 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv

You could make your own live distribution that has the serial getty lines properly disabled in the inittab...

I understand your hesitation to include features that might get you blamed for theft of bitcoins.

Instead of explicitly defining the hardware layer, would it be possible to have Armory be agnostic about such things? I'm not sure how/if this would work in Windows, but I'm imagining that a *nix user could set up a device (/dev/foo) on each computer that when read from/written to would communicate with the other computer. Then in Armory, the user would just specify which device should be used for communication. The user would be liable for making sure that connection was secure, and Armory would attempt to communicate with itself through that device, failing gracefully if unable.

That's basically it.  You can say that it's easily mitigated, but it's a potential disaster if it's not.

Take this for example:  someone wants to do offline transactions, hearing that Armory is a super-secure way to do it.  So they download Ubuntu, grab some RS232 hardware, and set everything up.  The problem is they downloaded the wrong Ubuntu version, and it comes with drivers or modules that they weren't expecting.  Or they're just oblivious anyway because they heard about how secure Armory is, what could go wrong?

You might say:  "Well, even if they get the login prompt, it would take a while for someone to figure out how to compromise it."  I guarantee you that a large number of users (correlated with the same ones that do the previous part carelessly), their login and password for the offline computer and wallet will be one of the dozens of website logins&passwords they have saved in Firefox (Edit->Preferences->Security->Saved Passwords->Show Passwords).  And the attacker probably got there because the user never changed their primary computer password after the same one they used at Mt. Gox got compromised last year.

I don't mean to suggest that the RS232 link is useless.  It's just something that I can't promote as a general solution because of the counter-risk associated with doing it incorrectly.  Most of the other solutions proposed here, if you do it incorrectly, no one gets signatures from the offline computer, including the intended user.  The wallet will remain secure, just inaccessible until they figure it out.

As I've said in other posts: I end up with most of the blame when a compromise does happen, so while it's easy for others to say "ahh, careless users are not your problem"... well I disagree.  I'd like to think that part of the reason Armory is successful is because I try really really hard to prevent newbies from shooting themselves in the foot (as evidenced by the endless warning dialogs and corner-case checking).

What were the drawbacks of RS232 again? The possibility of opening a terminal through the connection? I seem to remember that was fairly easily mitigated, but I can't find the thread now. I just ordered a Raspberry Pi (actually two, one from BitMit, one from Newark) to set up as an offline wallet storage box. Eventually I wanted to connect it to my main computer via RS232 and play with that idea.

I now see that something like this has already been considered ...



[Edit: But then re-considered here as well ....

]

Meh, I've already received a ton of donations from a vast array of users, well in excess of the cost of the certificate.  It's not only unnecessary to ask for it, it seems kind of beggar-y.  Really, that was part of the original intent of the donations anyway -- not just to help me work less at my job, but cover related expenses.  And this is purely a software project (no hardware), so I hardly have to spend money on anything else.  

So, while I won't turn down any donations, I don't need to solicit any.  After all, I do still have a real job

And now that you bring it up, maybe I should stop procrastinating and actually do it!  I figure I'll do it at some point...

bitmit to the rescue: https://www.bitmit.net/de/q/?q=raspberry

Why not specifically ask the windows-crowd to donate for that. They're used to paying for proprietary bloated shit. They should cough up the bill for using the crap.

Sorry for the rant, this shit still gets to me.

A QR code can hold up to 4K of alphanumeric data.

 - http://stackoverflow.com/a/3964342


[Edit:

Online Armory --> Offline Armory could be 100Kb+.  Thus not a workable plan.  Thus was described here:

The rest of my argument is invalid.]


A USB barcode/QR code scanner acts as a USB keyboard:

 - https://bitcointalksearch.org/topic/handle-a-wasp-and-you-will-not-get-stung-practice-safe-bitcoin-105824

Maybe a QR code could be an alternative for shuttling the offline transaction that would be more secure than mounting a USB storage device?


If the online and offline systems are not sitting right next to each other then the QR code would need to be transported over somehow. If that's needed then a $100 Android (or any other) mobile smartphone works for scanning the QR code displayed by Armory on the online system and then the mobile's display will present the QR code to the barcode/QR code scanner connected to the offline Armory:


Or a little $50 thermal printer could print the QR codes for transfer to the scanner for the offline Armory:

 - http://learn.adafruit.com/mini-thermal-receipt-printer


Then the Android mobile could scan the QR of the signed transaction and send it without even needing Armory by sending it as a raw transaction like is available from Blockchain.info/pushtx or the raw transaction feature of BrainWallet.org right?

 - http://blockchain.info/pushtx
 - http://brainwallet.org/#tx  [Edit: Looks like the signed transaction from Armory is its own format, and not compatible with raw transaction ?]

running two separate computers is the very idea of Armory (one for the offline wallet and one for the watching-only wallet).

With my USB stick I could do everything on the same PC:
- boot normally from harddisk: internet connection, bitcoind and Armory watching-only wallet. Create unsigned tx and save to the fat partition on the stick
- boot from USB, sign the tx with offline Armory (this needs no block chain)
- reboot from harddisk and send the signed transaction

whenever the system is booted from its harddisk the wallet on the encrypted part of the stick is securely hidden

so the unsigned tx has is located in the unencrypted data portion of the USB stick and can be accessed after you've booted up a desktop computer from the encrypted Linux OS on the USB stick, correct?  but where is the Satoshi client/blockchain that you need Armory to access?

I have the full Linux system with offline Armory in an encrypted partition on the same stick as the fat32 partition I use for transaction exchange.
- when a system is booted from the stick no processes on the possibly infected system are running
- when the stick is inserted into a running system everything except the data partition is encrypted and can't be changed
- malware on the online computer could destroy my offline OS but not install anything into it

so then how do get access to the unsigned tx; a second USB stick?

this is the reason why I boot from the USB and no storage component of the host computer is part of the file system in the running OS

as a general option for the rest of us, it would be cool to have a USB version of Armory that is easy to implement.  i'm not sure though once the USB is connected to desktop/laptop how its protected from malware residing on the desktop/laptop.

I was just investigating USB auto-run vulnerabilities, and was surprised by the number of attack vectors that Ubuntu has (mainly due to tendency to "auto" do stuff for the convenience of the user, despite exposing attack surface).  I bet the USB viruses could be completely a non-issue if you compiled away all the auto-everything that is normally part of the kernel and/or desktop manager.  The only thing I want the USB key to do when I plug it in is mount automatically and don't do anything else (also disabling file browser icons, which were a source of previous vulnerabilities -- injecting code that exploits an evince bug into the icon of a file, which will automatically get loaded when the file browser pops and up loads the icons to display the files).  

I never considered that the answer to remaining attack surface of the USB method could just be a custom-compiled distro...

Of course, I have no experience with that, but I'm sure someone else does