-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mainnet compatibility #713
Milestone
Comments
This was referenced Mar 14, 2023
Merged
4 tasks
The documentation of known issues should be more present and compliant legal. Also, we need to ensure to revert an accidentally removed known issue/workaround: https://github.com/input-output-hk/hydra/pull/795/files#r1152936796 |
ghost
removed their assignment
Apr 7, 2023
ghost
added
green 💚
Low complexity or well understood feature
and removed
amber ⚠️
Medium complexity or partly unclear feature
labels
Apr 25, 2023
Internal review of known issues in progress |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Why
As a user of Hydra I would like to use real Ada in a Hydra head.
As the Hydra team it would demonstrate the maturity of the product. It would be an opportunity to get feedback from users using it for real.
This could (or not) unleash potential adoption and experiments.
It could also raise interest into people wanting to assess actual mainnet Hydra heads security (it's not a hack, it's a pentest).
Anyway, let's see what surprises it could bring.
What
Currently, Hydra software would only run on preview network. It prevents testers from shooting themselves in the foot in case of problematic situation at this stage of development. Which made sense while this project was still named hydra-poc.
We should keep in mind the idea of limiting the risk for people to shoot themselves in the foot. In the meantime, we should not prevent people to make experiments with Hydra on main net once they're happy with what they've seen on preview.
Make it technically feasible to run on mainnet
Risk limitation features
In the same way lightning used to have a hard-coded limit of 4,390,000 satoshis, we might consider introducing a hard-coded limit for the amount of Ada one can lock with a commit transaction. Today we are only limiting the number of UTxO allowed in a commit. We could consider adding a hard-coded limit on the quantity of Ada in this UTxO. We don't need to enforce that on-chain. Enforcing that in the hydra-node software would be good enough. If one wants to change this limit, recompile and run it, they take their chances.
Known issues we're ok with
There will be a set of known issues/out of scope items. We make sure that the issues are documented, explained why we are okay with these known issues and in general that users are informed we are releasing a beta product, that we will be continuously fixing them (until it's not beta anymore?). We should try to turn the argumentation on it's had that we are happy to be exploited as we can learn from any successful hacks.
Known issues and a list of things we likely see not part of the first mainnet beta release:
How
The text was updated successfully, but these errors were encountered: