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

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.

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

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.

@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 ?

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.


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.

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.

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.

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.

Payment Protocol could be good, I do understand it helps with MITM attacks. We're just not too keen on the MITM we're in turn volunteering information to being able to identify how much other BTC we have and where else we spend it. A legitimate concern.

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!

Create another subset Satoshi distribution sans Payment Protocol, you're already doing it with your no forced Tx fee distro. Then everybody will have an off the shelf alternative, instead of the lazy route that they could potentially take. If enough objection develops towards the Payments Protocol, it will be dead in the water before potential arguments in favour of removing direct public key payments can even begin.

nee - I would not worry about this; it won't happen, because people (bitcoin community) won't buy it.
still it's a shame that the precious dev resources are being so much wasted.
IMHO if someone had an intention to sabotage the actual useful development of the bitcoin software, he could not have done a better job.

SERIOUSLY, GUYS.

One question:

Devs, did you anticipate that in the future their new CA-Based centralized protocol may become the standard of doing Bitcoin payments ?
And then NSA/USA Govt/World govt/whatever can actually seize the CA and decide who can do business with whom ?

I guess that by the time I'm writing this, governments of the world already figured out that Bitcoin cannot be stopped using the easy "conventional" methods. So they may(or rather WILL) try to embrace, extend and extinguish Bitcoin. 1. First by making it centralized, 2. second by promoting the centralized way of doing transactions, 3. third attacking the single point of failure, thus ending it.

You are just in the process of helping them with the step 2.

Armory won't need the Satoshi client forever. If it's not already possible to make Armory worth with btcd it will be soon.

+1000

Well, i never thought i would agree with you on something, but it just happened.

Adding any kind of "trusted" "root" servers to Bitcoin core totally negates the decentralized nature of the currency. What if in some time, everybody starts to build their buisness solutions of top of this OBVIOUSLY BROKEN centralized scheme and 20 years in the future Bitcoin will turn into another shit like central banks because certificate authorities will control who can and who can't do Bitcoin-related buisness ?


+ 1000

Adding "trusted" certificates of CENTRALIZED entities into Bitcoin code ? I mean *WTF* ?

Except that (as I'm sure you know), Armory interfaces with the network via RPC calls to the Satoshi client. And I know it's not going to be utilising any aspect of the Satoshi client that the PP affects, how could it possibly do so when it's not yet functional in Satoshi itself? The mining nodes are never going to need the payments protocol code anyway, so there is actually a good reason from a technical standpoint for two editions to exist (as well as the holdings privacy standpoint I'm advocating).


MultiBit? I can't trust a Java based client with my mining reserves. I'd actually prefer that etotheipi re-writes the python based parts of Armory in C++, but I understand the python run-time isn't as vulnerable as that of Java, so it's not too uncomfortable. And I also understand that at least some of the time saving algorithmic expression that python has over C++ has been added to the newer standard of C++, so it's more possible than it once was, given that Armory is now a full-time project. Maybe not though, I don't claim to have anything like an insiders understanding of this sort of thing.

Just don't use Bitcoin-Qt. Armory is a better wallet client anyway.

So, who's going to strip the Payment Protocol out of the release it gets into and distribute the binary? Until I see how this plays out longer term, I'm buying dl'ing.

Personally I wouldn't use a client that had anything to do with a Certificate Authority.

I believe that Bitcoin should not be in any way reliant on a 3rd party "authority". The advantages of Bitcoin are enough that it isn't worth sacrificing independence for the sake of those who refuse to adapt.

Of course - luckily for us.

Nevertheless this topic is about "Invoices/Payments/Receipts proposal discussion" - and we are just providing our feedback..