Bitcoin Forum
December 05, 2016, 06:37:13 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Coding guidelines  (Read 1102 times)
melek
Newbie
*
Offline Offline

Activity: 11


View Profile
March 02, 2011, 12:50:08 AM
 #1

I have studied the Bitcoin code for the past few days hoping that it would be easy to understand and edit, but for me it was quite hard to figure out what exactly is going on. I think we need to simplify the code and make it more modular.
Having a clear code base that follows strict guidelines (such as those given by Google) is of great importance for improving the maintainability of the code and attracting new developers. Simplicity also improves security as there will be less attack vectors compared to an overcomplicated chunky code-base.

There are a few decisions about Bitcoin that I do not understand.

Firstly, what is the justification for using esoteric elliptic curve cryptography, rather than the standard public/private key cryptography as used in PGP or SSH? If we want to move away from elliptic curves, how difficult would it be to translate the current block-chain so that we can transition to an alternative client while preserving all transactions and the current wealth distribution?

Secondly, I find it difficult to understand the concept behind the "scripting" part of the Bitcoin client. Why isn't the communication between the clients done via remote procedure calls, reusing some RPC library that is well-tested and secure, rather than inventing a custom protocol that has not been tested for security? The Bitcoin client should be based on technology that is tested and has been shown to work well.

I think Satoshi was a genius for coming up with the idea of Bitcoin, but the code of the default Bitcoin implementation leaves a lot to be desired in terms of clarity and simplicity. In order to take Bitcoin to the next level, I think it is important that we focus our attention on simplifying the code and on increasing its modularity.

First, we should provide a clearly documented C++ API to a Bitcoin library - libbitcoin. Libbitcoin should only concern itself with the application logic of bitcoin, and should have a public api for sending and receiving coins.

Second, the network communication protocol should be completely decoupled from the libbitcoin library. The libbitcoin should define an interface that will allow the library to broadcast and receive information from the network. Maybe the network communication can be set up as plugins - where one could load a multitude of communication plugins - the current bitcoin protcol would be one of many plugins, there will be alternatives such as ones based on RPC, others based on RESTful HTTP connections to bitcoin clients, and maybe when security is important bitcoin clients may connect with each other via encrypted ssh.

Of course, all this is easier said than done, but I think we should be able to gradually achieve these goals.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480963033
Hero Member
*
Offline Offline

Posts: 1480963033

View Profile Personal Message (Offline)

Ignore
1480963033
Reply with quote  #2

1480963033
Report to moderator
grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
March 02, 2011, 12:51:43 AM
 #2

I agree about the scripting part.  To me this is kind of huge mystery.
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
March 02, 2011, 10:34:20 AM
 #3

Get on it then Grin
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
March 02, 2011, 11:03:56 AM
 #4

Firstly, what is the justification for using esoteric elliptic curve cryptography
Elliptic curve cryptography takes less than one-tenth the space in the block chain, because the keys are so much shorter for the same degree of security.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 02, 2011, 02:00:30 PM
 #5

Firstly, what is the justification for using esoteric elliptic curve cryptography, rather than the standard public/private key cryptography as used in PGP or SSH?

As noted, the reason is ECDSA signatures are an order of magnitude smaller than RSA.

I'm not sure ECC really counts as esoteric. It's a part of SSL for some time already. It's newer than RSA but getting more popular over time.

Quote
Secondly, I find it difficult to understand the concept behind the "scripting" part of the Bitcoin client.

Scripts are not to do with network communication. They are to allow for flexible types of transactions. Today the client only generates one type of transaction - taking coins from some inputs and sending them to some outputs. But Satoshi also wanted to support things like escrow transactions, multi-claimant transactions, password protected transactions etc. Scripting allows for this to be phased in over time as new transaction types are designed.

Unfortunately Satoshi left no documentation explaining what tx types are possible or how to structure them. This is an underexplored area of the system.

Quote
Why isn't the communication between the clients done via remote procedure calls, reusing some RPC library

Satoshi felt that he couldn't have any confidence in parsing code that was complex and had many degrees of freedom. Also there aren't so many good RPC/serialization libraries out there. Protocol buffers are pretty good but by the time it was released, the code was already written.

This is a tradeoff between having flexible serialization and being able to convince yourself of its correctness by reading it. Here's a direct quote from Satoshi when I asked him the same thing:

Quote from: satoshi
I looked at Google protocol buffers when they were released last year, but I had already written everything by then.  What I did was something similar to Boost Serialisation.  For this application, where I was parsing messages from strangers who might have extreme incentive to hack the protocol, it was necessary to make it as basic as possible so I could crawl over every line of code to convince myself it was airtight.  It became clear that any unnecessary degrees of freedom in the binary format multiplied the potential angles of attack.  You guys are so right though to standardize across the company on protocol buffers.  I think you've got the optimal solution in the general case.

As to simplification. I'm this -><- close to releasing a fairly well documented (but incomplete) Java implementation of the system. It comes with a fully JavaDocd API and some example apps. Also lots of comments. I'm hopeful this will make programming directly against the protocol less opaque.

Note that if you just want to receive/make payments, the JSON-RPC API the official client already exposes works well, is easily accessible from many languages and is how people are programming against the system today. The Java libraries being written will be primarily of interest to people who can't/don't want to use bitcoind for some reason, or who want to do lower level bitcoin hackery than what the JSON-RPC api provides.
Pages: [1]
  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!