improve 'Transaction Lifecycle' docs

Author: mr-zwets

website/docs/guides/lifecycle.md

@@ -5,33 +5,46 @@ sidebar_label: Transaction Lifecycle
 
 This guide will explain the "transaction lifecycle" of a Bitcoin Cash transaction. We'll talk about what the mempool is and how block inclusion works. Further we'll discuss the possibility of unconfirmed transaction chains and conflicting transactions to cover all the possibilities of the transaction lifecycle!
 
-## Mempool and Block-Inclusion
+## Block Inclusion
 
-Bitcoin Cash has a blocktime of 10 minutes, meaning that on average every 10 minutes a new block is found which adds a collection of transactions to the ledger. Before transactions are included in a block they are waiting for inclusion in the mempool of the full nodes.
+Bitcoin Cash has a blocktime of 10 minutes, meaning that on average every 10 minutes a new block is found which adds a collection of transactions to the ledger. On Bitcoin Cash it is standard for transactions to be included in the very next mined block.
 
-Miners can choose which transactions to include in their block. Some miners might set a higher minimum fee or mine empty blocks so transactions can remain pending in the mempool even though a new block was mined.
-
-:::note
-In Bitcoin Cash it is standard for transactions to be included in very next mined block. Because there is no network congestion, 
-the mempool can get cleared with the arrival of a new block.
+:::tip
+The minimum relay-fee for Bitcoin Cash transactions in 1 sat/byte, meaning a transaction with size 500 bytes has to pay at least 500 satoshis mining fee.
 :::
 
-Because transactions in the mempool are "seen" but not included in the blockchain yet, the latest state of the blockchain of who owns what is somewhat fuzzy. In some sense only the transaction with 6 confirmations are truly finalized but on the other hand in the normal scenario it's only a matter of time before transactions in the mempool get included in blocks and are 6 blocks deep in the blockchain.
+Miners choose which transactions to include in their block. Some miners might set a higher minimum fee or mine empty blocks so transactions can remain pending in the mempool even though a new block was mined. Under normal circumstances, a 1 sat/byte fee rate will be included in the next block but this is not guaranteed.
+
+## Mempool
+
+Before transactions are included in a block they are waiting for block inclusion in the mempool of the full nodes. Because transactions in the mempool are "seen" but not included in the blockchain yet, the latest state of the blockchain of who owns what is somewhat fuzzy. 
+
+In some sense only the transactions with 6 confirmations are truly finalized but on the other hand in the normal scenario it's only a matter of time before transactions in the mempool get included in blocks and are 6 blocks deep in the blockchain.
 
 Where things get more complex however is if there are **competing unconfirmed transactions**. In this scenario it is **not** necessarily the case that a transaction is destined to be included in the blockchain. In other words, the latest state of the blockchain is still undecided.
 
 :::tip
 This is why many BCH indexers will allow you to query UTXOs with the option to include or exclude unconfirmed transactions. By default indexers will include unconfirmed UTXOs/unconfirmed transactions in the query result.
 :::
 
+## First-Seen Rule
+
+The "first-seen rule" is a default mempool inclusion and relay rule for full nodes which says that for any UTXO the first seen spending transaction is the one that gets included in the node's mempool and relayed. The default relay policies on Bitcoin Cash have been designed in such a way to maximally enable "0-conf" transactions meaning transactions with zero confirmations but which can still be considered reasonably secure.
+
+:::note
+On BTC the mempool node default policy got changed to replace-by-fee, and tooling to submit your non-standard transaction directly to mining pools has become commonplace with ordinals.
+:::
+
+The first-seen rule is subjective based on time, because of this different parts of the network might enforce this rule for conflicting transactions in case of a race condition. For P2PKH transactions a trustless notification system was developed called [double-spend-proofs](https://docs.bitcoincashnode.org/doc/dsproof-implementation-notes/) (DSPs). However DSPs unfortunately do not work for smart contract transactions.
+
 ## Unconfirmed Transaction Chains
 
 Unconfirmed transactions can be chained after one another meaning that even an output of an unconfirmed transaction can already be spent in a new transaction. This means you can have competing unconfirmed transaction **chains** where child transactions are chained to an unconfirmed parent. Any competing transaction for one of the parent transactions then presents a cancellation of the whole chain of dependent child transactions.
 
 There is no maximum to the length of an unconfirmed transaction chain on BCH, software of full nodes has been upgraded to allow for arbitrary length unconfirmed tx chains. This is very important for public covenants which might have many users interacting and transacting with the same smart contract UTXO.
 
 :::tip
-On Bitcoin Cash it is possible to design smart contract systems which utilize long unconfirmed transaction chain, avoiding the need for blockchain confirmations. However contract developers should be mindful of the possibility of competing transaction chains.
+On BCH it's possible to design smart contracts which use long unconfirmed transaction chains, avoiding the need to wait for blockchain confirmations.
 :::
 
 ## Competing Transactions
@@ -50,16 +63,8 @@ However, it is also possible double-spends are created intentionally. For exampl
 Smart contract developers developing applications at scale should consider the game-theoretic interaction of advanced, rational economic actors who might benefit from competing against instead of cooperating on building a transaction chain.
 :::
 
-## First-Seen Rule
-
-The "first-seen rule" is a default mempool inclusion and relay rule for full nodes which says that for any UTXO the first seen spending transaction is the one that gets included in the node's mempool and relayed. Because the first-seen rule is subjective based on time, different part of the network might enforce this rule for conflicting transactions in case of a race condition.
+## Adversarial Scenarios
 
-:::note
-In case of normal a P2PKH transaction this time window for race conditions is the risk window where it's beneficial to listen for double spends with [double-spend-proofs (DSPs)](https://docs.bitcoincashnode.org/doc/dsproof-implementation-notes/).
-:::
-
-Importantly, the "first-seen rule" is just a default and a network relay rule, advanced actors might send double-spend transactions with a significantly higher fee (bribe) to miners directly. Custom configured miners who actively maximize transaction fee revenue would accept the bribe transaction and switch off the "first-seen rule" altogether. However the majority of the Bitcoin Cash network will not relay such late double spend attempts in accordance with the first-seen rule.
+This guide laid out the "transaction lifecycle" of a Bitcoin Cash transaction in general cases but it can be beneficial to specifically analyze how your smart contract system would hold up in adversarial scenarios. For an in depth guide on this more advanced topic, see [the adversarial analysis guide](/docs/guides/adversarial).
 
-:::caution
-On BTC the mempool node default policy got changed to replace-by-fee, and tooling to submit your non-standard transaction directly to mining pools has become common place with ordinals.
-:::
+Some examples are of adversarial scenarios include: what if the minimum relay fee increase? what if the "first-seen-rule" starts to break down? What if we start to see MEV on Bitcoin Cash?