Invoices/Payments/Receipts proposal discussion - page 3.

metacoin

sr. member

Activity: 437

Merit: 260

balance

Quote from: piotr_n on October 24, 2013, 04:35:38 PM

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.
Instead of adding more mess to the existing one...

Hopefully this soon becomes a reality. In Gavin's blog post today, he mentioned the goal of making the client less monolithic and more modular. This is absolutely a step in the right direction.

Quote

We are (slowly) moving from a monolithic code base that does everything (wallet, RPC, network, blockchain storage/validation) towards more modular internals with fewer dependencies between the different pieces. Another change you should see in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client– Wladimir J. van der Laan split the RPC client functionality (“tell the running bitcoin daemon to do THIS”) into a separate executable, ‘bitcoin-cli’. The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two.

https://bitcoinfoundation.org/blog/?p=290

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: piotr_n on October 24, 2013, 04:35:38 PM

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.

It's called btcd.

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.
Instead of adding more mess to the existing one...

grau

hero member

Activity: 836

Merit: 1030

bits of proof

While I assume that you integrate these protocols with extreme care, they are hairball on their own with lots of flavors and options. Adding them is the exact opposite of what I would like to see happening to the reference client.

Is there a hope for a standard build without payment protocol, like the no wallet option jgarzik worked on?

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

I am not saying it is a rocket science - I am saying that OpenSSL is a one big mess and nobody knows what it really does these days.
Come on, you must know life; how much you can actually rely on any documentation? OpenSSL is surely no exception.
Mind that you have just quoted "Bugs" section of the doc, to support your statement that "No attempt is made to download CRLs from the CRL distribution points extension".

If my fate is about to be judged on whether you set a flag or not while calling the lib, and whether this flag actually does what the man page says it should - then I would rather stay away from such a secured payment solution. And I will be advising people to do the same, if you don't mind.

Mike Hearn

legendary

Activity: 1526

Merit: 1134

Look, it's late and I'm tired. If you want to learn OpenSSL then go read the documentation instead of demanding personalised tutorials whilst simultaneously talking crap about my coworkers. Your attitude reveals you to be both obnoxious and incompetent.

For example, you could start here:

http://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html

and in particular this statement:

Quote

If CRLs checking is enable CRLs are expected to be available in the corresponding X509_STORE structure. No attempt is made to download CRLs from the CRL distribution points extension.

Seriously Piotr, this stuff isn't rocket science. If you aren't capable of understanding it yet then go and read documentation until you do, then come back.

riplin

member

Activity: 116

Merit: 10

Quote from: piotr_n on October 24, 2013, 04:07:20 PM

Do you still claim that there is no way that the bitcoin client can leave my IP a CA server, when you just use this function?
I am not saying that it does - I am just saying that it isn't totally clear what this function actually does. And I betting that it's also not totally clear for you.

Code:

-CApath directory
   A directory of trusted certificates. The certificates should have
   names of the form: hash.0 or have symbolic links to them of this
   form ("hash" is the hashed certificate subject name: see the -hash
   option of the x509 utility). Under Unix the c_rehash script will
   automatically create symbolic links to a directory of certificates.

   -CAfile file
   A file of trusted certificates. The file should contain multiple
   certificates in PEM format concatenated together.

So you need to supply your own trusted root certificates.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: kjj on October 24, 2013, 03:43:31 PM

Quote from: Carlton Banks on October 24, 2013, 03:34:56 PM

Ok, so the signature sent to the user is composed by the merchant, and the hash does what hashing should.

Can someone explain then why the signature is sent to the user, if the user does not verify it with the CA themselves? (given the case where using the CA system is used)

Can someone explain then why the signature must contain a hash of the Request Details? Just saying "it doesn't matter what data is hashed" suggests that any data could be used in place of the Request Details.

The point of the signature itself is that it is now impossible to change the signed data without invalidating the signature. Things that are important need to be included in the signed portion. It would be pointless to sign a transaction request message that didn't include the Request Details in the signature, as the details could then be changed by anyone, at any time.

Ok, so only the holder(s) of the merchant's privkey can verify that the signature is a hash of the Payment Request. The merchant's certificate cannot be used to do this. Is this right?

If so, I still fail to understand the necessity of hashing the Request Details and signing that. The end user cannot verify that the hash is a result of such a hashing operation, and they are the only recipient of this signature. Only the merchant should be able to ascertain that the signature is generated by signing a hash of the Request, and they have no apparent need to verify this, being as they presume to have collected the details in a direct https session with the user.

