[ANN] cbitcoin 2.0 - A Bitcoin Library in C

[notme]

I am currently studying Enterprise Development BA at the University of Huddersfield and I have a very exciting business idea for bitcoin that would make use of cbitcoin.

So... please don't take this the wrong way, but what's your prior experience creating and shipping high-quality software?

I ask because re-implementing Bitcoin as a first "software-people-other-than-myself-are-going-to-use" project is a really bad idea, I don't see any list of previous work at the RocketHub page, and the 9,000 lines of code you've already written doesn't look like the work of somebody who has professional software development experience (e.g. no makefile/build system ...).

Maybe you're a prodigy and will get it right the first time, but you're already at 'cbitcoin 2.0' because you weren't happy with how 'cbitcoin 1.0' was turning out. See the solidcoin/microcash saga for an example of how over-promising "1.0/2.0/3.0" releases destroys confidence.

And maybe you CAN point to some other successful software you wrote and shipped when you were 17, in which case I'll shut up and leave you alone.

What's the matter Gavin, can't take a little competition?

How about instead of ad hominem attacks you actually read through his 9000 lines of code already written and find something concrete to criticize? Wouldn't that be more relevant and productive than questioning his capability based on a brief observation? And why not encourage him to try and fail if nothing else, it's not like his failure will be forced upon anyone else but his success might be good for a lot of people, no?

Btw I'm posting this not because I have anything against your work on the original client but because I can't understand the nature or goal of your post. If it was to save people from investing into something that might not yield a positive result, I would have wished you didn't need to resort to manipulative fallacies to do so.

Indeed.  I don't see a reason for the hate from reference client developers other than their codebase is a competitor.  I haven't had time to dig into cbitcoin, but a C language library implementation will definitely be useful.  Sure it might be a bit rough around the edges, but lets give him some time to develop it and get some help from other developers.

I can agree about the version number inflation.  I know it seems superficial, but 0.0, 0.2, etc. is a much better way to go than 1.0, 2.0, 3.0.  1.0 should not be used until you have a usable library with a stable API.

[1714755186]

1714755186

[1714755186]

1714755186

[1714755186]

1714755186

[1714755186]

1714755186

[1714755186]

1714755186

[MatthewLM]

I do not mind people being skeptical but sometimes it can seem disingenuous. I don't think Gavin was trying to be disingenuous but he was a little bit considering he was jumping to conclusions on assumptions and dubious subjective opinion.

It's fair to ask for what my previous experience is. It's not fair to say my project is an automatic failure because of my previous experience. You may wish to only donate to projects run by 50 year old experienced cryptographers and that is OK if you want that. Equally, a younger brain can yield much more interesting and innovative results. The problem with people with "experience" is sometimes this experience is full of old ideas and habits. I hope my progress on cbitcoin thus far has been some indicator to my ability. I'm just looking forward to completing it so I can really demonstrate what I can do.

The focus should not all be on me either. I'm the project leader but not the only person who will be working on this project.

I guess I just need to get that logo sorted. Once I have a logo people will have to take me seriously.  

Indeed.  I don't see a reason for the hate from reference client developers other than their codebase is a competitor.  I haven't had time to dig into cbitcoin, but a C language library implementation will definitely be useful.  Sure it might be a bit rough around the edges, but lets give him some time to develop it and get some help from other developers.

Time is nice. I would appreciate that.  The library is not rough around the edges; it's incomplete. It doesn't completely work, it has many problems... because it's incomplete. I'm working on it (help appreciated).

I can agree about the version number inflation.  I know it seems superficial, but 0.0, 0.2, etc. is a much better way to go than 1.0, 2.0, 3.0.  1.0 should not be used until you have a usable library with a stable API.

This is opinion. My opinion is that it makes much more sense to have the left number as incompatible releases and the right number as compatible releases (No confusion over "will this break my code" then). Maybe I should have had three numbers but I prefer to keep it simple. If this goes against convention, then good. I like breaking conventions. I'll signify alpha and beta releases by adding alpha-x or beta-x on the end (eg. cbitcoin 2.0 alpha-2).

[Peter Todd]

I am currently studying Enterprise Development BA at the University of Huddersfield and I have a very exciting business idea for bitcoin that would make use of cbitcoin.

So... please don't take this the wrong way, but what's your prior experience creating and shipping high-quality software?

