Armories are usually highly-secured buildings full of weapons and tools.  You could consider the capabilities of Armory as "weapons" or "armor" for dealing with Bitcoin attackers.   Or, the focus is more on the "fortified building" aspect, not the weapons.  

And of course, it's not necessary for names/trademarks to match the exact nature of what they represent.  Just the gist of it (or not all: there's millions of companies that use a name that has no relationship to what it represents:  what about "Microsoft"?).  If I had known an illegal weapons marketplace would open with the same name, I might have considered something different...

I would like to add, that anyone who donates $20 or more can have my my quantum computing seminar, previously prepared as a final project for a graduate level computational-complexity class.  However, I wouldn't recommend it to anyone that doesn't have a strong math background -- it's very math-heavy.

I'm not worried about people noticing the similarity in names.  I already expect people will notice both.  I just want to make sure no one mistakenly assumes real association between the two "projects." 

At least that one is called "The Armory" and I am just "Armory." 

I like stability and consistency in my life.  It's not always about just being right.  Dealing with that would be quite a disruption to my development plans.  Unless I can get them to "settle" by donating $10,000 to my crowdfunding campaign

Except for that part about US FBI/DEA/ATF agents who want to learn more about "The Armory" and keep ending up at my site, wondering if there's a connection.   It shouldn't matter, but I suspect it's not trivial.

F*#(@*&##^!!&#@*

Even if I had trademarked the name in relation to Bitcoin, I don't it would've mattered.  They're walking all over the criminal law, they sure as hell aren't going to care about IP/trademark law.  I'm going to have to think about what to do to distinguish my program from that.

The main wallet is always looking ahead 100 addresses.  As soon as a transaction appears in the blockchain that contains an address not officially generated yet, the wallet will then extend the pool and continue watching.  As long there are no stretches of consecutive unused keys greater than 100 in length, the other wallet will automatically follow along.  100 is just the default, and can be manually increased by using "wlt.setAddrPoolSize(10000)", if your use case results in [potentially] much longer strings of usued keys.  Finally, if you know something like this happened, you can manually tell the wallet to extend the keypool (just not through the GUI, yet).

btc_artist:  this is already part of the SelectCoins algorithm optimization  (or at least it is in Armory, I assume Satoshi SelectCoins is similar).  But you don't always win when you do that -- you frequently have no way to construct a transaction without doing something that invokes a fee (usually having to combine lots of tiny inputs to make the transaction).   

From talking to gmaxwell, it sounded like the dust-output trigger (for sending a tx with any sub-0.01 outputs) is universal.  In otherwords, there are plenty of miners that will mine large transactions, or transactions with young inputs, but all nodes impose a fee for dust outputs.  Without it, there's nothing stopping people from spamming the network with single Satoshi coins and adding a GB to the blockchain per day.

I have a very slight preference for RocketHub, but it only matters if you are completely indifferent to sending BTC vs entering CC information.  There's nothing wrong with BTC donations! (in other words, pick whatever you want, and only pick RH if you don't care one way or another)

Yup 2.1 BTC to the BTC address or $10 through RocketHub for the encryption seminar.  Maybe if I can generate enough interest, I could finish my crowdfunding on that alone  (only need about 900 people to buy in!)

Thanks again, Cypherdoc.  Both for the donation and the kind words.  It's great to know that my work can be so inspirational to others!


I wish I knew the answer to this question.  However, I have been thinking about how one could avoid USB keys altogether, as they seem to be the weakest link in this process.  Since there is no executable that needs to be run to use offline wallets, any method of transferring ASCII from one computer to another is sufficient (QR codes + Webcams, IR tx/rx streams, etc).  The narrower the channel, the better, it's just that USB keys are very convenient.  

The offline wallets would be 100.00% perfect security (besides physical security) if I just find another device that can help me move 1-3 kB of text back and forth without the autorun risk.  The problem is, something like printing/scanning QR codes could be more trouble than it's worth.  But if you have ludicrous amounts of BTC, it could be worth anything!  (I think the best solution right now for the super-ultra-paranoid is to just setup a webcam on both systems, and I can add functionality to have all the data displayed/read as QR codes)

You are now the 183rd person to suggest this.  So maybe I will do it.  I was resisting because I didn't want to have to try to support someone else's program on the wide variety of platforms out there.  At the very least, I can add it only for Windows and Ubuntu, which should be fairly uniform.  Alternatively, I might just make a PyQt wrapper for it, now that I'm fairly experienced with PyQt...

I don't know if you tried the calculation... but getting 12 specific letters after the '1' is pretty difficult.  In fact if you were searching for '1GoldmanSachs...', it would take you an average of 1,850,000 years with oclvanitygen on one 5870.  No big deal, I have 3 of them!

I guess you missed slide 4 which says "Press F5 Now!"     As you can tell, I put a lot of time into the slide transitions, and creating a "visual language" for the encryption concepts.  You should be able to examine every small detail of each of those complicated slides, and everything matches up.  In fact, let me know if it doesn't!  I'll either fix it, or explain why it actually does

