Topic: A minimum Bitcoin daemon. (Read 3687 times)

I haven't programmed C or C++ for about 15 years. I moved onto Java and I remember the joy of not having to update header files anymore.

However, It would be nice to re-learn my C++ skills so I may have a crack at this on the side.

A favorite quote of mine:  "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -- Alan Kay

Here's my perspective...for about 5 years all I did was C++.  I loved it.  This was in the late 80's and early 90's.  My employer's library (big company) had a subscription to The C++ Report (which was about $300/yr at the time)...I lapped up everything in that journal and everything that Stroustrup had to say on the topic.  Then, I happened upon Smalltalk.  It was a language that had a clear goal and was honed over a period of ~10 years using the scientific method and it shows.  It's a beautiful language.  In retrospect I came to realize that C++ was a language that was designed in a rather haphazard manner...reading some of the articles in the C++ report were like reading the musings of a person that suddenly realized a deficiency in the language and hacked something in to fix it.  It was a series of one hack after another.  That's not to say that C++ doesn't have some convenient constructs to offer, nor that people can't do useful things with it (clearly they can)...it's just to say that as far as languages go, C++ is rather poor.  C sticks very close to the machine architecture and as such, is very useful (and of course since most OSes are written in it, it's most convenient for interfacing with the OS).  Stroustrup just did a poor job of grafting OO capabilities on top of C (and which in retrospect was probably a bad idea to begin with).  Objective-C was arguably a better approach to adding OO to C, but is still a horrible monstrosity.  Java, Smalltalk, and other OO languages that have a native interface are much better ways to combine the high level constructs of OOP with the lower level utility of C.  Google's Dart will be interesting...its "isolates" and optional type system may bring a couple long overdue concepts into the broader consciousness of developers.

This is just my perspective.  I try not to be a language fanatic and have no problem writing C++ code when I need to (among many other languages).  But, I also appreciate good language design and like to talk about it from time to time.

The problem isn't coding, its maintaining the code. The quality of C++ implementations leaves a lot to be desired. And those desires will probably never be fulfilled.

Lets revisit the issue when you integrate your boost-using libbitcoin with some other system written with a different release of boost or that just requires to be compiled with a different set of flags. You will probably end up like many other C++ projects: maintaining a private boost tree where every instance of the identifier "boost" was replaced with "god_please_forgive_me_i_will_never_do_it_again". But for now have fun while you still have your hair un-pulled.

lol, yeah I didn't feel like I was contributing much to the convo so I was going to type a proper response instead but then... ahhh lost interest.

Here's the unfinished version:
----------

C++ is perfectly standard and for good reason. C is simplistic which makes it ideal for small projects.

I think critics of C++, cannot code C++. It's not only C with classes, but template meta-programming, RAII, design patterns, generalised expressions and so on, all with type-safety.

There's a reason many large projects are written in it, but not in Python. But the language is not easy to learn and

genjix...I saw that 

For two you should probably use dnsseeds and not irc...   even easier and faster and should be cleaner.  Also leaves room for the dnsseeds to weight filter out old bad nodes in the future.

As for your #1, rather then just change it to goto files, it would be nicer to change the db interface... to be more by the functions....   then change this to be able to talk to different back ends....  a good first one to use may be the sqlite direct btree interface as that is a nice bridge in between two.   Do this first for the address.dat file, which already seems silly to be using dbd and transactions.  Then for the block chain, then  maybe put the wallet.dat into the sql sqlite interface with transaction support still (really the only part that seems to need them, even though it is currently turned on for all the bdb files).

I take it by your comment about a decent C coder could do this.... that you yourself are not actually thinking of implementing this, but just wondering about it?

Looking at 2 and 3, they are quite simple. Forward a transaction (2) could be as simple as

1. Download IP addresses from IRC channel (lots of code around that does IRC).
2. Connect to a node in the list and forward a raw transaction.

Monitor an address (3)

1. Connect to a node similar to above
2. Parse each incoming transaction looking for the public address.

So it's 1 that would be the hardest as you'd have to do the block logic. But given that you could cut and paste the official bitcoin client code I reckon a decent C coder could achieve this in about a week.

Slight tangent.
While this may be true of python, it is not true of high level languages in general.  For example, the squeak VM (squeak.org) is written entirely in Smalltalk.  It is translated into C code, then from there to machine code.  However, had the authors had the time or inclination, they could have bypassed C altogether to translated straight to machine code.  Whether you can do this in any particular language is a function of how complete and well designed that language is...it's not any inherent limitation of high level languages in general.

I'm sure you could find a way around that...for example, you could create one file per bitcoin block and store the full content of the bitcoin block in that file (including transactions).  For accessing individual transactions, you could use file system links (filename is the tx id) that point to the block in which the transaction appears.  Having the block chain easily accessible via the file system and small command line utilities to do things with it would be quite useful.  That's not to say there isn't also place for using a DB.

don't do file based storage, its just stupid, every TX will fill up for at least the blocksize, of the FS. it is not a good idea, and it will not scale.

I think this is a good idea...removing BDB and going with a git style content addressable, file based store should be a good fit for bitcoin.  And it shouldn't take anywhere near a year to do it.  I also prefer well written C code over C++.

C++ is bad. its a blend of high-level language and a low-level language. it can not be good.
if you want low-level DO low-level! Assembler and C.
if you want high-level DO high-level Python and Ruby.

you can't write an OS/kernel in python(someone did try, and failed.), but in C you can, and that is what C is for.

but do not blend the things, it will not work out well. its like blending potato and mango

Implementing Bitcoin is hard work if you want to do it well. I wouldn't start on it unless you're willing to sink, say, a year into it.

Linus rants about things. I wouldn't pay too much attention to him. If C++ is so horrible how did Google manage to build an entire search engine and distributed computing infrastructure with it? Why are nearly all video games written in it?

The idea that C++ is inherently bad is something you find in parts of the Linux/GNU community but not so much in industry.

I was reading Linus's take on C++ http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Not saying that I agree or disagree with his views but it got me thinking what could be a useful but very small Bitcoin daemon written in C.

So I thought.

1. Creates a file based representation of the block chain. So take out the berkely DB and store the transactions as files similar to the way git handles version control. The folder structure would be such that transaction were easy to find by public key or transaction hash.

2. Can forward a transaction. It would have no knowledge of wallets or keys but it could forward a transaction to the network. Transactions could be saved as a file to a folder the daemon monitors.

3. Can monitor an address. i.e. will call an excutable you specify when a transaction is receved for an address. This would handle instant payment notifications.

The advantages I see are.

1. Small and very lean, once up and running there would be no need to update it.

2. All of the possible use cases for Bitcoin such as wallets etc, could be built on top of the 3 function listed above (I'm making a bit of an assumption there).

3. It would open up the database. It's my understanding Berkely DB only handles 1 process at a time ?

4. Would require a minmum of linked in libraries, so easier to compile on all platforms.

Is this a good/bad/flawed idea ?