We used checks. For high value transactions, cashier's checks. I don't know how this transfers to a bitcoin environment. Oh, there wasn't as much mail order back then. Most shopping was local.

The zerocoin part does more than defend against DOS, doesn't it? It also provides a degree of anyonymity, if I understand it. In the conventional multi-party anti-taint protocol, every participant knows the mapping from inputs to outputs. But in your improved protocol using libzerocoin, nobody sees the mapping. Now, this requires more than two participants, so considerable organization is needed to coordinate.

Still, this an application of the zerocoin protocol which doesn't have an impact on the blockchain. OTOH, it has a small anonymity set, so the benefit is rather modest.

I really like Adam's very creative idea earlier in this thread to have a pure-zerocoin system:

https://bitcointalk.org/index.php?topic=175156.msg2420768#msg2420768

The zerocoin paper proposed a hybrid bitcoin-zerocoin system. Bitcoins would be temporarily exchanged for zerocoins, and then exchanged back. Adam's idea was that zerocoins would be exchanged directly for zerocoins. Zerocoins could be mined directly, too. All this is a simple modification of the zerocoin protocol. In fact, it would be simpler in terms of code size, because you wouldn't have to support bitcoin transactions. No scripting language, no bitcoin validation rules. Just pure zerocoin spend transactions.

This would also free us from the forced assumption of bitcoin-zerocoin parity. The heavy resource requirements of zerocoin might naturally break that parity. (Admittedly, zerocoin would first be implemented as an extension to an alt, so the value in terms of bitcoins would float. But the simplification is still a win.)

There are various proposals to do P2P exchanges between altcoin chains. I don't know what the status is as far as Bitcoin support in the bitcoin-qt client. You'd have to have a new client to do the P2P protocol. But even if we had to rely on an exchange, it would be an interesting experiment.

The last problem for a zerocoin implementation is the generation of an RSA modulus for which no one knows the factorization. This is hard, and deserves more analysis.

Lois Lane:

How do you find someone who has spent a lifetime covering his tracks?

For some, he was a guardian angel. For others, a ghost, who never quite fit in.

What's the S stand for?

I sent a PM a couple of days ago to frankAcct366, and accompanied it with a bitcoin tip. No reply yet.

I aquired most of my coins by mining. This has no anology with currency (unless you're counterfeiting ) so I intend to treat bitcoins as precious metals and declare my profits as capital gains. Since I mined them more than a year earlier, they are long term capital gains. This is not as favorable as usual because it turns out that precious metals, even bullion, are considered "collectables" and taxed at a rate of 28%. Normal rate is 15%. If your overall tax rate is less than 28%, you can pay the lower rate. That is what I intend to do, based on my reading of the IRS documents.

I used to have one of these. In fact, I hacked a version of PGP to look for your private key on the ring, so you could sign or decrypt just by touching the ring to the reader. (Actually you had to kind of snap it in.) Since PGP already used the "key ring" terminology, I thought it was particularly apropos. Too bad they never caught on, although it would bring on the dreaded "stolen finger" attack.

I actually had an account with MTB back in the day. They partnered with David Chaum, guru of techno-privacy. Chaum had a place with Cypherpunks roughly analogous to Satoshi's around here, except he didn't have the grace to disappear mysteriously, and he very definitely had feet of clay.

Anyway, MTB offered accounts using Chaum's blinding technology, so the bank couldn't see whom you were paying, as long as it was another account holder. I don't think this would fly today, but that was before KYC etc. The experiment never really got off the ground, and it was terminated shortly after.

The OP has a piece of blinded ecash suitable for transfer to another MTB account holder, at least if you had a time machine and could go back to the 90's. They were all powers of two, hence the 128 cents.

Thank you so much for your kind and encouraging words. I'm sorry that I can't respond to each of you individually. But know that I am touched and encouraged by your words of support.

I thought I'd write about the last four years, an eventful time for Bitcoin and me.

For those who don't know me, I'm Hal Finney. I got my start in crypto working on an early version of PGP, working closely with Phil Zimmermann. When Phil decided to start PGP Corporation, I was one of the first hires. I would work on PGP until my retirement. At the same time, I got involved with the Cypherpunks. I ran the first cryptographically based anonymous remailer, among other activities.

Fast forward to late 2008 and the announcement of Bitcoin. I've noticed that cryptographic graybeards (I was in my mid 50's) tend to get cynical. I was more idealistic; I have always loved crypto, the mystery and the paradox of it.

When Satoshi announced Bitcoin on the cryptography mailing list, he got a skeptical reception at best. Cryptographers have seen too many grand schemes by clueless noobs. They tend to have a knee jerk reaction.

I was more positive. I had long been interested in cryptographic payment schemes. Plus I was lucky enough to meet and extensively correspond with both Wei Dai and Nick Szabo, generally acknowledged to have created ideas that would be realized with Bitcoin. I had made an attempt to create my own proof of work based currency, called RPOW. So I found Bitcoin facinating.

When Satoshi announced the first release of the software, I grabbed it right away. I think I was the first person besides Satoshi to run bitcoin. I mined block 70-something, and I was the recipient of the first bitcoin transaction, when Satoshi sent ten coins to me as a test. I carried on an email conversation with Satoshi over the next few days, mostly me reporting bugs and him fixing them.

Today, Satoshi's true identity has become a mystery. But at the time, I thought I was dealing with a young man of Japanese ancestry who was very smart and sincere. I've had the good fortune to know many brilliant people over the course of my life, so I recognize the signs.

After a few days, bitcoin was running pretty stably, so I left it running. Those were the days when difficulty was 1, and you could find blocks with a CPU, not even a GPU. I mined several blocks over the next days. But I turned it off because it made my computer run hot, and the fan noise bothered me. In retrospect, I wish I had kept it up longer, but on the other hand I was extraordinarily lucky to be there at the beginning. It's one of those glass half full half empty things.

The next I heard of Bitcoin was late 2010, when I was surprised to find that it was not only still going, bitcoins actually had monetary value. I dusted off my old wallet, and was relieved to discover that my bitcoins were still there. As the price climbed up to real money, I transferred the coins into an offline wallet, where hopefully they'll be worth something to my heirs.

Speaking of heirs, I got a surprise in 2009, when I was suddenly diagnosed with a fatal disease. I was in the best shape of my life at the start of that year, I'd lost a lot of weight and taken up distance running. I'd run several half marathons, and I was starting to train for a full marathon. I worked my way up to 20+ mile runs, and I thought I was all set. That's when everything went wrong.

My body began to fail. I slurred my speech, lost strength in my hands, and my legs were slow to recover. In August, 2009, I was given the diagnosis of ALS, also called Lou Gehrig's disease, after the famous baseball player who got it.

ALS is a disease that kills moter neurons, which carry signals from the brain to the muscles. It causes first weakness, then gradually increasing paralysis. It is usually fatal in 2 to 5 years. My symptoms were mild at first and I continued to work, but fatigue and voice problems forced me to retire in early 2011. Since then the disease has continued its inexorable progression.

Today, I am essentially paralyzed. I am fed through a tube, and my breathing is assisted through another tube. I operate the computer using a commercial eyetracker system. It also has a speech synthesizer, so this is my voice now. I spend all day in my power wheelchair. I worked up an interface using an arduino so that I can adjust my wheelchair's position using my eyes.

It has been an adjustment, but my life is not too bad. I can still read, listen to music, and watch TV and movies. I recently discovered that I can even write code. It's very slow, probably 50 times slower than I was before. But I still love programming and it gives me goals. Currently I'm working on something Mike Hearn suggested, using the security features of modern processors, designed to support "Trusted Computing", to harden Bitcoin wallets. It's almost ready to release. I just have to do the documentation.

And of course the price gyrations of bitcoins are entertaining to me. I have skin in the game. But I came by my bitcoins through luck, with little credit to me. I lived through the crash of 2011. So I've seen it before. Easy come, easy go.

That's my story. I'm pretty lucky overall. Even with the ALS, my life is very satisfying. But my life expectancy is limited. Those discussions about inheriting your bitcoins are of more than academic interest. My bitcoins are stored in our safe deposit box, and my son and daughter are tech savvy. I think they're safe enough. I'm comfortable with my legacy.
[edited slightly]

Indeed, I bricked my laptop when I was first experimenting with this technology several years ago. Fortunately it was under warrantee and they replaced it. All you have to do is make sure your BIOS is up to date and that won't be a problem.

As far as XMHF (TrustVisor) I just bought a new system from bitcoinstore.com which should support it. This is a newer technology than Flicker which should remove some of the limitations. I'm worried though because Jon McCune, whose group is doing both of those projects, left CMU for Google. The projects seem a little rudderless now.

