Invoices/Payments/Receipts proposal discussion

[piotr_n]

Well - I'd have to disagree with this - I've offered very reasonable bounties (actually unreasonable in terms of the payee) and still found no-one willing to write any source code at all.

You shouldn't be surprised, considering that you don't care about anonymity at all.
Any dev working for your money, would not have been much different from what Gavin or Mike are doing right now.
As much as the media admires them, the people who can actually develop stuff see that there is something wrong around it.
Nobody wants to take a part in building a worse future for his children, even if you pay them.

[1714860160]

1714860160

[1714860160]

1714860160

[CIYAM]

You shouldn't be surprised, considering that you don't care about anonymity at all.

People can be as anonymous as they like with CIYAM Open (clearly you have not looked into it at all).

I don't block TOR or control anything about how people do things at all so where do you get your ideas about my care about anonymity from?

[piotr_n]

You shouldn't be surprised, considering that you don't care about anonymity at all.

People can be as anonymous as they like with CIYAM Open (clearly you have not looked into it at all).

You're right - I have not looked into it at all.
Sorry, but I never watch ads, no matter how good a movie is

But what I can tell you is that, as far as I know you, I would not trust you with protecting my anonymity.
I'd rather use Tor with enabled JavaScript.

[CIYAM]

Sorry, but I never watch ads, no matter how good a movie is

Fair enough about ads - actually I was just trying to help out Gavin in this topic (and no he and I have never even exchanged a PM).

(as stated you can use Tor with CIYAM Open)

I will bow out of this topic now as it seems I have overstepped the mark - hopefully the rest of the posts can at least be on topic.

[piotr_n]

FWIW, I don't think you helped Gavin at all, while stating: yes, the user's transaction along with his IP will be logged at the CA server, every time the new payment protocol handles an outgoing transaction.

But thank you - you definitely helped the rest of us.
Knowledge is power

[riplin]

FWIW, I don't think you helped Gavin at all, while stating: yes, the user's transaction along with his IP will be logged at the CA server, every time the new payment protocol handles an outgoing transaction.

Can anyone please point me to the section in the BIP that actually states that this is the case?

[Cryddit]

What gets logged at the CA is not the transaction and IP address; it's the *hash* of the transaction and IP address.  Essentially the same hash Bitcoin uses to secure the integrity of its blockchain, which works because nobody can find a preimage.  IE, given a 256-bit hash value, you can't find the original message (in this case the transaction and IP) without doing 2²⁵⁶ work.  Which nobody can do, or the difficulty threshold for mining would be around 115792089237316000000000000000000000000000000000000000000000000000000000000000 instead of around 267731249 right now.


So what happens is that you and the other party/parties to the transaction both/all know about the transaction.  The CA signing the hash doesn't mean anybody else (not even the CA itself) can find out about the transaction, because nobody can find a preimage; what it means that either/any of you can choose to prove what you know by revealing the transaction record and showing that it is the preimage for the CA's hash.

Essentially, there's little risk that there wasn't before.  A party to the transaction can let other people know about the transaction.  All that changes with the CA is that you (or they) can prove when they reveal it that it's the same thing the CA signed.

Well, not quite all.  If someone has hacked, burgled, extorted, blackmailed, bribed, or served the CA with a court order, and is able to spoof your traffic when you're making the transaction,  they will be able to eavesdrop on or alter the transaction unless you develop and deploy better channel security than the users of the payment protocol have so far developed and deployed.

[piotr_n]

What gets logged at the CA is not the transaction and IP address; it's the *hash* of the transaction and IP address.

OK.
So on the 11th page of this topic, it is already sort of official: each time you use the new payment protocol, your PC connects to the CA server and leaves there the TxID and your IP.

Guys, you should have started from it - then we would tell you already at the first page to not waste a year of your time on developing such a crap.
Hell, if you put it into 0.9, I am not going to run it even once, on my PC. Thank you very much for such a great features, but I'm totally fine without them

[riplin]

each time you use the new payment protocol, your PC connects to the CA server and leaves there the TxID and your IP.

I still haven't seen the section of the BIP that states this to be true.

The way I understand it, the actual transaction is signed using either the merchant certificate or the payment processor (like bitpay for example), NOT the CA.

