Ecosystem/gupaxx
1
0
Fork 0
mirror of https://github.com/Cyrix126/gupaxx.git synced 2024-12-22 14:49:21 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

feat: update ideas

Browse source
This commit is contained in:
Cyrix126 2024-10-09 11:03:53 +02:00
parent e1241b3e20
commit 9d1afe9ebc
1 changed files with 21 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

42
IDEAS.md
View file

@ -5,15 +5,14 @@
Some ideas could be done in a matter of hours, some could take months. Some ideas could be done in a matter of hours, some could take months.
## More Decentralized ## More Decentralized
### Integrate a Monero Node
Started by [Cyrix126](https://github.com/Cyrix126)
If we want Gupaxx to help user mine in the most decentralized way, we should offer them to run a monero node.
This would be optional and would check if the requirement are fulfilled before enabling the button to do so.
### Synchronize source code repository on p2p network ### Synchronize source code repository on p2p network
Github is proprietary. If Gupaxx aims to be free, it should not be only available on this platform and we should explore options to get github free. Github is proprietary. If Gupaxx aims to be free, it should not be only available on this platform and we should explore options to get github free.
We can use [Radicle](https://radicle.xyz/) to get Gupaxx on a p2p collaboration stack. We can use [Radicle](https://radicle.xyz/) to get Gupaxx on a p2p collaboration stack.
The code, issues and PR could be synchronized with Github. The code, issues and PR could be synchronized with Github.
### Integrate a Monero Node
[Done](https://github.com/Cyrix126/releases/tag/v1.5.0)
If we want Gupaxx to help user mine in the most decentralized way, we should offer them to run a monero node.
This would be optional and would check if the requirement are fulfilled before enabling the button to do so.
## More User friendly ## More User friendly
### Website ### Website
@ -25,6 +24,7 @@ It could be an option to ask at first start.
The user could access this wallet on the same computer with the official GUI wallet. The user could access this wallet on the same computer with the official GUI wallet.
### Auto register to XvB ### Auto register to XvB
If Gupaxx could register the user automaticcly to the raffle, it would remove a manual step for the user. If Gupaxx could register the user automaticcly to the raffle, it would remove a manual step for the user.
Automatic registration could be done to prevent spam by checking if the registred address is in p2pool window or by giving a small HR to XvB.
It could be an option to ask at first start. It could be an option to ask at first start.
### Setup Guide ### Setup Guide
At first start, a guide could ask the user what it intends to do with Gupaxx (create node, create wallet, use xmrig-proxy, participate in raffle...) and do the setup for him and show him what it must do manually. An option to skip this guide would be present for advanced users. At first start, a guide could ask the user what it intends to do with Gupaxx (create node, create wallet, use xmrig-proxy, participate in raffle...) and do the setup for him and show him what it must do manually. An option to skip this guide would be present for advanced users.
@ -40,6 +40,9 @@ Add on README a table with minimum hardware/software requirements.
Gupaxx could add support for linux arm64 since p2pool and xmrig can compile on this target. Gupaxx could add support for linux arm64 since p2pool and xmrig can compile on this target.
### Refactor size of text ### Refactor size of text
Gupax/x currently resize texts/widgets based on the window size. Instead, the text/widget size should be decided by the OS/config, scroll bar should be used when there is not enough space. It will allow to use Gupaxx on different ratio of screen. Gupax/x currently resize texts/widgets based on the window size. Instead, the text/widget size should be decided by the OS/config, scroll bar should be used when there is not enough space. It will allow to use Gupaxx on different ratio of screen.
### CLI for Algorithm
A simple script or a small binary could be made to reproduce the algorithm who would take args for every other needed programs.
This script would need arguments to know how to control xmrig/xmrig-proxy and where to watch p2pool data plus the XvB token and xmr address.
## More Powerful ## More Powerful
### Optimization for xmrig ### Optimization for xmrig
@ -47,27 +50,24 @@ Gupax/x currently resize texts/widgets based on the window size. Instead, the te
On linux, we can activate 1GB pages after detecting cpu flags. We can also add cpu affinity option. On linux, we can activate 1GB pages after detecting cpu flags. We can also add cpu affinity option.
#### Manual optimizations #### Manual optimizations
On the XMRig tab, inform users about manual optimizations that Gupaxx can't control. For example, disabling hyper-threading in BIOS is recommended. On the XMRig tab, inform users about manual optimizations that Gupaxx can't control. For example, disabling hyper-threading in BIOS is recommended.
### CLI for Algorithm ### Watch Stratum Data instead of estimate.
A simple script could be made to reproduce the algorithm who would take args for every other needed programs. Right now, the algorithm estimate the eHR with the estimation made by the p2pool instance which is calculating from passed shares.
Gupaxx itself doesn't have any features that bundled programs don't offers. The algorithm could instead watch the stats from the stratum server, which is more precise but would take into account only miners which are pointed to it.
#### Integrate XMRig-Proxy The algorithm would still check the estimation made by the p2pool instance of Gupaxx and warn the user if it seems there is too much difference between the data of the stratum server and the one of p2pool. It could prevent the user to forget to configure a miner to the stratum p2pool.
Could also be an option in advanced tab of XvB warning the user that he should point all his miners to the p2pool instance of Gupaxx to take them into account.
It can be a checkbox into advanced option of XvB to use the stratum data.
### Manually set HR for XvB algo
Done by [Sina](https://github.com/mostafaei2002) [PR](https://github.com/Cyrix126/gupaxx/pull/11)
An advanced tab on XvB tab with multiple tools to set the HR manually.
The user can sometime better know the right decision from his HR than the algo that will take more time to get everything right, specially if resources are changing.
### Integrate XMRig-Proxy
[Done](https://github.com/Cyrix126/gupaxx/releases/tag/v1.2.0) [Done](https://github.com/Cyrix126/gupaxx/releases/tag/v1.2.0)
The algorithm of distribution of HR can't control HR outside of his instance. The algorithm of distribution of HR can't control HR outside of his instance.
It must estimate external HR, which can be approximative. It must estimate external HR, which can be approximative.
If a user control multiples miners, it could connect all of them to a xmrig-proxy instance. If a user control multiples miners, it could connect all of them to a xmrig-proxy instance.
Gupaxx could offer this xmrig-instance and control it like it was a normal xmrig instance. Gupaxx could offer this xmrig-instance and control it like it was a normal xmrig instance.
OR ### Wait for sync to start of xmrig
#### Watch Stratum Data instead of estimate. If p2pool/node is not yet synced, xmrig can slower them and mine for nothing if it start at the same time. We don't want to prevent the user to start xmrig without p2pool, so xmrig could start later only if p2pool is auto started.
Right now, the algorithm estimate the eHR with the estimation made by the p2pool instance which is calculating from passed shares.
The algorithm could instead watch the stats from the stratum server, which is exact but would take into account only miners which are pointed to it.
Miners using the cli xmrig could point their miners to the p2pool instance of Gupaxx, or have an identical option if they are using the CLI of the algorithm.
The algorithm would still check the estimation made by the p2pool instance of Gupaxx and warn the user if it seems there is too much difference between the data of the stratum server and the one of p2pool. It could prevent the user to forget to configure a miner to the stratum p2pool.
Could also be an option in advanced tab of XvB warning the user that he should point all his miners to the p2pool instance of Gupaxx to take them into account.
### Manually set HR for XvB algo
Done by [Sina](https://github.com/mostafaei2002) [PR](https://github.com/Cyrix126/gupaxx/pull/11)
An advanced tab on XvB tab with multiple tools to set the HR manually.
The user can sometime better know the right decision from his HR than the algo that will take more time to get everything right, specially if resources are changing.
## Trust-less ## Trust-less
## Builds ## Builds