more edits

RFC/src/RFC-0202_TariScriptOpcodes.md

@@ -325,21 +325,21 @@ push 0.
 Identical to [`CheckSig`](#checksigmsg), except that nothing is pushed to the stack if the signature is valid, and the
 operation fails with `VERIFY_FAILED` if the signature is invalid.
 
-##### RistrettoPoint,
+##### ConvertToRistrettoPoint,
 
 Pop the top element, converts it to a Ristretto point, and pushes this to the stack.
 
 * Fails with `EMPTY_STACK` if the stack is empty.
 * Fails with `INVALID_INPUT` if the top stack element is not a input.
 
-##### Ed25519Point,
+##### ConvertToEd25519Point,
 
 Pop the top element, converts it to a Ed25519 point, and pushes this to the stack.
 
 * Fails with `EMPTY_STACK` if the stack is empty.
 * Fails with `INVALID_INPUT` if the top stack element is not a input.
 
-##### Secp256k1Point,
+##### ConvertToSecp256k1Point,
 
 Pop the top element, converts it to a Secp256k1 point, and pushes this to the stack.
 

RFC/src/RFC-0241_AtomicSwapXMR.md

@@ -124,24 +124,30 @@ transaction will reveal Bob's Monero key so that if Alice reappears, she can cla
 The image below details the time flow of the Tari transactions spending the Tari UTXO. 
 ![swap flow](assets/TXR_XMR_flow.png)
 
-## Heights and other considerations
+## Heights, Security, and other considerations
 
-It should be noted that when looking at the two lock heights, the first lock height should be sufficiently large enough
-to give ample time for Alice to post the Tari UTXO transaction and for it to be mined with a safe number of confirmations,
+There are a few things we need to consider for this to be secure as there are possible scenarios that can reduce the security
+in the atomic swap. 
+
+When looking at the two lock heights, the first lock height should be sufficiently large enough to give ample time for Alice to post the Tari UTXO transaction and for it to be mined with a safe number of confirmations,
 and for Bob to post the Monero transaction and for it to be mined with a safe number of confirmations. The second lock
 height should give ample time for Alice after the first lock height to re-claim her Tari. Larger heights here might make
 refunds slower, but it should be safer in giving more time to finalize this. 
 
-
 Allowing both to claim the Tari after the second lock height is, on face value, a safer option. This can be done by enabling
-either party can claim the script with the lapse transaction. The counterparty can then claim the Monero, however, this
+either party to claim the script with the lapse transaction. The counterparty can then claim the Monero. However, this
 will open up an attack vector to enable either party to claim the Monero while claiming the Tari. Either party could trivially
 pull off such a scheme by performing a front-running attack and having a bit of luck. The counterparty monitors all broadcast 
 transactions to base nodes. Upon identifying the lapse transaction, they do two things; in quick succession, broadcast 
 their lapse transaction and the transaction to claim the Monero, both with sufficiently high fees. Base nodes will 
 prefer to mine transactions with the higher fees, and thus the counterparty can walk away with both the Tari and the 
 Monero.
 
+It is also possible to prevent the transaction from being mined after being submitted to the mempool. This can be caused by a combination
+of a too busy network, not enough fees, or a too-small period in the time locks. When one of these atomic swap transactions gets published to a mempool, we effectively already have all the details exposed. For the atomic swaps, it means we already revealed the Monero key, although
+the actual Tari transaction has not been mined. But this is true for any HTLC or like script on any blockchain. But in the odd
+chance that this does happen whereby the fees are too little and time locks not enough, it should be possible to do a child-pays-for-parent
+transaction to bump up the fees on the transaction to get it mined and confirmed.
 
 ## Key construction
 
@@ -165,13 +171,13 @@ $$
 
 This method relies purely on TariScript to enforce the exposure of the private Monero aggregate keys. The script forces 
 the spending party to supply their Monero private key part as input data to the script, evaluated via the operation 
-`Ed25519Point`. This TariScript operation will reveal part of the aggregated Monero private key publicly but this is still secure:
+`Ed25519Point`. This TariScript operation will reveal part of the aggregated Monero private key publicly, but this is still secure:
 see [Key security](#key-security).
 
 The simplicity of this method lies therein that the spending party creates all transactions on their 
 own. Bob requires a pre-image from Alice to complete the swap transaction; Alice needs to verify that Bob published the 
 Monero transaction and that everything is complete as they have agreed. If she is happy, she will provide Bob with the 
-pre-image to immediately claim the Tari UTXO.
+pre-image to claim the Tari UTXO.
 
 ### Key security
 
@@ -181,21 +187,21 @@ the secret key with just one part.
 
 $$
 \begin{aligned}
-(xm_a + xm_b) \cdot M &= xm_a \cdot M + xm_b \cdot M\\\\
-(xm_a + xm_b) \cdot M &= Xm_a + Xm_b \\\\
-(xm_a + xm_b) \cdot M &= Xm \\\\
+(xm_a + xm_b) \cdot G_m &= xm_a \cdot G_m + xm_b \cdot G_m\\\\
+(xm_a + xm_b) \cdot G_m &= Xm_a + Xm_b \\\\
+(xm_a + xm_b) \cdot G_m &= Xm \\\\
 \end{aligned}
 \tag{2}
 $$
 
-We know that \\(Xm\\), \\(Xm_a\\), \\(Xm_b\\) is public. While \\(xm\\), \\(xm_a\\), \\(xm_b\\) are all private.
+We know that \\(Xm\\), \\(Xm_a\\), \\(Xm_b\\) are public. While \\(xm\\), \\(xm_a\\), \\(xm_b\\) are all private.
 
 But if we expose \\(xm_b\\), we can try to do the following:
 $$
 \begin{aligned}
-(xm_a + xm_b) \cdot M &= Xm_a + Xm_b\\\\
-xm_a \cdot M &= (Xm_a + Xm_b - xm_b \cdot M) \\\\
-xm_a \cdot M &= Xm_a \\\\
+(xm_a + xm_b) \cdot G_m &= Xm_a + Xm_b\\\\
+xm_a \cdot G_m &= (Xm_a + Xm_b - xm_b \cdot G_m) \\\\
+xm_a \cdot G_m &= Xm_a \\\\
 \end{aligned}
 \tag{3}
 $$
@@ -207,11 +213,11 @@ hardware. Thus this is still secure even though we leaked part of the secret key
 
 The Script used for the Tari UTXO is as follows:
 ``` TariScript,ignore
-   Ed25519Point
+   ConvertToEd25519Point
    CheckHeight(height_1)
    LtZero
    IFTHEN
-      PushPubkey(Xm_b)
+      PushHash(Xm_b)
       EqualVerify
       HashSha256 
       PushHash(HASH256{pre_image})
@@ -221,11 +227,11 @@ The Script used for the Tari UTXO is as follows:
       CheckHeight(height_2)
       LtZero
       IFTHEN
-         PushPubkey(Xm_a)
+         PushHash(Xm_a)
          EqualVerify
          PushPubkey(K_{Sa})
       Else
-         PushPubkey(Xm_b)
+         PushHash(Xm_b)
          EqualVerify
          PushPubkey(K_{Sb})
       ENDIF
@@ -235,6 +241,8 @@ The Script used for the Tari UTXO is as follows:
 Before `height_1`, Bob can claim the Tari UTXO by supplying `pre_image` and his private Monero key part `x_b`. After 
 `height_1` but before `height_2`, Alice can claim the Tari UTXO by supplying her private Monero key part `x_a`. After 
 `height_2`, Bob can claim the Tari UTXO by providing his private Monero key part `x_b`.
+The operation `PushHash` is used to push the Ed25519 public key onto the stack, we don't want to use the public key here except for
+comparison purposes, so we keep it as a byte array. 
 
 ### Negotiation
 
@@ -256,8 +264,8 @@ The Monero key parts for Alice and Bob is constructed as follows:
 
 $$
 \begin{aligned}
-Xm_a' &= xm_a' \cdot M \\\\
-Xm_b' &= xm_b' \cdot M \\\\
+Xm_a' &= xm_a' \cdot G_m \\\\
+Xm_b' &= xm_b' \cdot G_m \\\\
 xm_a &=  \hash{\hash{Xm_a' \cat Xm_b'} \cat Xm_a' } * xm_a' \\\\
 xm_b &=  \hash{\hash{Xm_a' \cat Xm_b'} \cat Xm_b' } * xm_b' \\\\
 Xm_a &=  \hash{\hash{Xm_a' \cat Xm_b'} \cat Xm_a' } * Xm_a' \\\\
@@ -418,8 +426,8 @@ $$
 \begin{aligned}
 xm_a' &= x_a' \\\\
 xm_b' &= x_b' \\\\
-Xm_a' &= x_a' \cdot M \\\\
-Xm_b' &= x_b' \cdot M \\\\
+Xm_a' &= x_a' \cdot G_m \\\\
+Xm_b' &= x_b' \cdot G_m \\\\
 X_a' &= x_a' \cdot G \\\\
 X_b' &= x_b' \cdot G \\\\
 x_a &=  \hash{\hash{X_a' \cat X_b'} \cat X_a' } * x_a' \\\\
@@ -489,7 +497,7 @@ $$
 e = \hash{X_a \cat Xm_a \cat R_{ZTa} \cat R_{ZMa}} \\\\
 s_{ZTa} = r + e(x_a) \\\\
 R_{ZTa} = r \cdot G \\\\
-R_{ZMa} = r \cdot M \\\\
+R_{ZMa} = r \cdot G_m \\\\
 \end{aligned}
 \tag{9}
 $$
@@ -530,7 +538,7 @@ $$
 e = \hash{X_b \cat Xm_b \cat R_{ZTb} \cat R_{ZMb}} \\\\
 s_{Zb} = r + e(x_b) \\\\
 R_{ZTb} = r \cdot G \\\\
-R_{ZMb} = r \cdot M \\\\
+R_{ZMb} = r \cdot G_m \\\\
 \end{aligned}
 \tag{11}
 $$
@@ -553,7 +561,7 @@ $$
 \begin{aligned}
 e &= \hash{X_b \cat Xm_b \cat R_{ZTb} \cat R_{ZMb}} \\\\
 s_{Zb} \cdot G &= R_{ZTb} + e(X_b) \\\\
-s_{Zb} \cdot M &= R_{ZMb} + e(Xm_b) \\\\
+s_{Zb} \cdot G_m &= R_{ZMb} + e(Xm_b) \\\\
 \end{aligned}
 \tag{13}
 $$
@@ -573,7 +581,7 @@ $$
 \begin{aligned}
 e &= \hash{X_a \cat XM_a \cat R_{ZTa} \cat R_{ZMa}} \\\\
 s_{Za} \cdot G &= R_{ZTa} + e(X_a) \\\\
-s_{Za} \cdot M &= R_{ZMa} + e(Xm_a) \\\\
+s_{Za} \cdot G_m &= R_{ZMa} + e(Xm_a) \\\\
 \end{aligned}
 \tag{15}
 $$
@@ -810,7 +818,7 @@ assigned greek lowercase letters in most cases. Some terms used here are noted d
 | Bob's adaptor signature     | \\( b'_{Sb} \\)       | Bob's adaptor signature for the \\( b_{Sb} \\) of the script_signature of the utxo |
 | Ristretto G generator       | \\(k \cdot G  \\)     | Value k over Tari G generator |
 | Ristretto H generator       | \\(k \cdot H  \\)     | Value k over Tari H generator |
-| ed25519 G generator         | \\(k \cdot M  \\)     | Value k over Monero G generator |
+| ed25519 G generator         | \\(k \cdot G_m  \\)     | Value k over Monero G generator |
 
 
 [HTLC]: Glossary.md#hashed-time-locked-contract