Invoices/Payments/Receipts proposal discussion

[ShadowOfHarbringer]

SERIOUSLY, SHADOWOFHARBINGER:

I LOVE IT WHEN PEOPLE SHOUT AT ME! IT IS A GREAT WAY OF MAKING ME REALIZE THE FOLLY OF MY WAYS, GIVES ME WARM FUZZIES, AND MAKES ME WANT TO COME BACK TO THESE WONDERFUL FORUMS AGAIN AND AGAIN!

I'M GLAD YOU LOVE IT, I WORKED SO HARD ON IT !!!!!1111111oneone

----
But seriously, i do love to emphase important parts of my posts.

[Carlton Banks]

Sorry for butting in, I don't know enough about the inner workings of Bitcoin to contribute to this thread but the questions asked by ShadowOfHarbringer are what's worrying me too. Is this introducing a single point of faliure?

Not a failure point, but an authority point. And it's not a point of absolute authority, it's conditional (conditional on whether or not you're using the Payment Protocol).

The concern is that conditional gently gets transformed into absolute. I think we'd all prefer a trustless 2 party solution to MITM attacks to this proposed trust-based 3 party solution.

[StarfishPrime]

From what I've seen there's no requirement to use the new protocol, and even when using them the use of CA certificates for signing is optional anyway, so some of the concerns being discussed here might not be a real problem.

Some of us do however have an issue with introducing third-party support/reliance of any kind into a system that was explicitly designed to be free of any centralized dependencies.

Only time will tell if anyone outside of a few payment providers, etc. actually use the protocol, but it could eventually evolve into something useful, with or without CA support. The core devs deserve credit for at least attempting to add this functionality, there's always bound to be some push back regarding feature implementation.

[Carlton Banks]

From what I've seen there's no requirement to use the new protocol, and even when using them the use of CA certificates for signing is optional anyway, so some of the concerns being discussed here might not be a real problem.

Yes, but how many of this target audience of newcomers are actually going to understand the implications of sending a CA signed payment request? Perhaps more than previously would considering the current political debates around privacy, but the whole cryptocurrency concept has more than enough obstacles to comprehension as it is, and that's despite the current clients being pretty simplistic in their layout and operational dialogs. Doesn't stop the rabbit in the headlights look on the face of the uneasy, I have seen this IRL.

[...]but it could eventually evolve into something useful, with or without CA support. The core devs deserve credit for at least attempting to add this functionality, [...]

This I can wholeheartedly agree with. The messaging aspect of the Payments Protocol is vital, we should be accepting any feature that reduces people using the blockchain to store anything other than BTC transactions. I can't help thinking that the MITM problem should be dealt with differently, especially considering:

1) It's not a widespread problem right now (or even at all? are there any recorded cases of public keys being transposed to the key of an interloper?)

2) There are low tech solutions that webmerchants could use that would be non-standard. A standard is a single point of failure in a way, as it provides a uniform way to exploit it, no matter the software the sender and receiver are using. Attacks on bespoke methods of transmitting public keys to the sender are less likely, there'd have to be consistently attractive tx sums to be worthwhile.

[ShadowOfHarbringer]

@Gavin Andresen

Several questions:

1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?
2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?
3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?
4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?
Isn't the invoicing possible to do through third party app or in-browser using SSL ?
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?

[Carlton Banks]

...
The concern is that conditional gently gets transformed into absolute. I think we'd all prefer a trustless 2 party solution to MITM attacks to this proposed trust-based 3 party solution.

Thanks. The chance of an extra becoming a requirement is worrying, it sounds a lot like MS's embrace, extend, destroy practices. Iirc SSL was just a currently working solution and that layer could be replaced or other solutions added to it at any stage later, is that right and if so does it still work that way? I don't know what 2 party trustless system is proposed but it sounds like the obvious answer, guess I have some reading to do

There are no documented plans to make the Payment Protocol a required way to pay, it would require significant additional changes to the design. It does introduce a foundation into which such a change could be made, though.

There is no formal proposal for a trustless public key transmittance that I'm aware of, but it could be done in a variety of simple ways without the need for CA verification of the message. I see no good reason why (on balance) self signed messages couldn't work, for instance. It's not such a bad trade off to having your public keys matched to your real world identity, I'd live with that.

In fact, if (more like when) we do end up increasing the 1Mb block size limit (something I can agree is ultimately necessary), why not use the storage of merchant certificates on the chain a part of the justification for it? It's the single exception I would consider to wanting to prevent the blockchain being used for non-transaction information.

