I have recently made a handful of BUIPs that are very similar in nature and essentially just gives BU a way to see if their members want them involved in a set of existing CHIPS.
There are more chips I could do this for, but given that a voting window was just closed and it is 3 months to the next one, it seems moot.
Three months from now we will either have a clear picture of what could go into BCH in may 2022, or we will have significantly more uncertainty than we do now.
NOTE: I was going to make one for GROUP, but given that andrew has distanced himself from bitcoincashautist’s CHIP, and have not retained an alternative version, I don’t know how to feel on that matter.
@JonathanSilverblood
I have added these to the BUIP index and they can be put forward for vote at the next voting session. I do ask that you monitor them for community feedback and make appropriate revisions as and when new information comes to light. As we discussed last year, raising a BUIP is not a fire-and-forget procedure, the proposer needs to work with commenters and make updates before the voting period starts.
Note that commitment to fund someone at BU specifically to liaise and shepherd our interaction with the CHIP process, a goal implied by several of your BUIPs, is in BUIP166 which you have just rejected.
Actually, in this specific case I think it is a fire-and-forget situation as long as @JonathanSilverblood does not mind updating the BUIPS with links to either the CHIP discussion threads or to the CHIPs themselves (which should contain links to the discussion threads). All further discussion at that point should be directed to the discussion place for that specific CHIP. There would be nothing left for him to do with the BUIPs. Any changes would need to go into the CHIP being voted on because the BUIP is asking for a vote on the CHIP.
I appreciate all of these BUIPs and certainly we will remain engaged in technical developments even during the interim until the next BUIP voting period, when these BUIPs can be officially oked or rejected.
I have a few questions for each one. First of all, how does Bitcoin Unlimited decide to support or reject a CHIP? There are some options: you could have the completion of these BUIPs be another BUIP that calls for an accept/reject vote or why. You could delegate that to the Developer (me) / dev team. Or you could delegate that to the Developer/dev team if we conclude “support it”, and call for a BUIP vote if we conclude “no”.
If you think that what I’ve suggested above is valid criticism, don’t only write something here. Post your changed text as a reply to each BUIP and we’ll edit the OP for you. Or you can edit the BUIP yourself, based on various timeouts in the forum software.
I will inform you in advance that my predilection is to aggressively move forward with the changes needed to build broad functionality into BCH, so I will tend to support a CHIP even if there are small things that I don’t like about it.
It’s my understanding that for things that relate to the full node development, you currently already have the mandate to take such action. Until a BUIP is voted on that gives specific direction, I think you and/or the dev team is the only actor that has that mandate.
This is much appreciated, as the expectation on the CHIP process is for proposals to produce public testnets before the next BUIP voting period, which is technical work I don’t personally have resources to do.
I am looking forward to seeing that turn into actions supporting the chips so that those less aggressive in this matter can spend more of our focus ensuring that there is a strong social consensus on the changes and as early as possible commitment to activate the changes.
It is perfectly fine to complete the technical work necessary for the chip process ahead of time - for example, the introspection chip need a public testnet and then a formal specification before commitment to activation should take place. If that work is done early, we might get a commitment to activate early as well, leaving more time and resources for people like me to bring other chips up to par and ready for the same activation date.
Here is a full explanation for those who are reading and may want one:
In the same way people elect officials to represent them in government, Andrew was elected to fill the position of lead developer and was therefor entrusted with the role of determining if a proposal is technically sound and poses no security risks to the BU implementation. The other contributors weigh in on the decisions but the lead developer does have the final call. If there is strong disagreement between the lead developer and the other contributors, it is the responsibility of the contributors to raise a BUIP to call the issue to a vote because they may be the only ones with the technical expertise to be able to do so. If a member who is not a regular contributor feels very strongly about a proposal or desires the organisation to vote on a proposal they may raise a BUIP for it.
I know that you know that quite literally every other line you wrote is either misleading or incorrect. My only question is why make a comment like that 3 months after the last post in the thread?