Pages:
Author

Topic: [ANN] cbitcoin 2.0 - A Bitcoin Library in C - page 4. (Read 17227 times)

sr. member
Activity: 420
Merit: 250
November 25, 2012, 07:09:49 AM
#84
is this big and little endian compatible?
legendary
Activity: 1190
Merit: 1004
November 23, 2012, 02:12:37 PM
#83
The makefile works for OSX Mountain Lion. I'm having issues getting cbitcoin to compile on Linux however. I think it is due to the weak linking and -fPIC (Also tried -fpic) is not working.

This is the issue: https://github.com/MatthewLM/cbitcoin/issues/13
legendary
Activity: 1190
Merit: 1004
November 22, 2012, 12:31:28 PM
#82
Hello Mike.

We could have a lengthy debate on whether C or Java is best. The fact is people will disagree on this and never reach agreement. It's something to agree to disagree upon. I personally think Java and C both have their pros and cons and it's OK for people to have their own preference to either. Maybe you'd like to start another topic for discussing C vs Java for bitcoin?

I am fully aware of the security issues to do with bitcoin implementations. Indeed cbitcoin will not implement wallets (people would add that on top as they see fit) or mining (absolutely zero point) but it will implement full validation and SPV nodes. It is important cbitcoin precisely corresponds to the bitcoin protocol. One thing that will be useful to maintain bitcoin implementations is to have some form of bitcoin standard. If people could agree upon a technical document that clearly outlines the protocol, that would be more helpful than reading though an existing implementation and bits of information placed on the bitcoin wiki.

Quote
I've got nothing against people re-implementing Bitcoin for fun

cbitcoin is not for fun.
legendary
Activity: 1526
Merit: 1134
November 22, 2012, 07:55:09 AM
#81
Quote
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.

I'm pretty sure those are principles we can all get behind. The question is why you think re-implementing Bitcoin in C is the best way to achieve that, given that C is known to be prone to various classes of problems (like buffer overflows) that other languages don't have.

For example, MultiBit is a client that processes the block chain much faster than the Satoshi client because it implements the SPV security model. There are optimizations in the work that will accelerate it still further, to the point where syncing with the network should only take a few seconds even if you don't start the client for a long time. MultiBit (and bitcoinj which it's based on) already exist. As far as I know, bitcoinj is the only codebase that implements both SPV and full validation.

So there are already people working towards this goal. You could help them, rather than re-implement Bitcoin from scratch, which is a lot of work to do well.

I share Jeff and Gavins concerns about this thread. I've got nothing against people re-implementing Bitcoin for fun as long as they are extremely conservative with enabling network participation (mining, relaying). I learned programming from my father, but he wasn't a professional so I didn't get any good until I started taking part in open source projects and learning from more experienced developers. I spent my teenager years working on a video game. So, many of us have spent a lot of time on IRC or elsewhere teaching people how Bitcoin works and helping them get started, because that's important.

Despite that, it's important to understand that Bitcoin is not like other open source projects. In most software the worst you can do is write a program that crashes and loses the users work. For Bitcoin, it can result in other people losing large sums of money. In the worst case if a buggy implementation becomes popular, the entire system could be destroyed. I worry a lot about bugs being introduced into the Satoshi client due to refactorings, etc, and the people working on that client are all extremely skilled and have a lot of experience. Even so, we still find serious bugs in each others code during review and testing.

For now the damage potential from cbitcoin is limited because it does not implement a wallet, so people can't store money with it, and it doesn't seem to support mining, so people can't split the chain with it. These things may change in future.

Developers are raising red flags here not because of a concern about competition, but because asking people to fund work on a Bitcoin implementation changes things quite a lot.
legendary
Activity: 1190
Merit: 1004
November 22, 2012, 07:28:37 AM
#80
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
legendary
Activity: 1190
Merit: 1004
November 21, 2012, 12:55:30 PM
#79
cbitcoin now has a logo!

legendary
Activity: 1190
Merit: 1004
November 16, 2012, 04:36:41 PM
#78
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 
#include
#include
#include

#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
legendary
Activity: 1764
Merit: 1002
November 15, 2012, 11:32:10 PM
#77
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://bitcointalksearch.org/topic/m.1034613
legendary
Activity: 1764
Merit: 1002
November 15, 2012, 10:03:28 PM
#76
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.
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
November 15, 2012, 09:35:27 PM
#75
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"

legendary
Activity: 1764
Merit: 1002
November 15, 2012, 09:30:13 PM
#74
MatthewLM was convinced to buy his first Bitcoin only a few months ago.
legendary
Activity: 1596
Merit: 1100
November 15, 2012, 08:59:40 PM
#73
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.

legendary
Activity: 1120
Merit: 1164
November 15, 2012, 05:30:22 PM
#72
Quote
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.

Quote
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%

Quote
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.
legendary
Activity: 1764
Merit: 1002
November 15, 2012, 05:19:38 PM
#71
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.
legendary
Activity: 1904
Merit: 1002
November 15, 2012, 05:13:39 PM
#70
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.
legendary
Activity: 1904
Merit: 1002
November 15, 2012, 05:12:38 PM
#69
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.
legendary
Activity: 1120
Merit: 1164
November 15, 2012, 05:09:48 PM
#68
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.
legendary
Activity: 1190
Merit: 1004
November 15, 2012, 05:08:09 PM
#67
Quote
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).

Quote
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?

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

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

Quote
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.
legendary
Activity: 1904
Merit: 1002
November 15, 2012, 04:49:32 PM
#66
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).
legendary
Activity: 1120
Merit: 1164
November 15, 2012, 04:20:15 PM
#65
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.
Pages:
Jump to: