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

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

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.

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?

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.

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.

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.

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?

Recent revelations have shown (Snowden, et al.) that any SSL communication should be considered a three way conversation. As in you, me and the [three letter agency of your choice].

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

There are good ways to secure a protocol from MITM attacks without resorting to a Central Authority for certificates.

For example, Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack.  Diffie & Hellman's key exchange protocol, if you are able to communicate with each other at all, allows you to generate a session key impenetrable to an eavesdropper.  The two can be combined, resulting in cutting out MITM attacks very effectively.  It reduces MITM to, at most, DoS.  And DoS can be done by people who aren't even in a position to eavesdrop.

Actually key agreement protocol is unnecessary; Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key.

The Central Authority for HTTPS certificates was never necessary except that certain powers-that-be needed central points of control where keys could be taken, enabling covert eavesdropping, and securely linked to physical-world identities, enabling prosecution.  And also because some people needed to make the system work in such a way that they could make a profit off it, and if it were implemented as protocol, it would be free of charge. 

The functionality of protection from MITM attacks could be far more effectively and securely implemented simply by using protocol between browsers.  For Free.  Essentially, the CA system is still open to insider attacks.  It depends on keys held by people whose secrets the keys are not protecting.  Worse, those key holders have identities known to the public, and are therefore  subject to theft, bribery, extortion, blackmail, court orders, security letters, gag orders, etc. 

Is there plans for adding colored coins support? As a merchant I could ask the customer if they support colored coins and ask for an address where to send them. I could then send the colored coins with along with label for what they are. This could allow the merchant to do a rewards or points system that the customer could redeem later as a reward for using BTC.

I believe most implementations will just wait until the balance of the requested scripts is higher than an amount, but rejecting a transaction that isn't formatted according to what was requested isn't unreasonable.

I did suggest some language around how zero-valued outputs are handled that had tipping in mind, but I think for v1 we punted on it (don't recall exactly). We need to ship this thing, everything else is secondary.

Now that we have the memo thing out of the way, I'm still a little unclear on my initial question about the ability to modify the tx output amount(s) of a payment (my examples were the common practices of adding a tip at a restaurant, and deducting a credit note amount from an invoice payment request).

The spec refers to "fully pay", "pay in full", "satisfy conditions of payment" etc. It seems that the client and/or merchant server will be assumed(?)/expected(?) to enforce this somehow. The spec. could be made more clear as to if/when exceptions may be optionally allowed by either the client (wallet) or the server.

Thanks Mike for clarifying this. That's what I gathered from Gavin's comments about sending a 'memo'. My initial inquiry was more about changing the output value than adding a memo .. and YES, it is obvious from the spec. My bad:

 

You can actually put a message into the payment submission:

https://en.bitcoin.it/wiki/BIP_0070#PaymentACK

Please read the spec before asking questions about what it can do - this will help us find out if the spec is clear enough.

The payment protocol is extensible; this is just version 1.0 (edit: though as mike points out if all you want is an informational message, you can do that - it's renegotiating the payment as the op asked that can't be done. also don't reuse addresses)

The reason we need the payment protocol is for security for multi-signature wallets first and foremost; getting a reasonable first version implemented without bloating it with lots of non-essential features is what's most important right now.

Really? It seems like a significant limitation/oversight if this is intended to be widely adopted in the real world.

Some mechanism for including a (non blockchain-embedded) message would be very useful. In fact, it's difficult to imagine a payment service or protocol (Paypal, etc.) being without that functionality. It would also make multiple payments to the same address much less ambiguous if that was desired for any reason: i.e. a supplier may choose to have each customer send funds to an address assigned to them specifically, or for ongoing subscription payments, etc.... in addition to the examples above.

There's no mechanism in the protocol for those modifications to be communicated back to the payee.

Are there any restrictions on a payment request (signed or unsigned) being modified by the payor before submitting the transaction?

A couple of obvious instances would be:
1. "Here's the transaction for the restaurant meal, your request plus a 20% tip" 
2. "Here's the payment for invoice #12345, minus the credit note #34567 from 2 months ago"

(sorry if the answer is obvious, just want to make sure).

Re: liability - maybe. That's why CA's try their hardest to prevent people from faking their certs, and charge money for issuing one (helps pay for liability insurance and lawyers).

"Faking" here really means getting them to issue a cert incorrectly or stealing their private key, as you can't fake a digital signature. If you can perform identity theft then you might be able to get a cert issued incorrectly though, and cert transparency is meant to help address that.