Bitcoin Forum
May 24, 2019, 06:22:34 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Bitcoin Discussion / Bitcoin and me (Hal Finney) on: March 19, 2013, 08:40:02 PM
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]
2  Bitcoin / Development & Technical Discussion / [ANN] bcflick - using TPM's and Trusted Computing to strengthen Bitcoin wallets on: March 17, 2013, 09:48:15 PM
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
3  Other / Off-topic / Shave and a haircut, two bitcoins on: June 06, 2011, 06:13:58 AM
Just noticed that we've reached "shave and a haircut" parity. The old secret knock is becoming true once again.
4  Bitcoin / Bitcoin Discussion / Bitcoin == terrorism? on: March 20, 2011, 06:52:34 PM
Here is the government press release on the Liberty Dollar case:

http://charlotte.fbi.gov/dojpressrel/pressrel11/ce031811.htm

Quote
“Attempts to undermine the legitimate currency of this country are simply a unique form of domestic terrorism,” U.S. Attorney Tompkins said in announcing the verdict. “While these forms of anti-government activities do not involve violence, they are every bit as insidious and represent a clear and present danger to the economic stability of this country,” she added. “We are determined to meet these threats through infiltration, disruption, and dismantling of organizations which seek to challenge the legitimacy of our democratic form of government.”

I worry that Bitcoin can be seen as even more of a threat to the supremacy of the dollar, which by this reasoning would make it terrorism. An extreme claim, to be sure, but apparently the U.S. Is willing to go there.

The government also advances this theory:

Quote
Article I, section 8, clause 5 of the United States Constitution delegates to Congress the power to coin money and to regulate the value thereof. This power was delegated to Congress in order to establish and preserve a uniform standard of value and to insure a singular monetary system for all purchases and debts in the United States, public and private. Along with the power to coin money, Congress has the concurrent power to restrain the circulation of money which is not issued under its own authority in order to protect and preserve the constitutional currency for the benefit of all citizens of the nation. It is a violation of federal law for individuals, such as von NotHaus, or organizations, such as NORFED, to create private coin or currency systems to compete with the official coinage and currency of the United States.

Now this is really stretching the truth. Until the Civil War era, there was no U.S. currency as such, rather paper money was issued, perfectly legally, by private banks. There is no Constitutional prohibition of private currency. There is a law that prohibits private metallic coins, 18 USC 486, which is what they used against LD. It's ominous to see the U.S. expanding its claims like this, to the point where they would cover Bitcoin.
5  Bitcoin / Bitcoin Discussion / Future Bitcoin security depends on price on: March 18, 2011, 09:00:41 PM
We know that Bitcoin's resistance to attack is based on the cost for the attacker to overwhelm the network, or at least to control a large fraction of its computing power. We assume this cost will continue to rise in the future so attacks will be infeasible even for well-funded attackers.

But the computational power of the network is proportional to difficulty; and it appears that difficulty is proportional to bitcoin price. It follows that unless bitcoins become substantially more valuable than they are today, the Bitcoin network will never be substantially more resistant to attack than it is today.

For Bitcoin to succeed and become secure, bitcoins must become vastly more expensive.
6  Bitcoin / Development & Technical Discussion / The first rule of Bitcoin is... on: March 16, 2011, 11:17:33 PM
Follow the rules!

I've put up a wiki page listing the rules used by the client to process transactions and blocks. It's a bit linear and could benefit from some refactoring, but I didn't want to go too far in terms of pseudocode, because IMO it obscures the logic.

