I'm more referring to the use case that some party puts 1 BTC in a private key and distributes it like a coupon code, or as a refund for something, or when you're redeeming a Casascius coin.  Or in the case of "buried keys."  I personally believe it's a waste of time to put any effort towards keeping those keys around, because that key is dead.  No one has any reason to ever send that key any money, ever again.  Sweep it and move on with your life.

And of all the one-time-use keys that are ever distributed to all the people that ever receive them.  How often do you expect such a key to be magically refilled?  Who is refilling it?  Do people like throwing money away?  What purpose could possibly be served by sending money to a completely-insecure key after it's been used once?

In reality, I'd have to spend time to complicate my interface to add an "untrusted keys" feature, and it would be absolutely useless.

If you really want to do this anyway, just create a new wallet, label it "INSECURE" and put such keys in there.  Then I don't have to add anything to my interface.  

P.S. -- I've pondered some kind of auto-sweep setting for certain addresses, but that doesn't work with encrypted wallets, and even for unencrypted wallets, I've never been comfortable with moving money in any of the users' wallets when they aren't looking, no matter how benevolent my intentions are.

I think the best thing to do is to spend a little bit of time on the forums and find out who the respected posters are.  Especially in the case of a girls-only posting site.  Most often, those highly-respected posters will respond positively to rational and non-spammy inquiries, and they would probably be willing to look into it themselves and then promote it themselves. 

You don't always win, since you can't always convince these strangers that what you're proposing is legitimate.  But in this case just piquing their interest might be enough:  a direct person-to-person, semi-anonymous payment system makes sense for girls with webcams.  If it's a good match, at least one of the people you contact will look into it and decide to become the proponent for it.

It's a billion times better if a respected member of the community posts about it instead of a new member with one post.  I'd almost rather that Bitcoin not get mentioned at all than see it cast into such a poor light by trolling evangelists. 

Just make yourself available to those members to help them understand it and make sure they're saying things that are factual and correct, and use references instead of just telling them.  In particular, I would reference the Reuter's Article and the WeUseCoins websites, mainly because Reuters is respected and shows that this is a real, respectable phenomenon, and not [necessarily] a scam.  Weusecoins, probably gives a more-concise introduction to what it's about.  Both are much better voices to promote its legitimacy than some shady dude with 1 post on a girl's only forum...

You might try doing a round or two of deblurring/deconvolution on the image, first.  Richardson-Lucy is a great algorithm if you can give a reasonable estimate of the blur function (which may not be too bad just assuming very simple blurring).  Do 2-4 passes of Richardson-Lucy, it might sharpen it just the right amount.  (I speak as if you would be manually processing the image with custom algorithms... I'm sure photoshop/gimp has some canned algorithms for this).

Well, there's also "sharpening", but I've never been very impressed with the sharpening algorithms out there...

I have read enough (U//FOUO) documents in my time, and this one fits right in.  The tone, the balance, and the constant declaration of "confidence" in a given statement is consistent with legitimate reports.  The crappy resolution is completely irrelevant, as the document was probably scanned or modified in some way to hide any information that could trace it back to the person who leaked it.

I'm impressed with the balance of the report.  I'm disappointed it doesn't mention any more about the legitimate uses of Bitcoin, but it is an organization devoted to fighting crime.  I can forgive them for that...

By the way, do you really think a troll would spend the time creating 4 pages of endnotes?    Plus, there's nothing really groundbreaking or sensational in the report that would justify spending weeks putting this together as a sham.  It's too boring to be a troll...

@ Foxpup

I just uploaded to the previous location a dark-background-fixed version of 0.76.  It has the new logo sizes, and it printing looks better:

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.76-python2.6-1_amd64.deb

Try it and tell me if that's any better.  I'm pretty sure that python2.6/amd64 is your arch.  I didn't feel like recompiling all of them just for you to test it...

There's lots of proposals for pruning.  None of them look like they're going to make it into the protocol/client any time soon.  The devs are more concerned that CPU and internet bandwidth are going to cap out before user start needing multiple hard-drives to store that data.  On the other hand, while the current client is full-blockchain only, the first-time  blockchain download is going to become a serious hurdle for bitcoin adoption.

This thread is full of discussion about this very topic (mainly starting on page 4).

The gist of it is that you have wallets and keys in your wallet.  If you import an insecure key to your wallet, someone can "pay you" by sending funds to it and making you believe you've received money, then yank it out from under you.  It's a very easy attack and completely avoidable.  This is why I plan not to allow importing of keys in "Standard/Beginner" mode in Armory.

The solution would be to have a separate portion of the program devoted to maintaining addresses for sweeping.  Well, sure.  You could do that.  But the vast majority of the time you receive an insecure key, it's because it's intended to be used just once.  Ever.  I don't really feel like designing and interface around something that should basically never happen, and just confuse users with the extra functionality.

That's not to say it can't be done.  I just won't be doing it myself.

However, if this thread is talking about multiple people eventually seeing the same key, then it makes sense for one user to keep the key around around, monitoring the network for when it receives more funds and sweeping it right away.  In fact, if this is done, I'll be setting up a daemon to do just that...  Might make the whole thing kind of useless.  But maybe I don't understand the application.

What's stopping the hacker's software from reading your settings file for OT and finding out what password picture it uses?

I've seen this technique on yahoo mail before, where the attacker has to put up a fairly generic webpage and doesn't have access to your password picture.  But if the hacker already planted software on your system, I would think it has access to everything it needs to impersonate the dialog.

I just tried this on a version compiled with 12.04 (python 2.7), on a 10.04 system (python 2.6).  I got a


Not really related to your question, but further justification for needing separate versions.  I really don't feel like battling glibc version compatibility issues...

---

More directly related to your question:  in order for the 10k lines of C++ to be made available to Python, I need to use swig to create a .so file.  This requires linking using -lpython2.X, which of course needs to be the one available on the system.  Then, the resulting .so file requires having that specific version of libpython2.X.so on the system. 

On the other hand, now that I look at it:  I don't see why I can't statically compile whatever version of python I currently have.  I don't think it needs to match the current python version.  That might be worth trying, though I don't think I can avoid the glibc issue I mentioned previously...

That's exactly what "sweeping" is for, in Armory.  Copy the key into Armory, select "sweep" and it will search the blockchain for the balance and transfer it to the selected wallet.  The private key is not saved (because if you are sweeping, it is assumed you don't trust it and shouldn't put it in your wallet).




If this becomes popular, it would be quite easy to add an entry field for inputting whatever it is you are proposing, then doing the hashing and sweeping for the user in one operation

Transaction fees come about from any one of three conditions, two of which you don't always have control over. 

(1) Priority of the transaction inputs:  age * size   (age is in block numbers, size is in BTC).  If there's not enough priority on the inputs, you pay a fee
(2) Total transaction size:  each input is about 170 bytes, each output is about 40 bytes.
(3) Dust outputs:  if any output is less than 0.01 BTC, you have to pay 0.0005 fee.


If you're talking microtransactions, you are probably hitting (3) every time.  But that would only cause a 0.0005 fee.  The priority issue is probably also an issue, but again only causes a fee of 0.0005 BTC.  Number (2) is what causes large fees.   If (1) and (3) are satisfactory, the transaction can be free if it's less than 3-4 kB. 

However, above 3-4 kB, you're going to be paying 0.0005 per kB.  As seen above, inputs are 4x the size of outputs:  if you can bundle up lots of your transactions into a single transaction with lots of outputs, you might be getting those extra outputs for "free".  i.e. if you're going to use 5 kB and return 90% of it as change to yourself anyway, you might as well try to batch all the transactions together.   You're already using 5kB of inputs, your fee probably wouldnt' even go up for 20 outputs.

Btw, I'm pretty sure that even the forced-zero-tx-fee branch of the Bitcoin client still requires a fee for dust outputs.  It's the only thing preventing nodes from spamming the hell out of the network and bloating the blockchain with dust.  However, many nodes will accept low-priority, large-kB transactions without any fee.

-Eto


P.S. -- There's more conditions that may result in fees that have to do with transaction volume on the network.  If blocks are getting full, you will pay more to get yours included.  I have ignored those here, because I don't believe that transaction volume is high enough on the network to induce those.  Worst case, your tx might be delayed a block or two until there is room for your standard-fee tx.

This is one reason why alternative clients have come about ...

I don't follow.  Or rather, I don't know why this is any more computationally inconvenient than a pure unspent-txout-list-merkle-tree.  Much of the tree would probably have to be recomputed anyway when you have hundreds of transactions removing and adding branches to the tree.  The only difference is that your main tree now only holds all "recipients" in stead of all unspent outputs, and each recipient has its own sub-tree of unspent outputs.   Either way, you have N unspent outputs that have to be represented in the tree, and updating 300 of them on a new block still requires substantial recomputations.  

In this case, each op requires updating a subtree and then the master tree after that.  If all unspent outputs were conentrated behind a single recipient, then we're back to the original proposal of unspent-TxOut-list trees, which was the basis for this thread.

Unless your point has to do with the general feasibility of maintaining such a tree.  Then it's a fair point, but I'm simply building on the original proposal (and its flaws).  

If one argument against it was that the 90% space savings isn't worth the tremendous complexity changes to the client and protocol, then my question is "is it worth revisiting it knowing that a change of similar complexity could save you 90% and give nodes the ability to verify balances without downloading the whole tree?"



Would you have preferred I started a new thread?  Then you could complain about the dozens of threads already out there discussing this general topic.  Plus, this isn't a "bump"... it's a legitimate expansion of the exact, original idea proposed in this thread.

Thanks for the bug reports.

(1) I'll try what you suggested on my various machines, with respect to python versions.  I have to make sure that just because it works on one system that I think has only 2.6, but it will on the others.  As happened with the 2.6 version that worked on 11.04 which appears to only have 2.7, but didn't work on 12.04.  Supporting all these different variants reliably is tough!
(2) I actually forgot to resize the dark-background logo before committing everything.  It's not a problem on regular backgrounds.  I'll try to remember it for final release of 0.76
(3) Wallet migration and encryption options are getting overhauls with the new wallet format.  For instance, fixing migration stuff won't happen til I support compressed keys, and it is of limited usefulness until I do.  So I wasn't putting too much effort into it, yet.
(4) If you're really anxious to change the encryption options, it can be done from the python shell, I just never put an interface into Armory for it.  There is a "test-change-KDF" test in the unittest.py file, which shows you what python commands need to be issued.  It will involve a readWalletFile() command and then another call.  The wallet will be modified in place, so you won't need to save anything back out.  I remember test passed, but it is of course recommended to make a backup before trying this.  There might be a long-forgotten reason I didn't finish it...
(5) I looked briefly at paper wallets on dark backgrounds... there wasn't an obvious fix for it that didn't make the print-dialog display suffer from the same problem you are reporting on the printout (...then no one would use it at all).  I'll see if it's not too hard to make the text gray when on a dark background, so that it will show up on screen and on paper both.


@ Teste,

I'll add this to my list of things to do to support other Linux versions.  I don't think it'll be that difficult, except that Armory is a python script so it will require having a couple of dependencies satisfied on the user's sides

Armory sends the Satoshi client the tx, then asks for the same tx 2 seconds later.  If it receives a reply, the client accepted it and broadcast it.  If it doesn't, an error message will pop up saying there was an issue and you should contact support (me).  If you didn't get the error message, then it means the Satoshi client accepted it.

Has anyone considered this idea using address/P2SH hashes as the "key" of the tree instead of TxOuts/OutPoints?   By doing this, lite-weight nodes could retrieve the entire unspent-TxOut-list of an address by downloading only a couple kilobytes but still have the same security of a full-node!     

Like the OP's generic merkle-tree-of-unspent-TxOuts, this would provide the same level of compression but additionally enable lightweight nodes to verify address balances within seconds.  That's because the leaf nodes of the ledger tree are actually lists of unspent outputs, instead of individual outputs (organized in sub-merkle-trees).

For convenience, I will use the vague term "recipient" to refer to the pub-key-hash160, or a P2SH script.  I'm sure a scheme could be created that takes into account arbitrary TxOut scripts and still have benefit of uniform distribution.  Here's how the "ledger" is created on a given block:

• All nodes traverse the blockchain and collect unspent outputs (can be done on an already pruned tree to be updated)
• The unspent outputs are sorted by their recipient, which can be done in linear time using bucket-sort (because the sorting keys are hashes which are uniformly distributed)
• For each recipient all of its unspent outputs are put into a merkle sub-tree.
• The sub-tree root for each individual recipient is put into a master merkle tree
• The fingerprint of the blockchain on a given block is the master-merkle-tree root.

Therefore, each address/recipient is one leaf node of the master merkle tree, and the value of each leaf node is the merkle root of the unspent-TxOut-list for that recipieint.

There's plenty of discussion already about how this fingerprint is distributed, so we assume that all full nodes have it and agree on it for each recipient.  So now you are a lite-weight node getting onto the network for the first time.  You have a list of addresses ("recipients") to collect balances for.  

• You download the headers (80 bytes each) plus the ledger-fingerprint at each block (32 bytes each).  Compute the longest chain.
• For each address, you query your peers with the recipient string.
• Each peer responds with the sub-merkle-root of that recipient, along with the entire merkle branch -- which should be 2*log(N) hashes, where N is the number of "recipients" in the blockchain with balance > 0.  If the blockchain has 100,000,000 addresses, this is about 2 kB worth of data.
• You verify the merkle branch against the ledger fingerprint for this block.  You now know that the sub-merkle-root is valid.
• You request the sub-merkle tree from your peers (which is just the unspent TxOut list for that address).
• You compute the merkle-root of the unspent TxOuts and verifies it matches the sub-merkle-root previously verified.

As long as the ledger-fingerprint (which is just an enormous-merkle-tree root) is somehow included in the protocol, then lite-clients could import addresses and verify balances for only a couple kilobytes and with the same security as downloading the whole blockchain!  

Oh, and you'd get the benefit of blockchain pruning, too.  A small bonus...

Please help test the new version:  Armory 0.76-alpha-RC1:  Layout Fixes&Memory, Table sorting, Fedora Compiling, --datadir


Armory now looks remarkably different yet actually the same, all at once!  In addition to some slight layout improvements, I've added memory to the major windows and tables so that windows open to the last position&size, and table columns will remember the widths manually set by the user.

• Dialog and Table Geometry Memory --  Dialog sizes and column widths are saved between loads.
• Smart Stretch factors -- Major layouts are more efficient and stretch more intelligently.
• Table sorting now works! --  You can now sort ledgers and address lists by any column. (not all tables have been upgraded)
• Added "--datadir" option -- Use "--datadir" to choose a different home-directory for Armory (i.e. keep wallets on a USB key).
• Fixed wallet corruption bug! -- A "wallet description" of more than 256 chars could overflow into and overwrite the encryption settings.  Fixed now.
• Fixed Fedora compiling -- I became aware that the latest version of crypto++ was [accidentally] dependent on a bug in gcc that was fixed in gcc version 4.7.  The latest version of Fedora uses gcc 4.7 and thus compiling fails.  I upgraded the included Crypto++ code with the official fix, so it should work, now.

I've provided the most popular downloads below.

Windows 64-bit
Ubuntu/Debian 64-bit, 9.04-10.10
Ubuntu/Debian 64-bit, 11.04+
Ubuntu/Debian 32-bit, 9.04-10.10


Layouts are more efficient and table sorting lets you find stuff easier!

New wallet format is on hold:  I started a complete overhaul of Armory wallets and probably spent a week getting about 30% done.  Not only is it hugely complicated (but worth it!), the new determinism algorithm has not been finalized by the Satoshi developers yet (it's not even an official BIP yet, and I don't want to release it until I know that they're supporting it).  Given that the 0.7X code is pretty darned stable, anyway, I think this will be the basis for Armory Beta!


So instead of a new wallet format, my final hurdle to beta will be completely eliminating all system requirements.  Mmap did not succeed on Windows 32-bit at all, and is still pretty heavy on Windows 64-bit.  I think it will be better to get Armory working on any hardware, and will give me a headstart on some networking stuff.


P.S. -- For anyone interested, Sipa has really locked down a great algorithm for the new wallets.  It allows you to deterministically generate new addresses and new wallets.  In fact, you can very quickly compute addresses of arbitrary dimension and index:  i.e.  you can get Address(12),  or Address(3)(9), or Address(98)(4)(182)(5)(48372221).  Of course, this can get wildly out of hand, which is why the new wallets will have a "convention" for what addresses are used and associated with each other.   Here's a diagram I made of how it will work (assuming it survives the BIP process).

This means that you can create a single wallet seed when you install Armory, and all future wallets you create can be regenerated from that seed.  Of course, you can choose to create new seeds to keep wallets truly separate.  But at least you have the option! 

I used dumb error-correction:  it's just regular checksums as seen elsewhere in the Bitcoin protocol.  All I do is hash the field, and add the first four bytes to the end of that field.  If a byte goes bad, I just iterate through the field changing single bytes until it matches the checksum again.

Hashing like this is not really intended for error correction, but 4 bytes is enough to do it reliably, and dead simple to use it.  And given the remarkably-low frequency of hard-drive errors, one-byte should be enough.  If more than one byte in the same checksummed field went bad, there's probably bigger problems.   

I decided not to use something more appropriate like Reed-Solomon because I thought it would obfuscate the fields (i.e. -- 256 bytes of data has to be converted to 268 bytes of coefficients, meaning you need another library in order to read the data even if you don't care about the error correction).  I just recently found out that's not true under my circumstances, so I may consider switching to it on my next wallet upgrade. 

Oh.  I didn't think that option actually worked!  Very interesting that it does! 

I would think any sub-standard fee broadcast by Armory would be DOA at the Satoshi node and never make it to the rest of the network.  Unless your Satoshi node is a special version designed to allow low-fee tx through...