Invoices/Payments/Receipts proposal discussion

[piotr_n]

Do we really want CA support hard coded into the client? Worth some thought.

No we don't, but the core dev team obviously does, since they have paralyzed the bitcoin-qt development for almost a year already, just to give the bitcoin community this great new feature, that no sane person is going to use anyway because of the reasons that are obvious to everyone with a working brain.

Good job, guys!
How much longer are you going to be busy with this useless crap?

[1714852928]

1714852928

[jgarzik]

It is difficult to take this complaint seriously, lacking similar protests for people to stop using SSL + existing CAs when visiting bitcoin websites.

A certain user class is already using certificates and digital signatures.

[piotr_n]

I just don't understand what this SSL based payment processing has to do with bitcoin itself.
For me, and I am an active bitcoin user who uses bitcoins on daily basis, it is a waste of time at best.
Only big corporations will be using such a payment protocol, and since when we care about them?
Big corporations have enough money to invent their own payment protocols, on top of the already existing bitcoin client - which IMHO is exactly the place where a payment protocols should be, definitely not in the core where you are putting it now.

Mike - it is at least clear that he works for Google and his employer has a vast interest in putting hands on any new emerging IT, preferably driving its development into a direction that will make them lots of money in the future. That's BTW also a reason why they found Ripple interesting - because it is something that is supposed to be for bitcoin what fractional reserve system once was for gold; a great money maker.

Gavin - quite similar; he gets paid by "Bitcoin Foundation" - a cartel of a well known companies, that obviously want to comply with all possible NSA "standards and requirements". They don't want US gov to shut them down, so they will do everything to drive the development towards features that will make bitcoin payments "more transparent" and "NSA friendly". It's only logical.

But the rest of you, guys. If nobody pays you for doing this, then I can only ask, what is wrong with you?
Why aren't you working on increasing anonymity, performance, splitting wallet from the blockchain parser, making the core smaller and less dependent on other libs, thus more easy to audit?
Why the hell are you doing the opposite?

Do you really think Satoshi is proud of you today, seeing how you are handling further his great invention?
I don't think so, sirs.

[Cryddit]

It is also possible to use an SSL channel at the lowest level but then layer protocol security on top of it, so that even someone with the SSL keys and a priveleged position on the backbone still won't have an opportunity to eavesdrop or modify messages.   

This buys you everything SSL buys you (linkable identities / CA-level authentication) and yet, can still be a secure protocol even if SSL is compromised (in which case SSL wouldn't buy you anything, so no loss).  Also, protocol security can be used over TCP/IP or even UDP, without loss of anything else.  Note that UDP is enabled by default because any protocol that detects and corrects for MITM message modifications will also detect and correct for line noise; we don't actually need the TCP layer, let alone the SSL layer built on top of it, unless we want linkability to SSL-authenticated identities.

You'd need to ignore all the insecure payment processing crap and protocols that have been built up assuming that SSL is itself a secure channel, and build better ones.  No security model works if the assumptions it's built on aren't true.  But now that we know what we know about SSL, EVERYBODY needs better protocols to use over those channels, not just Bitcoin users.

[StarfishPrime]

I tend to agree with the general concensus on the other thread running here somewhere: That this sort of functionality should be added as a vendor-neutral API interface, rather than being hard-coded into bitcoinQT, which should remain free of third party dependencies/support.

With full respect to the coredev team, this "upgrade" to bitcoinQT seems mostly like a solution without a problem, and not a really great one at that.

BIP38 is an example of a useful proposal that's already well tested and providing real security for many users today (off line storage, etc) why not implement that?

[Carlton Banks]

With full respect to the coredev team, this "upgrade" to bitcoinQT seems mostly like a solution without a problem, and not a really great one at that.plement that?

Indeed, the premise of this feature was that newbie or average users wouldn't want to handle the weird geekiness of the public key format, but what happens when these same users want to use the network to send money to each other? We're not all going to get issued with CA certificates any time soon, and probably a good thing too considering the flaws in the present system that everybody acknowledges.

I'm just glad that the Payments Protocol has been designed with modularity in mind, and that not all core development members have been working on it, as it seems that X. 509 part will croak eventually anyway.

I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.

[piotr_n]

I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.

Of course - who wouldn't?
What good would bitcoin be for, if you had to register yourself at a CA, before receiving any payment.
It totally contradicts the very principle behind bitcoin's existence.

Let's be realistic; already today, when we do any payment to a webshop, or whatever other commerce, we get a SSL signed payment address anyway, because every single one of these web services uses SSL.
And when we pay to an individual? Well, that's something that is definitely worth addressing, but not by "send your ID to CA and they will tell me that it's you". And definitely it is not so high priority to lock core devs in it for a year - are you out of your mind?

[Carlton Banks]

I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.

Of course - who wouldn't?
What good would bitcoin be for, if you had to register yourself at a CA, before receiving any payment.
It totally contradicts the very principle behind bitcoin's existence.

Let's be realistic; already today, when we do any payment to a webshop, or whatever other commerce, we get a SSL signed payment address anyway, because every single one of these web services uses SSL.
And when we pay to an individual? Well, that's something that is definitely worth addressing, but not by "send your ID to CA and they will tell me that it's you..." - are you out of your mind?

Well, there will always be a free market for cryptocurrencies under the Satoshi model, not to mention a free market for Bitcoin clients. And if people ever feel like Bitcoin development isn't sharing their ideals any more, the friction of dumping BTC for TrueSatoshi, or whatever it may be, will be way lower. As long as the catalyst isn't the removal of the ability to pay directly with a public key.

The mining pool operators will be the ones to watch, as they in fact run the most decisive nodes on the network, and there are less than a dozen.

[piotr_n]

Well, there will always be a free market for cryptocurrencies under the Satoshi model, not to mention a free market for Bitcoin clients. And if people ever feel like Bitcoin development isn't sharing their ideals any more, the friction of dumping BTC for TrueSatoshi, or whatever it may be, will be way lower. As long as the catalyst isn't the removal of the ability to pay directly with a public key.

The mining pool operators will be the ones to watch, as they in fact run the most decisive nodes on the network, and there are less than a dozen.

Of course - luckily for us.

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

[metacoin]

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.

[Carlton Banks]

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.

[justusranvier]

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.

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

[Carlton Banks]

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.

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

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.

[ShadowOfHarbringer]

I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.

Of course - who wouldn't?
What good would bitcoin be for, if you had to register yourself at a CA, before receiving any payment.
It totally contradicts the very principle behind bitcoin's existence.

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

I tend to agree with the general concensus on the other thread running here somewhere: That this sort of functionality should be added as a vendor-neutral API interface, rather than being hard-coded into bitcoinQT, which should remain free of third party dependencies/support.
With full respect to the coredev team, this "upgrade" to bitcoinQT seems mostly like a solution without a problem, and not a really great one at that.

+ 1000

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

[justusranvier]

Except that (as I'm sure you know), Armory interfaces with the network via RPC calls to the Satoshi client.

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

[ShadowOfHarbringer]

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.

[piotr_n]

Devs, did you anticipate that in the future their new CA-Based centralized protocol may become the standard of doing Bitcoin payments ?

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.

[Carlton Banks]

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. First by making it centralized, second by promoting the centralized way of doing transactions, third attacking the single point of failure, thus ending it.

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

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.

[Gavin Andresen]

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!

[Carlton Banks]

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!

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.