Start of the security analysis

bcflick is a Flicker PAL (Piece of Application Logic) designed to increase the security of the Satoshi Bitcoin client. Flicker uses security features on modern processors to create an isolated, cryptographically protected segment of memory which is immune to tampering by other code running on the same computer. These security features go by different names depending on the manufacturer. Intel calls it TXT, while AMD calls it SVM. I will refer to it here simply as the secure mode.

The threat model which bcflick is designed to address is a thorough infection by sophisticated malware. It is assumed that the attacker can corrupt the operating system, install key loggers, read and write files and network traffic, and generally exert arbitrary control over the computer. Despite this powerful attacker, bcflick lets the user spend and receive bitcoins, and enforces a daily limit on the number of bitcoins spent. The attacker, as well as the user, is bound by that limit. This prevents the attacker from stealing the bitcoins all at once. He is forced to let them trickle out a little at a time, giving the user a chance to detect and mitigate the theft.

Although this is a powerful attacker, we have to restrict its capability is one way. We assume that there is some way to boot into a "safe" mode, out of the control of the attacker. Typically this would be done by booting from an external medium, a CD or a USB drive. Technically, sophisticated malware can insinuate itself into even a boot from a clean medium, by inserting itself into the firmware of some peripheral device, or even the BIOS. However, these techniques are little used and hardware dependent. In practice, booting from a clean external device will produce a safe mode with high probability.

bcflick uses the safe mode for three purposes. On initialization, the wallet is encrypted, and the decryption key is passed to bcflick, along with the daily spending limit. It is also used for error recovery, such as if the TPM timer gets reset, or if a Flicker crash gets things out of sync. By booting into safe mode, the user can reset the passphrase, and that will reinitialize bcflick. Last, if the user wants to spend more than the bcflick policy permits, he can boot into safe mode, unlock the wallet with the passphrase, and create arbitrary transactions, bypassing bcflick.

The remainder of this document discusses the security design of bcflick. It is dived into four parts. I first list the security assumptions. The second part addresses security related to Flicker and the secure mode. The next part discusses Bitcoin related security. Finally, I conclude with further directions for research.

Actually TPM's do have a secure clock. There's just no guarantee about when it will keep ticking. You can detect if it gets reset because there is a 20 byte nonce, which changes at every reset. I've found that my HP laptop preserves the timer in S3 sleep, I don't know for sure, but I shut it down for a few seconds and it seemed to be preserved, which was a surprise. And my HP desktop system is never shutdown, but it preserves the timer across reboots.

If bcflick eetects a timer reset, it won't let you spend anything for 24 hours. But you can always boot into a safe mode and reset your passphrase. This will reininitialize bcflick and you can spend up to the daily limit, right away.

In this post, https://bitcointalk.org/index.php?topic=67508.0, Mike Hearn gives a good introduction to trusted computing technology and how it could help secure Bitcoin wallets. I've been working on these ideas, using the Flicker software that Mike linked to, and it's about ready for testing, if anyone is interested.

Basically it's a patched version of bitcoin-qt/bitcoind (for Linux only) that enforces limits on your daily spending. You could get infected with malware and the most it could do would be to drain your wallet a little bit at a time. All this with a single machine, although only certain models of Intel and AMD processors support the secure mode.

Mike gives a good summary of the principles of trusted computing. Suffice it to say that the technology allows you to create a piece of code that can run unmolested by the rest of the computer. The TPM chip is used to cryptographically protect its data. The data is sealed to the hash of the secure code, so that only that piece of code has access to its secrets.

I'm using Jon McCune's Flicker technology. Flicker switches you into the secure mode for just an instant, and then switches you back out again. In this way, the secure mode doesn't have to coexist with the operating system, which would require hypervisor technology. Flicker is only about 3000 lines of code, small as these things go.

I've made a Flicker module (they call it a PAL) called bcflick. And I've patched bitcoind to make calls into bcflick to generate new keys and to sign transactions. The Flicker module knows the wallet encryption key, while bitcoind (normally) doesn't. So the only way to sign transactions, for you or for malware, is to go through bcflick. Bcflick knows the time from the TPM and keeps track of the amount spent today, and will refuse to sign a transaction if the daily amount were to exceed the pre-set limit.

