What would you change about the Bitcoin protocol?

[oskar]

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?

[error]

The absolute #1 first thing I would change would be to make the network protocol big endian.

[oskar]

The absolute #1 first thing I would change would be to make the network protocol big endian.

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?

[error]

The absolute #1 first thing I would change would be to make the network protocol big endian.

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?

Because it goes over the network. I care not what's on the local machine, when dealing with the network. (There's a reason they call big endian "network byte order.")

And x86-based OSes are irrelevant for several deployment scenarios, such as Java (which is big endian).

As for endian conversion, we already have libraries for converting network byte order (big endian) to host byte order (big or little endian; whatever the local system supports), making endian conversion (if necessary) trivial, but only when the protocol is big endian.

[oskar]

As for endian conversion, we already have libraries for converting network byte order (big endian) to host byte order (big or little endian; whatever the local system supports), making endian conversion (if necessary) trivial, but only when the protocol is big endian.

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.

[jgarzik]

Fixed little endian is just fine, and happens to match 99.9% of our current usage.

Big endian adds pointless byteswapping.  "network endian" is just so that Sun could sell more hardware, back in the day.

[error]

Fixed little endian is just fine, and happens to match 99.9% of our current usage.

Big endian adds pointless byteswapping.  "network endian" is just so that Sun could sell more hardware, back in the day.

Eh? Sun barely existed on January 1, 1983.

[genjix]

Would use INT128 so it can be claimed that Bitcoin is 'infinitely divisible' (well that's near enough for most people) as a selling point.

Right now saying it's 8 decimals divisible isn't so catchy.

[oskar]

Would use INT128 so it can be claimed that Bitcoin is 'infinitely divisible' (well that's near enough for most people) as a selling point.

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.

[error]

Would use INT128 so it can be claimed that Bitcoin is 'infinitely divisible' (well that's near enough for most people) as a selling point.

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.

Shh! Don't tell anybody that plain text is big endian!

[oskar]

Shh! Don't tell anybody that plain text is big endian!

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.

[Mike Hearn]

Most of the needed changes can be made in a backwards compatible manner. The subver field in version is currently unused, I'd like to maybe repurpose that at some point into a User-Agent equivalent.

[caveden]

I would change this: http://bitcointalk.org/index.php?topic=1865.0

[QuantumMechanic]

Would use INT128 so it can be claimed that Bitcoin is 'infinitely divisible' (well that's near enough for most people) as a selling point.

That combined with the bitcoin supply limit being 1 since it's so sexy and natural.

[Cdecker]

Little Endian is a pain, and I've said it often enough.

Then the protocol version should evolve independently of the client version. Consolidate some stuff, like "do we really need size fields that can have a length of UINT64?". It's just a cheap trick to optimize the length of the messages, but each message has a fixed header field for the command that is never used fully, why start hacking exceptions in?

And then finally comes my argument for structuring the network topology, in order to scale better and detect partitions (think dynamic degree hypercube).

Edit: nearly forgot my old capabilities proposal: http://bitcointalk.org/index.php?topic=894.0

[iya]

The blockchain is basically an unalterable public register, and I would suggest to use a forward compatible format which allows storage of possibly arbitrary data, of course at the discretion of the block generating node, for possible fees and up to some maximum blocksize.
My main idea for additional usage would be credentials, which would greatly improve some interactions, going so far as to enable credit.
This needs the host and/or blockchain to be used for blind-signing: blind signs-proc.pdf.
The scripting language is already designed to be very flexible, maybe it would need a few extensions.

Disclaimer: I'm regularly programming in C++, but have not much experience with cryptography, so the details of above paper are a little over my head.

[Hal]

My pet peeve, related to endianness, is treating hashes as numbers and reversing them. A hash is a byte string with a well defined order and it makes no more sense to reverse it than to reverse text.

I would also have used a more common elliptic curve for the crypto, and made some changes to speed it up.

[dirtyfilthy]

Though this will probably forever be impossible to change, I wonder about why the interval time was set at ten minutes. Was this number just plucked out of the air? I know there is a relationship between smaller interval times and larger number of chain forks, but it seems to me that this number should be as low as possible while maintaining an "acceptable" number of forks. Would five minutes work? two? one?

[Mike Hearn]

10 mins was set with propagation times in very large networks in mind. I don't think it's worth changing that. There are only two times that matter - instant and not instant. 10 mins vs 5 isn't going to change much.

[error]

10 mins was set with propagation times in very large networks in mind. I don't think it's worth changing that. There are only two times that matter - instant and not instant. 10 mins vs 5 isn't going to change much.

It would have to be much longer than 10 minutes to work properly on the Interplanetary Internet.