2836
TestNet Discussion Archive / Re: Testnet - Test Proof of Giving
« on: January 02, 2019, 08:53:24 AM »
Hey All,
So from a very high level, POG seems to be "relatively good", but I have an uneasy feeling about one issue.
When we removed the training wheels, I noticed we always had a smaller chain with less work competing with the main chain - IE we were more apt to form a fork. We had about one fork per day, yet we recovered. I don't think this is normal.
In light of this, I will need to make some changes to POG - most likely changes that deal with shortening the POG duration down from 205 blocks to 16. I'm thinking what we might do is simplify POG in a way where the wallet takes a look at the last 16 blocks to determine POG difficulty (in contrast to 205), and inside those 16 blocks, it creates a map of who is in the pool (IE who legally tithed), and we pay every pool participant in the next block.
This should give the POG participant the benefit of receiving less volatile reward amounts per tithe (IE not waiting for a payment tier to occur).
The main benefit of this for the core wallet is it will theoretically be more efficient (IE less lookback calculations) and also less prone to fork risk (as during every block connect, the wallet looks at its prior 16 block indexes).
So in light of this please pause testing and Ill prioritize this to the highest level and be back asap with a new version.
So from a very high level, POG seems to be "relatively good", but I have an uneasy feeling about one issue.
When we removed the training wheels, I noticed we always had a smaller chain with less work competing with the main chain - IE we were more apt to form a fork. We had about one fork per day, yet we recovered. I don't think this is normal.
In light of this, I will need to make some changes to POG - most likely changes that deal with shortening the POG duration down from 205 blocks to 16. I'm thinking what we might do is simplify POG in a way where the wallet takes a look at the last 16 blocks to determine POG difficulty (in contrast to 205), and inside those 16 blocks, it creates a map of who is in the pool (IE who legally tithed), and we pay every pool participant in the next block.
This should give the POG participant the benefit of receiving less volatile reward amounts per tithe (IE not waiting for a payment tier to occur).
The main benefit of this for the core wallet is it will theoretically be more efficient (IE less lookback calculations) and also less prone to fork risk (as during every block connect, the wallet looks at its prior 16 block indexes).
So in light of this please pause testing and Ill prioritize this to the highest level and be back asap with a new version.