I see.  I was under the impression that the coloring algorithm in Meni Rosenfeld's paper "Overview of Colored Coins" was the one that's employed.  Thanks.

If I understand the coloring algorithm correctly, there has to be a global agreement as to what the colors are.  Otherwise if one party believed in yellow and another didn't (i.e., saw yellow coins as uncolored), they would disagree about how the colors propagated.  Do I have this right?

Is there a site that tracks the current size of the UTXO table?  I've been unable to find one.  Barring that, could someone give me a current figure?

Start with a string that's roughly what you want.  Base 58 decode it.  Delete the last 4 bytes, call the remaining bytes s.  Hash s twice with SHA-256.  The first four bytes of that are your checksum.  Append the checksum to s and base 58 encode it.

Mostly no. It takes roughly n hashes to build the Merkle tree for an n-transaction block, so a larger block takes slightly longer to prepare.  But it takes trillions of hashes to hit the required difficulty, so the contribution of the block size is negligible.

Actually, neither one is correct (even if you blur the distinction between a constant and the opcode that pushes it).  There are lots of representations of true, and -- since the script manipulates byte strings, not integers -- there are lots of representations of false as well.

Also, the way I read the code, OP_0 doesn't actually work, but I could be confused.  I'd like it if someone better familiar with the code than I could weigh in on that.

You use the XVERIFY instructions if you want to check more than one condition (eg, EQUAL and CHECKSIG) to avoid needing BOOLAND and annoying stack manipulation.  So XVERIFY all but the last condition.

I'm pretty sure the answer is no.

Keep in mind that the compressed and uncompressed public keys have different hashes, and thus result in different Bitcoin addresses.  You need the right one to unlock a Txout.

Received, thanks!

The infographic gives the hash of "The root of all evil" as 6d0a1899086a....  That is the beginning of
6d0a1899086ad3337062a61f7cb5ec3b8fe94e36a2d73ce26b7b06a8a2d389d2, the correct SHA-256 hash.  But Bitcoin always double-hashes, so it should have been 045bbb133c6739d2b298eee99cbe3bc40b959e47506587f0b1216b6769510bbb.

(To be really pedantic, Bitcoin reverses the hash before displaying it, resulting in bb0b5169676b21b1f0876550479e950bc43bbe9ce9ee98b2d239673c13bb5b04.)

Aside from the fact that coinbase is 25 now, not 50, this seems pretty accurate.  I guess there's also that the hash example uses only one round of SHA256, not two.

(12t5NM2Qnb496JMKSFafoHUCvgKqYaMJ8j if I win.)

This happens occasionally, it's called a soft fork.  (http://blockchain.info/orphaned-blocks) The history is defined by the longest chain, so whichever block the miners happen to build on is the winner.  Timestamps are not used.

It says here: https://bitcointalk.org/index.php?topic=15958.msg209292#msg209292

To become a node, as you put it, you would have to become a miner.  These days, that requires a significant outlay of capital and is not an economic strategy for recovering tiny transaction fees.

I think it is theoretically possible to get small transactions into blocks without paying fees, if you can get it to a miner who will accept it, but it can't be done easily or quickly.  It not worth the trouble to avoid a 5-cent transaction fee.