@anonymint says:
In the case of 4, well, its just a disaster. Blocks can be replaced all the way back to the last checkpoint potentially and all transactions from that point could be destroyed.
Checkpoint is useless against a majority of the world's hashrate. The attacker can even divide-and-conquer the vested interests of the majority of the users:
https://medium.com/@shelby_78386/the-caveat-though-is-that-when-the-attacker-can-fork-the-vested-interests-of-some-of-the-users-9340dd037a61https://bitcointalk.org/index.php?topic=4266048.40#msg39124755In the case of 3, which is by far the most difficult to resolve, the partition tolerance reduces proportional to the duration of the partitioned state, and becomes more difficult to resolve without consequence in any system, as there may be conflicting actions which diverge the resulting state of all partitions further away from each other. These partition events will always become unsolvable at some point, no matter what the data structure, consensus mechanisms or other exotic methods employed, as it is an eventuality that one or more conflicts will occur.
The fact is that DAGs/Tangles and our channels have a better partition resolution performance in the case of event 3 as the data structures are more granular. An inconsistency in P doesn't affect the entire data set, only a portion of it, thus it is resolvable without issue more frequently as the chances of a conflict preventing resolution is reduced.
Now, you haven't provided any detail on exactly how you imagine a data structure that uses blocks that could merge non-conflicting partitions, let alone conflicting ones. In fact I see no workable method to do this with blocks that may contain transactions across the entire domain. Furthermore, who creates these "merge" blocks and what would be the consensus mechanism to agree on them? In the event of a conflict, how do you imagine that would be resolved?
One possible solution which @anonymint first wrote about in 2014 (and @patmast3r
mentioned in 2016 which I dismissed at that ime only the context of the Iota-style DAG) is that double-spending burns all the UTXO involved. All lineage balances are reduced by the destroyed value. And if the payer associates a KYC identity, then all (or the amount designated by the payer) UTXO of that identity are destroyed or used to pay all of the double-spends instead of burning them if the designated amount is sufficient to pay all. Or stated in another way independent of KYC, the payer may designate some other UTXO which is time locked guaranteeing he will not issue a double-spend. Note even if the attacker had forked the chain before commitment to the time lock and orphans the commitment, then the attacker doesn't succeed in double-spending because the network remembers the signed commitment regardless of it being on an orphaned fork and inserts into any subsequent block unless the attacker can sustain censorship of the winning fork indefinitely. Yet this penalty system has to have some expiration into finality, otherwise an attacker can maliciously burn lineage far in the past causing current descendent UTXO to be burned. The payee (and all payees down the lineage chain) then judge the risk of the transaction based on the amount of UTXO still guaranteeing against double-spend combined with the depth of the confirmations. It's important to understand that all consensus is probabilitistic because of the physics of our universe.
However this proposed solution may not work in general cases of smart contracts although it can adapted to smart contracts in smart contracts where each user action is provably either a descendent or replacement of a prior action, so that issuing replacements can be penalized. And each such linearlized action chain has to be independent of the other ones, so that removing actions in one chain doesn't impact other action changes. An example of an independent linearized action chain, is a blog author making sequential edits of his blog. That would be independent of the edits of the other blogs of that author and other authors. Note that these attributes are actually necessary in any smart contract system which employs blocks, because otherwise the block producer could influence the outcome of the interactions by controlling the ordering of contract transactions within each block. The smart contract thus can't assume these interactions are randomized nor deterministic from the perspective of the signers of the transactions. This is probably yet another security hole in many extant smart contracts.
Note this idea is employed in SPECTRE and @anonymint
pointed out that it would be incompatible with Replace-by-fee in Bitcoin. Yet his most
significant criticism was specific to the fact that SPECTRE doesn't form consensus around a single total order, so that criticism wouldn't apply to the idea above because the total order will designate that the double-spends are burned and can't be further transacted as UTXO. @anonymint's understanding of SPECTRE is that the status of UTXO being double-spent is interpreted by the payer and payees, not by any total order of the ledger and ledger validators.
Note this sort of design is also being discussed in the
ECDSA signatures: why not force the reuse for r for spends from the same address thread.
The best case scenario any system can hope for is that the actor with 51% majority can influence future events only, not the past! Because at least then, in the event of a complete system failure, you still have a true historical record of fact which can be trusted up to the point of failure.
100% finality of confirmations
requires a permissioned set of validators which has significant downsides to liveness.
See also the explanation below in response to @Ix.
Without a block reward, you are correct that the only incentive to be on a longest chain is so your transaction is confirmed unambiguously.
There are still transaction fees to consider (although obviously not in Iota), otherwise you might argue that bitcoin itself would suffer the same fate of diverging consensus, when the block reward expires.
Indeed that ends up being
exactly the case.
See also the further discussion of Byzcoin in the OmniLedger discussion in @anonymint's
latest blog.
So both of you were prescient.
That's what I'm trying to establish. As far as I can tell, there isn't any real cost (neither coins or electricity) to obtaining a majority of nodes, but I'll wait for fusilier's[fusillade's] reply.
Fixed that misspelling for you. Sorry I couldn't resist a little humor given the context of the discussion that was quoted from. In honor of the favorite word of the MSM in the Trump era.