I'll make another point: what's your prior experience with working with others? Part of what you're asking money for is to have the option to hire people to do some of the work for you, and in addition you're also asking for help with the codebase. I haven't done much management myself, but I have done just enough to know it's surprisingly difficult. Do you even have experience even just contributing to an open-source project, or working as a programmer in a large group? The people skills of setting expectations, negotiating technical compromises and so on are surprisingly hard to learn or do right without experience, well, doing just that. Frankly you're going to waste peoples' donations and time if you haven't had experience doing this before; at least have solid experience working in a group on software. It doesn't have to be fancy - some web-programming for a website is fine - but it has to be real and it has to be in a group.

Myself I'd feel better even if you were able to say you worked as a shift manager at a fast-food resturant; seriously, even that kind of experience would make a big difference to your success with hiring others on the project or with working with other volunteer contributors. Right now I just get the impression you manage to come off the wrong way with others in the community.

Maybe you're a prodigy and will get it right the first time, but you're already at 'cbitcoin 2.0' because you weren't happy with how 'cbitcoin 1.0' was turning out. See the solidcoin/microcash saga for an example of how over-promising "1.0/2.0/3.0" releases destroys confidence.

And maybe you CAN point to some other successful software you wrote and shipped when you were 17, in which case I'll shut up and leave you alone.

I'm 27 now, and I remember my projects ten years ago that I thought were going to change the world... and they didn't. Do the right web searches and you can probably still find some emails on the Freenet project development lists among others that I now find kinda embarrassing to say the least.

I've got this timestamping project I'm working on right now. It's not as far along as your library, 2500 lines vs. 9800, but still, you notice how probably no-one here actually knows the name of it? I might think it's going to change the world, but I don't want to waste people's time on a project that doesn't really exist yet. There's nothing wrong with eventually asking for donations and asking for help, but get something concrete first that's actually getting used in the real world to do a real task, then start thinking about where you're going to go next. You're also not going to really understand how your software should be architectured until you're at that point.

Myself I've set the goal that my timestamping thing needs to be able to create and validate timestamps, and a user should be able to do that out of the box. It doesn't have to be pretty or nicely documented, but it has to do something real and useful. I know I'm not really going to understand if my idea even makes any sense until I'm at that point. For instance for you, you're not going to know if, say, writing it in C makes any sense until you try integrating cbitcoin with a real-world C application using it. You also won't know if you're library interface makes sense until someone else tries to integrate *their* application with your library; IE, the point where they'll decide "yeah, lets send some money to this guy and improve it" Speaking of, the discussion on the forums about the license for cbitcoin is a good example: you'll understand better what sort of licensing works for people when people actually want to use your library for a real-world application.

Making a big deal about the project before that point is just going to make people think it's a bunch of vaporware, and people are also going to think I'm wasting a lot of other peoples time on the forums. I'm definitely not at the point where I can ask others for money to further the development effort. Posting occasional status updates and progress reports is fine, but just like me you're a long way away from going further than that.

tl;dr: In open-source useful working code speaks louder than anything else.

How about instead of ad hominem attacks you actually read through his 9000 lines of code already written and find something concrete to criticize? Wouldn't that be more relevant and productive than questioning his capability based on a brief observation? And why not encourage him to try and fail if nothing else, it's not like his failure will be forced upon anyone else but his success might be good for a lot of people, no?

jgarzik and others have raised very good points on why his failure does have the potential to do a lot of harm to others. Splitting the network with incompatible implementations is a very real risk and does have the potential to harm everyone in the community. In addition bad PR from software failures affects us all.

Besides, I want to see Matthew become an open source contributor, and much of being an effective open source contributor has nothing to do with technical skills.

[hazek]

How about instead of ad hominem attacks you actually read through his 9000 lines of code already written and find something concrete to criticize? Wouldn't that be more relevant and productive than questioning his capability based on a brief observation? And why not encourage him to try and fail if nothing else, it's not like his failure will be forced upon anyone else but his success might be good for a lot of people, no?

jgarzik and others have raised very good points on why his failure does have the potential to do a lot of harm to others. Splitting the network with incompatible implementations is a very real risk and does have the potential to harm everyone in the community. In addition bad PR from software failures affects us all.

It was not my intention to defend MatthewLM, he can clearly do that on his own, or to suggest he should be automatically trusted with your contribution just because he says nice things. Of course his background and history are important and should be questioned. All that I didn't appreciate is the manner in which Gavin did so.

