Topic: Feature Creep in Bitcoin (Payment Protocol) (Read 1647 times)

Well, that was intentional. I might be corrected, but I don't think Gavin has ever considered the feature particularly important. He isn't opposed to it, and its supported by other core developers but Gavin has been pretty insistent on someone doing a robust test plan for it (and I agree)— which no one has ever done.

Most of the discussion on it has been on bitcoin-development, ... there has been hundreds of messages on it. The complexity is generally self contained. As I mentioned above, I don't personally care _that_ much about it, but I don't think it's problematic in the slightest.

Taking some time to describe all the things you'd normally do with coin control, what you expect the outcome to be, and then walking through them on testnet, and documenting the result and reporting any weirdness would help increase confidence that we could safely merge it.  The concern is that some bad outcome like "I selected less coins than my send value... and it sent all my coin to dev null!" happens for some rare mixture of behaviors. It's good that lots of people have been using it, but usually when someone documents what they're doing it will make some of the less tested interactions more obvious.

They pay Gavin but have no word on what he works on? I think highly of Gavin and hope he will manage to stay independent. What you wrote above is exactly the reason for me questioning.

This sentence can be interpreted in a lot of ways

Nah, I do not even have a strong opinion against the payment protocol but I think there is and has been too little discussion about it. For example, is it really worth all the effort and added complexity? In politics I would say connection to the base has been lost concerning this issue.

The OP is provocative on purpose, hopefully not too rude. I am aware you core devs throw plenty of energy and heart at it but please take the community with you on that trip. Your first answer gave some helping insights already.

OT:
I have always been running coin control since it has been available (sendfromaddress) but never ran into an issue IIRC. Also I donated lately though I rarely do that as I spend a lot time on Bitcoin/Namecoin without getting direct rewards, either. Link on website and I mention it on pretty much every occasion I can.
BTW: Cozz just released v0.8.4 with Coin Control yesterday! https://bitcointalksearch.org/topic/yet-another-coin-control-release-closed-144331

uhh. You're aware that the reference client is an open source project, right? The Bitcoin foundation is a organization primarily oriented in promoting Bitcoin on behalf of businesses and professionals, who are super eager for the payment protocol stuff.  The foundation doesn't control what goes into the reference client, and if it did that would be a pretty concerning event.

No one who has any interest in coin control spent any time on the payment protocol as far as I know. So is this your real motivation, you're out to attack features you don't care about in a misguided effort to boost the ones you do? As an aside, I do see that you appear to have contributed nothing to coin control, including any testing reports or help with test plans. Throwing mud at other features will do nothing to get the feature you want in, but stepping up to help out with testing absolutely will.

Also it sucks up resources. And it makes the client even more complicated. My guess is that it took a large chunk of developer time over the last months? And probably will for a while.

If I were a member of the US Bitcoin Foundation and v0.9 will not have CoinControl I would go nuts over this.

I think thats silly, unenforceable, and doesn't actually change anything in any case.  A payment protocol payment can communicate as little as a pay to address can. ... and if you want to hypothesize about required communications, you could just as well assume that only transactions containing certain data would be legal,  which would be a lot more enforceable if in the future mining is like it is today: controlled by a hand full of super large mining entities.

I suppose the concern is that it opens the door for legislators to rule that only payment-protocol payments are legal ....

Yup, exactly.

Isn't the payment-protocol-enabled-bitcoin compatible with non-payment-protocol-enabled-bitcoin? I was never that worried about the payment protocol because (besides thinking that it was a good thing) it seems to not interfere with any of the core bitcoin functionality. You can still just send to bitcoin addresses and pretend the payment protocol doesn't exist, right?

Remember that the Payments Protocol is in part a backwards compatibility effort to make payments more integrated with the way many commercial websites and their customers expect: allowing proof of purchase that is cryptographically signed by a third party. It's a metaphorical foot in the door into the what makes web-businesses and those browsing them feel comfortable. I would be more concerned if this was the first-and-last Payments Protocol, and it is not that.

Remember that if this attempt drives merchant and consumer pick-up any way, that the metaphorical foot is wedged in a door that swings both ways. Web businesses and their customers could then be alot more likely to feel open to whatever other protocol may be proposed for the task.

Yes, it should. Bitcoin needs exactly this type of layered improvement to make it an even better payments system. This will enhance take-up by a wider diversity of merchants, and novice users will be more comfortable with it. Obviously not all the ideas applicable to the payment space should be supported as that really would be scope creep, but supporting core payments functionality very well is essential.

Thanks for elaborating.

And it has worked well so far.

I have a feeling this is a very large change / addition so I wonder if it really should be a part of the standard client.

In many ways this is a move back to how Bitcoin originally worked:  Originally Bitcoin was setup to use pay to IP,  and the address stuff was a hack for those few cases where you couldn't.  But pay to IP was directly vulnerable to man in the middle and so it was removed. (Addresses are also MITM vulnerable, but we can pretend its not our problem)

Payment protocol solves the MITM at least for many applications, bringing back the moral equivalent of pay-to-ip but in a way which is friendlier with how real infrastructure is deployed.  Does it solve all use cases?  Heck no.  It'd love to have a pay-to-contract system someday that worked better for the OTC model of doing business.  But payment protocol covers some very common cases using familiar mechanisms.

It also addresses some major problems with our ecosystem which were creating long term danger:  The payment protocol provides space for attached messages which doesn't require polluting our highly scarce shared blockchain storage, it provides for refund addresses and easy per-payment addresses reducing the spread of address reuse that craps up fungiblity and privacy for bitcoin users, and it allows the recipient to specify (and pay) the transaction fees— reducing a growing source of bad user experiences for payment processors.

(and it probably does a bunch more— I'm perhaps less interested in the formal merchant use cases and so I've not followed the payment protocol super closely, only enough to realize that it does a lot of things we need)

So sure, you can fault payment protocol for not being ambitious enough. But perfect is the enemy of good and there are a lot of people saying they want and need what this thing does.

reserved

Also discussed here: https://bitcointalksearch.org/topic/invoicespaymentsreceipts-proposal-discussion-128442 Invoices/Payments/Receipts proposal discussion


I'm afraid we might be jumping the shark with all this.