What IS signed by the CA is the certificate of the merchant. This happens in a chain like fashion (if there are more intermediary CA's). This happens when the merchant acquires his certificate, long before he uses it to sign any transactions. All these certificates are sent in the payment request package, except for the root certificate, which is acquired out of band, either locally from the OS or from something like the Mozilla root store.

All communication is between the merchant and the client as shown in this nice image that's in the BIP:



At no point in that image is any kind of information sent to the CA.


If any of this is wrong, then please tell me and I'd appreciate if you supplied sources.

[piotr_n]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

[riplin]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

Authorize means: "Do you wish to make this payment? (Y/N)"

It's a dialog presented to the user asking him if he wants to execute this payment.

[piotr_n]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

Authorize means: "Do you wish to make this payment? (Y/N)"

It's a dialog presented to the user asking him if he wants to execute this payment.

Right.
So where/when is the SSL verification?
It's definitely missing in there.

[riplin]

So where/when is the SSL verification?
It's definitely missing in there.

It's not missing. It's done at the point where the PaymentRequest is received by the wallet app.

The payment message is signed with the merchant's (or payment processor's) private key. The PaymentRequest contains the merchant's (or payment processor's) certificate, which contains the public key, which is used to verify that the PaymentRequest isn't tampered with.

Now this doesn't solve anything by itself, since you don't know if the merchant's certificate is authentic, so, you need to figure that out next. That's where the chain of certificates comes in. They basically state: "I hereby declare that this certificate is authentic". If you traverse up this chain of certificates (all of which are present in the PaymentRequest message) then eventually you'll end up at the top, where you'll need the ROOT certificate to see if this chain is valid.

The root certificate is usually shipped with your OS. And if it isn't the BIP suggest that you request it from the Mozilla Root Store.

At no point in this entire exchange has any information been sent to the CA.

[piotr_n]

That was actually my initial understanding that SSL does not need CA server, as long as it has a trusted parent cert in local storage.

But still, this diagram does not mention SSL validation at all, and some people in this topic have clearly stated that it involves signing (verifying) transaction's hash with the CA server itself.
To be honest, I don't know if it is entirely true. All I know is that these are the same people who are sort of defending this new payment protocol.
And I also know that SSL certificate has a built in mechanism to be revoked - so it makes me wonder how it works with the payment protocol, since it's logical that it must connect to CA at least to revoke a cert. Having this in mind, I would not be surprised anymore finding out that it also connects to CA to verify the signature itself.

The problem is that we don't know how the validation process really works, step by step and Mike's "fantastic payment protocol FAQ" does not come handy here at all, does it?

How do identities work?

The protocol can be extended with multiple methods, but for v1 the only one that works is X.509 certificates. This is the same scheme used for SSL.

https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143

[riplin]

But still, this diagram does not mention SSL validation at all, and some people in this topic have clearly stated that it involves signing transaction's hash with the CA itself.

As long as nobody provides any sources, there's no reason to believe this is the case.

And I also know that SSL certificate has a built in mechanism to be revoked having this in mind, I would not be surprised if it connects to CA even to verify the signature.

The signature verification only requires the certificate, nothing more.

Testing whether or not a specific certificate is revoked is done using certificate revocation lists:

http://en.wikipedia.org/wiki/Revocation_list

These are published lists that contain ID's of certificates that have been revoked.

Again, this does not expose any kind of information from the PaymentRequest.

[kjj]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

Authorize means: "Do you wish to make this payment? (Y/N)"

It's a dialog presented to the user asking him if he wants to execute this payment.

Right.
So where/when is the SSL verification?
It's definitely missing in there.

You know, if you would just learn to use google, you'd make a hell of a lot less incoherent emo posts, and probably do a fair bit less cutting.

Please read the RFCs for OCSP (2560, 5019, etc).  OCSP involves asking the OCSP server for the current revocation status of the certificate.  There is no provision for sending your transaction to the OCSP server for tracking.  Very close to 100% of OCSP traffic is used for validating SSL certs.  If it was leaking data, it would have already leaked all of your SSL session keys (since 1999!).

If OCSP is enabled in bitcoind, the OCSP server might be able to figure out that you are looking at a signed payment request from entity X, which they probably already knew because your browser checked the exact same certificate a few seconds earlier.

It is entirely possible that I'm being unfair in my estimation that you are a giant fucking troll*, in which case I would owe you an apology.  But you are clearly aware of the existence of OCSP (since your questions make no sense in any other context), but you have either intentionally refused to educate yourself about it, or you know perfectly well what it does and does not do, but want to spread misinformation.

* Not like we don't all know about you from your insane rants in other threads.

[piotr_n]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

Authorize means: "Do you wish to make this payment? (Y/N)"

It's a dialog presented to the user asking him if he wants to execute this payment.

Right.
So where/when is the SSL verification?
It's definitely missing in there.

You know, if you would just learn to use google, you'd make a hell of a lot less incoherent emo posts, and probably do a fair bit less cutting.

Please read the RFCs for OCSP (2560, 5019, etc).  OCSP involves asking the OCSP server for the current revocation status of the certificate.  There is no provision for sending your transaction to the OCSP server for tracking.  Very close to 100% of OCSP traffic is used for validating SSL certs.  If it was leaking data, it would have already leaked all of your SSL session keys (since 1999!).

If OCSP is enabled in bitcoind, the OCSP server might be able to figure out that you are looking at a signed payment request from entity X, which they probably already knew because your browser checked the exact same certificate a few seconds earlier.

It is entirely possible that I'm being unfair in my estimation that you are a giant fucking troll*, in which case I would owe you an apology.  But you are clearly aware of the existence of OCSP (since your questions make no sense in any other context), but you have either intentionally refused to educate yourself about it, or you know perfectly well what it does and does not do, but want to spread misinformation.

* Not like we don't all know about you from your insane rants in other threads.

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

But sure, feel free to call me a giant fucking troll, as opposed to a member of the bitcoin elite that you are obviously representing here - from you, I actually take it as a compliment

[riplin]

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

How do you expect people to take you seriously with statements like these?

[Carlton Banks]

each time you use the new payment protocol, your PC connects to the CA server and leaves there the TxID and your IP.

I still haven't seen the section of the BIP that states this to be true.

[...]


If any of this is wrong, then please tell me and I'd appreciate if you supplied sources.

According to BIP 70, it's a non-mandatory part of the protocol. The behaviour is defined in pki_type in the Payment Request message. If pki_type is not supplied, then the protocol treats the instance as if the lack of PKI specifics means that none is to be used. This means the composer of the message needs to specify this correctly themselves, there is no "send to the CA for a signature whether people like it or not" behaviour.

Take a look at the constituents of the PaymentRequest message in BIP 70:

PaymentDetails/PaymentRequest

Payment requests are split into two messages to support future extensibility. The bulk of the information is contained in the PaymentDetails message. It is wrapped inside a PaymentRequest message, which contains meta-information about the merchant and a digital signature.

    message PaymentDetails {
        optional string network = 1 [default = "main"];
        repeated Output outputs = 2;
        required uint64 time = 3;
        optional uint64 expires = 4;
        optional string memo = 5;
        optional string payment_url = 6;
        optional bytes merchant_data = 7;
    }        

network    either "main" for payments on the production Bitcoin network, or "test" for payments on test network. If a client receives a PaymentRequest for a network it does not support it must reject the request.
outputs    one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored).
time    Unix timestamp (seconds since 1-Jan-1970) when the PaymentRequest was created.
expires    Unix timestamp after which the PaymentRequest should be considered invalid.
memo    UTF-8 encoded, plain-text (no formatting) note that should be displayed to the customer, explaining what this PaymentRequest is for.
payment_url    Secure (usually https) location where a Payment message (see below) may be sent to obtain a PaymentACK.
merchant_data    Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address.

A PaymentRequest is PaymentDetails optionally tied to a merchant's identity:

    message PaymentRequest {
        optional uint32 payment_details_version = 1 [default = 1];
        optional string pki_type = 2 [default = "none"];
        optional bytes pki_data = 3;
        required bytes serialized_payment_details = 4;
        optional bytes signature = 5;
    }

payment_details_version    See below for a discussion of versioning/upgrading.
pki_type    public-key infrastructure (PKI) system being used to identify the merchant. All implementation should support "none", "x509+sha256" and "x509+sha1".
pki_data    PKI-system data that identifies the merchant and can be used to create a digital signature. In the case of X.509 certificates, pki_data one or more X.509 certificates (see Certificates section below).
serialized_payment_details    A protocol-buffer serialized PaymentDetails message.
signature    digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data.

From this, you can see that the Payment Details message is contained in the overall PaymentRequest message (in the serialized_payment_details variable). What I've tried to highlight is, that:

• your Bitcoin public key (message Payment Details { repeated Output outputs })  
• the Merchant's message for details of the request (message Payment Details { optional string memo })
• your IP (message Payment Details { optional string payment_url })

are all contained in the presiding message PaymentRequest variable {required bytes serialized_payment_details}.

If you look at the description in the section for the PaymentsRequest message that describes the composition of the signature, also bolded, you'll see that the PaymentRequest message itself is hashed using the public key (optionally) provided by the merchant.

What concerns me is that I have no idea whether the data in the Payments Details (non-mandatory as some of it is) can be somehow cajoled into something meaningful, given that the nature of the hashing of this information involves using a certificate to authenticate that some of the contents of the hash are verifiable. The PKI public key of the merchant must be positively identified from within the hash of the information, so is the rest of the hashed information also safe?

What is the necessity of sending the PaymentDetails for the purpose of verifying the merchant key, could something that is not user sensitive be used? Or not? Does it even matter at all?

[piotr_n]

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

How do you expect people to take you seriously with statements like these?

I believe most people don't know what OCSP stands for - so why would they not take me seriously asking about it?