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

[paraipan]

To Bitcoin developers,

Who do you think you are to decide what's good or bad for us?

Why are you treating bitcoiners like a "nanny-government"?

Why do you stall for months patches and features to the reference client that are useful to all of us?


Patches:

"coin control / less change / refactor coin selection" - https://github.com/bitcoin/bitcoin/pull/1017

"let user select wallet file with -wallet=foo.dat" - https://github.com/bitcoin/bitcoin/pull/1889

"Addition of Import Private Key Menu" - https://github.com/bitcoin/bitcoin/pull/2050

"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383



This situation is aggravating with every day that passes!

Please make sure you understand the issue discussed in this thread before commenting.

[1714902619]

1714902619

[1714902619]

1714902619

[justusranvier]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

[paraipan]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

Why don't you use some alternative to Bitcoin? For the same reason, you like Bitcoin and want it to succeed.

[greyhawk]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

Why don't you use some alternative to Bitcoin? For the same reason, you like Bitcoin and want it to succeed.

So build a version of Bitcoin that succeeds. If yours is better, everyone will migrate to it.

[paraipan]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

Why don't you use some alternative to Bitcoin? For the same reason, you like Bitcoin and want it to succeed.

So build a version of Bitcoin that succeeds. If yours is better, everyone will migrate to it.

Why should I redo the work of others? The features are already built and waiting to be merged in the main client. Or your answer was a sarcastic one?

Where is Satoshi when you need him...

[speeder]

What stops you from cloning the bitcoin repository and pulling in those changes yourself?

Why don't you use some alternative to Bitcoin? For the same reason, you like Bitcoin and want it to succeed.

So build a version of Bitcoin that succeeds. If yours is better, everyone will migrate to it.

Why should I redo the work of others? The features are already built and waiting to be merged in the main client. Or your answer was a sarcastic one?

Where is Satoshi when you need him...

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.

[ionux]

I know everyone isn't a developer, but this is the beauty of open source software.  Grab the sources and learn how to hack in the changes you want personally.  If you think they might be helpful to the rest of the community, submit back your changes to the main developers.  I'm sure they are swamped and any help would be appreciated.

I'll start and show you how to do this.  If you click on the link for the "let users select their wallet" request, you'll see that a patch has already been submitted.  If you click on the "Files Changed" tab, you'll see exactly which 4 files were updated and exactly which lines of code were changed.  The lines with the "-" were removed and the lines with the "+" were added.  Using your favorite text editor, you can make these changes.

So, for the first file, for example, the source code file "src/init.cpp" had one line added near the top of the file:

Code:

        "  -wallet=<file>         " + _("Specify wallet file (within data directory)") + "\n" + 

This line is part of the command-line help that's printed out.

Next, on line 908, this code is removed:  "pwalletMain = new CWallet("wallet.dat"); " and two new lines are added in its place:

Code:

    strWalletFile = GetArg("-wallet", "wallet.dat");
    pwalletMain = new CWallet(strWalletFile.c_str()); 

