Main developers don't give a damn about us, bitcoiners!

[r.willis]

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.

[1715221089]

1715221089

[1715221089]

1715221089

[1715221089]

1715221089

[1715221089]

1715221089

[Mike Hearn]

So, would BF chime in and halt inclusion of bitcoin payment protocol into mainline client before it goes through BIP procedure? May be Chief Scientist Gavin Andresen could enlighten us? (oh wait, he is the author of proposal in question). I see problem here.

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.

[MPOE-PR]

You won't be redoing anything.

You will fork the main client, merge the changes, and release it, that is it.

If it becomes more popular than the main client, probably the main devs will merge on the official client too, and then you won.

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.

[r.willis]

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?

Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.

Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users.

[gmaxwell]

It is not BIP, but its inclusion into mainline client is decided. Am I reading this correctly?

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.

[r.willis]

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.

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?

[phelix]

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.

Yeah, you have an argument there.

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

[Gavin Andresen]

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.

[paraipan]

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.

[ShadowOfHarbringer]

I think multiple wallets are much better alternative then coin control.

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

[artgoodluck]

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.

[aantonop]

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.

[gmaxwell]

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?

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.

[r.willis]

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.

[grau]

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.

[wumpus]

So I'll finish burning the strawman with the following: tax the miners with proceeds going to at least two pockets, one of them Gavin's and Bitcoin Foundation and one in escrow for another R&D and implementation effort. Just don't repeat the devcoin mistake and set the tax rate to 90%.

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.

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.

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.

[r.willis]

it stands for the network

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

[Jobe7]

As usual, Gavin descends upon us and then disappears mysteriously, again...

So... you complain about development not happening faster, and then you complain that I'm not spending all of my time here on the forums?

"okey dokey"

Time to clone yourself! 

[Jobe7]

it stands for the network

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

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