unpublish unready sections (#32)

src/SUMMARY.md

@@ -6,29 +6,20 @@
 
 # Protocol
 
-1. [Overview](./overview.md)
-2. [Notarization](./protocol/notarization/README.md)
+1. [MPC-TLS](./protocol/notarization/README.md)
     - [TLS Handshake](./protocol/notarization/handshake.md)
     - [Encryption and Decryption](./protocol/notarization/encryption.md)
     - [Commitment](./protocol/notarization/commitment.md)
     - [Signing](./protocol/notarization/signing.md)
-3. [Verification](./protocol/verification.md)
-4. [Selective Disclosure]()
+2. [Verification](./protocol/verification.md)
+3. [Selective Disclosure]()
 
 # MPC
 
-- [Garbled Circuits](./mpc/garbled_circuits.md)
-- [Dual Execution with Asymmetric Privacy](./mpc/deap.md)
-- [Oblivious Transfer]()
-- [MAC](./mpc/mac.md)
-- [Finite-Field Arithmetic](./mpc/ff-arithmetic.md)
-- [Encodings](./mpc/encodings.md)
 - [Key Exchange](./mpc/key_exchange.md)
-- [ECtF](./mpc/ectf.md)
-- [Commitment scheme](./mpc/commitment_scheme.md)
+- [Finite-Field Arithmetic](./mpc/ff-arithmetic.md)
+- [Dual Execution with Asymmetric Privacy](./mpc/deap.md)
 - [Encryption](./mpc/encryption.md)
-- [TLS handhsake](./mpc/tls_handshake.md)
-- [Committed Oblivious Transfer]() <!-- (./mpc/committed_ot.md) -->
-- [Oblivious Transfer]() <!-- (./mpc/oblivious_transfer.md) -->
+- [MAC](./mpc/mac.md)
 
 +[Glossary](./glossary.md)

src/protocol/notarization/commitment.md

@@ -4,6 +4,4 @@ As part of the TLSNotary protocol, the `User` creates authenticated commitments
 
 A naive approach of creating such authenticated commitments is to extend the `Encryption and Decryption` steps to also compute a commitment (e.g. a blake3 hash) to the plaintext using MPC and have the `Notary` sign that commitment. Unfortunately, such MPC approach is too resource-intensive, prompting us to provide a more lightweight commitment scheme.
 
-The high-level idea is that the `User` creates a commitment to the encodings from the MPC protocol used for `Encryption and Decryption`. Since those encodings are chosen by the `Notary` and are not known to the `User` at the time when she makes a commitment, they can be thought of as "authenticated plaintext".
-
-For technical details on the commitment scheme, see [Commitment scheme](/mpc/commitment_scheme.md)
+The high-level idea is that the `User` creates a commitment to the encodings from the MPC protocol used for `Encryption and Decryption`. Since those encodings are chosen by the `Notary` and are not known to the `User` at the time when she makes a commitment, they can be thought of as "authenticated plaintext".