Invoices/Payments/Receipts proposal discussion

[CIYAM]

I think anything that Google (MS or any other such company) suggests would not be acceptable by anyone (apart from those that of course work for Google, MS, etc.).

We need a system that has *no ties* to any large corporation or we have nothing that can be trusted at all.

[1714853319]

1714853319

[1714853319]

1714853319

[1714853319]

1714853319

[1714853319]

1714853319

[Peter Todd]

I think anything that Google (MS or any other such company) suggests would not be acceptable by anyone (apart from those that of course work for Google, MS, etc.).

We need a system that has *no ties* to any large corporation or we have nothing that can be trusted at all.

Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.

The enemy of better is perfect.

[CIYAM]

Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.

The enemy of better is perfect.

Sure but I would not use SSL for anything I really cared about (if it really mattered I would trust GPG).

I think the payment protocol idea itself is fine but we do need to have our eyes wide open when it comes to SSL.

[Peter Todd]

Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.

The enemy of better is perfect.

Sure but I would not use SSL for anything I really cared about (if it really mattered I would trust GPG).

I think the payment protocol idea itself is fine but we do need to have our eyes wide open when it comes to SSL.

Yes, and if you are using something else, then use it - other ways of making Bitcoin transactions aren't going away. (although some poorly-written wallet software and Bitcoin libraries still haven't implemented P2SH addresses, which makes those other ways a bit inconvenient at times)

[Mike Hearn]

Certificate transparency is not a "suggestion", it's actual working code with an open specification that real CA's have started signing up to.

If you think it's somehow inherently untrustworthy because a bunch of rich guys decided to fund its development, then I wonder if you're going to stop using Bitcoin as the number of developers working for a salary goes up?

[CIYAM]

If you think it's somehow inherently untrustworthy because a bunch of rich guys decided to fund its development, then I wonder if you're going to stop using Bitcoin as the number of developers working for a salary goes up?

I think Google, Microsoft and others have *proven* themselves to be inherently untrustworthy and yes I do think it will be a concern for the future of Bitcoin if say the NSA starts making decisions about future security aspects.

[User705]

Doesn't this introduce liability issues?  I mean if there is a central authority claiming to authenticate one entity to another and someone fakes a certificate as is certainly possible since its just ssl overlay and gets away with coins wouldn't they become liable?

[Boussac]

If a webshop using a deterministic wallet makes its master public key public (as it should), then a shopper's wallet app can verify that the payment address associated with her invoice belongs to the merchant's wallet.
E.g a merchant could publish its master public key on its web site and on social networks: a bitcoin wallet app could double check or triple check the master public key against the payment address before making any payment.
No need for a CA.
I dvelopped two apps to demonstrate this use case (those are RoR apps that I intend to open source when I fidn the time to do so):
the webshop is deployed on microbitcoin.net and the address verification app (still in beta) is on bitcoinrad.io.
You can try out bitcoinrad.io with your own electrum master public key and addresses.
The bitcoinrad.io type service should be duplicated so that multiple (decentralized) verification sources are available to merchants using deterministic wallets.
Multiple verification sources, possibly exposing a unified API, would greatly reduce the risks of a MITM attack.

[Mike Hearn]

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.

[callem]

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

[Peter Todd]

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

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

[callem]

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

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

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.

[Peter Todd]

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.

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.

[Mike Hearn]

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.

[callem]

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.

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:

 

message Payment {
        optional bytes merchant_data = 1;
        repeated bytes transactions = 2;
        repeated Output refund_to = 3;
        optional string memo = 4;
    }

[callem]

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.

...
transactions   One or more valid, signed Bitcoin transactions that fully pay the PaymentRequest
...
If the customer authorizes payment, then the Bitcoin client:
Creates and signs one or more transactions that satisfy (pay in full) PaymentDetails.outputs
...
When the merchant's server receives the Payment message, it must determine whether or not the transactions satisfy conditions of payment. If and only if they do, if should broadcast the transaction(s) on the Bitcoin p2p network.

[Mike Hearn]

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.

[dillpicklechips]

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.

[Cryddit]

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. 

[callem]

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.