That article about databases doesn't have to contend with double-spends which infect everything irreversibly downstream. This added wrinkle for cypto currency is what makes CAP more strictly inviolable on us, i.e. we can't in general recover Consistency from multiple partitions.
Really? You want to stick with that train of thought?
Aside from the fact you seem to be conflating the issue of double-spending to a single problem, when it is in fact two issues, a double-spend is akin to many issues that a database has to deal with and is VERY relevant.
Assume we have 3 machines with a copy of a database, and this database contains the state of some object. The state of some object is A in all 3. Then, one of these machines sets the state of an object to B, and another sets the state to Z. The remaining machine A now has to decide which of the 3 states are correct, A, B or Z. The database is in a partitioned state, which is exactly the same as what an
internal double-spend results in, a conflict of state.
In crypto, A is the existing state, B is a spend to one place and Z is a spend to another. The machines with state A then have to decide whether to ignore the new conflicting 2 spends entirely and stick with A, or pick between one of the spends B or Z.
In the case of a database, the choice of selecting A, B or Z effects everything irreversibly downstream also, just like it does here, they are the same thing.
In the case of write-only database, the inconsistency can always be merged. I was stating that in general due to double-spends, paritions can't be merged. Indeed in a read/write database where clients of the database base their data writes on the state of the database, then inconsistency infects irreversibly same as for double-spends.
My point is that cases of relaxed CAP implications that apply to one type of network do not apply to our case which is strictly inviolable.
For example that article says:
Second, the choice between C and A can occur many times within the same system at very fine granularity; not only can subsystems make different choices, but the choice can change according to the operation or even the specific data or user involved. Finally, all three properties are more continuous than binary. Availability is obviously continuous from 0 to 100 percent, but there are also many levels of consistency, and even partitions have nuances, including disagreement within the system about whether a partition exists.
Which is inapplicable to the inviolable point the double-spends in multiple partitions can't be merged. This ends up infecting every possible design you can think of to temporarily enable partitions, unless you accept reversibility of transactions (tolerance for inconsistency) or give up Access during that temporal partitioning. CAP is strict on our situation.