Public derivation is called public because it's performed with the public key values.  The chain code is never made public as part of the blockchain and would normally be made available only over an encrypted channel, if its even shared at all.

No, if it did that difficulty could only change by factors of 2.

Perceptive. It doesn't.

Bitcoin doesn't use the number of zeros. Instead it converts the hash into a single big integer and requires that the value be less than a target value. The target value is adjusted every 2016 blocks as required to control the block rate and the "difficulty" number is just the ratio of the current hardness of the problem to the initial hardness.

If the initial peer it pulls from is unresponsive or hangs up then it may wait until the next block on the network to continue pulling.

There is no need to use the interlock protocol when you have an authentication method. You can just use your authentication method to authenticate the DH ephemeral exchange (or some resulting derived session ID) and then you know there is no MITM. If you do not have an authentication method the interlock protocol generally does you no good.

Do you have any idea what the payment protocol is or has the name confused you?  It's format for (optionally cryptographically signed) invoices and receipts. It's not necessarily used interactively, e.g. you can send payment requests as email attachments.

The discussion in this thread is about the fact that the payment requests can x.509 certificates to cryptographically sign their content. "SSL authentication" is completely out of left field here.

I *will* be upset if you continue to use that tone in this discussion.

It so obvious to you when you get to gloat over other people's losses, but I've yet to see you speak up in a thread where people are advancing "brainwallets" and say "no! don't do it!".

There is no BIP38.

Okay sure, but it's well established that you're a weirdo: You use windows.

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

If the first peer it tries to pull from fails it may not continue until the next block is found on the network.

I'm earnestly confused here— honest to god derpy look on my face confused—, I'm not trying to be snippy or anything at all like that. What you were saying made so little sense to me that I am concerned that I am mis-parsing your english. Your sentenced was, indeed, grammatically sound but ducks inverted my rutabaga.

Talking to someone confused about something, who is loudly angry as a result of the confusion, and is not following a clarification in part because of their anger can be a little frustrating to deal with... but in this case I'm not even frustrated because I can't actually figure out what y'all are thinking.  It's just mystifying to me.

I suspect that you have a very incorrect model in your head of how this stuff works, what the goal is, and what the consequences are... but I can't quite figure out how.  CAs seeing payment requests is basically a martian comment, as it has no semblance to how CAs work (much less how payment requests work), so I know something is wrong. I think I'm reasonably skilled with helping people through misunderstandings, but to do so I first need the start of an idea about what the confused person is thinking.

What I've found works when people have unclear complaints about Bitcoin is I suggest we roleplay.  You are the attacker out to harm people. Tell me what you'll do and what you'll get out of it, and I'll "defend" by telling you why your attack fails (or ask for clarifications for 'attacks' that are too non-specific).

I am a naughty thread participant. I just patterned matched what the OP was saying with something else I'd recently been thinking and talking about.   Not exactly fair of me.

Your agonizing clarity is failing me. Sorry.

Huh. This appears to be word salad. There is no CA signing of any part of a payment request itself. None at all.

Why don't you try to explain to me step by step how you think it works and I'll point out where we are occupying alternative universes.

The only signed data is the request to pay, which is signed by the merchant (when used, it's optional), and the merchants own credentials which are part of a certificate he sends (if he is doing the optional signing).

No. I'm not talking about that at all.

Nothing stops you from sending unsolicited requests to pay.

A payment request is like an invoice, it forms an agreement "I'll send you the things listed on the payment request, if you pay this amount to these scriptpubkeys." the request can be signed so that you known who its from, and the signature is non-reputable so that if they don't make good on the deal you can show someone the payment request (and the transactions in the blockchain) as evidence that an agreement existed and you kept up your side of the deal.

It's not a "technical side effect" it's what it does. If you don't care about non-repudiation then you don't need to care x.509 certificates in the payment protocol at all.

I'm struggling at trying to figure out your understanding of the payment protocol world. Are you under the impression that CAs would sign payment requests or control private keys? Thats not the case.  Only the requester and the requestee will see the payment requests.  If x.509 is used its used so that when you receive a payment request signed by a particular party your client (and anyone you show the payment request to) can use their certificate to validate that the request was signed by the right party.

I'm afraid I'm not following you here.

I addressed your concern by saying that it's the requester who controls how non-repudiation is provided and it's the requester who suffers if the non-repudiation is insecure. (Because the consequence of insecure non-repudiation is that a customer can produce cryptographic evidence that vendor ripped them off when they didn't really)

I have no comment on the "qualitative security" of the channel. It's entirely outside of the payment protocol, and you must have it even before a payment request can exist since you'll need to use it to negotiate the request (e.g. to do your shopping). The payment protocol doesn't provide it. Obvious readily available options today include: SSL (with its various limitations), http+tor onion URLs (though how you know you have the right site is another question), or exchanging gpg signed and encrypted payment requests.

AFAIK the payment protocol stuff does not support OCSP. I suspect that it probably shouldn't.

Yes, but if you're going to make the argument that you're being harmed by bitcoin-qt not restricting the freedom of others (an argument I've used here and there at times) I don't think it applies here.

The payment protocol doesn't provide its own secure channel. Thats not what x.509 for is used for in the payment protocol. The use of x.509 in the payment protocol is for non-repudiation (which many secure communications channels don't provide, including SSL).  Without a secure communications channel your privacy/security is hosed, and with one your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

In particular: It's primarily the sender the payment request which cares about the integrity of non-repudiation since if their non-repudiation is compromised customers will be able to convince others that the sender ripped them off.

If someone were making an argument about non-repudiation there might be something to discuss here, but no one appears to be talking about it.

This just isn't how it works. You keep repeating this, but it's nonsensical.

You can transmit a payment request via whatever channel you want. If the x.509 non-repudiation signature in it is not secure you're still secured by whatever channel you're transmitting the data over.  If you have no secure channel at all, your problem is ... kinda out of scope for the payment requests.

What would you have the payment protocol do instead? All you've done so far is list completely inapplicable things that demonstrate that you don't understand what it does at all.

I'm sure your english is much better than my ability to speak whatever language that you're native in, but I still can't understand your question.

Perhaps you could also try google translate?

None of that list of things actually do anything to address whats the payment protocol is doing.  x.509 is used to provide non-repudiation. The merchant tells you to pay 5 BTC to scriptpubkey X and they'll send you 10 widgets.  If the merchant scams you, you can show other people the signed invoice to convince them that the merchant really did make that agreement.  This means that none of the authentication for ephemeral keying things are actually useful (e.g. every one of your bulleted "alternatives"), nor is "have to trust the merchant not to scam you".

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

Do take care there, it's not the right comparison.  _Generally_ more CAs == more vulnerable because any CA can author a cert for any domain.

The greater point is that the payment protocol, while it can use x.509 doesn't have security that turns totally brittle even if the CA infrastructure misbehaves.

I'd like to see better support for non-SSL CA stuff, but the options are pretty limited. Doing other things, however, is not mutually exclusive with also supporting x.509.

Do you even have any idea what you're talking about here? What do you think the payment protocol does? Or, stated another way why the histrionics. If you don't like it, just don't use it. It doesn't do anything if you don't use it.

Case in point.
Yes, as I said, this subforum is generally lower in nonsense than the rest of the forum.

Again, please feel free to state concerns, but if you regularly cannot manage to do so in a polite, adult manner I'm going to have to ask you to leave.

Back to the thread subject, the limitations of the CA infrastructure have been extensively discussed both in this very thread and in the older bitcoin-development thread. I agree that the CA infrastructure is lame, but the world doesn't really have any good PKIs.

Fortunately, the way the payment protocol is designed the CA infrastructure being potentially weak isn't all that critical, as payment messages can be sent directly between buyers and sellers over whatever secure channel they already have. An evil CA cannot do as ShadowOfHarbringer suggests, it cannot prevent people from transacting with each other even inside the payment protocol (of course, the option of just not using it would work too), nor can it produce completely undetectable forgeries, nor could it impersonate anyone _at all_ unless it could already impersonate your secure communications channel. As far as I know the x.509 support does in the payment protocol is create a non-reputable signature for invoices for messages which you would be sending over a secure channel anyways.

If a community of users (now or in the future) prefers to send their payment messages with external PGP signing— because they don't even trust the CA infrastructure for non-repudiation—, they can do that instead of or in addition to the x.509 key signing.