Bitcoin Forum
December 07, 2016, 08:15:50 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5  All
  Print  
Author Topic: What would you change about the Bitcoin protocol?  (Read 11164 times)
oskar
Newbie
*
Offline Offline

Activity: 9


View Profile
March 08, 2011, 04:47:29 AM
 #1

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?
1481141750
Hero Member
*
Offline Offline

Posts: 1481141750

View Profile Personal Message (Offline)

Ignore
1481141750
Reply with quote  #2

1481141750
Report to moderator
1481141750
Hero Member
*
Offline Offline

Posts: 1481141750

View Profile Personal Message (Offline)

Ignore
1481141750
Reply with quote  #2

1481141750
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 08, 2011, 05:13:33 AM
 #2

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
oskar
Newbie
*
Offline Offline

Activity: 9


View Profile
March 08, 2011, 05:41:32 AM
 #3

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
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 08, 2011, 06:06:24 AM
 #4

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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
oskar
Newbie
*
Offline Offline

Activity: 9


View Profile
March 08, 2011, 06:26:34 AM
 #5

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
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 08, 2011, 06:37:18 AM
 #6

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 08, 2011, 07:01:28 AM
 #7

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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
March 08, 2011, 07:09:18 AM
 #8

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
Newbie
*
Offline Offline

Activity: 9


View Profile
March 08, 2011, 07:21:29 AM
 #9

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
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 08, 2011, 07:26:14 AM
 #10

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! Cheesy Cheesy Cheesy

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
oskar
Newbie
*
Offline Offline

Activity: 9


View Profile
March 08, 2011, 07:46:06 AM
 #11

Shh! Don't tell anybody that plain text is big endian! Cheesy Cheesy Cheesy
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
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 08, 2011, 07:57:28 AM
 #12

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
Legendary
*
Online Online

Activity: 1106



View Profile
March 08, 2011, 08:42:08 AM
 #13

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

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
QuantumMechanic
Member
**
Offline Offline

Activity: 110


View Profile
March 08, 2011, 11:52:15 AM
 #14

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
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
March 08, 2011, 12:15:31 PM
 #15

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

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
iya
Member
**
Offline Offline

Activity: 81


View Profile
March 08, 2011, 02:10:01 PM
 #16

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
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
March 08, 2011, 08:52:00 PM
 #17

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.

Hal Finney
dirtyfilthy
Member
**
Offline Offline

Activity: 75


View Profile
March 08, 2011, 09:43:43 PM
 #18

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?

Address: 1EkSP5Uqf5Fhs8Gg4XJG2b3hrFS7Vm8WFz
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 08, 2011, 09:45:38 PM
 #19

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
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 08, 2011, 09:47:27 PM
 #20

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. Grin

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
Pages: [1] 2 3 4 5  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!