Hey guys, would it be possible to create a pool like this;
Each miner mines to a separate address. The pool (and the miner obviously) knows the private key.
The pool has insurance of lets say, 15 spr in a separate address for each miner. The insurance needs to be paid by the miner before he starts mining.
The miner submits shares and once he finds a block he publishes it to the network.
If the miner steals coins from his address then he gets banned from the pool and the pools uses his insurance to pay the other miners.
Could this work? Or is it not possible because it isn't how mining works for spreadcoin?
The problem here is that if you will find a block and will not try to steal its reward pool can still claim that you are trying to steal it and use both your funds and block reward. For external observer it is not possible to distinguish between situations when you are trying to steal money and when pool operators are just lying about this. Even if pool is operated by some legally registered entity with non anonymous owners they can steal your money and you wouldn't be able to prove anything. If you cannot find blocks consistently but are still mining that means that even one block's reward worth something for you. |
|
|
|
In particular, I want to improve syncing time, right now it is too slow.
Is that because of having smaller transactions so the cpu is used more? No, transaction verification speed is the same, maybe even faster than in Bitcoin. It is because of slower PoW algorithm. Right now it is checked several times for each received block, this should be fixed. Once we will have more transactions PoW checking time will become less important than transaction verification time. |
|
|
|
May I also propose a few more suggestions, beyond the fixing / upgrading of the masternode payments system?
Of course, very interesting suggestions. 1) Block time of 1 minute could create bloat in the long run and might need upward adjustment. It is also worth looking into a mini-blockchain integration. If InstantX is also copied from Darkcoin in the future (something that only coins with masternodes can emulate - and spreadcoin will be in that position), block time can be safely revised upwards. Don't forget that this is solo only coin. Block time should be low to allow people with less hashrate to mine. 7) CPU mining is ideal in the way it is conducted through the menu, but the mining speed should be faster / more optimized for certain architectures and instruction sets. This needs some work.
It would be ideal if GPU mining can also be integrated or "associated" from the mining menu... ie spreadcoin-qt calling the gpu miner program with the right parameters (that the newbie user doesn't know how to setup). I spent some time optimizing integrated CPU miner before GPU miners appeared but it probably requires more work though. Note that this hashrate should be lower than in X11 by design because mining algorithm itself is slower. 10) Quantum-resistance: The ECDSA of Bitcoin / Bitcoin clones is not quantum-computing resistant. This means that once a public key is known, a private key is weaker against a QC attack.
I believe there can be two solutions for this issue: Changing the algorithms to QC-resistant and thus creating the first QC-resistant altcoin (there is the possibility that they might introduce bloat). Alternatively a work-around QC-resistance can be created through a checkbox. When ticked, all addresses with even one spend transaction will have their funds moved, automatically, to new addresses with zero spends. This will prevent the pub key from being publicly known (and thus being reversed), if and when a QC attack occurs / if and when a QC is developed and deployed. Futureproofing in this way could create a new way of crypto-diversification asset to counter a QC-attack risk (that will leave vulnerable the other coins).
I was investigating quantum-resistance some time ago. It appears that all quantum resistant digital signature algorithms have insane key and signature sizes which makes them completely impractical to store in blockchain. Your proposed future-proofing won't work, to spend any of your "secured" coins you would still need to reveal your public key. |
|
|
|
|
I have submitted another potential issue to DarkCoin dev, its significance is hard to estimate but I guess it already affected many people in a minor way, they just haven't noticed it.
I now have feeling that I'm working more on DarkCoin instead of SpreadCoin, I need to fix that. While integrating DarkCoin features is a longer term project, in a shorter term I want to make some improvements to the SpreadCoin wallet. In particular, I want to improve syncing time, right now it is too slow.
|
|
|
|
It looks similar but more complicated because of the requirement of backward compatibility with existing Bitcoin miners. |
|
|
|
Interesting concept -- I've browsed through most of the thread but haven't seen a clear answer on a key point:
How specifically are mining pools avoided with this coin?
There is a whitepaper in OP. I think I should change OP to make it more clear why there are no pools, you are not the first one who asks. 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.
I personally like the current name. |
|
|
|
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. 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. |
|
|
|
Response from Bittrex: 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. |
|
|
|
Is there any Spreadcoin Wallet that works on a gnu/linux terminal ? 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 use builds from OP: Linux wallet (32-bit)Linux wallet (64-bit)But it is generally better to build by yourself. How does one compile for Windows? Didn't find a .sln file for Visual Studio... I'm using gitian to do all release builds. Compiling bitcoin and its forks on Windows is not an easy task. Compiling with VS you would probably only be able to build spreadcoind but not spreadcoin-qt. SpreadCoin-Qt should be build with Qt instead of VS but Qt's *.pro file contains some scripts which are supposed to be executed on unix. Some related info for DarkCoin: https://darkcointalk.org/threads/compiling-the-source-in-visual-studio.2171/http://wiki.darkcoin.qa/display/DRK/Creating+a+Visual+Studio+Solution+for+Darkcoin (seems that images are broken on that page and it is only for leveldb) |
|
|
|
Is there any Spreadcoin Wallet that works on a gnu/linux terminal ? 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 use builds from OP: Linux wallet (32-bit)Linux wallet (64-bit)But it is generally better to build by yourself. |
|
|
|
Hi! How can i see, that i have found a block? And am i hashing right now?  Yes, you are mining. You will see new coins in your wallet if you will mine a block, they will appear as "mined". |
|
|
|
The current plan is to integrate DarkCoin features, there is no definite timeline, reviewing DarkCoin source code will definitely take some time. I have sent DarkCoin devs info about another potential bug. It may not be a bug though, if some checks in source code are only for historical reasons and will not fail for newer blocks.
Price for launching a masternode isn't set yet.
EDIT: according to Duffield it is not a bug but he still patched it for consistency.
Are you the only Dev working on this project? Mostly. There are contributions from Palmdetroit and gjhiggins. girino helped with the AMD GPU miner. |
|
|
|
|
I wouldn't call C-CEX a scam, they are not stealing coins. Although this 0.5 BTC fee for solving problems is bad, it should be free or at least much cheaper.
|
|
|
|
|
The current plan is to integrate DarkCoin features, there is no definite timeline, reviewing DarkCoin source code will definitely take some time. I have sent DarkCoin devs info about another potential bug. It may not be a bug though, if some checks in source code are only for historical reasons and will not fail for newer blocks.
Price for launching a masternode isn't set yet.
EDIT: according to Duffield it is not a bug but he still patched it for consistency.
|
|
|
|
Also, any idea what caused the huge hash rate jump last night? Can't all be CPU miners... Maybe it is a idiosyncrasy of the Spreadcoin QT but the network hashrate was only reported as 3Mhps last night and its over 2Ghps today. Have I misunderstood something or have you attracted hundreds of new miners overnight?
It was around 1 Gh/s. Did you really saw 3 Mh/s? Maybe it was old hashrate shown during sync? |
|
|
|
Page 66! A milestone.
While hashrate is now 2.6 GH/s:  |
|
|
|
Is there a white paper on how pools are prevented? Did you just remove the RPC commands for it? We may be interested in adding a Spread market on Excoin after learning more and reviewing the sourcecode.
Yes, there a whitepaper, it is here: http://spreadcoin.net/files/SpreadCoin-WhitePaper.pdf |
|
|
|
Anyone knows why average spacing between DarkCoin blocks is approximately 157 seconds instead of 150 seconds? I remember that when creating SpreadCoin several months ago I noted that there is a small bug in DarkCoin difficulty retarget which causes block generation to be a bit slower than it should be. But it seems that I lost this knowledge. When I'm now looking at difficulty retarget it looks correct to me, although a bit obfuscated.
This has been known for some time and isn't worth fixing. I'll explain why: https://github.com/darkcoin/darkcoin/blob/master/src/main.cpp#L1607https://github.com/darkcoin/darkcoin/blob/master/src/main.cpp#L1453One of them is computing 24 blocks and one is computing 23. So: 1/24.0 == 0.0416 2.5*1.0416 == 2.604 (minutes) Statistically it's doing exactly what it should! Here is the DarkCoin retarget formula freed from any obfuscation and without clamping:  where T i is the target of i-th block and t i is the timestamp of i-th block. Initially I thought that this is because previous block is counted twice but it is divided by 25, not 24, so it's ok. But look at actual timespan computation: t i-1 - t i-24 but 24 - 1 = 23, so it is actually timespan of 23 blocks. 23 blocks per hour instead of 24. This is 156.522 seconds or 2.6087 minutes of spacing between blocks. By the way, I don't see here any "multiple exponential moving averages" as white paper states, where are they? |
|
|
|
|
Show Posts