Why use the Payment Details, which the merchant should be confident of anyway?

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: Mike Hearn on October 24, 2013, 04:00:13 PM

Perhaps we need a basic tutorial somewhere on how X.509 / PKIX works. I didn't go into details in the payment protocol FAQ because I thought people would research this if they didn't already know.

A lot of the frustration and talking past each other in this thread and elsewhere makes a lot more sense now it's clear that some people have a garbled understanding of how certificates and the PKI operate. This article is reasonable:

http://en.wikipedia.org/wiki/X.509

piotr_r, you can see the code that verifies payment requests here:

https://github.com/gavinandresen/paymentrequest/blob/master/c%2B%2B/paymentrequest-dump.cpp

Look for the functions that begin with X509_ or EVP_ to see which functions manage in it OpenSSL. Or look at the Java implementations for one that's not OpenSSL:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/validator/PKIXValidator.java?av=f

Thanks Mike.
I hope you don't take my comment personally and you understand that you work for Google while I work for the people.
We play for different teams, but it doesn't mean we cannot play fair.

So, let's get into X509_verify_cert

Quote

A complete description of the process is contained in the verify(1) manual page.

And this is the verify(1) manual page: http://www.manpagez.com/man/1/verify/

Do you still claim that there is no way that the bitcoin client can leave my IP a CA server, when you just use this function?
I am not saying that it does - I am just saying that it isn't totally clear what this function actually does. And I'm betting that it's also not totally clear for you.

riplin

member

Activity: 116

Merit: 10

Quote from: piotr_n on October 24, 2013, 04:00:48 PM

As for a guy who has just refereed me to a source code of ECDSA verify function, after I had asked him for the function name that verifies the SSL certificate, you seem to be pretty funny advertising your expertise in the matter

I already told you that I was being facetious. You asked me for a function that can verify a signature. That was one. Whether or not that's actually used in SSL is irrelevant. I know it's not, but the inputs to that function are exactly the same as the function you requested. Hash, public key, signature. output: true / false.

For what it's worth, ECDSA is one of the algorithms supported by X.509: http://tools.ietf.org/html/rfc5758

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: riplin on October 24, 2013, 03:58:35 PM

Quote from: piotr_n on October 24, 2013, 03:55:43 PM

From what I see ATM nobody seems to really know what it does.

From what I see here, there are only a few that don't know what it does, you being one of them.

As for a guy who has just refereed me to a source code of ECDSA verify function, after I had asked him for the function name that verifies the SSL certificate, you seem to be pretty funny advertising your expertise in the matter

Mike Hearn

legendary

Activity: 1526

Merit: 1134

Perhaps we need a basic tutorial somewhere on how X.509 / PKIX works. I didn't go into details in the payment protocol FAQ because I thought people would research this if they didn't already know.

A lot of the frustration and talking past each other in this thread and elsewhere makes a lot more sense now it's clear that some people have a garbled understanding of how certificates and the PKI operate. This article is reasonable:

http://en.wikipedia.org/wiki/X.509

piotr_r, you can see the code that verifies payment requests here:

https://github.com/gavinandresen/paymentrequest/blob/master/c%2B%2B/paymentrequest-dump.cpp

Look for the functions that begin with X509_ or EVP_ to see which functions manage in it OpenSSL. Or look at the Java implementations for one that's not OpenSSL:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/validator/PKIXValidator.java?av=f

riplin

member

Activity: 116

Merit: 10

Quote from: piotr_n on October 24, 2013, 03:55:43 PM

From what I see ATM nobody seems to really know what it does.

From what I see here, there are only a few that don't know what it does, you being one of them.

riplin

member

Activity: 116

Merit: 10

Quote from: piotr_n on October 24, 2013, 03:55:43 PM

Quote from: riplin on October 24, 2013, 03:48:07 PM

Quote from: piotr_n on October 24, 2013, 03:39:06 PM

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

What it does - is not so important.
What is important is that you have no clue what it does - and that's dangerous. For privacy, I mean.

Hardly. Root CA's are used to sign hundreds, if not thousands of certificates. The CA has absolutely no clue which certificate you're trying to verify.

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: riplin on October 24, 2013, 03:48:07 PM

Quote from: piotr_n on October 24, 2013, 03:39:06 PM

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

What it does - is not so important.
What is important is that you have no clue what it does - and that's dangerous. For privacy, I mean.
I cannot believe that I even need to explain it here

From what I see ATM nobody seems to really know what it does.
It needs to be established on IRC first, but we can be sure that results will be positive...

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: Carlton Banks on October 24, 2013, 03:48:12 PM

I wouldn't be asking any questions, or attempting to provide my own answers if I either fully understood all of this, or if the devs weren't being awkward about it. I don't know whether you've noticed, but the stakes in this here Bitcoin system are worth money, being as it is that it is money. I kind of take an interest in the way the design and the infrastructure works, so unless being rightfully inquisitive isn't disrespectful or uncalled for, I will reserve the right to ask as many questions and get as many details wrong as it takes. Getting it wrong is not criminal, and it certainly doesn't disqualify anyone from asking more questions, the opposite if anything.

If you go ask a cardiac surgeon to explain how a multiple bypass surgery works, and every time he starts to answer you interrupt him by asking how that step helps to balance the humors, or some other pseudomedical nonsense, he's pretty likely to quickly become exasperated. If you are the twelfth guy this week to pull that stunt, he may not be entirely polite when he tells you to come back when you have a better grasp on medicine.

I'm sorry that the devs didn't have time to spoonfeed "How the Internet Works, Volume 7: SSL" to you. But this is the age of Google. It is within your own capability to educate yourself enough to ask meaningful questions.

riplin

member

Activity: 116

Merit: 10

Quote from: piotr_n on October 24, 2013, 03:48:52 PM

Right.
You know everything, except the function's name..
Well, thank you for sharing your valuable knowledge with me

Because it's completely irrelevant. It's a set of crypto functions, depending on which signing algorithm is used. The one thing I do know about these functions is that they are given all the required input data in order to verify if a signature is valid. and that's a hash of the data, depending on the hash algorithm used (SHA1, SHA256, whatever), the public key, and the signature. No other information is needed in order to verify a signature.

You somehow think that you've "won" the discussion simply because I can't tell you the name of the required function. This type of discussion is also referred to as "pigeon chess":

Quote

Refers to having a pointless debate with somebody utterly ignorant of the subject matter, but standing on a dogmatic position that cannot be moved with any amount of education or logic, but who always proclaims victory.

Origin:
"Debating piotr_n on the topic of the payment protocol is rather like trying to play chess with a pigeon; it knocks the pieces over, craps on the board, and flies back to its flock to claim victory."

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: riplin on October 24, 2013, 03:45:05 PM

Quote from: piotr_n on October 24, 2013, 03:39:06 PM

Are you fucking kidding me?

I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever.
Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client.

I was being facetious. The signature verification for an X.509 certificate is determined by the certificate itself. It's nothing more than a basic crypto function and it doesn't need to connect to any 3rd party in order to verify if a signature is produced by the private key that a specific certificate represents.

see http://en.wikipedia.org/wiki/X.509 for details.

Right.
You know everything, except the basic function's name..
Well, thank you for sharing your valuable knowledge with me

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: riplin on October 24, 2013, 03:30:01 PM

Quote from: Carlton Banks on October 24, 2013, 03:21:57 PM

It would reflect better on the core devs if they were not defensive

And it would reflect better on you if you tried to actually figure out some of the basics first. You've shown a significant lack of understanding of even something as simple and instrumental as a hash function.

Quote from: Carlton Banks on October 24, 2013, 03:21:57 PM

aversive, or insulting in their participation. I'm coming entirely from the perspective of asking questions, and attempting to answer them myself after the dev team member I was speaking to before hand reverted to being insulting, aversive and defensive.

You guys are all following the same pattern, and yet there is a distinct lack of any honest attempt to clarify. You keep focusing on the people asking the questions, and not answering the questions posed.

There have been multiple clarifying posts in this thread, yet you continue to ignore them.

I wouldn't be asking any questions, or attempting to provide my own answers if I either fully understood all of this, or if the devs weren't being awkward about it. I don't know whether you've noticed, but the stakes in this here Bitcoin system are worth money, being as it is that it is money. I kind of take an interest in the way the design and the infrastructure works, so unless being rightfully inquisitive isn't disrespectful or uncalled for, I will reserve the right to ask as many questions and get as many details wrong as it takes. Getting it wrong is not criminal, and it certainly doesn't disqualify anyone from asking more questions, the opposite if anything.

riplin

member

Activity: 116

Merit: 10

Quote from: piotr_n on October 24, 2013, 03:39:06 PM

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

Topic: Invoices/Payments/Receipts proposal discussion - page 3. (Read 24726 times)