From dee1ccf7bbc5def39333633543420b4e5470fa3d Mon Sep 17 00:00:00 2001 From: DonFixi <38095284+DonFixi@users.noreply.github.com> Date: Mon, 14 Mar 2022 21:55:07 -0700 Subject: [PATCH 1/2] Create draft-Nuke'em.md --- qips/draft-Nuke'em.md | 58 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 qips/draft-Nuke'em.md diff --git a/qips/draft-Nuke'em.md b/qips/draft-Nuke'em.md new file mode 100644 index 0000000..03dc6a4 --- /dev/null +++ b/qips/draft-Nuke'em.md @@ -0,0 +1,58 @@ +--- +qip: 18 +title: "Distribution of ERC-20 Unmigrated Quanta to Active Nodes" +author: DonFixi (@DonFixi) +layer: meta +status: "draft/"Nuke'em" +comments_uri: ~ +created: 2022-03-14 +modified: 2021-03-14 +--- + +## Abstract + +To incentivise node running decentralisation while reducing a side-attack Quantum Computing (QC) minor risk. + + +## Motivation + +Still there almost half million of unmigrated Quanta as per address Q010500e587fd07bb1c5ace98956d9aa6c347e7114ccb4ec7183baa54804cc8b974e91cc3b5617e + +These native QRL tokens are exchangable for QRL ERC-20 tokens as per initial 2017 ETH from the contract set 0x697beac28B09E122C4332D163985e8a73121b97F at 1:1 ratio. + +There was an atutomatic migration window the team deployed back in 2017, that was closed 4 years ago. + +To migrate them today, there is a non-public disclosed manual migration proccess which involves the ERC-20 owner to stablish communication with qrl.foundation + +As QC grows, and ETH and ERC remains vulnerable to factorization algorithms such as Shor's, there is a minor chance that a malicious actor with access to powerfull QC would try to breach one, if not several, QRL ERC-20 in near future. + +Hereby, since its been 4 years already, I do propose here a fair QRL re-distribution of these non-claimed Quanta funds to all active node peers in the QRL chain. + + +## Specification + +Mathematicak Distribution Model TBD - could be X per block/luck, a simple decay curve, per uptime running, or a combiantion. + +## Rationale + +The idea is to one mitigate once for all QC risk, and two, promote node running. + +Specially node running on low power devices such a Raspberry Pi, until Proof-of-Stake arrives and beyond. + +## Backward compatibility + +Those that dont migrate their ERC-20 on a set time, though luck. + +A liability study shall be studied before this QIP passes. + +The "Robin Hood Effect", may not land equally for those who still have ERC-20 under control. + +## Implementation + +A hard-fork will likely be required in order to set the new distributive model for the unmigated address. + +## Security Considerations + +This QIP suggest the mitigation of an external QC side-attack while promoting and incetivising a healthy quanta redistribution for the active participants. + +Nuke from orbit--it's the only way. \ No newline at end of file From 858a6ad3bc4c06eb1fae2d8f1926660d6b3454d7 Mon Sep 17 00:00:00 2001 From: DonFixi <38095284+DonFixi@users.noreply.github.com> Date: Mon, 14 Mar 2022 22:40:33 -0700 Subject: [PATCH 2/2] Update draft-Nuke'em.md --- qips/draft-Nuke'em.md | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/qips/draft-Nuke'em.md b/qips/draft-Nuke'em.md index 03dc6a4..5d64ad0 100644 --- a/qips/draft-Nuke'em.md +++ b/qips/draft-Nuke'em.md @@ -1,55 +1,54 @@ --- qip: 18 -title: "Distribution of ERC-20 Unmigrated Quanta to Active Nodes" +title: "Re-Distribution of ERC-20 Unmigrated Quanta to Active Nodes" author: DonFixi (@DonFixi) layer: meta status: "draft/"Nuke'em" comments_uri: ~ created: 2022-03-14 -modified: 2021-03-14 --- ## Abstract -To incentivise node running decentralisation while reducing a side-attack Quantum Computing (QC) minor risk. +To incentivise node running decentralisation while reducing an external enginnered side-attack Quantum Computing (QC) minor risk. ## Motivation -Still there almost half million of unmigrated Quanta as per address Q010500e587fd07bb1c5ace98956d9aa6c347e7114ccb4ec7183baa54804cc8b974e91cc3b5617e +There is almost half million of unmigrated Quanta as per address Q010500e587fd07bb1c5ace98956d9aa6c347e7114ccb4ec7183baa54804cc8b974e91cc3b5617e -These native QRL tokens are exchangable for QRL ERC-20 tokens as per initial 2017 ETH from the contract set 0x697beac28B09E122C4332D163985e8a73121b97F at 1:1 ratio. +These native QRL tokens are exchangable for QRL ERC-20 tokens as per initial 2017 ETH from the ERC contract 0x697beac28B09E122C4332D163985e8a73121b97F at 1:1 ratio. -There was an atutomatic migration window the team deployed back in 2017, that was closed 4 years ago. +There was an atutomatic migration QRL ERC-20 -> Quanta window that the team deployed back in 2017. That window was closed 4 years ago. -To migrate them today, there is a non-public disclosed manual migration proccess which involves the ERC-20 owner to stablish communication with qrl.foundation +To migrate them today, there is a non-public disclosed manual migration proccess which involves the QRL ERC-20 owner to stablish communication with the QRL foundation. -As QC grows, and ETH and ERC remains vulnerable to factorization algorithms such as Shor's, there is a minor chance that a malicious actor with access to powerfull QC would try to breach one, if not several, QRL ERC-20 in near future. +As QC grows, ETH and ERC remains vulnerable to factorization algorithms such as Shor's, there is a minor chance that a malicious actor with access to powerfull QC would try to breach one, if not several, QRL ERC-20 in near future. -Hereby, since its been 4 years already, I do propose here a fair QRL re-distribution of these non-claimed Quanta funds to all active node peers in the QRL chain. +Hereby, since its has been 4 years already, I do propose here a fair QRL re-distribution of these non-claimed Quanta funds to all active node peers in the QRL chain. ## Specification -Mathematicak Distribution Model TBD - could be X per block/luck, a simple decay curve, per uptime running, or a combiantion. +Mathematical Distribution Model TBD - could be X per block/luck, a simple decay curve, per uptime running, or a combiantion. ## Rationale -The idea is to one mitigate once for all QC risk, and two, promote node running. +The idea is to one, mitigate once for all external QC risk, and two, promote node running. -Specially node running on low power devices such a Raspberry Pi, until Proof-of-Stake arrives and beyond. +Specially for those running low power node devices such a Raspberry Pi, until Proof-of-Stake arrives and beyond 🚀 ## Backward compatibility -Those that dont migrate their ERC-20 on a set time, though luck. +Those that don't migrate their QRL ERC-20 tokens from ETH chain on a set time, well though luck. -A liability study shall be studied before this QIP passes. +A liability study shall be conducted before this QIP passes or pushes the final "burning" code. -The "Robin Hood Effect", may not land equally for those who still have ERC-20 under control. +The "Robin Hood Effect" may not land equally for those who still have QRL ERC-20 tokens under control. ## Implementation -A hard-fork will likely be required in order to set the new distributive model for the unmigated address. +A hard-fork will likely be required in order to set the new distributive model for the unmigrated address. ## Security Considerations