(Don't add the + or - signs at the beginning of those lines, by the way.  They are there just to show you that it has been added or removed.)

Next up, on line 971, this line was removed: "CWalletDB walletdb("wallet.dat"); " and this line was added in its place:

Code:

CWalletDB walletdb(strWalletFile.c_str()); 

Ok, follow the same directions for the next three files that need to be changed: src/main.cpp, src/main.h,  src/qt/optionsmodel.cpp

After you make all of the changes, you'll have to compile it to make it an executable program.  The file ./bitcoin/doc/readme-qt.rst has the simple instructions for doing this (you can read it online at this link: https://github.com/bitcoin/bitcoin/blob/master/doc/readme-qt.rst)

When you compile it with the "qmake && make" commands, it will tell you if you made any errors adding the lines above.  If you see any "Warnings", you can safely ignore those.  The program will still compile and work correctly, they are compiler warnings.  Any "fatal" errors, however, will stop it from compiling.

There you have it.  Keep in mind that you are now using your own custom bitcoin client.  Any updates that you need to do, like official security updates, may break it and you'll have to grab the new source, add your changes and recompile.  So there is that caveat.

Hope that helps.  It's a bit arcane for non-developers, I understand.  Bit the more you get your hands dirty, so to speak, the easier making these changes for yourself will become.

[Luke-Jr]

To Bitcoin developers,

Who do you think you are to decide what's good or bad for us?

Why are you treating bitcoiners like a "nanny-government"?

Why do you stall for months patches and features to the reference client that are useful to all of us?

Oh please...

"coin control / less change / refactor coin selection" - https://github.com/bitcoin/bitcoin/pull/1017

For a popular feature, nobody was willing to take the effort required to address problems with it, until very recently (too late for 0.8). Hopefully it will make it into 0.9.

"let user select wallet file with -wallet=foo.dat" - https://github.com/bitcoin/bitcoin/pull/1889

Too short-sighted. sipa and CodeShark have been working on true multi-wallet support for a while, and that will hopefully be ready for 0.9.

"Addition of Import Private Key Menu" - https://github.com/bitcoin/bitcoin/pull/2050

Too dangerous for easy access - do you really want to enable people stealing coins from newbies? Power users can already import private keys using the debug console.

"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383

I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.


Sounds like I need to get around to spinning a 0.8-based next-test release, though...

[paraipan]

...

Thank ionux, much appreciated, this is not the point though.

Imagine you've been using Bitcoin for a few years and want to have a few useful features that you've seen missing. You probably already know that Gavin et all incentive people to help them out (https://bitcointalk.org/index.php?topic=4571.10) and submit patches or new features. You start working on it and complete all the steps like a champ, but this is where things start to get complicated and main developers could select your feature, or not, to be merged with the mainstream client. They can leave your submission waiting for a few months too, effectively rendering your work useless because you have to re-base (adapt) your feature or patch to the new client versions.

Here is an example from 11 months ago Re-issue getblocks to the next suitable peer when the previously selected one disappears, the patch was practically abandoned rendering the original work useless!!!

[paraipan]

To Bitcoin developers,

Who do you think you are to decide what's good or bad for us?

Why are you treating bitcoiners like a "nanny-government"?

Why do you stall for months patches and features to the reference client that are useful to all of us?

Oh please...

"Oh please", but you didn't address either one...

"coin control / less change / refactor coin selection" - https://github.com/bitcoin/bitcoin/pull/1017

For a popular feature, nobody was willing to take the effort required to address problems with it, until very recently (too late for 0.. Hopefully it will make it into 0.9.

Nice to hear that, didn't know.

"let user select wallet file with -wallet=foo.dat" - https://github.com/bitcoin/bitcoin/pull/1889

Too short-sighted. sipa and CodeShark have been working on true multi-wallet support for a while, and that will hopefully be ready for 0.9.

Nice to hear that too, didn't know.

"Addition of Import Private Key Menu" - https://github.com/bitcoin/bitcoin/pull/2050

Too dangerous for easy access - do you really want to enable people coins from newbies? Power users can already import private keys using the debug console.

What? Please listen to yourself. The answer is yes, people can and will take care for themselves.

"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383

I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.

Oh no, not again. The feature is there waiting for an approval that never comes. WTF?

I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?

[Gavin Andresen]

So....  move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.

[Mike Hearn]

I've been involved with open source projects for over a decade, so know this issue well.

Usually, if you dig in, there's a reason why some patch is left in limbo. These issues are sometimes not what you want to hear: it's buggy, it's not obviously buggy but seems "risky" and maybe not worth the cost, it solves an issue in a short term way but a long term solution is wanted, etc.

For a lot of these patches, when I dig in, the issue seems like one of those. For instance "re-issue getblocks to the next available peer when one disappears" got superseded by some other patch, and rebroad then said that the other patch wasn't actually ready to be merged. So I can see why it might have got stuck.

For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.

Again, same thing for "dust limit and filtered addresses". If you know enough about Bitcoin to know what this is about, you don't need a GUI to set them. It's not something that regular users should be thinking about.

As pointed out, sometimes people will disagree on these sorts of things. That's open source - the solution is for you to fork the project and maintain your own version with these features merged in. If you aren't a developer, find someone who agrees with you who is, or pay someone to do it.  That's how open source has always worked. If you refuse to do it, then you're refusing the very nature of open source itself!

[paraipan]

So....  move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.

Ok, start a "Bitcoin-QT Poweruser" fork, and let people submit their heart's desire. Without you doing this it will have 0 credibility, including from me.


Edit: Hope you're not coming in from above just to go back again after you said only 2 words.

[Mike Hearn]

paraipan, if you think there needs to be a power user fork, it's up to you or someone else to make one. Not Gavin.

If you can't do it yourself, Luke-Jr actually does maintain a "next test" fork where he merges in lots of features together. Maybe you could convince him to do one.

[paraipan]

I agree with most of the points you make Mike, but...

...
For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.
...

... why you would want to know that? Is not your responsibility or problem. Software has been know to be used in many more ways that initial developers designed it for. Google is your friend, no pun intended.

[justusranvier]

"Bitcoin-QT Poweruser" fork,

There's already a client specifically for power users. It's called Armory.

[christop]

Translation of OP:

I paid nothing for some Free software and demand that its main developers add some features instead of doing it myself or paying someone else to do so.

The features are available to anyone interested and skilled enough to add them, and others in this thread have posted reasonable reasons for rejecting those features in the reference client at this time.

If you can apply the patches for those features and then build it yourself, why don't you? Otherwise, you can hire somebody else who can, so why don't you? Complaining in this thread won't change the valid reasons for excluding the features from the reference client.

[JTurner]

As the reference client, I can sure understand that devs may be reluctant to introduce patches without a lot of testing first. If a released were to introduce some nasty bug, it could quickly create a nice chaos given that most people just run and update the official client without asking themselves many questions (which is understandable, the official client, being "official", is supposed to be stable and running out of the box).

That said:

"Addition of Import Private Key Menu" - https://github.com/bitcoin/bitcoin/pull/2050

Too dangerous for easy access - do you really want to enable people coins from newbies? Power users can already import private keys using the debug console.

What? Please listen to yourself. The answer is yes, people can and will take care for themselves.

Using the console for this is good enough to me (it's not as if this was a very frequent operation), but it would be nice though if the client was able to dump encrypted private keys... It's a bit sad that the official client provides a way to encrypt a wallet but no way to decrypt it... (and it doesn't really help switching from one client to another)

For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.

Well, GUI coin control would actually make Bitcoin easier for anyone needing coin control... A basic design which looks useful to me would be:
1. a list of balance per address
2. from this list, allow to pick one (or optionally several) addresses to spend from
And to avoid clogging the main GUI, it can just be buried somewhere into the menu

[paraipan]

...

You missed the whole point, please re-read thread.

I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.

As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want.

[Mike Hearn]

... why you would want to know that? Is not your responsibility or problem. Software has been know to be used in many more ways that initial developers designed it for. Google is your friend, no pun intended.

Because coin control is a complex way to achieve any given goal. It requires you to understand the transactional nature of the Bitcoin protocol. Fine for super-fans who don't mind studying, a bit of a pain for anyone who isn't. Look at how confused even some developers get about the relationships between addresses, balances and transactions.

So if coin control exists, what that means is people who aren't power users can't solve whatever problem the power users are solving with it. It'd be better to find solutions to the underlying problems, and then everyone can benefit. And often, I bet we can find fully automatic solutions, so it can be more convenient for power users too.

Making Bitcoin usable by everyone is an important goal, and thus so is understanding what people do with it. That's why I'm interested to know what people want coin control for. It's not a "I want to invade your privacy" thing, it's a "how can the software be better designed for everyone" thing.

Saying "I want to spend from a single address" is not a good explanation, by the way, it's just tautological. Why do you care about the precise outputs that are being spent? What is the high-level goal here? Is it to simplify your accounting? Is it part of some other scheme?

[paraipan]

...

Saying "I want to spend from a single address" is not a good explanation, by the way, it's just tautological. Why do you care about the precise outputs that are being spent? What is the high-level goal here? Is it to simplify your accounting? Is it part of some other scheme?

Yes, spending from a single address would be nice. Does that sound too complicated?

[Luke-Jr]

"Addition of Import Private Key Menu" - https://github.com/bitcoin/bitcoin/pull/2050

Too dangerous for easy access - do you really want to enable people coins from newbies? Power users can already import private keys using the debug console.

What? Please listen to yourself. The answer is yes, people can and will take care for themselves.

I was missing a word: "stealing".
Importing private keys that others might have makes you vulnerable to theft.
Newbies could easily be fooled into this kind of an attack.
Advanced users can still do it via the debug console.

The correct solution is to implement the sweep function, and make that easily accessible.

"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383

I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.

Oh no, not again. The feature is there waiting for an approval that never comes. WTF?

I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?

The point is that people are not supposed to be reusing addresses in the first place, which would make the filter useless.

You are granting people "main developers" status. Don't complain about authority you give people - if you don't like it, don't give them that authority.
But in the end, the decisions you're talking about here have reasons behind them.
Ignoring those reasons isn't the best idea.

I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.

As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want.

Yes, there is a problem with getting things merged. But this problem mostly comes down to testing.
You can "fix" it by skipping testing, or getting more people available to test. Only the latter is acceptable to Gavin, and for good reason.

[christop]

You missed the whole point, re-read the whole thread.

I didn't miss the whole point. The point is that you don't want to do anything to fix the situation you're in. You would rather complain about it here.

I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.

As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want.

No, you do not have to depend on the main developers for any new feature. It's Free (as in freedom) software, after all. You can have a Bitcoin-qt client with those features if you would just put some effort into it.

[John (John K.)]

I have read through the thread, and as somebody who uses Armory extensively for the coin control feature plus others, I have to disagree respectfully to paraipan. To cut it short, the reference client should be improved slowly and steadily, thus decreasing the potential vector of attacks as possible. Also, Mike does make a good point up there - spending from a single address isn't paramount to the client, and I'd like to have as few features as possible just for the ease of use to newbies. At the end of the day, anyone wanting the advanced features (or 'graduate') from the reference client can simply use other clients like Armory or even the test-qt by Luke.

[paraipan]

...

Get some sleep, your off by a mile.

...

The correct solution is to implement the sweep function, and make that easily accessible.

Ok, so ignoring smaller previous pull requests that could be the start of such feature is a solution? I remind you that Bitcoin is still beta software.

"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383

I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.

Oh no, not again. The feature is there waiting for an approval that never comes. WTF?

I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?

The point is that people are not supposed to be reusing addresses in the first place, which would make the filter useless.

You are granting people "main developers" status. Don't complain about authority you give people - if you don't like it, don't give them that authority.
But in the end, the decisions you're talking about here have reasons behind them.
Ignoring those reasons isn't the best idea.

Pardon me, but people have authority when things get done through them, or not? So if someone decides over a matter you imply they don't have any authority. I respect Gavin and team for this and because they reached there with allot of hard work and learning, but I don't agree with their "nanny" attitude towards bitcoiners. Hope I make myself understood and you don't beat the subject around the bush.

I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.

As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want.

Yes, there is a problem with getting things merged. But this problem mostly comes down to testing.
You can "fix" it by skipping testing, or getting more people available to test. Only the latter is acceptable to Gavin, and for good reason.

Don't give me that "testing" crap, you know very well the same thing we're discussing here happened to you and many other people. Testing is non-issue when you've already tested all known cases. Unknown are to be discovered, just like the recent database fork that even Satoshi himself couldn't foresee.

[2112]

Because coin control is a complex way to achieve any given goal. It requires you to understand the transactional nature of the Bitcoin protocol. Fine for super-fans who don't mind studying, a bit of a pain for anyone who isn't. Look at how confused even some developers get about the relationships between addresses, balances and transactions.

So if coin control exists, what that means is people who aren't power users can't solve whatever problem the power users are solving with it. It'd be better to find solutions to the underlying problems, and then everyone can benefit. And often, I bet we can find fully automatic solutions, so it can be more convenient for power users too.

Making Bitcoin usable by everyone is an important goal, and thus so is understanding what people do with it. That's why I'm interested to know what people want coin control for. It's not a "I want to invade your privacy" thing, it's a "how can the software be better designed for everyone" thing.

Saying "I want to spend from a single address" is not a good explanation, by the way, it's just tautological. Why do you care about the precise outputs that are being spent? What is the high-level goal here? Is it to simplify your accounting? Is it part of some other scheme?

Actually coin control GUI would be an excellent teaching tool to help the beginning users and developers understand the Bitcoin protocol.

At the same time this is exactly why people who think like Mike Hearn oppose it: they oppose educating people about the inner working of the machinery. The key to control the people is to make them believe that they really need somebody more knowledgeable to ensure their safety.

Coin control is a beautiful example of anti-paternalistic stance and how it aggravates anyone who is a paternalist and wants to treat every user like a potential "grandma" or whatever else is the current polite word for "mentally deficient".

I think the Bitcoiner emancipation movement is getting formed here and now.

[Luke-Jr]

The correct solution is to implement the sweep function, and make that easily accessible.

Ok, so ignoring smaller previous pull requests that could be the start of such feature is a solution? I remind you that Bitcoin is still beta software.

But it isn't the start of such a feature. It's the end. The start needs to come before the end.

"Add user interface to set dust limit and filtered addresses" - https://github.com/bitcoin/bitcoin/pull/2383

I agree this would be nice (in some form), but the filtering is inevitably a political move to try to force others to stop reusing addresses. While I think that may be necessary, it's arguable whether it belongs in the reference client.

Oh no, not again. The feature is there waiting for an approval that never comes. WTF?

I refuse to fork or join or split or whatever. The code is there waiting for what? Main developers mercy?

The point is that people are not supposed to be reusing addresses in the first place, which would make the filter useless.

You are granting people "main developers" status. Don't complain about authority you give people - if you don't like it, don't give them that authority.
But in the end, the decisions you're talking about here have reasons behind them.
Ignoring those reasons isn't the best idea.

Pardon me, but people have authority when things get done through them, or not? So if someone decides over a matter you imply they don't have any authority. I respect Gavin and team for this and because they reached there with allot of hard work and learning, but I don't agree with their "nanny" attitude towards bitcoiners. Hope I make myself understood and you don't beat the subject around the bush.

Nobody is deciding this for you, except yourself. If you choose to go with Gavin or someone else's decision, that is still your choice to do so. You can just as easily decide to ignore Gavin on this, and merge the branches yourself, as everyone has been trying to tell you.

I enjoy only using Bitcoin-qt, this way my coins are safe and I help the network because other implementations aren't even considering this issue. People create features and submit them to Bitcoin mainstream client, where main developers actually get "free lunch" and only have to merge those. What you don't understand from that? They have a long record of not accepting even minor changes and leaving them rot on Github. This puts off people wanting to help or develop new features more every day.

As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want.

Yes, there is a problem with getting things merged. But this problem mostly comes down to testing.
You can "fix" it by skipping testing, or getting more people available to test. Only the latter is acceptable to Gavin, and for good reason.

Don't give me that "testing" crap, you know very well the same thing we're discussing here happened to you and many other people. Testing is non-issue when you've already tested all known cases. Unknown are to be discovered, just like the recent database fork that even Satoshi himself couldn't foresee.

Satoshi isn't a god. Testing is the main issue. One person testing is not sufficient, no matter what the change is.
Some of my oldest outstanding pull requests have had months of testing on Eligius and other pools now, but I can accept that they really need unit tests to truly prove themselves.

[paraipan]

I have read through the thread, and as somebody who uses Armory extensively for the coin control feature plus others, I have to disagree respectfully to paraipan. To cut it short, the reference client should be improved slowly and steadily, thus decreasing the potential vector of attacks as possible. Also, Mike does make a good point up there - spending from a single address isn't paramount to the client, and I'd like to have as few features as possible just for the ease of use to newbies. At the end of the day, anyone wanting the advanced features (or 'graduate') from the reference client can simply use other clients like Armory or even the test-qt by Luke.

John, you're free to use whatever client suits your needs. As I understand you probably use Armory allot, but I don't and my reasons are straight forward, I don't want to use a fancy GUI when the reference client already has one that can be improved.

Push for improvements happens daily but at slower pace than before because few people that are in charge decide is not "safe" for us to control certain things. How is that sounds?

...
Some of my oldest outstanding pull requests have had months of testing on Eligius and other pools now, but I can accept that they really need unit tests to truly prove themselves.

Guess you didn't got any help or support but you keep defending the un-defendable, whatever dude.

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

[paraipan]

...

Coin control is a beautiful example of anti-paternalistic stance and how it aggravates anyone who is a paternalist and wants to treat every user like a potential "grandma" or whatever else is the current polite word for "mentally deficient".

I think the Bitcoiner emancipation movement is getting formed here and now.

+1 nicely put!

[gweedo]

I will leave this right here https://bitcointalk.org/index.php?topic=156334.msg1671697#msg1671697

[Gavin Andresen]

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"

[greyhawk]

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"

Clearly we need a solutions for that. If you would step in the cloning vat for just a second....

[paraipan]

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"

We're both humans and have our time constraints, but what you say doesn't compute.

Where did I complain about you, or developers close to you, not working on the project? If you have read something that I said in OP, and many other posts, the issue lies with your "thick skin" when ignoring or rendering useless many developments to reference client. Addressing them with a "NAK" or having a "nanny" attitude doesn't do any good.

Bitcoin is a protocol and the reference client is it's main support at this moment, so your help is needed to build a healthy ecosystem. With the attitude you have right now you're successfully forcing people to use alternate wallets, insecure and faulty sometimes, so you achieve exactly the opposite of that. The main client/protocol isn't properly documented so compatible clients can't be built from scratch, you keep pushing for changes that break things and make documenting even harder. How we're supposed to work together in this situation?


Edit: I'm a member of the Bitcoin Foundation, hence paying your salary, so I demand an explanation to all of this.

[justusranvier]

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?

Is it ok to grumble a bit about emails that were never acknowledged?

[klaus]

@developers

paraipan does not represent the opinion of us bitcoiners.

[mikeg]

I'm a member of the Bitcoin Foundation, hence paying your salary, so I demand an explanation to all this.

With friends like these...

[🏰 TradeFortress 🏰]

So....  move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.

Ok, start a "Bitcoin-QT Poweruser" fork, and let people submit their heart's desire. Without you doing this it will have 0 credibility, including from me.


Edit: Hope you're not coming in from above just to go back again after you said only 2 words.

Why don't you make a bitcoin fork, but not a network fork?

[maqifrnswa]

So....  move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.

Ok, start a "Bitcoin-QT Poweruser" fork, and let people submit their heart's desire. Without you doing this it will have 0 credibility, including from me.


Edit: Hope you're not coming in from above just to go back again after you said only 2 words.

Why are you relying on your nanny-state oppressor to provide the fork you want when you can make one yourself and let people submit to their heart's desire? That is what is supposed to happen (see https://bitcointalk.org/index.php?topic=22434.0)

Galvin is gaining credibility amongst the community by not including every patch/feature people request.

[misterbigg]

The developers have more in common with Richard Stallman than they do Joe Bitcoin. Case in point, they shut down the whole #bitcoin channel on Freenode, voicing only a few individuals, so they could make a dog and pony show of some M of N signature transaction feature nonsense. Why didn't they just do it in #bitcoin-dev?

But looking at the bigger picture, are these really the most important features? We still don't have an official 1.0 release and these people are still saying that after four and a half years "Bitcoin isn't ready for people to use yet." The arrogance and condescension this projects is enormous.

It's a shame that the wonderful Bitcoin project is controlled by neckbeards whose values are so completely at odds with commercial success as to be laughable.

[behindtext]

paraipan,

you are being such an open source troll, it is very annoying. i am reminded of why i unsubscribed from misc@openbsd.org several years ago when i read your posts.

the same way you chided the bitcoind devs, i am now chiding you: who do you think you are to dictate what a bunch of (presumably) unpaid open source developers choose to contribute to a project they hack on and maintain? i somehow doubt you have compensated any of the devs in such a way that it would justify your acute agitation.

i do think there is some merit to your claim that the devs exercise an unusually large amount of control over the project when there should be a (well) documented standard protocol. i believe this is done on purpose to facilitate centralization of power and make it difficult to create a working alternative to bitcoind.

[Jackten]

I hope none of the developers actually read this ungrateful dribble.  It's open source you fucking dick.. if something is so important to you that you're going to make stink, fucking do it yourself or pay someone else to do it if you lack the skills.  Goddamn, this isn't fucking politics

[johnyj]

I think miners should pay developers so that they can get more people to do test, is it possible to implement this in pools?

[ShadowOfHarbringer]

@developers

paraipan does not represent the opinion of us bitcoiners.

Definately.

I personally, like the slower way better. I don't want to lose money because of a serious bug in the code. Do you, paraipan ?

I think this whole thread is therefore pointless. There are and there will be forks. There is armory. If the code is good enough, it will be merged into mainline. OR a lot of people will use it instead of the mainline client.

You can have either more features faster OR more stability faster. You can't have both at the same time.

[paraipan]

...

Definately.

I personally, like the slower way better. I don't want to lose money because of a serious bug in the code. Do you, paraipan ?

I think this whole thread is therefore pointless. There are and there will be forks. There is armory. If the code is good enough, it will be merged into mainline. OR a lot of people will use it instead of the mainline client.

You can have either more features faster OR more stability faster. You can't have both at the same time.

I wont call names and keep calm.

That's the whole point of this thread! We don't have stability because Gavin and team are focused on implementing stuff that breaks things, like continuously modifying the underlying protocol, instead of properly documenting it and improving the client on the user side. Who do you think he got the smart idea of increasing block size in the first place? Yeah you guessed it, it was Gavin. He told pool owners they can try raising the limits. What happened after that? You probably know, the blockchain split a few days ago.

[ShadowOfHarbringer]

...

Definately.

I personally, like the slower way better. I don't want to lose money because of a serious bug in the code. Do you, paraipan ?

I think this whole thread is therefore pointless. There are and there will be forks. There is armory. If the code is good enough, it will be merged into mainline. OR a lot of people will use it instead of the mainline client.

You can have either more features faster OR more stability faster. You can't have both at the same time.

I wont call names and keep calm.

That's the whole point of this thread! We don't have stability because Gavin and team are focused on implementing stuff that breaks things, like continuously modifying the underlying protocol, instead of properly documenting it and improving the client on the user side. Who do you think it got the smart idea of increasing block size in the first place? Yeah you guessed it, it was Gaving. He told pool owners they can try raising the limits. What happened after that? You probably know, the blockchain split a few days ago.

1. The blockchain split was only mildly serious bug. AFAIK nobody lost their money.
2. The increase of block size was done to ensure scalability of the network ! So it is stability we are getting.
3. The problem existed not because of bug in Bitcoin, but because of bug in BerkeleyDB. Which was used by Satoshi himself, not by Gavin.

Coincontrol and such is a fancy new feature which is not critically necessary to proper functioning of the network. But proper block size is. So it got addressed more quickly, like it should. I don't see anything unusual about that.

[gweedo]

...

Definately.

I personally, like the slower way better. I don't want to lose money because of a serious bug in the code. Do you, paraipan ?

I think this whole thread is therefore pointless. There are and there will be forks. There is armory. If the code is good enough, it will be merged into mainline. OR a lot of people will use it instead of the mainline client.

You can have either more features faster OR more stability faster. You can't have both at the same time.

I wont call names and keep calm.

That's the whole point of this thread! We don't have stability because Gavin and team are focused on implementing stuff that breaks things, like continuously modifying the underlying protocol, instead of properly documenting it and improving the client on the user side. Who do you think it got the smart idea of increasing block size in the first place? Yeah you guessed it, it was Gaving. He told pool owners they can try raising the limits. What happened after that? You probably know, the blockchain split a few days ago.

1. The blockchain split was only mildly serious bug. AFAIK nobody lost their money.
2. The increase of block size was done to ensure scalability of the network ! So it is stability we are getting.
3. The problem existed not because of bug in Bitcoin, but because of bug in BerkeleyDB. Which was used by Satoshi himself, not by Gavin.

1) Actually some miners lost coins, and Gavin being the such the nice guy :/ gave them the coins to cover up his mistake (He should just done more testing)

2) Actually we aren't even hitting the current limit so they are just arbitrary upping the limit.

3) No, they didn't configure it correctly in bitcoin program, so cause Satoshi didn't see the limit getting hit by bitcoin blocks we should blame him LMAO. Gavin is maintaining it he should have seen it being hit WITH TEST. No test was performed. So that is completely 1000000000% Gavin's fault.

Honestly the core developers view's are so different from real bitcoiners. It is impossible to run a full node with out aligning your views with them, thank god for armory for allowing me to continue to help the bitcoin network and be trust-less.

[mrdavis]

Honestly the core developers view's are so different from real bitcoiners

Please, explain the views of "real bitcoiners" Or at least tell me who real bitcoiners are if it's not the people that have been maintaining the code base for longer than most have even known of the existence of bitcoin. Or by "real bitcoiners" did you mean you? If that's the case, I can breathe a sigh of relief that the devs views differ.

[gweedo]

Honestly the core developers view's are so different from real bitcoiners

Please, explain the views of "real bitcoiners" Or at least tell me who real bitcoiners are if it's not the people that have been maintaining the code base for longer than most have even known of the existence of bitcoin. Or by "real bitcoiners" did you mean you? If that's the case, I can breathe a sigh of relief that the devs views differ.

I define real bitcoiners as people who everyday are trying to push bitcoins, trying their hardest to make it stand out in the outside world. Just power users in the sense that everyday they are head deep in bitcoin 24/7. The core developers don't have time for that, or they say they don't. Views of those people are keeping these core values of bitcoin which I think each day, the core development team is moving farther and farther from some of them. With certain aspects of the where the client is going, you can see that views are changing to something that I find not what I would consider the official bitcoin client.

Now I know everyone is going to say build your own then, I have tried and let me tell you it takes more time then I can spend doing it. There is no documentation and the little documentation is out dated. I recently tried again and I got some blocks to download when just connecting to my own bitcoind node, and no one else. They need to real start looking more like an open source team then a team that is hiding behind the foundation. I honestly can't believe the lead developer is head of the foundation, and 2 business that complement each other are together.

So the views will never align with real bitcoiners, and I don't count newbies views, cause they are learning and sucking in information. When I was a newbie I didn't really form my opinion about things I just took the information researched it for validity and accepted it. Now I am very well informed and can my own opinions and know how everything works in the community.

[ShadowOfHarbringer]

So....  move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.

Ok, start a "Bitcoin-QT Poweruser" fork, and let people submit their heart's desire. Without you doing this it will have 0 credibility, including from me.


Edit: Hope you're not coming in from above just to go back again after you said only 2 words.

Why are you relying on your nanny-state oppressor to provide the fork you want when you can make one yourself and let people submit to their heart's desire? That is what is supposed to happen (see https://bitcointalk.org/index.php?topic=22434.0)

Galvin is gaining credibility amongst the community by not including every patch/feature people request.

Gavin is including very, very few patches and features people have requested. Even extremely well-tested ones, like coin control.

[Citation needed]

Also, he is probably frightened of breaking something. I know i would be in his situation.
We're talking hundereds millions of dollars, this is no joke.

[gmaxwell]

Gavin is including very, very few patches and features people have requested. Even extremely well-tested ones, like coin control.

It would be nice if people didn't outright lie here. The original coincontrol patches were a somewhat broken kludge. The address grouping parts were merged after a bunch of fixes (and even still— a crash bug crept through and I didn't find it until the next release), but no one was willing to step up and fix the problems that were pointed out in the GUI part on review.

There is a new coin control patch now which is a complete rewrite and not based on the old stuff— it's based on some coin selection modification things that Jeff subsequently wrote. It's my opinion that something along these lines should eventually go in. Though I think Jeff and Gavin would like to see more of these things done externally— because we can get more "feature velocity" if feature can be moved away from the really sensitive parts of the codebase.

[ShadowOfHarbringer]

@gweedo, @Wolf0, @paraipan

Do you actually fully understand seriousness of this situation  ? Because I don't think you do.

Gavin and other devs either are or will be under enormous pressure when they manage a code that manages **1 billion of USD worth**. And it will only get worse as the market grows.
I surely know that i wouldn't merge just any code into the main branch if i was in his situation. Do you think anybody wants to be responsible for people losing hundered millions $$$ ? Nope, one does not.

Do you know that banks and large corporations, even today, use code that has been written 10, 20, 30 and MORE years ago ? Do you know why ? Because it has been thoroughly tested, it is 100% stable and it just works.

So not only is the "slow way" the good way, but the ONLY ACCEPTABLE way. Keep all the new cool and funky stuff out of the mainline client, until there is absolute certanity that it is stable.

[gweedo]

@gweedo, @Wolf0, @paraipan

Do you actually fully understand seriousness of this situation  ? Because I don't think you do.

Gavin and other devs either are or will be under enormous pressure when they manage a code that manages **1 billion of USD worth**. And it will only get worse as the market grows.
I surely know that i wouldn't merge just any code into the main branch if i was in his situation. Do you think anybody wants to be responsible for people losing hundered millions $$$ ? Nope, one does not.

Do you know that banks and large corporations, even today, use code that has been written 10, 20, 30 and MORE years ago ? Do you know why ? Because it just works.

So not only is the "slow way" the good way, but the ONLY ACCEPTABLE way. Keep all the new cool and funky stuff out of the mainline client, until there is absolute certanity that it is stable.

You didn't read my post or even understand it clearly. First off if they released better documentation then I think most companies would roll there own bitcoind, but today it is very hard to do that. So then Gavin is forcing us to use bitcoind and have code that is managing $1billion USD of worth. Why not put some of the pressure off to other developers. I mean bitcoin's core value is decentralized so this would only farther help it. Second I think you are wrong about the banks, I seen some bank backends and they are fairly modern to keep up with security breaches and combat cyber-attacks. So again another lie. Also when do we blame the core development team for issues? Never? I mean come on a Berkley configuration issue, and we blame the Berkley db? Come on WHEN DOES THE BLAME GO TO THE DEVELOPMENT TEAM? This is why issues will never be solved or have head way.

[benjamindees]

As you probably understand main developers consolidate their position by doing this, assuring no one has any significant contribution towards the reference client, so we depend on them for whatever minor feature we need or want.

Paraipan, I agree with your concerns.  And I want to say "thank you" for stepping up to voice them.  I am also concerned about any trend towards needlessly re-writing or rejecting submitted patches for no reason other than consolidating copyright claims, which as many of us know is a common tactic used to close open source projects.

And I'd like to see useful features like coin control added as much as anyone.

BUT, the reference client is a lot like Linux in this respect:  it needs to be stable and boring.  The fun stuff really should happen elsewhere.

Also, that address filtering thing is concerning.

So let's all try to keep reminding ourselves that, for a market the size of Bitcoin,

"move slow" is the right answer.

But if you don't want to promote a more avant garde client like Armory or something, perhaps a plugin system could be developed?  I'm not sure how feasible that is.  Just throwing that out there as a possible solution.

[wumpus]

the same way you chided the bitcoind devs, i am now chiding you: who do you think you are to dictate what a bunch of (presumably) unpaid open source developers choose to contribute to a project they hack on and maintain? i somehow doubt you have compensated any of the devs in such a way that it would justify your acute agitation.

Couldn't have worded it better, thanks for the sanity. I work on this in my very limited free time because it interests me, and unless you pay me to work on stuff I'm the only one that decides what I'm going to do.

i do think there is some merit to your claim that the devs exercise an unusually large amount of control over the project when there should be a (well) documented standard protocol.

Luckily, this is free software, so it's not like I'm holding a critical part of the pie for myself and am unwilling to share it. If you're serious about developing on bitcoin, or want to maintain a 'bleeding edge' fork (I actually wanted to spearhead this in the beginning, but I don't have time for it), you can always ask me questions about the code or how things work and I'll try to help.

I'd love to see some more activity around the bitcoin code base, but the 'official' bitcoin repository is likely not the place for it, as the software that runs the largest part of the network things have to be checked and tested carefully to not break the network etc...

Having said that, I chuckle a bit when I see "Main developers don't give a damn about us" and a few words later we're accused of being nannies and overprotective. So, do we care too little or care too much...  

It's a shame that the wonderful Bitcoin project is controlled by neckbeards whose values are so completely at odds with commercial success as to be laughable.

I love this one too. How do you propose we make this a "commercial success". Sell licenses? Charge a fee for every transaction and send it to Gavin's pocket? Add banners and commercials to the client? Sell statistics about client usage? Maybe we should start a bank! j/k...
Any action aimed at commercializing will inevitably result in lock-ins and centralization. So, be happy we're just a bunch of idealistic neckbeards eh...

[Isokivi]

I hope none of the developers actually read this ungrateful dribble.  It's open source you fucking dick.. if something is so important to you that you're going to make stink, fucking do it yourself or pay someone else to do it if you lack the skills.  Goddamn, this isn't fucking politics

+1
This a hundred times this.

[ShadowOfHarbringer]

I hope none of the developers actually read this ungrateful dribble.  It's open source you fucking dick.. if something is so important to you that you're going to make stink, fucking do it yourself or pay someone else to do it if you lack the skills.  Goddamn, this isn't fucking politics

