Slimcoin | First Proof of Burn currency | Decentralized Web

[gjhiggins]

Obviously, people are interested in the development of Slimcoin, and the team must seriously consider the future of the project.It is necessary for the team to strengthen the market value management.

Don't be misled, the initial account farming exercise was successful, a substantial number of noob accounts have been promoted to higher levels. A quick review of this a/c posting history reveals it as a bot:

https://bitcointalk.org/index.php?action=profile;u=1080133;sa=showPosts
- "QRL this coin can be held for a long time, the technical content is still very high. The prospect of QRL project is very bright. This project is worth your expectation."
- "There is a huge market space for the development of the block chain in the medical service industry. The ATLANTICO project team should make further efforts to increase the market publicity."
- Although the fragmentation technology of Zilliqa project is excellent, the current price of ZIL basically follows the overall trend of the encrypted money market.

Simcoin's permutation reads:
"Obviously, people are interested in the development of ${COIN}, and the team must seriously consider ${OBJ5958} .It is necessary for the team to ${TACTIC4635}."

The Higgins' dictum; "For maximum discrimination, Turing tests must be performed offline and face-to-face."

Cheers

Graham

[muf18]

Yep it's a bot, scrypted answers, my questions is - why they even respond to our thread?
What are their intentions ?

[gjhiggins]

What are their intentions ?

Merely to continue the farming in order to progress a/c promotion to more exalted status levels, to be better able to exploit the as-yet-not-clued-in. The successful broadscale compaign to compromise the pseudonym system is very likely the reason why people are gradually abandoning bitcointalk in favour of Discord/Slack,etc. The bitcointalk upgrade project has long passed from its "poorly managed" origins, has sped past "failing", "bit of a scandal", "outright joke" and is now very firmly embedded in the category: "obviated by irrelevance".

Cheers

Graham

[FreeEarnsActivist]

No idea how i have never heard of this. I like the proof of burn concept a lot.

[muf18]

What are their intentions ?

Merely to continue the farming in order to progress a/c promotion to more exalted status levels, to be better able to exploit the as-yet-not-clued-in. The successful broadscale compaign to compromise the pseudonym system is very likely the reason why people are gradually abandoning bitcointalk in favour of Discord/Slack,etc. The bitcointalk upgrade project has long passed from its "poorly managed" origins, has sped past "failing", "bit of a scandal", "outright joke" and is now very firmly embedded in the category: "obviated by irrelevance".

Cheers

Graham

True, bitcointalk is getting out from users into bots and spammers (and this process is at least from 2014-2015).
Btw. do you know why we arent having target block time, but instead it's faster ? 6 days average is about 73.5 second. Maybe we should change target block time to 75 second ? :p

[gjhiggins]

Btw. do you know why we arent having target block time, but instead it's faster ? 6 days average is about 73.5 second. Maybe we should change target block time to 75 second ? :p

Not off the top of my head, no. The answer is probably somewhere in the complexities of maintaining the designed PoB/PoW/PoS ratio of emissions.

Cheers

Graham

[muf18]

Yep that's really strange. I think there are more PoS blocks than it should be, shortening avg block time.

[iguanodon1]

Yep that's really strange. I think there are more PoS blocks than it should be, shortening avg block time.

Perhaps part of the reason is that I have been monkeying around with the PoS code. The old PoS code is slow and has been choking up pretty much all the time. It also created more and more txouts, causing it to choke up even more. Thus, I optimized the code for better performance and changed the utxo splitting/consolidation logic to create fewer txouts.

The result is that my computer can now actually keep up with computing all those PoS hashes
Since I'm running this code on a fairly sizable stack of SLM, this caused significant block interval fluctuations. I haven't looked at the difficulty adjustment algorithm but I suspect that those large fluctuations made it set the average PoS difficulty below what would be required for a 90s block time during those fluctuations. Perhaps the adjustment algo decreases the difficulty more eagerly than increasing it...

My modified PoS code is available at https://github.com/iguanodon1/Slimcoin/tree/optimized-pos
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 It didn't blow up in my face yet though.

[gjhiggins]

Yep that's really strange. I think there are more PoS blocks than it should be, shortening avg block time.

Perhaps part of the reason is that I have been monkeying around with the PoS code.

I do hope not. If significant changes to emissions behaviour actually can be wrought by changing a single client, independently of the consensus, the implication is that the integrity of the blockchain is compromised.

Cheers

Graham

[muf18]

Yep that's really strange. I think there are more PoS blocks than it should be, shortening avg block time.

Perhaps part of the reason is that I have been monkeying around with the PoS code. The old PoS code is slow and has been choking up pretty much all the time. It also created more and more txouts, causing it to choke up even more. Thus, I optimized the code for better performance and changed the utxo splitting/consolidation logic to create fewer txouts.

The result is that my computer can now actually keep up with computing all those PoS hashes
Since I'm running this code on a fairly sizable stack of SLM, this caused significant block interval fluctuations. I haven't looked at the difficulty adjustment algorithm but I suspect that those large fluctuations made it set the average PoS difficulty below what would be required for a 90s block time during those fluctuations. Perhaps the adjustment algo decreases the difficulty more eagerly than increasing it...

My modified PoS code is available at https://github.com/iguanodon1/Slimcoin/tree/optimized-pos
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 It didn't blow up in my face yet though.

From when did you run this code? Exactly date is really needed. Besides how is it possible to run custom PoS code without forking ? Cause I suppose different code to current codebase and with such important consensus as PoS in Slimcoin should mean that your client should be blacklisted and your blocks submitted shouldnt be approved meaning that it would create fork of Slimcoin.

Besides @iguanodon1 - can you turn off your client for at least one day that we could see, if diff will re-adjust and it will come into target block time again?

[iguanodon1]

I've been running some kind of optimized PoS code for months. Back then, it didn't occur to me that the impact on the network would be this large...
The modifications I made are just performance improvements. There are no exploits in there and my blocks conform to the normal consensus rules. (The combine/split changes I made actually reduce the possible "PoS block production power" by creating txouts larger than what would be optimal if it weren't for the performance problems.)

Every node doing PoS staking needs to compute one PoS hash per second per wallet UTXO. Also, in order to maximize the blocks produced, the staking balance needs to be split into lots of small txouts so that each individual txout accumulate significant weight before being used in minting a block.
I believe that right now, many (most? all?) Slimcoin nodes on the network can't keep up with computing this many hashes each second due to the slow PoS code.
If this is true, most staking nodes are using a tiny fraction of the staking power their wallets would allow them to have. Thus, when my node actually manages to stake close to full capacity, it can generate more blocks than the other nodes. The fix would be to upgrade those slower nodes' PoS code so they can use their full staking capacity too.

I've turned off staking on my node for now so we can see how large the impact is going to be.

[gjhiggins]

it didn't occur to me that the impact on the network would be this large

The point that is currently escaping you is that if one node can significantly impact the network, then the coin's consensus mechanism is flawed.

Cheers

Graham

[keliokan]

The PoS went back up again.
Did you re-started the stacking on your node ?

86% for the last 100 blocks. What is the point to keep this. It would be nice to shut it completely or to share the code (for a implantation in a new wallet version).

K.

I've been running some kind of optimized PoS code for months. Back then, it didn't occur to me that the impact on the network would be this large...
The modifications I made are just performance improvements. There are no exploits in there and my blocks conform to the normal consensus rules. (The combine/split changes I made actually reduce the possible "PoS block production power" by creating txouts larger than what would be optimal if it weren't for the performance problems.)

Every node doing PoS staking needs to compute one PoS hash per second per wallet UTXO. Also, in order to maximize the blocks produced, the staking balance needs to be split into lots of small txouts so that each individual txout accumulate significant weight before being used in minting a block.
I believe that right now, many (most? all?) Slimcoin nodes on the network can't keep up with computing this many hashes each second due to the slow PoS code.
If this is true, most staking nodes are using a tiny fraction of the staking power their wallets would allow them to have. Thus, when my node actually manages to stake close to full capacity, it can generate more blocks than the other nodes. The fix would be to upgrade those slower nodes' PoS code so they can use their full staking capacity too.

I've turned off staking on my node for now so we can see how large the impact is going to be.

[psycodad]

The PoS went back up again.
Did you re-started the stacking on your node ?

86% for the last 100 blocks. What is the point to keep this. It would be nice to shut it completely or to share the code (for a implantation in a new wallet version).

K.

I didn't go through iguanodon1's code but he gave a github URL with his POS-optimized code that he claims to use:

https://github.com/iguanodon1/Slimcoin/tree/optimized-pos

[keliokan]

The increase of orphan blocks could be related to this ?
K.

[gjhiggins]

I didn't go through iguanodon1's code but he gave a github URL with his POS-optimized code

I haven't either. Nor should anyone need to. The docs are quite clear:

Repository Guidelines
Developers work in their own forks, then submit pull requests when they think their feature or bug fix is ready.
If it is a simple/trivial/non-controversial change, then one of the development team members simply pulls it.
If it is a more complicated or potentially controversial change, then the change may be discussed in the pull request, or the requester may be asked to start a discussion SlimCoin Talk for a broader community discussion.
The patch will be accepted if there is broad consensus that it is a good thing. Developers should expect to rework and resubmit patches if they don't match the project's coding conventions (see coding.txt) or are controversial.
From time to time a pull request will become outdated. If this occurs, and the pull is no longer automatically mergeable; a comment on the pull will be used to issue a warning of closure. Pull requests closed in this manner will have their corresponding issue labeled 'stagnant'.


All a bit moot now that the speed-up is out in the wild.

Cheers

Graham

[iguanodon1]

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.

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:

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.

[muf18]

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.

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:

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.

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

[iguanodon1]

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.

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.

[muf18]

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