Topic: Main developers don't give a damn about us, bitcoiners! (Read 6661 times)

The network is like .. you.. me, anyone that uses bitcoin, a miner, an exchanger, a new/old bitcoin business, your granny if you give her bitcoin and she uses it (though some might argue she's become part of the 'network' just by owning some).

Time to clone yourself! 

Can you elaborate, what exactly is done for the network?

That's some very dangerous territory. While from a self-interest point of view I really appreciate what initiatives such as devcoin are trying to do, I don't like the idea of writers of the most popular client "picking winners".

The network and client are separate things, and as miners have big investments in it they are concerned with the health of the network (so automatically with the health of the *some* client that maintains the network). However, hardcoding who does this into the network rules would be a bad idea in the long run. It is the definition of centralization.

If it was the case that, for example, a percentage of the mining proceeds would go to Gavin, that would make him "the bitcoin king" and if then the network was crashing daily and he wouldn't be doing anything about it, you would have good reason to be angry and get out the pitchforks (Solidcoin tried this).

But that's not the case. Even though it may be difficult and a lot of work, anyone can get involved with client development, and get paid for it by the network just as much as we do (ie, nothing). Pretty fair uh... And there are quite a lot of alternative clients already, for example  based on bitcoinj, so I don't think it's going the wrong way at all.

If we would start charging for using the client, or adding ads (which was just a joke of course), users can simply move to another one. That's what decentralization should be.

And with regard to the Bitcoin Foundation, let this be clear: it stands for the network and promoting the usage of bitcoin payments worldwide.
It is not the "satoshi client foundation", and certainly not the "bitcoin UI foundation". It is not funding bitcoin-qt development or tech support. So by all means donate to them, but don't do it for the wrong reasons and get disappointed.

Satoshi had to implement the protocol validation, mining, wallet, payment etc. to have a proof of concept.

Now that we see the concept is working, it is natural that people want different flavors of the non-validation functions. It is not feasible that the single implementation will satisfy those often conflicting (at least in priority) needs. The Satoshi client and its maintenance model became the bottleneck for innovation the core team does not think it is fun to work on.

The solution is to isolate the protocol validation and modularize. Since the Satoshi code is badly suited for modularization and separation of validation engine, other implementations started and some are already in good shape.

The bits of proof implementation has an impressive compliance level and performance, is radically modular and comes with a list of unmatched features by the Satoshi client such as e.g. BIP32, BIP38 and colored coins. Its development is led by commercial demand while it will continue to open source the validation engine to the community.

Now you have the choice of navigating the politics of influencing the Satoshi client or simply sign a contract with bits of proof zrt. to get what you want.

I agree working implementation is a must for BIP. But rolling new feature in stable release without "Active" BIP must be no-no.
Write code, test on testnet and on main-net small-scale (maybe beta or "technology preview" to test on real users), then go throug BIP, if there are some other implementations based on BIP test them for interoperability and then ship it with next bitcoind. Otherwise, you are gaining unfair advantage over other implementations (or maybe even over competing standards).
I'm fixating on Gavin because he 1) is paid developer working on bitcoin full-time 2) holds official position in BF (one (and first) goal of BF is stated as bitcoin standardization). BIP is the only formalized standardization process in bitcoin community, and I wanted to know what is the policy regarding inclusion new non-BIP features in bitcoind.
It seems having BIP in whatever status is mandatory for everyone, but not for Gavin. I see disconnect here.
Concerns regarding payment protocol were raised on mailing list and were not fully addressed. My main concerns are 1) introducing into bitcoin notion of trust and centralization 2) inclusion something that is orthogonal to bitcoin as cryptocurrency 3) proposed protocol is specific to bitcoin, while it can have much broader range of applications 4) no clear explanation why existing (or emerging) protocols cannot be used.

An acceptable looking specification and public support are some of the things we'd look for before pulling a feature with interoperability impact. We've held other pulls for BIPs to be written or gain more evidence of support but "Active" status itself wouldn't be a barrier.  As Gavin says— rough consensus and running code, like the IETF.  A BIP cannot be really be finalized without implementations, preferably interoperable ones with some use by real users. Otherwise you get a circular deadlock.