Because Flicker is so minimal, it has limitations. The total size of the PAL has to be less than 1 Meg. And the size of the input to and output from the PAL is a couple hundred K. More importantly, the PAL can't do any device I/O, because that would interfere with OS management of devices. Basically, the PAL starts up, reads input buffer, does work, and writes its output buffer, all in the blink of an eye. Actually, that is a little exaggerated about the speed. Because the TPM is so slow, and because of the firmware overhead in switching into the secure mode, a Flicker call takes a substantial fraction of a second.

These Flicker limitations restrict what we can do to strengthen a Bitcoin wallet. We can't ask the user to approve spends, because of no I/O. So the policy enforcement has to be self-contained. The daily spending limit seemed useful and not too complex. More complicated policies could be supported, such as adjusted daily limits based on the average of recent days. More ambitious would be to take into consideration infow of funds; this would require parsing the block chain, including dealing with reorgs.

It's best to start with a new wallet. If you have some funds, transfer them elsewhere temporarily and delete wallet.dat. After you finish initialization, transfer your funds back to new, bcflick-protected addresses.

In more detail, bcflick must be initialized when running cleanly, i.e. malware-free. This is unfortunately impossible. An approximation can be achieved by booting from a live CD or USB. Doing this will eliminate all but the most sophisticated threats.

In this mode, start bitcoind with the -flickerlimit switch. This will allow you to set the daily spending limit that bcflick will enforce.  Then encrypt the new wallet with a long passphrase. This will pass the wallet encryption key to bcflick, along with the daily spending limit.

If you don't want to transfer your funds away and you are certain that you are not currently infected with malware, there is a shortcut. Boot into a clean mode and start bitcoind with the -flickerlimit switch. Then change your passphrase. You can change it to something longer, or even have the old and new passphrases be the same. Executing a passphrase change (re)initializes bcflick with the wallet encryption key and spending limit. This procedure is also useful when things go wrong and bcflick stops working. Boot into a clean state, run bitcoind with -flickerlimit, and change the passphrase from itself to itself.

Then you can boot into a regular mode, and bcflick will sign transactions, using the wallet encryption key to decrypt the signing keys. Bcflick will also create (encrypted) keys. This is so malware can't observe any decrypted keys. Any other operations requiring the wallet passphrase, such as spending in excess of the daily limit, should be done by booting into a clean mode and entering the passphrase. Under no circumstances should you enter your passphrase without booting into a clean mode. Otherwise, malware could learn it, and steal all your funds.

Because the passphrase is not needed for daily use, you can use a longer and more complex one. That, coupled with the infrequent use, means you should probably write it down and store it in a secure place.

I need to write more about the security model, both Flicker related and Bitcoin related. But in the mean time, here is a quick-start guide:



Experimental integration of Flicker with Bitcoin

Get a computer that supports Flicker

Set up the TPM:
Get TPM/J from http://projects.csail.mit.edu/tc/tpmj/
Enable the TPM in BIOS
Take ownership of the TPM with sudo java edu.mit.csail.tpmj.tools.TPMTakeOwnership <ownerpwd>
Create a counter with sudo java edu.mit.csail.tpmj.tools.TPMCreateCounter <ownerpwd> BITC