Ugh, somehow I ended up unsubscribed from this thread, so I missed all this discussion.  I wanted to respond to the discussion about Grover's algorithm...

Any circuit that can be made on a classical computer (such as a circuit for evaluating sha256(sha256(X))), can be made equivalently on a quantum computer using quantum circuits.  As long as the quantum system includes entanglement (which a lot of QC research right now doesn't even include, because it's hard enough without it), then it can apply this concept of "quantum superposition" to execute Grover's algorithm.  It doesn't matter whether the black-box evaluates sha256 or sha256^2, it still takes N-byte input, and spits out an 32-byte output.  The difference is that the sha256^2 black-box will probably evaluate at about half the speed of the sha256 black-box.

Below is an illustration of how Grover's algorithm works.  It makes a lot more sense when you understand one key point about quantum computation:  Just like Schrodinger's cat, all possible outcomes are equally like, and it's the act of measuring the state (opening the box and checking on the cat) is what "collapses" the probability space into one state or another.  So the cat is both dead and alive, until you open the box and then it is dead or alive with 50% probability of each measurement.

With quantum circuits, we start by preparing the qubits to have a similar all-states-equally-likely situation.  If we were to measure the state at this point, we would get exactly one state, and the one we get is completely random (and then the system assumes that state).    If there are two correct answers and N possible states, the chance of getting the right answer is 2/N which is approximately 0 (the same as making one random guess).  However, each iteration of Grover's algorithm nudges the probabilities slightly in favor of the correct answer:




At the end of ~O(sqrt(N)) iterations of Grover's algorithm, we then measure the state for the first (and only) time.  Now, the chance of measuring the wrong state is 2/N which is approximately 0.  The two correct states now contain all the "probability", and when we measure the qubits we will get one of the two answers (it's random which one we get).  Unfortunately, the act of measuring it destroys the quantum goodiness, so if we wanted to get the other answer, we'd have to repeat this process from the beginning (which would take as long a time as the first), measure again, and hope we get the other answer.  (this assumes we know how many correct answers there are, which wouldn't be the case with hashing:  all we know is that if there is an answer, Grover's algorithm will get us closer to it, a lot faster than random guessing).

This process can be applied to any "pure guessing" problem, as long as a quantum circuit can be constructed to evaluate it.  However, it's been proven that every classical circuit has a quantum counterpart, the issue is being able to string enough quantum gates together to build the complete circuit.  It also requires having enough qubits in your system to be able to represent all possible inputs.  If we are hashing a 256-bit number, we'll need 256 qubits to plug through this circuit.  Building a usable 256-qubit QC with entanglement might be a couple decades off...

Thanks to Cypherdoc for making an extremely generous donation.  There's another hero in the house!   I am now at 20% of my goal, and three weeks to go!  Thanks so much to everyone who has supported me so far!  I am becoming very optimistic that I can actually make the goal and become an official part-time Bitcoin[-related] developer!

Anyone else have comments about the encryption seminar?

What's your math background like?  I'm curious how much non-math-y people will get out of the presentation.  Since I am a mathematician, it's difficult for me to judge

Update:  I'm distributing the encryption seminar, finally!   It is titled:  Understanding Encryption:  Using Boring Math for Something Useful
The presentation has a good mix of math and concepts, so there should be something for everyone.  If you don't know any math, feel free to skip the math slides and just try to absorb the concepts.  I think everyone can get something out of it!

I have already sent it to everyone who donated >=$10 already and whose email address I have.  If you have donated but have not received the seminar, please email me at etotheipi@gmail.com and I will attach it to a reply email.  The seminar is available for both MS Office (*.ppt) and OpenOffice/ODF (*.odp).  

If you received a copy, please don't forward it to anyone else -- this is a reward for donating!  In fact, if you want to make your previous donation more effective, tell your friends about how great the seminar is, and send them to my donation page if they want to acquire a copy, too  Thanks for your support, and I hope you learn something from it!




I think it's been pretty successful so far!  I'm at 1/6 of the funding at about 1/4 the funding time.  I'll need a bit of a push to meet my goal, but it's tough to say that it hasn't been successful alread.  I think it's already more money raised than some people would've expected, and I still have 3 weeks left!  I'll be releasing some new features soon, hopefully to generate more interest.  Stay posted!

mila,

I put some thought into how Armory could be used for a webserver application, and I realized that with just a couple lines of python, you can generate addresses no problem on your webserver.  I added a couple convenience functions and committed them to the master branch of Armory. Here's what you do:

(1) Load Armory on your computer.  
(2) Create a regular wallet.  
(3) In Wallet Properties, "Create Watching-Only Copy"
(4) Upload watchonly wallet to webserver
(5) Setup webserver to load wallet and call wlt.getNextUnusedAddress() for each request
(6) Sit at home with the full wallet and watch/confirm/send transactions while the webserver does the work!

Demonstration code to see how to access/manipulate the wallet from a python script:


Here's the output on a watching-only wallet (this is actually the output of the second time I ran it):


Your webserver can run blissfully ignorant about what is actually going on with the wallet, it just gives out a new address on every request.  You can sit at home on your computer with Armory running and the full wallet there, with full control.  But someone who compromises the webserver will not get anything!

If you want the webserver to track incoming transactions, it will require loading the blockchain and checking for new blocks periodically.  It's not a lot of code, but I'll save it for later if you are interested.

One other thing:  Armory uses the crypto++ library, which is not particularly fast at ECDSA operations (and my key generation algorithm is kinda slow, which is why I'll be upgrading to a new one, soon).   My [decent] system can generate about 200 addr/sec.  So this script takes a few sec to run.  But all keys are stored in the wallet, so they don't have to be recomputed when you restart the script.

Unfortunately, I'm new to Qt, so my UI code is probably "suboptimal".  On the other hand, this is mostly Python, so it should be uniformly more pleasant to deal with   I'm hoping to kind of lock-down the C++ stuff, and then users can fork and modify the code-base strictly with python (and PyQt is delightful!)



I'm only motivated by money if it's enough to cut down my hours or pay off a significant portion of my house.  So, I decided to see if I could pull off the first one with crowdfunding in exchange for keeping my software awesome and open source.  I'll let you know how it goes

John,

I'd be thrilled if I was responsible for encouraging some new features in the Satoshi client!  Of course, I'd like to take credit for having done it first (like crowdfunding based on those features before anyone else has them ), but I really think the Satoshi client needs some goodies beyond security upgrades.  Security is great and all, but the Satoshi client is both the security and the face of Bitcoin, and I think the face is starting to look kind of boring...


sirk390,

You are awesome!  Thanks so much!  Please email or PM me your email address and/or mailing address, if you'd like your rewards.  I insist that everyone who deserves a USB key and/or Tshirt should get one... the bulk discounts I get for 50+ and 100+ are pretty substantial


On that note:  I haven't gotten the shirts made yet.  I was planning on doing something very simple like

(btw, that's not me... I'm much paler than that )

My girlfriend says I should include the full logo on there, but I have a few arguments against it.  I'm looking for feedback about it:
(1) I am really happy with my logo/icon, and I think it looks great without needing to identify the brand behind it.
(2) I think that identifying the brand is largely unnecessary:  the Bitcoin community is small enough that if someone else is not part of the community, they won't care what brand is behind it (in fact, advertising a brand explicitly may be undesirable for some of us geeks).   If they are part of the community, they will probably recognize it and it won't matter whether the "ARMORY" is there. 

For instance, I own one of these XKCD shirts.  I get all sorts of positive reactions to it regardless of whether the person knows what XKCD is.  But, I know my logo isn't as cool as a velociraptor (I mean, what is cooler than a velociraptor?).  Recommendations are accepted.

I absolutely love the concept of negative reinforcement for being stupid, but it's not always that simple.  They may have created their private keys months before any kind of security breach happens, and even forgotten or not realized that their private key was so simple.  Then, 6 months later, they're on the forums complaining about how their BTC were stolen, and sending all the client developers on a security breach investigation.  Their refusal, of forgetfulness, to mention that they used a simple password is irrelevant:  they will still waste a lot of people's time and generate negative exposure for Bitcoin (about how it's insecure, etc).

Since I'm a client developer, liability issues enter my mind quite frequently (not legally liable, but guilty-conscience liability).  Even if it wasn't my fault, I don't want to deal with figuring out what happened, especially since users don't like to admit that they did something else most other people would criticize them for (like 4-char passphrases).   At least if you have to go through a lot of effort to make that mistake, then you should already be aware of the consequences and how likely they would be.

ctoon,

I totally agree that ARM would be a perfect platform for offline signing device.  But I don't know a thing about it.  I don't have a clue where to even start with that!  I have enough other things to do on Armory, I think I might leave porting it to ARM to someone else more experienced.  Though, I'll happily provide guidance for how to read/write wallet files, etc.  Perhaps we can emulate a TPM device...

Slightly related, I think once I get a JSON-RPC interface hooked up, there will be a lot of great options for interacting with Armory from other devices or lightweight programs.    Based on feedback, I think JSON-RPC will be my first priority after fixing the clean-shutdown-in-windows issue, and pulling the RAM req'ts down to Earth.  It seems like webservers have a lot to gain from a nice interface to watching-only wallets, and will typically have the resources to hold the blockchain in memory (at least for now) so it would be damned fast for blockchain operations, too.

On that note, I have taken recommendations from earlier in the thread and started looking at mmap() for reducing RAM req'ts.  It's very impressive:  on my linux VM with 1 GB of RAM, it works (using only a couple hundred MB) but it's a little slow.  On my main box with 16 GB of RAM, it not only works, but it caches the whole blockchain and runs just as fast as the full-RAM version!   It appears to be the best of both worlds... but I've only tested it on linux with mmap(), haven't tried the windows equivalent, yet..