Slimcoin | First Proof of Burn currency | Decentralized Web

[d5000]

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.

[muf18]

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.

[RuSS512]

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?

[d5000]

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):

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.

[d5000]

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:

Code:

CBigNum bnNewTrust = (CBigNum(1)<<256) / (bnTarget + 1);

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:

• 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

If both conditions are met, chain trust gets reduced to 1/9 of the value of the first PoW block in the row.

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;

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:

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

[muf18]

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.

[gjhiggins]

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

[muf18]

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

[gjhiggins]

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.

Cheers

Graham

[muf18]

Sorry, I corrected my message earlier, if it was wrong.
FFS? Really? Ok.

[iguanodon1]

@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:

Code:

CBigNum bnNewTrust = (CBigNum(1)<<256) / (bnTarget + 1);

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:

• 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

If both conditions are met, chain trust gets reduced to 1/9 of the value of the first PoW block in the row.

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.

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));

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)

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 

[d5000]

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".

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.

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));

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.

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.

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).

[muf18]

@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:

Code:

CBigNum bnNewTrust = (CBigNum(1)<<256) / (bnTarget + 1);

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:

• 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

If both conditions are met, chain trust gets reduced to 1/9 of the value of the first PoW block in the row.

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.

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));

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)

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.

[iguanodon1]

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".

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.

I think so. Not entirely sure though.

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.

Yes, this would require a hard fork since it decreases the difficulty of blocks that are accepted.

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.
 

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.

[d5000]

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.

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.

I understand. The "declining chain trust curve" could be designed "smoother" so only the last ones of every 12-block-group drastically lose trust, so this problem can be mitigated. The goal being ~8-11 PoS blocks per PoW block, until a hard fork can be planned.

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.

[ZellaAnders]

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?

[NoFoodOnlyEnergy]

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?

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?

kudos to the botbois for at least producing coherent sentences now

[d5000]

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?

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?

kudos to the botbois for at least producing coherent sentences now

I guess the first one is a real user, maybe he's trying to increase activity, but at least he asked a coherent and legitimate question (if he didn't copy from an ancient post). (He could have googled "Proof of Burn ELI5", but ok). ZellaAnders is obviously a simple copy-and-paste bot. It didn't even change a single letter (well, at least not visibly, maybe there's an I for an l somewhere)  Have already reported it.

[gjhiggins]

I guess the first one is a real user, maybe he's trying to increase activity, but at least he asked a coherent and legitimate question (if he didn't copy from an ancient post).

A quick browse of the RuSS512 account's posting history affords some opportunity for "reverse social engineering" (aka, "I see what you did there").

Cheers

Graham

[muf18]

I updated http://slimco.in/ content.

Will do more in the week.