Topic: Let's bring some centralisation (Read 1440 times)

Progress is, but slow without competition.
The disinterest of core the team to isolate the consensus algorithm of the rest takes development of higher level features in hostage.

It's bullshit FUD. I wouldn't listen to any of that claptrap. Bitcoin will never progress if we don't have competition. Are you still using the original browser by Tim Berners Lee? Bitcoin is ~15k lines of code by a single person. Competent programmers everywhere deal with millions of lines of code.

I think Armory will stop needing Bitcoin-QT in the not so distant future. Reverse engineering of the functionality will be necessary however but I believe the core developers of the Satoshi client will assist etotheipi (at least I sincerely hope they will).

This is the same problem as different versions of the satoshi client. If you are going to say "don't use other clients", you should also say "don't use new versions of the satoshi client". We saw that problem with incompatibly between v7 and v8 as an example. The fact is bitcoin will always be difficult to maintain properly but that doesn't mean no one should try to write new software for it. It just means we should be more careful. And if there is a fork problem, it can be resolved by updating the software to fix the issue. Of-course we don't want that as it can cause disruption and also enable attacks whilst the problem is unnoticed. You can write fork detection into node software to also warn users of potential problems and to stop using the software until problems are resolved thus making attacks less likely but keeping the problem of disruption.

Right. They don't discourage you from using an alternative bitcoin solutions, as long as what you are doing with them isn't anything serious

But me at the other hand, I would not use bitcoin-qt for anything serious, because its online-only wallet architecture is completely unacceptable as for my personal security standards.

Yeah, I know that there are workarounds to keep the wallet.dat offline - I've been there and I know that they require a user to move gigabytes of blockchain data, and to wait for an endless -rescan, over and over, each time before spending a new coin... but if this is supposed to be the serious solution, then there must be something seriously wrong with my sense of humor

I think they are trying to say that Bitcoin-QT is recommended, since it is the "original". Other wallets might be slightly different.

Obviously it's hard to reproduce all the official client's behaviors and misbehaviors, in order to handle the blockchain properly... we all know that it's the only reference there is and by definition you cannot beat the reference.
But I did my best and I challenge anyone to break my client by forking its behavior against bitcoin-qt, or get it stuck at a certain block.
Especially I encourage the guy who wrote that quote!
But until he does, he's just pathetic - I can also say that his children are stupid and far off the right course..

I read it as saying: "If you are running your company on Bitcoin then your safest option is to use bitcoind as your backend'.

I totally see what you're describing and I agree.
Maybe I wasn't clear enough though, it's the form that bothered me. I find it really negative towards other implementations (I don't have developped any).
I am not an English native though, did I misunderstand the meaning of the text?

The root issue is that Bitcoin runs on a consensus mechanism for the blockchain.

A comparision is the quite amazing coordinated displays for the Beijing Olympics.
You had thousands upon thousands of individuals coordinating precisely to produce the overall display.

There are now I think bitcoind, bitsofproof, libbitcoin and the 'fullnode' implementation of bitcoinj that _potentially_ could act as full nodes on the main network. (Sorry if I have missed your implementation !)

Using these on the main network now would be like the "Beijing Olympics Chief Dance Coordinator" writing down the choreography for all the displays, printing out thousands of copies, handing them out to various dancers and getting them to all practice the steps at home in front of the mirror. Depending on the edge cases, the understanding of the dancers etc etc it would look "kind of" ok but you are never going to get true coordination. In Bitcoinland this creates one or more hard forks and a lot of pain.

Your points I think are valid, but there isn't an easy answer to it. For instance, Matt Corralo has written compatibility tests for the work he has done in implementing the fullnode version of bitcoinj. But is that going to cover ever possible edge case, database incompatibility, etc etc ? No disrespect to Matt, but that's a pretty difficult thing to achieve.

I suspect that for a while people will be running their alternative implementations behind a 'firewall/ DMZ' of a regular bitcoind for safety's sake.

One Bitcointalk "ad" states the following:
Am I the only one seeing a conflict of interests here?
Isn't bitcoin-qt the only known safe implementation of a full node because it's buggy and people can't rightly reproduce its bugs behaviour?