There are also degrees of adoption. For example, things that aren't core protocol features (like the payment protocol stuff) might go in initially hidden behind a "this is a work in progress, subject to revisions, beware dragons." checkbox, if it's believed that doing so might improve things.

I'm not sure why your fixating on Gavin in any case. So far, all the major change that have gone in with the support of all of the core developers. And I generally expect that if there were any major reservations a feature would be revised to get rid of them.

If you have concerns about the payment protocol stuff— please express them. Perhaps my search-fu is weak, but I don't see any comments from you on the subject. Getting comments earlier rather than later is important if you actually want them addressed.

Instead of having people manage bitcoind better, we need more full-node clients that adhere to a reference protocol.

So that people can swap in other node clients to server JSON/RPC to GUI clients.

A single reference implementation for the node, without a standardized protocol, means there is no reference. It's just "whetever the current bitcoind speaks, is the protocol". That's a terrible recipe for stability. Assuming that every peer is a bitcoind, because of course it almost always is, only helps to ensure that you can never develop a non-bitcoind node. It's like trying to hack FAT or Windows SMB networking and build a compatible client.

We need a Gnutella like protocol group. The reference standard should be the protocol, not a lump of C++ code.

A lot of software can be about egos.  While the Bitcoin architecture is genius the code itself is merely adequate.  With all projects that use contributions from volunteers,  you need people managing it which are full time.   It's harder than it looks. Bitcoin's biggest enemy could be its own success.

Why not have both ? The code is almost ready anyway and may be merged into 0.9.

You actually didn't address any of my points, nice way of saying "yeah, you're probably right but get off my back".

I rest my case. Btw, if this keeps going the same way, I think this will be my first and last year supporting your work though the Foundation.

r.willis is confused about the BIP process.

It is not "Write a specification. Submit a BIP.  Argue for a while, revise the specification.  Finalize BIP, then everybody agrees to implement it."

I know there are standardization processes that try to work that way, and they're generally miserable failures. You end up with bloated specifications and implementations that don't work with each other because everybody interprets the spec slightly differently.

I like the IETF model, of working code and rough consensus. So, once the payment protocol is implemented and early adopters have had a chance to play with it, it will become a formal BIP.  Until then, as Mike said, I'll be tweaking https://gist.github.com/gavinandresen/4120476 as I run into issues.

Yeah, you have an argument there.

What about displaying how addresses are linked? Grouped, color coded...

There were some reasons voiced on the mailing list.
Does this mean that the code will be accepted even if there is no BIP in "Active" status? What's Gavin's policy on this?

No, you are not. There isn't even a pull request yet.  Something is not in until its in. Of course, it'll likely go in once there is a pull request and its been tested unless reasons not to talk it come up— no such reasons have come up so far but ones might once code is actually written.

It is not BIP, but its inclusion into mainline client is decided. Am I reading this correctly?
I.e. going through BIP is not required for Gavin?

For the record, this is a boneheaded argument, no different from the usual "I made a website therefore I have a business therefore I am CEO now" nonsense the geek crowd keeps sprouting.

That aside: merging more crap into the codebase is nonsense. Just testing properly what's already there is enough to keep the current herd of cats occupied for a year or two.

What are you talking about?

The payment protocol spec is here:

https://gist.github.com/gavinandresen/4120476

It isn't a BIP yet because it didn't reach that stage of maturity and is still being tweaked occasionally whilst it's being implemented for the first time.

I think multiple wallets are much better alternative then coin control. You are guaranteed that no addresses from different wallets will be linked together, unless you explicitly ask to make payment from different wallets together.

that's good news. thanks for the other facts, too.

+1  


About coin control
It obviously is about privacy. As somebody pointed out above it shows everybody how bitcoin addresses get all linked together if you are not careful.
In bitcoin-qt it is an option that is deactivated by default. Also bitcoin-qt is no good for newbies.