Feature Creep in Bitcoin (Payment Protocol)

[phelix]

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.

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:

• Privacy upgrades (better block chain obfuscation)
• Dispute mediation
• Temporary "authorize and hold" type transactions, as sometimes are done with credit cards by hotels/car rental firms/etc
• Subscriptions
• Better support for tipping in service industries
• Security upgrades:
  
  • Being able to receive money directly to a threshold signed "account" so business funds can't be easily embezzled.
  • Tackling viruses that may be on your computer
  • Ability to temporarily extend a corporate identity to employees, e.g. waiters could use their smartphone to obtain a 24-hour certificate allowing them to request money as Starbucks Inc, and then at the end of the day that authorization expires.
• Marking transactions with a "You saved $X by using Bitcoin!" so merchants can pass on some of the savings from avoiding credit card fees, and users wallets can show them a running total of how much money they saved. It's just a neat little psychological trick but I think it'd be cool to see the money you earned by using Bitcoin clock upwards every time you use it.
• Merchant-pays-fee, which would simplify some things for end users. At the moment network fees (though very small) end up being paid by the sender of the money, which can result in weird looking balances and amounts.
• Sending transactions directly by Bluetooth, so you can make purchases without a working internet connection
• Automatic, interaction-less payments to trusted merchants. For instance if you walk into a Starbucks, you don't worry that they're going to scam you because their brand is worth more than that. You can configure your smartphone to just automatically pay whatever they request, when they request it (up to a safety limit). Now you can just walk in, order a coffee and walk out, and nobody ever even has to mention money let alone reach into their pocket. The cashier entered your order on her screen, picked your face and first name from a list of people in the shop, your phone automatically woke up, talked to the tablet they're using, verified their identity via the payment protocol ... and paid them. Done.
• Social network integration, so payments show up as being to names/photos instead of addresses
• Provable person to person payments, so you can sign payment requests with your e-Passport and someone else can prove they sent you the money. Useful for reducing risk for in person cash trading (localbitcoins.com). Currently the payment protocol only supports verified identities for websites and email addresses, but it can be extended in future.
• Assisted calculations for tax returns, e.g. payments can be marked with VAT codes and then your wallet could automatically file the relevant paperwork for you.
• Smart property

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 with all this.

[phelix]

reserved

[gmaxwell]

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.

[phelix]

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.

[solex]

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.

[Carlton Banks]

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.

[chriswilmer]

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?

[gmaxwell]

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.

[marcus_of_augustus]

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

[gmaxwell]

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.

[phelix]

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.

[gmaxwell]

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.

[phelix]

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.

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.

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

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:

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

[gmaxwell]

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.

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.

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 release v0.8.4 yesterday! https://bitcointalk.org/index.php?topic=144331.0

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.