As for any dangers of his failures I simply don't understand how a project with open code could ever implement or cause someone else to implement code that could cause any real harm. Actually if it did happen I think I'd have to welcome that sort of split because it would signal that the market isn't happy with the original client or is more happy with a new client. As long as the use of any code is voluntary there should be no problems for the future of Bitcoin, no?

[Peter Todd]

It was not my intention to defend MatthewLM, he can clearly do that on his own, or to suggest he should be automatically trusted with your contribution just because he says nice things. Of course his background and history are important and should be questioned. All that I didn't appreciate is the manner in which Gavin did so.

As for any dangers of his failures I simply don't understand how a project with open code could ever implement or cause someone else to implement code that could cause any real harm. Actually if it did happen I think I'd have to welcome that sort of split because it would signal that the market isn't happy with the original client or is more happy with a new client. As long as the use of any code is voluntary there should be no problems for the future of Bitcoin, no?

The code may be open, but open code only helps if you are knowledgeable enough to both understand the code, and understand the potential problems. Frankly Bitcoin is complex, and subtle, enough that even most experienced developers don't have much hope of doing that without a big investment of time. Thus if cbitcoin has flaws it will be used anyway, although hopefully used less if the developers who do understand the issues vocally complain on the forums. Obviously that's exactly what has happened.

The market is only efficient if information is widely spread. Unfortunately information about what bitcoin software is secure doesn't appear to meet that criteria very well.

[notme]

It was not my intention to defend MatthewLM, he can clearly do that on his own, or to suggest he should be automatically trusted with your contribution just because he says nice things. Of course his background and history are important and should be questioned. All that I didn't appreciate is the manner in which Gavin did so.

As for any dangers of his failures I simply don't understand how a project with open code could ever implement or cause someone else to implement code that could cause any real harm. Actually if it did happen I think I'd have to welcome that sort of split because it would signal that the market isn't happy with the original client or is more happy with a new client. As long as the use of any code is voluntary there should be no problems for the future of Bitcoin, no?

The code may be open, but open code only helps if you are knowledgeable enough to both understand the code, and understand the potential problems. Frankly Bitcoin is complex, and subtle, enough that even most experienced developers don't have much hope of doing that without a big investment of time. Thus if cbitcoin has flaws it will be used anyway, although hopefully used less if the developers who do understand the issues vocally complain on the forums. Obviously that's exactly what has happened.

The market is only efficient if information is widely spread. Unfortunately information about what bitcoin software is secure doesn't appear to meet that criteria very well.

The only flaws pointed out is that it will broadcast invalid transactions (which other nodes will ignore), and that there is not a good build system in place.  The other complaints turned out to be misunderstandings.  While an alternative implementation could cause damage if widely used and not properly implemented, neither of these flaws are dangerous.  Cbitcoin will still reject blocks with invalid transactions and the build system will be put in place eventually (and has no bearing on the functionality of the code).

[MatthewLM]

I'll make another point: what's your prior experience with working with others? Part of what you're asking money for is to have the option to hire people to do some of the work for you, and in addition you're also asking for help with the codebase. I haven't done much management myself, but I have done just enough to know it's surprisingly difficult. Do you even have experience even just contributing to an open-source project, or working as a programmer in a large group? The people skills of setting expectations, negotiating technical compromises and so on are surprisingly hard to learn or do right without experience, well, doing just that. Frankly you're going to waste peoples' donations and time if you haven't had experience doing this before; at least have solid experience working in a group on software. It doesn't have to be fancy - some web-programming for a website is fine - but it has to be real and it has to be in a group.

I've not had experience working with other developers on a project, only working with people on ideas. The biggest thing I've learned is that when you start working with people, it's very easy for them to forget about the project and disappear. Sometimes even when you email them repeatedly, they just ignore you. This is not a problem here where I will be hiring professionals and paying them but I need to make sure the money does not go to waste. I know never to pay by the hour. Using fixed prices with clear terms is important, otherwise people will not deliver and take all your money (cynical, I know, but true).

tl;dr: In open-source useful working code speaks louder than anything else.

Fund a project's development after developing it? Hmm. Do you see the problem there?

Thus if cbitcoin has flaws it will be used anyway, although hopefully used less if the developers who do understand the issues vocally complain on the forums. Obviously that's exactly what has happened.

