I know everyone is busy coding the necessary stuff for the last hard fork, but I think it would be great to at least start talking about post-hardfork future. I’m interested in hearing what you guys think would be a good thing to start tackling in January. I’ll start with my list:
Wallet simplifications and ease of use
Continue to fund wallet projects and making it easier for exchanges to adopt us. This could include extending the wallet API to allow more options for the mobile wallets
Privacy improvements
Research further how to improve privacy (payjoins, dandelion variants, hopefully also some new ideas)
PIBD improvements
Replay/play attacks
To sum it up, I think we should start tackling wallet and privacy improvements next.
Wallet simplification as well as looking for performance bottlenecks (to make mobile experience the best possible).
PIBD improvements, making PIBD default. Again to optimize every part of the Grin experience including syncing.
Further improvements in privacy, yes absolutely agree (payjoin would be best I think).
Better standardization within the project, e.g. automatic testing of code, easy to setup and use API’s with good documentation to stimulate ‘playing’ with Grin. This will foster the future developers for the project together with micro funds for tinkering projects and a reward based system to solve problems as well as rewards to find optimizations to make using Grin faster and smoother.
There has been many discussion about whether the council should invest in Grin or not. I am against using donated funds to invest in the value of Grin and use it to pay the core developers but I think Grin would be perfect to use for the reward system of small code improvements.
The answer to each of the points I made can be “yes”, but it depends on the solutions that are agreed on in the end. To clarify:
Wallet level changes don’t need a hardfork, we can extend the wallet API if needed
Privacy is about getting txs aggregated in a way that as few people saw the deaggregated txs. This happens outside of the consensus so if this is the way to improve privacy, then it can be done without touching the consensus
Afaik, the consensus changes needed for IBD will be finished in this last hard fork, from that point on, we won’t need to touch the consensus I believe
There exist both consensus and wallet level solutions for these, wallet level solutions don’t require a hard fork
I forgot to add 2-step research to the list. I think it would be good to continue checking on this front.
I think the difference would be that the stem node aggregation is automated and hard to opt-out. The hourly/daily aggregation service would be an opt-in thing I believe. I’m not sure if the two are different though
A daily aggregation server collects transaction during one whole day and broadcasts them as one aggregate at the end. (the ones that don’t fit having to wait for the next day).
when the volume increases it might have to wait for too many days to get included. I think it would be good to have a minimum required aggregation factor, eg. i send a tx and i want it to be mixed with aggregation factor 8 (let’s say this means it gets aggregated with 7 other txs) and when it’s done it’s automatically broadcasted. This would reduce the tx broadcast time significantly
That’s a valid point and i agree that it pretty much renders my idea useless. I feel like not many people would use it since i expect not many would want to wait 1 hour for tx to be broadcasted. Although some mixers do use X minutes to mix, so i might be wrong. Is there a way to make that aggregator trustless?
There’s no easy way. You would need assurances that the service is running particular software unmodified, perhaps using technologies such as Software Guard Extensions [1].
Google recently announced their “Confidential Computing” VMs [2]
that may provide some assurances as well.
