diff --git a/README.md b/README.md
index e9b3b38..9f6a27c 100644
--- a/README.md
+++ b/README.md
@@ -15,13 +15,19 @@ To instantiate a DKG there are many possible schemes which differ by the guarant
 Since DKGs are difficult to implement correctly in practice, this document describes DKGs that are relatively *simple*, namely SimplPedPop and SecPedPop.
 However, the DKG can be swapped out for another one if desired.
 
+<!-- Can it though? I understood the claim of the "practical" paper was that the keygen and signing must be proved secure together. Is there some way of checking whether a DKG can be replaced with another. Is there some functionality we can simulate or a game we can reduce to? -->
+
 The DKG outputs the shared public key and a secret share for each signer.
 It is extremely important that both outputs are securely backed up because losing the share will render the signer incapable of producing signatures.
 In order to reduce the chance of losing the backup, it is possible to encrypt the backup and send it to every other signer.
 If a signer loses the local backup, as long as there's at least one other signer that cooperates and sends back the encrypted backup, the signer can restore (see also [repairable threshold signatures](https://github.com/chelseakomlo/talks/blob/master/2019-combinatorial-schemes/A_Survey_and_Refinement_of_Repairable_Threshold_Schemes.pdf).
 
+<!-- But then one must back up the deryption key? I think we should clear this up by explaining what your options are in "backup and recover section". This is an option where you have a long lived secret you can encrypt to. The other solution that is always available to you is to use MPC to recover the share with a threshold of parties. This also allows issuing a new share i.e. enrollment. Not suggesting we should specify that here  but for our project at least this is a more appropriate solution. -->
+
 Once the DKG concludes successfully, it is recommended to rule out basic mistakes in the setup by having all signers create a FROST signature for some test message.
 
