Quote from: dNote on June 18, 2015, 12:29:04 AM

He accepts a block with the transaction. It is 1 conf, but not 0-conf

It's 0-PoW-conf, I tried to explain to you in post #4 why the merchant would consider this 0-PoW-conf to be ~~inferior~~ superior to 0-conf in Bitcoin, but still inferior to a single PoW confirmation.

Quote from: dNote on June 18, 2015, 12:29:04 AM

The paper says that nodes "ban all blocks (blockheaders) with the last Nth stakeholders", but that can happen only if they will discover such headers. Imagine:
All nodes are connected as bipartite graph (every "red" node is connected to a "blue" node, but there is no "red"-"red" or "blue"-"blue" connections)
Attacker sends different blocks to all red nodes, remember, there is no connection between red-red nodes, so red nodes relay blocks only to blue nodes. Each blue node will ban this header. But how can red nodes know about it?
We will need to implement some kind of alert system to avoid new DoS attack vectors. Can you ban the node for sending 2nd, 3rd, 4th ... block with the same header?

I don`t think that system with a user, who can create unlimited number of blocks "for free" will run perfectly.
Can see a problems here and solutions can cause new problems.

What problems specifically? Maybe what you don't understand is that what you describe is exactly the same situation as with Bitcoin right now, the red miner picks transactions as he wishes and tries to solve a red block, the blue miner picks other transactions (in particular a different coinbase) and tries to solve a blue block, and so on, and we get convergence because of the PoW component, both in Bitcoin and in PoA. I tried to show to you in post #4 how "it isn't important whether miners try to extend the single block that the attacker signed" if the objective of the attack is to create netsplits, because it'd be easier to do the attack with regular transactions as in Bitcoin.