+1
This a hundred times this.

Ohhhh yes.

You are not forced to use main developer's client. Change the code, make one yourself. Or pay somebody to do it. It is that simple.

Actually I have a say in this, because I already did so when I didn't like just ONE decision of the devs.

[behindtext]

the same way you chided the bitcoind devs, i am now chiding you: who do you think you are to dictate what a bunch of (presumably) unpaid open source developers choose to contribute to a project they hack on and maintain? i somehow doubt you have compensated any of the devs in such a way that it would justify your acute agitation.

Couldn't have worded it better, thanks for the sanity. I work on this in my very limited free time because it interests me, and unless you pay me to work on stuff I'm the only one that decides what I'm going to do.

ppl taking a tack similar to paraipan are all over every open source project, it is a real drag sometimes. complain, complain, complain but they ultimately contribute nothing. to quote theo deraadt "shut up and hack!"

i do think there is some merit to your claim that the devs exercise an unusually large amount of control over the project when there should be a (well) documented standard protocol.

Luckily, this is free software, so it's not like I'm holding a critical part of the pie for myself and am unwilling to share it. If you're serious about developing on bitcoin, or want to maintain a 'bleeding edge' fork (I actually wanted to spearhead this in the beginning, but I don't have time for it), you can always ask me questions about the code or how things work and I'll try to help.

