Skip to content
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

Multi-Algo - Defence against 51% attacks? #100

Open
wants to merge 9 commits into
base: 0.14.0
Choose a base branch
from

Conversation

nzsquirrell
Copy link

What's here is the foundation for migrating VTC to a multi-algo coin. History has shown this to be far more resilient to 51% attacks than a traditional single PoW algorithm.

What needs more time, attention, and discussion:

  1. Number of PoW algorithms. Currently 3, however 5 is a common choice for multi-algo. Need to balance between diluting hashrate across a larger set of choices vs complexity of launching an attack
  2. Choice of algorithms. I would continue with Lyra2rev3 (until ASICs are confirmed), other choices may include something like x21s. I believe a good balance would be something for each of NVidia and AMD miners. Possibility of including a CPU only algorithm?
  3. Difficulty adjustment algorithm and parameters. Currently coded with DGB's Multishield, however in testing I am not satisfied with it. I prefer Myriadcoin's method, where each PoW algorithm in completely independent of one another.
  4. Hardfork timing.
  5. Choice of bits in nVersion to encode algorithm. Could be changed to higher bits, freeing up low-bit numbers for versionbits

@ChillingSilence
Copy link

Very cool to see, and you've already done a lot of the leg work too. Kudos for the pull request!
Perhaps something like RandomX or SIGMA for CPU mining?

@dfischer
Copy link

dfischer commented Feb 1, 2021

Wouldn't this theoretically increase the risk of a 51% attack given attack vectors and unknown unknown's of a PoW's attack surface to an attack vector? Similar to the theoretic sides of cryptography on when it makes sense to combine methods vs not (rarely).

Not to shoot this down (cool idea) but what type of formalism can we use to at least semi-formalize this?

@vertiond vertiond mentioned this pull request Mar 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants