add initial prose writeup of fraud types
@@ -23,3 +23,63 @@ ifndef::tbtc[toc::[]]
=== Aborts / Liveness
=== Fraud
+
+The system recognizes two redundant fraud proofs: ECDSA, in which the signing
+group produces a signature on a message which was not explicitly requested,
+and SPV, in which the UTXO custodied by the signing group moves for an unknown
+reason. Intuitively, the UTXO should not be able to move without ECDSA fraud,
+however, the system accepts either proof (and may require both proofs in
+certain cases). Each proof its own limitations and security parameters. When
+fraud is detected, the system penalizes the signers by seizing their bonds.
+
+==== ECDSA Fraud Proofs
+
+The signers collectively control an ECDSA keypair. By cooperating, they can
+produce signatures under the public key. Signers are charged with producing
+certain signatures (e.g. on a redemption transaction during the redemption
+process). Any valid signature under the signers' public key, but not
+specifically requested by the system is considered fraud.
+
+An ECDSA fraud proof is simply a signature under the signers' public key, the
+signed message digest, and the preimage of that digest. From there we perform
+regular ECDSA verification. If the preimage matches the digest and the
+signature on the digest is valid but the digest was not explicitly requested by
+the system, then we can be sure that the signer set is no longer reliable. It
+is worth noting here, that verification of the preimage-digest relationship may
+not be skipped. Given any public key, it is possible to construct a signature
+under that public key and select a digest that matches it. Which is to say,
+anyone can produce an apparently valid signature on any unknown message.
+Only direct verification of the preimage's existence (via checking its
+relationship to the signed digest) prevents this attack as the attacker would
+have to invert the hash function to forge this relationship.
+
+Notionally, the system can verify any signature the signers produce. However,
+the capabilities of the host chain set practical limitations. For instance, on
+Ethereum, only certain digest functions are available, so we cannot verify
+signatures on digests produced by unsupported hash functions. As a practical
+example, this precludes verification of Decred signatures, which use blake256.
+Signers in an Ethereum-hosted system can produce signatures on Decred
+transactions with no possibility of punishment.
+
+All host chain impose costs on argument size, Therefore cost of verification
+scales with the length of the preimage. This means that it may not be
+economically feasible to verify signatures on very long pre-images, or that
+attempting to do so will exceed resource-use limitations (e.g. Ethereum's block
+gas limit). Fortunately, Bitcoin's signature hash algorithm uses double-sha256.
+This means that the preimage to the signed digest is always 32 bytes. As such,
+verification costs never scale with transaction size, and even very large
+transactions do not evade ECDSA fraud verification.
+
+==== SPV Fraud Proofs
+
+// TODO: link SPV description
+
+The signers custody a single Bitcoin UTXO. If that UTXO moves, except at the
+direction of the system then the signers have failed to perform their duties.
+SPV Proofs of Bitcoin inclusion (as documented here) suffice to prove signer
+fault. If the coins move, and its movement was not specifically requested by
+the system, then the signers have failed in their custodial duties. Compared to
+ECDSA Fraud proofs, SPV Fraud Proofs are more expensive to verify and have a
+weaker security model. The system expects SPV Fraud Proofs only rarely, and
+subjects them to much higher work requirements than SPV funding and redemption
+proofs.