I'd love to see some more activity around the bitcoin code base, but the 'official' bitcoin repository is likely not the place for it, as the software that runs the largest part of the network things have to be checked and tested carefully to not break the network etc...

you are right to point out that the protocol pieces can be extracted from the bitcoind code, but it takes a fair amount of work.

[r.willis]

Yeah, change the code and core developers would whine "do you want to cause chain fork?". If code of bitcoind is the spec, then any non-trivial change is breaking the spec.
Great news: there would be "bitcoin payment protocol" in 0.9. Where is the BIP?

Bitcoin Foundation standardizes, protects and promotes the use of Bitcoin cryptographic money for the benefit of users worldwide.

(emphasis mine)
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.

[2112]

Having said that, I chuckle a bit when I see "Main developers don't give a damn about us" and a few words later we're accused of being nannies and overprotective. So, do we care too little or care too much...  

Please John! Nitpicking on somebody's grammar is not a way to show that you are a great thinker. Let me restate the complaint in a more unambiguous way: core development team cares for some idealized mentaly deficient user, politely expressed as Gavin's grandma. Out-of-core developers and users care mostly for acceptance amongst knowledgeable IT geeks and innovative financial people. There is a serious disconnect right here.

I hope that this disconnect soon will be quantitatvely measured by the sales of Trezor. Originally it was conceived for the "grandma" market. After I and other people applied little presure on the designers there will be two versions: for "grandmas" and for "geeks", the second one being an unlocked device that doesn't use jail and doesn't require jailbreak.

