Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 43. (Read 137085 times)

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

The increase of orphan blocks could be related to this ?
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

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.

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

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.

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?

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

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.

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

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

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

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

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

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

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://bitcointalksearch.org/user/yyz13857180757-1080133
- "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

It's up to everybody, up to us. Unfortunately the whole market is down, people have losses instead of gains, so there's not much money for marketing. Let's hope it'll change soon so we'll have more resources.

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.

Editted and updated topic at https://cryptocurrencytalk.com/topic/11782-slimcoin-first-proof-of-burn-currency-decentralized-web/

Updated important files: https://github.com/muf18/Slimcoin-important-files

Slimcoin Wallet AIO (block 1461500) : https://mega.nz/#!hq4T1AbY!4O5w3WWWQmRMfdoyxCY1_Hwfgs0fUW0lNJ2gsi_i4jQ

Is there anywhere MacOS binary of 0.5.1 version (which had fixed client, which wouldn't crash after receving/calculating burn hashes) ?

https://www.reddit.com/r/slimcoin/comments/955xcg/development_of_slimcoin/

With little time and new explorer with great features we can estimate, which wallets are known to be wallets of Coinsmarkets scammers.

https://chainz.cryptoid.info/slm/wallet.dws?75580.htm

I'm 99% this is for sure wallet of them.
So they hold in on 106K of SLM. Great for another scammers... I'm sorry I even messaged about listing us, it's my fault, I didn't research it enough.
I have seen that this exchange has strange UI/UX, but I thought that 1+ year experiance is "good enough" - it isn't.
I'm very sorry for this. That shouldn't happen. That's why now, when I inquiry any exchange, I do it very carefully, and don't go with some new, untrusted, and unknown exchanges.
About freiexchange - I'm confident enough to say, they rather should be trusted, they are supporting as coin similar to us in terms of marketcap, and they have running this exchange for almost 2 years now.
I don't know about Novaexchange now - it's in new hands, they say it's in "better hands", but I can't say anything about it really.

Btw. - blocks are faster then they should - averaging on about 75 sec.

https://chainz.cryptoid.info/slm/#!overview