My design doesn't (and afaics shouldn't need to) prove to a syncing node anything about propagation that occurred while that node wasn't listening live. Remember that the 49 - 99% attack must be sustained otherwise it can't maintain the blacklist on the minority PoW. The minority PoW will have identified the dishonest chain and be humming along (at a reduced level of PoW difficulty, yet still including the attacker's nominations so as to prove to syncing nodes which chain is refusing to include the other's nominations). So the syncing node will have ample opportunities while live to objectively determine which chain is dishonest.

(Assuming the node is syncing to a honest relay and remember my point about community responsibility for this,) the syncing node will see there are two competing chains and thus syncing node will be wary to accept any transaction as final until it has determined which chain is the honest one. Note that if the dishonest chain is an extension of the chain the syncing node had earlier identified as dishonest (a hash for that node's choice is saved on the block chain so the node can't forget), that node already knows it blacklisted that chain (which can be determined from the chain history).


Finney attacks are not possible in my design, because transactions are not confirmed by PoW blocks. So the payee will not accept the transaction until it has been confirmed, which can be on the order of 1 second from the time the transaction is sent to the confirmation network.

In my (monumental?) prior two posts, I was starting to lay out some of the paradigmatic gains that arose from separation-of-concerns for transaction confirmation and PoW chains. Bitcoin-NG (from the researchers who published the selfish mining attack) separates timing of transaction confirmation from PoW chains (thus removing the latency spikes for propagation of block announcements, i.e. a form of anti-aliasing), but it doesn't eliminate double-spending by orphaned chains (which my design does eliminate). Also Bitcoin-NG nominates only one node per block period to confirm transactions thus Bitcoin-NG (and Bitshares' DPOS) is highly vulnerable to DDoS (even more vulnerable than current Bitcoin which employs Satoshi's design!).

Based on your use of the word 'nominate', you may be misunderstanding what is nominated in my design. C.f. how Bitcoin-NG nominates a node to confirm all the transactions until the next block. In my design, there are a plurality of confirmation nodes nominated, they persist for a plurality of PoW blocks.

Afaics, in my design there simply isn't a way to create an orphaned chain which would be required to create a double-spend other than a Finney attack. In my design, orphaned chains can only occur due to network partitioning and in that case Satoshi's design also allows double-spends on both forks. Dealing with network partitioning is another issue. We can discuss that later.

P.S. as a tribute to the prodigious generosity and amiable unassuming attitude of Hal Finney, I like to share his description of how Chaum's Ecash worked which helped me a lot when I was first learning what the Fiat-Shamir transform is and how it converts an interactive ZKP to a NIZKP (non-interactive zero knowledge proof).