Rework directories structure: CIP-XXXX.md -> README.md (cardano-found…

…ation#125)

* Rename all CIP-XXXX.md into README.md

  Github automatically renders README.md files in directories in their UI, which is makes quite convenient to navigate CIPs through Github. This would eventually replace the static website which is currently a big buggy, with deadlinks and not getting all the love it'd require. Plus, the scope of the CIP is already given by the parent directory, so there's really no need to repeat the filename.
  Small drawback however: this may break any existing link to CIPs, but, without being _too far off_. People should be able to recover the right CIP in a single click by going one directory up.

* Edit link to CIPs to now point to the parent directory instead of CIP-XXXX.md

* Adjust build and update scripts to the new structure.

* Keep CIP-XXXX.md files, but with a redirection to the README file.

BiweeklyMeetings/2021-03-16.md

@@ -104,7 +104,7 @@ PR -> ‘Draft’: Needs format + approval.
 **F** - This is looking at the various keys using accross Cardano. Matthias did you go over this one last time?  
 **M** - Maybe "Cryptographic key serialization" format is a bit too generic, because we don't really touch to vrf or other types of keys: We could maybe rename this CIP.  
 **D** - I have not looked at this one recently and this is one of the ones that requires more brainpower. We have a new Cryptographer that just joined, this might be a good task to look into to review and check if the CIP here is comprehensive. The good thing about this CIP is that this is documenting - so this just needs to be accurate.   
-**M** - This implements exactly what we have in both Cardano Adrestia and Cardano CLI and was discussed in Slack historically to agree on forma... Really how we want to serialize things and how does it compare to existing implementation and before (basically Jormungandr). The new one is more on the compact and it does recomputes some things on the fly. I guess both are fine but we could ask cryptographers, and maybe there's a good reason to package the private and public key and not recompute it all the time. We could almost go one step further: This specifies the datapart of the Bech32 payload that we specified in [CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/CIP-0005.md), but only for 4 of them. We have maybe 20 objects or so now in CIP5... so we could go for an expansion of CIP5, starting with the keys, but also going into payloads. I think we could document all of them. This very strongly seem to connect to CIP5, so maybe we should make that connection a bit more explicit.  
+**M** - This implements exactly what we have in both Cardano Adrestia and Cardano CLI and was discussed in Slack historically to agree on forma... Really how we want to serialize things and how does it compare to existing implementation and before (basically Jormungandr). The new one is more on the compact and it does recomputes some things on the fly. I guess both are fine but we could ask cryptographers, and maybe there's a good reason to package the private and public key and not recompute it all the time. We could almost go one step further: This specifies the datapart of the Bech32 payload that we specified in [CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md), but only for 4 of them. We have maybe 20 objects or so now in CIP5... so we could go for an expansion of CIP5, starting with the keys, but also going into payloads. I think we could document all of them. This very strongly seem to connect to CIP5, so maybe we should make that connection a bit more explicit.  
 **D** - Right, this is covering the greater compatibility issues. I feel someone should spend some time and brainpower on this. Because Matthias and I are rather busy..  
 **M** - agree.  
 **F** - Forward to Cryptographer at IOHK, Duncan to flag.  

BiweeklyMeetings/2021-04-27.md

@@ -73,7 +73,7 @@ PR -> ‘Draft’: Needs format + approval.
 #### Multi-signatures HD Wallets  
 ([PR69](https://github.com/cardano-foundation/CIPs/pull/69) - potential CIP-1854: "Multi-signatures HD Wallets")  
 **F** - This is the one we had a lengthy conversation last time (1854).    
-**M** - The changes from last time were to change the purpose instead of adding a new role - we will use a new purpose (1854) to distinguish multisg wallet from standard wallets and will keep the same coin type.  And we will keep a structure similar to the structure defined in 1852 and as a summary I recapped all that in a small table, but leaving the 'role=1' out, which is reserved for the internal adddresses in the standard wallets but will remain unused in the multisignature wallets so we will only use '0' for the payment keys and '2' for the stake keys after that the structure is the same. One account which is hardened and an index not hardened. This prevent mixing up a standard wallet and a shared wallet and also makes it possible to share the cosigners the account key without exposing your other normal payment keys to your cosigners - and makes it easier to extend both proposals, such as adding new roles for 1852 and piggyback on the same structure for 1854. For example the voting key could be added as a new role here (ex role=3) that could be added. Re: user-facing encoding we have defined new prefixes for the bech32 encoding so there isn't a shared prefix for all the keys coming from this particular proposal. I made the update to [CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/CIP-0005.md) directly, and it setups parallel for every key - [CIP-1852](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/CIP-1852.md) and [CIP-1854](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1854/CIP-1854.md) have their own formats. I added a bit to CIP-1852 to explain the rationale - if intent simply to extend the existing roles with a completely different semantic then it's fine to add a new role. The part about discovering the template does not change.   
+**M** - The changes from last time were to change the purpose instead of adding a new role - we will use a new purpose (1854) to distinguish multisg wallet from standard wallets and will keep the same coin type.  And we will keep a structure similar to the structure defined in 1852 and as a summary I recapped all that in a small table, but leaving the 'role=1' out, which is reserved for the internal adddresses in the standard wallets but will remain unused in the multisignature wallets so we will only use '0' for the payment keys and '2' for the stake keys after that the structure is the same. One account which is hardened and an index not hardened. This prevent mixing up a standard wallet and a shared wallet and also makes it possible to share the cosigners the account key without exposing your other normal payment keys to your cosigners - and makes it easier to extend both proposals, such as adding new roles for 1852 and piggyback on the same structure for 1854. For example the voting key could be added as a new role here (ex role=3) that could be added. Re: user-facing encoding we have defined new prefixes for the bech32 encoding so there isn't a shared prefix for all the keys coming from this particular proposal. I made the update to [CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md) directly, and it setups parallel for every key - [CIP-1852](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md) and [CIP-1854](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1854/README.md) have their own formats. I added a bit to CIP-1852 to explain the rationale - if intent simply to extend the existing roles with a completely different semantic then it's fine to add a new role. The part about discovering the template does not change.   
 **D** - Nice. I think that's good.   
 **S** - LGTM too - I approved it.   
 => Merge now   
@@ -110,7 +110,7 @@ PR -> ‘Draft’: Needs format + approval.
 
 #### Cardano URI Scheme  
 ([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: "Cardano URI Scheme")  
-**M** - This is using decimals as proportions which we probably do not want as explaind earlier, and I will comment in this PR itself. And it would be good to get alignment between the portfolio as json and the portfolio as URL. With which we would actually redefine this [CIP-0013](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/CIP-0013.md) and provide a more general structure and have something a bit more like what was done for the metadata label registry ([CIP-0010](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/CIP-0010.md)). (For the metadata it was essentially imposed by the blockchain format really) and say this is how it works and this is a registry for the various actions that can be recognized.  
+**M** - This is using decimals as proportions which we probably do not want as explaind earlier, and I will comment in this PR itself. And it would be good to get alignment between the portfolio as json and the portfolio as URL. With which we would actually redefine this [CIP-0013](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md) and provide a more general structure and have something a bit more like what was done for the metadata label registry ([CIP-0010](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/README.md)). (For the metadata it was essentially imposed by the blockchain format really) and say this is how it works and this is a registry for the various actions that can be recognized.  
 **S** - My main Q for the portfolio stuff is still if we can get it implemented in the actual Cardano nodes themselves: The single stake key, with the multi-pool delegation... We were previously told "possibly in the future"... With the Alonzo integration into the node wrapping up maybe more bandwidth would enable that?   
 **M** - The last info I have on that is basically that "no" we aren't going to bring this into the node (at least immediately) because of all the complications it brings. I am not aware of any long range target. It could be that we have this notion of portfolios for now, but it might be deprecated in the future if there is the capability.  
 **S** - It feels we're moving the complexity from one place to another. But the PR is fine as is, I have no issue approving it and merging it.  

BiweeklyMeetings/2021-06-08.md

@@ -56,7 +56,7 @@ PR -> ‘Draft’: Needs format + approval.
 **K** - All fee-related parameters, how they work, are set and the levels. Also min/max settings. Expect an encompassing blog post.   
 **D** - So it may or may not address this ([PR66](https://github.com/cardano-foundation/CIPs/pull/66))...   
 **F** - Any update on [PR21](https://github.com/cardano-foundation/CIPs/pull/21)?   
-**D** - I think the same point applies, which is that the researcher have just about completed and are about to provide internal feedback on the pledge benefit curve ([CIP-0007](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0007/CIP-0007.md)) proposal. It doesn't directly address this PR but it addresses in some sense what comes before that: incentives leading to ranking. So one might want to rethink/adjust "ranking" post incentive tweaking.... I think the situation is basically as it was before and Shawn should be in his right to push for the publishing of these proposals: The researchers at IOHK will get to those proposals in time. Not everything has to be what everyone agrees with and what gets implemented might be a gradient of those.  
+**D** - I think the same point applies, which is that the researcher have just about completed and are about to provide internal feedback on the pledge benefit curve ([CIP-0007](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0007/README.md)) proposal. It doesn't directly address this PR but it addresses in some sense what comes before that: incentives leading to ranking. So one might want to rethink/adjust "ranking" post incentive tweaking.... I think the situation is basically as it was before and Shawn should be in his right to push for the publishing of these proposals: The researchers at IOHK will get to those proposals in time. Not everything has to be what everyone agrees with and what gets implemented might be a gradient of those.  
 **K** - Expecting good news on that is the near future..   
 **D** - Shawn might want to revisit the proposal pending changes.  
 **K** - The blog is in the final stages, might be out already.   

BiweeklyMeetings/2021-06-29.md

@@ -57,7 +57,7 @@ PR -> ‘Draft’: Needs format + approval.
 
 ([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - "Non-Centralizing Rankings")  
 **M** - The main problem that people have with the current ranking system (which is also its main point in a way) is that it is not fair for pools "beyond" the **k** limit (the system is trying to establish homeostasis around k, fixed by the protocol -currently 500- and pools that are beyond k appear unprofiteable - this is by design as the system is trying to achieve "k" pools) Pools beyond k are punished quite severly in the rankings, such as appearing unprofiteable. What this proposal here is doing is smoothing a bit the transition beyond K so that there is no more hardcut, but it is smoother... If you are close to k, then you get less punished than if you are severly further out. It makes the transition a bit smoother.  
-**R** - Happy to move this forward. Meanwhile (I don't know if it's within the scope of this PR but) if "ranking" is always showing for every pool, then it will have a centralizing effect. Ex: for pools outside of k=500, will users get flags about the "beyond k" pools? (even from following an external delegation link ala [cip 13](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/CIP-0013.md)) there might be red flags and warning signs from the current discrimination, which would effectively centralize stakepools, and I want to go on record about this.  
+**R** - Happy to move this forward. Meanwhile (I don't know if it's within the scope of this PR but) if "ranking" is always showing for every pool, then it will have a centralizing effect. Ex: for pools outside of k=500, will users get flags about the "beyond k" pools? (even from following an external delegation link ala [cip 13](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md)) there might be red flags and warning signs from the current discrimination, which would effectively centralize stakepools, and I want to go on record about this.  
 **M** - Not sure the title aligns with the CIP though / this should be about "non-centralizing"... If you limit the number of stakepool then you are acting against decentralization. But we can adjust K if the goal is not acceptable, ex: from 500 to 2000 and such as needed - that was a bit the rationale about that. We have to find the sweet spot where you make most of the people happy and still achieve good decentralization?  
 **R** - You might say something like "less abruptly centralizating rankings"? hard to put that into few works.  
 **M** - It will not prevent having flags/warnings and still having a lot of incentives for having "less" than k pools because the entire system is designed around that... So if you really want to have "non-centralized rankings" then we probably need to rework the entire ranking system and not have that designed around k. And that's a totally different endeavor. I would agree with **R** and propose "less punitive rankings" as a better title. I would push for merging this as draft and then notify the author about the cosmetic changes.