https://en.bitcoin.it/wiki/Protocol_rules
7  Bitcoin / Bitcoin Discussion / Difficulty to remain constant for the next month on: March 10, 2011, 06:48:05 PM
Newbie chodpaba has discovered a strong correlation between lagged btc price and difficulty: http://bitcointalk.org/index.php?topic=4339.0. It predicts that difficulty should stay level or decrease slightly for the next month. We'll see!
8  Bitcoin / Development & Technical Discussion / dPriority and free transactions on: March 05, 2011, 07:14:52 AM
CreateNewBlock() has this code:
Code:
3368         uint64 nBlockSize = 1000;
3369         int nBlockSigOps = 100;
3370         while (!mapPriority.empty())
3371         {
3372             // Take highest priority transaction off priority queue
3373             double dPriority = -(*mapPriority.begin()).first;
3374             CTransaction& tx = *(*mapPriority.begin()).second;
3375             mapPriority.erase(mapPriority.begin());
3376
3377             // Size limits
3378             unsigned int nTxSize = ::GetSerializeSize(tx, SER_NETWORK);
3379             if (nBlockSize + nTxSize >= MAX_BLOCK_SIZE_GEN)
3380                 continue;
3381             int nTxSigOps = tx.GetSigOpCount();
3382             if (nBlockSigOps + nTxSigOps >= MAX_BLOCK_SIGOPS)
3383                 continue;
3384
3385             // Transaction fee required depends on block size
3386             bool fAllowFree = (nBlockSize + nTxSize < 4000 || dPriority > COIN * 144 / 250);
3387             int64 nMinFee = tx.GetMinFee(nBlockSize, fAllowFree);
The last couple of lines here relate to one of the free-transaction rules: if the size counting the new tx is < 4000 then it is eligible to pay no tx fee.

I wanted to point out the first line, which initializes nBlockSize to 1000. It means there is only 3000 bytes reserved for free transactions, not 4K as often stated.

dPriority for a tx is calculated as sum over all input transactions of the input value times its depth, divided by tx size in bytes. This is compared above with 144/250, in units of bitcoins. 250 is about the size of a simple transaction, so to be eligible for no tx fees beyond the 3000 bytes area, the average depth of the inputs times the tx value must be > 144 btc (more for complex transactions with many inputs). If so, the GetMinFee() function allows up to 27K of space.

A special case is transactions with input(s) not in blocks. These don't contribute to priority, as though depth==0. If all the inputs are not in blocks, then dPriority will be zero, and the tx can go into the block only if its predecessors have got into the block.

If someone sends out a bunch of transactions quickly, such that each one depends on the one before, then all but possibly the first will have dPriority zero. With no tx fees, only about 12 can get into the 3K free area. If there are other transactions around, there will be room for fewer.

I do see a pattern of blocks about 3.1K in size with about 12 transaction. Also there have been reports of chains of transactions, each dependent on the previous, getting into consecutive blocks, one per block. This might be because with each new block, (only) the next tx in the chain gets nonzero dPriority.
9  Bitcoin / Development & Technical Discussion / Prize for importing private key [WON] on: February 19, 2011, 10:36:49 PM
This is a base58 encoded plain private key (256 bit value from a "key" entry in my wallet) worth 20 BTC. We're now at block 109180. Let's see how long it takes for someone to input the key and collect the bitcoins.

2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy

ETA: this is wrong, the correct value is later in the thread
10  Other / Off-topic / FreedomBox on: February 16, 2011, 09:12:24 PM
Article in the NY Times today about FreedomBox, Eben Moglen's project to get everybody running private servers on plug computers. Seems like a natural fit for Bitcoin. Not mining obviously, but could hold a wallet accessible from your mobile. Also another good target for Bitcoin donations.

Quote
On Tuesday afternoon, as Secretary of State Hillary Rodham Clinton spoke in Washington about the Internet and human liberty, a Columbia law professor in Manhattan, Eben Moglen, was putting together a shopping list to rebuild the Internet — this time, without governments and big companies able to watch every twitch of our fingers.

The list begins with “cheap, small, low-power plug servers,” Mr. Moglen said. “A small device the size of a cellphone charger, running on a low-power chip. You plug it into the wall and forget about it.”

Almost anyone could have one of these tiny servers, which are now produced for limited purposes but could be adapted to a full range of Internet applications, he said.

“They will get very cheap, very quick,” Mr. Moglen said. “They’re $99; they will go to $69. Once everyone is getting them, they will cost $29.”

The missing ingredients are software packages, which are available at no cost but have to be made easy to use. “You would have a whole system with privacy and security built in for the civil world we are living in,” he said. “It stores everything you care about.”

Put free software into the little plug server in the wall, and you would have a Freedom Box that would decentralize information and power, Mr. Moglen said. This month, he created the Freedom Box Foundation to organize the software.

“We have to aim our engineering more directly at politics now,” he said. “What has happened in Egypt is enormously inspiring, but the Egyptian state was late to the attempt to control the Net and not ready to be as remorseless as it could have been.”

Not many law professors have Mr. Moglen’s credentials as lawyer and geek, or, for that matter, his record as an early advocate for what looked like very long shots.

Growing up on the West Side of Manhattan, he began fooling around with computers as a boy. In 1973, at age 14, he was employed writing programs for the Scientific Time Sharing Corporation. At 26, he was a young lawyer, clerking for Justice Thurgood Marshall. Later, he got a Ph.D. in history from Yale. He was also the lawyer for the Free Software Foundation, headed by Richard M. Stallman, which aggressively — and successfully — protected the ability of computer scientists, hackers and hobbyists to build software that was not tied up by copyright, licensing and patents.

In the first days of the personal computer era, many scoffed at the idea that free software could have an important place in the modern world. Today, it is the digital genome for millions of phones, printers, cameras, MP3 players, televisions, the Pentagon, the New York Stock Exchange and the computers that underpin Google’s empire.

This month, Mr. Moglen, who now runs the Software Freedom Law Center, spoke to a convention of 2,000 free-software programmers in Brussels, urging them to get to work on the Freedom Box.

Social networking has changed the balance of political power, he said, “but everything we know about technology tells us that the current forms of social network communication, despite their enormous current value for politics, are also intensely dangerous to use. They are too centralized; they are too vulnerable to state retaliation and control.”

In January, investors were said to have put a value of about $50 billion on Facebook, the social network founded by Mark Zuckerberg. If revolutions for freedom rest on the shoulders of Facebook, Mr. Moglen said, the revolutionaries will have to count on individuals who have huge stakes in keeping the powerful happy.

“It is not hard, when everybody is just in one big database controlled by Mr. Zuckerberg, to decapitate a revolution by sending an order to Mr. Zuckerberg that he cannot afford to refuse,” Mr. Moglen said.

By contrast, with tens of thousands of individual encrypted servers, there would be no one place where a repressive government could find out who was publishing or reading “subversive” material.

In response to Mr. Moglen’s call for help, a group of developers working in a free operating system called Debian have started to organize Freedom Box software. Four students from New York University who heard a talk by Mr. Moglen last year have been building a decentralized social network called Diaspora.

Mr. Moglen said that if he could raise “slightly north of $500,000,” Freedom Box 1.0 would be ready in one year.

“We should make this far better for the people trying to make change than for the people trying to make oppression,” Mr. Moglen said. “Being connected works."

11  Bitcoin / Development & Technical Discussion / Payment to yourself on: February 13, 2011, 09:30:06 PM
I did "Copy to Clipboard" of my Bitcoin address and then hit Pay, paid myself 20 btc. Is this supposed to work?

It sort of worked and sort of didn't. The transaction displays as "Payment to yourself" with Debit -20.00 and Credit +20.00. But Status is stuck at "0/offline?". I'm online and I've never had a problem sending a transaction before.
12  Bitcoin / Development & Technical Discussion / Displaying bitcoins in wallet on: February 10, 2011, 12:43:33 AM
I have enhanced the bc_key program to print interesting information about transactions found in the wallet file.

https://github.com/halfinney/bc_key

Run it as:

Code:
./bc_key EVERYTHING ~/.bitcoin/wallet.dat

(substitute your own wallet.dat location on mac and windows)

This dumps everything in the wallet, including keys and address book, but let's just look at transactions:

Code:
./bc_key EVERYTHING ~/.bitcoin/wallet.dat | grep ^tx

I'll go ahead and violate my own privacy because I want to make a point. Here's my output:

Code:
tx 011104eddf3afd4e1133996e3e2a9c7f16ed1f9dfa922493612bab9b8be19f0e    1.50000000 12gHtU8z4HNymJUBetcyY2MU8CYYfszq5X 2011/01/22 spent
tx 5fa35fa2e753c8997aaca3b1cb434f218884d95ae8803a0ee7ff8eee298ba00f    3.00000000 1BPE6sLdYn8zoRH2ovEWiqQH4NRbyAAHNK 2011/01/22 change spent
tx cff5962c80af06506d6583710fdbde01b95e0bf4a37df27af82ee5038b241016    9.00000000 1NiihskVid2GTWEJjKDaft67aFkeCJTTaE 2011/02/06 change
tx 31989da39c18a351fb393b05d7d66efd69cf1cc64958d67a5c49189e28402b1f    0.50000000 157a7eFdnTg89gPZ5wWPjX1TMVL3ffeDSh 2011/01/28 change
tx a5a88c6af09b9bcd21a7ee0e0c25ce912a0ccabd90a5a6d8a5644c7b6c519321    6.00000000 payment                            2011/01/30 spent
tx b6f4b9239544d864d5fbbfce5bc6d6333227e2b6db8aa0d35beba3bcf12b212d   12.00000000 1513Z4iDpW1K3qyknHUhwxhXy6H5aYd6q6 2011/01/30 spent
tx 061ef85f7936b138675e5c6b01c67ddbb8710aa9c00dffdd1859e2e0b231ce47    3.00000000 payment                            2011/02/01 spent
tx 835d37f77fc980efa21771e3fefbd79d9a20f2f69d3d0517d99f86aeecae464a  997.00000000 1F4YL3tYS1Y4dEvCUppwMjggi2imgJogVW 2011/01/20 change spent
tx 3ed3602d07e3f16f90f4966c502e5fcccb7e13faacc0053e9558e91a93a9a24f    3.00000000 1J6ToHCuN6jeniL7wD2zJwxhRUv2V6TLXW 2011/01/30 change spent
tx 78537330713ec5c92befd3e1a91c754198ee14877c02d8888c899280d0a49c58  994.00000000 1K8THF4Qkr5mMKjQRJe1xW33ZYoUrgtUHL 2011/01/20 change
tx 82621223fccb83122edda411f941c729929507a21bed320d1a9af6caa12dc159 1000.00000000 1KeWUnmZZUNDSeWKf9pqZmMdtkeJ5jENnX 2011/01/02 spent
tx 5fd3fed9bef47df2c95255b863bf989b027121bfcedd692d08888ba704130c7a    5.00000000 19MvB9acQ4wx4GtGxBwTamMkfHPVSBWY3Z 2011/01/22 change spent
tx 9555b4b8e84e6e5b045847fe86d6bb82df67e4360a897b485dbd8a76e0b46b83   10.00000000 1NC55QPMZqtpRNiRvkBatNvZLrXT5XqnRR 2011/02/03 change spent
tx 3a3b74721cc6af482bcc8b6722f80a87a9de103ee26a67975a2eee69328a3b92    6.00000000 1513Z4iDpW1K3qyknHUhwxhXy6H5aYd6q6 2011/01/20 spent
tx 4c9bb949f106cfe6bed53415e7dcb86f5c93603434c65ca6423d5de1eabafa92    1.25000000 12gHtU8z4HNymJUBetcyY2MU8CYYfszq5X 2011/01/22 spent
tx 03f87b3c1ed4231e64a781ce2f8c10c03e7a3f6439389c97af640e1e63eb29b0    0.25000000 1LKRbsyxiSi3zfHKyumEH8W7fSQapapnnw 2011/01/28 change
tx a97511426aac9be884236578060293a1b6783d4c7467288bf89436bfc38feec9    3.00000000 payment                            2011/01/30 spent
tx 230fec2b39bc56ef359a5c078505b8aac0d8221c5109dd0fa8f98ddd667ab8d3   18.87000000 12BxP2C6aj2KT5fsnNdiyVMKfhm9tu1MK4 2011/02/01
tx 7b8cb378bc8f15e98a8f94c2c20a8e552b6dd785f3863c1baac314e8b8d56ada    6.00000000 1513Z4iDpW1K3qyknHUhwxhXy6H5aYd6q6 2011/01/30 spent
tx ca43a17aa52c670e96c77a752552d502016355e2c7018ed4c930215e8366a9da    6.00000000 1513Z4iDpW1K3qyknHUhwxhXy6H5aYd6q6 2011/01/20 spent

The big number is the transaction ID, suitable for plugging into blockexplorer.com. Next is the bitcoin amount, your address that received the bitcoins, and the date of the transaction. Finally come the optional words change and spent. Change means this transaction produced change as a side effect of a payment you made to others, and the address shown is the change address, which is largely hidden in the client UI. Spent means that the bitcoin(s) associated with this transaction have been spent and are no longer available.

There are basically three types of wallet transactions. First are payments from someone else to a wallet key. Next are payments to others which happen to exactly use up one or more available transactions, with nothing left over. These are shown as "payment" in the address field and are always marked as spent. Last are payments where there were bitcoins left over, which get returned to a new address. These are the ones which are shown as change.

To see the transactions which are available for spending, filter out the spent ones with grep -v:

Code:
./bc_key EVERYTHING ~/.bitcoin/wallet.dat | grep ^tx | grep -v spent\$


Code:
tx cff5962c80af06506d6583710fdbde01b95e0bf4a37df27af82ee5038b241016    9.00000000 1NiihskVid2GTWEJjKDaft67aFkeCJTTaE 2011/02/06 change
tx 31989da39c18a351fb393b05d7d66efd69cf1cc64958d67a5c49189e28402b1f    0.50000000 157a7eFdnTg89gPZ5wWPjX1TMVL3ffeDSh 2011/01/28 change
tx 78537330713ec5c92befd3e1a91c754198ee14877c02d8888c899280d0a49c58  994.00000000 1K8THF4Qkr5mMKjQRJe1xW33ZYoUrgtUHL 2011/01/20 change
tx 03f87b3c1ed4231e64a781ce2f8c10c03e7a3f6439389c97af640e1e63eb29b0    0.25000000 1LKRbsyxiSi3zfHKyumEH8W7fSQapapnnw 2011/01/28 change
tx 230fec2b39bc56ef359a5c078505b8aac0d8221c5109dd0fa8f98ddd667ab8d3   18.87000000 12BxP2C6aj2KT5fsnNdiyVMKfhm9tu1MK4 2011/02/01

These are really my "bitcoins". They are what I have available to spend. The sum of the bitcoin amounts should equal my wallet balance. Any spend I make will come from one or more of these transactions. Generally, the Bitcoin client will try to combine one or more small transactions to make a payment, otherwise it will use the smallest single transaction capable of funding the payment.

Although my wallet doesn't show it too clearly, it's not unusual for a single Bitcoin address to be funded by multiple transactions. But for making payments, this is basically irrelevant. Individual transactions are picked to fund payments without regard to whether some of them happen to use the same address.
13  Bitcoin / Development & Technical Discussion / Speeding up signature verification on: February 07, 2011, 10:31:27 PM
In another thread, [mike] wrote:

I don't know of any algorithms that will make ECDSA much faster using GPUs. The best bet for speeding this up (assuming we care) is to exploit the special properties of the secp256k1 curve:

http://portal.acm.org/citation.cfm?id=1514739

http://www.hyperelliptic.org/tanja/KoblitzC.html

I'm trying to inplement the secp256k1 shortcut. Should have results shortly. Unfortunately I only expect about 20% speedup. We'll see.

I'm also looking at batch signature verification:

http://cseweb.ucsd.edu/~mihir/papers/batch.pdf

http://www.math.snu.ac.kr/~jhcheon/publications/2007/BatchVer_PKC2007_CL.pdf

This can theoretically speed up verification by almost a factor of 4 (table 6 in 2nd paper) if you have a lot of signatures in a batch. It requires a slight change in the ECDSA signature format: (r, s) is replaced by (R, s), where R is the EC point of which r is the x coordinate. This change could be applied retroactively, as R is calculated and discarded every time the sig is verified.

We do tend to have sigs in batches, namely blocks; sometimes several dozen or even hundreds, and this will grow. Batch verification returns true iff all sigs are valid. A good block should never have invalid signatures so it makes sense to batch the verify.

I need to research some security aspects, namely: does R need to be checked to see if it's on the curve (ie y^2 = x^3 + 7)? And what is an appropriate security parameter for the probability the batch verify test could be fooled? The papers talk about 2^80 but that seems too conservative.
14  Bitcoin / Development & Technical Discussion / What if you spend after receiving a double spend? on: January 28, 2011, 09:41:15 PM
Suppose you receive a payment and then immediately spend it. Then there is a block reorganization and the payment to you goes away. It never comes back because it was a double spend. Can the client handle this? How would it appear in the transaction window?
15  Bitcoin / Bitcoin Discussion / Clusters of transactions on the hour on: January 28, 2011, 05:33:14 AM
I listen to the network (via http://bitcointalk.org/index.php?topic=2808.0), and while transactions generally come pretty randomly, there is occasionally a cluster of a dozen or so transactions, coming very quickly, within a second or two. It took me a while to realize that when these happen, it is always the top of the hour. I don't notice them every hour, but several times a day, always on the hour.

Looking at blockexplorer, it looks like these are a series of small payments, a few cents or a few bitcoins, generally from high value transactions near 50 btc. And they each normally have a 0.01 btc transaction fee.

An interesting pattern...
16  Bitcoin / Development & Technical Discussion / Mobile client design ideas on: January 28, 2011, 12:55:23 AM
Several people have mentioned they are working on mobile clients (at least Android, don't know about iOS). But I haven't seen much discussion of the design in terms of security and performance issues.

In another thread, http://bitcointalk.org/index.php?topic=2957.msg41905#msg41905, [mike] made a provocative comment: "1) Are you trying to make an Android client? You don't want to verify transactions if so."

Can mobile clients get away without verifying transactions? Maybe they could just rely on the block chain. Any transaction in a block that has enough confirmations is considered to be good. Checking blocks is both easy and quick, pretty much just hashing.

The one problem I see would be a possible delay in knowing that payments to you are valid. It wouldn't matter for payments to merchants who can run regular clients, but payments from one mobile user to another might be slow to be validated.

Another possible shortcut would be for mobile clients not to forward blocks, transactions, and addresses the way regular clients do. Network transmissions draw a lot of power. Mobile nodes could just leech. If they don't process transactions, they wouldn't even need to read those.

iOS doesn't have true multitasking. I don't think a client could receive the block chain in the background. Android presumably doesn't have this problem, but the question would be impact on battery life to keep the client running all the time.
17  Bitcoin / Development & Technical Discussion / Reducing block time variability on: January 25, 2011, 07:11:52 AM
Bitcoin aims to produce blocks every ten minutes. But the actual time between blocks is quite variable, being governed by the Poisson distribution. I listen to block formation, and this variability is apparent. It's not unusual for blocks to be formed just a few seconds apart, while sometimes an hour goes by without one.

This variability is intrinsic to the hash solutions used by Bitcoin, and will not change even as the network grows. It may be a problem particularly for transactions that want a single confirmation. An application where a ten minute delay is acceptable might be in trouble if the delay becomes an hour.

A way to reduce the variability while maintaining the average solution time is to split the hash problem up into several sub-problems. Instead of solving a hash puzzle with difficulty 16,000, solve 4 puzzles with difficulty 4,000. The total difficulty and average time to find a solution is the same, but the variability is much less. Splitting into even more sub-problems will further reduce variability.

A downside to reducing variability is that we would have more block collisions, where more than one node solved the same block at about the same time. This would reduce the efficiency of the network, as nodes work on blocks doomed to be superseded, and blocks get reshuffled in and out of the longest chain. Also, it would give more advantage to the fastest node; in the extreme, if we eliminated all variability, it would win every time.

So we wouldn't want to go too far with this. But splitting into a modest number of sub-problems could substantially reduce the odds of hour+ inter-block intervals, hopefully without causing too many problems.
18  Bitcoin / Development & Technical Discussion / What has it got in its walletses? on: January 24, 2011, 11:44:45 PM
I modified the bc_key program originally by dirtyfilthy, to dump out info on everything in the wallet.dat file.

https://github.com/halfinney/bc_key

It prints out keys (as addresses), transaction hashes, key pool addresses, address book names, etc.

Run it as:

./bc_key EVERYTHING ~/.bitcoin/wallet.dat

or wherever your wallet.dat might be. I like to pipe the output through sort.

I've noticed two oddities in the couple of wallets I've looked at:

There are no wkey entries, only keys. wkeys would hold extra stuff with Merkle branches and all that. Is this not yet (or no longer) supported, present in the code for the hypothetical "lightweight client"?

I have a very old wallet, created by the first version of bitcoin. Recently I upgraded to a modern version. However, the wallet has no pool entries. I thought the upgrade would create 100 keypool entries?
19  Bitcoin / Development & Technical Discussion / Shy client patch on: January 22, 2011, 08:26:13 PM
I made a patch to make the client "shy". On incoming connections, it won't send a version message until it receives one. This can help make port scanning identification harder.

Code:
diff --git a/main.cpp b/main.cpp
index b7dfd9f..cb4fad6 100644
--- a/main.cpp
+++ b/main.cpp
@@ -2290,6 +2290,10 @@ bool ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv)
             return true;
         }
 
+        // Be shy and don't send version until we hear
+        if (pfrom->fInbound)
+            pfrom->PushVersion();
+
         pfrom->fClient = !(pfrom->nServices & NODE_NETWORK);
 
         AddTimeData(pfrom->addr.ip, nTime);
diff --git a/net.h b/net.h
index f070816..12e415b 100644
--- a/net.h
+++ b/net.h
@@ -571,14 +571,9 @@ public:
         fGetAddr = false;
         vfSubscribe.assign(256, false);
 
-        // Push a version message
-        /// when NTP implemented, change to just nTime = GetAdjustedTime()
-        int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());
-        CAddress addrYou = (fUseProxy ? CAddress("0.0.0.0") : addr);
-        CAddress addrMe = (fUseProxy ? CAddress("0.0.0.0") : addrLocalHost);
-        RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));
-        PushMessage("version", VERSION, nLocalServices, nTime, addrYou, addrMe,
-                    nLocalHostNonce, string(pszSubVer), nBestHeight);
+        // Be shy and don't send version until we hear
+        if (!fInbound)
+            PushVersion();
     }
 
     ~CNode()
