Bitcoin Forum

Bitcoin => Project Development => Topic started by: MatthewLM on November 09, 2012, 03:01:56 PM



Title: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on November 09, 2012, 03:01:56 PM
deleted


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: crazy_rabbit on November 09, 2012, 05:02:28 PM
Very cool, will definitely check it out. It would be interesting to have the software allow for multiple chains- a plurality of Bitcoins. A world filled with various chains is quite an exciting idea.

None the less, I will be check this out for sure!

+1


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 05:05:46 PM
At the moment I'm looking to provide support for the testnet chain. The software could be modified to support other chains and maybe the library in the future can be made to be more configurable for custom block chains.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: ArticMine on November 09, 2012, 05:08:09 PM
With respect to the licensing it appears to me that if one wants to use the GPL v3 but with additional permissions then under section 7 of GPLv3 one can add additional permissions for a work. For legal advice, for a FLOSS project, the place I would suggest is the Software Freedom Law Center. http://www.softwarefreedom.org (http://www.softwarefreedom.org) They have years of expertise on FLOSS licensing.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 05:13:51 PM
With respect to the licensing it appears to me that if one wants to use the GPL v3 but with additional permissions then under section 7 of GPLv3 one can add additional permissions for a work. For legal advice, for a FLOSS project, the place I would suggest is the Software Freedom Law Center. http://www.softwarefreedom.org (http://www.softwarefreedom.org) They have years of expertise on FLOSS licensing.

Thanks, I'll check this out.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: ShadowOfHarbringer on November 09, 2012, 05:56:06 PM
With respect to the licensing it appears to me that if one wants to use the GPL v3 but with additional permissions then under section 7 of GPLv3 one can add additional permissions for a work. For legal advice, for a FLOSS project, the place I would suggest is the Software Freedom Law Center. http://www.softwarefreedom.org (http://www.softwarefreedom.org) They have years of expertise on FLOSS licensing.

If he is the only author & owner of the code, then he can license the code under as many licenses as he can, including GPLv3/v2, BSD, MIT and closed commercial licenses.

The problem only comes when/if more people join the project.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: WikileaksDude on November 09, 2012, 05:56:25 PM
This is indeed very important to bitcoin.

Just waiting for my money to hit mtgox and use this friday promoting to get some coins.. I sure will be donating some!

Keep it strong, im sure the community will help.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 05:58:43 PM
This is indeed very important to bitcoin.

Just waiting for my money to hit mtgox and use this friday promoting to get some coins.. I sure will be donating some!

That will be very much appreciated.  :)


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: ShadowOfHarbringer on November 09, 2012, 06:40:43 PM
This is indeed very important to bitcoin.

Just waiting for my money to hit mtgox and use this friday promoting to get some coins.. I sure will be donating some!

That will be very much appreciated.  :)

I will also donate, just waiting for my client to sync with the net.

You know, as it was said above - this project holds tremendous importance when it comes to Bitcoin future, so it probably wouldn't hurt to try kickstarter or something to pay for your time.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 06:56:05 PM
I will also donate, just waiting for my client to sync with the net.

You know, as it was said above - this project holds tremendous importance when it comes to Bitcoin future, so it probably wouldn't hurt to try kickstarter or something to pay for your time.

Thanks for the donation.

Would people actually want to donate using fiat moneys? I could set something up if that is the case. And, as I've mentioned, I do not need donations to pay for my time. In fact, I'll not be taking money out, but be putting money in. I cannot promise this will remain the case but I have planned to put £4,000 into the project.

First I want to see how much voluntary contributions I can gather. It will be great if I am able to collaborate with the university with this. Hopefully I'll have more information on that next week.

It's vital that I have other people work on the project, not only to speed things along but so others can check what I've done. I might make mistakes and misunderstand some things that others can pick up on and vice versa.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: jgarzik on November 09, 2012, 08:04:02 PM
If this was just another client, great!  We like alt implementations.  The more clients, the healthier the ecosystem.

But marketing this as "the route to bitcoin's future" is a bit much.

There are already several other node implementations out there, including C implementations: ufasoft-coin (https://bitcointalk.org/index.php?topic=58821.0), bitsofproof (https://bitcointalk.org/index.php?topic=122013.0), and pynode (https://github.com/jgarzik/pynode/).  Not to mention SPV clients like BitcoinJ (http://code.google.com/p/bitcoinj/), Electrum (http://electrum.ecdsa.org/) and picocoin (https://github.com/jgarzik/picocoin/).

The licenses are more liberal than GPLv3 as well.



Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 08:10:09 PM
This is not a client, it is a library. And I'm replacing the GPLv3 with either a dual license or the GPLv3 with exceptions whichever turns out to best. I want to remove some of the nasty bits of GPLv3 as I admit that there are nasty bits.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: jgarzik on November 09, 2012, 08:32:54 PM
This is not a client, it is a library. And I'm replacing the GPLv3 with either a dual license or the GPLv3 with exceptions whichever turns out to best. I want to remove some of the nasty bits of GPLv3 as I admit that there are nasty bits.

If you look at the links provided, you will see libraries used by said clients.



Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 08:38:26 PM
Well, we will just have to see what becomes the future of bitcoin wont we?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: ShadowOfHarbringer on November 09, 2012, 09:19:50 PM
This is not a client, it is a library. And I'm replacing the GPLv3 with either a dual license or the GPLv3 with exceptions whichever turns out to best. I want to remove some of the nasty bits of GPLv3 as I admit that there are nasty bits.

As the only author, you can license under as many licenses as you want, simultaneously.

KDE does/did something like that. They licensed under both GPL and commercial license (for money) in case some buyer didn't like the restrictions of GPL.
You can do that, but it will require every other contributor than yourself (if there are/will be any) to completely pass their copyrights to you and give you sole property of their code. Since IANAL and this may be little legally complicated - you would need to do some research on topic how the KDE guys did it exactly.

Mozilla also licenses Firefox under GPL,MPL and LGPL.

----
And BTW, the "nasty bits" of GPLv3 are there for a reason - because big companies usually like to play nasty and generally fuck over everybody (including OSS devs) for profit.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Joshwaa on November 09, 2012, 09:24:11 PM
I like where this is going. Watching this one.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 09:25:45 PM
By "nasty" I did not mean confusing or awkward but because I do not think there is a good reason for them.

And I will require all copyrights be passed to me, though the licenses will be irrevocable, so that if you receive a copy the license applies to that copy even if I decide to change the license. So it's not a problem. If I decide to change the license to something stupid then people can just fork the project, but never-mind as I will continue to maintain the project as open-source.

Software licenses do confuse me and maybe I do not know what I am talking about here...  :)


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: jimbobway on November 09, 2012, 09:33:11 PM
I think you are doing great work for Bitcoin.

I do have a question though.  Amir of bitcoinconsultancy also created a library called libbitcoin and also claimed that it would be the future of bitcoin.  I don't think he did as good as job as you though since his library is very dependant on many other libraries while yours is not.  It looks, though, as if Amir has left bitcoin since we have not heard from him for a while.

What kind of assurances can you give us, if any, that cbitcoin will be the future of bitcoin?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 09:45:32 PM
I was intrigued by libbitcoin. If I was going to work on another library and not create my own, it would most likely have been that. Unfortunately I don't think libbitcoin is going to go anywhere from here unless someone else picks it up.

Will the same thing happen to cbitcoin, as it does with many other libraries? No it will not. The reason is because I'm not developing the library as an end in itself. I will be using this library for the business idea I have. It's hugely unlikely that I'll suddenly decide to forget all my plans and not go ahead with it. I see great potential in the idea I have, so I will continue to put many resources into cbitcoin. And also, I don't want to see all my work I've done so far go to waste either.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: ShadowOfHarbringer on November 09, 2012, 09:53:01 PM
It's hugely unlikely that I'll suddenly decide to forget all my plans and not go ahead with it.

"The route to Bitcoin's future" sounds very bold. It is a bold promise. With title like that people will expect (quite reasonably ?) the best of the best, which automatically generates a pressure on you.

Many people can't take such pressure and quit after some time. I hope you are not one of these people and you can live up to your promises.

EDIT:
I think that one of the reasons Linux kernel succeeded was because nobody expected it to grow so big, so there was no pressure on the devs to "deliver", so they could work undisturbed and do what they like.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 10:06:43 PM
Yes, there is a lot of pressure on me, but that cannot be fixed by leaving the project. The pressure is on to make this a success for me and everyone else. I cannot do that by quitting. That is simply unthinkable. The pressure is not to quit under any circumstances and to keep going.

And "future of bitcoin" is in reality subjective. Different people will have different ideas for the direction of bitcoin. Obviously I think I am going in the right direction but others may disagree. But I can say with almost absolute certainty I will continue on this project and release cbitcoin 2.0. It will happen a lot faster with donations though.  ;)


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: ShadowOfHarbringer on November 09, 2012, 10:14:12 PM
Yes, there is a lot of pressure on me, but that cannot be fixed by leaving the project. The pressure is on to make this a success for me and everyone else. I cannot do that by quitting. That is simply unthinkable. The pressure is not to quit under any circumstances and to keep going.

And "future of bitcoin" is in reality subjective. Different people will have different ideas for the direction of bitcoin. Obviously I think I am going in the right direction but others may disagree. But I can say with almost absolute certainty I will continue on this project and release cbitcoin 2.0. It will happen a lot faster with donations though.  ;)

The easy solution was simply to remove the unnecessary boldness from the title.

"Not-drawing-attention-and-simply-doing-good-job" way was always easier for me, but if you like to do it the harder way, then by all means - proceed as you like.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 10:17:28 PM
Keeping a low-profile does not help me receive contributions from other people. Contributions not only including donations and code but suggestions, criticisms etc.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: teste on November 09, 2012, 11:18:29 PM
MatthewLM,

I think you should create account on Gittip to receive donations, see: https://www.gittip.com/about/
They probably have plans to support Bitcoin, see: https://github.com/whit537/www.gittip.com/issues/14


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 09, 2012, 11:27:17 PM
MatthewLM,

I think you should create account on Gittip to receive donations, see: https://www.gittip.com/about/
They probably have plans to support Bitcoin, see: https://github.com/whit537/www.gittip.com/issues/14

Thanks for the suggestion, though whatever service I use, it should be suited for the fact I have a UK bank account. I'll take a further look at fiat methods of donations tomorrow.

I'm also looking for a suitable noSQL database for block-chain storage, so I'll hopefully sort that out tomorrow: http://stackoverflow.com/questions/13317443/an-alternative-to-leveldb-that-allows-you-to-read-a-subsection-of-the-data-recor But for now, I'm off to bed  ;)


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: jimbobway on November 09, 2012, 11:55:38 PM
Not sure if you know this but the creator of Armory, etothepi, was able to raise over $4000 for this bitcoin client using rockethub.com.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 13, 2012, 02:09:10 PM
Well all together I've found these websites which provide the type of thing I'd want:

http://www.rockethub.com/ (Thanks jimbobway)
http://www.kickstarter.com/
http://www.crowdfunder.co.uk/
http://www.indiegogo.com/
http://www.chipin.com/
http://www.gofundme.com/

I'll have to carefully go through them all to determine what I want. If anyone has any comments about them, please post them.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: adamstgBit on November 13, 2012, 04:31:30 PM
is this a bitcoin fork?
whats different about this fork?

sry OP is one huge wall of text, no time...


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 13, 2012, 04:45:57 PM
No it is not a fork, it is a complete re-implementation of bitcoin, in the C programming language, as a software library.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: adamstgBit on November 13, 2012, 05:01:30 PM
No it is not a fork, it is a complete re-implementation of bitcoin, in the C programming language, as a software library.

would cbitcoin start its own blockchain?

or is it just a re-implementation of bitcoind, for cleaner code, and would use the same blockchain as bitcoin?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 13, 2012, 05:08:29 PM
It uses the same block-chain as bitcoin. At the moment it has code for the production netwok but I plan to add testnet support also and maybe more configurable features for new chains in the future as well.

The code should be cleaner, yes, and have more documentation. On top of that, the fact my code is a library will make it more useful than bitcoind, it will have fewer and more configurable dependencies and will hopefully be more efficient, but that is yet to be judged.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: adamstgBit on November 13, 2012, 05:12:44 PM
It uses the same block-chain as bitcoin. At the moment it has code for the production netwok but I plan to add testnet support also and maybe more configurable features for new chains in the future as well.

The code should be cleaner, yes, and have more documentation. On top of that, the fact my code is a library will make it more useful than bitcoind, it will have fewer and more configurable dependencies and will hopefully be more efficient, but that is yet to be judged.

+21 million  ;)

I will donate a small amount sometime soon

Thank you!


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 13, 2012, 05:15:53 PM
+21 million  ;)

I will donate a small amount sometime soon

Thank you!

And thank you too.  :)


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 13, 2012, 09:13:23 PM
Well I'm undecided between http://www.rockethub.com/ and http://www.indiegogo.com/.

The fee structure is reasonably similar:

http://rockethub.com

Reached goal = 4%
Failed goal = 8%
Transaction fee = 4%

http://indiegogo.com

Reached goal = 4%
Failed goal = 9%
Transaction fee = 3%
Plus $25 bank transfer fee.

I personally like the interface of indiegogo more. What do others think?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: hazek on November 13, 2012, 09:39:52 PM
Just opening up both homepages I'd say I like the Indiegogo interface better but I like Rockethub more because of the activity ticker. But this is purely superficially speaking and I think I'd try to figure out which one is more popular and go with that one.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 13, 2012, 10:21:00 PM
I'm going to decide tomorrow. In the meantime I'm going to leave a poll up so people can give their opinion.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: ShadowOfHarbringer on November 14, 2012, 09:15:37 AM
#MatthewLM:

Hey Matthew, does your client allow user to risk re-sending "fresh" coins without a fee, or do I have to fork cbitcoin the same as i forked mainline client ?

EDIT:
By "fresh" coins i mean just received coins but having 6-7 confirmations. Official client won't allow to re send these, so this is the reason i created my fork.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 14, 2012, 09:52:33 AM
cbitcoin is not a client, nor will it be. When it is finished you could use it to create your own client which follows any behaviour you'd like as long as it works with the protocol. The full node implementation will provide the block-chain validation and you will be able to register events for incoming transactions which match addresses as well as for when transactions are found in blocks I've not got to implementing any of that yet.

It's really hard selecting which funding platform to use. There are advantages and disadvantages to both platforms it seems. I don't like indiegogo's checkout system which annoys you about paypal... I think I'll use rockethub. Any ideas for rewards? There's not much I can do. I could create a "Contributors" webpage on cbitcoin.com with a "Financial Contributors" or "Sponsors" section where I can place people's and business names with website links, logos and/or bitcoin addresses.

Perhaps there could be gold/silver/bronze sponsorship?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 14, 2012, 08:13:27 PM
EDIT:
By "fresh" coins i mean just received coins but having 6-7 confirmations. Official client won't allow to re send these, so this is the reason i created my fork.

So the satsohi client doesn't allow you to make transactions from outputs just found, even when they have 6 confirmations???

I'll get the fundraiser page up probably tomorrow...

I've been working on a B-Tree implementation for indexing. If anyone would like to help, the deletion algorithm need finishing and testing: https://github.com/MatthewLM/cbitcoin/blob/master/src/CBAssociativeArray.c#L154

And I'm following this but I can figure it out in my head: http://www.scribd.com/doc/18210/B-TREE-TUTORIAL-PPT


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: notme on November 14, 2012, 08:24:25 PM
EDIT:
By "fresh" coins i mean just received coins but having 6-7 confirmations. Official client won't allow to re send these, so this is the reason i created my fork.

So the satsohi client doesn't allow you to make transactions from outputs just found, even when they have 6 confirmations???

I'll get the fundraiser page up probably tomorrow...

I've been working on a B-Tree implementation for indexing. If anyone would like to help, the deletion algorithm need finishing and testing: https://github.com/MatthewLM/cbitcoin/blob/master/src/CBAssociativeArray.c#L154

And I'm following this but I can figure it out in my head: http://www.scribd.com/doc/18210/B-TREE-TUTORIAL-PPT

I'm not sure what he is talking about unless maybe it's newly generated coins, which need 120 confirmations.  With regular transactions, I can respend received coins after 1 confirmation.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 14, 2012, 08:28:11 PM
I have the coinbase maturity set at 100 and not at 120.

I'm going to start posting issues on the repository. It would be a good place to look for anyone that wishes to contribute: https://github.com/MatthewLM/cbitcoin/issues?page=1&state=open

As well as reading the README of-course: https://github.com/MatthewLM/cbitcoin/blob/master/README.md#making-a-contribution


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Pieter Wuille on November 14, 2012, 09:42:11 PM
I have the coinbase maturity set at 100 and not at 120.

To warn you against a potential misconception (it's bitten me before...), coinbase outputs are valid to spend as of 101 confirmations (i.e. a difference of 100 between the height of the coinbase and the height of the transaction that spends it), but to be safe in the face of reorganisations, the reference client allows spending as of 120.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 14, 2012, 09:53:18 PM
Don't worry, I have implemented it as 101 confirmations. Obviously the block with the coinbase is included as a confirmation and I meant 101 confirmations. I did spend some time staring at it to make sure I did implement it correctly. Others might want to check again: https://github.com/MatthewLM/cbitcoin/blob/7ff4abcff40221ac0eee7a32b12b4509ee4a9f56/src/CBFullValidator.c#L450.

If we have a coinbase in block 0, we see by my code that the coinbase can be spent at block 100 (100 - 0 == 100) which is at the maturity and 101 confirmations, therefore it is correct.

I didn't know about the 120 behaviour, though obviously that has nothing to do with the block validation code so I've not missed anything there.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: capsqrl on November 14, 2012, 11:03:07 PM
KDE does/did something like that. They licensed under both GPL and commercial license (for money) in case some buyer didn't like the restrictions of GPL.

No, KDE is fully open source under various licenses, and does not sell proprietary licenses. You're thinking of Qt, which KDE happens to use, but does not manage or produce.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: jgarzik on November 15, 2012, 12:49:52 AM
EDIT:
By "fresh" coins i mean just received coins but having 6-7 confirmations. Official client won't allow to re send these, so this is the reason i created my fork.

So the satsohi client doesn't allow you to make transactions from outputs just found, even when they have 6 confirmations???

Of course it does.  You may make transactions from any output with at least one confirmation...  except for newly generated blocks, as another poster noted.

Generated blocks are not considered "mature" and spendable until 120 confirmations.



Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 10:12:37 AM
Yes and ShadowOfHarbringer was most likely speaking of the 120 confirmation requirement. The answer to the original question is therefore that cbitcoin will not have this 120 confirmation restriction since cbitcoin will not restrict what transactions you can produce and broadcast. You can use it to create any transactions you want. It doesn't mean all transactions will be accepted by the network and cbitcoin will include checks on received relayed transactions.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Mike Hearn on November 15, 2012, 10:42:43 AM
If we have a coinbase in block 0, we see by my code that the coinbase can be spent at block 100 (100 - 0 == 100) which is at the maturity and 101 confirmations, therefore it is correct.

The coinbase in block zero is not spendable. If you allow it, potentially one day Satoshi could split the network.

It's details like this which make reimplementing Bitcoin so dangerous.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 10:50:09 AM
Yes I know that. I was ignoring everything else and using the number 0 to demonstrate the mathematics. Imagine a different number if you want.

The genesis coinbase is not added to the unspent output index in cbitcoin so it cannot be spent. I made a note about it here: https://github.com/MatthewLM/cbitcoin/blob/master/src/CBFullValidator.c#L780

I've followed the validation rules carefully but indeed something might be missed which is why testing is important and I'd like to get others to look through the code.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 12:39:05 PM
If anyone wants to be listed as a donor or a business sponsor then you can email me and I can give a bitcoin address: http://cbitcoin.com/donors.html

Anyone who has already donated more than $15 in equivalent bitcoins can email me proof that they own addresses spent from in the donation transactions, if they want to be included in the list. You can do that by signing your information to be included on the list with a bitcoin address which acted as the source of the transaction. Email me questions if you need help.

The categories are:

Business Sponsor: For $1000 or more you can have your business logo and weblink listed on the contributors page and the homepage.
Gold Donor: For $500 or more you can have your personal name or business name with an optional weblink listed on the contributors page.
Silver Donor: For $150 or more you can have your personal name or business name with an optional weblink listed on the contributors page.
Bronze Donor: For $50 or more you can have your personal name or business name with an optional weblink listed on the contributors page.
Other Donor: For $15 or more you can have your personal name listed on the contributors page.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 02:38:52 PM
I've now added the RocketHub page: http://www.rockethub.com/projects/11976-cbitcoin-developing-bitcoin-s-future

While I'm looking to raise over $6000 ideally, I picked the more modest $2000 goal as I think that should be reachable. I'd be very grateful for any donations. Using RocketHub you can become a donor or business sponsor.

I've also contacted a designer in regards to the logo. I should hopefully have that sorted within a couple of weeks. That will be a small cost.

Also please share the project on as many websites pages as you can. That much is free to do.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: jgarzik on November 15, 2012, 03:49:47 PM
Yes and ShadowOfHarbringer was most likely speaking of the 120 confirmation requirement. The answer to the original question is therefore that cbitcoin will not have this 120 confirmation restriction since cbitcoin will not restrict what transactions you can produce and broadcast. You can use it to create any transactions you want. It doesn't mean all transactions will be accepted by the network and cbitcoin will include checks on received relayed transactions.

You have just admitted that you are creating a non-compliant codebase, which will create invalid transactions.

In that case, maybe people should redirect their donations and attention elsewhere.

Other bitcoin clients include this requirement because it is....  a requirement.



Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 04:58:59 PM
So now you are telling me that the coinbase maturity is not 100 (ie. 101 confirmations)?

I've read the code. The code is lying to me? It's changed?

Explain to me exactly how cbitcoin is non-compliant with the bitcoin protocol.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Dusty on November 15, 2012, 05:26:19 PM
Quote
The coinbase in block zero is not spendable. If you allow it, potentially one day Satoshi could split the network.
Yes I know that.
I'm interested in knowing the details on why this is the case: someone is kind enough to enlighten me?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 05:39:37 PM
Quote
The coinbase in block zero is not spendable. If you allow it, potentially one day Satoshi could split the network.
Yes I know that.
I'm interested in knowing the details on why this is the case: someone is kind enough to enlighten me?

I don't know either. All I know is that it is that way for whatever reason.

Well it looks like I'll be able to get a logo done for £60 (~$95) upfront for initial designs (minimum 10). I'll then be able to post the designs on here to receive feedback. After deciding on a good design, for another £60 (~$95) the logo will be adjusted and finalised.

So that will be a cost of £120 (~$190).


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: notme on November 15, 2012, 06:19:09 PM
So now you are telling me that the coinbase maturity is not 100 (ie. 101 confirmations)?

I've read the code. The code is lying to me? It's changed?

Explain to me exactly how cbitcoin is non-compliant with the bitcoin protocol.

I think he's referring to it allowing invalid transactions to be broadcast.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 06:39:14 PM
So now you are telling me that the coinbase maturity is not 100 (ie. 101 confirmations)?

I've read the code. The code is lying to me? It's changed?

Explain to me exactly how cbitcoin is non-compliant with the bitcoin protocol.

I think he's referring to it allowing invalid transactions to be broadcast.

That doesn't mean cbitcoin is non-compliant with the bitcoin protocol. So it is unfair to say:

Quote
In that case, maybe people should redirect their donations and attention elsewhere.

cbitcoin is a bitcoin library and not a bitcoin client. It will give developers the ability to broadcast transactions and it is their responsibility to ensure the transactions are produced correctly. And this is false:

Quote
will create invalid transactions.

Not "will". The correct word is "can" but obviously there is little good reason why someone would want to create duff transactions.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Gavin Andresen on November 15, 2012, 07:14:03 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: ShadowOfHarbringer on November 15, 2012, 07:31:29 PM
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

+ 10 ^ n, where n -> ∞


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 07:55:09 PM
Quote
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 ...).

The "software-people-other-than-myself-are-going-to-use" I've successfully completed are iPhone and Android apps which I've developed over a couple of years. Also I've done some web-development (See for example: http://www.thelibertyportal.com/#articles) and I'm currently also working on a facebook app (but that's not finished).

You can see the android apps here: https://play.google.com/store/apps/developer?id=Matthew+Mitchell&hl=en_GB
And the iOS apps: https://itunes.apple.com/sa/artist/matthew-mitchell/id398617356 (Open)

Re-implementing bitcoin is obviously a major challenge compared to mobile apps. That doesn't mean I cannot do this though. I'm getting there and I'm getting there at a reasonable pace.

I will implement the makefile. Others said they would help with that but since no one has I'll do it myself but I'll do that in my own time (I've got a long list of things to do).

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

So it's a good idea not to improve software? cbitcoin 1.0 was OK but it was limited. I changed my vision for the project into something much more advanced. I do not see why that should destroy confidence.

But if anyone does not trust me, then that's fine, just wait a while and I'll prove you wrong. If there is one good thing about being criticised, it is that it becomes so much better when you make it work. I know what that feels like.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: hazek on November 15, 2012, 08:25:29 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: notme on November 15, 2012, 08:44:34 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 08:53:38 PM
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.  :D

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


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Peter Todd on November 15, 2012, 08:58:06 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: hazek on November 15, 2012, 09:05:34 PM
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?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Peter Todd on November 15, 2012, 09:20:15 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: notme on November 15, 2012, 09:49:32 PM
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).


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 15, 2012, 10:08:09 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Peter Todd on November 15, 2012, 10:09:48 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: notme on November 15, 2012, 10:12:38 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: notme on November 15, 2012, 10:13:39 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: cypherdoc on November 15, 2012, 10:19:38 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Peter Todd on November 15, 2012, 10:30:22 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: jgarzik on November 16, 2012, 01:59:40 AM
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.



Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: cypherdoc on November 16, 2012, 02:30:13 AM
MatthewLM was convinced to buy his first Bitcoin only a few months ago.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: adamstgBit on November 16, 2012, 02:35:27 AM
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"



Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: cypherdoc on November 16, 2012, 03:03:28 AM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: cypherdoc on November 16, 2012, 04:32:10 AM
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


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 16, 2012, 09:36:41 PM
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


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 21, 2012, 05:55:30 PM
cbitcoin now has a logo!

http://cbitcoin.com/logo.png


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 22, 2012, 12:28:37 PM
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


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Mike Hearn on November 22, 2012, 12:55:09 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 22, 2012, 05:31:28 PM
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.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 23, 2012, 07:12:37 PM
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


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: paulie_w on November 25, 2012, 12:09:49 PM
is this big and little endian compatible?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 25, 2012, 12:13:34 PM
is this big and little endian compatible?

Yes it is, or at least that is the way it is designed to be. It's only been tested on a little-endian machine so feel free to try it out on a big-endian machine.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 30, 2012, 12:23:00 AM
I have completed the storage component for cbitcoin: https://github.com/MatthewLM/cbitcoin/tree/master/dependencies/storage

I will now complete the full validator, before I have no choice but to finally fix the CBNetworkCommunicator: https://github.com/MatthewLM/cbitcoin/issues/9

Building on Linux Mint 13 with the makefile still fails. If someone can get the build system to work for linux please submit a fix: https://github.com/MatthewLM/cbitcoin/issues/13


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on November 30, 2012, 01:32:52 AM
Take a look at strcpy(), it includes a termination character when copying.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: jgarzik on November 30, 2012, 01:57:18 AM
Take a look at strcpy(), it includes a termination character when copying.

Edit: correct.



Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Elxiliath on December 04, 2012, 06:22:08 PM
Your project seems like it could improve some aspects of the bitcoin client/network.  I may not understand it completely, but I see a lot of potential.  In reference to using multiple block chains, if this client software supports that, couldn't we see potential competition between different chains then on the network.  Like coins from block A are more then block B or would it still be the same essentially?  Would one who has these coins have them combined or would they be split across the two chains when conducting transactions and not able to send them from A to B?


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on December 04, 2012, 06:32:10 PM
Hello. cbitcoin will at first be designed to work with the bitcoin production and test chains. If someone made a separate chain it would be incompatible with other chains. In the future I may support more customisability for technologies based upon bitcoin, which could use their own chain. That is not a priority right now.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: Elxiliath on December 04, 2012, 06:36:29 PM
Thank you for the quick reply, I understand more what was your intent now.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on December 19, 2012, 10:39:22 PM
Good news everyone! http://www.youtube.com/watch?v=1D1cap6yETA

I have now got the basic unit tests working for the full validator. This does not yet test various parts of the validator such as output spending, but it shows that the database system is working nicely. Next stop is to implement the full range of tests for the full validator. The CBNetworkCommunicator is still not working... I'll get to that eventually but first a lot of the old code needs to be updated to incorporate some new features.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on January 01, 2013, 10:15:26 PM
The hamming codes for storage are working. The problem is that they slow down the IO quite considerably. A storage system not using the hamming codes should be used instead for speed. Servers shouldn't need the hamming codes since server hardware is supposed to be highly resistant to data corruption.

Now I just need to test the full validator properly. I do not have the mined test blocks so I'll have to modify the code to allow for disabling the proof of work check.

There were some people that requested I gave them an option to donate using a crowd-funding website, since they did not want to donate in bitcoin. I set up a page because of that but only two people have donated. Do not forget that you can donate via debit/credit card here: http://www.rockethub.com/projects/11976-cbitcoin-developing-bitcoin-s-future and as a reward you can have your name or your business listed on the cbitcoin website.

Thanks.


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: MatthewLM on January 16, 2013, 03:07:58 PM
If anyone wishes to help, the best thing that can be done presently is to test the validation code. I already have many tests which pass, but much scrutinisation is needed for the block-chain validation code: https://github.com/MatthewLM/cbitcoin/blob/master/test/testCBFullValidator.c


Title: Re: [ANN] cbitcoin 2.0 - The Route to Bitcoin's Future
Post by: CIYAM on January 16, 2013, 04:26:55 PM
Matthew - although I am a big supporter of your project (and you are welcome to set up a Project on http://ciyam.org/open for your venture - and if you do so I will personally donate 1 BTC towards it) I think that to get better "cred" you should consider changing the title of this thread (perhaps get rid of the "Route to Bitcoin's Future part") as I think this could really hinder your otherwise very admirable idea.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on January 16, 2013, 04:39:44 PM
OK, since you aren't the only one to complain, I've changed the title.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: finkleshnorts on January 24, 2013, 05:39:49 PM
Props on your progress Matthew, and I applaud your listening ear. I've been keeping an eye on this project :)


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: Peter Todd on January 24, 2013, 05:51:02 PM
OK, since you aren't the only one to complain, I've changed the title.

Thanks, it's a much better title!


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on January 29, 2013, 02:16:05 PM
Props on your progress Matthew, and I applaud your listening ear. I've been keeping an eye on this project :)

Thanks. I've been ill over the last few days so I haven't made any progress in that time and I've got a lot of other work to do, but I'll try my best to continue at a reasonable pace from here onwards.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 04, 2013, 03:43:56 PM
cbitcoin now builds fully (In it's current state) on OSX and Linux Mint (tested).

To build yourself and run the tests do this:

Code:
git clone https://github.com/MatthewLM/cbitcoin.git
cd cbitcoin
./configure
make test


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: GMD1987 on February 04, 2013, 06:19:03 PM
MatthewLM,
On Linux crunchbang 3.2.0-0.bpo.4-686-pae #1 SMP Debian 3.2.35-2~bpo60+1 i686 GNU/Linux, cloned and ran ./configure && make test.  Error on openssl libs, apt-get installed libssl-dev zlib1g-dev, tried again but got the following for dependencies/random/CBRand.c
dependencies/random/CBRand.c: In function ‘CBNewSecureRandomGenerator’:
dependencies/random/CBRand.c:33: error: cast from pointer to integer of different size
dependencies/random/CBRand.c: In function ‘CBSecureRandomSeed’:
dependencies/random/CBRand.c:38: error: cast to pointer from integer of different size
dependencies/random/CBRand.c: In function ‘CBRandomSeed’:
dependencies/random/CBRand.c:41: error: cast to pointer from integer of different size
dependencies/random/CBRand.c:42: error: cast to pointer from integer of different size
dependencies/random/CBRand.c: In function ‘CBSecureRandomInteger’:
dependencies/random/CBRand.c:45: error: cast to pointer from integer of different size
dependencies/random/CBRand.c:45: error: cast to pointer from integer of different size
dependencies/random/CBRand.c:47: error: cast to pointer from integer of different size
dependencies/random/CBRand.c: In function ‘CBFreeSecureRandomGenerator’:
dependencies/random/CBRand.c:51: error: cast to pointer from integer of different size

Looking at the code, uint64_t was used (and designed for this sort of error, no?)
bool CBNewSecureRandomGenerator(uint64_t * gen){
        *gen = (uint64_t)malloc(32);
        return *gen;
}

Do you know what's going on here?  I'm pretty sure the cast it's referring to is in the assignment.  I think this was initially a warning converted to an error and just turning off pedantic would solve it but would be antithetical to a make test  :D


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 04, 2013, 07:20:19 PM
Hi GMD1987. Thanks for trying it out. I make all warnings into errors to help spot problems (warnings easily go unnoticed otherwise). I didn't get this since I'm using 64-bit. I'm assuming the correct way to suppress this would be to use "-Wno-pointer-to-int-cast" so I'll add this to the makefile now.

testCBNetworkCommunicator is sometimes problematic. I'm going to go through all the tests and run them with valgrind to detect any problems I've missed so far.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: notme on February 04, 2013, 07:27:36 PM
Hi GMD1987. Thanks for trying it out. I make all warnings into errors to help spot problems (warnings easily go unnoticed otherwise). I didn't get this since I'm using 64-bit. I'm assuming the correct way to suppress this would be to use "-Wno-pointer-to-int-cast" so I'll add this to the makefile now.

testCBNetworkCommunicator is sometimes problematic. I'm going to go through all the tests and run them with valgrind to detect any problems I've missed so far.

I don't think that code is doing what you think it is doing unless you are trying to do something very tricky.  If that is the case, you should document it with a few comments.

Do you really intend to convert the newly allocated pointer to an integer and then return it as a boolean?


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: davout on February 04, 2013, 07:30:25 PM
@MatthewLM
I think the work you're doing is awesome and I thank you for putting your skill and intelligence at work for the common good.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 04, 2013, 07:33:41 PM
Do you really intend to convert the newly allocated pointer to an integer and then return it as a boolean?

Yes, believe it or not. I was in two minds as to whether or not this is a good idea or not, but for the dependencies I've used uint64_t instead of void * so that it is friendly with integer identifiers (These function prototypes are designed so that they can be implemented in different ways). But now I'm closer to using void * instead. What do others think?

@MatthewLM
I think the work you're doing is awesome and I thank you for putting your skill and intelligence at work for the common good.

Thank you.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 04, 2013, 11:18:55 PM
These valgrind errors I'm getting are driving me mad:

Code:
==1886== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==1886==    at 0x4E412CC: send (send.c:33)
==1886==    by 0x54881B0: CBSocketSend (CBLibEventSockets.c:287)
==1886==    by 0x506953D: CBNetworkCommunicatorOnCanSend (CBNetworkCommunicator.c:459)
==1886==    by 0x5487F43: CBCanSend (CBLibEventSockets.c:235)
==1886==    by 0x663454B: event_base_loop (event.c:1346)
==1886==    by 0x5487B29: CBStartEventLoop (CBLibEventSockets.c:154)
==1886==    by 0x4E39E99: start_thread (pthread_create.c:308)
==1886==  Address 0x6f69774 is 20 bytes inside a block of size 24 alloc'd
==1886==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1886==    by 0x506903B: CBNetworkCommunicatorOnCanSend (CBNetworkCommunicator.c:394)
==1886==    by 0x5487F43: CBCanSend (CBLibEventSockets.c:235)
==1886==    by 0x663454B: event_base_loop (event.c:1346)
==1886==    by 0x5487B29: CBStartEventLoop (CBLibEventSockets.c:154)
==1886==    by 0x4E39E99: start_thread (pthread_create.c:308)
==1886==  Uninitialised value was created by a heap allocation
==1886==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1886==    by 0x5067E55: CBNewNetworkCommunicator (CBNetworkCommunicator.c:30)
==1886==    by 0x4022C2: main (testCBNetworkCommunicator.c:286)
==1886==
==1886== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==1886==    at 0x4E412CC: send (send.c:33)
==1886==    by 0x54881B0: CBSocketSend (CBLibEventSockets.c:287)
==1886==    by 0x5069684: CBNetworkCommunicatorOnCanSend (CBNetworkCommunicator.c:480)
==1886==    by 0x5487F43: CBCanSend (CBLibEventSockets.c:235)
==1886==    by 0x663454B: event_base_loop (event.c:1346)
==1886==    by 0x5487B29: CBStartEventLoop (CBLibEventSockets.c:154)
==1886==    by 0x4E39E99: start_thread (pthread_create.c:308)
==1886==  Address 0x6f6918a is 106 bytes inside a block of size 110 alloc'd
==1886==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1886==    by 0x5061449: CBInitByteArrayOfSize (CBByteArray.c:133)
==1886==    by 0x5061088: CBNewByteArrayOfSize (CBByteArray.c:48)
==1886==    by 0x506C433: CBNetworkCommunicatorSendMessage (CBNetworkCommunicator.c:1307)
==1886==    by 0x506882C: CBNetworkCommunicatorDidConnect (CBNetworkCommunicator.c:217)
==1886==    by 0x5487E01: CBDidConnect (CBLibEventSockets.c:210)
==1886==    by 0x663454B: event_base_loop (event.c:1346)
==1886==    by 0x5487B29: CBStartEventLoop (CBLibEventSockets.c:154)
==1886==    by 0x4E39E99: start_thread (pthread_create.c:308)
==1886==  Uninitialised value was created by a heap allocation
==1886==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1886==    by 0x5067E55: CBNewNetworkCommunicator (CBNetworkCommunicator.c:30)
==1886==    by 0x4022C2: main (testCBNetworkCommunicator.c:286)

According to get_vbits, the checksum is not defined at https://github.com/MatthewLM/cbitcoin/blob/master/src/CBNetworkCommunicator.c#L457


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: Mike Hearn on February 05, 2013, 10:17:21 AM
Yes, believe it or not. I was in two minds as to whether or not this is a good idea or not, but for the dependencies I've used uint64_t instead of void * so that it is friendly with integer identifiers (These function prototypes are designed so that they can be implemented in different ways). But now I'm closer to using void * instead. What do others think?

Are you sure you want to try and write OOM-safe software? I know from experience that trying to handle NULL returns from malloc is insanely difficult to do correctly, almost no software these days even tries. Aborting the program if malloc returns NULL is invariably the right decision.

Also casting pointers to integers like that is likely to cause issues, which is why the compiler is warning you about it. Don't disable compiler warnings! They are there to help you. The entire Google codebase compiles with -Werror even though it's hundreds of millions of lines, because otherwise it's too easy to ignore them and have bugs sneak past. I'm not sure what you mean by "friendly with integer identifiers" but whatever the goal is here, it's not worth it, especially not for software where correctness is paramount.

The valgrind stack trace doesn't match the code on github, by the way, so if you're asking for help there you'd need to post one with fresh line numbers. The code in that part of the file is very hard to read. I strongly recommend you use structs to avoid code like this:

         // Checksum
         memcpy(peer->sendingHeader + 20, toSend->checksum, 4);

+ 20 here is a magic number, it's not needed because the message headers have a predictable layout anyway so you could just cast the entire header to a struct and then use real identifiers.

Also, try to avoid redefining the language. Here:

      // Need to send the header
      if (NOT peer->messageSent) {
         // Create header
         peer->sendingHeader = malloc(24);

peer->messageSent looks like it's being treated as a boolean (i assume that NOT is defined to be !) but then later on it's treated as if it was an int. If it's a number it's better to write out the integer comparison explicitly.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 05, 2013, 01:11:57 PM
Hello Mike and thank you for taking a look.

Quote
Are you sure you want to try and write OOM-safe software? I know from experience that trying to handle NULL returns from malloc is insanely difficult to do correctly, almost no software these days even tries. Aborting the program if malloc returns NULL is invariably the right decision.

I don't know about other systems but Linux has an OOM killer that makes checking malloc redundant anyway. However, I'm adding checks for the sake of better software regardless. It's not hard to add these checks. Testing them is more difficult. Handling OOM conditions is more important when you are dealing with embedded systems and various low memory environments, so if ever the ode was to be used for these applications it would become more useful.

Quote
Also casting pointers to integers like that is likely to cause issues, which is why the compiler is warning you about it.

The compiler is not warning about casting pointers to integers, it's warning about casting a pointer to an integer of a different size. This is not a problem in this case but it doesn't matter since I'm changing my code to use void * instead.

Quote
Don't disable compiler warnings! They are there to help you.

Warnings are not necessarily problems. I could perhaps use GCC diagnostic ignored on certain files to avoid making errors ignored for all files.

Quote
The valgrind stack trace doesn't match the code on github, by the way, so if you're asking for help there you'd need to post one with fresh line numbers.

OK I'll fix that.

Quote
The code in that part of the file is very hard to read. I strongly recommend you use structs to avoid code like this:

         // Checksum
         memcpy(peer->sendingHeader + 20, toSend->checksum, 4);

+ 20 here is a magic number, it's not needed because the message headers have a predictable layout anyway so you could just cast the entire header to a struct and then use real identifiers.

I'll add an enum for the offsets, but I can't use a struct since this data is to be passed through the network.

Quote
Also, try to avoid redefining the language. Here:

      // Need to send the header
      if (NOT peer->messageSent) {
         // Create header
         peer->sendingHeader = malloc(24);

peer->messageSent looks like it's being treated as a boolean (i assume that NOT is defined to be !) but then later on it's treated as if it was an int. If it's a number it's better to write out the integer comparison explicitly.

I have the habit of using !/NOT (I've used NOT since I always overlook !) to mean == 0. I can see why that may be misleading. It will take a while to convert all instances of that, but I'll add an issue on github to record that.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: Mike Hearn on February 05, 2013, 01:36:46 PM
I don't know about other systems but Linux has an OOM killer that makes checking malloc redundant anyway. However, I'm adding checks for the sake of better software regardless. It's not hard to add these checks. Testing them is more difficult. Handling OOM conditions is more important when you are dealing with embedded systems and various low memory environments, so if ever the ode was to be used for these applications it would become more useful.

In practice unless you write/obtain tools that allow systematic exploration of the control flow graph with malloc returns being mocked out, you will never write correct OOM handling software. As you point out, returning NULL when malloc fails is easy, doing something sensible with it is not. In practice you can't do anything sensible with it, so it's not worth trying, it just slows down and clutters up the code.

Quote
I'll add an enum for the offsets, but I can't use a struct since this data is to be passed through the network.

Learn about __attribute__((packed)) and bit fields. You can use a struct to overlay any arbitrary piece of memory.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 05, 2013, 02:17:29 PM
Checking for malloc returning NULL is hardly going to slow down the code. Though saying it clutters up the code is a fair point.

Learn about __attribute__((packed)) and bit fields. You can use a struct to overlay any arbitrary piece of memory.

I do not want to do this as it is bad for portability.

I'm not going to use void * after-all as I just remembered the network code uses integers returned by socket(). Best keep it the way it was before. uint64_t can take any pointer or integer, so it's safest to just use that.

Edit: The valgrind errors do correspond with the line numbers for me.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: jgarzik on February 05, 2013, 02:47:14 PM
I'm not going to use void * after-all as I just remembered the network code uses integers returned by socket(). Best keep it the way it was before. uint64_t can take any pointer or integer, so it's safest to just use that.

You want to use, not work around, the C type system.  Use the type that most accurately reflects the contents.  Google for alias analysis, as just one of many examples why you should not "hide" things from the compiler.



Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 05, 2013, 04:08:26 PM
But the contents are unknown. Either an integer or a pointer could be used depending on the implementation. And any optimisations would be useless in this case.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: jgarzik on February 05, 2013, 06:41:59 PM
But the contents are unknown. Either an integer or a pointer could be used depending on the implementation. And any optimisations would be useless in this case.

No, you're doing something wrong if you're stuffing/casting pointers into integers like that.  File descriptors and handles returned by the OS are different in every way from a pointer.





Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 05, 2013, 06:56:05 PM
But the contents are unknown. Either an integer or a pointer could be used depending on the implementation. And any optimisations would be useless in this case.

No, you're doing something wrong if you're stuffing/casting pointers into integers like that.  File descriptors and handles returned by the OS are different in every way from a pointer.

Yes they are different than pointers, hence why I'm using a uint64_t that can hold all integers and all pointers. These functions that have uint64_t arguments are declared in the core library only as weakly linked prototypes. The functions are implemented outside this core library. These implementations can use integers or pointers. I could make assumptions such as that these implementations will only want to use integers for sockets, pointers for random number generators etc. but I feel better making so that people can implement them with integers or pointers as they choose up to 64 bits.

From what I know this causes no problems. Any losses in optimisation would be too small to worry about.

The only thing the core library that holds the integer representation does, is store that integer and pass it into functions that are implemented outside the library. These implementations will cast the integer into the appropriate type for that implementation.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: Mike Hearn on February 05, 2013, 07:59:05 PM
I do not want to do this as it is bad for portability.

Every compiler supports struct packing. See here:

http://stackoverflow.com/questions/1537964/visual-c-equivalent-of-gccs-attribute-packed/3312896#3312896


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 05, 2013, 08:05:14 PM
OK Mike. I see four problems with this:

1. It's more confusing and counter-intuitive in my opinion, though different people may think differently of-course.
2. The way I do it works and is simple enough.
3. What about endianness?
4. What about compilers for embedded systems, which cbitcoin may (may being an important word) be suitable for in the future?


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: K1773R on February 05, 2013, 09:33:50 PM
OK Mike. I see four problems with this:

1. It's more confusing and counter-intuitive in my opinion, though different people may think differently of-course.
2. The way I do it works and is simple enough.
3. What about endianness?
4. What about compilers for embedded systems, which cbitcoin may (may being an important word) be suitable for in the future?
4. show me a emdedded systems architecture where gcc cant compile for it?


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 06, 2013, 09:02:34 PM
Are you saying that practically all architectures have compilers that support the packed attribute?

There are the other three reasons to keep it the way it is.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: EndTheFed321 on February 09, 2013, 06:33:52 AM
Good luck with this one hope you reach your goal  8)


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: Mike Hearn on February 09, 2013, 11:04:57 AM
Are you saying that practically all architectures have compilers that support the packed attribute?

There are the other three reasons to keep it the way it is.

Yes, that is what he is saying.

Bitcoin is inherently a little endian protocol because Satoshi uses memcpy in a few places in the serialization code, and because it runs on x86 chips which are LE only. Your code is also endian-specific for the same reason.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: notme on February 19, 2013, 08:59:23 PM
I've almost decided now to continue using GPLv3 but with an exception for OpenSSL and another exception allowing for distribution of binary forms without the source code (thought the GPL does allow for these exceptions to be removed when conveying copies).

And my mind is settled on using a copy-left license. Sorry for all those that do not like copy-left.

I'm currently working upon an "accounter", which is code that looks for transactions with particular output scripts and can thus keep track of transactions and balances for bitcoin addresses or whatever type of output. It also keeps track of unspent outputs. Bizarrely this is more awkward than I thought it would be. This code does not manage private keys.

I will be looking at modifying the database code to store the index on disk, to prevent high memory usage, and looking to cache certain pieces of data. At the moment the entire index is loaded to memory.

Why not just use a BSD license if you're going to take the teeth out of the GPL?


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: onelineproof on March 11, 2013, 07:35:46 AM
Hi, not sure if it's useful, but I created lightweight bitcoin wallet tool called cwallet, implemented in C: https://github.com/piratelinux/cwallet

It's good for reading the address and private key pairs in a wallet, as well as creating a paper wallet with QR codes. There's a CLI version and a GUI version.

I recently did some hacking around and added a feature that let's you see the address associated with a brainwallet as well as try to "hack" the password of an address generated by a brainwallet. I still didn't add this into the repo yet. I also plan to have a feature that lets you check the balance associated with an address by querying the Bitcoin network.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: paulie_w on March 13, 2013, 10:03:56 AM
so how did this one handle the recent fork situation? :-)


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: rlh on August 23, 2013, 04:59:38 PM
What's the story on this project?  Any further momentum?


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on August 23, 2013, 05:25:11 PM
Hi. I was busy for quite a few months earlier in the year, but I'm now able to put more work towards this.

The most up-to-date branch is this one: https://github.com/MatthewLM/cbitcoin/tree/accountingAndNodes

I've finished the accounting code now which keeps track of balances, transactions and unspent outputs for "accounts". These accounts are calculated with a list of watched outputs, so you can watch bitcoin addresses for wallets or whatever, and store the account information. It was designed so that you could have multiple accounts.

Now I'm working on finishing off the node code (both full validation and SPV). Progress has not been so bad for that. I'm currently working on producing features for the protocol version 60000, but other things such as the bloom filtering can come later.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: tspacepilot on August 24, 2013, 03:07:54 AM
Thanks for this, I may just try it out!  I didn't see what kind of licensing in your OP?  Is it GPL?


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on August 24, 2013, 12:54:10 PM
Hi, the license for the most up-to-date code is the GPLv3 with additional permissions and can be found here: http://cbitcoin.com/license.html and here: https://github.com/MatthewLM/cbitcoin/blob/accountingAndNodes/LICENSE

I'll make sure to add it to the OP.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: rlh on September 04, 2013, 03:46:20 PM
I have this in my Watchlist, but somehow I've missed the additional discussion.  Thanks for the update.  I'll be keeping my eye on this project once it near, fully implemented.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: hivewallet on October 08, 2013, 09:38:37 AM
Wow, nice work. This could be great for embedded devices!


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on October 08, 2013, 02:15:30 PM
Thanks. The library may be useful for embedded devices, though there will need to be at least a partial implementation of the C standard library, and to use all of the features you will to implement things like the cryptography, threading and network functions. At the moment cbitcoin has a core library which is in C99 only, and it has separated libraries which use POSIX libraries, libevent and OpenSSL. These separated libraries can be replaced by alternative code or ignored if they are not needed. So for instance if you want to use cbitcoin but don't want networking, the networking functions do not need to be implemented and thus there is no need to link to libevent.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: hivewallet on December 11, 2013, 08:39:40 PM
cbitcoin now has a fully validating node implementation. There is still much work to do. There are a lot of memory leaks that have not been resolved yet for a start.

Once again, thanks to people who have donated. The donations are now worth a good amount of money. I'm still open for more bitcoin donations (1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9), and I would be happy to receive any offers for code contribution.

I haven't implemented a headers-only node as of yet. Before I do that I will like to test cbitcoin over the real bitcoin network by implementing a basic client. Now that should not be too difficult (I hope) since I can extend an interface on-top of the node software.

Wow Matthew, congratulations! That's a massive achievement!


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on December 11, 2013, 08:45:20 PM
Thanks. I've not actually tested it running on the bitcoin network yet so let's hope it goes smoothly!  :)


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on January 18, 2014, 07:18:10 PM
I've fixed the address generation example and also added a (basic) generator for all upper-case and digit addresses such as this one I just generated: 17BK2E43VFA57KE6X5GQUAH12ECE7WL227.

cbitcoin now supports HD keys (BIP0032), it can properly construct and sign transactions of the standard types, various other things have been improved and there is a client on the way.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: linuxdoctor on February 11, 2014, 03:53:44 AM
cbitcoin now has a fully validating node implementation. There is still much work to do. There are a lot of memory leaks that have not been resolved yet for a start.

Yes, I've found one. This is from dependencies/random/CBRand.c:

Code:
bool CBGet32RandomBytes(uint8_t * bytes){
FILE * f = fopen("/dev/random", "r");
return fread(bytes, 1, 32, f) == 32;
}

I'm looking at the cbitcoin library for my own edification and possibly integrating it into something. I'm new to bitcoin in general and before I begin to use it (if I decide to use it) I want to know everything I can about it. Reading the code of various implementations of different parts of bitcoin (servers, miners, clients, etc.) has been an education.

Anyway, in looking at this file (quite by accident incidentally) I discovered that you did not close the file after reading from it. Which means every time you get some RandomBytes you will use a new file descriptor. This will leak a lot of memory and waste file descriptors to boot. It becomes a race between running out of memory or running out of file descriptors.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on February 11, 2014, 02:31:51 PM
Thank you linuxdoctor. I've added a fix and it will be available in the next commit. If you want to know anything about the library make sure to get in touch.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: CIYAM on February 11, 2014, 02:36:25 PM
It becomes a race between running out of memory or running out of file descriptors.

Typically the # of file descriptors is quite small compared to available memory so I'd think the latter would be the main problem but still a memory leak nonetheless.

Glad to see this project is still going (has been a while since I'd followed this topic).


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: linuxdoctor on March 22, 2014, 02:16:39 AM
I've been away doing other projects but spent a few hours playing with cbitcoin this evening and found a few more bugs and possible solutions. I've compiled some unified diffs. The diffs are between the current git repository  and a fork (named cbitcoin-2014-03-21).

1. Function CBNewBlockChainStorage() crashes when trying to free self->database which is never initialized at this point. At this point, the function is doing cleanup on an error but should just free self since everything before it has already been freed.
Code:
--- ./library/dependencies/storage/CBBlockChainStorage.c        2014-03-21 19:53:02.744321264 -0400
+++ ../cbitcoin-2014-03-21/./library/dependencies/storage/CBBlockChainStorage.c 2014-03-21 01:17:12.000000000 -0400
@@ -38,7 +38,7 @@
                CBFreeIndex(self->blockHashIndex);
        }
        CBLogError("Could not load one of the block chain storage indices.");
-       CBFreeDatabase(self->database);
+       free(self);
        return false;
 }
 void CBFreeBlockChainStorage(CBDepObject self){

2. Function CBOnUpToDate is never declared (nor do I know how to use it) nor is CBCallBacks callbacks initialized to point to it. This then  crashes cbitcoin example server whenever some routine tries to access callbacks->updatetodate. Simple fix.
Code:
--- ./client-server/src/main.c  2014-03-21 19:53:02.738321373 -0400
+++ ../cbitcoin-2014-03-21/./client-server/src/main.c   2014-03-21 18:36:45.608202593 -0400
@@ -66,6 +66,9 @@
 void CBOnTransactionUnconfirmed(CBNode * node, uint8_t * txHash){
        
 }
+void CBOnUpToDate(CBNode * node, bool truefalse){
+
+}
 CBNetworkAddress * CBReadNetworkAddress(char * ipStr, bool isPublic){
        CBSocketAddress saddr = {NULL, 8333};
        char * portStart;
@@ -286,7 +289,8 @@
                CBOnNewTransaction,
                CBOnTransactionConfirmed,
                CBOnDoubleSpend,
-               CBOnTransactionUnconfirmed
+               CBOnTransactionUnconfirmed,
+               CBOnUpToDate
        };
        CBNodeFull * node = CBNewNodeFull(database, nodeFlags, otherTxsSizeLimit, callbacks);
        if (!node) {

3. This is a tricky one. in CBEcdsaVerify() if o2i_ECPublicKey() fails it writes a NULL into key which EC_KEY then tries to free. Result: crash. This is a work around which creates two copies of the new EC_KEY. If key gets stomped on then we can free the copy in eckey. Interestingly, ECDSA_verify harmlessly passes over any NULL value in key (although I wouldn't count on any future version doing so).
Code:
--- ./library/dependencies/crypto/CBOpenSSLCrypto.c     2014-03-21 19:53:02.741321318 -0400
+++ ../cbitcoin-2014-03-21/./library/dependencies/crypto/CBOpenSSLCrypto.c      2014-03-21 19:44:44.181601752 -0400
@@ -84,9 +84,13 @@
        RIPEMD160(data, len, output);
 }
 bool CBEcdsaVerify(uint8_t * signature, uint8_t sigLen, uint8_t * hash, uint8_t * pubKey, uint8_t keyLen){
-       EC_KEY * key = EC_KEY_new_by_curve_name(NID_secp256k1);
+       EC_KEY *eckey, * key;
+       int res = 0;
+
+       eckey = key = EC_KEY_new_by_curve_name(NID_secp256k1);
        o2i_ECPublicKey(&key, (const unsigned char **)&pubKey, keyLen);
-       int res = ECDSA_verify(0, hash, 32, signature, sigLen, key);
-       EC_KEY_free(key);
+       if ( key != NULL )
+               res = ECDSA_verify(0, hash, 32, signature, sigLen, key);
+       EC_KEY_free(eckey);
        return res == 1;
 }


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on March 23, 2014, 04:12:30 PM
Thanks very much linuxdoctor. I've added your fixes, except for the second one which is not included in my latest source code. There are several bugs I'm working on at once, I'll hopefully push them to github later or sometime soon.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on March 29, 2014, 01:33:11 PM
You can now donate via Paypal or Charitycoin (http://charitycoinfoundation.com):

Paypal: Click here! (https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YPB6N4BBZQD3N)

Charitycoin: CSU54ZAa4VuhiVwzgyAudePmn7eJigkKU5


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on June 04, 2014, 02:02:23 PM
cbitcoin is now using the MIT license.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: BitCoinDream on June 04, 2014, 02:38:11 PM
Can we push it into student's syllabus learning C ? If yes, how ? Any idea ?


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on November 16, 2014, 11:39:06 PM
Can we push it into student's syllabus learning C ? If yes, how ? Any idea ?

There was one university project using cbitcoin. I'm not sure how much they would be happy for me to disclose about that though.

I changed cbitcoin significantly in a new commit. I removed a lot of incomplete code so that what is left is done to a higher degree of completeness. It has code for HD wallets, transaction construction, script execution/construction, network messages, bitcoin addresses, WIF addresses, general base58 encoding/decoding, basic network communication, proof of work validation and more.


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: azw409 on January 09, 2015, 03:47:10 PM
Hi Matt,

Thanks for your work on this, I'm very impressed by the simplicity of it - Bitcoin code that is easy to follow, what a novelty !

I want to do some experimentation with a slightly different blockchain implementation i.e. yet another worthless altcoin and thought that cbitcoin might be a good starting point. Is there a rough example on how to use cbitcoin to create a basic full validating node as I've looked through all the classes and can't find a 'main' function or a basic entry point anywhere ? None of the examples seem to cover this basic case, unless I've missed it.

Thanks

Andrew


Title: Re: [ANN] cbitcoin 2.0 - A Bitcoin Library in C
Post by: MatthewLM on January 09, 2015, 06:55:38 PM
Hi Andrew,

I have worked on full validation on cbitcoin, though I decided to scrap it in favour of more primitive bitcoin functions only, because of the time and work involved in getting it fully functional and tested. cbitcoin however would give a set of tools to help with creating a fully validating node, and the CBNetworkCommunicator code goes some way to implementing a node (handshakes, pings, peer discovery etc.). For blockchain validation you could look at the old CBValidator  (https://github.com/MatthewLM/cbitcoin/blob/5a51ce7f97b9b1d1028d16d8008bb56bfc7f76ae/library/src/CBValidator.c)code, though I removed it. The library still has things such as address encoding, BIP0032 HD Wallets, message structures inc. serialisation, basic validation functions (merkle tree functions, proof of work stuff etc.), script creation/execution, and transaction creation/signing.

However to create an alt-coin from it would be an unnecessary difficulty in my opinion, though it could make an interesting project for sure, and cbitcoin may be useful in projects, though I can't guarantee that it's 100% correct and bug free. I am personally using the HD wallet code in another project with some modifications. I also use the example programs quite a lot: https://github.com/MatthewLM/cbitcoin/tree/master/examples

Regards,

Matthew