The original price list was $10 for the seminar.  $25 for a USB key, $50 for Tshirt, $100 for all of the above + Casascius coin, $300 for used laptop, and $500 for all the above.  I will still honor those, at least until I run out of stuff...

Glad to see people still interested!

Btw, I'm getting close to a preliminary RAM-reduction release for Linux (and Windows will get implemented as people help test Linux).  I'll post on the main thread when I'm ready for people to help me test -- hopefully Friday!  And it will need quite a bit of testing!

Offline wallets are not threatened by the physical security of the data moving back and forth.  I don't care if an attacker has access to the data I'm moving back and forth between the computers because it's only raw transaction data, which is all going to end up in the public blockchain anyway.  What I'm concerned about is what nasty things an attacker can do to a USB key to "autorun" and compromise the offline system when it is plugged in.  While autorun.inf is the most vulnerable way to induce arbitrary code execution, there's other creative ways attackers have been able to compromise system.

In Windows, there was a vulnerability in the ...png?...library that is used to render the icons embedded in files to be displayed in the file explorer next to the file name (for instance, you always see .exe files that have custom icons when displayed in file browser or on the desktop).  An attacker only needed to modify the icon header of the file to exploit that vulnerability which gives it root access to your system.  And simply the act of viewing the file in a file browser--you don't even click on it--will cause the malicious icon code to be executed and compromise your system.  This is not USB-specific, as it could be easily executed via email if you can get the person to simply download the file... compromised as soon as the download directory is viewed in a file explorer)

And to do this, the attacker wouldn't even be adding any files to the key: it would simply be bloating one of the existing files with a new icon header.  In the same way, he could pull a private key off the system by embedding it in slack space in one of the existing files, or injecting it into the icon header, or using steganography to hide it in an existing image file (if there were any on the USB key).  Unfortunately, private keys are small enough that they could be embedded just about anywhere.

EDIT: How could I forget NTFS alternate data streams!.  Windows was trying to improve compatibility using them, but opened up a massive security hole in their filesystem:  the ability to embed data and even executables in files in such a way that it doesn't even show up in file explorer!


I'm not suggesting any of this is likely -- it requires very resourceful attacker.  But these things are possible.  I'd rather come up with a 100% solution now and never think about it again.  That's why I started this thread.  It seems that USB-serial port cables are good way to move raw ASCII back and forth without any risk of the online computer inducing remote code execution on the offline system.  i.e. the offline system doesn't even receive a file via serial, it listens on the serial port for an ASCII-only stream of bytes that can be parsed successfully as a BIP 0010 packet.  The only potential vulnerability there would be if the "unserializeAscii" method in Armory had an exploitable vulnerability in it -- but that is ludicrously far-fetched for an text-parsing-only method that fails to do anything else unless the received data passes a sha256 checksum and matches the BIP 0010 format.

EDIT: On that last note, anything that will be processing the BIP 10 "packet" would be vulnerable, not just the BIP validation method.  If for instance, I had an "eval(packet[i:i+j])" as part of the BIP 10 parser, an attacker might be able to construct a valid BIP 0010 packet that has malicious executable [python] code between byte i and byte i+j.  This is one reason I avoid "eval()" function at all costs in all python programs.  But as you can see, the available attack vectors are cut down to virtually nothing with a few precautions.

It sounds like the pure-ASCII-ness of the tx proposals (TxDPs) will benefit me here, compared to coming up with a binary encoding scheme.  It will add a little more bloat, but guarantees I won't be sending any bytes that might trigger special character/command bytes by accident.  When you speak of XON and XOFF, I assume you are talking about "defining" such bytes, myself.  I will pick the XON, XOFF, TX_SEPARATOR, etc:  I will be defining this stupidly-simple protocol myself using only bytes across pins 2 and 3. ...?

How do the buffers work exactly?  If I do not execute a serialPort.read() or readline() in python, is the buffer accumulating the data being sent from the other system?  Does it only accumulate when I create the serial port object?  Perhaps I can clear the buffer the moment the user presses the Receive-Tx-Over-Serial button on the Sign-Transasction dialog.  Is there a "danger" in the buffer getting too big?


I'll stay away.  I don't mind doing a little extra work myself to add simplicity to device pairs with different OSes. 

Thanks for the reply.  It has been extremely useful!

Yup, just got a Null-modem connector and it works like a charm.  I can't believe how ridiculously easy it is to use serial ports!  (at least, in Linux).   

For reference: I have combined two USB-serial cables and one null modem (F/F) adapter.  The total cost is about $40 after shipping.  Not too bad if you're protecting thousands of dollars.

With everything hooked up, the cable stretches about 4 ft, which is enough if you keep your laptop anywhere near your regular system.  You can get longer USB serial cables if necessary.

So now I want to start thinking about an actual interface to use them... I need to solve a few problems.  And I'm happy to do it purely in Linux for now, and figure out how to port it to Windows later.

• (1) Detect presence of serial port (looks like this is a good way to do it in Windows, and perhaps I can just search /dev/ on linux...?)
• (2) Detect presence of other device on serial port.  I think there's pins for this, but I don't know if it can detect just by being connected, or if one has to do something to make itself detectable
• (3) Can devices both read and write at the same time?  Can I have both devices always "reading" and pop up a message asking to accept incoming data?  Then one device can start transmitting when it's ready, the other will detect and ask for confirmation?  Or do I have to explicity put each device into receiving mode and not send while it is receiving?
• (4) Seems like the serial link will be very reliable.  I can probably have the sending node just keep transmitting the data over and over with a sha256 checksum at the end for integrity checking.  That way the receiving device only looks for the "beginning of tx" and "end of tx" markers, checks whether the data in between matches the checksum, and if not, just grab the next batch of bytes in the buffer and try again.
• (5) The online computer only needs to check for incoming data to know when to stop sending data.  Receiving data implies that the user has reviewed the unsigned transaction and signed it, and is sending it back.  Auto-receive from offline system and pop up "Confirm broadcast"? 
• (6) How do I check for other programs that may be running on the serial port?  I mean, there shouldn't be... but it would be silly not to verify.  Is there a way to query a device for processes "attached" to it? 

Btw, for those following Armory:  I won't be implementing this for a while, but it looks like it would be fairly easy to do once I have a plan, so I'm hoping to get input now to fill in the gaps in my own knowledge.  After RAM-reduction, compressed public keys, and address books, I might spend a weekend on this.  Given the simplicity of the interface, it might be doable in a day!

Okay, let me know if you find any more issues like this.  I'll go ahead and make those two changes in the master branch   Always glad to help!

-Alan

Oh, also change that "str( ... )" on ArmoryQt.py:1431 to "unicode( ... )". 

I haven't been paying much attention to different locales, though fornit is helping me with translation, so it will be happening at some point.  Until then, try one fix in the code for me just to see if it works:

armoryengine.py:622, change it to:


That won't change the locale to english, but it might cause your current locale to display properly. 

Some significant bug fixes in...

Armory version 0.61-alpha  (source-code update only; no Windows binaries)

Since this is mainly a Linux/OSX update (which must be pulled from git and compiled, anyway), I have updated the repo but not the Windows binaries.  I probably will not make those for 0.61 at all.  Instead, this will show up in Windows when it is merged into the RAM-reduction upgrade.

--Implemented static linking of Crypto++ to permanently resolve a number of linking issues on Linux/OSX.  If you had to use LD_PRELOAD before, you no longer have to!
--Created a qresources file to hold all the images in an importable python module.  This solves the problem of images not loading when using a running from a different directory in Linux/OSX (or using a shortcut).  The downside is the qrc_img_resources.py file is 10 MB!  But it's worth it for the robustness.
--Fixed a minor bug with the warning dialog for receiving coins with a watching-only wallet.

On the topic of RAM reduction: I spent all day yesterday re-organizing blockchain scanning code, and working a new system of "registering" wallets and addresses with the BlockDataManager (BDM).  The new system will allow me to combine the initial scan with the wallet-tx search (it would be done multiple times if I had just blindly thrown in mmap).  It also gives me a way to ask the BDM if the next balance-retrieval operation will take a while, and then I can notify the user instead of just locking up the interface for 15-60 sec -- this would be primarly for importing a new address, requiring a full rescan of the blockchain.

I expect to have an experimental version of RAM reduction for Linux/OSX next week.  I'm going to have to modify some of the interfaces to accommodate long-action-times, and modify some stuff under-the-hood to make sure it respects balance retrieval operations.  I'll probably introduce all sorts of bugs, which users can help test while I work on making it happen on Windows, too.