+<!-- Nice idea. I'd soften the recommendation to "Applications should consider..".  -->
+
 ### SimplPedPop
 
 We specify the SimplPedPop scheme as described in [Practical Schnorr Threshold Signatures
@@ -32,6 +38,8 @@ Without the Algebraic Group Model, section 4](https://eprint.iacr.org/2023/899.p
 - Very rudimentary ability to identify misbehaving signers in some situations.
 - The proof-of-knowledge in the setup does not commit to the prover's id. This is slightly simpler because it doesn't require the setup algorithm to know take the id as input.
 
+<!-- This is indeed what we do atm but there's a good reason to using small integer indicies: You can ask a user to etch a number onto a 24 seed word backup plate. Also something like BIP93 for when you can backup a short bech32 string. Like bip93 we'd wanna keep the index to ≤ 2⁵ -->
+
 SimplPedPop requires SECURE point-to-point channels between the participants, i.e., channels that are ENCRYPTED and AUTHENTICATED.
 The messages can be relayed through a coordinator who is responsible to pass the messages to the participants as long as the coordinator does not interfere with the secure channels between the participants.
 
@@ -83,7 +91,7 @@ def simplpedpop_finalize(ids, my_id, vss_commits, shares, eta = ()):
             throw BadParticipant(ids[i])
         if not verify_sig(vss_commits[i].sig, vss_commits[i][0], "")
             throw BadParticipant(ids[i])
-    eta += (sig, vss_commit[i])
+        eta += (sig, vss_commit[i])
     if not Eq(eta):
         return False
     # helper_compute_pk computes the individual pubkey of participant with the given id
@@ -104,7 +112,7 @@ def secpedpop_round1(seckey):
     return individual_pk(seckey)
 ```
 
-The public keys are set to each other.
+The public keys are sent to each other.
 Every participant stores the received public keys in the `pubkeys` array.
 
 ```python
@@ -221,3 +229,23 @@ TODO Consider a variant based on MuSig2
 If the participants run a BFT-style consensus protocol (e.g., as part of a federated protocol), they can use consensus to check whether they agree on `x`.
 
 TODO: Explain more here. This can also achieve termination but consensus is hard (e.g., honest majority, network assumptions...)
+
+
+<!-- An important question here is how many parties need to give input of polynomial commitments for the key generation? -->
+<!-- It would be prohibitive to require that the number of input parties is the same number as those receiving shares (which would be every consensus node). The spec implicitly implies this invariant atm. -->
+
+
+<!-- If we have n = 3T + 1 (where T is number of corrupted parties) and `n` is the consensus nodes -->
+<!-- I claim you only need T + 1 parties to be involved in keygen for it to be secure (i.e. only one -->
+<!-- honest party). This means if we get consensus on the need to generate key then there will be at -->
+<!-- least T+1 nodes who provide input in the next epoch in an atomic broadcast consensus algo like -->
+<!-- HoneyBadgerBFT (https://eprint.iacr.org/2016/199.pdf) so it can be done in one round. -->
+
+<!-- So I think we have to allow the number of parties receiving shares be different from the number that receive shares. Also these two groups can be totally disjoint. On one extreme you can have a trusted party who generates key shares for a bunch of other parties for example. On the other you can have a group of `N` parties contribute polynomial commitments for a smaller group of `n` nodes where `N ⊃ n`. We are doing this in frostsnap so that we have extra randomness go into the key generation. -->
+
+<!-- On the other hand, I'm not sure we should recommend this protocol for honest majority settings. There are elegant, efficient and information theoretically secure protocols that can do sharings in batch. -->
+<!-- These slides have the closest thing to what I have in mind (but they are not for key specifically but secret sharing sharing): -->
+
+<!-- https://tcc.iacr.org/2020/workshop/tcc-tot-2020.pdf (see "Random Sharings with HIM") -->
+<!-- There's also this more sophisticated schemes like https://eprint.iacr.org/2023/1175 that I still haven't finished understanding yet. -->
+-
diff --git a/notes.md b/notes.md
index a118eb1..60be5e9 100644
--- a/notes.md
+++ b/notes.md
@@ -10,13 +10,17 @@
 - Need to document that we shouldn't throw away data until we're sure that the DKG either failed or succeeded. Otherwise, the DKG may end up succeeding after throwing away and someone sends funds to the address.
 - How modular do we want to design this? Do we support plugging in other DKGs?
 - Do we want to support some sort of share backup scheme (see also [repairable threshold sigs](https://github.com/chelseakomlo/talks/blob/master/2019-combinatorial-schemes/A_Survey_and_Refinement_of_Repairable_Threshold_Schemes.pdf))that sends share encrypted-to-self to other signers? As long as one other signer cooperates we can restore.
+<!-- I 'd not use the self-encrypted one. The enrollment scheme is nicer because it doesn't store extra data. Just having the shares is enough. If we agree on this we can just specify a bech32 format like BIP93 for shares and leave this stuff for future work. In addition we should specify how to generate the public keys from a threshold number of share images. --> 
 - Are we able to get rid of indices entirely? SimplPedPop uses indices, JessePedPop doesn't. It uses public keys instead.
   - use unique identifier instead of pubkey?
+  <!-- No. Indicies are useful for backups. Otherwise you have to back up the index as well. -->
 - Into how many functions should we split up the DKG. Jesse claims that splitting up has the advantage that "it's more flexible because with the proposed API the VSS can be generated prior to knowing the public keys of any participants"
 - Should it be possible to assign weights for weighted threshold sigs?
+<!-- I wouldn't unless we want to specify how to sign with multiple shares at once in a single signature. Easy to derive a correct protocol for this dunno about security. -->
 - Do we need to include the signature in the vss_hash? Probably not, but depending on how the rest is set up, it may not hurt.
 - Should the scheme support deterministic key derivation?
    - Not sure if that's actually that useful. And it only works as long as the code does not change, which we may not want to guarantee.
+   <!-- After a lot of thought on this: no it shouldn't. Everything can reproduced with a threshold of shares via MPC. Polynomials should use runtime randomness and deleted after share generation. -->
 - Is it impossible to sign if the `Eq` check fails? If not, we may want to tweak the public key by `eta` to make sure that signing fails.