Title: Feature Creep in Bitcoin (Payment Protocol) Post by: phelix on September 04, 2013, 08:12:28 AM Quote from: http://en.wikipedia.org/wiki/Feature_creep Feature creep [...] is the ongoing expansion or addition of new features in a product [...]. Extra features go beyond the basic function of the product and so can result in over-complication rather than simple design. [...] extra or unnecessary features seem to creep into the system, beyond the initial goals. Quote from: https://gist.github.com/gavinandresen/4120476 Requests for payment (PaymentRequests) are tied to authenticated identities using the only widely-deployed identity authentication system we have right now (X.509 certificates signed by root certificate authorities) Is this still Bitcoin? The journalist asked me for some things the payment protocol would allow. Here's the list I came up with:
There are certainly other use cases I didn't think of or forgot about. Also discussed here: https://bitcointalk.org/index.php?topic=128442.0 Invoices/Payments/Receipts proposal discussion I'm afraid we might be jumping the shark (http://en.wikipedia.org/wiki/Jumping_the_shark) with all this. Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: phelix on September 04, 2013, 08:12:50 AM reserved
Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: gmaxwell on September 04, 2013, 08:24:17 AM 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. Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: phelix on September 04, 2013, 09:47:26 AM Thanks for elaborating.
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. 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. Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: solex on September 04, 2013, 11:17:19 AM 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. 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. Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: Carlton Banks on September 04, 2013, 06:59:45 PM 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. Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: chriswilmer on September 05, 2013, 12:12:21 AM 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?
Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: gmaxwell on September 05, 2013, 12:12:56 AM 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? Yup, exactly.Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: marcus_of_augustus on September 05, 2013, 02:48:16 AM 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? Yup, exactly.I suppose the concern is that it opens the door for legislators to rule that only payment-protocol payments are legal .... Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: gmaxwell on September 05, 2013, 02:51:49 AM I suppose the concern is that it opens the door for legislators to rule that only payment-protocol payments are legal .... 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. Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: phelix on September 05, 2013, 09:29:10 AM 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? Yup, exactly.I suppose the concern is that it opens the door for legislators to rule that only payment-protocol payments are legal .... 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. Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: gmaxwell on September 05, 2013, 09:40:17 AM If I were a member of the US Bitcoin Foundation and v0.9 will not have CoinControl I would go nuts over this. 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. Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: phelix on September 05, 2013, 10:29:59 AM If I were a member of the US Bitcoin Foundation and v0.9 will not have CoinControl I would go nuts over this. 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.Quote No one who has any interest in coin control spent any time on the payment protocol as far as I know. This sentence can be interpreted in a lot of ways :)Quote 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? 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: Quote 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. 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://bitcointalk.org/index.php?topic=144331.0 Title: Re: Feature Creep in Bitcoin (Payment Protocol) Post by: gmaxwell on September 05, 2013, 10:52:19 AM This sentence can be interpreted in a lot of ways :) 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.Quote 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. 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.Quote 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. 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.BTW: Cozz just release v0.8.4 yesterday! https://bitcointalk.org/index.php?topic=144331.0 |