[This is all with the understanding that I am walking straight into the middle of various active conversations around the funding of contribution to the grin project. I am only speaking for myself here.]
January was an unpaid “sabbatical” and I was not actively involved or contributing in any meaningful way. I was originally going to request a shortened two month period of funding for Feb/Mar to sync back up with the quarterly schedule. Given the somewhat heated and ongoing discussion around deliverable based funding vs. time based funding I am rethinking this. I am requesting funding based on successful delivery of a couple of new features. I think there is the opportunity for alignment here with some uncertainty around how much time I can dedicate to grin over the next couple of months. I would like to experiemt with this if people are in agreement.
Short summary of the features I am considering (across wallet and node) -
- Full archive node (full historical block archive)
- This has been a requested feature since the early days (Full chain archive sync at protocol level · Issue #3092 · mimblewimble/grin · GitHub)
We support enabled/disabled features and p2p protocol versioning and I think it is entirely feasible to introduce opt-in support for serving up historical blocks via the existing block p2p message. We sync recent blocks during IBD, this can be extended to “in the background” sync all historical blocks from peers that advertize support for this. It may not be fast and it may not be a perfect solution initially, but I think there is value there in aiming to support this feature.
- Wallet “late locking” improvements -
- support transaction pre-generation prior to having funds available (v5 - Wallet - Late locking - pre-generate transaction not working correctly · Issue #541 · mimblewimble/grin-wallet · GitHub)
- granular “coin control” in the context of “late locking” (Add ability to select outputs for send · Issue #529 · mimblewimble/grin-wallet · GitHub)
The two wallet related features are I think good candidates for deliverable based funding. They are relatively self-contained and hopefully small enough chunks of work to see through to completion in a constrained amount of time.
My intention would be to continue to work on improving the codebase, general maintenance, cleanup, testing, etc. in addition to delivering the above feature(s). I would preferably like to account for this in the funding request, but not necessarily call these activities out as separately funded items. I think we need to discuss approaches to this.
All of this leads to the queston of assigning “value” to these deliverables. In the interest of keeping everything as simple as possible and in an attempt to avoid getting into endless conversations around relative values I’d like to propose the following -
- late locking pre-generation of transactions: 5k EUR
- late locking coin control: 5k EUR
- full archival node support: 10k EUR
The intent here would be for payment on successful completion of a given task with the understanding that having “claimed” these tasks in advance (for the specified period of time) that these are not “open bounties” available for others to claim.
And to be clear, “delivery” here is not just writing the code and would cover testing, evaluation, revision/rework, documentation, rollout etc. Presumably we would want to define success criteria reasonably explicitly as part of this.
I believe these numbers provide a starting point for the discussion. This would take into consideration the various ongoing tasks and activities that I would continue to be involved in and contribute to. The expectation would be that this is not an exhaustive list of what I would be working on over the next couple of months.
I believe the next governance meeting is on Tuesday. I’d like to set some time aside in that meeting to at least start a discussion on this. I believe we ask for at least 7 days notice before making funding decisions, so not expecting a final decision on Tuesday.