Beyond last hard fork

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.

7 Likes

Good list.

Can we still do those things without a (new) hardfork?

Fully agree with your list @oryhp .

  1. Wallet simplification as well as looking for performance bottlenecks (to make mobile experience the best possible).
  2. PIBD improvements, making PIBD default. Again to optimize every part of the Grin experience including syncing.
  3. Further improvements in privacy, yes absolutely agree (payjoin would be best I think).
  4. 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.
  5. 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:

  1. Wallet level changes don’t need a hardfork, we can extend the wallet API if needed
  2. 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
  3. 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
  4. 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.

1 Like

Yes! Always good to start talking about the next step early! Good list! :+1:

Would be nice to develop software for a transaction aggregation service, and run instances at hourly.grin.mw and daily.grin.mw

We would finally see some serious aggregation.

1 Like

Agree, but I do wonder whether it would be legal to run and/or participate in this

Seems just as legal as stem nodes aggregating,
or as miners aggregating…

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

But it is centralized, so trivial to target if it is determined to be illegal in some way

what does daily and hourly mean here? it’s probably not the aggregation time right?

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

When the volume increases that much you’d switch from the daily to the hourly service. Or even a more fine-grained one.

It would also allow someone knowing the approximate time of your tx to inject a few dozen tx of their own so as to be able to de-aggregate yours.

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?

If you wanted to unlink your output, you could do a self spend to daily aggregated service. Is it worth waiting? For some, probably

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.

[1] https://en.wikipedia.org/wiki/Software_Guard_Extensions
[2] https://cloud.google.com/confidential-computing