[ShadowOfHarbringer]

@Gavin Andresen

I'm not shouting anymore, but I am still humbly awaiting for your answers to my questions, please.

I am not in a hurry, however I am also afraid I won't receive them at all.

[Quetzalcoatl_]

@Gavin Andresen

Several questions:

1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?

This is not just a hypothetical concern. It is a known fact that not only the NSA, but hacker groups have copies of CA certs, which they use to perform MITM attacks against HTTPS. The CA model is insecure.

[Carlton Banks]

it sounds like its adding a messaging system that will need information other than transfers of funds to be passed.

Not necessarily a bad thing, it depends what the message is!

SatoshiDice is the classic example. They were using lots of single Satoshi transactions as a way of proving the validity of their bets. Blockchain space got gobbled, Bitcoin devs had to contemplate how to dissuade them from doing this. They weren't sending money for the purpose of someone else receiving that money, they were doing it as a way to send a message that had the effect of providing evidence of the trustworthiness of their betting system.  

Payments Protocol solves this problem, but also gives the person who draws up the payments request the option to have the message authenticated by a CA. This is where your own personal details might get associated with the public key you use to pay that person. In a webshop -> customer transaction, the webshop might include the product, and a confirmation of the Name & Address to deliver to. The information in the message is all under their control, and we now know this can be slurped by the CA, and in turn by our friends at the NSA.

There's no reason to assume the payment requester to disclose details that identify either you or your purchase items in the Payments Protocol message, this is not mandatory to the protocol (I hope!). Although, the merchant requesting payment should choose something useful to the user, and relevant to the transaction. Imagine buying from a webshop, confirming the order, being presented with a payment request message triggered in your Bitcoin client, and the message being completely or nearly blank! It would seem a little strange, you'd wonder if the Payment had been successfully attacked and you were sending your money to an attackers address (the attacker's method maybe didn't or couldn't copy the message into their spoof message).

And so there lies the rub, you can kind of assume that the more correct information about the transaction that the merchant includes, the more convinced the end user will be that they're accepting a request to pay from who it's supposed to be from. And hence the more information for the NSA to slurp.

[Cryddit]

Gweedo, I think you're being rude.

Until you're willing to put up time and effort developing code, don't harsh on someone who does.

That said, I don't think Bitcoin needs SSL for any security purpose, and should not rely on it for any security purpose.  If we need it at all, it's for purposes of making it easy for websites to accept bitcoin payments using a system they already know how to use and already have set up.  But I don't see how we can do that unless the communications are otherwise unsecured (ie, insecure), so I don't really think it's a good idea.

Short answer; I don't think you'll be able to order things directly from Amazon.com using Bitcoin until this is done.  But if we have it at all, I don't think you'll be able to order things from Amazon.com with any security greater than it provides now.  And, in fact, even less, because if you use it with a bank, credit card, etc, you can always reverse bogus charges.  With Bitcoin that isn't, and won't, be possible.  

Because Bitcoin has a higher security requirement in the first case, due to its non-repudiability, I don't think that SSL is adequate to secure Bitcoin payments.  It's okay for payments you can challenge or reverse, but it's not okay for Bitcoin.  The right answer is that Amazon.com and company need to man up and accept some genuinely secure protocols to process payments.

Bear

[al.matic]

For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you. I don't see the problem with this in restaurant/bar scenario.

[gweedo]

Gweedo, I think you're being rude.
Until you're willing to put up time and effort developing code, don't harsh on someone who does.

Wait so you agree Gavin should be rude to people that make him rich because they use bitcoins. Also since I working on startups and helping people get started in bitcoin I guess that isn't as good as people who write the reference client right? I work harder on bitcoin in a way to get more people involved instead of writing code, and just making myself rich. I am making the community richer.

[Carlton Banks]

For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you. I don't see the problem with this in restaurant/bar scenario.

Sounds like what I'd prefer.

Why not implement ZRTP as 2 party "trustless", then make a clear distinction between the two payment methods? I already trust Bitpay not to scam me, I have no problem with continuing to accept that risk at my end of the deal as a way to protect association of my public keys with my identity.

[al.matic]

For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you. I don't see the problem with this in restaurant/bar scenario.

Sounds like what I'd prefer.

Why not implement ZRTP as 2 party "trustless", then make a clear distinction between the two payment methods? I already trust Bitpay not to scam me, I have no problem with continuing to accept that risk at my end of the deal as a way to protect association of my public keys with my identity.

It is only useful if you have separate channel to verify the PIN/SAS (similar to Bluetooth pairing), like in the restaurant where you can visually verify it.

[Carlton Banks]

For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you. I don't see the problem with this in restaurant/bar scenario.

Sounds like what I'd prefer.

Why not implement ZRTP as 2 party "trustless", then make a clear distinction between the two payment methods? I already trust Bitpay not to scam me, I have no problem with continuing to accept that risk at my end of the deal as a way to protect association of my public keys with my identity.

It is only useful if you have separate channel to verify the PIN/SAS (similar to Bluetooth pairing), like in the restaurant where you can visually verify it.

I see. Well, the bricks and mortar businesses can at least prove that you're not subject to attacks that target key exchange as it happens (as in web transactions), but I guess we're trusting that said business hasn't had their wallet software compromised before the transaction is initiated.

[charleshoskinson]

Gavin you ok?

[super3]

SERIOUSLY, SHADOWOFHARBINGER:

I LOVE IT WHEN PEOPLE SHOUT AT ME! IT IS A GREAT WAY OF MAKING ME REALIZE THE FOLLY OF MY WAYS, GIVES ME WARM FUZZIES, AND MAKES ME WANT TO COME BACK TO THESE WONDERFUL FORUMS AGAIN AND AGAIN!

Go back to the foundation forums where everyone pays to kiss your feet. It is sad you can't address concerns of user of the client, that make the price $171 which makes you rich. Greedy Dev core members that is all they are, they do nothing to advance bitcoin.

This guy needs to be banned from the forums. Agree with Gavin or not he deserves your respect for the work he has put into the Bitcoin source. If you don't agree then write an alternate protocol spec yourself.

Can you show me where in the Bitcoin TOS were it says that Gavin must provide support for you?

[gmaxwell]

Why should I be banned cause I posted my opinions and they aren't what you want to hear?

Your incivility is going to scare off the actual technical people from responding on this forum. Already several of them don't, which I think is sad... relatively to the rest of the forum the technical sub-forum is mostly low rubbish.

Treating other people poorly has the effect of silencing their opinions here. It's possible to state just about any opinion without being excessively rude about it, but it seems is nearly impossible there to continue a conversation with some forum members while retaining a bit of human dignity.

Greedy Dev core members that is all they are, they do nothing to advance bitcoin.

Most of us are unpaid volunteers. Nothing I do with development makes me rich. This kind of ignorance just multiplies the offensiveness of your misplaced attacks.

FWIW, I didn't notice the attacks in this thread until someone reported-to-mod them because I had both Gweedo and ShadowOfHarbringer on ignore (though I've been considering removing the latter one lately). I strongly recommend everyone else use ignore aggressively, it can actually be pretty effective.  Even though I do ultimately end up clicking on much of what I've ignored, I find the extra clickthrough to be a good reminder that I've already written that poster's opinions off, and that I expect them to say some hurtful uninformed nonsense. It's less shocking when I find what I expect.

