Topic: Invoices/Payments/Receipts proposal discussion - page 8. (Read 24728 times)

IMO, bitcoin is mainly a monetary system with secure transaction function. As a monetary system designer, business oriented practice is a too low level of concern. FED will never care about what paypal or VISA is doing, that is many levels lower down the importance chain

The monetary policy of bitcoin has already been written into stone by Satoshi, but there are still many area to improve regarding the performance and reliability. Only the security part will bring a normal user lots of headache. I just heard that someone lost 150 coins in an offline wallet with a 20 character strong password and he doesn't understand at all what went wrong

I'm the "proposer" and I know exactly what the interlock protocol does.  It flatly prevents a MITM from altering your communications with someone else while allowing you to communicate at all.  That is what I said, and that is what it does.

The MITM has to make an immediate choice when faced with Diffie-Hellman over Interlock Protocol.  He can either try to impersonate one or both sides of the conversation completely (refusing to allow you to communicate at all) or he can allow you to communicate, whereby he immediately loses the ability to eavesdrop on or interfere with your communication at all except by cutting it off.

Good protocol for secured channels works like this: 

1) All Protocol negotiation via Interlock protocol to ensure that you are talking to exactly one endpoint  (which may be an MITM, but if so will definitely *not* be communications from your intended endpoint as altered by an MITM).

2) Diffie-Hellman Key exchange via Interlock Protocol to establish a private key (thereby cutting out potential eavesdroppers).

3) Authentication via shared secret to make sure that the endpoint you are talking to is in fact the endpoint you want to be talking to, ie, not the MITM. 

Protocol security (steps one and two) secures the channel.  Authentication (step 3) is not addressed by securing the channel; it is addressed by a shared secret.  It might also be addressed by 509 certificates to the extent that people trust them. 

What I said about SSL is that we ought not rely solely on the keys in those certs for securing the channel.  SSL is a hybrid monster that conflates securing the channel with authentication, and they are two separate jobs. 

SSL, trusted third parties and all, is a better method than any zero-trust protocol for authentication between strangers.   Knowledge of the private key corresponding to the public key in an SSL certificate is not quite as good as a shared secret due to CA trust issues, but by definition you can't have a shared secret with a stranger, and it's a pretty good proxy for knowledge of a shared secret.  We can use it for that, and I'll have no objections.

But using SSL to secure the channel (ie, trusting the keys in those certs _and_nothing_else_ to prevent eavesdropping or alteration of messages in flight) is a method inferior to zero-trust protocols, and I *will* be upset if using SSL authentication reduces us to using SSL to secure the channel.

Okay sure, but it's well established that you're a weirdo: You use windows.

Well, to me it's sexy to improve and work on the UI at least .

Dia

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

Most of the devs I know have a habit: They must do something every day 

But I tends to believe, upon certain maturity level, the more you try to improve it, the worse it gets. Raised level of complexity will reduce the robustness and flexibility of the system and result in more compatibility problem and customer confusion. A good approach is to be always prepared, but do NOTHING when it is not necessary

Although nothing is done, this wait and prepare action is high valuable and worth getting paid

It won't. The messages are sent directly between the user and the merchant/service that is sending the payment requests, then stored locally, presumably by both the user and the merchant/service.

I see. Your content seems rather concentrated around the way I'm saying something, or the internal workings of my mind, projecting emotional states onto me, or simply diverting from a coherent direction of discourse. I think we'll leave it there, you're appearing to be manipulative as well as impolite.

I'm earnestly confused here— honest to god derpy look on my face confused—, I'm not trying to be snippy or anything at all like that. What you were saying made so little sense to me that I am concerned that I am mis-parsing your english. Your sentenced was, indeed, grammatically sound but ducks inverted my rutabaga.

Talking to someone confused about something, who is loudly angry as a result of the confusion, and is not following a clarification in part because of their anger can be a little frustrating to deal with... but in this case I'm not even frustrated because I can't actually figure out what y'all are thinking.  It's just mystifying to me.

I suspect that you have a very incorrect model in your head of how this stuff works, what the goal is, and what the consequences are... but I can't quite figure out how.  CAs seeing payment requests is basically a martian comment, as it has no semblance to how CAs work (much less how payment requests work), so I know something is wrong. I think I'm reasonably skilled with helping people through misunderstandings, but to do so I first need the start of an idea about what the confused person is thinking.

What I've found works when people have unclear complaints about Bitcoin is I suggest we roleplay.  You are the attacker out to harm people. Tell me what you'll do and what you'll get out of it, and I'll "defend" by telling you why your attack fails (or ask for clarifications for 'attacks' that are too non-specific).

There we are, that's better! If you want to answer the questions I have asked you, but in the form of a response to some other part of the dialog, then I can add the clarity myself by bringing the two together via cut and paste. It makes the conversation appear less intransigent to those that are following it. Why don't you want to answer the question directly? Why is it necessary to use personal sleights in your indirect answer?


My apologies, but you were incomplete in the way that you described your non-repudiative case, the subject of the repudiation was ambiguous. The above more than satisfys a complete description.

"Word salad" is an expression that's used to describe sentences that are logically and/or grammatically obtuse. My sentence made sense, but didn't describe a situation accurately. A little less haughty, please, you are being impolite.

Indeed, why bits of the truth will come out every time those sneaky devs do a git push! 

Your agonizing clarity is failing me. Sorry.

Huh. This appears to be word salad. There is no CA signing of any part of a payment request itself. None at all.

Why don't you try to explain to me step by step how you think it works and I'll point out where we are occupying alternative universes.

The only signed data is the request to pay, which is signed by the merchant (when used, it's optional), and the merchants own credentials which are part of a certificate he sends (if he is doing the optional signing).

No. I'm not talking about that at all.

Nothing stops you from sending unsolicited requests to pay.

A payment request is like an invoice, it forms an agreement "I'll send you the things listed on the payment request, if you pay this amount to these scriptpubkeys." the request can be signed so that you known who its from, and the signature is non-reputable so that if they don't make good on the deal you can show someone the payment request (and the transactions in the blockchain) as evidence that an agreement existed and you kept up your side of the deal.

@gmaxwell, @Gavin Andresen, @Mike Hearn

I have run out of time and Brain-CPU cycles that can be used for this particular discussion, but judging by preliminary analysis of the topic I will (logically) assume you are right.

However i will be closely watching the run of events - If you were wrong, the truth will come out eventually.

Wallets don't use it, but isn't it like: wallets use OpenSSL that uses parent certificates installed in the OS, and it is the OpenSSL+OS that eventually asks the revocation server, without leaving the wallet any control over the actual process?

Sorry - it might be a stupid question, I don't know how it works, so just asking.

Well, you in fact addressed a different concern, one that I do not share. The notional concern that you are talking about is that of generating a proof that a given payment request was instantiated at the users end, such that a webmerchant cannot be accused of sending unsolicited requests to pay.


I will be agonisingly clear. The recipient of a payments request has no way of knowing that a request will be initiated, unless they analyse the code behind every event triggering piece of interface on every payments form on every website they use, every time they use it. The website can choose various ways of utilising the Payments Protocol, for instance using the CA or self-signing. This is all a consequence of the directionality of the request itself. Logically, it can only ever come from the requester. Payee will never request payment from themselves using the Payments Protocol.

Therefore I cannot know whether my personal details are to be signed by a CA until after the event has taken place. This is a concern. If you are saying that this is not a correct description, and that the message is communicated directly between user and merchant using SSL, then please be more explicit in confirming this.

If you're saying that the non-repudiative proof is the only information signed by the CA, then please be more explicit in confirming this.




Your own text (bolded) does not constitute such a comment?

It would be great if we could be purists about everything Bitcoin-related being totally zero trust, always, but there often isn't any technical way to do that. That's why we've ended up with centralised exchanges and so on. Some people even use third party wallets or payment processors.

If you believe you found a way to provide the features the PKI provides, except with no third parties, then go right ahead and show us how (in a new thread please). In the absence of such a breakthrough, we roll with the best we've got, which is a protocol in which anyone can sign keys for anyone else, along with a bunch of companies who do a professional job of it "out of the box".

It's a shame my first sentence didn't make any sense, because now I can't edit it. Damn. That's what I get for having 3 hours of sleep and coming in to work early...

I understand what the CA's role is and how the payment protocol works.

I was simply outlining the fact that despite there being a good use-case for this update as well as very small or no technical side-effects, people here are against setting the precedent of implementing code into Bitcoin which necessarily relies on a "trusted" 3rd party, even if that feature is optional.

Yes, back when OCSP was designed, that didn't seem to be a big deal. Wallets don't use it anyway.

You could theoretically design a new version of OCSP that used oblivious set intersection, so although the server would see your IP, it would not see what your query was and thus would learn nothing beyond "someone behind this IP wanted to know the status of some certificate", which isn't a very useful piece of information to have. Or you could query via Tor, etc.

But as I said, revocation is rare. Browsers just have a hard-coded list, and wallets would probably end up the same, if they ever needed to revoke a cert for some reason. Then there's no server at all. Nice and simple.

It's not a "technical side effect" it's what it does. If you don't care about non-repudiation then you don't need to care x.509 certificates in the payment protocol at all.

I'm struggling at trying to figure out your understanding of the payment protocol world. Are you under the impression that CAs would sign payment requests or control private keys? Thats not the case.  Only the requester and the requestee will see the payment requests.  If x.509 is used its used so that when you receive a payment request signed by a particular party your client (and anyone you show the payment request to) can use their certificate to validate that the request was signed by the right party.

The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.