There's so much like that. I'm going to try to write a blog post highlighting all the gems.

My favorite is:

    IMPLEMENT_SERIALIZE
    (
        READWRITE(prevout);
        READWRITE(scriptSig);
        READWRITE(nSequence);
    )

It's a C++ macro that implements reading and writing member variables to/from disk/network. It uses C++ templates to figure out the sizes of everything, so it winds up packing items efficiently. We used something similar in the gamedev industry, so this was a delightful surprise.

Ohh, no, I take it back. This is my favorite:

    //
    // Compact size
    //  size <  253        -- 1 byte
    //  size <= USHRT_MAX  -- 3 bytes  (253 + 2 bytes)
    //  size <= UINT_MAX   -- 5 bytes  (254 + 4 bytes)
    //  size >  UINT_MAX   -- 9 bytes  (255 + 8 bytes)
    //
    inline unsigned int GetSizeOfCompactSize(uint64 nSize)
    {
        if (nSize < UCHAR_MAX-2)     return sizeof(unsigned char);
        else if (nSize <= USHRT_MAX) return sizeof(unsigned char) + sizeof(unsigned short);
        else if (nSize <= UINT_MAX)  return sizeof(unsigned char) + sizeof(unsigned int);
        else                         return sizeof(unsigned char) + sizeof(uint64);
    }

When encoding an arbitrary value, if it's less than 253, it only uses 1 byte of space. When you read a byte off the network, if it's 253, you know there are two more bytes to read. 254 = 4 bytes, 255 = 8 bytes.

Again, it's a small thing -- very standard tactic. But there are dozens of tiny, effective decisions exactly like this all throughout the codebase.

There's a secure allocator for wiping your private key so that it doesn't hang out in memory, with hacks to work around MSVC8 problems. Which academics bother with MSVC8 hacks?

    //
    // Allocator that clears its contents before deletion
    //
    template<typename T>
    struct secure_allocator : public std::allocator<T>
    {
        // MSVC8 default copy constructor is broken
        typedef std::allocator<T> base;
        typedef typename base::size_type size_type;
        typedef typename base::difference_type  difference_type;
        typedef typename base::pointer pointer;
        typedef typename base::const_pointer const_pointer;
        typedef typename base::reference reference;
        typedef typename base::const_reference const_reference;
        typedef typename base::value_type value_type;
        secure_allocator() throw() {}
        secure_allocator(const secure_allocator& a) throw() : base(a) {}
        ~secure_allocator() throw() {}
        template<typename _Other> struct rebind
        { typedef secure_allocator<_Other> other; };

        void deallocate(T* p, std::size_t n)
        {
            if (p != NULL)
                memset(p, 0, sizeof(T) * n);
            allocator<T>::deallocate(p, n);
        }
    };

Another gem (note the comments):

   case OP_EQUAL:
   case OP_EQUALVERIFY:
   //case OP_NOTEQUAL: // use OP_NUMNOTEQUAL
   {
       // (x1 x2 - bool)
       if (stack.size() < 2)
           return false;
       valtype& vch1 = stacktop(-2);
       valtype& vch2 = stacktop(-1);
       bool fEqual = (vch1 == vch2);
       // OP_NOTEQUAL is disabled because it would be too easy to say
       // something like n != 1 and have some wiseguy pass in 1 with extra
       // zero bytes after it (numerically, 0x01 == 0x0001 == 0x000001)
       //if (opcode == OP_NOTEQUAL)
       //    fEqual = !fEqual;
       stack.pop_back();
       stack.pop_back();
       stack.push_back(fEqual ? vchTrue : vchFalse);
       if (opcode == OP_EQUALVERIFY)
       {
           if (fEqual)
               stack.pop_back();
           else
               pc = pend;
       }
   }
   break;

Bitcoin is worth N billion dollars right now, and this codebase really is a billion dollar codebase. Is this really the work of a single person?

Even people working on bitcoin aren't fans of base58. Variable length serialization? Bignums in the serializer? Poor error detection? No error correction? Confused characters in alphabet? Case sensitivity? Lots of reasons to dislike.