Quote from: MPOE-PR on March 12, 2013, 09:48:57 PM

Quote from: justusranvier on March 12, 2013, 09:30:26 PM

Incorrect. The only question is who is willing to do it, and who is willing to support them.

I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.

To quote here:

Quote

jurov anyway, the problem isn't as much the drama, but moreover that a single-source codebase is both non-bitcoiny and suspect.
but i think if we can get one (or ideally multiple) people to summarize the code
we can pretty much derive a spec from there.
this wouldn't take much longer than a few weeks for a first draft, which can then be argued and refined
in my experience any devteam resists such an effort like cats resist washing, because coders love to write but hate having to read code.
hiowever, once it's complete there's a few day's worth of facepalming and going "wait, we are doing W?HAT ?!"
after which everything's much better.
this is a solid plan.
mod6 in experience it tends to work.
of course it has to first get the cat into the washing machine.

There wouldn't really be need for much testnetting, at least originally (ie, for the first draft).

What there's need for is people to sit down with a cup of coffee and a (preferably printed) copy of the code and just read it through. This can be done in bits as long as the bits aren't arbitrarily segmented (it's ok to summarize a procedure, it's not ok to summarize between lines 520 and 545). Once we have a few of these completed we're already very far down the road.

Then the work of merging them into a spec emerges, where a lot of arguments will for sure be had ("no, it doesn't do that"/"yes it does") at which point there may be a need to whip out the testnets but not necessarily. Then a ton of drama and hurt feelers, and then that's it, once everyone is beaten into a pulp we have the spec.

Ideally this would include people other than the current dev team, not because the current dev team is made of idiots (which mostly it is) but because people tend to read what they think should be there and in general skip over the unflattering bits.

In fact this can be started today.

Another approach is to write the spec while refactoring the reference implementation into something more documentable. Any superfluous functionality than can be removed from bitcoind and moved to the clients is less functionality a fully-compliant alternate implementation is required to implement.

Quote from: alexkravets on March 12, 2013, 08:02:34 PM

Quote from: justusranvier on March 12, 2013, 05:03:40 PM

I've suggested this before but maybe it's worth mentioning again.

Split bitcoind and bitcoin-Qt into completely independent components. Bitcoind stores a local copy of the blockchain, connects to the p2p network, relays blocks and transactions, and serves blockchain information to clients only. Bitcoin-Qt is a client application only that connects to a trusted bitcoind node. The default installation would install them in a pair, with bitcoind running all the time as a unix daemon (Windows service) and Bitcoin-Qt started on demand. Only one instance of bitcoind is needed on a typical home LAN, all the clients can just connect to it.

Once this is done Bitcoin-Qt can just focus on being the best client it can be, while bitcoind can focus on the blockchain and p2p network. It should also be extended to serve MultiBit, Armory and Electrum. Once the reference implementation is fully refactored into a client/server application it should make any attempt to develop an alternate implementation easier.

I don't have enough programming skill to do this, but I'd donate to anyone who does.

This would definitely be the first step out of the current insanity and finally bring some layering into the code base client UI === depends on ==> bitcoind but zero backward pointing dependencies.

This would be the first step on the long journey to the promised land of the BPS (Bitcoin Protocol Specification)