I am currently funded through until the end of June (previous funding request).
I would like to request a further 3 months of funding to cover July through to September.
This would be for the standard yeastunit of €10k/month.
I have been almost exclusively focused on Grin node over the past few months, specifically NRD kernel support and ongoing work on node stability and performance etc.
I am looking to shift my focus a little over the next few months and spend at least a portion of my time with Grin wallet.
There are a few wallet features under discussion that I would like to get involved with and put some time toward.
- “mostly” lock free transactions
- PayJoin aka Pay-To-EndPoint (P2EP)
- multi-party outputs for Succint Atomic Swaps
- Payment channel implementation (leveraging NRD relative locks and multi-party outputs)
These all share some commonality, specifically around the interactive transaction building process, fine-grained control over output selection and kernel offset adjustments.
We currently support a relatively limited and “simplified” single-round transaction building protocol, supporting a single sender and a single receiver. (1) and (2) require more flexible output selection and flexibility of kernel offset adjustments. (3) and (4) actually require a different and more complex transaction building protocol. We need support for “three-round” musig with secure communication of random nonce values etc.
We will likely not implement all of these in the next few months but I would like us to be thinking about them collectively and to ensure we do not implement one at the expense of making subsequent changes harder.
So while I was focused on activating NRD kernel support at the node p2p protocol layer (on floonet for testing) for HF3 I suspect my HF4 focus will shift to wallet related support for musig and improved transaction building flexibility.
It will be interesting to see what we can do with the Grin wallet to support this additional complexity while keeping the UI/UX as simple and robust as possible.
Alongside this shift in focus toward wallet I’m also aiming to continue spending time on node itself.
We have one final scheduled hardfork at the end of the year. We want to ensure we are ready for this, both taking advantage of this final hardfork to make any necessary protocol changes and to prepare Grin for what happens beyond HF4.
I am aiming to stay involved in the ongoing “Parallel IBD” work that will add significant improvements to the initial Grin experience, in terms of both stability and performance.
Edit: This post makes the assumption that we require musig support to be able to support multi-party outputs securely. This is not necessarily true and we need to spend time investigating this further. @tromp suggested in keybase that we may be able to continue using “naive Schnorr” and we need to convince ourselves of this. So please treat any reference to musig above as a loose term for Schnorr signatures in general.
We may be able to avoid the additional complexity of musig if we are careful.