From 593dbdcae46c34963cdb820507a72ad4df07227d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20=C3=80ngels=20Jover?= <99675813+mangelsjover@users.noreply.github.com> Date: Wed, 2 Mar 2022 22:52:11 +0100 Subject: [PATCH 1/7] Create 2022-02-01.md --- BiweeklyMeetings/2022-02-01.md | 273 +++++++++++++++++++++++++++++++++ 1 file changed, 273 insertions(+) create mode 100644 BiweeklyMeetings/2022-02-01.md diff --git a/BiweeklyMeetings/2022-02-01.md b/BiweeklyMeetings/2022-02-01.md new file mode 100644 index 0000000000..82eab3d2d1 --- /dev/null +++ b/BiweeklyMeetings/2022-02-01.md @@ -0,0 +1,273 @@ +**Table of Contents:** + +- [Summary](#summary) +- [Editors Meeting Flow](#editors-meeting-flow) +- [February 15 2022 notes](#february-15-2022-notes) + * [Triage](#triage) + + [PR211 - Add reference implementation for CIP15 ](#pr211) + + [PR104 - CIP-1856 | Collateral Key derivation](#pr104) + + [PR217- Collateral reward](#pr217) + * [Last Check](#last-check) + + [PR153 - Fair min fees ](#pr153) + + [PR159 - CIP-31: Reference inputs](#pr159) + + [PR160 - CIP-32: Inline datums](#pr160) + * [Review](#review) + + [PR148 - "CIP-0030: update to api.signData()""](#pr148) + + [PR216 - "Collateral output"](#pr216) + * [Discussions](#discussions) + + [PR200 - Add support for Catalyst multi-delegation](#pr200) + + [PR208- [CIP-0030] Adding getCollateral function to the connector API](#pr208) + + [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](#pr209) + + [PR215 - CIP-35: Plutus Core Evolution](#pr215) + * [Close](#close) +- [Extra](#extra) + * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status) + * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram) + * [Understanding CIPs further](#understanding-cips-further) + +## Summary + +Rough transcript of 01/03/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. +_Transcript might contain errors or miss pieces - call out issues as needed_ + +Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-40) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. + + +## Editors Meeting Flow + +**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions.. + +**Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period) + +**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews) + +PR -> ‘Draft’: Needs format + approval. +‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation. +‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing. +**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. + +**Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list. + + +## March 1 2022 transcript + +**Attending Editors**: Matthias Benkort, Frederic Johnson + guests (Kevin Hammond) + +**Maria** - Welcome, everybody, to the CIP editors meeting number 40. My name is Maria Jover and I am a project manager of the Cardano Foundation and I am here to facilitate this meeting. At the top left, you can find the agenda for the meeting today and please feel free to use the chat or the ask question in order to engage with the conversation. It's my pleasure today to introduce you our editors, Matthias Benkort and Frederic Johnson. So you want to make an announcement or a request, right, Matthias? +**Matthias** - Yeah. So we've been discussing in the past a bit getting the CIP into a more US friendly time zones so I've been discussing that a bit with the other editors and we would like to try to have meetings more often in these time zones. So what we're going to do is to move maybe to a weekly cadence, where half of the meeting will be still at the current time, so in the Europe based, at this daily hour, on the same day, and the other half of the time, it will be on the same day also, but later, or more around six, seven from European perspective, but then it'll be a more convenient time for the US people to join in and chip in. And also, it will double basically the frequency of meetings. So hopefully we'll get to move a bit faster on the triage and the discussions on some of the CIPs. +That doesn't mean that the process per se will be faster per CIP, because we still want to allow time to discussions and time for people to actually chip in. But at least we'll be able to cover, I hope, much more items faster. The CIP has gained traction over the past months. A lot of people are using it. And yeah, so we have to keep up basically with all the request proposals and changes that are going on. +**M. Àngels Jover** - Good. So shall we start with our items on triage? PR211: Add reference implementation for CIP15 +**Frederic Johnson** - Maria, one second. So first, when we check in, is also if there's any long-lasting items that needs to be followed up on, that needs to be added to the agenda. I don't believe there is, but just want to make sure that we look into this, Matthias, if you have anything you want to bring up outside of the announcement. No CIPs? +**Matthias Benkort** - No. Or maybe yes. There is a small Pull Request I did some days ago, which is just clarifying a bit the README on the CIP, because I saw a lot of people getting confused in the community about CIP31, CIP32, CIP33, and their adoption in Cardano. So I wanted to clarify a few things. That's for request number 227. It's mostly for editors to chip in here and Robert has already checked that. Not sure about Sebastian, but it's clarifying a bit the wording, clarifying the intent by explaining really what is CIP all about, and in particular, that it's not a process that is blocking implementations or that is mandatory for an implementation. +And it's actually going often at the same time that you do an implementation and you propose also kind of the rationale for that implementation as a CIP. And they are both helping each other because as you implement, you discover new things. And as you discuss with people, you might adjust also your implementation. And I also added on the CIP on the README, a table with all the CIPs currently under discussions, that are still in pull requests, just to ease a bit the navigation so that it's easier to find. And to keep in mind that this README is also part of the website, the cips.cardano.org website that's the front page is actually our project README. And a lot of people are actually going through that website as an entry point for the CIPs, and many were surprised not to find the CIP32 or CIP33, which were still in pull request and not merged in the repo. +So of course, since they are not merged, they are not in the audit table, which contains all the CIPS that we have discussed and reviewed. But I think it's still worthwhile to have them under README just to have to a link to them and to be able to easily jump on the conversations. So that's the change. +**M. Àngels Jover** - Perfect. So now we have PR211: Add reference implementation for CIP15. This one, we had a conversation last meeting, and according to my last notes this was going to be merged asynchronously, but it hasn't been done, I guess. +**Matthias Benkort** - Yeah. We were waiting for review from Robert. It came two weeks ago, but we then kind of forgot to merge it. So this is just a small update on CIP15, adding a reference implementation, which I've also reviewed. So this one is fine to go. Now it has two check marks from a editors so I would just proceed and merge that one. Good. +**M. Àngels Jover** - PR105 Collaterall Key Derivation +**Matthias Benkort** - I would like to maybe postpone a bit this one, because it's a proposal from Sebastian, who is not there today. So there has been a lot of discussions on top of it. And I haven't been following quite closely that one. So I would very much like Sebastian to walk us through a bit the discussions and the outcome. So the general idea here is really to have a ... it is proposing a dedicated key for making the management of collectables easier and hopefully remove that version from the end users, which currently has sort of to define a collectable in their wallets to make sure that they can execute scripts. And it's a bit cumbersome at this stage. So yeah, I see the proposal has been discussed by the people from the Ledger teams. So it's interesting. But yeah, let's see when Sebastian is back to walk us through that change. +**M. Àngels Jover** - Good. So it will happen the same with PR217 and PR216, right? +**Matthias Benkort** - Yeah, one of them is actually duplicated. I think that's PR217. Sebastian said last week he wanted to remove that one, I think. +**M. Àngels Jover** - The previous one was pretty old, I think. +**Matthias Benkort** - Yeah, I think what he said last week was that this one wasn't really useful. He just did it for the sake of reporting what had been discussed with the Ledger team in the past. I think he wanted to duplicate it. So we'll also wait on that, maybe ping him back on the pull requests. I've dropped in the comments. So moving to fair min fees, maybe. The PR153. So this one is actually just exchange of statuses, right? If I recall correctly or not. +**M. Àngels Jover** - Yes. What was talked last meeting is that you want to do some with github cleanup on it. +**Matthias Benkort** - I don't think so. +**Frederic Johnson** Yeah. The merged ... The comment history just has some weird back and forth and you wanted to- +**Matthias Benkort** - Ah, yeah, yeah, you're right. You're right. Indeed. It has more comments than it deserves with only one word change. So indeed, hasn't happened. So my bad. So okay. Still ready to go. Will merge it then. But I will make a note for myself to do it at the end of this call. So yeah, to adjust the git history, just to make sure we have only the last comments in there because the other ones are from a wrong rebate or something, it seems. Yeah, I guess it's been there for a while and that's probably what happened. +At the same time, also, I was going back through the CIP1 process and in particular, what it means to be proposed for a CIP, and currently, in the condition for semantic, for propose, we are saying that there is a clear path to active, which brings the question of the core CIPs, like this one, that are actually changing Ledger roles, or really addressing changes in the Ledger. What's a proper path to active. What does it mean? Because there is ... how do you get something to be active? There is no process formally defined criteria with the Ledger team for that, as the Plutus team is trying to push forward. They sort of outline the process for contributing to the Plutus code base, what it would take for a CIP to go from just a draft to an actual implemented and active CIP. But I guess we need to work something out with the Ledger team also for those kind of CIPs. +**Matthias Benkort** - It's a bit more ... well, tricky for a Ledger, obviously, because it touches the core part of Cardano, so you don't want to do anything wrong with that. But okay, I will also keep a note for that, but I will definitely need to bring the conversation with the Ledger team and IOG on that, to make sure we have an actual way for bringing the CIP up front. I reached out to the research last two weeks ago on various sort of topics. I haven't got a clear answer so far, so I will keep on chasing people. But yeah. +**M. Àngels Jover** - So we can put this on hold until you have an answer from the Ledger team, right? +**Matthias Benkort** - No, no. For this one, it's fine. We've already discussed this one a few times. It's also been reviewed by the Ledger team back in the days, but there is still this question of, even if you're moving to propose, that doesn't mean it will ... There isn't currently a item on the roadmap of the Ledger team to address that particular proposal. I'm not sure that's shown as also the willingness or capability to implement the change in the Ledger code base itself. So it has proposed already an implementation, but more like a separated one. So yeah. I will bring that back again to the attention of the Ledger team to see what's up and if they have indeed no plan to implement that and it's a few unknown because these and these reasons. I don't know. Then we'll report back and maybe make the CIP obsolete. But for now, we can move it to proposed, and I will just modify the git history to have a clean history of commits with the Ledgers after the meeting, since it's a fairly small thing to do. +**M. Àngels Jover** - Perfect, perfect. We have PR159: Reference Inputs. And for this one, we comment in last meeting that it was good to go, but we asked Michael to add a justification for phase one. And I don't think that that has been added. +**Matthias Benkort** - So yeah, it was a small thing, right? That he added recently an extra check, again that was on the forbidding usage of referenceinputs with old scripts with the V1 versions. And I guess there's someone in the chats was discussing why was this done in the phase one but additions of phase two? But I guess we answered that in the last meeting already. Michael didn't report it back on the CIP. Yeah, just drop a line in there. I see it has also the insert, so we can maybe just clarify with him. I will just drop a comment on the pull request. And once we have that, this one would be ready to go and get merged as we discussed last time. +**M. Àngels Jover** - Perfect. +**Matthias Benkort** - So we'll just merge it with just the conditions as we add this little rationale, just one small line change. And I will state we can get that done today as well. +**M. Àngels Jover** - Perfect. We have PR160: Inline Datums +**Matthias Benkort** - Yeah, this one is pretty much. Also it was in the last check, it was under last check... No, it was just ready for review. +**M. Àngels Jover** - Yeah. I think that we have a comment here. It's not in this one. This was for the last check. +**Matthias Benkort** - Yeah. And that was a bit with some spirits. Yeah, this one is also fine. It should go as a draft towards the implementation. It happening also concomitantly. +**M. Àngels Jover** - We have all the approvals here, I am going to check. We miss one approval, right? In order to merge it? +**Matthias Benkort** - Yeah. So, Sebastian, Robert or Fred maybe later when they are up. I will just CC them. Okay. + +**M. Àngels Jover** - Cool. So we will go into the review items. We're going to start PR 148, because the other one, we will wait for Sebastian +**Matthias Benkort** - Yeah. So, 148. Yeah, I asked last meeting to have an update from Rob. He said: + “I think it's read for review now. I just updated the spec to use an Address string type which can be either the old hex bytes or bech32. I think that's is it for comments on this besides out-of-scope large changes like not using cbor anywhere mentioned above. +I changed the Address format in other endpoints for consistency, but we can do that in another PR if we feel it is necessary. There's also the issue of the API version. Should we be incrementing this by a major version here or do we only want to start doing that once CIP-30 moves out of draft status?” +That's a good point.- +There's one comment from Martynas: + “How about adding a "content type" argument? Wallets could try to display the message being signed to the user” +Not sure to get it. +** Frederic Johnson** - So we will get changes that occurred since Rob actually pushed that comment, or show right before he post that comment? So, my issue goes to- +**Matthias Benkort** - Yeah, that is what he said. We were discussing in the past, to change the API, to accept not the address as a hexacoded string, but actually as bech32 strings, which is the way it actually displays in most interfases. That's the way wallets manipulate them, and it's a bit more coherent with the entire presenter API. So, what we discussed was to do that for the same data, of course, but then reflect that on the entire API or to keep consistency. But since that would be in principle a breaking change, the idea was to support both formats. It has wallets that actually accepts either hex or Bech32 encoded strings, and let them figure out basically which one it is, which is pretty straightforward to do for a wallet implementer. +So, as it is for now, at least from my perspective, the proposal is fine. This was not a proposal per se but just an addendum on an existing one, for the CIP 30. So we can probably move this to the last check for the next meeting, and see if people still want to comment on it or not. So, there is actually one comment, which is asking about something I don't quite get. So we can try to divert that with that person in the next two weeks and see where it goes. +**M. Àngels Jover** - Okay. So, this was what we have from the agenda. Let me check if there's any questions in the chat. +**Matthias Benkort** - Kevin wanted to bring up the votes delegation CIP, which I think was proposed by Mark some time ago. That was initially proposed as an extension to Catalyst to the CIP 15 proposal I think. But then we decided that it was better to move it as a separate proposal, in form of like an extension of CIP 15, instead of modifying CIP 15, which is already complex enough, and it has undergone a lot of changes. +**Matthias Benkort** - So, the idea was to say, "Okay, we want to have this extension to a line which you have multiple... or just do multiple keys for the Catalyst proposal, such that on the side chain can be multi-delegated to different pools, and therefore enables more like a split routine in the real. +**Matthias Benkort** - We have Kevin around, so maybe we can bring Kevin on the voice chat, and he can give us a walkthrough. I think Kevin you've been discussing that with Mark a bit. +** Frederic Johnson** - If I recall correctly, I think Mark was adamant on pushing his own pull request or own CIP. And I think Kevin did his own CIP, and I think there were two competing CIPs doing the same thing. +**Matthias Benkort** - Okay. But I didn't see the CIP from Kevin actually. There was an original request which was changing CIP 15, which is still actually open as a pull request. +** Frederic Johnson** - But the decision on that specific PR was that we'd scrub that PR, effectively closing it, and instead request a standalone CIP just for simplicity, as opposed to trying to modify the old one. +**Matthias Benkort** - Yeah. Because it was modifying quite substantially the old one, effectively making it a completely different proposal. So we asked Mark... Actually, we asked to create a number of PR, and Mark volunteered to do so, but haven't still closed the old one. I'm not sure actually who opened the old one in the first place. Do we have Kevin online? Oh no, Kevin is not here anymore. So let's actually go through the comments ourselves then. Oh, Kevin is there. +**Kevin Hammond** - I lost the window. Happy for this to be a separate CIP if that’s what you want to progress. What we do need is a dedicated CIP number that we can just refer to this internally during the developing process. We're trying to use CIP 36. I understand that number that Mark assigned to it, there is path for confusion developing. On terms of content the we've been commenting the new PR that Mark had put in. +**Matthias Benkort** - Yeah, okay. So that's [crosstalk 00:23:13]. +**Kevin Hammond** - What else now needs to be done? +**Matthias Benkort** - Well, discussing, obviously, right? Making sure people agree. I think that's fairly the case on that one. The number assignation, that's part of why I did this little change in the read-me I was mentioning earlier. One of the reason why I wanted to move also the current PR under discussions to the read-me, was to pre-allocate them a number already, to avoid these clashes. And this one is in this number 36, so there is a good chance that it will stay exactly like that, unless it gets not merging in the end and ends obsolete. But I don't think this will happen, so we'll probably proceed with that. Move it to the last check as well for the next meeting; it's been reviewed already quite a bit. And yeah, I take it from there basically. So those two discussions... No, I think let's check with maybe too soon, we haven't properly given time to discuss it in any little meeting. We can move it to the next meeting for review. +**Kevin Hammond** - Okay. +**M. Àngels Jover** - Is this one PR 188 we're talking about right now? +**Matthias Benkort** - No. This one is the old one. That's the one modifying CIP 15 that we asked to split as a separate pull request. +**M. Àngels Jover** - So which one is the one that we're going to add to review in the next meeting? +**Matthias Benkort** - PR number 200, right? Yeah, the 200 one by Mark, which we'll have a full complete review of that one. +**Kevin Hammond** - That's slightly go over authorship it should be attributed Giacomo to who wrote the original proposal rather than Mark. I don't know if there's a way to [crosstalk 00:25:22]. +**Matthias Benkort** - Yeah, it's not attributed to Mark, right? It currently has one, two, three, four, five authors. You're actually one of them, by the way, apparently. Giacomo is also one of them. I guess Mark just wrote the PR, and he didn't even credit himself as an author. He just credited the original. It's just that he did open the pull request. +**Kevin Hammond** - I'm actually trying to get some attribution. So, if Mark created the PR, he'll be attributed with creating this. +**Matthias Benkort** - No, no, no. If you look at the author of the CIP, they are actually listed here, right? ? So it's Sebastian Reno, Mikhail, Giacomo and you Kevin. Github is always referring to the person who has created the PR as being [crosstalk 00:26:17]. +**Matthias Benkort** - I see what you mean. So maybe what we can do is tweak a bit the GitHub history so that this full request is made as a change on top of Giacomo one. +So that in the history we can see that one. This first thing it was reverted, and then this new commit was created. I can do something like that to have the above authors actually be contributors to the repository. +**Kevin Hammond** - Exactly. That will keep the history straight and fair. +**Matthias Benkort** -Yeah. Fair enough. +**Kevin Hammond** - Like proper credit. +**Matthias Benkort** - Yeah. +**M. Àngels Jover** - So Matthias, you will be able to do that yourself or... +**Matthias Benkort** - Yeah. I will just push on the branch only if Mark actually have authorized people to push on his branch. If not, I will see with him if we can just do that updates. Right? So the ideas is really not to change anything to the current result, but change the history. Right? So that it better reflects what happened, that there was a first change by Giacomo, and then it was on top of that extracted by marking a separate PR. Right? +**Kevin Hammond** -Okay. +**Matthias Benkort** - So in the history we keep the right history of how things happened. +**Kevin Hammond** -Exactly. Yeah. I think it's important to make sure the history is recorded properly, right Matthias? +**Matthias Benkort** -Yeah. I mean, in the end, that's why we have this metadata on top of CIPs. It's also, you have the list of authors here, and if you want to refer to one of those people, should be someone from the list. It doesn't quite matter who made the change on unbeatable when you think. But I mean, for some people, it does matter so I can get that. +**Kevin Hammond** - It matters. It matters to some people. +**Matthias Benkort** -Mm-hmm (affirmative). +**Kevin Hammond** - Great. And in terms of status, we're working on this, we are taking into account any comments that have been made. If people like to make further comments, happy to respond. And not seen any major issues coming up through the commenting process. +**Matthias Benkort** - Yeah. +**Kevin Hammond** - If anyone would like to add anything to that, very happy to do so. +**Matthias Benkort** - Okay, good. +**Kevin Hammond** -That you. +**Matthias Benkort** - Let's see, maybe if we have other call request we could bring up to discussions here. If there's anyone in the chat that has a suggestion, otherwise we'll just pick one from the existing ones. I see there is another update on, or two other updates actually, on CIP 30, which we could maybe quickly go through. One is for request 208 and one 209. +So one of them is Adding getCollateral function to the connector API: getCollateral given an amount, it gives back a UXTO to spend as collateral. +The value to use for collateral? Because... yeah, okay. There is an amounts to be passed, but in principle, this amounts depends on the transaction script execution units. +Okay. I guess that's an interesting one. We should also bring maybe for review for the next meeting. There is quite a fair, rational extension here. Then on top of that, there is also the CIP... Sorry, the pull request 209, which is Adding optional networkId parameter to .enable: a DApp for test net or main net future networks. +Okay, interesting too. +And it probably echoes... Yeah, CIP 34 from Sebastian, which was about providing a chain identifier. So maybe there is something to do here. Have the network ID be provided as non-chain identifier. Yeah. Providing it as zero or one. Feels a bit untied, or not really user friendly from a developer perspective. So Sebastian had already a good proposal for identifying networks using a proper string of characters, I think codes the network ID and genesis. So we could go for that. So I would be happy also if we maybe this for review, for request 209. +CIP 30 seems to be creating some discussion with IO... Of course. some additional functionality being needed. Yeah. So I guess the whole point of CIP 30... I mean the whole issue with the CIP in a way, is that it was created pre Alonzo, so there was a lot of things in there that didn't account for scripts and Plutus. Although it is now mainly used by wallets that provides that functionalities. And therefore, yeah, it needs a couple of extensions in that regard. +So I guess the collateral is one of them that's get us in the right direction. The network ID is definitely also a cool one to be able to support multiples networks and have also... Well, I test wallets. Test CIP 30 capable wallets for testnets. +If there is any other one, Kevin, if you can get the people in IO to make a proposal with those changes, that will be good. And the sooner better, right? Because we can start the discussion earlier then. +Another CIP maybe, that I would like to bring to review our discussions next week, is the Plutus Core built-in of... Sorry, the Plutus Core changes CIP. Plutus Core evolution. So PR number 215, which gives a framework for actually proposing changes to Plutus and getting them through the entire process also including implementation with the team and all that. I think that's a very nice initiative for Michael to really lay that down and have a clear process for proposing Plutus changes. +There have already been a couple of proposals on top of that one, following that exact process. So it would be nice if we could get this one approved, or at least discussed. I've already been reviewed by me, already reviewed it, because I already made a proposal on top of that one. And I definitely see the value of this one. So I would very much like to have it as an active CIP as soon as possible to be able to then move on and have proposals on Plutus. +Exactly. That follows this standard. So they can bring it for reviews also next week and then last check. Hopefully we can get it into the repro quite fast. Since there is no implementation for that one even, we can probably move it almost directly to active. Because the sole fact that there are already two or three proposals on top of it, well, qualifies it as an active CIP. +**M. Àngels Jover** - Okay. Anything else that you want to discuss Matthias? +**Matthias Benkort** - I'm not sure. Keep getting the same stuff in the chat. Yes, I'll try to get people to comment on that. It seems to be some divergence on this. Of course, that's why we want to have a CIP. Because then discussions can happen on the CIPs publicly, and people can share different implementations and different wallets. Yeah. +**Kevin Hammond** - That's right. So we need to get some standardization, I think, on this Matthias. And as I've said in the chat, I think there's some additional functionality which isn't original CIP proposal, which we'll need for the vote delegation. So we need witnessing capabilities as well as signing capabilities. +**Matthias Benkort** - What do you mean witnessing capabilities? +**Kevin Hammond** - I mean, we'll need to... Because the way the CIP 36 is to find, there are two distinct keys involved. One of them to provide a witness from a voting key... Sorry, from the stake key, and the other to sign and submit a transaction using a payment key. So we need sort out the different elements of witnessing using stake key, versus signing and submitting using payment key. +**Matthias Benkort** - Yeah. I'm mean, okay. But in both cases that remains, it's still a signature. But it's just a signature from not a human key, but a staking key, right? +**Kevin** - Yes +**Matthias Benkort** - Because I thought you were referring to witness as in being able to add full scripts or datums or redeemers, or whatever's going for [inaudible 00:36:42] that. But that can already be done by a DApp in principle. They don't need the wallet for that. +So how is actually currently... Well, I need to refresh my mind now. On CIP 30, how does the signing works currently? What does it provide? Sign TX, does the wallet determines automatically what the key test to use? Yes. +Ah, yeah. Okay. Yeah. The sign, we give it the TX and the wallet figure out the transaction, witness it. Wallet should be able to figure out it's the staking key, right? But surely the staking key comes from the wallet? +**Kevin** - As long as it knows it needs to sign with staking key, Matthias. +**Matthias Benkort** - Yeah. So, okay. I mean, maybe we could use an API that is a bit more explicit, like the Ledger or Tresor devices works, right? For signing to device you give them the transaction body, but also the derivation path of the signing key you expect. And then they produce the signatures cross going to do his path. +**Kevin Hammond** - Yes. +**Matthias Benkort** - So I guess the API here could be extended in that direction to say... Well, you take also a list of derivation path and you make sure that you can produce a signature for them. If you don't provide that list, then it's up to the wallet to figure out those keys needed for a single transaction. +**Kevin Hammond** - Yeah. And then the question is, how does the Dapp knows the derivation path that it needs to have enough information [crosstalk 00:38:12] of it. +**Matthias Benkort** - Not necessarily. But yeah, okay. Because it's internal details of the wallet in here. +**Kevin Hammond** - Exactly. Yes, don't want to [crosstalk 00:38:24]. +**Matthias Benkort** - But ideally, wallet can probably figure out the signature already. +**Kevin Hammond** - Sorry? +**Matthias Benkort** - I mean, if you need to sign by a staking key, then surely there is something in the transactions that identified as staking key, right? It has to be in the required signature of the transaction. +**Kevin Hammond** - Yeah. That's right. I can identify what I have is information about the public. I have the public stake key hash. I won't have the stake key itself, I think. +**Matthias Benkort** -Yeah, yeah, of course, of course. +**Kevin Hammond** - So I'll need [crosstalk 00:38:57]. +**Matthias Benkort** - But, so a wallet that's receiving this transaction for signing through this CIP 30 API, right? +**Kevin Hammond** - Yes, correct. +**Matthias Benkort** - It's received the whole transactions and there is some point in a transaction, something that says you need a signature from that key hash. And that key hash is known of the wallet because it's a state key. +**Kevin Hammond** - Yeah. Correct. So as long as I identify the fact that I need a signature from that key hash, as long as the wallet can then determine the derivation path from that, then that would work fine, I think. +**Matthias Benkort** - I think the current API is fine. What we maybe need to enhance that CIP is a list of test vectors with a specific test case, where you can actually provide a transaction that has a staking key as a required key hash signature, and the resulting signature contains witnesses for that stake key. +**Kevin Hammond** - Right. +**Matthias Benkort** - And as we make sure that wallets that implement that CIP would have also to satisfy the test vectors and that's it. +K**Kevin Hammond** - So I propose is why don't you and I take this offline materials with the IO, we can discuss this with other people and why io wallet team, and then make sure that we have something concrete to this committee. +**Matthias Benkort** - Yeah. And then make a proposal out of it. That will be fair. +**Kevin Hammond** - Yeah. That seems to be the correct presence. +**Matthias Benkort** - Okay. +**Kevin Hammond** - Thank you. +**Matthias Benkort** -Fair enough. +**Frederic Johnson** - +Do you not consider maybe the rest of the time for discussion regarding moving to a US time zone for the meeting or to try something like that? +**Matthias Benkort** - Yeah. Maybe, to be a bit more on the process. There is also one thing I would like us to give a thoughts, maybe not in this current meeting, but that is for you, Fred also, and other editors I will reach out, but we have 12 issues open on the repo. So it seems that people are using issues to discuss things. And it's something we are actually, we haven't included the part of the process currently. Right. So we had issues and no one is really taking care of them at the moment. I actually just noticed last week that had so many issues because I was so far focused on the pull request when it comes to the CIPs, but there is a fair amount of discussions happening in issues, which is interesting. Right. We never really stated that as part of the process, but it just happened organically, I guess. And maybe we should start also, including issues, issue triage as part of the editors meeting or spend some time offline to go through them. +**Frederic Johnson** Yeah. I agree. I've seen those grow and I think that it's good that we're actually paying attention right now as they've pretty much propped up functionally like the past few month. And it's a matter of just keeping on top of it, the same with the labeling of the issues right now. So I think this is all project management really, Maria is going to be able to cover a lot of that ground. I think that's like a new added step. I don't want to overextend a little bit into committing to too many things, like too many meetings and covering issues and adding too many PRs, just because a lot of that is functionally being offloaded mostly to Maria. And I'm just thinking that if we're doubling the meetings, it might be something, have you also coupled with other people that are involved in transcribing the meeting notes and everything like that. +**Matthias Benkort** - Yeah. Sorry. I was not actually implying that. We shouldn’t double the workload for Maria as well on these US based time zones that I'm actually thinking that the US crew could be possibly different from the European crew. I don't mind bridging the two crew for now, but for sure for the US base, we would Robert onboard and maybe we can also have someone that help with notes and whatnot. Or I can take that. I can take that part maybe on me and let Robert conduct the meetings for the US based one. And there was also the question of recruiting more editors, getting more people on board. So maybe we could start discussing an actual approach to that. How do we get people who join us and help us with that task? Maybe that would be interesting. +**Frederic Johnson** - I agree. I think we have a meeting like that coming up with Maria on the side of the retrospective, every 10 meetings we have that, I think that's totally a good place to have that. If you want to try something regarding US time zones, what our propose is that we do something at 10:00 a.m. PST, which equates to, I think like 7:00 PM your time. So Maria and yourself, I think both of you are in the same time zone. If you're able to do a 7:00 PM meeting, that might be an option. But I don't know if we want to do that for the next one or for like 42 or something like that. +**Matthias Benkort** - I would like to try for the next one. Definitely. So next week have that up. That will work for me if it works for you also Maria, or I can try to take some notes on that. +**Frederic Johnson** - Can we try the next biweekly one? So in two weeks, rather than one week. +**Matthias Benkort** - Oh, so you mean to move the next biweekly as a US based? +**Frederic Johnson** - Yes. Just the next CIP meeting because those meetings are biweekly. So every two weeks, so the 40th right now is up on Tuesday. The next 41 will be in two weeks and it will be happening functionally at a US time zone slot. +**Matthias Benkort** - Yeah. Okay. Okay. I guess it's also maybe fine for even European time to be at 7:00, because I imagine if people are also not joining because they just have work to do at 10:00 AM and maybe it's more convenient to join at 7:00. +**M. Àngels Jover** - Maybe that's right. +**Matthias Benkort** - So maybe it's also all better for even European time zones. +**Frederic Johnson** - Yeah. The only +**M. Àngels Jover** - Maybe we can test it and see how it goes. +**Matthias Benkort** - Yeah. Yeah. Test for a couple of weeks. So last time I asked on Twitter actually, a bunch of people, it was pretty much 60%, 40% that there was a lot of people I wanted to have meetings in the US time zone. So I was out of like 400 people. That's still a fair amount of four segments to join. I imagine I'm not sure how about the actually distribution. It's all the people that answer "yes, we're actually in the US', or even if there were some European that were interested to have meetings at the US base time zones. But yeah, maybe let's try it, let's have the next one in, at 6:00 UTC. Right. And I don't know the time zone, like the UTC to be franc, but it much easier for me to think just in UTC time. And that that would be... +**M. Àngels Jover** - The 15. Right? +**Matthias Benkort** - Yes. +**Matthias Benkort** - 6:00 pm UTC. +**M. Àngels Jover** - Do you want to do a wrap up of what we have for next meeting? +So we have PR 153 that you are going to do Matthias some github clean up and it will be ready to go and can be merged before next meeting. PR 160 also is ready to go and can be merged. Then for next meeting, we will have PR 148 for last check. And then we have a pretty busy review section. We will have PR 215, 208, 209 and 200. And we are waiting for Rob answering 211 in order to identify phase one. If this is done, you are going to merge it asynchronously, right? +**Matthias Benkort** - Yep. +**M. Àngels Jover** - And we have on hold, all the collateral PRs that we want Sebastian to be commenting on them. +**Matthias Benkort** - Yeah. Work us through the changes. Correct. Okay. Thank you. +**M. Àngels Jover** - Perfect. Thank you very much. +**Frederic Johnson** - All right. Thank you everyone. + + +--- +## Extra + +### Current CIPs in the CIP repository and their status + +| # | Title | Status | +| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | +| 1 | [CIP process](../CIP-0001/) | Active | +| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | +| 3 | [Wallet key generation](../CIP-0003/) | Active | +| 4 | [Wallet Checksums](../CIP-0004/) | Draft | +| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | +| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | +| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | +| 8 | [Message Signing](../CIP-0008/) | Draft | +| 9 | [Protocol Parameters](../CIP-0009/) | Draft | +| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | +| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | +| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | +| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | +| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | +| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | +| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | +| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | +| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | +| 19 | [Cardano Addresses](../CIP-0019/) | Active | +| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | +| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | +| 22 | [Pool operator verification](../CIP-0022/) | Active | +| 23 | [Fair Min Fees](../CIP-0023/) | Draft | +| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | +| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | +| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | +| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | +| 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft | +| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | +| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | +| 33 | [Reference Scripts](../CIP-0033/) | Draft | +| 34 | [Chain ID Registry](../CIP-0034/) | Draft | +| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | +| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | +| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | +| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft | + +:bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001). + + +### CIP creation process as a Sequence Diagram + +_"Alice has a Cardano idea she'd like to build more formally":_ +![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") + +### Understanding CIPs further + +[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) +[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) From 037b08099a2a67891ccd956cb4f3ce967dbb4687 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20=C3=80ngels=20Jover?= <99675813+mangelsjover@users.noreply.github.com> Date: Wed, 2 Mar 2022 22:53:11 +0100 Subject: [PATCH 2/7] Update 2022-02-01.md --- BiweeklyMeetings/2022-02-01.md | 1 + 1 file changed, 1 insertion(+) diff --git a/BiweeklyMeetings/2022-02-01.md b/BiweeklyMeetings/2022-02-01.md index 82eab3d2d1..2935982cb0 100644 --- a/BiweeklyMeetings/2022-02-01.md +++ b/BiweeklyMeetings/2022-02-01.md @@ -54,6 +54,7 @@ PR -> ‘Draft’: Needs format + approval. **Attending Editors**: Matthias Benkort, Frederic Johnson + guests (Kevin Hammond) **Maria** - Welcome, everybody, to the CIP editors meeting number 40. My name is Maria Jover and I am a project manager of the Cardano Foundation and I am here to facilitate this meeting. At the top left, you can find the agenda for the meeting today and please feel free to use the chat or the ask question in order to engage with the conversation. It's my pleasure today to introduce you our editors, Matthias Benkort and Frederic Johnson. So you want to make an announcement or a request, right, Matthias? + **Matthias** - Yeah. So we've been discussing in the past a bit getting the CIP into a more US friendly time zones so I've been discussing that a bit with the other editors and we would like to try to have meetings more often in these time zones. So what we're going to do is to move maybe to a weekly cadence, where half of the meeting will be still at the current time, so in the Europe based, at this daily hour, on the same day, and the other half of the time, it will be on the same day also, but later, or more around six, seven from European perspective, but then it'll be a more convenient time for the US people to join in and chip in. And also, it will double basically the frequency of meetings. So hopefully we'll get to move a bit faster on the triage and the discussions on some of the CIPs. That doesn't mean that the process per se will be faster per CIP, because we still want to allow time to discussions and time for people to actually chip in. But at least we'll be able to cover, I hope, much more items faster. The CIP has gained traction over the past months. A lot of people are using it. And yeah, so we have to keep up basically with all the request proposals and changes that are going on. **M. Àngels Jover** - Good. So shall we start with our items on triage? PR211: Add reference implementation for CIP15 From 70de9052d1d20f24bf0ae50b90619b010a19b59a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20=C3=80ngels=20Jover?= <99675813+mangelsjover@users.noreply.github.com> Date: Wed, 2 Mar 2022 22:58:21 +0100 Subject: [PATCH 3/7] Update 2022-02-01.md --- BiweeklyMeetings/2022-02-01.md | 151 ++++++++++++++++++++++++++++++--- 1 file changed, 139 insertions(+), 12 deletions(-) diff --git a/BiweeklyMeetings/2022-02-01.md b/BiweeklyMeetings/2022-02-01.md index 2935982cb0..8bde825324 100644 --- a/BiweeklyMeetings/2022-02-01.md +++ b/BiweeklyMeetings/2022-02-01.md @@ -49,7 +49,7 @@ PR -> ‘Draft’: Needs format + approval. **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list. -## March 1 2022 transcript +## March 1 2022 Transcript **Attending Editors**: Matthias Benkort, Frederic Johnson + guests (Kevin Hammond) @@ -57,89 +57,159 @@ PR -> ‘Draft’: Needs format + approval. **Matthias** - Yeah. So we've been discussing in the past a bit getting the CIP into a more US friendly time zones so I've been discussing that a bit with the other editors and we would like to try to have meetings more often in these time zones. So what we're going to do is to move maybe to a weekly cadence, where half of the meeting will be still at the current time, so in the Europe based, at this daily hour, on the same day, and the other half of the time, it will be on the same day also, but later, or more around six, seven from European perspective, but then it'll be a more convenient time for the US people to join in and chip in. And also, it will double basically the frequency of meetings. So hopefully we'll get to move a bit faster on the triage and the discussions on some of the CIPs. That doesn't mean that the process per se will be faster per CIP, because we still want to allow time to discussions and time for people to actually chip in. But at least we'll be able to cover, I hope, much more items faster. The CIP has gained traction over the past months. A lot of people are using it. And yeah, so we have to keep up basically with all the request proposals and changes that are going on. + **M. Àngels Jover** - Good. So shall we start with our items on triage? PR211: Add reference implementation for CIP15 + **Frederic Johnson** - Maria, one second. So first, when we check in, is also if there's any long-lasting items that needs to be followed up on, that needs to be added to the agenda. I don't believe there is, but just want to make sure that we look into this, Matthias, if you have anything you want to bring up outside of the announcement. No CIPs? + **Matthias Benkort** - No. Or maybe yes. There is a small Pull Request I did some days ago, which is just clarifying a bit the README on the CIP, because I saw a lot of people getting confused in the community about CIP31, CIP32, CIP33, and their adoption in Cardano. So I wanted to clarify a few things. That's for request number 227. It's mostly for editors to chip in here and Robert has already checked that. Not sure about Sebastian, but it's clarifying a bit the wording, clarifying the intent by explaining really what is CIP all about, and in particular, that it's not a process that is blocking implementations or that is mandatory for an implementation. + And it's actually going often at the same time that you do an implementation and you propose also kind of the rationale for that implementation as a CIP. And they are both helping each other because as you implement, you discover new things. And as you discuss with people, you might adjust also your implementation. And I also added on the CIP on the README, a table with all the CIPs currently under discussions, that are still in pull requests, just to ease a bit the navigation so that it's easier to find. And to keep in mind that this README is also part of the website, the cips.cardano.org website that's the front page is actually our project README. And a lot of people are actually going through that website as an entry point for the CIPs, and many were surprised not to find the CIP32 or CIP33, which were still in pull request and not merged in the repo. + So of course, since they are not merged, they are not in the audit table, which contains all the CIPS that we have discussed and reviewed. But I think it's still worthwhile to have them under README just to have to a link to them and to be able to easily jump on the conversations. So that's the change. + **M. Àngels Jover** - Perfect. So now we have PR211: Add reference implementation for CIP15. This one, we had a conversation last meeting, and according to my last notes this was going to be merged asynchronously, but it hasn't been done, I guess. + **Matthias Benkort** - Yeah. We were waiting for review from Robert. It came two weeks ago, but we then kind of forgot to merge it. So this is just a small update on CIP15, adding a reference implementation, which I've also reviewed. So this one is fine to go. Now it has two check marks from a editors so I would just proceed and merge that one. Good. + **M. Àngels Jover** - PR105 Collaterall Key Derivation + **Matthias Benkort** - I would like to maybe postpone a bit this one, because it's a proposal from Sebastian, who is not there today. So there has been a lot of discussions on top of it. And I haven't been following quite closely that one. So I would very much like Sebastian to walk us through a bit the discussions and the outcome. So the general idea here is really to have a ... it is proposing a dedicated key for making the management of collectables easier and hopefully remove that version from the end users, which currently has sort of to define a collectable in their wallets to make sure that they can execute scripts. And it's a bit cumbersome at this stage. So yeah, I see the proposal has been discussed by the people from the Ledger teams. So it's interesting. But yeah, let's see when Sebastian is back to walk us through that change. + **M. Àngels Jover** - Good. So it will happen the same with PR217 and PR216, right? + **Matthias Benkort** - Yeah, one of them is actually duplicated. I think that's PR217. Sebastian said last week he wanted to remove that one, I think. + **M. Àngels Jover** - The previous one was pretty old, I think. + **Matthias Benkort** - Yeah, I think what he said last week was that this one wasn't really useful. He just did it for the sake of reporting what had been discussed with the Ledger team in the past. I think he wanted to duplicate it. So we'll also wait on that, maybe ping him back on the pull requests. I've dropped in the comments. So moving to fair min fees, maybe. The PR153. So this one is actually just exchange of statuses, right? If I recall correctly or not. + **M. Àngels Jover** - Yes. What was talked last meeting is that you want to do some with github cleanup on it. + **Matthias Benkort** - I don't think so. + **Frederic Johnson** Yeah. The merged ... The comment history just has some weird back and forth and you wanted to- + **Matthias Benkort** - Ah, yeah, yeah, you're right. You're right. Indeed. It has more comments than it deserves with only one word change. So indeed, hasn't happened. So my bad. So okay. Still ready to go. Will merge it then. But I will make a note for myself to do it at the end of this call. So yeah, to adjust the git history, just to make sure we have only the last comments in there because the other ones are from a wrong rebate or something, it seems. Yeah, I guess it's been there for a while and that's probably what happened. + At the same time, also, I was going back through the CIP1 process and in particular, what it means to be proposed for a CIP, and currently, in the condition for semantic, for propose, we are saying that there is a clear path to active, which brings the question of the core CIPs, like this one, that are actually changing Ledger roles, or really addressing changes in the Ledger. What's a proper path to active. What does it mean? Because there is ... how do you get something to be active? There is no process formally defined criteria with the Ledger team for that, as the Plutus team is trying to push forward. They sort of outline the process for contributing to the Plutus code base, what it would take for a CIP to go from just a draft to an actual implemented and active CIP. But I guess we need to work something out with the Ledger team also for those kind of CIPs. + **Matthias Benkort** - It's a bit more ... well, tricky for a Ledger, obviously, because it touches the core part of Cardano, so you don't want to do anything wrong with that. But okay, I will also keep a note for that, but I will definitely need to bring the conversation with the Ledger team and IOG on that, to make sure we have an actual way for bringing the CIP up front. I reached out to the research last two weeks ago on various sort of topics. I haven't got a clear answer so far, so I will keep on chasing people. But yeah. + **M. Àngels Jover** - So we can put this on hold until you have an answer from the Ledger team, right? + **Matthias Benkort** - No, no. For this one, it's fine. We've already discussed this one a few times. It's also been reviewed by the Ledger team back in the days, but there is still this question of, even if you're moving to propose, that doesn't mean it will ... There isn't currently a item on the roadmap of the Ledger team to address that particular proposal. I'm not sure that's shown as also the willingness or capability to implement the change in the Ledger code base itself. So it has proposed already an implementation, but more like a separated one. So yeah. I will bring that back again to the attention of the Ledger team to see what's up and if they have indeed no plan to implement that and it's a few unknown because these and these reasons. I don't know. Then we'll report back and maybe make the CIP obsolete. But for now, we can move it to proposed, and I will just modify the git history to have a clean history of commits with the Ledgers after the meeting, since it's a fairly small thing to do. + **M. Àngels Jover** - Perfect, perfect. We have PR159: Reference Inputs. And for this one, we comment in last meeting that it was good to go, but we asked Michael to add a justification for phase one. And I don't think that that has been added. + **Matthias Benkort** - So yeah, it was a small thing, right? That he added recently an extra check, again that was on the forbidding usage of referenceinputs with old scripts with the V1 versions. And I guess there's someone in the chats was discussing why was this done in the phase one but additions of phase two? But I guess we answered that in the last meeting already. Michael didn't report it back on the CIP. Yeah, just drop a line in there. I see it has also the insert, so we can maybe just clarify with him. I will just drop a comment on the pull request. And once we have that, this one would be ready to go and get merged as we discussed last time. + **M. Àngels Jover** - Perfect. + **Matthias Benkort** - So we'll just merge it with just the conditions as we add this little rationale, just one small line change. And I will state we can get that done today as well. + **M. Àngels Jover** - Perfect. We have PR160: Inline Datums + **Matthias Benkort** - Yeah, this one is pretty much. Also it was in the last check, it was under last check... No, it was just ready for review. + **M. Àngels Jover** - Yeah. I think that we have a comment here. It's not in this one. This was for the last check. + **Matthias Benkort** - Yeah. And that was a bit with some spirits. Yeah, this one is also fine. It should go as a draft towards the implementation. It happening also concomitantly. + **M. Àngels Jover** - We have all the approvals here, I am going to check. We miss one approval, right? In order to merge it? + **Matthias Benkort** - Yeah. So, Sebastian, Robert or Fred maybe later when they are up. I will just CC them. Okay. **M. Àngels Jover** - Cool. So we will go into the review items. We're going to start PR 148, because the other one, we will wait for Sebastian -**Matthias Benkort** - Yeah. So, 148. Yeah, I asked last meeting to have an update from Rob. He said: - “I think it's read for review now. I just updated the spec to use an Address string type which can be either the old hex bytes or bech32. I think that's is it for comments on this besides out-of-scope large changes like not using cbor anywhere mentioned above. -I changed the Address format in other endpoints for consistency, but we can do that in another PR if we feel it is necessary. There's also the issue of the API version. Should we be incrementing this by a major version here or do we only want to start doing that once CIP-30 moves out of draft status?” -That's a good point.- -There's one comment from Martynas: - “How about adding a "content type" argument? Wallets could try to display the message being signed to the user” + +**Matthias Benkort** - Yeah. So, 148. Yeah, I asked last meeting to have an update from Rob. He said: “I think it's read for review now. I just updated the spec to use an Address string type which can be either the old hex bytes or bech32. I think that's is it for comments on this besides out-of-scope large changes like not using cbor anywhere mentioned above. + +I changed the Address format in other endpoints for consistency, but we can do that in another PR if we feel it is necessary. There's also the issue of the API version. Should we be incrementing this by a major version here or do we only want to start doing that once CIP-30 moves out of draft status?” That's a good point.- There's one comment from Martynas: “How about adding a "content type" argument? Wallets could try to display the message being signed to the user” Not sure to get it. -** Frederic Johnson** - So we will get changes that occurred since Rob actually pushed that comment, or show right before he post that comment? So, my issue goes to- + +**Frederic Johnson** - So we will get changes that occurred since Rob actually pushed that comment, or show right before he post that comment? So, my issue goes to- + **Matthias Benkort** - Yeah, that is what he said. We were discussing in the past, to change the API, to accept not the address as a hexacoded string, but actually as bech32 strings, which is the way it actually displays in most interfases. That's the way wallets manipulate them, and it's a bit more coherent with the entire presenter API. So, what we discussed was to do that for the same data, of course, but then reflect that on the entire API or to keep consistency. But since that would be in principle a breaking change, the idea was to support both formats. It has wallets that actually accepts either hex or Bech32 encoded strings, and let them figure out basically which one it is, which is pretty straightforward to do for a wallet implementer. So, as it is for now, at least from my perspective, the proposal is fine. This was not a proposal per se but just an addendum on an existing one, for the CIP 30. So we can probably move this to the last check for the next meeting, and see if people still want to comment on it or not. So, there is actually one comment, which is asking about something I don't quite get. So we can try to divert that with that person in the next two weeks and see where it goes. + **M. Àngels Jover** - Okay. So, this was what we have from the agenda. Let me check if there's any questions in the chat. + **Matthias Benkort** - Kevin wanted to bring up the votes delegation CIP, which I think was proposed by Mark some time ago. That was initially proposed as an extension to Catalyst to the CIP 15 proposal I think. But then we decided that it was better to move it as a separate proposal, in form of like an extension of CIP 15, instead of modifying CIP 15, which is already complex enough, and it has undergone a lot of changes. + **Matthias Benkort** - So, the idea was to say, "Okay, we want to have this extension to a line which you have multiple... or just do multiple keys for the Catalyst proposal, such that on the side chain can be multi-delegated to different pools, and therefore enables more like a split routine in the real. + **Matthias Benkort** - We have Kevin around, so maybe we can bring Kevin on the voice chat, and he can give us a walkthrough. I think Kevin you've been discussing that with Mark a bit. -** Frederic Johnson** - If I recall correctly, I think Mark was adamant on pushing his own pull request or own CIP. And I think Kevin did his own CIP, and I think there were two competing CIPs doing the same thing. + +**Frederic Johnson** - If I recall correctly, I think Mark was adamant on pushing his own pull request or own CIP. And I think Kevin did his own CIP, and I think there were two competing CIPs doing the same thing. + **Matthias Benkort** - Okay. But I didn't see the CIP from Kevin actually. There was an original request which was changing CIP 15, which is still actually open as a pull request. ** Frederic Johnson** - But the decision on that specific PR was that we'd scrub that PR, effectively closing it, and instead request a standalone CIP just for simplicity, as opposed to trying to modify the old one. + **Matthias Benkort** - Yeah. Because it was modifying quite substantially the old one, effectively making it a completely different proposal. So we asked Mark... Actually, we asked to create a number of PR, and Mark volunteered to do so, but haven't still closed the old one. I'm not sure actually who opened the old one in the first place. Do we have Kevin online? Oh no, Kevin is not here anymore. So let's actually go through the comments ourselves then. Oh, Kevin is there. + **Kevin Hammond** - I lost the window. Happy for this to be a separate CIP if that’s what you want to progress. What we do need is a dedicated CIP number that we can just refer to this internally during the developing process. We're trying to use CIP 36. I understand that number that Mark assigned to it, there is path for confusion developing. On terms of content the we've been commenting the new PR that Mark had put in. + **Matthias Benkort** - Yeah, okay. So that's [crosstalk 00:23:13]. + **Kevin Hammond** - What else now needs to be done? + **Matthias Benkort** - Well, discussing, obviously, right? Making sure people agree. I think that's fairly the case on that one. The number assignation, that's part of why I did this little change in the read-me I was mentioning earlier. One of the reason why I wanted to move also the current PR under discussions to the read-me, was to pre-allocate them a number already, to avoid these clashes. And this one is in this number 36, so there is a good chance that it will stay exactly like that, unless it gets not merging in the end and ends obsolete. But I don't think this will happen, so we'll probably proceed with that. Move it to the last check as well for the next meeting; it's been reviewed already quite a bit. And yeah, I take it from there basically. So those two discussions... No, I think let's check with maybe too soon, we haven't properly given time to discuss it in any little meeting. We can move it to the next meeting for review. + **Kevin Hammond** - Okay. + **M. Àngels Jover** - Is this one PR 188 we're talking about right now? + **Matthias Benkort** - No. This one is the old one. That's the one modifying CIP 15 that we asked to split as a separate pull request. + **M. Àngels Jover** - So which one is the one that we're going to add to review in the next meeting? + **Matthias Benkort** - PR number 200, right? Yeah, the 200 one by Mark, which we'll have a full complete review of that one. + **Kevin Hammond** - That's slightly go over authorship it should be attributed Giacomo to who wrote the original proposal rather than Mark. I don't know if there's a way to [crosstalk 00:25:22]. + **Matthias Benkort** - Yeah, it's not attributed to Mark, right? It currently has one, two, three, four, five authors. You're actually one of them, by the way, apparently. Giacomo is also one of them. I guess Mark just wrote the PR, and he didn't even credit himself as an author. He just credited the original. It's just that he did open the pull request. + **Kevin Hammond** - I'm actually trying to get some attribution. So, if Mark created the PR, he'll be attributed with creating this. + **Matthias Benkort** - No, no, no. If you look at the author of the CIP, they are actually listed here, right? ? So it's Sebastian Reno, Mikhail, Giacomo and you Kevin. Github is always referring to the person who has created the PR as being [crosstalk 00:26:17]. + **Matthias Benkort** - I see what you mean. So maybe what we can do is tweak a bit the GitHub history so that this full request is made as a change on top of Giacomo one. So that in the history we can see that one. This first thing it was reverted, and then this new commit was created. I can do something like that to have the above authors actually be contributors to the repository. + **Kevin Hammond** - Exactly. That will keep the history straight and fair. + **Matthias Benkort** -Yeah. Fair enough. + **Kevin Hammond** - Like proper credit. + **Matthias Benkort** - Yeah. + **M. Àngels Jover** - So Matthias, you will be able to do that yourself or... + **Matthias Benkort** - Yeah. I will just push on the branch only if Mark actually have authorized people to push on his branch. If not, I will see with him if we can just do that updates. Right? So the ideas is really not to change anything to the current result, but change the history. Right? So that it better reflects what happened, that there was a first change by Giacomo, and then it was on top of that extracted by marking a separate PR. Right? + **Kevin Hammond** -Okay. + **Matthias Benkort** - So in the history we keep the right history of how things happened. + **Kevin Hammond** -Exactly. Yeah. I think it's important to make sure the history is recorded properly, right Matthias? + **Matthias Benkort** -Yeah. I mean, in the end, that's why we have this metadata on top of CIPs. It's also, you have the list of authors here, and if you want to refer to one of those people, should be someone from the list. It doesn't quite matter who made the change on unbeatable when you think. But I mean, for some people, it does matter so I can get that. + **Kevin Hammond** - It matters. It matters to some people. + **Matthias Benkort** -Mm-hmm (affirmative). + **Kevin Hammond** - Great. And in terms of status, we're working on this, we are taking into account any comments that have been made. If people like to make further comments, happy to respond. And not seen any major issues coming up through the commenting process. + **Matthias Benkort** - Yeah. + **Kevin Hammond** - If anyone would like to add anything to that, very happy to do so. + **Matthias Benkort** - Okay, good. + **Kevin Hammond** -That you. + **Matthias Benkort** - Let's see, maybe if we have other call request we could bring up to discussions here. If there's anyone in the chat that has a suggestion, otherwise we'll just pick one from the existing ones. I see there is another update on, or two other updates actually, on CIP 30, which we could maybe quickly go through. One is for request 208 and one 209. So one of them is Adding getCollateral function to the connector API: getCollateral given an amount, it gives back a UXTO to spend as collateral. The value to use for collateral? Because... yeah, okay. There is an amounts to be passed, but in principle, this amounts depends on the transaction script execution units. @@ -152,67 +222,124 @@ If there is any other one, Kevin, if you can get the people in IO to make a prop Another CIP maybe, that I would like to bring to review our discussions next week, is the Plutus Core built-in of... Sorry, the Plutus Core changes CIP. Plutus Core evolution. So PR number 215, which gives a framework for actually proposing changes to Plutus and getting them through the entire process also including implementation with the team and all that. I think that's a very nice initiative for Michael to really lay that down and have a clear process for proposing Plutus changes. There have already been a couple of proposals on top of that one, following that exact process. So it would be nice if we could get this one approved, or at least discussed. I've already been reviewed by me, already reviewed it, because I already made a proposal on top of that one. And I definitely see the value of this one. So I would very much like to have it as an active CIP as soon as possible to be able to then move on and have proposals on Plutus. Exactly. That follows this standard. So they can bring it for reviews also next week and then last check. Hopefully we can get it into the repro quite fast. Since there is no implementation for that one even, we can probably move it almost directly to active. Because the sole fact that there are already two or three proposals on top of it, well, qualifies it as an active CIP. + **M. Àngels Jover** - Okay. Anything else that you want to discuss Matthias? + **Matthias Benkort** - I'm not sure. Keep getting the same stuff in the chat. Yes, I'll try to get people to comment on that. It seems to be some divergence on this. Of course, that's why we want to have a CIP. Because then discussions can happen on the CIPs publicly, and people can share different implementations and different wallets. Yeah. + **Kevin Hammond** - That's right. So we need to get some standardization, I think, on this Matthias. And as I've said in the chat, I think there's some additional functionality which isn't original CIP proposal, which we'll need for the vote delegation. So we need witnessing capabilities as well as signing capabilities. + **Matthias Benkort** - What do you mean witnessing capabilities? + **Kevin Hammond** - I mean, we'll need to... Because the way the CIP 36 is to find, there are two distinct keys involved. One of them to provide a witness from a voting key... Sorry, from the stake key, and the other to sign and submit a transaction using a payment key. So we need sort out the different elements of witnessing using stake key, versus signing and submitting using payment key. + **Matthias Benkort** - Yeah. I'm mean, okay. But in both cases that remains, it's still a signature. But it's just a signature from not a human key, but a staking key, right? + **Kevin** - Yes + **Matthias Benkort** - Because I thought you were referring to witness as in being able to add full scripts or datums or redeemers, or whatever's going for [inaudible 00:36:42] that. But that can already be done by a DApp in principle. They don't need the wallet for that. So how is actually currently... Well, I need to refresh my mind now. On CIP 30, how does the signing works currently? What does it provide? Sign TX, does the wallet determines automatically what the key test to use? Yes. Ah, yeah. Okay. Yeah. The sign, we give it the TX and the wallet figure out the transaction, witness it. Wallet should be able to figure out it's the staking key, right? But surely the staking key comes from the wallet? + **Kevin** - As long as it knows it needs to sign with staking key, Matthias. + **Matthias Benkort** - Yeah. So, okay. I mean, maybe we could use an API that is a bit more explicit, like the Ledger or Tresor devices works, right? For signing to device you give them the transaction body, but also the derivation path of the signing key you expect. And then they produce the signatures cross going to do his path. + **Kevin Hammond** - Yes. + **Matthias Benkort** - So I guess the API here could be extended in that direction to say... Well, you take also a list of derivation path and you make sure that you can produce a signature for them. If you don't provide that list, then it's up to the wallet to figure out those keys needed for a single transaction. + **Kevin Hammond** - Yeah. And then the question is, how does the Dapp knows the derivation path that it needs to have enough information [crosstalk 00:38:12] of it. + **Matthias Benkort** - Not necessarily. But yeah, okay. Because it's internal details of the wallet in here. + **Kevin Hammond** - Exactly. Yes, don't want to [crosstalk 00:38:24]. + **Matthias Benkort** - But ideally, wallet can probably figure out the signature already. + **Kevin Hammond** - Sorry? + **Matthias Benkort** - I mean, if you need to sign by a staking key, then surely there is something in the transactions that identified as staking key, right? It has to be in the required signature of the transaction. + **Kevin Hammond** - Yeah. That's right. I can identify what I have is information about the public. I have the public stake key hash. I won't have the stake key itself, I think. + **Matthias Benkort** -Yeah, yeah, of course, of course. + **Kevin Hammond** - So I'll need [crosstalk 00:38:57]. + **Matthias Benkort** - But, so a wallet that's receiving this transaction for signing through this CIP 30 API, right? + **Kevin Hammond** - Yes, correct. + **Matthias Benkort** - It's received the whole transactions and there is some point in a transaction, something that says you need a signature from that key hash. And that key hash is known of the wallet because it's a state key. + **Kevin Hammond** - Yeah. Correct. So as long as I identify the fact that I need a signature from that key hash, as long as the wallet can then determine the derivation path from that, then that would work fine, I think. + **Matthias Benkort** - I think the current API is fine. What we maybe need to enhance that CIP is a list of test vectors with a specific test case, where you can actually provide a transaction that has a staking key as a required key hash signature, and the resulting signature contains witnesses for that stake key. + **Kevin Hammond** - Right. + **Matthias Benkort** - And as we make sure that wallets that implement that CIP would have also to satisfy the test vectors and that's it. -K**Kevin Hammond** - So I propose is why don't you and I take this offline materials with the IO, we can discuss this with other people and why io wallet team, and then make sure that we have something concrete to this committee. + +**Kevin Hammond** - So I propose is why don't you and I take this offline materials with the IO, we can discuss this with other people and why io wallet team, and then make sure that we have something concrete to this committee. + **Matthias Benkort** - Yeah. And then make a proposal out of it. That will be fair. + **Kevin Hammond** - Yeah. That seems to be the correct presence. + **Matthias Benkort** - Okay. + **Kevin Hammond** - Thank you. + **Matthias Benkort** -Fair enough. -**Frederic Johnson** - -Do you not consider maybe the rest of the time for discussion regarding moving to a US time zone for the meeting or to try something like that? + +**Frederic Johnson** - Do you not consider maybe the rest of the time for discussion regarding moving to a US time zone for the meeting or to try something like that? + **Matthias Benkort** - Yeah. Maybe, to be a bit more on the process. There is also one thing I would like us to give a thoughts, maybe not in this current meeting, but that is for you, Fred also, and other editors I will reach out, but we have 12 issues open on the repo. So it seems that people are using issues to discuss things. And it's something we are actually, we haven't included the part of the process currently. Right. So we had issues and no one is really taking care of them at the moment. I actually just noticed last week that had so many issues because I was so far focused on the pull request when it comes to the CIPs, but there is a fair amount of discussions happening in issues, which is interesting. Right. We never really stated that as part of the process, but it just happened organically, I guess. And maybe we should start also, including issues, issue triage as part of the editors meeting or spend some time offline to go through them. + **Frederic Johnson** Yeah. I agree. I've seen those grow and I think that it's good that we're actually paying attention right now as they've pretty much propped up functionally like the past few month. And it's a matter of just keeping on top of it, the same with the labeling of the issues right now. So I think this is all project management really, Maria is going to be able to cover a lot of that ground. I think that's like a new added step. I don't want to overextend a little bit into committing to too many things, like too many meetings and covering issues and adding too many PRs, just because a lot of that is functionally being offloaded mostly to Maria. And I'm just thinking that if we're doubling the meetings, it might be something, have you also coupled with other people that are involved in transcribing the meeting notes and everything like that. + **Matthias Benkort** - Yeah. Sorry. I was not actually implying that. We shouldn’t double the workload for Maria as well on these US based time zones that I'm actually thinking that the US crew could be possibly different from the European crew. I don't mind bridging the two crew for now, but for sure for the US base, we would Robert onboard and maybe we can also have someone that help with notes and whatnot. Or I can take that. I can take that part maybe on me and let Robert conduct the meetings for the US based one. And there was also the question of recruiting more editors, getting more people on board. So maybe we could start discussing an actual approach to that. How do we get people who join us and help us with that task? Maybe that would be interesting. + **Frederic Johnson** - I agree. I think we have a meeting like that coming up with Maria on the side of the retrospective, every 10 meetings we have that, I think that's totally a good place to have that. If you want to try something regarding US time zones, what our propose is that we do something at 10:00 a.m. PST, which equates to, I think like 7:00 PM your time. So Maria and yourself, I think both of you are in the same time zone. If you're able to do a 7:00 PM meeting, that might be an option. But I don't know if we want to do that for the next one or for like 42 or something like that. + **Matthias Benkort** - I would like to try for the next one. Definitely. So next week have that up. That will work for me if it works for you also Maria, or I can try to take some notes on that. + **Frederic Johnson** - Can we try the next biweekly one? So in two weeks, rather than one week. + **Matthias Benkort** - Oh, so you mean to move the next biweekly as a US based? + **Frederic Johnson** - Yes. Just the next CIP meeting because those meetings are biweekly. So every two weeks, so the 40th right now is up on Tuesday. The next 41 will be in two weeks and it will be happening functionally at a US time zone slot. + **Matthias Benkort** - Yeah. Okay. Okay. I guess it's also maybe fine for even European time to be at 7:00, because I imagine if people are also not joining because they just have work to do at 10:00 AM and maybe it's more convenient to join at 7:00. + **M. Àngels Jover** - Maybe that's right. + **Matthias Benkort** - So maybe it's also all better for even European time zones. + **Frederic Johnson** - Yeah. The only + **M. Àngels Jover** - Maybe we can test it and see how it goes. + **Matthias Benkort** - Yeah. Yeah. Test for a couple of weeks. So last time I asked on Twitter actually, a bunch of people, it was pretty much 60%, 40% that there was a lot of people I wanted to have meetings in the US time zone. So I was out of like 400 people. That's still a fair amount of four segments to join. I imagine I'm not sure how about the actually distribution. It's all the people that answer "yes, we're actually in the US', or even if there were some European that were interested to have meetings at the US base time zones. But yeah, maybe let's try it, let's have the next one in, at 6:00 UTC. Right. And I don't know the time zone, like the UTC to be franc, but it much easier for me to think just in UTC time. And that that would be... + **M. Àngels Jover** - The 15. Right? + **Matthias Benkort** - Yes. + **Matthias Benkort** - 6:00 pm UTC. + **M. Àngels Jover** - Do you want to do a wrap up of what we have for next meeting? So we have PR 153 that you are going to do Matthias some github clean up and it will be ready to go and can be merged before next meeting. PR 160 also is ready to go and can be merged. Then for next meeting, we will have PR 148 for last check. And then we have a pretty busy review section. We will have PR 215, 208, 209 and 200. And we are waiting for Rob answering 211 in order to identify phase one. If this is done, you are going to merge it asynchronously, right? + **Matthias Benkort** - Yep. + **M. Àngels Jover** - And we have on hold, all the collateral PRs that we want Sebastian to be commenting on them. + **Matthias Benkort** - Yeah. Work us through the changes. Correct. Okay. Thank you. + **M. Àngels Jover** - Perfect. Thank you very much. + **Frederic Johnson** - All right. Thank you everyone. From 60c057158bd4b80d07a48c6f12ec42438bac6b6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20=C3=80ngels=20Jover?= <99675813+mangelsjover@users.noreply.github.com> Date: Wed, 2 Mar 2022 23:01:18 +0100 Subject: [PATCH 4/7] Update 2022-02-01.md --- BiweeklyMeetings/2022-02-01.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/BiweeklyMeetings/2022-02-01.md b/BiweeklyMeetings/2022-02-01.md index 8bde825324..8a3dd3c4de 100644 --- a/BiweeklyMeetings/2022-02-01.md +++ b/BiweeklyMeetings/2022-02-01.md @@ -2,8 +2,8 @@ - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) -- [February 15 2022 notes](#february-15-2022-notes) - * [Triage](#triage) +- [March 1 2022 Transcript](#march-1-2022-transcript ) + * Triage + [PR211 - Add reference implementation for CIP15 ](#pr211) + [PR104 - CIP-1856 | Collateral Key derivation](#pr104) + [PR217- Collateral reward](#pr217) From 44fc999bdfbaf72638db146bbf0081a333988f7e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20=C3=80ngels=20Jover?= <99675813+mangelsjover@users.noreply.github.com> Date: Wed, 2 Mar 2022 23:02:59 +0100 Subject: [PATCH 5/7] Update 2022-02-01.md --- BiweeklyMeetings/2022-02-01.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/BiweeklyMeetings/2022-02-01.md b/BiweeklyMeetings/2022-02-01.md index 8a3dd3c4de..883f1a4e28 100644 --- a/BiweeklyMeetings/2022-02-01.md +++ b/BiweeklyMeetings/2022-02-01.md @@ -4,22 +4,22 @@ - [Editors Meeting Flow](#editors-meeting-flow) - [March 1 2022 Transcript](#march-1-2022-transcript ) * Triage - + [PR211 - Add reference implementation for CIP15 ](#pr211) - + [PR104 - CIP-1856 | Collateral Key derivation](#pr104) - + [PR217- Collateral reward](#pr217) - * [Last Check](#last-check) - + [PR153 - Fair min fees ](#pr153) - + [PR159 - CIP-31: Reference inputs](#pr159) - + [PR160 - CIP-32: Inline datums](#pr160) - * [Review](#review) - + [PR148 - "CIP-0030: update to api.signData()""](#pr148) - + [PR216 - "Collateral output"](#pr216) - * [Discussions](#discussions) - + [PR200 - Add support for Catalyst multi-delegation](#pr200) - + [PR208- [CIP-0030] Adding getCollateral function to the connector API](#pr208) - + [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](#pr209) - + [PR215 - CIP-35: Plutus Core Evolution](#pr215) - * [Close](#close) + + PR211 - Add reference implementation for CIP15 + + PR104 - CIP-1856 | Collateral Key derivation + + PR217- Collateral reward + * Last Check + + PR153 - Fair min fees + + PR159 - CIP-31: Reference inputs + + PR160 - CIP-32: Inline datums + * Review + + PR148 - "CIP-0030: update to api.signData()"" + + PR216 - "Collateral output" + * Discussions + + PR200 - Add support for Catalyst multi-delegation + + PR208- [CIP-0030] Adding getCollateral function to the connector API + + PR209 - [CIP-0030] Adding optional networkId parameter to .enable + + PR215 - CIP-35: Plutus Core Evolution + * Close - [Extra](#extra) * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status) * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram) From 456c675313bec6d9d3742af0e3d1dc85db603dff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20=C3=80ngels=20Jover?= <99675813+mangelsjover@users.noreply.github.com> Date: Thu, 3 Mar 2022 01:24:33 +0100 Subject: [PATCH 6/7] Update 2022-02-01.md --- BiweeklyMeetings/2022-02-01.md | 166 +++++++++++++++++++++++++++------ 1 file changed, 139 insertions(+), 27 deletions(-) diff --git a/BiweeklyMeetings/2022-02-01.md b/BiweeklyMeetings/2022-02-01.md index 883f1a4e28..4e7f96faee 100644 --- a/BiweeklyMeetings/2022-02-01.md +++ b/BiweeklyMeetings/2022-02-01.md @@ -3,27 +3,23 @@ - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [March 1 2022 Transcript](#march-1-2022-transcript ) - * Triage - + PR211 - Add reference implementation for CIP15 - + PR104 - CIP-1856 | Collateral Key derivation - + PR217- Collateral reward - * Last Check - + PR153 - Fair min fees - + PR159 - CIP-31: Reference inputs - + PR160 - CIP-32: Inline datums - * Review - + PR148 - "CIP-0030: update to api.signData()"" - + PR216 - "Collateral output" - * Discussions - + PR200 - Add support for Catalyst multi-delegation - + PR208- [CIP-0030] Adding getCollateral function to the connector API - + PR209 - [CIP-0030] Adding optional networkId parameter to .enable - + PR215 - CIP-35: Plutus Core Evolution - * Close -- [Extra](#extra) - * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status) - * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram) - * [Understanding CIPs further](#understanding-cips-further) + * [Triage](#triage) + + [PR211 - Add reference implementation for CIP15](#pr211) + + [PR104 - CIP-1856 | Collateral Key derivation](#pr104) + + [PR217- Collateral reward](#pr217) + * [Last Check](#last-check) + + [PR153 - Fair min fees](#pr153) + + [PR159 - CIP-31: Reference inputs](#pr159) + + [PR160 - CIP-32: Inline datums](#pr160) + * [Review](#review) + + [PR148 - CIP-0030: update to api.signData() ](#pr148) + + [PR216 - Collateral output](#pr216) + * [Discussions](#discussions) + + [Add support for Catalyst multi-delegation](#pr200) + + [PR208 - CIP-0030 Adding getCollateral function to the connector API](pr208) + + [PR209 - CIP-0030 Adding optional networkId parameter to .enable](#pr209) + + [Moving meeting 41 to US time zone](Moving-Editors-Call-Meeting-41-to-US-time-zone) + * [Close](#close) ## Summary @@ -50,8 +46,12 @@ PR -> ‘Draft’: Needs format + approval. ## March 1 2022 Transcript +**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, ~Sebastien Guillemot~, Frederic Johnson, ~Robert Phair~. + guests(Kevin Hammond) -**Attending Editors**: Matthias Benkort, Frederic Johnson + guests (Kevin Hammond) +### Triage + +#### PR211 + [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) **Maria** - Welcome, everybody, to the CIP editors meeting number 40. My name is Maria Jover and I am a project manager of the Cardano Foundation and I am here to facilitate this meeting. At the top left, you can find the agenda for the meeting today and please feel free to use the chat or the ask question in order to engage with the conversation. It's my pleasure today to introduce you our editors, Matthias Benkort and Frederic Johnson. So you want to make an announcement or a request, right, Matthias? @@ -72,17 +72,44 @@ So of course, since they are not merged, they are not in the audit table, which **Matthias Benkort** - Yeah. We were waiting for review from Robert. It came two weeks ago, but we then kind of forgot to merge it. So this is just a small update on CIP15, adding a reference implementation, which I've also reviewed. So this one is fine to go. Now it has two check marks from a editors so I would just proceed and merge that one. Good. +=> Merged as CIP15 (draft) [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) waiting for Rob answering 211 in order to identify phase one + + +#### PR104 + +[PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) + **M. Àngels Jover** - PR105 Collaterall Key Derivation **Matthias Benkort** - I would like to maybe postpone a bit this one, because it's a proposal from Sebastian, who is not there today. So there has been a lot of discussions on top of it. And I haven't been following quite closely that one. So I would very much like Sebastian to walk us through a bit the discussions and the outcome. So the general idea here is really to have a ... it is proposing a dedicated key for making the management of collectables easier and hopefully remove that version from the end users, which currently has sort of to define a collectable in their wallets to make sure that they can execute scripts. And it's a bit cumbersome at this stage. So yeah, I see the proposal has been discussed by the people from the Ledger teams. So it's interesting. But yeah, let's see when Sebastian is back to walk us through that change. +=> [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) put on hold and waiting for Sebastien to discuss it + +#### PR217 + +[PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) + **M. Àngels Jover** - Good. So it will happen the same with PR217 and PR216, right? **Matthias Benkort** - Yeah, one of them is actually duplicated. I think that's PR217. Sebastian said last week he wanted to remove that one, I think. **M. Àngels Jover** - The previous one was pretty old, I think. -**Matthias Benkort** - Yeah, I think what he said last week was that this one wasn't really useful. He just did it for the sake of reporting what had been discussed with the Ledger team in the past. I think he wanted to duplicate it. So we'll also wait on that, maybe ping him back on the pull requests. I've dropped in the comments. So moving to fair min fees, maybe. The PR153. So this one is actually just exchange of statuses, right? If I recall correctly or not. +**Matthias Benkort** - Yeah, I think what he said last week was that this one wasn't really useful. He just did it for the sake of reporting what had been discussed with the Ledger team in the past. I think he wanted to duplicate it. So we'll also wait on that, maybe ping him back on the pull requests. I've dropped in the comments. + +=> [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) put on hold and waiting for Sebastien to discuss it, possibly removed as duplicate + + + +### Last check + + + +#### PR153 + +[PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153) + +**Matthias Benkort**So moving to fair min fees, maybe. The PR153. So this one is actually just exchange of statuses, right? If I recall correctly or not. **M. Àngels Jover** - Yes. What was talked last meeting is that you want to do some with github cleanup on it. @@ -100,7 +127,15 @@ At the same time, also, I was going back through the CIP1 process and in particu **Matthias Benkort** - No, no. For this one, it's fine. We've already discussed this one a few times. It's also been reviewed by the Ledger team back in the days, but there is still this question of, even if you're moving to propose, that doesn't mean it will ... There isn't currently a item on the roadmap of the Ledger team to address that particular proposal. I'm not sure that's shown as also the willingness or capability to implement the change in the Ledger code base itself. So it has proposed already an implementation, but more like a separated one. So yeah. I will bring that back again to the attention of the Ledger team to see what's up and if they have indeed no plan to implement that and it's a few unknown because these and these reasons. I don't know. Then we'll report back and maybe make the CIP obsolete. But for now, we can move it to proposed, and I will just modify the git history to have a clean history of commits with the Ledgers after the meeting, since it's a fairly small thing to do. -**M. Àngels Jover** - Perfect, perfect. We have PR159: Reference Inputs. And for this one, we comment in last meeting that it was good to go, but we asked Michael to add a justification for phase one. And I don't think that that has been added. +=> [PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153) this PR has a weird git commit history so Matthias will clean up the history to keep only the last commit that is actually the change proposed by the PR (moving it to proposed) and proceed with merging it + + + +#### PR159 + +[PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159) + +**M. Àngels Jover** - We have PR159: Reference Inputs. And for this one, we comment in last meeting that it was good to go, but we asked Michael to add a justification for phase one. And I don't think that that has been added. **Matthias Benkort** - So yeah, it was a small thing, right? That he added recently an extra check, again that was on the forbidding usage of referenceinputs with old scripts with the V1 versions. And I guess there's someone in the chats was discussing why was this done in the phase one but additions of phase two? But I guess we answered that in the last meeting already. Michael didn't report it back on the CIP. Yeah, just drop a line in there. I see it has also the insert, so we can maybe just clarify with him. I will just drop a comment on the pull request. And once we have that, this one would be ready to go and get merged as we discussed last time. @@ -108,7 +143,13 @@ At the same time, also, I was going back through the CIP1 process and in particu **Matthias Benkort** - So we'll just merge it with just the conditions as we add this little rationale, just one small line change. And I will state we can get that done today as well. -**M. Àngels Jover** - Perfect. We have PR160: Inline Datums +=> [PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159) moved from draft to proposed + +#### PR160 + +[PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160) + +**M. Àngels Jover** - We have PR160: Inline Datums **Matthias Benkort** - Yeah, this one is pretty much. Also it was in the last check, it was under last check... No, it was just ready for review. @@ -120,6 +161,15 @@ At the same time, also, I was going back through the CIP1 process and in particu **Matthias Benkort** - Yeah. So, Sebastian, Robert or Fred maybe later when they are up. I will just CC them. Okay. +=> Merged [PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160) + + +### Review + +#### PR148 + +[PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) + **M. Àngels Jover** - Cool. So we will go into the review items. We're going to start PR 148, because the other one, we will wait for Sebastian **Matthias Benkort** - Yeah. So, 148. Yeah, I asked last meeting to have an update from Rob. He said: “I think it's read for review now. I just updated the spec to use an Address string type which can be either the old hex bytes or bech32. I think that's is it for comments on this besides out-of-scope large changes like not using cbor anywhere mentioned above. @@ -134,6 +184,23 @@ So, as it is for now, at least from my perspective, the proposal is fine. This w **M. Àngels Jover** - Okay. So, this was what we have from the agenda. Let me check if there's any questions in the chat. +=> [PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) moved to Last check for the next meeting + + +#### PR216 + +[PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) + +** Matthias ** - I would like to maybe postpone a bit this one, because it's a proposal from Sebastien, who is not there today. + +=> [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) put on hold and waiting for Sebastien to discuss it + +### Discussions + +#### PR200 + +[PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) + **Matthias Benkort** - Kevin wanted to bring up the votes delegation CIP, which I think was proposed by Mark some time ago. That was initially proposed as an extension to Catalyst to the CIP 15 proposal I think. But then we decided that it was better to move it as a separate proposal, in form of like an extension of CIP 15, instead of modifying CIP 15, which is already complex enough, and it has undergone a lot of changes. **Matthias Benkort** - So, the idea was to say, "Okay, we want to have this extension to a line which you have multiple... or just do multiple keys for the Catalyst proposal, such that on the side chain can be multi-delegated to different pools, and therefore enables more like a split routine in the real. @@ -210,10 +277,24 @@ So that in the history we can see that one. This first thing it was reverted, an **Kevin Hammond** -That you. +=> [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) moved to next meeting for review + +### PR208 + +[PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) + **Matthias Benkort** - Let's see, maybe if we have other call request we could bring up to discussions here. If there's anyone in the chat that has a suggestion, otherwise we'll just pick one from the existing ones. I see there is another update on, or two other updates actually, on CIP 30, which we could maybe quickly go through. One is for request 208 and one 209. So one of them is Adding getCollateral function to the connector API: getCollateral given an amount, it gives back a UXTO to spend as collateral. The value to use for collateral? Because... yeah, okay. There is an amounts to be passed, but in principle, this amounts depends on the transaction script execution units. -Okay. I guess that's an interesting one. We should also bring maybe for review for the next meeting. There is quite a fair, rational extension here. Then on top of that, there is also the CIP... Sorry, the pull request 209, which is Adding optional networkId parameter to .enable: a DApp for test net or main net future networks. +Okay. I guess that's an interesting one. We should also bring maybe for review for the next meeting. There is quite a fair, rational extension here. + +=> [PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) moved to next meeting for review + + +### PR209 + +[PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) +Then on top of that, there is also the CIP... Sorry, the pull request 209, which is Adding optional networkId parameter to .enable: a DApp for test net or main net future networks. Okay, interesting too. And it probably echoes... Yeah, CIP 34 from Sebastian, which was about providing a chain identifier. So maybe there is something to do here. Have the network ID be provided as non-chain identifier. Yeah. Providing it as zero or one. Feels a bit untied, or not really user friendly from a developer perspective. So Sebastian had already a good proposal for identifying networks using a proper string of characters, I think codes the network ID and genesis. So we could go for that. So I would be happy also if we maybe this for review, for request 209. CIP 30 seems to be creating some discussion with IO... Of course. some additional functionality being needed. Yeah. So I guess the whole point of CIP 30... I mean the whole issue with the CIP in a way, is that it was created pre Alonzo, so there was a lot of things in there that didn't account for scripts and Plutus. Although it is now mainly used by wallets that provides that functionalities. And therefore, yeah, it needs a couple of extensions in that regard. @@ -293,6 +374,11 @@ Ah, yeah. Okay. Yeah. The sign, we give it the TX and the wallet figure out the **Matthias Benkort** -Fair enough. +=> [PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) moved to Review + + +#### Moving Editors Call Meeting 41 to US time zone + **Frederic Johnson** - Do you not consider maybe the rest of the time for discussion regarding moving to a US time zone for the meeting or to try something like that? **Matthias Benkort** - Yeah. Maybe, to be a bit more on the process. There is also one thing I would like us to give a thoughts, maybe not in this current meeting, but that is for you, Fred also, and other editors I will reach out, but we have 12 issues open on the repo. So it seems that people are using issues to discuss things. And it's something we are actually, we haven't included the part of the process currently. Right. So we had issues and no one is really taking care of them at the moment. I actually just noticed last week that had so many issues because I was so far focused on the pull request when it comes to the CIPs, but there is a fair amount of discussions happening in issues, which is interesting. Right. We never really stated that as part of the process, but it just happened organically, I guess. And maybe we should start also, including issues, issue triage as part of the editors meeting or spend some time offline to go through them. @@ -330,7 +416,7 @@ Ah, yeah. Okay. Yeah. The sign, we give it the TX and the wallet figure out the **Matthias Benkort** - 6:00 pm UTC. **M. Àngels Jover** - Do you want to do a wrap up of what we have for next meeting? -So we have PR 153 that you are going to do Matthias some github clean up and it will be ready to go and can be merged before next meeting. PR 160 also is ready to go and can be merged. Then for next meeting, we will have PR 148 for last check. And then we have a pretty busy review section. We will have PR 215, 208, 209 and 200. And we are waiting for Rob answering 211 in order to identify phase one. If this is done, you are going to merge it asynchronously, right? +So we have PR 153 that you are going to do Matthias some github clean up and it will be ready to go and can be merged before next meeting. PR 160 also is ready to go and can be merged. Then for next meeting, we will have PR 148 for last check. And then we have a pretty busy review section. We will have PR 215, 208, and 200. And we are waiting for Rob answering 211 in order to identify phase one. If this is done, you are going to merge it asynchronously, right? **Matthias Benkort** - Yep. @@ -342,6 +428,32 @@ So we have PR 153 that you are going to do Matthias some github clean up and it **Frederic Johnson** - All right. Thank you everyone. +### Close + + + => Merged as CIP15 (draft) [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) waiting for Rob answering 211 in order to identify phase one + + => Hold on [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) put on hold and waiting for Sebastien to discuss it + + => Hold on [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) put on hold and waiting for Sebastien to discuss it, possibly removed as duplicate + + => Merging it [PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153) this PR has a weird git commit history so Matthias will clean up the history to keep only the last commit that is actually the change proposed by the PR (moving it to proposed) and proceed with merging it + + => Hold on [PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159) moved from draft to proposed + + => Merged [PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160) + + => Hold on [PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) moved to Last check for the next meeting + + => Hold on [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) put on hold and waiting for Sebastien to discuss it + + => Hold on [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) moved to next meeting for review + +=> Hold on [PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) moved to next meeting for review + + +=> Hold on [PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) moved to Review + --- ## Extra From 548781f29eb33b5cae275230e49f3dc0229c02e8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20=C3=80ngels=20Jover?= <99675813+mangelsjover@users.noreply.github.com> Date: Thu, 3 Mar 2022 14:25:03 +0100 Subject: [PATCH 7/7] Rename 2022-02-01.md to 2022-03-01.md --- BiweeklyMeetings/{2022-02-01.md => 2022-03-01.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename BiweeklyMeetings/{2022-02-01.md => 2022-03-01.md} (100%) diff --git a/BiweeklyMeetings/2022-02-01.md b/BiweeklyMeetings/2022-03-01.md similarity index 100% rename from BiweeklyMeetings/2022-02-01.md rename to BiweeklyMeetings/2022-03-01.md