From b0bc815730e34c829e638a96c6f91fcb011ef52a Mon Sep 17 00:00:00 2001 From: John Tromp Date: Fri, 7 Aug 2020 17:31:15 +0200 Subject: [PATCH 01/11] commit initial version --- text/0000-fix-daa.md | 105 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 text/0000-fix-daa.md diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md new file mode 100644 index 00000000..8867dfed --- /dev/null +++ b/text/0000-fix-daa.md @@ -0,0 +1,105 @@ +- Title: fix-daa +- Authors: [John Tromp](mailto:john.tromp@gmail.com) +- Start date: July 23, 2020 +- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000) +- Tracking issue: [Edit if merged with link to tracking github issue] + +--- + +# Summary +[summary]: #summary + +Change Grin's DAA (Difficulty Adjustment Algorithm) from the current damped simple moving average (dsma) to a weighted-target exponential moving average (wtema). Optionally further restrict the faster-than-light window to 1 minute. + +# Motivation +[motivation]: #motivation + +The current DAA suffers from oscillatory behaviour, and also requires keeping the last 60 block on hand. +wtema is simpler to state, requires only the last 2 blocks, and fixes the oscillatory behaviour. + +# Community-level explanation +[community-level-explanation]: #community-level-explanation + +Grin aims for a 1 minute average block time. +Thus, if the last block took exactly 1 minute to solve, then network difficulty remains the same in Grin's DAA. +If it took 2 minutes to solve, then network difficulty should be decreased. +But only by a small percentage. Halving network difficulty would make it way too erratic. +Similarly, if the last block took less than a minute to solve, then network difficulty should be increased a little. +Grin's DDA uses a simple formula to express the factor by which to change network difficulty, in terms of the ratio of last block time to ideal block time. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +In wtema-M, the factor by which to lower network difficulty after every block +is 1 + (t/T - 1) / M, where T is the ideal block time of 60 seconds, t is the +last block time in seconds, and M is a mean life time. Grin requires strictly +increasing timestamps in consecutive blocks, so t > 0. +In M blocks, the difficulty can thus be increased by at most (1-1/M)^-M ~ e. + +# Drawbacks +[drawbacks]: #drawbacks + +The one drawback I can think of is that using the difference of consecutive +timestamps makes the DAA more susceptible to timestamp manipulation. To quanify +the effect of this, let's say that miners maximally misrepresent m typical +consecutive block times as one m-minute block + m-1 instant blocks. Instead of +keeping network difficulty constant, this would divide it by (1+(m-1)/M) * (1-1/M)^m. +For m much smaller than M, and M > 100, this is only a tiny increase in difficulty. +If m is as large as k\*M+1 then this is (approximately) dividing by (1+k)/e^k, i.e. multiplying by e^k/(1+k). +This is not something that miners should be interested in doing, +as they generally want to maximize rewards by minimizing difficulty, +so this kind of timestamp manipulation seems unlikely. +On the other hand, they have a small incentive to misrepresent block times as +being more regular (closer to T) than they really are, since for m blocks +taking a total time of m\*T, setting timestamps exactly 1 minute apart minimizes the new difficulty. +For instance, reporting a 30-second block and a 90-second block as two 1-minute blocks, changes the adjustment factor +from (1-1/2M)(1+1/2M) = 1-1/4M^2 to 1, which for M > 100 is pretty negligible, indistinguishable from noise +among realistic graphrate fluctuations. + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +The simplest fix to the current DAA to reduce the problem of oscillations is to increase the damping factor. +The reason Grin went with a small damping factor was to make the DAA very responsive to changes in graphrate. +This responsiveness will suffer from increasing the damping factor. It makes sense to consider changing not just +a parameter in the current DAA, but the DAA altogether, as alternatives may offer better trade-offs between stability +and responsiveness. They may also achieve greater overall simplicity, both conecptually and in implementation. + +# Prior art +[prior-art]: #prior-art + +The current DAA in Bitcoin Cash suffers from the same oscillatory behaviour that Grin's DAA does. +Which is what led various BCH developers to do extensive research on possible alternatives [1]. +They identified two DAAs as being superior to others. These two, wtema, and asert, also happen to behave nearly identically. +While wtema is simpler in that it doesn't need exponentiation, it would need special safeguards to robustly deal with +the possibility of very negative solvetimes. Since Grin requires strictly increasing timestamps, it doesn't need any such +safeguards, making wtema the preferred choice for Grin. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +- What parts of the design do you expect to resolve through the RFC process before this gets merged? +While this RFC argues for adopting wtema as a new DAA, it doesn't want to argue for a specific value of the half life M. +In Grin tradition, an integral number of hours is preferable, to limit +arbitrariness. Either 2 hours, 3 hours, or 4 hours, all offer a resonable +balance of responsiveness and stability. +These 3 choices as well as Grin's current DAA with various damping factor choices are implemented at [2], +which allows for easy comparison across many scenarios. +At the same time, we need to decide if reducing the maximum allowed clock drift (FTL parameter) from 12 minutes +down to 1 makes sense, as this will reduce one form of timestamp manipulation. + +# Future possibilities +[future-possibilities]: #future-possibilities + +Although Grin graphrate has been relatively stable throughout its short history, as a GPU mineable coin availble at nicehash, it's always at risk of sudden temporary surges in graphrate, to which it should be able to respond quickly. The current DAA does that, but at a cost (of oscillatory behaviour). +In a future where Grin mining is dominated by Cuckatoo32 ASICs and where Grin is the C32 coin with the largest daily issuance, +the graphrate should be naturally stable, with the need for responsiveness lessened. +We should however account for the possibility of other coins adopting Cuckatoo32 as well. +If, like most coins, they opt for a finite supply, then in initial years they may well have a daily issuance exceeding that of Grin. That would put us in a situation similar to Bitcoin Cash competing with Bitcoin for ASIC hashrate. +Having such a well vetted DAA will be a reassurance for years to come. + +# References +[references]: #references + +[1] https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 +[2] https://github.com/tromp/difficulty From fed44dfb7633c11cc6a86a8a02dfafba01b4b57f Mon Sep 17 00:00:00 2001 From: John Tromp Date: Fri, 7 Aug 2020 18:02:34 +0200 Subject: [PATCH 02/11] compare with Ethereum DAA --- text/0000-fix-daa.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md index 8867dfed..bd50e49f 100644 --- a/text/0000-fix-daa.md +++ b/text/0000-fix-daa.md @@ -69,12 +69,17 @@ and responsiveness. They may also achieve greater overall simplicity, both conec [prior-art]: #prior-art The current DAA in Bitcoin Cash suffers from the same oscillatory behaviour that Grin's DAA does. -Which is what led various BCH developers to do extensive research on possible alternatives [1]. +Which is what led various BCH developers to do extensive research on possible alternatives [1] [2]. They identified two DAAs as being superior to others. These two, wtema, and asert, also happen to behave nearly identically. While wtema is simpler in that it doesn't need exponentiation, it would need special safeguards to robustly deal with the possibility of very negative solvetimes. Since Grin requires strictly increasing timestamps, it doesn't need any such safeguards, making wtema the preferred choice for Grin. +Before adding a dependence on number of parent uncles, Ethereud uses a DAA that can be seen as a close approximation of wtema: +After every block, increase network difficulty by a factor of 1 - (t/T - 1) / M. +Comparing with wtema above, we see that instead of dividing by (1+x), they multiply by (1-x). +Even though Ethereum, like Grin, enforces positive solvetimes, they still need to guard against division by 0 in this form. + # Unresolved questions [unresolved-questions]: #unresolved-questions @@ -83,7 +88,7 @@ While this RFC argues for adopting wtema as a new DAA, it doesn't want to argue In Grin tradition, an integral number of hours is preferable, to limit arbitrariness. Either 2 hours, 3 hours, or 4 hours, all offer a resonable balance of responsiveness and stability. -These 3 choices as well as Grin's current DAA with various damping factor choices are implemented at [2], +These 3 choices as well as Grin's current DAA with various damping factor choices are implemented at [3], which allows for easy comparison across many scenarios. At the same time, we need to decide if reducing the maximum allowed clock drift (FTL parameter) from 12 minutes down to 1 makes sense, as this will reduce one form of timestamp manipulation. @@ -101,5 +106,8 @@ Having such a well vetted DAA will be a reassurance for years to come. # References [references]: #references -[1] https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 -[2] https://github.com/tromp/difficulty +[1] https://www.yours.org/content/the-wtema-difficulty-adjustment-algorithm-855a3405606a + +[2] https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 + +[3] https://github.com/tromp/difficulty From 97daf22cccf3a49b248d6f6be4ac0a48ff95801b Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sat, 8 Aug 2020 11:14:07 +0200 Subject: [PATCH 03/11] fix FTL naming --- text/0000-fix-daa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md index bd50e49f..9f3d7045 100644 --- a/text/0000-fix-daa.md +++ b/text/0000-fix-daa.md @@ -9,7 +9,7 @@ # Summary [summary]: #summary -Change Grin's DAA (Difficulty Adjustment Algorithm) from the current damped simple moving average (dsma) to a weighted-target exponential moving average (wtema). Optionally further restrict the faster-than-light window to 1 minute. +Change Grin's DAA (Difficulty Adjustment Algorithm) from the current damped simple moving average (dsma) to a weighted-target exponential moving average (wtema). Optionally further restrict the future-time-limit window to 1 minute. # Motivation [motivation]: #motivation From 2392bd66d92b924a389e6330fd442ce4406a737c Mon Sep 17 00:00:00 2001 From: John Tromp Date: Fri, 14 Aug 2020 17:31:50 +0200 Subject: [PATCH 04/11] fix typos and disambiguate --- text/0000-fix-daa.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md index 9f3d7045..1dedb7db 100644 --- a/text/0000-fix-daa.md +++ b/text/0000-fix-daa.md @@ -40,7 +40,7 @@ In M blocks, the difficulty can thus be increased by at most (1-1/M)^-M ~ e. [drawbacks]: #drawbacks The one drawback I can think of is that using the difference of consecutive -timestamps makes the DAA more susceptible to timestamp manipulation. To quanify +timestamps makes the DAA more susceptible to timestamp manipulation. To quantify the effect of this, let's say that miners maximally misrepresent m typical consecutive block times as one m-minute block + m-1 instant blocks. Instead of keeping network difficulty constant, this would divide it by (1+(m-1)/M) * (1-1/M)^m. @@ -63,7 +63,7 @@ The simplest fix to the current DAA to reduce the problem of oscillations is to The reason Grin went with a small damping factor was to make the DAA very responsive to changes in graphrate. This responsiveness will suffer from increasing the damping factor. It makes sense to consider changing not just a parameter in the current DAA, but the DAA altogether, as alternatives may offer better trade-offs between stability -and responsiveness. They may also achieve greater overall simplicity, both conecptually and in implementation. +and responsiveness. They may also achieve greater overall simplicity, both conceptually and in implementation. # Prior art [prior-art]: #prior-art @@ -75,7 +75,7 @@ While wtema is simpler in that it doesn't need exponentiation, it would need spe the possibility of very negative solvetimes. Since Grin requires strictly increasing timestamps, it doesn't need any such safeguards, making wtema the preferred choice for Grin. -Before adding a dependence on number of parent uncles, Ethereud uses a DAA that can be seen as a close approximation of wtema: +Before adding a dependence on number of parent uncles, Ethereum uses a DAA that can be seen as a close approximation of wtema: After every block, increase network difficulty by a factor of 1 - (t/T - 1) / M. Comparing with wtema above, we see that instead of dividing by (1+x), they multiply by (1-x). Even though Ethereum, like Grin, enforces positive solvetimes, they still need to guard against division by 0 in this form. @@ -100,7 +100,9 @@ Although Grin graphrate has been relatively stable throughout its short history, In a future where Grin mining is dominated by Cuckatoo32 ASICs and where Grin is the C32 coin with the largest daily issuance, the graphrate should be naturally stable, with the need for responsiveness lessened. We should however account for the possibility of other coins adopting Cuckatoo32 as well. -If, like most coins, they opt for a finite supply, then in initial years they may well have a daily issuance exceeding that of Grin. That would put us in a situation similar to Bitcoin Cash competing with Bitcoin for ASIC hashrate. +If, like most coins, they opt for a finite supply, then in initial years they +may well have a daily issuance exceeding that of Grin. That would put us in the +same situation as Bitcoin Cash competing with Bitcoin for ASIC hashrate. Having such a well vetted DAA will be a reassurance for years to come. # References From c141a7d11b93f201c4b40943b3c49ee0f0728116 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 16 Aug 2020 21:13:43 +0200 Subject: [PATCH 05/11] typo fix --- text/0000-fix-daa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md index 1dedb7db..269166f8 100644 --- a/text/0000-fix-daa.md +++ b/text/0000-fix-daa.md @@ -96,7 +96,7 @@ down to 1 makes sense, as this will reduce one form of timestamp manipulation. # Future possibilities [future-possibilities]: #future-possibilities -Although Grin graphrate has been relatively stable throughout its short history, as a GPU mineable coin availble at nicehash, it's always at risk of sudden temporary surges in graphrate, to which it should be able to respond quickly. The current DAA does that, but at a cost (of oscillatory behaviour). +Although Grin graphrate has been relatively stable throughout its short history, as a GPU mineable coin available at nicehash, it's always at risk of sudden temporary surges in graphrate, to which it should be able to respond quickly. The current DAA does that, but at a cost (of oscillatory behaviour). In a future where Grin mining is dominated by Cuckatoo32 ASICs and where Grin is the C32 coin with the largest daily issuance, the graphrate should be naturally stable, with the need for responsiveness lessened. We should however account for the possibility of other coins adopting Cuckatoo32 as well. From 54267ac08df803cecd16b08fa69120eb78ad556f Mon Sep 17 00:00:00 2001 From: John Tromp Date: Fri, 21 Aug 2020 17:04:07 +0200 Subject: [PATCH 06/11] configurable FTL --- text/0000-fix-daa.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md index 269166f8..33e9ab17 100644 --- a/text/0000-fix-daa.md +++ b/text/0000-fix-daa.md @@ -90,8 +90,9 @@ arbitrariness. Either 2 hours, 3 hours, or 4 hours, all offer a resonable balance of responsiveness and stability. These 3 choices as well as Grin's current DAA with various damping factor choices are implemented at [3], which allows for easy comparison across many scenarios. -At the same time, we need to decide if reducing the maximum allowed clock drift (FTL parameter) from 12 minutes +At the same time, reducing the maximum allowed clock drift (FTL parameter) from 12 minutes down to 1 makes sense, as this will reduce one form of timestamp manipulation. +Preferably, this is not hardcoded but specified as a parameter in grin-server.toml # Future possibilities [future-possibilities]: #future-possibilities From 9da7228d499db41057388bb0aa059cfc2297cadb Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 6 Sep 2020 23:50:17 +0200 Subject: [PATCH 07/11] fix typo and broken link --- text/0000-fix-daa.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md index 33e9ab17..f0e18912 100644 --- a/text/0000-fix-daa.md +++ b/text/0000-fix-daa.md @@ -25,7 +25,7 @@ Thus, if the last block took exactly 1 minute to solve, then network difficulty If it took 2 minutes to solve, then network difficulty should be decreased. But only by a small percentage. Halving network difficulty would make it way too erratic. Similarly, if the last block took less than a minute to solve, then network difficulty should be increased a little. -Grin's DDA uses a simple formula to express the factor by which to change network difficulty, in terms of the ratio of last block time to ideal block time. +Grin's DAA uses a simple formula to express the factor by which to change network difficulty, in terms of the ratio of last block time to ideal block time. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -109,7 +109,7 @@ Having such a well vetted DAA will be a reassurance for years to come. # References [references]: #references -[1] https://www.yours.org/content/the-wtema-difficulty-adjustment-algorithm-855a3405606a +[1] https://web.archive.org/web/20181120082228if\_/https://www.yours.org/content/the-wtema-difficulty-adjustment-algorithm-855a3405606a/ [2] https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 From 7ff586948fa461a36095e87622867b6d41f400f9 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Mon, 7 Sep 2020 00:11:09 +0200 Subject: [PATCH 08/11] try fix links --- text/0000-fix-daa.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md index f0e18912..1dbf0be0 100644 --- a/text/0000-fix-daa.md +++ b/text/0000-fix-daa.md @@ -109,8 +109,8 @@ Having such a well vetted DAA will be a reassurance for years to come. # References [references]: #references -[1] https://web.archive.org/web/20181120082228if\_/https://www.yours.org/content/the-wtema-difficulty-adjustment-algorithm-855a3405606a/ +[1] [archive.org](https://web.archive.org/web/20181120082228if_/https://www.yours.org/content/the-wtema-difficulty-adjustment-algorithm-855a3405606a/) -[2] https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 +[2] [read.cash](https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696) -[3] https://github.com/tromp/difficulty +[3] (tromp github)https://github.com/tromp/difficulty From 60fade0207b9d088b21468d3dd69939dac0e5e37 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sat, 26 Sep 2020 17:58:49 +0200 Subject: [PATCH 09/11] confom to new template and adapt to conclusions of FTL discussion --- text/0000-fix-daa.md | 74 ++++++++++++++++++++++++++++++-------------- 1 file changed, 50 insertions(+), 24 deletions(-) diff --git a/text/0000-fix-daa.md b/text/0000-fix-daa.md index 1dbf0be0..bfb9c4c4 100644 --- a/text/0000-fix-daa.md +++ b/text/0000-fix-daa.md @@ -6,28 +6,40 @@ --- -# Summary +## Summary [summary]: #summary -Change Grin's DAA (Difficulty Adjustment Algorithm) from the current damped simple moving average (dsma) to a weighted-target exponential moving average (wtema). Optionally further restrict the future-time-limit window to 1 minute. +Change Grin's DAA (Difficulty Adjustment Algorithm) from the current damped simple moving average (dsma) to a weighted-target exponential moving average (wtema). Also, restrict the future-time-limit (FTL) window to 5 minutes. -# Motivation +## Motivation [motivation]: #motivation The current DAA suffers from oscillatory behaviour, and also requires keeping the last 60 block on hand. wtema is simpler to state, requires only the last 2 blocks, and fixes the oscillatory behaviour. +The current FTL window of 12 minutes appears rather arbitrary. It matches the 2-hour window used in bitcoin +when expressed in their respective blocktimes, but we prefer a more natural amount in terms of clock time. -# Community-level explanation + +## Community-level explanation [community-level-explanation]: #community-level-explanation Grin aims for a 1 minute average block time. -Thus, if the last block took exactly 1 minute to solve, then network difficulty remains the same in Grin's DAA. -If it took 2 minutes to solve, then network difficulty should be decreased. -But only by a small percentage. Halving network difficulty would make it way too erratic. -Similarly, if the last block took less than a minute to solve, then network difficulty should be increased a little. -Grin's DAA uses a simple formula to express the factor by which to change network difficulty, in terms of the ratio of last block time to ideal block time. - -# Reference-level explanation +Thus, if the last block took exactly 1 minute to solve, then network difficulty +remains the same in Grin's DAA. If it took 2 minutes to solve, then network +difficulty should be decreased. +But only by a small percentage. Halving network difficulty would make it way +too erratic. Similarly, if the last block took less than a minute to solve, +then network difficulty should be increased a little. +Grin's DAA uses a simple formula to express the factor by which to change +network difficulty, in terms of the ratio of last block time to ideal block +time. + +A future-time-limit of 5 minutes naturally corresponds to the hour markers on a clock. +The trade-off for FTL is between impact of timestamp manipulation and risk of divergence between local +and actual clock time. For properly configured systems (e.g. correct time-zone and daylight-savings-time settings) +we expect drifts of several minutes to be quite noticeable, and likely to be corrected by operators. + +## Reference-level explanation [reference-level-explanation]: #reference-level-explanation In wtema-M, the factor by which to lower network difficulty after every block @@ -36,10 +48,14 @@ last block time in seconds, and M is a mean life time. Grin requires strictly increasing timestamps in consecutive blocks, so t > 0. In M blocks, the difficulty can thus be increased by at most (1-1/M)^-M ~ e. -# Drawbacks +The maximum allowed clock drift (FTL parameter) is to be 5 minutes; blocks whose timestamp exceeds +the local time by more than 5 minutes are ignored and not relayed. +This parameter is not hardcoded but to be specified in grin-server.toml + +## Drawbacks [drawbacks]: #drawbacks -The one drawback I can think of is that using the difference of consecutive +At the time of writing, the only apparent drawback is that using the difference of consecutive timestamps makes the DAA more susceptible to timestamp manipulation. To quantify the effect of this, let's say that miners maximally misrepresent m typical consecutive block times as one m-minute block + m-1 instant blocks. Instead of @@ -56,7 +72,10 @@ For instance, reporting a 30-second block and a 90-second block as two 1-minute from (1-1/2M)(1+1/2M) = 1-1/4M^2 to 1, which for M > 100 is pretty negligible, indistinguishable from noise among realistic graphrate fluctuations. -# Rationale and alternatives +The risk of NTP (Network Time Protocol) based local clocks diverging by more than 5 minutes is somewhat +larger than with a 12 minute threshold. + +## Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives The simplest fix to the current DAA to reduce the problem of oscillations is to increase the damping factor. @@ -65,7 +84,12 @@ This responsiveness will suffer from increasing the damping factor. It makes sen a parameter in the current DAA, but the DAA altogether, as alternatives may offer better trade-offs between stability and responsiveness. They may also achieve greater overall simplicity, both conceptually and in implementation. -# Prior art +An FTL window of 1 minute, matching the blocktime, was considered as being the least arbitrary, +and also leaving little room for timestamp manipulation. However, some worries remained that NTP is not robust enough to +practically guarantee sub-minute drift even for properly configured systems. + + +## Prior art [prior-art]: #prior-art The current DAA in Bitcoin Cash suffers from the same oscillatory behaviour that Grin's DAA does. @@ -80,25 +104,25 @@ After every block, increase network difficulty by a factor of 1 - (t/T - 1) / M. Comparing with wtema above, we see that instead of dividing by (1+x), they multiply by (1-x). Even though Ethereum, like Grin, enforces positive solvetimes, they still need to guard against division by 0 in this form. -# Unresolved questions +## Unresolved questions [unresolved-questions]: #unresolved-questions -- What parts of the design do you expect to resolve through the RFC process before this gets merged? While this RFC argues for adopting wtema as a new DAA, it doesn't want to argue for a specific value of the half life M. In Grin tradition, an integral number of hours is preferable, to limit arbitrariness. Either 2 hours, 3 hours, or 4 hours, all offer a resonable balance of responsiveness and stability. These 3 choices as well as Grin's current DAA with various damping factor choices are implemented at [3], which allows for easy comparison across many scenarios. -At the same time, reducing the maximum allowed clock drift (FTL parameter) from 12 minutes -down to 1 makes sense, as this will reduce one form of timestamp manipulation. -Preferably, this is not hardcoded but specified as a parameter in grin-server.toml -# Future possibilities +## Future possibilities [future-possibilities]: #future-possibilities -Although Grin graphrate has been relatively stable throughout its short history, as a GPU mineable coin available at nicehash, it's always at risk of sudden temporary surges in graphrate, to which it should be able to respond quickly. The current DAA does that, but at a cost (of oscillatory behaviour). -In a future where Grin mining is dominated by Cuckatoo32 ASICs and where Grin is the C32 coin with the largest daily issuance, +Although Grin graphrate has been relatively stable throughout its short +history, as a GPU mineable coin available at nicehash, it's always at risk of +sudden temporary surges in graphrate, to which it should be able to respond +quickly. The current DAA does that, but at a cost (of oscillatory behaviour). +In a future where Grin mining is dominated by Cuckatoo32 ASICs and where Grin +is the C32 coin with the largest daily issuance, the graphrate should be naturally stable, with the need for responsiveness lessened. We should however account for the possibility of other coins adopting Cuckatoo32 as well. If, like most coins, they opt for a finite supply, then in initial years they @@ -106,7 +130,9 @@ may well have a daily issuance exceeding that of Grin. That would put us in the same situation as Bitcoin Cash competing with Bitcoin for ASIC hashrate. Having such a well vetted DAA will be a reassurance for years to come. -# References +Future improvements in network clock synchronization might make a reduction of FTL down to one minute viable. + +## References [references]: #references [1] [archive.org](https://web.archive.org/web/20181120082228if_/https://www.yours.org/content/the-wtema-difficulty-adjustment-algorithm-855a3405606a/) From 949eba8a44d839c492a3b32ba616c2661717d140 Mon Sep 17 00:00:00 2001 From: Daniel Lehnberg Date: Mon, 26 Oct 2020 17:13:24 +0000 Subject: [PATCH 10/11] RFC#0018 --- text/{0000-fix-daa.md => 0018-fix-daa.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename text/{0000-fix-daa.md => 0018-fix-daa.md} (97%) diff --git a/text/0000-fix-daa.md b/text/0018-fix-daa.md similarity index 97% rename from text/0000-fix-daa.md rename to text/0018-fix-daa.md index bfb9c4c4..24879406 100644 --- a/text/0000-fix-daa.md +++ b/text/0018-fix-daa.md @@ -1,8 +1,8 @@ - Title: fix-daa - Authors: [John Tromp](mailto:john.tromp@gmail.com) - Start date: July 23, 2020 -- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000) -- Tracking issue: [Edit if merged with link to tracking github issue] +- RFC PR: [mimblewimble/grin-rfcs#61](https://github.com/mimblewimble/grin-rfcs/pull/61) +- Tracking issue: [mimblewimble/grin#3473](https://github.com/mimblewimble/grin/issues/3473) --- From 63e52205334c9498bca2778ec05cd014c99a7682 Mon Sep 17 00:00:00 2001 From: Daniel Lehnberg Date: Mon, 26 Oct 2020 17:15:06 +0000 Subject: [PATCH 11/11] Update README --- README.md | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 6b733fc4..18e12e1f 100644 --- a/README.md +++ b/README.md @@ -10,23 +10,26 @@ To begin writing your own RFC or to find out more about the process and the gene ## List of accepted RFCs -|Title|Tl;dr| -|:---|:---| -| [0001-rfc-process](text/0001-rfc-process.md) | Introduce RFC process | -| [0002-grin-governance](text/0002-grin-governance.md) | Articulate community values, define core and sub-teams | -| [0003-security-process](text/0003-security-process.md) | Define community standards for ethical disclosure behaviour | -| [0004-full-wallet-lifecycle](text/0004-full-wallet-lifecycle.md) | Define API standard for sensitive wallet operations | -| [0005-variable-size-kernels](text/0005-variable-size-kernels.md) | Introduce kernel variants that can be of different sizes | -| [0006-payment-proofs](text/0006-payment-proofs.md) | Support generating and validating payment proofs for sender-initiated (i.e. non-invoice) transactions | -| [0007-node-api-v2](text/0007-node-api-v2.md) | Create a v2 JSON-RPC API for the Node API | -| [0008-wallet-state-management](text/0008-wallet-state-management.md) | Improve wallet state management | -| [0009-enable-faster-sync](text/0009-enable-faster-sync.md) | Enable faster txhashset sync by changing output MMR commitment | -| [0010-online-transacting-via-tor](text/0010-online-transacting-via-tor.md) | Define standard for transacting via Tor | -| [0011-security-team](text/0011-security-team.md) | Establish Grin Security team | -| [0012-compact-slates](text/0012-compact-slates.md) | Introduce new compact slate format (Slate V4) | -| [0013-nrd-kernels](text/0013-nrd-kernels.md) | Introduce relative timelocks through "No Recent Duplicate" transaction kernels | -| [0014-general-fund-guidelines](text/0014-general-fund-guidelines.md) | Define general fund spending guidelines | -| [0015-slatepack](text/0015-slatepack.md) | Universal transaction standard for Grin | +|Title|Status|Tl;dr| +|:---|---|:---| +| [0001-rfc-process](text/0001-rfc-process.md) | ACTIVE | Introduce RFC process | +| [0002-grin-governance](text/0002-grin-governance.md) | RETIRED | ~~Articulate community values, define core and sub-teams~~ Replaced by RFC#6. | +| [0003-security-process](text/0003-security-process.md) | ACTIVE | Define community standards for ethical disclosure behaviour | +| [0004-full-wallet-lifecycle](text/0004-full-wallet-lifecycle.md) | ACTIVE | Define API standard for sensitive wallet operations | +| [0005-variable-size-kernels](text/0005-variable-size-kernels.md) | ACTIVE | Introduce kernel variants that can be of different sizes | +| [0006-payment-proofs](text/0006-payment-proofs.md) | ACTIVE | Support generating and validating payment proofs for sender-initiated (i.e. non-invoice) transactions | +| [0007-node-api-v2](text/0007-node-api-v2.md) | ACTIVE | Create a v2 JSON-RPC API for the Node API | +| [0008-wallet-state-management](text/0008-wallet-state-management.md) | ACTIVE | Improve wallet state management | +| [0009-enable-faster-sync](text/0009-enable-faster-sync.md) | ACTIVE | Enable faster txhashset sync by changing output MMR commitment | +| [0010-online-transacting-via-tor](text/0010-online-transacting-via-tor.md) | RETIRED | ~~Define standard for transacting via Tor~~ Replaced by RFC#0015. | +| [0011-security-team](text/0011-security-team.md) | ACTIVE | Establish Grin Security team | +| [0012-compact-slates](text/0012-compact-slates.md)| ACTIVE | Introduce new compact slate format (Slate V4) | +| [0013-nrd-kernels](text/0013-nrd-kernels.md) | ACTIVE | Introduce relative timelocks through "No Recent Duplicate" transaction kernels | +| [0014-general-fund-guidelines](text/0014-general-fund-guidelines.md) | ACTIVE | Define general fund spending guidelines | +| [0015-slatepack](text/0015-slatepack.md) | ACTIVE | Universal transaction standard for Grin. Replaces RFC#0010. | +| [0016-simplify-governance](text/0016-simplify-governance.md) | ACTIVE | Simplify Grin governance model. Replaces RFC#0002. | +| [0017-fix-fees](text/0017-fix-fees.md) | ACTIVE | Change minimum relay fees to be weight proportional, make output creation cost 0.01 Grin. | +| [0018-fix-daa](text/0018-fix-daa.md) | ACTIVE | Change DAA (Difficulty Adjustment Algorithm) from damped simple moving average (dsma) to a weighted-target exponential moving average (wtema). Restrict the future-time-limit (FTL) window to 5 minutes. | ## License