Hello, Slimcoin community!
Even though I did some research (i.e. tried the Bitcoin Wiki), I still can figure out what that Proof of Burn thing is. Can someone please explain me in the simplest manner possible? ELI5?
Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 42. (Read 137085 times)
The "hard cap" alone might be beneficial already though, especially if we go even lower than 8. If we set the limit to 3 PoS blocks in a row, we should get at least one PoW block every 4 minutes and a PoB block every 12 minutes.
If we do set a small hard cap, we need to increase the PoS target spacing however. Otherwise, the PoS diff would keep dropping since the hard cap prevents the network from ever generating more than 3 PoS blocks per 4 minutes (=1 PoS block every 80 seconds).
Doing this in a soft fork would be more complicated - we would need to add a new mandatory nBits field in the coinbase and ignore the old one in the blockheader. Attacking non-upgraded nodes would be even easier in this case as they will accept minimum-diff PoS blocks.
A hard cap significantly larger than 10 blocks could be done without fiddling around with the spacing and difficulties but that would also not help as much.
Thanks for your explanations. I have still to grasp fully the interactions between target spacing and difficulty on one hand and trust and a possible hard cap on the other hand.If we do set a small hard cap, we need to increase the PoS target spacing however. Otherwise, the PoS diff would keep dropping since the hard cap prevents the network from ever generating more than 3 PoS blocks per 4 minutes (=1 PoS block every 80 seconds).
Doing this in a soft fork would be more complicated - we would need to add a new mandatory nBits field in the coinbase and ignore the old one in the blockheader. Attacking non-upgraded nodes would be even easier in this case as they will accept minimum-diff PoS blocks.
A hard cap significantly larger than 10 blocks could be done without fiddling around with the spacing and difficulties but that would also not help as much.
I understand that when considering a possible "hard PoS block cap", there needs to be at least the "room" that PoS difficulty can "catch up", letting PoS minters create temporarily more than 10 blocks per PoW block.
Is there a possibility to make the "PoS block cap" depend on PoS difficulty? So if the PoS diff gets too low, or drops too much compared to e.g. 10 PoS blocks ago, the hard cap could be increased temporarily to a maximum of e.g. 15 PoS blocks in a row until it catches up again, otherwise staying on 10 or slightly below.
But even a hard cap of 12 or 13 blocks could help a bit, preventing the case that mining isn't able to catch up with chain trust for 30 or 50 blocks.
A hard fork is complicated in the current situation. So one perhaps could find an alternative solution, for example with a gradual reduction of trust of blocks in a row (for example: Block 1 full trust, Block 2-3 1/3 (like now), Block 4 and 5 1/6, block 6-8 1/9).
This idea sounds good but some problems may arise from the fact that most services (and users) work with a specific number of confirmations instead of trust. If we set the trust per PoS block too low, a minority PoW miner could build on top of the beginning of a long PoS chain and then revert that entire chain if he finds a PoW block.
Quote
If we can get services to use trust or rather some kind of "virtual confirmations" number based on trust instead of the number of confirmations, that would be optimal.
We could recommend that on the website for Slimcoin-only services, but I guess it's difficult to get major exchanges to do that. Quote
Interesting observation... but that last sentence is not quite correct. The two reductions will not be combined to 1/9 because the bnNewTrust/3 is returned right away. This kind of makes this problem more serious because PoS blocks will typically have 1/3 the trust of a PoW block.
Oh, you're probably totally right. Thanks. It's true - it's even clearer so that this is probably the reason for the temporary "PoS takeovers".Quote
I don't know if setting trust values to zero would be the best solution to this. Someone who can dominate PoS and is capable of producing at least a single PoW block could just prepare a long chain of PoS block and then mine a PoW block on top of it. Since the PoW block has nonzero trust, the network should accept it regardless of how many PoS blocks there are (unless I'm missing something). I think it would be more clean to just put a hard cap on the number of consecutive PoS blocks ("if the last N blocks were PoS and this block is PoS too, reject it"). This should be doable in a soft fork.
So I interpret it's possible to mine on a zero-trust block without other clients rejecting that, right? In this case, the "hard" cap obviously is a better idea. I would set the limit pretty low (lower than 10) because some services accept confirmation times of 10 blocks, and a large PoS minter could try to double-spend attack them otherwise.Quote
So, in order to decrease the influence of PoS on the network, it would probably make sense to decrease nTargetSpacingWorkMax from 10*STAKE_TARGET_SPACING (15min) to something more sane.
Would this require a hard fork? If not, I would support the combination of this measure with a "hard cap" of e.g. 8 PoS blocks in a row.
The "hard cap" alone might be beneficial already though, especially if we go even lower than 8. If we set the limit to 3 PoS blocks in a row, we should get at least one PoW block every 4 minutes and a PoB block every 12 minutes.
If we do set a small hard cap, we need to increase the PoS target spacing however. Otherwise, the PoS diff would keep dropping since the hard cap prevents the network from ever generating more than 3 PoS blocks per 4 minutes (=1 PoS block every 80 seconds).
Doing this in a soft fork would be more complicated - we would need to add a new mandatory nBits field in the coinbase and ignore the old one in the blockheader. Attacking non-upgraded nodes would be even easier in this case as they will accept minimum-diff PoS blocks.
A hard cap significantly larger than 10 blocks could be done without fiddling around with the spacing and difficulties but that would also not help as much.
Quote
Or we could get rid of the mechanism that increases the PoW target spacing based on the PoS interval entirely (equivalent to setting nTargetSpacingWorkMax to 1*STAKE_TARGET_SPACING) This would require a hard fork however.
A hard fork is complicated in the current situation. So one perhaps could find an alternative solution, for example with a gradual reduction of trust of blocks in a row (for example: Block 1 full trust, Block 2-3 1/3 (like now), Block 4 and 5 1/6, block 6-8 1/9).This idea sounds good but some problems may arise from the fact that most services (and users) work with a specific number of confirmations instead of trust. If we set the trust per PoS block too low, a minority PoW miner could build on top of the beginning of a long PoS chain and then revert that entire chain if he finds a PoW block.
Sybil and MITM attacks would also work just as well as they do right now.
If we can get services to use trust or rather some kind of "virtual confirmations" number based on trust instead of the number of confirmations, that would be optimal.
@iguano - I dont know, if you are on telegram/discord group, but I welcome you.
Thanks! I'm gonna check out the discord group sometime soon.What's interesting for us is the calculation of PoS block trust:
This line is called every time when a PoS block is detected. It sets the "block trust" for PoS blocks basically to a value correlated directly with PoW difficulty. The higher the difficulty, the higher the "trust" of the block.
After that line, there are some mechanisms in place meant to ensure that there are not too many PoS blocks in a row. So the block trust is reduced to a third if:
Interesting observation... but that last sentence is not quite correct. The two reductions will not be combined to 1/9 because the bnNewTrust/3 is returned right away. This kind of makes this problem more serious because PoS blocks will typically have 1/3 the trust of a PoW block.Code:
CBigNum bnNewTrust = (CBigNum(1)<<256) / (bnTarget + 1);
After that line, there are some mechanisms in place meant to ensure that there are not too many PoS blocks in a row. So the block trust is reduced to a third if:
- the parent block of the PoS block is not a PoW block
- there are less than 3 PoW blocks in the last 12 PoS blocks
I don't know if setting trust values to zero would be the best solution to this. Someone who can dominate PoS and is capable of producing at least a single PoW block could just prepare a long chain of PoS block and then mine a PoW block on top of it. Since the PoW block has nonzero trust, the network should accept it regardless of how many PoS blocks there are (unless I'm missing something). I think it would be more clean to just put a hard cap on the number of consecutive PoS blocks ("if the last N blocks were PoS and this block is PoS too, reject it"). This should be doable in a soft fork.
I have looked at 5000 blocks starting at 1467845 and gathered some data:
PoS blocks make up two thirds of the total trust score and 80% of the total number of blocks.
PoW has 27.5% trust and 15.4% blocks
PoB has 5.8% trust and 4.8% blocks
The main reason for this is that the target spacings massively favor PoS over everything else:
Code:
int64 nTargetSpacing = fProofOfStake ? STAKE_TARGET_SPACING :
min(nTargetSpacingWorkMax, (int64) STAKE_TARGET_SPACING * (1 + pindexLast->nHeight - pindexPrev->nHeight));
For PoB, there is a target spacing of one block per 3 PoW blocks (see GetNextBurnTargetRequired in main.cpp)
This also explains why there were periods during which PoS was not dominating: There simply weren't enough coins being staked to make one minimum-difficulty block every 90 seconds so this PoW-difficulty-increase mechanism didn't kick in back then.
So, in order to decrease the influence of PoS on the network, it would probably make sense to decrease nTargetSpacingWorkMax from 10*STAKE_TARGET_SPACING (15min) to something more sane. Or we could get rid of the mechanism that increases the PoW target spacing based on the PoS interval entirely (equivalent to setting nTargetSpacingWorkMax to 1*STAKE_TARGET_SPACING) This would require a hard fork however.
P.S.: I'm gonna restart staking now but I'll do it more gently for now
Bolded part - this is my observation as well - if there weren't enough coins to stake, the PoS diff was minimal, and PoW/PoB diff was sane.
When there is more staking coins - there is PoW/PoB diff skyrocketing, and it takes a while to stabilize, and taking PoW and the most important PoB rewards - down, as blocks which are made by those 2 consensus are much lower.
It's of course from my non-programming angle.
Quote
Interesting observation... but that last sentence is not quite correct. The two reductions will not be combined to 1/9 because the bnNewTrust/3 is returned right away. This kind of makes this problem more serious because PoS blocks will typically have 1/3 the trust of a PoW block.
Oh, you're probably totally right. Thanks. It's true - it's even clearer so that this is probably the reason for the temporary "PoS takeovers".Quote
I don't know if setting trust values to zero would be the best solution to this. Someone who can dominate PoS and is capable of producing at least a single PoW block could just prepare a long chain of PoS block and then mine a PoW block on top of it. Since the PoW block has nonzero trust, the network should accept it regardless of how many PoS blocks there are (unless I'm missing something). I think it would be more clean to just put a hard cap on the number of consecutive PoS blocks ("if the last N blocks were PoS and this block is PoS too, reject it"). This should be doable in a soft fork.
So I interpret it's possible to mine on a zero-trust block without other clients rejecting that, right? In this case, the "hard" cap obviously is a better idea. I would set the limit pretty low (lower than 10) because some services accept confirmation times of 10 blocks, and a large PoS minter could try to double-spend attack them otherwise.Quote
I have looked at 5000 blocks starting at 1467845 and gathered some data:
PoS blocks make up two thirds of the total trust score and 80% of the total number of blocks.
PoW has 27.5% trust and 15.4% blocks
PoB has 5.8% trust and 4.8% blocks
The main reason for this is that the target spacings massively favor PoS over everything else:
This piece of code (function GetNextTargetRequired in main.cpp) increases the PoW block spacing to 15 minutes if there are enough PoS blocks. (one PoW block per 10 PoS blocks)
For PoB, there is a target spacing of one block per 3 PoW blocks (see GetNextBurnTargetRequired in main.cpp)
Interesting observations, thanks! This is likely the "missing piece" of the puzzle I was still seeking.PoS blocks make up two thirds of the total trust score and 80% of the total number of blocks.
PoW has 27.5% trust and 15.4% blocks
PoB has 5.8% trust and 4.8% blocks
The main reason for this is that the target spacings massively favor PoS over everything else:
Code:
int64 nTargetSpacing = fProofOfStake ? STAKE_TARGET_SPACING :
min(nTargetSpacingWorkMax, (int64) STAKE_TARGET_SPACING * (1 + pindexLast->nHeight - pindexPrev->nHeight));
For PoB, there is a target spacing of one block per 3 PoW blocks (see GetNextBurnTargetRequired in main.cpp)
Quote
So, in order to decrease the influence of PoS on the network, it would probably make sense to decrease nTargetSpacingWorkMax from 10*STAKE_TARGET_SPACING (15min) to something more sane.
Would this require a hard fork? If not, I would support the combination of this measure with a "hard cap" of e.g. 8 PoS blocks in a row.
Quote
Or we could get rid of the mechanism that increases the PoW target spacing based on the PoS interval entirely (equivalent to setting nTargetSpacingWorkMax to 1*STAKE_TARGET_SPACING) This would require a hard fork however.
A hard fork is complicated in the current situation. So one perhaps could find an alternative solution, for example with a gradual reduction of trust of blocks in a row (for example: Block 1 full trust, Block 2-3 1/3 (like now), Block 4 and 5 1/6, block 6-8 1/9). @iguano - I dont know, if you are on telegram/discord group, but I welcome you.
Thanks! I'm gonna check out the discord group sometime soon.What's interesting for us is the calculation of PoS block trust:
This line is called every time when a PoS block is detected. It sets the "block trust" for PoS blocks basically to a value correlated directly with PoW difficulty. The higher the difficulty, the higher the "trust" of the block.
After that line, there are some mechanisms in place meant to ensure that there are not too many PoS blocks in a row. So the block trust is reduced to a third if:
Interesting observation... but that last sentence is not quite correct. The two reductions will not be combined to 1/9 because the bnNewTrust/3 is returned right away. This kind of makes this problem more serious because PoS blocks will typically have 1/3 the trust of a PoW block.Code:
CBigNum bnNewTrust = (CBigNum(1)<<256) / (bnTarget + 1);
After that line, there are some mechanisms in place meant to ensure that there are not too many PoS blocks in a row. So the block trust is reduced to a third if:
- the parent block of the PoS block is not a PoW block
- there are less than 3 PoW blocks in the last 12 PoS blocks
I don't know if setting trust values to zero would be the best solution to this. Someone who can dominate PoS and is capable of producing at least a single PoW block could just prepare a long chain of PoS block and then mine a PoW block on top of it. Since the PoW block has nonzero trust, the network should accept it regardless of how many PoS blocks there are (unless I'm missing something). I think it would be more clean to just put a hard cap on the number of consecutive PoS blocks ("if the last N blocks were PoS and this block is PoS too, reject it"). This should be doable in a soft fork.
I have looked at 5000 blocks starting at 1467845 and gathered some data:
PoS blocks make up two thirds of the total trust score and 80% of the total number of blocks.
PoW has 27.5% trust and 15.4% blocks
PoB has 5.8% trust and 4.8% blocks
The main reason for this is that the target spacings massively favor PoS over everything else:
Code:
int64 nTargetSpacing = fProofOfStake ? STAKE_TARGET_SPACING :
min(nTargetSpacingWorkMax, (int64) STAKE_TARGET_SPACING * (1 + pindexLast->nHeight - pindexPrev->nHeight));
For PoB, there is a target spacing of one block per 3 PoW blocks (see GetNextBurnTargetRequired in main.cpp)
This also explains why there were periods during which PoS was not dominating: There simply weren't enough coins being staked to make one minimum-difficulty block every 90 seconds so this PoW-difficulty-increase mechanism didn't kick in back then.
So, in order to decrease the influence of PoS on the network, it would probably make sense to decrease nTargetSpacingWorkMax from 10*STAKE_TARGET_SPACING (15min) to something more sane. Or we could get rid of the mechanism that increases the PoW target spacing based on the PoS interval entirely (equivalent to setting nTargetSpacingWorkMax to 1*STAKE_TARGET_SPACING) This would require a hard fork however.
P.S.: I'm gonna restart staking now but I'll do it more gently for now
Sorry, I corrected my message earlier, if it was wrong.
FFS? Really? Ok.
FFS? Really? Ok.
But you know - your "occasional contributions" were made into master branch of a main Slimcoin repo.
So I think I could make such "implications", cause it was mainly you, that were making contributions to the code in 2017.
Besides you have passes to the github repo of Slimcoin Project isn't it ?
https://github.com/orgs/slimcoin-project/people
Oh FFS. I've been candid. To little effect apparently. Perhaps my silence will speak louder.So I think I could make such "implications", cause it was mainly you, that were making contributions to the code in 2017.
Besides you have passes to the github repo of Slimcoin Project isn't it ?
https://github.com/orgs/slimcoin-project/people
Cheers
Graham
Yeah, sorry. But you know - your "occasional contributions" were made into master branch of a main Slimcoin repo.
So I think I could make such "implications", cause it was mainly you, that were making contributions to the code in 2017.
Besides you have passes to the github repo of Slimcoin Project isn't it ?
https://github.com/orgs/slimcoin-project/people
So I think I could make such "implications", cause it was mainly you, that were making contributions to the code in 2017.
Besides you have passes to the github repo of Slimcoin Project isn't it ?
https://github.com/orgs/slimcoin-project/people
Btw. @gjhiggins is making a little rest from main Slimcoin development direct contributions of code
Sorry, I must address the erroneous implication that I am engaged in "main Slimcoin development", especially in the context of discussions of upgrades to the codebase. I am an occasional contributor, that is as far as it can go given the primacy of my responsibility for the care of my disabled partner.Cheers
Graham
Yes, that's exactly what I meant, just I don't know how to read c++ code.
Thanks.
Btw. @gjhiggins is making a little rest from contributing to the master branch of Slimcoin git repo, making room for community contributions. He is going to develop further concept of ACME, and fuseki.
Thanks.
Btw. @gjhiggins is making a little rest from contributing to the master branch of Slimcoin git repo, making room for community contributions. He is going to develop further concept of ACME, and fuseki.
I've looked into the code now, and I think I get an impression what could be the problem. (Take into account that I'm no expert, and that confirmation of a developer of my interpretation would be a "must" before something is changed.)
Like Peercoin and Novacoin, Slimcoin relies on the concept of "chain trust". Clients will always select the chain with the highest trust to consider it the "best chain" (or "valid chain"). Each block has a "trust" value that is calculated in a section of main.cpp (search for "new protocol"), and the calculation is different for PoW/PoB and PoS blocks.
What's interesting for us is the calculation of PoS block trust:
This line is called every time when a PoS block is detected. It sets the "block trust" for PoS blocks basically to a value correlated directly with PoW difficulty. The higher the difficulty, the higher the "trust" of the block.
After that line, there are some mechanisms in place meant to ensure that there are not too many PoS blocks in a row. So the block trust is reduced to a third if:
However, if the difficulty is high enough, and hashrate drops temporarily, then the trust value of PoS blocks could be high enough even if it continuously stays at 1/9 of the initial chain trust value. Then big stakers (or a single staker with multiple accounts) could produce more than 12 blocks in a row, until miners catch up.
I would therefore propose a mechanism that further decreases the trust of PoS blocks or even reduces it to 0 if a certain number of PoS blocks in a row is detected.
For example, one could add the following line at the end of the section:
which means that there can never be more than 12 blocks PoS in a row (nPoWCount is the number of PoW blocks in the last 12 blocks).
Or one could reduce it further (e.g. bnNewTrust gets smaller directly proportional to nPoWCount. E.g. if the formula is:
a PoS block after 10 PoS blocks would already have 1(3*10)=1/30 of the chain trust of the first PoS block in the row, because additionally the "parent block is not PoW block" condition is fulfilled.
However, the first method (reducing trust to zero after 12 PoS blocks) would be additionally needed if the goal is to make never possible PoS minters "take over" the chain (e.g. after a permanent hashrate drop).
Both ways would not really affect the "profitability" of PoS minting, as after a single PoW block a PoS block would be permitted again (albeit with relatively low trust value).
This is only what I interpret from reviewing the code at a first glance, so I would like to see some comments on it, if my interpretation is correct. There may be missing parts in the "consensus puzzle". And obviously, a simulation would be needed to see if no side effects are to be expected.
PS: If my interpretation of hard and soft forks is correct, then this change could be implemented as a soft fork (with supermajority of blocks produced by client versions supporting the change). Old clients would not reject chains produced by new clients, but they could temporarily "fork away" if they mint too many PoS blocks in a row, that get rejected by new clients, so a high supermajority is needed.
PS2: Edited as in the initial version of the post were some mistakes and imprecisions, so always refer to this last version of the post
Like Peercoin and Novacoin, Slimcoin relies on the concept of "chain trust". Clients will always select the chain with the highest trust to consider it the "best chain" (or "valid chain"). Each block has a "trust" value that is calculated in a section of main.cpp (search for "new protocol"), and the calculation is different for PoW/PoB and PoS blocks.
What's interesting for us is the calculation of PoS block trust:
Code:
CBigNum bnNewTrust = (CBigNum(1)<<256) / (bnTarget + 1);
After that line, there are some mechanisms in place meant to ensure that there are not too many PoS blocks in a row. So the block trust is reduced to a third if:
- the parent block of the PoS block is not a PoW block
- there are less than 3 PoW blocks in the last 12 PoS blocks
However, if the difficulty is high enough, and hashrate drops temporarily, then the trust value of PoS blocks could be high enough even if it continuously stays at 1/9 of the initial chain trust value. Then big stakers (or a single staker with multiple accounts) could produce more than 12 blocks in a row, until miners catch up.
I would therefore propose a mechanism that further decreases the trust of PoS blocks or even reduces it to 0 if a certain number of PoS blocks in a row is detected.
For example, one could add the following line at the end of the section:
Code:
if (nPoWCount == 0)
return 0;
Or one could reduce it further (e.g. bnNewTrust gets smaller directly proportional to nPoWCount. E.g. if the formula is:
Code:
bnNewTrust = bnNewTrust / (12 - nPoWCount)
a PoS block after 10 PoS blocks would already have 1(3*10)=1/30 of the chain trust of the first PoS block in the row, because additionally the "parent block is not PoW block" condition is fulfilled.
However, the first method (reducing trust to zero after 12 PoS blocks) would be additionally needed if the goal is to make never possible PoS minters "take over" the chain (e.g. after a permanent hashrate drop).
Both ways would not really affect the "profitability" of PoS minting, as after a single PoW block a PoS block would be permitted again (albeit with relatively low trust value).
This is only what I interpret from reviewing the code at a first glance, so I would like to see some comments on it, if my interpretation is correct. There may be missing parts in the "consensus puzzle". And obviously, a simulation would be needed to see if no side effects are to be expected.
PS: If my interpretation of hard and soft forks is correct, then this change could be implemented as a soft fork (with supermajority of blocks produced by client versions supporting the change). Old clients would not reject chains produced by new clients, but they could temporarily "fork away" if they mint too many PoS blocks in a row, that get rejected by new clients, so a high supermajority is needed.
PS2: Edited as in the initial version of the post were some mistakes and imprecisions, so always refer to this last version of the post
Hello, Slimcoin community!
Even though I did some research (i.e. tried the Bitcoin Wiki), I still can figure out what that Proof of Burn thing is. Can someone please explain me in the simplest manner possible? ELI5?
I tried it here (well, may be more ELI15 than ELI5, but Proof of Burn is complicated, as you'll have "un-node" your mind a bit):Even though I did some research (i.e. tried the Bitcoin Wiki), I still can figure out what that Proof of Burn thing is. Can someone please explain me in the simplest manner possible? ELI5?
http://slimco.in/proof-of-burn-eli5/
tl;dr: Imagine you're buying "virtual mining hardware". Each burnt coin could be considered a virtual mining rig. So the more coins you burn, the more chances to find blocks you have.
@muf18: All these disproportions are very likely related to the fact that very few people are staking permanently. So a big stakeholder can easily dominate staking. If the optimized code allows staking with less hardware usage, then it could partly solve that problem.
However, as I wrote, I'll look into the consensus algorithm if it could be improved. For example, one could lower the "chain trust" formula more drastically if e.g. there are more than 5 PoS blocks in a row; in this case, even a big staker would not find more than that. However, one must carefully do the simulations with many different inputs before changing something.
If a hard fork is needed, then I would support combining this fix with a transition to the Peercoin 0.6 codebase.
Hello, Slimcoin community!
Even though I did some research (i.e. tried the Bitcoin Wiki), I still can figure out what that Proof of Burn thing is. Can someone please explain me in the simplest manner possible? ELI5?
Even though I did some research (i.e. tried the Bitcoin Wiki), I still can figure out what that Proof of Burn thing is. Can someone please explain me in the simplest manner possible? ELI5?
But as @iguanodon has said - this address isn't him https://chainz.cryptoid.info/slm/address.dws?SXYaGkxKjHGw96cMaHxjWGFDvyYvfoC87M.htm
And it's staking the most blocks for quite some time (>50% PoS blocks all the time).
We should know what address was @iguanodon staking, to came to any conclusion I think.
About disproportional influence of PoS minters, I have been saying for at least a year, when this problem started in july 2017, as far as I remember.
And it's staking the most blocks for quite some time (>50% PoS blocks all the time).
We should know what address was @iguanodon staking, to came to any conclusion I think.
About disproportional influence of PoS minters, I have been saying for at least a year, when this problem started in july 2017, as far as I remember.
Cool, so the PoS "mysterium" is at least partly solved ...
I believe the big influence your node @iguanodon1 had is caused by the fact that due to the high resource consumption most of the users are only staking when they think it's "worth it" - when they have enough old txouts.
I hope it can be achieved to incorporate the optimized code into the standard Slimcoin client. I'll test it as soon as I have time (I'm on Linux). If we can fix the PoS hardware resource consumption issue, that would bring more people to stake, and the influence of single nodes would be reduced, and the network more secure overall.
I hope also I find some time to look into the consensus mechanism (the "chain trust" calculation) to look if I discover a problem where strong PoS minters could have disproportional influence, like gjhiggins wrote.
I believe the big influence your node @iguanodon1 had is caused by the fact that due to the high resource consumption most of the users are only staking when they think it's "worth it" - when they have enough old txouts.
I hope it can be achieved to incorporate the optimized code into the standard Slimcoin client. I'll test it as soon as I have time (I'm on Linux). If we can fix the PoS hardware resource consumption issue, that would bring more people to stake, and the influence of single nodes would be reduced, and the network more secure overall.
I hope also I find some time to look into the consensus mechanism (the "chain trust" calculation) to look if I discover a problem where strong PoS minters could have disproportional influence, like gjhiggins wrote.
Sure, I will try to build it myself.
I know PoS rewards aren't depend on number of blocks produced, but still spamming network with more PoS blocks is making fragile balance between PoW/PoS and PoB, even more disturbed.
@iguano - I dont know, if you are on telegram/discord group, but I welcome you.
I also think that network is quite slow now, but it's mainly, because it is based on quite old PPC v0.5 (which is derivative from Bitcoin v0.6, AFAIK).
I know PoS rewards aren't depend on number of blocks produced, but still spamming network with more PoS blocks is making fragile balance between PoW/PoS and PoB, even more disturbed.
@iguano - I dont know, if you are on telegram/discord group, but I welcome you.
I also think that network is quite slow now, but it's mainly, because it is based on quite old PPC v0.5 (which is derivative from Bitcoin v0.6, AFAIK).
Building stuff on windows is such a pain 
I'm gonna have to set up the build environment first and get all the dependencies. I'm actually using a Linux VM to get around this.
It probably wouldn't help you with the orphans though. The last couple days, I've been getting orphan rates of 30-40% too. I think this happens because processing new blocks is too slow and needs to be optimized as well.
Also, in PoS, the number of blocks you generate should only slightly affect the rewards you get.
I'm gonna have to set up the build environment first and get all the dependencies. I'm actually using a Linux VM to get around this.It probably wouldn't help you with the orphans though. The last couple days, I've been getting orphan rates of 30-40% too. I think this happens because processing new blocks is too slow and needs to be optimized as well.
Quote
Besides if it's only optimizing the PoS code in the way of speed I could think of it like in PoW - built-in miner vs slimminer - normally nobody is using built-in miner anymore, cause it's too slow, and can't produce a block in a reasonable time.
Yeah, it's similar to PoW aside from the fact that once the PoS miner is fast enough, further speed improvements won't have an effect on your block-generating ability.Also, in PoS, the number of blocks you generate should only slightly affect the rewards you get.
I just took a closer look at my transaction history and it looks like my node actually stopped dominating around 2018-08-06 UTC.
It did produce quite a few orphans since that date though so the increased orphan count could be related to this.
Right now, https://chainz.cryptoid.info/slm/address.dws?SXYaGkxKjHGw96cMaHxjWGFDvyYvfoC87M.htm is getting most PoS blocks. (not me) They are spending a lot of old (>90d) txouts which gives them a lot of stake weight right now. I don't know if they are running an optimized version too or not. (This would be interesting to know though).
I did not restart staking on my node yet.
It did produce quite a few orphans since that date though so the increased orphan count could be related to this.
Right now, https://chainz.cryptoid.info/slm/address.dws?SXYaGkxKjHGw96cMaHxjWGFDvyYvfoC87M.htm is getting most PoS blocks. (not me) They are spending a lot of old (>90d) txouts which gives them a lot of stake weight right now. I don't know if they are running an optimized version too or not. (This would be interesting to know though).
I did not restart staking on my node yet.
Quote
Developers work in their own forks, then submit pull requests when they think their feature or bug fix is ready.
I did not submit a pull request because I don't think that my code is ready in its current state: Quote
It's probably not quite suitable for general use currently as I hardcoded some constants that should probably be set dynamically based on the amount of SLM in your wallet, the number of UTXOs in your wallet and the current and minimum staking difficulty: https://github.com/iguanodon1/Slimcoin/blob/optimized-pos/src/wallet.cpp#L1627
Also, I've been too lazy to properly test the code.
Also, I've been too lazy to properly test the code.
Can you make a binary version for Windows of your test PoS optimized code ?
I want to try and test it, if it would help me with orphans, cause I'm staking normally, but I get from time to time a load of orphans in a row, then back to normal, maybe this could optimize it.
Besides if it's only optimizing the PoS code in the way of speed I could think of it like in PoW - built-in miner vs slimminer - normally nobody is using built-in miner anymore, cause it's too slow, and can't produce a block in a reasonable time.
Just I'm curious enough, if consensus for PoS is optimized to see that there is more blocks submitted correctly, and is correcting diff for PoS (cause I still believe that there is too many PoS blocks currently being produced - it should be lesser imo, cause it's breaking target block time, and is probably making PoW and PoB blocks producing less rewarding, than it should be).
I just took a closer look at my transaction history and it looks like my node actually stopped dominating around 2018-08-06 UTC.
It did produce quite a few orphans since that date though so the increased orphan count could be related to this.
Right now, https://chainz.cryptoid.info/slm/address.dws?SXYaGkxKjHGw96cMaHxjWGFDvyYvfoC87M.htm is getting most PoS blocks. (not me) They are spending a lot of old (>90d) txouts which gives them a lot of stake weight right now. I don't know if they are running an optimized version too or not. (This would be interesting to know though).
I did not restart staking on my node yet.
It did produce quite a few orphans since that date though so the increased orphan count could be related to this.
Right now, https://chainz.cryptoid.info/slm/address.dws?SXYaGkxKjHGw96cMaHxjWGFDvyYvfoC87M.htm is getting most PoS blocks. (not me) They are spending a lot of old (>90d) txouts which gives them a lot of stake weight right now. I don't know if they are running an optimized version too or not. (This would be interesting to know though).
I did not restart staking on my node yet.
Quote
Developers work in their own forks, then submit pull requests when they think their feature or bug fix is ready.
I did not submit a pull request because I don't think that my code is ready in its current state: Quote
It's probably not quite suitable for general use currently as I hardcoded some constants that should probably be set dynamically based on the amount of SLM in your wallet, the number of UTXOs in your wallet and the current and minimum staking difficulty: https://github.com/iguanodon1/Slimcoin/blob/optimized-pos/src/wallet.cpp#L1627
Also, I've been too lazy to properly test the code.
Also, I've been too lazy to properly test the code.
Jump to: