Wow, I didn't expect to see my old thread when I browsed this forum today. To be honest, I took a pretty long break from bitcoin, and only recently began thinking about it and reading the code again. In fact, Sunday was the first day I even ran the client! That being said, allow me to do my best to summarize most ideas shared in this thread.

Keep in mind that this thread was not just about ideas that could potentially make it to a future bitcoin release, but ideas that could be used in an entirely new protocol. Everyone will benefit from competition in the cryptocurrency market.

1. Data Serialization: Vladimir suggests using BERT/YAML for binary and text serialization, and comboy suggests JSON for the latter.

(I'm putting this first because even though it's on page 2, I believe it's the biggest flaw in the current Bitcoin protocol, and a reason for many other problems listed here. Bitcoin is largely a binary-encoded protocol, so the composition of packets are set in stone. A more fungible serialization format like the aforementioned ones (or better yet, protocol buffers!) would allow the addition of new fields that older clients could safely ignore. All this talk about client versions, encryption algorithms, timestamp lengths, and more, would be much less of a worry, so I'll include them as 1a through 1d.)

1a. Client Handshakes: Cdecker and realnowhereman suggest making it possible to specify the client verson separately from the protocol version. grondilu suggests allowing a client to specify what algorithm they use for their key. realnowhereman also suggests flags to say whether a node is a generator, whether it accepts transactions, etc.

1b. Integer Lengths: realnowhereman suggests cleaning up the arbitrary use of 64-bit and 32-bit integer lengths; for example, having timestamps be 64-bit consistently.

1c. Hostnames: just_someguy suggests supporting host names alongside IP addresses.

1d. Transaction Scripts: realnowhereman and alkor suggest getting rid of the complexity of the custom scripting language, and implementing a simpler system.

2. Byte Order: error, Cdecker, and realnowhereman suggest standardizing on big endian, to be consistent with the native byte order for network addresses and hashes, and to match some mobile platforms. Others, including me, jgarzik, and xf2_org suggest little endian to match the most common computing architectures. Not entirely sure what side I come down on now.

3. Coin Divisibility: genjix suggests using INT128 to allow Bitcoins to be more divisible. realnowhereman suggests a fixed-point base 2 integer. Luke-Jr suggests a varint fraction that specifies the numerator and denominator separately. ribuck suggests he give it a rest please =)

4. Block Size Limit: caveden suggests having the protocol automatically adjust the block size limit according to the transaction rate.

5. Block Discovery Interval: dirtyfilthy and comboy suggest lowering the expected block discovery interval, to take into account the fact that networks speed up over time.

6. Hashing Algorithm: Vladimir and comboy suggest using multiple hashing algorithms for block generation. realnowhereman suggests the opposite: use a trivial CRC to make it quick for mobile devices to verify blocks. Difficulty could still be increased by increasing the number of 0-bits required in the beginning of the hash, or even increasing the number of iterations required as I suggested.

7. Block Downloads: realnowhereman and ByteCoin suggests making it possible to download recent blocks first.

8. Misc: To save space… =) realnowhereman suggests: (1) not specifying one's own IP, since such information could be inaccurate if behind a NAT; (2) getting rid of the unnecessary verack and use of RIPEMD; (3) a client that works in a multi-user environment; and (4) the ability to query a node for transactions it has queued.

Thanks for all the great ideas, everyone. I didn't have time to get a close look at Stevie1024's paper, so I'll do that later. I haven't decided whether I personally want to work on a Bitcoin client or an entirely new protocol, but I really hope either way we end up with a better, more robust cryptocurrency system in the future.

If you just mean to make it take longer to generate, why can't the protocol just gradually increment the number of iterations of SHA256 you must perform?

If you mean to make it less likely for hash vulnerabilities to be found, I think it may be better to just specify the hash algorithm that is used, so the network can easily move to a new algorithm if SHA256 proves to be insecure (as it eventually will be).

EDIT: The reason I think it may not be a good idea to use such a large variety of hash algorithms is that it would make it harder to create an implementation of bitcoin. If I want to write a bitcoin client in javascript, I can easily find a JS library with SHA256 -- but finding one with whirlpool, RIPEMD320, etc, may prove difficult.

ASCII is a single-byte encoding scheme so its characters are represented in memory the exact same way on big endian and little endian systems.

Unfortunately this thread seems to be devolving so if anyone else has other aspects of the protocol they would change, I am interested in hearing about it.

Why not just store numbers in packets as ASCII characters? That would eliminate both length restrictions as well as the above-mentioned endianness concerns. Bittorrent's bencode stores them this way for this reason.

I would argue it's trivial either way, with or without a library. It should only take a few lines of code to perform the appropriate bit shifts.

What about security-related things. I heard there is no encryption between directly-connected clients, so that seems like something that would be worth changing.

Is there any reason in particular? Endianness is pretty straightforward to convert, so I don't see why it would matter either way. Additionally, why wouldn't you use little endian, to match the endianness of x86-based OSes?

Protocols often include design decisions that people later regret, but often are kept for the sake of backwards compatibility. Does anyone consider any aspects of the Bitcoin protocol this way? If you could rewrite the protocol now, what things would you change?

Thanks for your responses. These two quotes seem to suggest different things. My understanding was that blocks contained a hash of every transaction since the last block, and that these transactions weren't "official" until they become part of the block-chain in this way. Is this incorrect? If it's right, then what happens when I create a block that doesn't contain a certain transaction (because I didn't receive it)? Does it get lost in time and never is deemed official?

I'm a hobbyist C++ programmer and spent some time going through Bitcoin's source code and absorbing whatever information I could find online about the protocol. I would really appreciate someone answering the few remaining questions I have.

1. How does the network decide when enough transactions have occurred for new block to be generated? Is it a hard-set number? On a related note, how do I know if I actually have all transactions in a given moment?

2. Once I successfully generate a block, how do I go about announcing this fact to the network? Is it a simple floodfill -- i.e., I send it to all my directly-connected neighbors, and they do the same, on and on until everyone gets it?

3. What happens if two people, Alice and Bob, generate a valid block at approximately the same time, and begin telling the network of their block simultaneously? Won't some nodes receive Alice's first, and some receive Bob's first? Who will ultimately be decided as the "winner"?