First, you pray.  Then you pull 256 bits at random from the entropy source that you just prayed to.  These 256 bits are your private key.  You check that the private key is not in excess of the modulus of the field, which would make it insecure, if it is, you start over.  Otherwise, the private key gets encrypted (you have encryption enabled, right?) and stored in your wallet.  Then, an operation called EC point multiplication is done using that private key and a well known constant.  The result of that multiplication is a pair of 256 bit numbers (x and y), the pair together known as the public key.*  The public key is put into a special representational form and stored in the wallet.  Finally, the pubkey representation is hashed, and then hashed again.  The second hash is then encoded with a checksum (more hashes!), and the result is an address.

* side note, the y-coordinate can be reconstructed, so it isn't needed, and can be discarded, but we have to store 2 different flags.  This changes the representation, and thus the hash, meaning that a private key can have two different addresses.  One flag is a marker along with the private key, telling the software which of the two possible addresses to use, and the other flag is a parity indication, coded into the public key representation to resolve the ambiguity of the quadratic used to reconstruct y.

Heh.  Forking is easy.  Just change anything important, and you will no longer be compatible with bitcoin.

If you want to be sure right from the beginning, just throw out the checkpoints and change the genesis hash.

Each block has a target.  The target is the largest possible hash value that is considered valid for that block.  In work terms, it takes about (uint256_max-target) hashes to create that block.

Note that this is calculated based on the acceptable hash values that the block could have had, not the actual hash value.

Each block has a prevHash field in the header that tells what block it is building on.  Each block can only have one parent, but it can have many children.  Consider all of the blocks in a tree structure, leading up to the genesis block at the root of the tree.  That block is actually special, because it doesn't point to another block.  (Instead, it points to a newspaper headline.)

For each leaf node in the tree, calculate the sum of the work values (target inverse) for each block starting from the leaf and going to the genesis block.  The highest sum you get is the longest path through the tree, and that is the "best chain value", and the chain that corresponds to that is the best chain.

Note that there may be two paths (rarely more than two) with equal value.  In that case, the one you saw first is your best chain.  The ambiguity will be resolved shortly, as one chain or the other will grow faster.

In the log messages, new best is the start of the hash of the block that it considers to be the head of the best chain, height is the length of the path through the tree, and work is the sum of the work embedded in that path.

Yes, unconfirmed transactions are stored in a memory pool.  And yes, when a transaction ends up in a block, it is removed from the memory pool.  The block contains the transactions, so in a sense, relaying the block relays the transactions, but they aren't sent as transactions any more.

If the block is orphaned, the transactions in it will be added to the memory pool , and then the new chain will remove some fraction of them right back out.  I'm actually not sure if the node will then try to relay the transactions it has in memory.  It doesn't matter in the long run though, because each node checks its own wallet, and will try now and then to resend anything that it thinks it has spent, but hasn't seen yet in a block.  So, the sender is ultimately responsible for getting their stuff out, and if any other nodes help, that is nice, but not necessary.  If a node goes offline, eventually their stuff will expire.

The actual code may optimize things a bit by building intermediate sets or whatever, but you have the net effect right.  Any transactions that were valid before the reorg and are still valid after the reorg, but were not included in the new blocks, will still be valid, and should end up in the memory pool.  But it turns out that it would be just as valid to throw them away, because the original node will resend them.

move does not involve the network at all, it just creates entries in the internal ledger.  As such, they are not subject to rollback.

This could be troublesome for you if you are using move in response to unconfirmed, or barely-confirmed, transactions.  But it should be fine to use it for your own transactions.

Example.  I get a bunch of small payments from p2pool, but want to de-clutter my wallet.  So, I use the raw API to gather a bunch of them up and send them back to their own address.  But I use an account to keep track of my p2pool earnings, and now the system thinks I've just been paid again, so I use move to reduce my p2pool account by the same amount as the transaction that I just sent myself.  This is safe because I know that I'm not going to double spend against myself.

Regression is useful when you are trying to understand how we got from barter with useful objects to where we are today.

Now that we are here, it hardly seems necessary to theorize on why we would want to switch from less useful monopoly money to more useful monopoly money.

When weaknesses like that are found, the world generally takes it as a warning sign.  It means that future weaknesses are very likely to be coming, and worse.  In that scenario, everyone would have a strong incentive to change.  But we'd also have lots of time to do it.

Look at MD4.  It is considered to be totally broken, and should not be used for anything, ever.  But really, none of the attacks on MD4 are even remotely useful for mining.  If we were using MD4 for mining, we would have years, probably decades really, to engineer a switch.

And a switch can be relatively painless.  As an example, we could all agree that ~2 years is plenty of time for everyone to upgrade their software, and ~4 years is enough to upgrade hardware.  That would mean that starting with block 3,150,000 the network would accept blocks with valid hashes under either SHA or the new algorithm, whatever we decide that may be.  And starting with block 4,200,000 the network would stop accepting blocks with SHA.

The account balance stuff is really just a sum of individual entries.  If the node reorganizes its chain, it rolls back everything in the removed fork, and then applies whatever it finds in the new fork.  This happens pretty often actually, but has no net effect, because for the most part, the two branches involved are very similar.  In a double spend, one of the removed parts will not be found in the new branch, and will not come back.

In short, the numbers are always correct relative to the node's current idea of what the "best chain" is.  And yes, it has been tested extensively, both on the testnet, and in reality.

The actual signature prep stage is complicated, but basically with SIGHASH_ALL alone, you can't change any important part of the transaction without invalidating the signature.  You can neither add, nor remove, nor reorder the inputs.  Ditto with the outputs.

Keep in mind that the hash flags are a property of the signature, not properties of the transaction.

Anyone can claim to own the address. 

But if you really have the private key for it, only you can spend coins sent to it, and only you can sign messages using that key.  Those are really the same thing.  A bitcoin transaction is really just a special message to be signed.

Yes.  The important thing is knowing the private key.  The way the client works internally isn't so important, but basically those coins are yours as soon as the transactions is confirmed.  When your client gets back online and catches up on the block chain, then it will update the balance that it shows you.

Oh, probably.  I didn't check my notes on the process, I just happened to have the file with the curve constants open.  It doesn't change anything fundamental either way.  And no one is reading this thread for a tutorial on how to create addresses, they already know to look elsewhere.


For the next 50 or 100 years or whatever, the issue is going to be engineering more than physics.

The Schneier quote is here if you want to read it.  The problem really is in the 2¹⁶⁰.  A Dyson sphere around the sun for a year is plenty to iterate 2¹⁶⁰, because 160 is puny compared to 256.  In physics terms, I'm not sure how many operations are required for the other parts of finding an address.  At the limits, the resources in our solar system appear to be capable of breaking 160 bit systems, but we are far, far from approaching those limits.  Maybe our grandchildren, or great-grandchildren will ask us some day if saving 16 bytes was worth it.  But I'm not worried about it tonight.

This is different.

Start with a 256 bit counter, set to any number you like.  On the secp256k1 curve, do an EC multiply of the value in the counter by the point at (0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8).  Now hash that result in RIPE-MD160.  If you got 0x759d6677091e973b9e9d99f19c68fbf43e3f05f9 as the result, you found the pubkey for the bitcoin eater address.  If not, increment the counter and try again.

Do that 2¹⁶⁰ times, and you have a decent chance* at finding it.  And every other address.

Of course, the entire bitcoin network has done less than 2⁷⁰ hashes since it started.  We can't expect to do much better than ol' Gordy predicted so long ago, but figure we double the amount of work done in each year.  That means one bit per year, which means 90 years between today and 2¹⁶⁰.

Except that EC multiplication is harder than hashing.  And that we are very unlikely to beat Moore's law in the long run.

Still, the 160 bit hash is by far the weakest link in bitcoin, by a factor of 2⁹⁶ and I suspect that they will gradually fade from favor over the next 50-100 years.

* Only a chance.  We don't have know that the output of RIPE-MD160 is evenly distributed.  It is possible that there is no input that gives that output, and more likely, it is possible that no bitcoin pubkey gives that output.

Starting on slide 7, he goes into the steps needed to make bitcoin.  He moves from a centrally issued ledger system into cryptographic currency, and then into decentralization.  After that, he covers the block chain.

He very clearly groks bitcoin and the history of electronic and cryptographic currency systems, enough so that I wish there was a video.  If he's even a halfway decent speaker, the presentation that goes with these slides is probably excellent.

Ahh, here it is:  http://vimeo.com/27177893.  I haven't watched it yet, going to now.

Excellent slide show, covers a lot of important stuff.

Ugh.  Linus is benevolent dictator for life of the project that bears his name.  However, if anyone doesn't like his decisions, they can fork.

In bitcoin, the situation is totally opposite.  If anyone wanted to make a big change, they would be the fork, and they'd have to convince all of us to switch.  Bitcoin is decentralized in the sense that no one has the capacity to make big decisions for the network.

Dude.  That is NOT how a magnetron works.  Magnetrons are oscillators, not accelerators.  And the frequency is controlled by the geometry of the resonant cavities, not the voltage.  If you increase the gate voltage, you might kill yourself, but you won't get x-rays.

Shut up before someone gets hurt.

Because spending free money is addictive.  If you could get fame, power and women by spending other people's money, would you stop doing it?

No, the conditional probability that a node was the origin of a transaction given that you first saw it from that node is rather small, even when you have a large number of connections.

I've checked the transactions first seen by blockchain.info from my personal node, and virtually none of the transactions that you first received from me are actually from me.

As an aside, this attack wouldn't find my wallet anyway because I run multiple nodes, and the one node that talks to the outside world has an empty wallet.

I made the mistake of reading some old financial statements this week.  I guess from now on, I'll just have to make copies of them.  I thought about paying a buck for 1000 credits, but I can't find any mention anywhere of how many credits each article costs.