Clarify ephemeral coin spends

CHIPs/chip-0014.md

@@ -94,17 +94,25 @@ This CHIP's soft fork will include the following update to the behavior of these
 
 These changes come with an additional advantage -- by changing the behavior to rely on the previous block's time stamp, the incentive for farmers to pick an inaccurate timestamp for the current block is also removed when these conditions exist in the mempool.
 
+### Negative values
+
+In the current implementation (prior to this CHIP), the parser ignores all negative values for the `ASSERT_*_RELATIVE` conditions. For example, `ASSERT_HEIGHT_RELATIVE -1` and `ASSERT_SECONDS_RELATIVE -1` both result in successful no-ops.
+
+If this CHIP is accepted, negative values will be assessed. Thus, conditions that use negative values could either succeed or fail, depending on the circumstances when the conditions are used.
+
 ### Ephemeral coin spends
 
-An ephemeral coin spend is a coin that's created and spent in the same block. The birth timestamp of a coin is the same as the timestamp of the block it was created in. The **current** implementation (prior to this CHIP) contains the following behaviors regarding ephemeral coin spends:
-* `ASSERT_HEIGHT_RELATIVE -1` does not work for ephemeral coin spends. This is because the comparison is made against the previous transaction block height.
-* `ASSERT_SECONDS_RELATIVE -1` results in a success no-op. This is because the comparison is made against the current time stamp.
+An ephemeral coin spend is a coin that is created and spent in the same block. The birth timestamp of a coin is the same as the timestamp of the block it was created in. The **current** implementation (prior to this CHIP) contains the following behaviors regarding ephemeral coin spends:
+* `ASSERT_HEIGHT_RELATIVE 0` will fail because the previous transaction block's height is less than the current height plus zero.
+* `ASSERT_SECONDS_RELATIVE 0` will succeed because the current block's time stamp is greater than or equal to the current block's timestamp plus zero.
 
-Because this CHIP will modify the behavior of `ASSERT_SECONDS_RELATIVE`, the behavior of ephemeral coin spends when this condition is used will also change. Specifically, `ASSERT_SECONDS_RELATIVE -1` will no longer work. This is because the condition's new behavior will be to compare against the previous time stamp.
+If this CHIP is accepted:
+* `ASSERT_HEIGHT_RELATIVE 0` will continue to fail; its functionality will not have changed.
+* `ASSERT_SECONDS_RELATIVE 0` will fail because the previous block's time stamp is less than current block's timestamp plus zero.
 
-Despite removing a farmer's incentive to modify a block's timestamp (as explained in the previous section), this incentive will still exist for ephemeral coin spends. This is because an ephemeral coin's birth timestamp is the same as the block's, and relative timestamp conditions could be used to depend on it. Because of this, two more changes will be made in this CHIP:
-* Disallow relative time lock conditions on ephemeral coin spends. This will also ensure that the current implementation of treating a negative value as a no-op remains valid.
-* Add a new `ASSERT_EPHEMERAL` condition, which is listed in the [New conditions](#new-conditions) section. This condition will require a coin to have been created in the same block as it is being spent.
+Despite removing a farmer's incentive to modify a block's timestamp (as explained in the [Modified conditions](#modified-conditions) section), this incentive will still exist for ephemeral coin spends. This is because an ephemeral coin's birth timestamp is the same as the block's, and negative relative timestamp conditions could be used to depend on it. Because of this, two more changes will be made in this CHIP:
+* Disallow relative time lock conditions on ephemeral coin spends (this applies when the time lock values are negative). This will also ensure that the current implementation of treating a negative value as a no-op remains valid.
+* Add a new `ASSERT_EPHEMERAL` condition, which is listed in the [New conditions](#new-conditions) section. This condition will require a coin to have been created in the same block as it is being spent. See also the note concerning this condition in the [Security](#security) section.
 
 ## Reference Implementation
 
@@ -142,10 +150,13 @@ This CHIP comes with several security risks, all of which we feel are outweighed
     * If the current block height is `100` and a coin is created with `(ASSERT_BEFORE_HEIGHT_ABSOLUTE 100)` in its puzzle, then at the time of the coin's creation, its last valid block height has already passed, so it will never be able to be spent.
     * If a coin is created with a puzzle that contains contradicting conditions, such as `(ASSERT_BEFORE_HEIGHT_ABSOLUTE 100)` and `(ASSERT_HEIGHT_ABSOLUTE 100)`, then it can never be spent.
 
+    Finally, if the `ASSERT_EPHEMERAL` condition is used in a coin's puzzle, rather than its solution, a farmer may choose to include the creation -- but not the ephemeral spend -- of the coin in the new block. The coin will never be considered ephemeral again, so the `ASSERT_EPHEMERAL` condition will fail for all future attempts to spend the coin. Thus, the farmer will have forced the coin to be bricked.
+
     In order to mitigate this risk, we will strongly recommend all Chialisp developers not to create any coins that include any of the conditions from this CHIP in their puzzles. The correct way to use these conditions is in the solution of a delegated puzzle. In this case, only the current spend of the coin could expire, but the coin itself would remain valid.
 
 4. A coin spend that has expired could become spendable in a re-org. This could lead to unintended consequences for anyone monitoring the blockchain to determine when the coin spend becomes invalid. However, because re-orgs are rare in Chia, this is unlikely to lead to any security issues.
 
+
 ## Additional Assets
 
 None