[super3]

Why should I be banned cause I posted my opinions and they aren't what you want to hear?

Your incivility is going to scare off the actual technical people from responding on this forum. Already several of them don't, which I think is sad... relatively to the rest of the forum the technical sub-forum is mostly low rubbish.

Treating other people poorly has the effect of silencing their opinions here. It's possible to state just about any opinion without being excessively rude about it, but it seems is nearly impossible there to continue a conversation with some forum members while retaining a bit of human dignity.

Greedy Dev core members that is all they are, they do nothing to advance bitcoin.

Most of us are unpaid volunteers. Nothing I do with development makes me rich. This kind of ignorance just multiplies the offensiveness of your misplaced attacks.

FWIW, I didn't notice the attacks in this thread until someone reported-to-mod them because I had both Gweedo and ShadowOfHarbringer on ignore (though I've been considering removing the latter one lately). I strongly recommend everyone else use ignore aggressively, it can actually be pretty effective.  Even though I do ultimately end up clicking on much of what I've ignored, I find the extra clickthrough to be a good reminder that I've already written that poster's opinions off, and that I expect them to say some hurtful uninformed nonsense. It's less shocking when I find what I expect.

Ignore seems like a good idea.  . Ha ha. I wish the open-source life was rich and glamorous. This is pretty accurate:

[super3]

Perhaps something good come of this. It might be worth bringing somebody on via the Foundation to help demystify some of the protocol spec, and the new developments. Demystifying some of the core stuff will lead to better discussion, and perhaps avoid misconceptions like these.