Double Spend

[tearodactyl]

Several Z coins were attacked with 51% double spend.
Partucularly, hard hit was Bitcoin Gold (BTG)
https://forum.bitcoingold.org/t/double-spend-attacks-on-exchanges/1362
https://forum.bitcoingold.org/t/anatomy-of-a-double-spend-51-attack/1398

The initial response by the exchanges is to increase the number of confirmations required, effectively buying more time against the chain reorganization. Detecting such events is crucial, though mitigation is TBD.
https://gist.github.com/gavinandresen/630d4a6c24ac6144482a
https://www.crypto51.app/

Heuristic grace period https://medium.com/@karbo.org/prevent-transaction-cancellation-in-51-attack-79ba03d191f0

[tearodactyl]

Zero has a lesser risk of an attack based on purchasing large volumes of existing hashing capacity i.e. on NiceHash or using a new Equihash ASIC miner that targets the Zcash params.
Additionally, due to a smallish market cap and trading volumes, at this point in time Zero is simply not a great target.
However, that should not stop improvements in this area, particularly if quality approaches are developed by other coins.
Specifically, Snowgem reduced the nMaxTip setting all the way down to a small handful of blocks, while ours is full 24 hours (720 blocks). Further evaluation of this change, particularly in the context of #17 postponed till after Fee Fork.

[tearodactyl]

Zcash reviewed for inclusion in Blossom (and pushed out to 2020) changes to support restricting maximum reorg (rollback) depth zcash#3678
Soon after the topic came-up again zcash#3782

RavenCoin attack https://medium.com/@tronblack/ravencoin-building-the-immune-system-23d077b65f71
Fixes RavenProject/Ravencoin#295
RavenProject/Ravencoin#316
FLO attack and using Raven solution https://medium.com/floblockchain/flo-team-response-to-51-attack-8c9ef683d7ba
Not using FeatherCoin checkpointing as centralized?

Bitcoin ABC added -maxreorgdepth (default 10) https://www.bitcoinabc.org/2018-11-20-bitcoin-abc-0-18-5/
https://github.com/Bitcoin-ABC/bitcoin-abc/releases/tag/v0.18.5
Code changes https://reviews.bitcoinabc.org/D2102
https://reviews.bitcoinabc.org/rABC917d65774c40c6bfad500a660e581c8ea5e20df0
Discussion https://twitter.com/pwuille/status/1065050225289519104
https://tomzander.gitlab.io/posts/reorg/
https://www.reddit.com/r/btc/comments/9z1gjo/on_the_new_deep_reorg_protection/

Coinbase detects ETC (Ethereum Classic) reorgs https://blog.coinbase.com/ethereum-classic-etc-is-currently-being-51-attacked-33be13ce32de

[tearodactyl]

Zcash code already has some logic for a limit, in main.cpp, from two years ago zcash#2463
But it is huge (COINBASE_MATURITY is 100 for Zcash and 720 for Zero)
main.h: static const unsigned int MAX_REORG_LENGTH = COINBASE_MATURITY - 1;
Maybe should be like 1/2 or 2/3 of the required confirmations.