Bitcoin Forum
June 17, 2019, 08:08:50 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 [117] 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 »
  Print  
Author Topic: Slimcoin | First Proof of Burn currency | Decentralized Web  (Read 116684 times)
dzarmush
Legendary
*
Offline Offline

Activity: 1582
Merit: 1001


View Profile
August 08, 2018, 05:18:09 AM
 #2321

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.

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.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1560802130
Hero Member
*
Offline Offline

Posts: 1560802130

View Profile Personal Message (Offline)

Ignore
1560802130
Reply with quote  #2

1560802130
Report to moderator
1560802130
Hero Member
*
Offline Offline

Posts: 1560802130

View Profile Personal Message (Offline)

Ignore
1560802130
Reply with quote  #2

1560802130
Report to moderator
gjhiggins
Legendary
*
Offline Offline

Activity: 1652
Merit: 1060



View Profile WWW
August 08, 2018, 08:08:19 AM
 #2322

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
Sr. Member
****
Offline Offline

Activity: 756
Merit: 308


View Profile
August 08, 2018, 10:55:28 AM
 #2323

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

Activity: 1652
Merit: 1060



View Profile WWW
August 08, 2018, 11:16:20 AM
 #2324

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
Jr. Member
*
Offline Offline

Activity: 98
Merit: 2


View Profile
August 08, 2018, 11:29:08 AM
 #2325

No idea how i have never heard of this. I like the proof of burn concept a lot.
muf18
Sr. Member
****
Offline Offline

Activity: 756
Merit: 308


View Profile
August 08, 2018, 03:13:05 PM
 #2326

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
Legendary
*
Offline Offline

Activity: 1652
Merit: 1060



View Profile WWW
August 08, 2018, 05:57:58 PM
 #2327

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
Sr. Member
****
Offline Offline

Activity: 756
Merit: 308


View Profile
August 08, 2018, 07:44:04 PM
 #2328

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

Activity: 9
Merit: 2


View Profile
August 09, 2018, 04:34:55 PM
 #2329

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 Smiley
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 Smiley It didn't blow up in my face yet though.
gjhiggins
Legendary
*
Offline Offline

Activity: 1652
Merit: 1060



View Profile WWW
August 09, 2018, 05:23:07 PM
 #2330

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
Sr. Member
****
Offline Offline

Activity: 756
Merit: 308


View Profile
August 09, 2018, 05:28:45 PM
Last edit: August 09, 2018, 05:50:30 PM by muf18
 #2331

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 Smiley
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 Smiley 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
Newbie
*
Offline Offline

Activity: 9
Merit: 2


View Profile
August 10, 2018, 04:08:40 AM
Merited by psycodad (1)
 #2332

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
Legendary
*
Offline Offline

Activity: 1652
Merit: 1060



View Profile WWW
August 10, 2018, 06:59:44 AM
 #2333

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
Jr. Member
*
Offline Offline

Activity: 71
Merit: 1


View Profile
August 10, 2018, 07:48:13 AM
 #2334

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
Hero Member
*****
Offline Offline

Activity: 883
Merit: 525


精神分析的爸


View Profile
August 10, 2018, 07:57:28 AM
 #2335

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


Protestatio facto contraria non valet.
keliokan
Jr. Member
*
Offline Offline

Activity: 71
Merit: 1


View Profile
August 10, 2018, 08:20:40 AM
 #2336

The increase of orphan blocks could be related to this ?
K.
gjhiggins
Legendary
*
Offline Offline

Activity: 1652
Merit: 1060



View Profile WWW
August 10, 2018, 08:30:06 AM
 #2337

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
Newbie
*
Offline Offline

Activity: 9
Merit: 2


View Profile
August 10, 2018, 09:18:54 AM
 #2338

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.

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.

muf18
Sr. Member
****
Offline Offline

Activity: 756
Merit: 308


View Profile
August 10, 2018, 09:25:40 AM
 #2339

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.

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.



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
Newbie
*
Offline Offline

Activity: 9
Merit: 2


View Profile
August 10, 2018, 10:07:09 AM
 #2340

Building stuff on windows is such a pain Sad 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.
Pages: « 1 ... 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 [117] 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!