Given the current stability of Armory, I may consider RAM-reduction, address books, and system-tray notifications to be a milestone for Armory Beta.  Mainly because it will at least be usable by everyone (even with 1 GB of RAM), and the networking-independence is going to be a pretty substantial overhaul under-the-hood.  

Thanks randomguy7.  Someone actually reported that bug like a month ago, and I totally forgot to take care of it.  It should take like 10 minutes. 

It's nice that these tiny, mundane bugs are the worst thing people can find in the program

So I actually got two USB-serial-port-emulators and a F-F adapter.   It was surprisingly simple to get setup in Linux (I haven't tried Windows yet).  I simply plugged it in, and checked dmesg to see that it was creating the /dev/ttyUSB0 device.  After that, I used a spare computer screw to short pins 2 and 3 and used gtkterm to receive/display data.  Looked up how to access serial in python -- ridiculously easy, as expected:


And the text showed up on the gtkterm session.  Great!   But I couldn't get any further.  I installed gtkterm on a different Ubuntu system, connected both serial cables together using the F-F adapter, loaded the same programs, and tried to read/write between them:  no luck.  I tried disconnecting and shorting 2&3 again on the other computer to make sure it worked -- it successfully receives messages sent to itself.  But when connected via the F-F adapter to the other system, none of the messages make it across.  Perhaps the F-F adapter doesn't "crossover" the pins as I would hope?  I'm not phsyically savvy enough to hack a crossover connection between the two cables to test it.  Or I just don't have the right stuff...  

On a separate note, is there a way to guarantee that nothing else is listening on the serial port?  For instance, a coworker mentioned to me that really old Linux systems automatically enable console logins over serial ports!!  He said the same thing would happen with IR, too.  But that it's easy to disable, and any modern linux distro wouldn't have that to begin with.  Of course it concerns me, but I'm confident that there are some simple precautions that could be taken that would 100% guarantee there are no more programs acting on serial data.

EDIT: I just noticed on the product description page that the F-F adapter says:  "Pins:  straight through".  I guess that answers the question...

What did "make swig" do?  It should've dumped a _CppBlockUtils.so/.dylib file into the base directory, along with CppBlockUtils.py.  If those are there, then it's probably an import error instead of a can't-find error.  Open a python shell and type "import CppBlockUtils".  It will tell you more-specifically what the error is. 

Also, make sure you've updated to the latest commit on master.  There cannot be any more issues with Crypto++, anymore.

Certain built-in safeguards could help.  But what I described above would work fine, too, since you are filling and emptying the address in one round.  The address will never have coins again, and most clients will never reuse any address for receiving or change outputs. 

If you want to refill your account, then get a new address from the service and and send more coins to it, from any other address (or mixer).  What I described above only needs to be done once, and then you can carry on as normal, using only the original address for signing messages declaring your intentions.

IANAL, but I seem to remember that: No matter what terms and conditions there are, even if you signed a contract, "gross negligence" is still usually legally enforceable.  A party in a contract like this cannot act grossly negligent and cause harm to another party, then claim that their contract protect them from being responsible.

The question is, can you show gross negligence?  It might be worth a quarter-million dollars to try.   (assuming US).  I argue that designing a universal backdoor into a piece of software that is marketed as "secure", and not letting the users know that it exists but letting your employees know is either grossly negligent, or borderline criminal (well some employees have to know, but how many?).

Why can't you use the mixing service to fund the same address that will be funding the account? 

-- Service provides address, A, to which you want to deposit 20 BTC
-- Create new address, B
-- Send 20 BTC from your regular wallet to the mixer, to be sent to B
-- Send 20 BTC from B to A (through Tor)
-- B is now your permanent identity with that service:  use signed messages to communicate actions.

It's an extra hop, but it maintains the anonymity, because B is used exactly once and never linked to any other address.  And the service doesn't know anything beyond that address B sent 20 BTC and is now empty.  Then you don't have to do anything with the service other than send them money and sign messages, with one address.

This is actually just a problem with the way I setup images in Armory.  They all look for the "./img/something.png" which doesn't exist unless you happen to have the executable in the same directory as the original build.  In Windows, I solved this by just copying the img directory into the "ArmoryStandalone" output directory and packaged it along with all the .dll's.  In the future, I think I will use qrcresources to try to embed all of them in a python file, I just haven't gotten around to figuring out how to use it yet.

The webwallet could have a page providing the exact same interface as Armory has:  "Enter your message and it will be signed by the specified private key."  And a button for "copy signature block to clipboard."  It would be trivial to add, since it already uses your private keys to send money. 

The big issue is how to handle stolen wallets... and maybe this condition would defeat the purpose of the whole exercise:  if they have to resort to secondary verification methods because message signing isn't reliable, then did the message-signing provide any valuee?  I'm sure there's still plenty of useful applications.

I just started a new thread, just for Armory+OSX:

Building Armory on OSX. 

I really want to see this discussed, but this thread is getting hammered with stuff that isn't relevant to a lot of people who subscribed.  Please continue discussion of OSX-specific stuff there.  I will eventually get an OSX system and use that thread to help myself get through the build process and create binaries.

Moving on:  the reason RAM-reduction is not so simple, is because the code assumes that a full-rescan of the blockchain takes <1 second.  Therefore, I need to reorganize code to make sure there is only one full scan (on load) and that all information on all your wallets is collected during that scan.  Of course, importing an address or new wallet will require a new rescan, but I've already created the "Please wait!" window to accommodate that.  And I will be adding a bulk-address-import window, so that you don't have to import one-by-one, waiting 30 seconds after each.

In the future I won't even be doing a full rescan of the blockchain on each load, but at the moment it is adding a lot of robustness and simplicity, not having to create any intermediate files at all.  There's no tx data stored between loads.  I haven't seen any issues with balances or spent-output corruption.  But if there was, it can always be fixed by restarting (and thus rescanning from scratch).

There seems to be endless difficulty getting Armory compiled and running properly on Mac/OSX.  Some versions of OSX/Homebrew/Xcode seem to work fine.  Others keep putting up a fight.   I am starting a new thread, because the original Armory thread is getting diluted with OSX discussion.  I definitely want to see this discussed, but I want to reserve the Armory thread for OS-independent discussion and features, and let the OSX crowd discuss, here, how to get it working on all relevant versionsof relevant software.    

The current Build-OSX-from-source-code instructions (appears to work in Lion)
Red Emerald Discusses updates he made to the build instructions for OSX 10.7.3 and Xcode 4.0.3

I have listed a couple questions below to seed this discussion, mainly because I have never even touched an OSX machine, much less done any development on one.  I need some serious education on this!

• Most important question:  How many different binaries do I have to produce to support 95%+ of Mac users?  It sounds like I may not be able to compile just one binary... but maybe I can?
• What is the absolute most-recent version of OSX?  What versions correspond to different "generations" of Macs/OSX?  What is the earliest version I should be supporting?
• It sounds like compilation is going to be based on not only OSX version, but homebrew and xcode.  How much different is this software between versions of homebrew and xcode?  I am hoping it's just like gcc: the version doesn't really matter as long as you have it.
• Someone is offering me a Macbook with OSX 10.3.9 -- is that going to be sufficient for all development activities (for the near future, at least)?
• Anyone have fail-proof instructions for getting an OSX VM working?  I've tried three times and failed.  I'd much prefer to get VM running than get new hardware.

Btw, if you missed it in the main thread, I modified the repo so that Crypto++ is statically compiled into the _CppBlockUtils.so file.  This not only resolves a plethora of linking issues on OSX, but also Linux.  Crypto++ source was already included in the project anyway, so I might as well.  It increases build time significantly, but only the very first time you "make".

Cypherdoc,
Yeah I saw it.   I'll take you up on the offer if I can't get a VM working.   I have some time before I get around to that, though.   Unless you're trying to get rid of it now,  I'll wait.

On the other hand, if the system is free, I don't mind paying for shipping.   In the long run, it is probly better for me to just take it.  Can you tell me OSX version and explain how it relates to other systems likely to be used by others?

@Red Emerald,

Fantastic!  It sounds like we're converging on something!  Unfortunately, I will have to compile it myself in order to release actual binaries.  But perhaps it's possible to make a script to do it.  I think I will have to split off compile directions, since the existing directions seem to work for some versions of OSX, but then need your directions for others. 

@Torus,

Did your problem go away?  I can see a very minor bug in the code that might cause that to happen rarely and randomly.  I don't see why that last commit would make a difference, and it should work if you just close and reopen it...?  Either way, I made the super-simple fix and will commit it with the next batch of bug-fixes.

@Everyone else:

Today is my day to do RAM-reduction.  I don't know if I can get it done today, but I have a solid 8 hours of uninterrupted time to dive into the blockchain utilities and get it done!