I would like to request funding to allow me to continue working full time on Grin.
This request is for a standardized monthly “yeast unit” for a period of 3 months (April to June 2020) at €10k/month.
I have been involved in Grin since mid 2017, initially unfunded and on a purely voluntary basis.
My first PR on Grin was back in Aug 7, 2017 - https://github.com/mimblewimble/grin/pull/87
Approximately 12 months ago an opportunity for external funding arose, allowing me to focus on contributing to Grin.
This opportunity has now ended and I am making this request to allow me to continue.
I would like to see payment channels (think Lightning or similar) built on Grin and one thing preventing this today is a robust “relative locktime” implementation.
My aim over the next few months is to continue focusing on this problem and to get the “No Recent Duplicate” (NRD) kernel proposal finalized, implemented and released as part of the scheduled hardfork in 4.0.0. This involves consensus breaking changes and we want to take advantage of the next scheduled hardfork to deploy this.
We have spent a significant amount of time over the past 12 months thinking through and considering various approaches to relative locktimes.
There are many ways this could be implemented, most of them a poor fit for Grin, specifically around data requirements and our ability to prune historical data.
We do not want to affect the prunability of Grin when adding new features.
We believe NRD kernels provide significant benefits while preserving this core tenet of Grin and Mimblewimble in general.
With NRD kernels we can enforce relative locks between kernels with minimal network, local storage and validation overhead.
Deliverables -
Final “relative timelock” RFC based on NRD kernels
NRD kernel implementation
Rollout/Release planning, specifically related to consensus breaking changes for 4.0.0 HF
Note that this is not intended as an exhaustive list. My involvement in general Grin development, discussions and PR reviews etc. will continue as before.
Considering that we are obbiously very far from needing lightening network, wouldn’t other prioritizations be relevant here to discuss at this point in time of the life of grin ?
A lot of forum threads and discussions have recently been focused on grin usability.
working on this (and probably also other things I forgot or do not see) is probably a higher priority than NRD kernel implementation at this point in time?
I personally do not have a fully strong opinion, but I thought it would be nice if we could gather more opinions from the community here on priorities for grin
Considering that we are obbiously very far from needing lightening network, wouldn’t other prioritizations be relevant here to discuss at this point in time of the life of grin ?
Yep, I can see why it may seem strange for the focus to be there. The logic is that we have only two scheduled hard forks left, one of which has a scope freeze in less than a week. We have no other way right now to introduce consensus breaking changes.
So while improving usability is certainly a very high priority, I for one consider consensus-breaking changes higher right now. Usability can continue to be improved even after the hard forks finish, if that makes sense.
I propose to open a window for hardfork every four years. problem fixed (we wont need lightening within the next 4 years).
Many other approaches can fix this problem which isn’t really one.
So I still maintain the point…
But that’s it. Up to you guys to decide
We’re definitely open for ideas on how to properly manage hard forks.
You were in attendance of the meeting where we discussed it in depth, right?[0] I think a lot of the concerns hold, there are trade-offs between being able to upgrade the network easily and centralisation. It doesn’t seem like there’s one obvious approach, and opinions are split.
If you want to, would be glad to have your help coming up with a full circled proposal that covers execution details etc. Let me know.
Yep I remember that discussion. Despite nothing was written on the rock at the end of the meeting/discussion I had the feeling that pretty much everybody thought that consensus hard fork will be necessary after the 4 scheduled HF (even John Tromp was not totally against it :))
Given that there are some concerns that progress toward a payment channel implementation is maybe not the most important area of focus right now, I’d like to gauge support for potentially altering this proposal.
I do think “standardized transactions” is in very capable hands right now and I don’t think I would add a lot of value.
The other usability related effort that has stalled recently is IBD performance during initial sync.
We made changes as part of 3.0.0 to facilitate this (RFC and related PR) but we are not yet taking advantage of this.
Do people think this would be more valuable to focus on, rather than “NRD kernels”? I’d like to gauge opinion here. To be clear this is not intended to be a vote or popularity contest.
Are there other areas that might be worth exploring with a possibility of focus?
What about finishing up Atomic Swap and work with GUI wallet developers (David and Xiaojay typically) to make it usable by people?
It feels like that GRIN is an “unfinished” coin, with tx method standardization not there yet, with no GUI wallet involving professional designers and UX people.
By finishing up Atonic Swap we could make GRIN have a nice usecase and attract more members from the Bitcoin or Ethereum community that would be interested to use grin to wash their coins.
Can also improve OTC trading
I’m a die hard fan of payment channels and the lightning network, I’m in full support of some kind of implementation of them on top of Grin. I fill like it’s some kind of mandatory requirement for any cryptocurrency today. So I’m definitely happy that you propose to work on it @antioch
I don’t really care for any fancy UI things at the moment.
One thing is that relative kernel has not been reviewed by the broader crypto community yet, hopefully it will soon. I recall Andrew Poelstra having said something around that there were no natural way to do them, on reddit, so it sounds a tricky problem.
Antioch seems to foresee that implementing this in production will take a few months so we could probably explore the possibility to do this a few months before HF4 instead with the great advantage that there is more time for the ideas to mature and to be reviewed.
Improving the usability doesnt necessarily involves fancy GUI things at this stage of the life of grin, but things in the code core code or wallet can be done to that goal.
Otherwise having at least everything ready for the Atomic Swap is something that has nice practical benefits in term of usecase
I do agree with @Kurt that NRD has not been reviewed by many (can’t talk about reviews done in private). I think having an actual RFC would bring some more readers, more attention and would encourage others to find possible problems or just get a better feeling that it would work and enable lightning. I’d suggest working on this RFC and then switching to other tasks if the community prefers other improvements, but I’d at least start on NRD so that people get familiar with the idea and have some time to think about it and comment on it so that it is not rushed.
While there are a few things I would be thrilled to see implemented, I understand the urgency of introducing as many consensus breaking changes as possible and layer 2 support is quite mandatory for grin to be capable of supporting any kind of adoption. I think whatever kind of relative lock kernel system you decide upon is valuable to focus on.
I appreciate the new possibilities being created, especially on the security front and how minimizing the slate can allow devs to be more creative. However, I dont think we can really refer to anything as “standardized transactions” until we have something that is not significantly more difficult to send/deposit than receive/withdraw (unless one of them is frictionless, like one-sided txs) AND this process is the same for any parties transacting. User-to-user, especially mobile-to-mobile but really any device, is going to likely be a different experience than the one to service providers/retailers/pools/etc.
I haven’t been vocal on next-gen mining ideas like BetterHash, stratum v2, etc. I think these are very powerful and empowering as well (voting mechanisms would be much better). One of many articles BetterHash: Decentralizing Bitcoin Mining With New Hashing Protocols | by StopAndDecrypt | HackerNoon.com | Medium for anyone who wants to learn a little more. I have also become more interested in DAG structures after the first few DAGs I learned about gave me a very bad impression. Unfortunately, both of these things would be consensus changing and not likely to be implemented by v5.0.0. I dont intend on sounding like we should copy beam on everything, but it may be that cooking grinbox into grin node (a la SBBS) might be the best option for e2ee and standardized tx for the short term prospects. Also, Vlad’s method of one-sided txs (similar to ignos), with pre-determined denominations, could be useful to investigate. They are not entirely ideal, but very useful for store fronts/vendors and also useful for mining pool payouts.
For usability, we do need kernel changes such as Lightning support so I am in favour of @antioch working on them (High priority). Then, with good colleboration with wallet developers, a mobile App with Lightning support could be made, greatly increasing usability of GRIN (High priority). Atomic swap should also be part of layer 2 supported by GRIN since indeed it is a great asset to any privacy coin (Medium priority). In general, payment with GRIN should be as easy as with any other cryptocurrency, which is currently not the case. Hence my great respect also goes out to GUI wallet developers like @david since they are as essential to GRIN usability as developers working on the core.