@@ -735,6 +730,19 @@ public:
 
 
 
+    void PushVersion()
+    {
+        /// when NTP implemented, change to just nTime = GetAdjustedTime()
+        int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());
+        CAddress addrYou = (fUseProxy ? CAddress("0.0.0.0") : addr);
+        CAddress addrMe = (fUseProxy ? CAddress("0.0.0.0") : addrLocalHost);
+        RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));
+        PushMessage("version", VERSION, nLocalServices, nTime, addrYou, addrMe,
+                nLocalHostNonce, string(pszSubVer), nBestHeight);
+    }
+
+
+
 
     void PushMessage(const char* pszCommand)
     {

I noticed that the variable nLocalHostNonce is being used to detect connecting to ourself. But I'm not sure it is working, because we will (re-)randomize nLocalHostNonce on incoming connection before we compare with incoming version message. So even if we are connecting to ourself, nLocalHostNonce won't match. The shy patch should fix this.
20  Economy / Economics / Efficient Market Hypothesis on: January 21, 2011, 12:57:00 AM
The EMH says that market prices are approximately "correct" and you can't expect large gains. Yet many Bitcoiners expect large increases in the price of bitcoins. Is the EMH failing in the Bitcoin market, giving us a true free lunch? Or are Bitcoin investors deluding themselves by not recognizing the likelihood of loss?
Pages: [1] 2 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!