From 8065da8decd3ef29100dddbd79d0600f97b3a8d6 Mon Sep 17 00:00:00 2001 From: nikvladan Date: Sun, 4 Oct 2020 17:33:56 +0200 Subject: [PATCH 1/3] my test template change on zenip --- testtemplate.md | 97 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 testtemplate.md diff --git a/testtemplate.md b/testtemplate.md new file mode 100644 index 0000000..896dcfe --- /dev/null +++ b/testtemplate.md @@ -0,0 +1,97 @@ +# ZenIP Template + +*If this is your first time writing a ZenIP, the structure and format may look intimidating. But really, it's just meant to reflect common-sense practice and some technical conventions. This template is meant to be a starting point for you to structure your ideas. It might help to sort the different aspects of your proposal into the structure below in order get your idea across efficiently. The community and ZenIP editors will help you figure things out and get your proposal into a proper shape later.* + +## Header Preamble + + ZenIP: Unassigned (numbers are assigned by ZenIP editors) + Title: *Something Short and To the Point* + Owners: First Owner + ... + Status: Draft + Category: (Consensus | Standards Track |Informational | Process) + Created: yyyy-mm-dd + License: MIT (see the licensing section of ZenIP-42000) + +## Table of Contents + +*Please always include a table of contents, e.g.* + +## Terminology + +The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to +be interpreted as described in [RFC 2119](#references). + +The terms below are to be interpreted as follows: + +- Term to be defined today + - definition +- Another term + - another definition + +## Abstract + +*Describe what this proposal does, typically in a few paragraphs.* + +The Abstract should only provide a summary of the ZenIP; the ZenIP should remain complete without the Abstract. +Use links where applicable, e.g. [[3]](#references). + +## Motivation + +*Why is this proposal needed?* + +This is one of the most important sections of the ZenIP, and should be detailed +and comprehensive. It shouldn't include any of the actual specification - +don't put conformance requirements in this section. + +Explain the status quo, why the status quo is in need of improvement, +and if applicable, the history of how this area has changed. Then describe +*at a high level* why this proposed solution addresses the perceived issues. +It is ok if this is somewhat redundant with the abstract, but here you can +go into a lot more detail. + +## Requirements + +*Describe design constraints on, or goals for the solution -- typically one paragraph for each constraint or goal.* + +Again, don't actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements. + +## Non-requirements + +*This section is entirely optional. If it is present, it describes issues that the proposal is **not** attempting to address, that someone might otherwise think it does or should.* + +## Specification + +*This section describes what should change, using precise language and conformance key words.* + +Anything that is *required in order to implement the ZenIP* (or follow its +process, in the case of a Process ZenIP) should be in this section. + +Avoid overspecification! Also avoid underspecification. Specification is hard. +Don't be afraid to ask for help. +Unless the specification is particularly simple, you will need to organise it under +subheadings. + +### Example Subheading + +At least while the ZenIP is in Draft, we encourage writing open questions and TODOs. + +#### Open Questions + +- What do hackers do on a boat? + +TODO: define byte encoding for the phishing trip. + +Feel free to copy from other ZenIPs doing similar things. + +## Reference Implementation + +This section is entirely optional; if present, it usually gives links to PRs. + +## References + +[1] ZenIP-42000 - https://github.com/HorizenOfficial/zenips/blob/master/zenip-42000.md/#zenip-licensing + +[2] RFC2119 - Key words for use in RFCs to Indicate Requirement Levels https://tools.ietf.org/html/rfc2119 + +[3] Example reference From 609872296ceb1e31dc4fc977eeeb2441a1712f96 Mon Sep 17 00:00:00 2001 From: nikvladan Date: Sun, 4 Oct 2020 17:54:47 +0200 Subject: [PATCH 2/3] My proposal for better reward distribution after Horizen halving --- trololino-zenip-distributionrewards.md | 73 ++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 trololino-zenip-distributionrewards.md diff --git a/trololino-zenip-distributionrewards.md b/trololino-zenip-distributionrewards.md new file mode 100644 index 0000000..b665da8 --- /dev/null +++ b/trololino-zenip-distributionrewards.md @@ -0,0 +1,73 @@ +# ZenIP Template + +*If this is your first time writing a ZenIP, the structure and format may look intimidating. But really, it's just meant to reflect common-sense practice and some technical conventions. This template is meant to be a starting point for you to structure your ideas. It might help to sort the different aspects of your proposal into the structure below in order get your idea across efficiently. The community and ZenIP editors will help you figure things out and get your proposal into a proper shape later.* + +## Header Preamble + + ZenIP: Unassigned (numbers are assigned by ZenIP editors) + Title: *Something Short and To the Point* + Owners: nikvladan(Alias Trololino) lordhakkira@yahoo.com + ... + Status: Draft + Category: (Consensus | Standards Track |Informational | Process) + Created: 2020-10-04 + License: MIT (see the licensing section of ZenIP-42000) + +## Table of Contents + +-Terminology +-Abstract +-Motivation +-Requirements +-Specification +-References + +## Terminology + +The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to +be interpreted as described in [RFC 2119](#references). + +The terms below are to be interpreted as follows: + +- Term to be defined + - definition +- Another term + - another definition + +## Abstract + + +This proposal suggests a change in daily distribution of Horizen rewards and changing requirements for hosting secure nodes and supernodes. Specifies a time when this change should activate. + + +## Motivation + + +After Horizen halving which will happen in approximately 58 days from today, rewards for holders that host secure nodes and supernodes will reduce in half. Due to price of Zen dropping so low as to bellow 5.3$ as it is at this moment of writting this project, hosting secure nodes as well as supernodes will become unprofitable. +Secure nodes and super node owners pay for hosting each month (as well as domain name each year for supernodes). Increased rewards have to come from somewhere, and in this proposal its suggested they are taken from miners. Ever since Q1 2018 when ASIC miners first appeared on Equihash network, they have been decreasing the price of Zen without any sign of stopping. This will also decrease their selling pressure on the markets, as well as halving event. As for security, measures are implemented to aid against 51% attack already. Additional measures can be taken, but this is not the point i want to discuss in this proposal. +Horizen fauced which has been mentioned a lot of times in weekly/quarterly reports and streams is irrelevant atm and rewards are not even worth opening the page. Making some of the rewards go directly to Horizen faucet will get a lot of people involved in ZEN, who don't have any means of buying ASIC miners, and will increase the community involvement. + +## Requirements + +For this proposal, I assume hard fork is needed to redistribute the rewards. Hard fork would happen right after the halving (71 days from now). +Requirements for hosting secure nodes will rise accordingly: +1) 84 ZEN for secure nodes, +2) and 1000 ZEN for SuperNodes. + + +## Specification + +After Halving event, daily inflation on Horizen network will drop to 3600 ZEN. I propose the rewards be distributed in following manner: +1) 20% (720 ZEN) to the team for development purposes +2) 20% (720 ZEN) to secure nodes (same as it is now before halving) +3) 20% (720 ZEN) to super nodes (same as it is now before halving) +4) 35% (1250 ZEN) to miners for securing the network, +5) 5% (180 ZEN) directly to zen faucet to get new community members. + +## References + +[1] ZenIP-42000 - https://github.com/HorizenOfficial/zenips/blob/master/zenip-42000.md/#zenip-licensing + +[2] RFC2119 - Key words for use in RFCs to Indicate Requirement Levels https://tools.ietf.org/html/rfc2119 + +[3] https://github.com/HorizenOfficial/ZenIPs/blob/master/zenip_template.md From 636dce1926479bfb9eef1089884980330e9c7604 Mon Sep 17 00:00:00 2001 From: Trololino Date: Sun, 4 Oct 2020 17:57:50 +0200 Subject: [PATCH 3/3] Delete testtemplate.md It was just a test --- testtemplate.md | 97 ------------------------------------------------- 1 file changed, 97 deletions(-) delete mode 100644 testtemplate.md diff --git a/testtemplate.md b/testtemplate.md deleted file mode 100644 index 896dcfe..0000000 --- a/testtemplate.md +++ /dev/null @@ -1,97 +0,0 @@ -# ZenIP Template - -*If this is your first time writing a ZenIP, the structure and format may look intimidating. But really, it's just meant to reflect common-sense practice and some technical conventions. This template is meant to be a starting point for you to structure your ideas. It might help to sort the different aspects of your proposal into the structure below in order get your idea across efficiently. The community and ZenIP editors will help you figure things out and get your proposal into a proper shape later.* - -## Header Preamble - - ZenIP: Unassigned (numbers are assigned by ZenIP editors) - Title: *Something Short and To the Point* - Owners: First Owner - ... - Status: Draft - Category: (Consensus | Standards Track |Informational | Process) - Created: yyyy-mm-dd - License: MIT (see the licensing section of ZenIP-42000) - -## Table of Contents - -*Please always include a table of contents, e.g.* - -## Terminology - -The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to -be interpreted as described in [RFC 2119](#references). - -The terms below are to be interpreted as follows: - -- Term to be defined today - - definition -- Another term - - another definition - -## Abstract - -*Describe what this proposal does, typically in a few paragraphs.* - -The Abstract should only provide a summary of the ZenIP; the ZenIP should remain complete without the Abstract. -Use links where applicable, e.g. [[3]](#references). - -## Motivation - -*Why is this proposal needed?* - -This is one of the most important sections of the ZenIP, and should be detailed -and comprehensive. It shouldn't include any of the actual specification - -don't put conformance requirements in this section. - -Explain the status quo, why the status quo is in need of improvement, -and if applicable, the history of how this area has changed. Then describe -*at a high level* why this proposed solution addresses the perceived issues. -It is ok if this is somewhat redundant with the abstract, but here you can -go into a lot more detail. - -## Requirements - -*Describe design constraints on, or goals for the solution -- typically one paragraph for each constraint or goal.* - -Again, don't actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements. - -## Non-requirements - -*This section is entirely optional. If it is present, it describes issues that the proposal is **not** attempting to address, that someone might otherwise think it does or should.* - -## Specification - -*This section describes what should change, using precise language and conformance key words.* - -Anything that is *required in order to implement the ZenIP* (or follow its -process, in the case of a Process ZenIP) should be in this section. - -Avoid overspecification! Also avoid underspecification. Specification is hard. -Don't be afraid to ask for help. -Unless the specification is particularly simple, you will need to organise it under -subheadings. - -### Example Subheading - -At least while the ZenIP is in Draft, we encourage writing open questions and TODOs. - -#### Open Questions - -- What do hackers do on a boat? - -TODO: define byte encoding for the phishing trip. - -Feel free to copy from other ZenIPs doing similar things. - -## Reference Implementation - -This section is entirely optional; if present, it usually gives links to PRs. - -## References - -[1] ZenIP-42000 - https://github.com/HorizenOfficial/zenips/blob/master/zenip-42000.md/#zenip-licensing - -[2] RFC2119 - Key words for use in RFCs to Indicate Requirement Levels https://tools.ietf.org/html/rfc2119 - -[3] Example reference