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

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.

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


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?

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-

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

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-

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?

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.


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.