So if someone finally succeeded in turning one of the alternative clients into a fully functional node, it wouldn't be that hard to keep up with changes in the Satoshi client from there on.
This is probably true only for the professionals with unusually low lucrum cessans. For the fishes I swim with the opportunity cost seemed too big. 
Topic: Bitcoin is NOT ready for mainstream because of 4 major problems (Read 3570 times)
August 08, 2011, 01:01:00 AM
I was talking about usability of bitcoind for a low-volume bitcoin user (at least one tech savvy enough to run a command line tool) as being "not all that bad" in this particular sentence.
I understand your point and I disagree with you. Bitcoind is particularly bad for small-time users:1) it cannot be used on shared or managed hosting plans
2) you have to trust you website manager with check-writing authority on your BTC account
3) the support infrastructure uses unsuitable protocols (JSON instead of FIX)
See my reply in other thread about the plight of small-time traders:
https://bitcointalksearch.org/topic/m.439514
Big-time users can afford dedicated servers, dedicated connections to the exchanges and dedicated accounting and infrastructure management teams.
August 07, 2011, 09:47:07 PM
I haven't seen the code you had to port & integrate. But from your description it was little-endian single-threaded C code not using exceptions.
It had its own built in preemptive scheduler and used lots of critical sections (many of them implemented ad-hoc rather than through a consistent API), but since all the target systems were single-core at least no more than one thread at a time would be scheduled. I survived it.
Quote
Now you have people saying single WALLET.DAT "isn't all that bad" design. I just checked, you think so too. Who erased your memory?
Maybe we're talking past each other. I was talking about usability of bitcoind for a low-volume bitcoin user (at least one tech savvy enough to run a command line tool) as being "not all that bad" in this particular sentence. I wasn't referring to back-end issues and I guess bitcoind in its current state might not scale well enough for a big site to use it unpatched. But really my whole point was about externally visible design features and usability, not about internal design which I can really comment on, never having extensively studied the code and being myself mostly a self taught tinkerer-coder with not all that much of a grip on more abstract software engineering issues.
EDIT: Also, since Bitcoin public keys can be easily derived from the private keys (not the case with RSA such as used in PGP), does it really help all that much to keep them in separate files? Granted, a file with only the public keys in them might be useful for receive-only situations.
August 07, 2011, 09:02:23 PM
The "core development team" has full access to the code base and is actively moving the target because they disagree with the "new brooms".
But the target is not moving that fast. The "core development team" has very much resistance against protocol and block chain rule changes. So if someone finally succeeded in turning one of the alternative clients into a fully functional node, it wouldn't be that hard to keep up with changes in the Satoshi client from there on.Also, Gavin was talking in another thread about introducing some kind of PEP process for the Bitcoin protocol(s). This would make it less hassle to keep up.
August 07, 2011, 08:45:33 PM
Yeah, I've been "through the desert of #ifdefs on a thread with no name" too.
I haven't seen the code you had to port & integrate. But from your description it was little-endian single-threaded C code not using exceptions. Here you have many more additional dimensions of complexity.Satoshi bitcoin client is really a trailblazer in the annals of bad software design. Can you name any other software that uses public-key cryptography and stores both public and private keys in a single object? I presume most people got acquainted with asymmetric cryptography with PGP. Even then, about twenty years ago, there were two separate files: PUBRING.PGP and SECRING.PGP.
Now you have people saying single WALLET.DAT "isn't all that bad" design. I just checked, you think so too. Who erased your memory?
August 07, 2011, 08:11:46 PM
Well, here the situation is different. The "core development team" has full access to the code base and is actively moving the target because they disagree with the "new brooms". Do you understand the difference?
Until 'M' tells me different or 'Q' proves it in second degree predicate logic as a formal theorem I'll let them worry about why our 'Cousins' might prefer we move a little slower.(*)
(*) Heck Maybe I might even sleep, I hear one should do so at least once a week whether one needs to or not.
-MarkM-
August 07, 2011, 08:05:57 PM
the GUI is really in need
This is the PHP GUI we're talking about, right? The one the big fishies from the financial sector want to plug an embeddable module into instead of using RPC to talk JSON in?
Have you seen the PHP one whoozit(*) was showing in some other thread?
So far "John Smith"(**)'s -qt GUI has been looking pretty good, what exactly do the way-awesome professional armchair^H^H^H^H^H^H^H^too busy doing real work to help out designers say is wrong with it, exactly?(***)
(*) Not their real forum-alias last time I checked.
(**) Their real forum-alias, last time I checked.
(***) Or are we talking about the guy designing the "safebit" GUI?
-MarkM-
August 07, 2011, 08:03:01 PM
to work with code bases much worse than the current bitcoin code. Internal projects edited by hundreds of programmers over the years, never refactored because of time constraints.
But presumably when you were working on the "bad code" the "bad programmers" were already dismissed and had no commit access to the codebase, right?Well, here the situation is different. The "core development team" has full access to the code base and is actively moving the target because they disagree with the "new brooms". Do you understand the difference?
August 07, 2011, 07:50:52 PM
Then let me tell you something -- in my nearly a decade of being a professional software developer I've had to work with code bases much worse than the current bitcoin code. Internal projects edited by hundreds of programmers over the years, never refactored because of time constraints.
Yeah, I've been "through the desert of #ifdefs on a thread with no name" too. Tens of thousands of lines of code with more preprocessor stuff than actual C code because it had to work on five different proprietary MS-DOS based compilers for embedded processors. My job was enabling this twisted mess (which was also its own operating system) to be built as a Linux application without breaking anything in the other builds...
The current client code is certainly better than that by far. That still doesn't make it an ideal base for building more complex bitcoin enabled applications on it. And even if bitcoind itself isn't all that bad, the GUI is really in need of some serious professional attention by people who know a bunch about design and usability issues, not just about algorithms. Unfortunately most self confessed geeks, including myself, are far better at the latter...
August 07, 2011, 07:35:18 PM
Quote
I work with "professional software development compan(ies)" not with Polyannas and other people full of hope that everything will be all right.
Then let me tell you something -- in my nearly a decade of being a professional software developer I've had to work with code bases much worse than the current bitcoin code. Internal projects edited by hundreds of programmers over the years, never refactored because of time constraints. Yes it can take some sweat to find out how things work in the Satoshi code, but once you get into it it isn't that bad anymore. If they are any good they should be able to figure it out pretty quickly.Don't get me wrong though -- I agree that the code could use some serious refactoring.
August 07, 2011, 07:32:54 PM
Care to be more specific? What would those problems be?
This isn't secret at all, they are in broad agreement with the goals of libbitcoin:1) sensible modulatization and abstraction layers
2) make the engine embeddable in other projects, eg. PHP engines
3) byte-endian cleanness
4) sensible test harness
AFAIK the "core development team" only agrees that (4) is a valid goal.
I just wanted to add that I'm not representing any "big fish(es)", I'm just a "pilot fish".
1) I wasn't aware that JSON is not sensible. Thanks for the heads-up.(*)
2) C/C++ isn't embeddable in PHP engines? Holy something, thanks again for another major heads-up.(**)
3) Yeah I had just started to encounter mentions of that earlier this wakeperiod.
4) Far out, some other codemonkey gets stuck with that drudgery, nice.
(*) The other port? What other port? Hush, I don't want to think about that. Its not something PHP needs to know.
(**) When the heck did that happen? What the heck is PHP itself written in nowadays?
-MarkM-
August 07, 2011, 07:16:09 PM
What does "official" even mean in an open source project?
Dude, are you nuts? What does "official block-chain", "official checkpoint" mean in this project? "Fully compatible" with what? With the bugs implemented in the "Satoshi client"?I work with "professional software development compan(ies)" not with Polyannas and other people full of hope that everything will be all right.
August 07, 2011, 07:07:16 PM
Care to be more specific? What would those problems be?
This isn't secret at all, they are in broad agreement with the goals of libbitcoin:1) sensible modulatization and abstraction layers
2) make the engine embeddable in other projects, eg. PHP engines
3) byte-endian cleanness
4) sensible test harness
AFAIK the "core development team" only agrees that (4) is a valid goal.
I just wanted to add that I'm not representing any "big fish(es)", I'm just a "pilot fish".
August 07, 2011, 07:04:40 PM
Except that the Java code is unofficial
What does "official" even mean in an open source project?Quote
incomplete implementation and is
Now that is exactly why people need to work on it to complete it... It might be a better base to start from, that was my point.Quote
Anyone seriously developing an "alternative client" must really develop a "replacement peer" which has a hope of getting accepted by majority of the current peers and miners
Why would it need to be accepted by the majority? Unless you plan on a takeover, being fully compatible with the current client is enough to be a good citizen of the network. More variation in clients would be good, not monoculture just with a new client. August 07, 2011, 06:54:41 PM
I can tell you this much: real professional software development compan(ies) took a look at the current source code and its history and gave estimates & quotes that were unacceptable to some "big fish(es)" in the finance industry.
Good to know it has been attempted at least... Usually when real money is involved you'd expect some people trying to be more professional about things than what the bitcoin client currently is like (i.e. more or less at the "Nullsoft Gnutella client" stage.)
Quote
There's a number of serious problems under the hood. You have to dig into the C++ code to see them.
Care to be more specific? What would those problems be? Or do they have to be "kept under the radar" at this time for security reasons?
August 07, 2011, 06:44:16 PM
If the problem is with the specific C++ code it could be better for them to work on BitcoinJ, then. The code is more modular, understandable and straightforward.
Except that the Java code is unofficial, incomplete implementation and is, well, in Java and not C/C++. Anyone seriously developing an "alternative client" must really develop a "replacement peer" which has a hope of getting accepted by majority of the current peers and miners. Anything else is just a hobby project.My personal guess is that BitcoinJ is really BitcoinD(alvik) as far as motivation and genesis of it.
August 07, 2011, 06:35:30 PM
There's a number of serious problems under the hood. You have to dig into the C++ code to see them.
If the problem is with the specific C++ code it could be better for them to work on BitcoinJ, then. The code is more modular, understandable and straightforward. August 07, 2011, 06:28:22 PM
What prevents a couple of the "big fish" (people with several thousand coins) from banding together and paying a real professional software development company for improving the official client, like, uh, you know, real fast and all?
I can tell you this much: real professional software development compan(ies) took a look at the current source code and its history and gave estimates & quotes that were unacceptable to some "big fish(es)" in the finance industry.Obviously, there are "real professional software developers" that will take on anything knowing upfront that they will go over the budget and behind the schedule, but I have no contact with those.
There's a number of serious problems under the hood. You have to dig into the C++ code to see them.
August 07, 2011, 06:22:43 PM
Tah-dah! Enter DeVCoin!
The "big fish" of DeVCoin have millions of DeVCoins, they are developers, and the mining rewards are rigged in their(*) favour instead of in favour of miners(**)!
The thot plickens!
-MarkM-
(*) Them: "developers". Of open source software, hardware, literature, firmware, etc etc etc...
(**) "Miners": typically owners of closed-source capital equipment "means of production"?
The "big fish" of DeVCoin have millions of DeVCoins, they are developers, and the mining rewards are rigged in their(*) favour instead of in favour of miners(**)!
The thot plickens!
-MarkM-
(*) Them: "developers". Of open source software, hardware, literature, firmware, etc etc etc...
(**) "Miners": typically owners of closed-source capital equipment "means of production"?
August 07, 2011, 06:16:29 PM
What prevents a couple of the "big fish" (people with several thousand coins) from banding together and paying a real professional software development company for improving the official client, like, uh, you know, real fast and all?
I'm not sure. From what I've noticed, the "big fish" are mainly concerned with exchanging and mining, and are not active with the development of the client. (either that, or they are working on the client internally, for example to handle large numbers of users, but not contributing code back; after all, the license does not require this)
Jump to: