Re: [neㄘcash, ᨇcash, net⚷eys, or viᖚes?] Name AnonyMint's vapor coin?
Against Dash and Satoshi's design (e.g. Bitcoin) that can theoretically be executed with a much less costly Finney attack (where the attacker wins a block but doesn't announce it right away and first announces his double-spend, which is even more likely in Dash's InstantX because the confirmation is instant making it much more feasible to fool the unwary merchant who was assured that InstantX is instantly confirmed so not to wait for chain confirmations), so no need to invest such massive resources. And there are other less costly attacks specifically on Dash that monsterer alluded to and I will be following up on in future posts.
But if the InstantX lock has been acquired (and the merchant will see in his wallet that the lock is on within a couple of seconds) the attacker's delayed block will be rejected by the network because it contains a conflicting transaction (all the honest nodes will obey the lock). To me it rather looks like InstantX is safer than Bitcoin in that respect or am I again missing something.
And if the attacker releases the block within the propagation delay so that some see the block announcement before they see the lock announcement. So there is an ambiguity. Which is correct the instantX announcement or block chain announcement?
I don't know the exact details but this seems non-issue to me. If the merchant receives the false block before he gets to know about the IX lock, his wallet will display only one standard confirmation, and he should therefor await for more confirmations (it's displayed differently than a successful IX). But he won't get more confirmations as the network elsewhere has rejected the block and won't mine on top of it.
If most of the selected masternodes see the block solution first however, they won't sign the IX lock and the transaction falls back to standard confirmations.
This is what the IX white paper says:
"If attackers gain control of the 10 Masternodes for a given block and propagate multiple conflicting messages, the network must appropriately handle the conflict. For example, an attacker that controls a large portion of masternodes might propagate a message to Merchant B and nowhere else ,while propagating a messages to many other nodes spending the inputs back to himself.
In this case it is suggested that conflicting messages will cancel each other out and clients wait for normal block confirmation."
Controlling the 10 masternodes is not implausible at all (and doesn't necessarily require a "large portion" as the paper claims), since the attacker gets to choose the time of the attack, and may also be able to game the selection somehow.
In general you can't assume that everyone sees everything at the same time, or even that people know they haven't seen something they haven't seen. When there is wording like "propagate to all nodes" or "all nodes will do X" in the description, you can be sure that issues are being missed, ignored, or papered over.