Topic: [ANN] SpreadCoin | True Decentralization (No Pools) | Testing New Masternodes - page 362. (Read 810079 times)
December 17, 2014, 11:42:11 PM
Mr. Spread, I mean ZERO disrespect when I ask this and will definitely not push the issue as it's your coin... but would you be open to a name change for Spreadcoin at some point? One of the biggest arguments against Darkcoin by many is its' name. Spreadcoin is going to have many of the same features as DRK (and maybe even some improvements by the sounds of it!) BUT in my opinion, "Spreadcoin" isn't the greatest name ever for a coin, especially for a coin I feel can be a top 3-10 market cap coin within a year. Again, I mean no disrespect and if you love the current name, I won't mention it again. But if you are open to a name change, I think it could bring even more attention to this coin.
December 17, 2014, 11:21:30 PM
Let's see what happens.
Good to see you over here. 
Looks like I am going to have some serious competition as I attempt to add to my position.
December 17, 2014, 10:48:38 PM
It's too hard to find a block now 
But I'll keep mining this excellent coin
But I'll keep mining this excellent coin
December 17, 2014, 09:15:26 PM
May I post a suggestion here?
Since some DRK features are implemented, and some could be improved upon, the original concept for the Darkcoin masternodes (RC2/RC3 releases) involved a protocol-level enforcement of the masternode payments. The problem with these releases was that there was some kind of bug that triggered sporadic network forking by misbehaving nodes or mining clients. The consensus wasn't working as it should.
In a sense, Darkcoin tried to use a dual consensus for every block: One for the transactions / mining, and one for the masternode payout. This didn't work as planned (there were sporadic forks of the network) and DarkSend development was lagging - so a workaround system was created instead that was "safer" and relieved some of the price speculation (it was the period of the great pump - and all eyes were on DRK news and how something would succeed or fail).
In that payment system (an evolution of which, is the current system of MN payments) the pools decided whether to pay or not in a semi-voluntary scheme. If a pool wanted to cheat payment, they could. The strategy was to shame the pools that "cheated" and it worked to compliance levels of 80-90%. The added threat of "enforcement" where Evan would "flip the switch" to fork off the non-compliant pools was also added as an extra measure. However, in my view, this is not the ideal solution to the problem. Rather, it should be done like it initially was conceived so that misbehaving clients are simply forked by themselves out of the network. No centralization / enforcement switch, no need for asking pools to play nice etc etc.
Perhaps the dev wants to give it a look* and see if he can come up with a system that works and which is free of forking bugs. It could also be implemented by DRK if successful, and it would also give added credibility to SPR itself for improving something in a significant way. The good thing with SPR is that, unlike DRK which is more mature, it can risk multiple hard forks to try things out.
* Perhaps the RC2/RC3 bugged solutions of DRK where there was a voting system in place to decide the MN payments are not the ideal concept for this implementation and another idea can be used altogether.
I think it should be based on the majority of the hashrate. If the majority of the hashrate agrees on masternode payments then others should be forced to accept it even if they don't agree with it and do not create forks. The only way to cheat would be 51% attack but with 51% you can do much worse things anyway.Since some DRK features are implemented, and some could be improved upon, the original concept for the Darkcoin masternodes (RC2/RC3 releases) involved a protocol-level enforcement of the masternode payments. The problem with these releases was that there was some kind of bug that triggered sporadic network forking by misbehaving nodes or mining clients. The consensus wasn't working as it should.
In a sense, Darkcoin tried to use a dual consensus for every block: One for the transactions / mining, and one for the masternode payout. This didn't work as planned (there were sporadic forks of the network) and DarkSend development was lagging - so a workaround system was created instead that was "safer" and relieved some of the price speculation (it was the period of the great pump - and all eyes were on DRK news and how something would succeed or fail).
In that payment system (an evolution of which, is the current system of MN payments) the pools decided whether to pay or not in a semi-voluntary scheme. If a pool wanted to cheat payment, they could. The strategy was to shame the pools that "cheated" and it worked to compliance levels of 80-90%. The added threat of "enforcement" where Evan would "flip the switch" to fork off the non-compliant pools was also added as an extra measure. However, in my view, this is not the ideal solution to the problem. Rather, it should be done like it initially was conceived so that misbehaving clients are simply forked by themselves out of the network. No centralization / enforcement switch, no need for asking pools to play nice etc etc.
Perhaps the dev wants to give it a look* and see if he can come up with a system that works and which is free of forking bugs. It could also be implemented by DRK if successful, and it would also give added credibility to SPR itself for improving something in a significant way. The good thing with SPR is that, unlike DRK which is more mature, it can risk multiple hard forks to try things out.
* Perhaps the RC2/RC3 bugged solutions of DRK where there was a voting system in place to decide the MN payments are not the ideal concept for this implementation and another idea can be used altogether.
I'm against introducing any centralization to SpreadCoin. "Hey, this is a decentralized currency but I have a magic switch with which I can turn on and off some major feature". This can be employed to avoid possible issues when introducing new features but not as a long term solution for any problem.
Yes, that's my thoughts on this also. DRK initially went to do it the hashrate way / protocol way, through a voting mechanism where nodes would collect "votes" and then get paid in the next block once their vote count had reached the predetermined limit (6 votes IIRC). But it proved problematic (sporadic forking of the network) in practice and debugging it while in production was attracting all sort of negative attention. Thus it was consequently abandoned in favor of the "spork". So there is definitely room for improvement there.
December 17, 2014, 08:58:03 PM
Coins now on my radar
December 17, 2014, 08:45:55 PM
Don't think too many people are gonna be selling on a gem like this coin unfortunately not for cheap I'm still trying to get some buy orders filled since 4 days ago but if anyone feels generous they can always donate to : SdpQYCKXV8MQeKE6MSCK2J5JZP8sc3bxAA or if anyone needs any work done I would gladly do it for some more SpreadCoin. Just let the NoobKidOnTheBlock know what needs to be done?
I'm still trying to get some buy orders filled since 4 days ago but if anyone feels generous they can always donate to : SdpQYCKXV8MQeKE6MSCK2J5JZP8sc3bxAA or if anyone needs any work done I would gladly do it for some more SpreadCoin. Just let the NoobKidOnTheBlock know what needs to be done?I will be generous and donate you 2 SPR
Hope this makes you happy, my bagholding wallet won't see market any time soon
Truly appreciate that and much thanks and praise that they still have some good folks left in CryptoWorld!! Thanks again I really appreciate that!! Good Strong Community growing here which is awesome for this coin 
Cheers December 17, 2014, 08:15:59 PM
Don't think too many people are gonna be selling on a gem like this coin unfortunately not for cheap I'm still trying to get some buy orders filled since 4 days ago but if anyone feels generous they can always donate to : SdpQYCKXV8MQeKE6MSCK2J5JZP8sc3bxAA or if anyone needs any work done I would gladly do it for some more SpreadCoin. Just let the NoobKidOnTheBlock know what needs to be done?
I'm still trying to get some buy orders filled since 4 days ago but if anyone feels generous they can always donate to : SdpQYCKXV8MQeKE6MSCK2J5JZP8sc3bxAA or if anyone needs any work done I would gladly do it for some more SpreadCoin. Just let the NoobKidOnTheBlock know what needs to be done?I will be generous and donate you 2 SPR
Hope this makes you happy, my bagholding wallet won't see market any time soon
Truly appreciate that and much thanks and praise that they still have some good folks left in CryptoWorld!! Thanks again December 17, 2014, 07:50:35 PM
Hey guys, is there any miner that does more than 1500kH/s with 750ti??
December 17, 2014, 07:46:12 PM
We should all go on IRC. Lots of us are online.
December 17, 2014, 07:42:26 PM
Don't think too many people are gonna be selling on a gem like this coin unfortunately not for cheap I'm still trying to get some buy orders filled since 4 days ago but if anyone feels generous they can always donate to : SdpQYCKXV8MQeKE6MSCK2J5JZP8sc3bxAA or if anyone needs any work done I would gladly do it for some more SpreadCoin. Just let the NoobKidOnTheBlock know what needs to be done?
I'm still trying to get some buy orders filled since 4 days ago but if anyone feels generous they can always donate to : SdpQYCKXV8MQeKE6MSCK2J5JZP8sc3bxAA or if anyone needs any work done I would gladly do it for some more SpreadCoin. Just let the NoobKidOnTheBlock know what needs to be done?I will be generous and donate you 2 SPR
Hope this makes you happy, my bagholding wallet won't see market any time soon
December 17, 2014, 07:39:56 PM
Let's see what happens.
December 17, 2014, 07:28:07 PM
Is there any Spreadcoin Wallet that works on a gnu/linux terminal ?
Thanks!
Thanks!
You can grab the source (link in OP) and build the daemon same as any other bitcoin-derived coin:
cd src/
make -f makefile.unix
...wait a few mins...
./spreadcoind or ./spreadcoind help if you're unfamiliar with the standard commands
Dependency info etc. in /doc/build-unix.md
I thought my screen needed cleaning when I saw your sig
How many of these bad boys can I mine in 24hrs with an AMD R9 290?
Cheers.
Well after me boring the tits off everyone about the utter uselessness of pooled mining in the Darkcoin thread for months, when I stumbled on Spreadcoin which does exactly what I have been arguing Darkcoin should do, it would have been hypocritical not to take a modest position and support SPR. Having seen Mr Spread behave honestly, openly and competently as the developer was icing on the cake.
Then I learned that SPR was based on the DRK codebase. So I extended my position somewhat.
Then Mr Spread decided to implement some advanced DRK features... so I - well, you can guess.
Your 290 should get you a handful of blocks a week...
So, running 20 R9's, using GB power costs, would mean it is cheaper to buy 10k SPR then mine them over a 4 week period?
December 17, 2014, 07:28:03 PM
And it's roughly 1 SPR per day. It has little sense with pools or without them. SPR blocks are generated pretty fast, every minute. So somebody with 1/1000 of net hashrate still can get the block about every 2/3 of the day. And even with 1/10000 it's every 7 days. When (if) price will go up, mining will be even harder, sure. But I like the idea that only dedicated miners will mine SPR, without switching on it for quick profit.
Idea of 'poolless' mining is good for coin security, even if it is not easy for miners. And honestly, I think sooner or later there will be workaround, there are some ideas ITT how to do it. But Mr. Spread is a good programmer and very good person. I think SPR will have a bright future.
Idea of 'poolless' mining is good for coin security, even if it is not easy for miners. And honestly, I think sooner or later there will be workaround, there are some ideas ITT how to do it. But Mr. Spread is a good programmer and very good person. I think SPR will have a bright future.
If there's ever a workaround that doesn't get instantly fixed, SPR will tank in value as it becomes just another short lived short term BTC/fiat hose for the ADD instadumpers, ie. 99.99% of all miners.
CheersYou strong hand bastards!!! Have some compassion and sell sell sell!
I'm still trying to get some buy orders filled since 4 days ago but if anyone feels generous they can always donate to : SdpQYCKXV8MQeKE6MSCK2J5JZP8sc3bxAA or if anyone needs any work done I would gladly do it for some more SpreadCoin. Just let the NoobKidOnTheBlock know what needs to be done? December 17, 2014, 07:23:11 PM
And it's roughly 1 SPR per day. It has little sense with pools or without them. SPR blocks are generated pretty fast, every minute. So somebody with 1/1000 of net hashrate still can get the block about every 2/3 of the day. And even with 1/10000 it's every 7 days. When (if) price will go up, mining will be even harder, sure. But I like the idea that only dedicated miners will mine SPR, without switching on it for quick profit.
Idea of 'poolless' mining is good for coin security, even if it is not easy for miners. And honestly, I think sooner or later there will be workaround, there are some ideas ITT how to do it. But Mr. Spread is a good programmer and very good person. I think SPR will have a bright future.
Idea of 'poolless' mining is good for coin security, even if it is not easy for miners. And honestly, I think sooner or later there will be workaround, there are some ideas ITT how to do it. But Mr. Spread is a good programmer and very good person. I think SPR will have a bright future.
If there's ever a workaround that doesn't get instantly fixed, SPR will tank in value as it becomes just another short lived short term BTC/fiat hose for the ADD instadumpers, ie. 99.99% of all miners.
CheersYou strong hand bastards!!! Have some compassion and sell sell sell!
I'm still trying to get some buy orders filled since 4 days ago but if anyone feels generous they can always donate to : SdpQYCKXV8MQeKE6MSCK2J5JZP8sc3bxAA or if anyone needs any work done I would gladly do it for some more SpreadCoin. Just let the NoobKidOnTheBlock know what needs to be done? December 17, 2014, 06:42:54 PM
Is there any Spreadcoin Wallet that works on a gnu/linux terminal ?
Thanks!
Thanks!
You can grab the source (link in OP) and build the daemon same as any other bitcoin-derived coin:
cd src/
make -f makefile.unix
...wait a few mins...
./spreadcoind or ./spreadcoind help if you're unfamiliar with the standard commands
Dependency info etc. in /doc/build-unix.md
I thought my screen needed cleaning when I saw your sig
How many of these bad boys can I mine in 24hrs with an AMD R9 290?
Cheers.
Well after me boring the tits off everyone about the utter uselessness of pooled mining in the Darkcoin thread for months, when I stumbled on Spreadcoin which does exactly what I have been arguing Darkcoin should do, it would have been hypocritical not to take a modest position and support SPR. Having seen Mr Spread behave honestly, openly and competently as the developer was icing on the cake.
Then I learned that SPR was based on the DRK codebase. So I extended my position somewhat.
Then Mr Spread decided to implement some advanced DRK features... so I - well, you can guess.
Your 290 should get you a handful of blocks a week...
December 17, 2014, 06:27:08 PM
May I post a suggestion here?
Since some DRK features are implemented, and some could be improved upon, the original concept for the Darkcoin masternodes (RC2/RC3 releases) involved a protocol-level enforcement of the masternode payments. The problem with these releases was that there was some kind of bug that triggered sporadic network forking by misbehaving nodes or mining clients. The consensus wasn't working as it should.
In a sense, Darkcoin tried to use a dual consensus for every block: One for the transactions / mining, and one for the masternode payout. This didn't work as planned (there were sporadic forks of the network) and DarkSend development was lagging - so a workaround system was created instead that was "safer" and relieved some of the price speculation (it was the period of the great pump - and all eyes were on DRK news and how something would succeed or fail).
In that payment system (an evolution of which, is the current system of MN payments) the pools decided whether to pay or not in a semi-voluntary scheme. If a pool wanted to cheat payment, they could. The strategy was to shame the pools that "cheated" and it worked to compliance levels of 80-90%. The added threat of "enforcement" where Evan would "flip the switch" to fork off the non-compliant pools was also added as an extra measure. However, in my view, this is not the ideal solution to the problem. Rather, it should be done like it initially was conceived so that misbehaving clients are simply forked by themselves out of the network. No centralization / enforcement switch, no need for asking pools to play nice etc etc.
Perhaps the dev wants to give it a look* and see if he can come up with a system that works and which is free of forking bugs. It could also be implemented by DRK if successful, and it would also give added credibility to SPR itself for improving something in a significant way. The good thing with SPR is that, unlike DRK which is more mature, it can risk multiple hard forks to try things out.
* Perhaps the RC2/RC3 bugged solutions of DRK where there was a voting system in place to decide the MN payments are not the ideal concept for this implementation and another idea can be used altogether.
I think it should be based on the majority of the hashrate. If the majority of the hashrate agrees on masternode payments then others should be forced to accept it even if they don't agree with it and do not create forks. The only way to cheat would be 51% attack but with 51% you can do much worse things anyway.Since some DRK features are implemented, and some could be improved upon, the original concept for the Darkcoin masternodes (RC2/RC3 releases) involved a protocol-level enforcement of the masternode payments. The problem with these releases was that there was some kind of bug that triggered sporadic network forking by misbehaving nodes or mining clients. The consensus wasn't working as it should.
In a sense, Darkcoin tried to use a dual consensus for every block: One for the transactions / mining, and one for the masternode payout. This didn't work as planned (there were sporadic forks of the network) and DarkSend development was lagging - so a workaround system was created instead that was "safer" and relieved some of the price speculation (it was the period of the great pump - and all eyes were on DRK news and how something would succeed or fail).
In that payment system (an evolution of which, is the current system of MN payments) the pools decided whether to pay or not in a semi-voluntary scheme. If a pool wanted to cheat payment, they could. The strategy was to shame the pools that "cheated" and it worked to compliance levels of 80-90%. The added threat of "enforcement" where Evan would "flip the switch" to fork off the non-compliant pools was also added as an extra measure. However, in my view, this is not the ideal solution to the problem. Rather, it should be done like it initially was conceived so that misbehaving clients are simply forked by themselves out of the network. No centralization / enforcement switch, no need for asking pools to play nice etc etc.
Perhaps the dev wants to give it a look* and see if he can come up with a system that works and which is free of forking bugs. It could also be implemented by DRK if successful, and it would also give added credibility to SPR itself for improving something in a significant way. The good thing with SPR is that, unlike DRK which is more mature, it can risk multiple hard forks to try things out.
* Perhaps the RC2/RC3 bugged solutions of DRK where there was a voting system in place to decide the MN payments are not the ideal concept for this implementation and another idea can be used altogether.
I'm against introducing any centralization to SpreadCoin. "Hey, this is a decentralized currency but I have a magic switch with which I can turn on and off some major feature". This can be employed to avoid possible issues when introducing new features but not as a long term solution for any problem.
December 17, 2014, 05:35:38 PM
Response from Bittrex:
Wow, I got the exact same response. It's funny that we contacted them at the same time.Quote
We gauge demand based off of tweets, hash power, length of bitcointalk thread, volume on other exchanges, etc. Follow us on twitter @bittrexexchange and tweet about how much you like this coin and Bittrex. We respond to creative and insightful posts to help market your favorite coins and Bittrex. I'd also consider coming to our irc channel #bittrex on irc.freenode.net and do some guerrilla marketing. The traders there can help you gain exposure for your coin.
Better off trying to get on Poloniex, BTER and/or Cryptsy.
polo
they had a pretty big stake on xmr doing well, and must be feeling it atm.
December 17, 2014, 05:14:41 PM
Is there any Spreadcoin Wallet that works on a gnu/linux terminal ?
Thanks!
Thanks!
You can grab the source (link in OP) and build the daemon same as any other bitcoin-derived coin:
cd src/
make -f makefile.unix
...wait a few mins...
./spreadcoind or ./spreadcoind help if you're unfamiliar with the standard commands
Dependency info etc. in /doc/build-unix.md
I thought my screen needed cleaning when I saw your sig
How many of these bad boys can I mine in 24hrs with an AMD R9 290?
Cheers.
December 17, 2014, 04:22:55 PM
And it's roughly 1 SPR per day. It has little sense with pools or without them. SPR blocks are generated pretty fast, every minute. So somebody with 1/1000 of net hashrate still can get the block about every 2/3 of the day. And even with 1/10000 it's every 7 days. When (if) price will go up, mining will be even harder, sure. But I like the idea that only dedicated miners will mine SPR, without switching on it for quick profit.
Idea of 'poolless' mining is good for coin security, even if it is not easy for miners. And honestly, I think sooner or later there will be workaround, there are some ideas ITT how to do it. But Mr. Spread is a good programmer and very good person. I think SPR will have a bright future.
Idea of 'poolless' mining is good for coin security, even if it is not easy for miners. And honestly, I think sooner or later there will be workaround, there are some ideas ITT how to do it. But Mr. Spread is a good programmer and very good person. I think SPR will have a bright future.
If there's ever a workaround that doesn't get instantly fixed, SPR will tank in value as it becomes just another short lived short term BTC/fiat hose for the ADD instadumpers, ie. 99.99% of all miners.
CheersYou strong hand bastards!!! Have some compassion and sell sell sell!
December 17, 2014, 03:48:06 PM
Response from Bittrex:
Wow, I got the exact same response. It's funny that we contacted them at the same time.Quote
We gauge demand based off of tweets, hash power, length of bitcointalk thread, volume on other exchanges, etc. Follow us on twitter @bittrexexchange and tweet about how much you like this coin and Bittrex. We respond to creative and insightful posts to help market your favorite coins and Bittrex. I'd also consider coming to our irc channel #bittrex on irc.freenode.net and do some guerrilla marketing. The traders there can help you gain exposure for your coin.
Better off trying to get on Poloniex, BTER and/or Cryptsy.
Jump to: