We agree that the first one is not really an issue since every serious webpage works with https:// and a certificate of a well known CA.

The second is an issue not limited to Bitcoin but to any type of payment. Having a cryptographic proof of the payment at customer side would positively distinguish Bitcoin payments.

In my opinion both address generation and digital receipts belong to the webshop's business process facilitated by other tools. There could be a whole lot of business rules influencing how payment is requested and there are already digital bills and regulatory requirements to present a receipt for money taken in (at least in the EU). 

I do not question if goals of payment protocol are noble or that its design is not careful and state-of-the art, but if it should be embedded into the bitcoin protocol server.

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

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?

Gavin works on whatever he likes, just like all other core devs in my observation.

I believe that the criticality of payment protocol is way below of other issues and if it was business critical there would be funds for it other than the foundation's.

The payment protocol is a pet project of Gavin, that will be useful just like everything he makes, but has not much to do with the core of Bitcoin that should rather be hardened and standardized as it was originally postulated to be the purpose of the foundation, that pays his salary

If it were business demand then there would be a business case and a solution for it.

The attack works by bribing miner to orphan certain blocks, it is not A against B but building coalitions to claim the bribe.

I think that the attack is technically valid but participating in it by any of the miner depends on if they are  greedy, especially short term greedy. Accepting the bribe brings higher profit in short term, but diminishes the value of their coins and investment on the longer term, since it hurts credibility of the entire system.

If I wasn't busy or there would be an upside to it I'd scan if this is already happening.

The observable sign would be transaction replacement at re-org. They could be the bribe paid to make the other block orphan.

Anyone-Can-Spend outputs may look like an ordinary transaction, just use the address of an easy to guess brain wallet.
In the described attack the output's intention is to bribe miner to participate in censorship.

The attack needs to be launched successfully only a couple times and other miner will stop building on the disliked miner's block since those carry high risk to be orphaned.

Maybe it is not even the miner that one targets but a certain type of transaction or address used in the block. Soon the rational miner will be trained to obey the rules of a censor with deep pocket.

Can transactions remain free if miner become "rational" ?

A big fee could be claimed by embedding its into the next block.
This bounty can only be claimed by orphaning the disliked block and it does not cost anything to the attacker if not claimed.

Exactly. The amount of bounties that need to be paid would pale in comparison of censoring power they could create.

It is not about me. Assume a big miner or cartel of them wants to get rid of a newcomer.

Yes, the attack does cost money, but less than the damage it would make to the bottom line of the disliked miner.

It is not viable at the moment since miner are not "rational" but using the standard client that has no notion of trivially redeemable transactions.

I raise this not because want to be a douchebag, but to discuss if Bitcoin can be hardened to cope with the attack or if it needs alturism to avert this.

I developed the following attack while discussing https://bitcointalk.org/index.php?topic=312668.0
Let me summarize it for a more targeted feedback if it would work:

Assume somebody is determined to frustrate a miner.

He prepares the attack by sending a sizable amount to his own new address. He repeats for every block. The transactions might build a chain, but do not have to.

As the disliked miner creates a block containing any of his prepared transactions he launches the attack by creating a transaction double spending that transaction to a script trivially redeemable and sending it to other miner.

Assuming miner act rationally and the trivially redeemable output is of tempting size, they will start working on a block parallel to that of the disliked miner and include the double spend and a transaction redeeming it to their own address.

If repeated the disliked miner will not be able to get a block to the trunk, hence no revenue.

The winner might issue a new smaller bounty to keep others on his branch, and he also has the chance to mine the next himself as usual.

The attack could be repeated and is final to coin base transactions.

Actually one does not even have to be a miner to launch this attack:

The attacker rolls a Bitcoin holding again and again to new addresses of his own. Once he discovers a block he dislikes, he broadcasts a double spend of his previous roll to a trivially redeemable address.

If the transaction has the sufficient size rational miner will be attracted to create an branch rooted where the transaction was still valid and attempt to re-org to cash in the offered bounty.

Added: He would have to send the double spend to miner directly since ordinary nodes would drop, broadcasting would only work by chance.

It could stop them if the transaction is only valid in the orphan. For that the source of the bounty would have to be spent in the disliked trunk. The miner could prepare the attack by broadcasting a spends to his own address. If one of those is included in the block he dislikes, then he has a bounty to offer that is only valid in his branch by spending the source again to a trivial to redeem address in his block.

It seems to me that mining on the trunk could be even brought to a temporary halt by creating a new orphan block deeper in the chain with a sufficient bounty trivially claimable.

Rational miner would mine on that orphan and leave enough bounty to incentivize the next until the orphan branch catches up with the trunk triggering a re-org that benefits those participated in the attack.

It is above my knowledge of game theory to attempt to formulate, but suspect that with only "rational" miner there is a sufficient bounty to trigger any depth of re-org (within the same difficulty cycle).

Assume a miner dislikes something in the highest block, and is willing to spend on suppressing it.  He mines a parallel block also embedding a transaction sending a bounty to a trivial to redeem script.  All rational miner including him will be incentivized to mine on top of his alternative and claim the bounty for themselves. Only an altruistic miner would remain on the original or include a mempool transaction claiming the bounty.

Added: An unsuccessful attempt to suppress the highest block does not even cost anything, since if not successful the bounty transaction will not be existent in UTXO. A trivial to redeem transaction included by the miner practically adds to the fee offered for the block building on it.