If a house is under construction and does not have a roof, is it fair to say "That house is a failure, it doesn't keep out the rain"? cbitcoin doesn't have a roof at the moment but it's not finished so people have no right whatsoever to complain.

Judge it's safety and quality when it is released as final. For now, if you see flaws, please fix them or politely bring them to my attention in case I've not yet noticed.

The testing of cbitcoin is the most important part.

The problem with this topic, is I don't think it's very productive for me at the moment and I've got a lot of things to do, so I apologise if I do not respond right away.

The only flaws pointed out is that it will broadcast invalid transactions

Wrong. I can broadcast invalid transactions but there is no reason why anyone would want to do that unless for testing purposes in which case that can be useful. So it's not a flaw.

that there is not a good build system in place

After I've finished the deletion algorithm for the B-Tree structure, I will make a makefile (pun intended). So it's now the next thing on my list. I've already prepared the directory structure which annoys me slightly since I liked it better when the header files and source files were grouped together in a friendly way. I suppose this is not so bad as I could re-organise everything within Xcode using groups. I'll make sure to do that as well.

[Peter Todd]

The code may be open, but open code only helps if you are knowledgeable enough to both understand the code, and understand the potential problems. Frankly Bitcoin is complex, and subtle, enough that even most experienced developers don't have much hope of doing that without a big investment of time. Thus if cbitcoin has flaws it will be used anyway, although hopefully used less if the developers who do understand the issues vocally complain on the forums. Obviously that's exactly what has happened.

The market is only efficient if information is widely spread. Unfortunately information about what bitcoin software is secure doesn't appear to meet that criteria very well.

The only flaws pointed out is that it will broadcast invalid transactions (which other nodes will ignore), and that there is not a good build system in place.  The other complaints turned out to be misunderstandings.  While an alternative implementation could cause damage if widely used and not properly implemented, neither of these flaws are dangerous.  Cbitcoin will still reject blocks with invalid transactions and the build system will be put in place eventually (and has no bearing on the functionality of the code).

Those are the flaws that have been found; who knows what flaws are still there.

Network splits are a big danger and the Bitcoin software is mostly unique in having that problem. Because it's unique people don't have prior experience dealing with the problem, so the process of learning about network splits is going to be painful as alternate implementations become more popular. I'd rather see that process happen in a slow, controlled manner than happen quickly and accidentally. You know the build system that itself isn't what worries me, it's that such a build system is a sign that other software engineering considerations haven't been considered carefully.

cbitcoin could make for an excellent test case for the type of compatibility tests that Gavin has worked a bit before. (as could pynode) The development of it could help drive testing those tests and learning how to apply them. Instead I get the impression of a rush to get some big grand project out the door.

[notme]

I give up.  Every time I try to defend your project you tell me I'm wrong for some small semantic reason.  I'll let you stand alone now since it's apparent you don't want my help.

I think retep may have a point about needing to learn to play well with others.

[notme]

The code may be open, but open code only helps if you are knowledgeable enough to both understand the code, and understand the potential problems. Frankly Bitcoin is complex, and subtle, enough that even most experienced developers don't have much hope of doing that without a big investment of time. Thus if cbitcoin has flaws it will be used anyway, although hopefully used less if the developers who do understand the issues vocally complain on the forums. Obviously that's exactly what has happened.

The market is only efficient if information is widely spread. Unfortunately information about what bitcoin software is secure doesn't appear to meet that criteria very well.

The only flaws pointed out is that it will broadcast invalid transactions (which other nodes will ignore), and that there is not a good build system in place.  The other complaints turned out to be misunderstandings.  While an alternative implementation could cause damage if widely used and not properly implemented, neither of these flaws are dangerous.  Cbitcoin will still reject blocks with invalid transactions and the build system will be put in place eventually (and has no bearing on the functionality of the code).

Those are the flaws that have been found; who knows what flaws are still there.

Network splits are a big danger and the Bitcoin software is mostly unique in having that problem. Because it's unique people don't have prior experience dealing with the problem, so the process of learning about network splits is going to be painful as alternate implementations become more popular. I'd rather see that process happen in a slow, controlled manner than happen quickly and accidentally. You know the build system that itself isn't what worries me, it's that such a build system is a sign that other software engineering considerations haven't been considered carefully.

cbitcoin could make for an excellent test case for the type of compatibility tests that Gavin has worked a bit before. (as could pynode) The development of it could help drive testing those tests and learning how to apply them. Instead I get the impression of a rush to get some big grand project out the door.

I agree that testing should be a big part of the development of any bitcoin implementation.

[cypherdoc]

i have a concern with MatthewLM.  mine comes from an extensive exposure to his knowledge (or more appropriately lack of) surrounding basic economics.  he has consistently trolled me in my gold thread and said many inappropriate things.  not that i may not have deserved it but i honestly feel he does not have a full understanding of what's going on in the financial world today. in other threads, i have had to actually teach and explain to him concepts about the Federal Reserve and its balance sheet, etc.  Satoshi's brilliance comes from how he artfully integrated a proper understanding of code, economics, cryptography, mathematics, and human behavior all into one project.   MatthewLM does not impress me at all in this regard.

[Peter Todd]

I'll make another point: what's your prior experience with working with others? Part of what you're asking money for is to have the option to hire people to do some of the work for you, and in addition you're also asking for help with the codebase. I haven't done much management myself, but I have done just enough to know it's surprisingly difficult. Do you even have experience even just contributing to an open-source project, or working as a programmer in a large group? The people skills of setting expectations, negotiating technical compromises and so on are surprisingly hard to learn or do right without experience, well, doing just that. Frankly you're going to waste peoples' donations and time if you haven't had experience doing this before; at least have solid experience working in a group on software. It doesn't have to be fancy - some web-programming for a website is fine - but it has to be real and it has to be in a group.

I've not had experience working with other developers on a project, only working with people on ideas. The biggest thing I've learned is that when you start working with people, it's very easy for them to forget about the project and disappear. Sometimes even when you email them repeatedly, they just ignore you. This is not a problem here where I will be hiring professionals and paying them but I need to make sure the money does not go to waste. I know never to pay by the hour. Using fixed prices with clear terms is important, otherwise people will not deliver and take all your money (cynical, I know, but true).

You're cynicism is a good thing... but don't think even hiring "professionals" magically makes the problems go away. How do you evaluate if someone is a professional? How do you deal with the inevitable conflicts when their idea of "done" doesn't match your idea? What are clear terms anyway? These are all things you'll be much more qualified to answer after you've had some experience being that developer being paid and seen the process first hand from start to finish.

Keep in mind too, that if people forget about a project and disappear, that may be an indication you're doing something wrong too.

tl;dr: In open-source useful working code speaks louder than anything else.

Fund a project's development after developing it? Hmm. Do you see the problem there?

Not at all. You do the first x%, prove that you know what you're doing and are on the right path, and then you can ask the community for the other y%. I'm saying the x% you've done too date is far too low to be taken seriously. You'll also find that after you've done one round of this, x+y << 100%

Thus if cbitcoin has flaws it will be used anyway, although hopefully used less if the developers who do understand the issues vocally complain on the forums. Obviously that's exactly what has happened.

If a house is under construction and does not have a roof, is it fair to say "That house is a failure, it doesn't keep out the rain"? cbitcoin doesn't have a roof at the moment but it's not finished so people have no right whatsoever to complain.

Judge it's safety and quality when it is released as final. For now, if you see flaws, please fix them or politely bring them to my attention in case I've not yet noticed.

The testing of cbitcoin is the most important part.

Security isn't a feature, it's a process. The analogy isn't that your house under construction doesn't have a roof, it's that people are noticing the walls being put up are crooked and the roof won't be supported when it is added. You're saying you'll straighten up the walls later, which may be true, but why weren't they straight in the first place? What's your process do make sure they are straight when you're done?

Frankly I think figuring out how to test cbitcoin properly is the most interesting and challenging part of the whole project. It's very good that you're beginning to do this, your scriptCases.txt in the test/ subdir as well as the other unit tests, but I don't seem to be the only one who is unconvinced about the depth you're going into. In particular I don't see any information on how your test suite can be used to validate the Satoshi client. Doing that is an essential validation that your test suite is itself correct. Similarly rejecting invalid transactions is a case that must be done correctly.

As a suggestion: a good project would be some sort of node behavior logger that wrapped around bitcoind and collected every transaction received, valid and invalid, as well as the state of the node when the transaction was received. (state being essentially what transactions the node has already received) If you can replay that log for your own software, including the invalid transactions, and you wind up with the same end-state at the Satoshi client you'll be a lot closer to where you need to be.

What I just described isn't that simple... but if you can implemented that, and understand where what I suggested oversimplifies the problem, I think you'll be far closer to understanding the problem enough to be able to effectively push cbitcoin ahead.

[jgarzik]

How about instead of ad hominem attacks you actually read through his 9000 lines of code already written and find something concrete to criticize? Wouldn't that be more relevant and productive than questioning his capability based on a brief observation? And why not encourage him to try and fail if nothing else, it's not like his failure will be forced upon anyone else but his success might be good for a lot of people, no?

It's not a brief observation.  We've been on IRC, teaching him the bitcoin basics for (months?) now.

It is good to have people learning bitcoin, and putting that knowledge to use.

It is not as good when obviously-still-learning people are billing their project as the "future of bitcoin" and misleading people into thinking they are a bitcoin expert, and are misleading people into thinking they are producing high quality, proven code (and potentially taking thousands of dollars for it).  Those who are not coders lack the skills to judge this sort of thing, and only have hype from this thread to go on.

[cypherdoc]

MatthewLM was convinced to buy his first Bitcoin only a few months ago.

[adamstgBit]

MatthewLM was convinced to buy his first Bitcoin only a few months ago.

are you sure about that?
"Date Registered:    June 09, 2011, 02:03:26 PM"

[cypherdoc]

MatthewLM was convinced to buy his first Bitcoin only a few months ago.

are you sure about that?
"Date Registered:    June 09, 2011, 02:03:26 PM"

i am.  he came onto my gold thread and announced it.  i'm too lazy to hunt for it but i'm almost sure.

[cypherdoc]

MatthewLM was convinced to buy his first Bitcoin only a few months ago.

are you sure about that?
"Date Registered:    June 09, 2011, 02:03:26 PM"

i am.  he came onto my gold thread and announced it.  i'm too lazy to hunt for it but i'm almost sure.

here it is:  https://bitcointalk.org/index.php?topic=68655.msg1034613#msg1034613

[MatthewLM]

I'd like to thank everyone who has donated and has been supportive. I will continue to read suggestions and constructive criticism, and I will reply if I have time. However I will not argue with anyone and I will ignore any antagonistic posts.

Also I apologise for being defensive or rude towards anyone.

I see the future of bitcoin resting in open innovation, with fast, secure and scalable bitcoin software. I don't want the future of bitcoin to be endless downloading of the block-chain and waiting for confirmations on Mac, Windows or Linux software using one client. I will ignore anyone that is against this ideal and no one can stop me trying to help this process of innovation and competition.

If anyone wants to help. Here's a little thing I could be helped with: Finding out what is wrong with this B-tree insertion algorithm (The order is the number of elements, not children):

Code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

#define CB_BTREE_ORDER 8
#define CB_BTREE_HALF_ORDER CB_BTREE_ORDER/2

typedef struct{
	void * parent;
	void * children[CB_BTREE_ORDER + 1];
	unsigned char numElements;
} CBBTreeNode;

typedef struct{
	unsigned char found;
	CBBTreeNode * node;
	unsigned char pos;
} CBFindResult;

typedef struct{
	unsigned char keySize;
	unsigned char dataSize;
	int nodeSize;
	CBBTreeNode * root;
} CBAssociativeArray;

CBFindResult CBAssociativeArrayFind(CBAssociativeArray * self, unsigned char * key);
void CBAssociativeArrayInsert(CBAssociativeArray * self, unsigned char * key, void * data, CBFindResult pos, CBBTreeNode * right);
CBFindResult CBBTreeNodeBinarySearch(CBBTreeNode * self, unsigned char * key, unsigned char keySize);
void CBInitAssociativeArray(CBAssociativeArray * self, unsigned char keySize, unsigned char dataSize);

CBFindResult CBAssociativeArrayFind(CBAssociativeArray * self, unsigned char * key){
	CBFindResult result;
	CBBTreeNode * node = self->root;
	for (;;) {
		result = CBBTreeNodeBinarySearch(node, key, self->keySize);
		if (result.found){
			result.node = node;
			return result;
		}else{
			if (node->children[result.pos])
				node = node->children[result.pos];
			else{
				result.node = node;
				return result;
			}
		}
	}
}
void CBAssociativeArrayInsert(CBAssociativeArray * self, unsigned char * key, void * data, CBFindResult pos, CBBTreeNode * right){
	// See if we can insert data in this node
	unsigned char * keys = (unsigned char *)(pos.node + 1);
	unsigned char * dataElements = keys + self->keySize * CB_BTREE_ORDER;
	if (pos.node->numElements < CB_BTREE_ORDER) {
		if (pos.node->numElements > pos.pos){
			memmove(keys + (pos.pos + 1) * self->keySize, keys + pos.pos * self->keySize, (pos.node->numElements - pos.pos) * self->keySize);
			memmove(dataElements + (pos.pos + 1) * self->dataSize, dataElements + pos.pos * self->dataSize, (pos.node->numElements - pos.pos) * self->dataSize);
			memmove(pos.node->children + pos.pos + 2, pos.node->children + pos.pos + 1, (pos.node->numElements - pos.pos) *  sizeof(*pos.node->children));
		}
		memcpy(keys + pos.pos * self->keySize, key, self->keySize);
		memcpy(dataElements + pos.pos * self->dataSize, data, self->dataSize);
		pos.node->children[pos.pos + 1] = right;
		pos.node->numElements++;
	}else{
		CBBTreeNode * new = malloc(self->nodeSize);
		unsigned char * newKeys = (unsigned char *)(new + 1);
		unsigned char * newData = newKeys + self->keySize * CB_BTREE_ORDER;
		new->numElements = CB_BTREE_HALF_ORDER;
		pos.node->numElements = CB_BTREE_HALF_ORDER;
		unsigned char * midKey;
		unsigned char * midVal;
		if (pos.pos >= CB_BTREE_HALF_ORDER) {
			if (pos.pos == CB_BTREE_HALF_ORDER) {
				memcpy(newKeys, keys + CB_BTREE_HALF_ORDER * self->keySize, CB_BTREE_HALF_ORDER * self->keySize);
				memcpy(newData, dataElements + CB_BTREE_HALF_ORDER * self->dataSize, CB_BTREE_HALF_ORDER * self->dataSize);
				memcpy(new->children + 1, pos.node->children + CB_BTREE_HALF_ORDER + 1, CB_BTREE_HALF_ORDER * sizeof(*new->children));
				new->children[0] = right;
				midKey = key;
				midVal = data;
			}else{
				if (pos.pos > CB_BTREE_HALF_ORDER + 1){
					memcpy(newKeys, keys + (CB_BTREE_HALF_ORDER + 1) * self->keySize, (pos.pos - CB_BTREE_HALF_ORDER - 1) * self->keySize);
					memcpy(newData, dataElements + (CB_BTREE_HALF_ORDER + 1) * self->dataSize, (pos.pos - CB_BTREE_HALF_ORDER - 1)  * self->dataSize);
				}
				memcpy(newKeys + (pos.pos - CB_BTREE_HALF_ORDER - 1) * self->keySize, key, self->keySize);
				memcpy(newData + (pos.pos - CB_BTREE_HALF_ORDER - 1) * self->dataSize, data, self->dataSize);
				memcpy(newKeys + (pos.pos - CB_BTREE_HALF_ORDER) * self->keySize, keys + pos.pos * self->keySize, (CB_BTREE_ORDER - pos.pos) * self->keySize);
				memcpy(newData + (pos.pos - CB_BTREE_HALF_ORDER) * self->dataSize, dataElements + pos.pos * self->dataSize, (CB_BTREE_ORDER - pos.pos) * self->dataSize); // o 0 i 1 ii 2 iii 3 iv
				memcpy(new->children, pos.node->children + CB_BTREE_HALF_ORDER + 1, (pos.pos - CB_BTREE_HALF_ORDER) * sizeof(*new->children));
				new->children[pos.pos - CB_BTREE_HALF_ORDER] = right;
				if (CB_BTREE_ORDER > pos.pos)
					memcpy(new->children + pos.pos - CB_BTREE_HALF_ORDER + 1, pos.node->children + pos.pos + 1, (CB_BTREE_ORDER - pos.pos) * sizeof(*new->children));
				midKey = keys + CB_BTREE_HALF_ORDER * self->keySize;
				midVal = dataElements + CB_BTREE_HALF_ORDER * self->dataSize;
			}
		}else{
			memcpy(newKeys, keys + CB_BTREE_HALF_ORDER * self->keySize, CB_BTREE_HALF_ORDER * self->keySize);
			memcpy(newData, dataElements + CB_BTREE_HALF_ORDER * self->dataSize, CB_BTREE_HALF_ORDER * self->dataSize);
			memcpy(new->children, pos.node->children + CB_BTREE_HALF_ORDER, (CB_BTREE_HALF_ORDER + 1) * sizeof(*new->children));
			memmove(keys + (pos.pos + 1) * self->keySize, keys + pos.pos * self->keySize, (CB_BTREE_HALF_ORDER - pos.pos) * self->keySize);
			memmove(dataElements + (pos.pos + 1) * self->dataSize, dataElements + pos.pos * self->dataSize, (CB_BTREE_HALF_ORDER - pos.pos) * self->dataSize);
			if (CB_BTREE_HALF_ORDER > 1 + pos.pos)
				memmove(pos.node->children + pos.pos + 2, pos.node->children + pos.pos + 1, (CB_BTREE_HALF_ORDER - pos.pos - 1) * self->dataSize);
			memcpy(keys + pos.pos * self->keySize, key, self->keySize);
			memcpy(dataElements + pos.pos * self->dataSize, data, self->dataSize);
			pos.node->children[pos.pos + 1] = right;
			midKey = keys + CB_BTREE_HALF_ORDER * self->keySize;
			midVal = dataElements + CB_BTREE_HALF_ORDER * self->dataSize;
		}
		if ( ! pos.node->parent) {
			self->root = malloc(self->nodeSize);
			self->root->numElements = 0;
			self->root->parent = NULL;
			pos.node->parent = self->root;
			self->root->children[0] = pos.node;
		}
		new->parent = pos.node->parent;
		CBFindResult res = CBBTreeNodeBinarySearch(pos.node->parent, midKey, self->keySize);
		res.node = pos.node->parent;
		return CBAssociativeArrayInsert(self, midKey, midVal, res, new);
	}
}
CBFindResult CBBTreeNodeBinarySearch(CBBTreeNode * self, unsigned char * key, unsigned char keySize){
	CBFindResult res;
	res.found = 0;
	if ( ! self->numElements) {
		res.pos = 0;
		return res;
	}
	unsigned char left = 0;
	unsigned char right = self->numElements - 1;
	unsigned char * keys = (unsigned char *)(self + 1);
	int cmp;
	while (left <= right) {
		res.pos = (right+left)/2;
		cmp = memcmp(key, keys + res.pos * keySize, keySize);
		if (cmp == 0) {
			res.found = 1;
			break;
		}else if (cmp < 0){
			if ( ! res.pos)
				break;
			right = res.pos - 1;
		}else
			left = res.pos + 1;
	}
	if (cmp > 0)
		res.pos++;
	return res;
}
void CBInitAssociativeArray(CBAssociativeArray * self, unsigned char keySize, unsigned char dataSize){
	self->keySize = keySize;
	self->dataSize = dataSize;
	self->nodeSize = sizeof(*self->root) + (keySize + dataSize) * CB_BTREE_ORDER;
	self->root = malloc(self->nodeSize);
	self->root->parent = NULL;
	self->root->numElements = 0;
	for (unsigned char x = 0; x < CB_BTREE_ORDER + 1; x++)
		self->root->children[x] = NULL;
}

int main(){
	srand(1);
	CBAssociativeArray array;
	CBInitAssociativeArray(&array, 10, 10);
	int size = CB_BTREE_ORDER * (CB_BTREE_ORDER + 2) * 10;;
	unsigned char * keys = malloc(size);
	for (int x = 0; x < size; x++) {
		keys[x] = rand();
	}
	for (int x = 0; x < size; x += 10) {
		CBAssociativeArrayInsert(&array, keys + x, keys + x, CBAssociativeArrayFind(&array, keys + x), NULL);
		for (int y = 0; y <= x; y += 10) {
			if ( ! CBAssociativeArrayFind(&array, keys + y).found) {
				printf("RANDOM FIND FAIL %u - %u\n", y, x);
				return 1;
			}
		}
	}
    return 0;
}

It obviously should not say RANDOM FIND FAIL 240 - 610

[MatthewLM]

cbitcoin now has a logo!

[MatthewLM]

Thanks go towards K. Darien Freeheart and Patrick Levell as the first fuelers of cbitcoin on RocketHub! They will have their names listed as donors on the cbitcoin website. You too can have your name listed from a donation of $15 or more.

http://www.rockethub.com/projects/11976-cbitcoin-developing-bitcoin-s-future