https://bitcointalk.org/index.php?topic=122438.msg1496928#msg1496928

It's a shame that the wonderful Bitcoin project is controlled by neckbeards whose values are so completely at odds with commercial success as to be laughable.

I love this one too. How do you propose we make this a "commercial success". Sell licenses? Charge a fee for every transaction and send it to Gavin's pocket? Add banners and commercials to the client? Sell statistics about client usage? Maybe we should start a bank! j/k...
Any action aimed at commercializing will inevitably result in lock-ins and centralization. So, be happy we're just a bunch of idealistic neckbeards eh...

This strawman is not yet completely burnt, so lets dissect what had left of it.

A simple definition of "commercial success" would be that the sum total of income of everyone involved in the enterprise is positive and increases as the product adoption increases.

A simple example of "commercial failure" would be an enterprise where the "accounts receivable" department gets all the bonuses, "accounts payable" department is constantly getting laid off and the "research and development" department lives on the handouts received openly and the bribes delivered in secret. Do you recognize it? This type of operation is sometimes called "asset stripping".

The original ideal of Bitcoin was that every peer would be its own accounts payable, accounts receivable and some of the peers will do R&D on the side while doing accounting. It didn't work out that way: the accounts receivable function broke out of the ranks and concentrated into the mining pools. This destroyed the balance of the original design. The balance needs to be restored by some compromise.

Being a businessman is an art of forging compromises.

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

[phelix]

[...]

"coin control / less change / refactor coin selection" - https://github.com/bitcoin/bitcoin/pull/1017

For a popular feature, nobody was willing to take the effort required to address problems with it, until very recently (too late for 0.. Hopefully it will make it into 0.9.
[...]

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

Sounds like I need to get around to spinning a 0.8-based next-test release, though...

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

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

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