Get the master branch of flicker working, git clone git://git.code.sf.net/p/flickertcb/code
Get the master branch of bitcoin working, git clone git://github.com/bitcoin/bitcoin.git
Download the bitcoin block chain
If you have bitcoins, transfer them elsewhere and delete wallet.dat
Get the flicker branch, git clone http://github.com/halfinney/bitcoin/
Get the mytxtck branch, git clone git://git.code.sf.net/u/hal/flickertcb
Make a symbolic link called flicker in the bitcoin directory pointing to the flicker/examples/app directory
Run make in flicker/examples/{app,pal/libtommath,pal}
Copy flicker/examples/pal/bcflick.bin to ~/.bitcoin
Run make bitcoind in bitcoin/src
Run chmod 666 /sys/devices/system/cpu/cpu*/online /sys/kernel/flicker/* (you'll probably have to do this after every reboot)
Boot into a secure mode (eg. boot from a live CD)
Run bitcoind -flickerlimit=<limit> &  where limit is the maximum daily limit of bitcoins spent
Run bitcoind encryptwallet <passphrase>
Boot into a regular mode and flicker will limit the amount spent per day to the limit you have set, without requiring a passphrase
Now you can transfer your funds back, to new addresses in your wallet
If you want to spend more, boot into the secure mode and unlock the wallet with the passphrase

I made an order from BitcoinStore, a high end HP laptop for my research into strengthening Bitcoin wallets with Trusted Computing. It was about $1000. Unfortunately the site crashed for several hours just after I sent my bitcoins in but before I could complete the order. I contacted customer service after the site came up, and they were very helpful. They entered my order manually, and I got an email that the order had been received. I didn't get any further response, however. I waited a week and emailed cs again. They were very apologetic and assured me they'd take care of it. To my surprise, the next morning I got a delivery and it was the laptop! It's working great.

So the store has some growing pains but customer service will take care of you. My one disappointment was that the package came from MemoryDealers and not BitcoinStore. That would have been cool.

I was lucky enough to receive the first bitcoin transaction, and then I was careless enough to spend it accidentally. I probably still have the key sitting on a switched-off computer, so I could auction off the key. Usual caveats about making sure I delete it when I sell it...

I felt bad about losing that donation address, particularly after elux very generously donated a whole bitcoin. I found a wallet on a backup that had the key, and so I was able to retrieve the funds. Again, thanks very much!

Actually the OP observed that the software always puts the change first. I was working on a separate project suggested by Mike Hearn, using the new secure "trusted computing" modes on modern cpus to enforce spending limits even when infested with malware. I'm using Jon McCune's flicker software from sourceforge. The secure mode signs transactions and enforces limits on spends, but to know the transaction amount it has to know which is the change output.So I was just looking at this code yesterday and scratching my head (figuratively). I'll post more on this project when it's further along.

As far as my donation address, I created that years ago using Gavin's original vanitygen patch. I don't even know if I still have the key. It might be on a computer I don't use any more. I've substituted one of my offline savings wallet addresses. I shouldn't lose that.I'm not hurting for bitcoins; I started running the first day (and gave up after a few weeks because of the fan noise). Still, it's the thought that counts - thanks!

bitcoin-qt tries to randomize the position of the change output, but I believe the code has a flaw:

// Insert change txn at random position:
vector<CTxOut>::iterator position = wtxNew.vout.begin()+GetRandInt(wtxNew.vout.size());
wtxNew.vout.insert(position, CTxOut(nChange, scriptChange));

The problem is that size() is one in the common case of one payee, so GetRandInt will always return 0.The change ends up in the first output.

I think it should be size()+1.

Apologies for resurrecting this old thread, but I wanted to mention a new development. The people that brought you Flicker and TrustVisor, both mentioned by Mike, have a new project out. xmhf is a hypervisor framework built around Trusted Computing. Its main advantage is that it works on both Intel and AMD, but you still need a newer, relatively high-end machine. TrustVisor has been ported to xmhf, so now it works on both architectures whereas previously it was just AMD.

I agree with the comments above that TC may not be quite right for bitcoin. For one thing these secure program compartments can't do any I/O directly. They have to rely on the insecure code to relay data, although crypto keeps the data secure. So if we wanted the user to approve a transaction, you'd have to send the data to a secure device for approval. In which case you might as well use multisig or even just keep all the keys there.

You could try to implement a self-contained policy like rate limiting, although as discussed above you need a secure time source and state rollback protection. I'm worried that using the blockchain as a time standard might be vulnerable to timing games by the untrusted code, although there might be mitigations. A couple of other potential sources of secure time: the network time protocol, which is how a lot of computers keep their time in sync, has a crypto layer. Unfortunately it doesn't seem suitable for public use, although I found out the US NIST will supposedly supply you with an authenticated time if you go through a complicated application process, http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm.

Thinking way outside the box, you could open an SSL connection to a web page that's updated frequently, and use the Date: header from the http response. You'd hard code the CA root cert and all the relaying could be done by the untrusted code and still be secure. I've tried this with https://google.com and the time is pretty accurate. TrustVisor includes a version of openssl so this would seem to be feasible.

But even if you got rate-limiting working, the untrusted code could substitute its addresses for the target addresses, or maybe just skim a percentage off each transaction, hoping to evade detection. A lot of things have to go right for the created transaction to match the user's intentions. Assuming a malware takeover and still trying to protect the user is aiming too high IMO. Maybe we can limit the damage though.