Example from one computer: Date Came after
H:M:S Average
25.10.14 20:29 00:01:05 01:21:06
25.10.14 20:28 02:03:20
25.10.14 18:25 04:59:56
25.10.14 13:25 05:22:20
25.10.14 08:02 03:13:25
25.10.14 04:49 02:14:38
25.10.14 02:34 02:32:46
25.10.14 00:02 00:24:30
24.10.14 23:37 00:09:06
24.10.14 23:28 02:22:36
24.10.14 21:05 02:45:36
24.10.14 18:20 01:32:15
24.10.14 16:47 00:12:00
24.10.14 16:35 00:20:15
24.10.14 16:15 00:45:52
24.10.14 15:29 00:02:08
24.10.14 15:27 01:12:25
24.10.14 14:15 00:50:36
24.10.14 13:24 01:30:20
24.10.14 11:54 00:15:18
24.10.14 11:39 01:00:08
24.10.14 10:38 00:25:49
24.10.14 10:13 02:24:00
24.10.14 07:49 00:35:15
24.10.14 07:13 01:03:44
24.10.14 06:10 00:48:43
24.10.14 05:21 00:39:04
24.10.14 04:42 00:50:01
24.10.14 03:52 00:09:02
24.10.14 03:43 03:17:25
24.10.14 00:25 01:13:40
23.10.14 23:12 02:13:00
23.10.14 20:59 00:11:15
23.10.14 20:47 00:40:56
23.10.14 20:07 00:12:24
23.10.14 19:54 02:07:25
23.10.14 17:47 00:31:48
23.10.14 17:15 00:19:35
23.10.14 16:55 02:40:04
23.10.14 14:15 04:50:55
23.10.14 09:24 00:30:38
23.10.14 08:54 00:34:33
23.10.14 08:19 01:10:27
23.10.14 07:09 00:18:47
23.10.14 06:50 00:09:28
23.10.14 06:40 00:21:58
Lets compare this with the truly random generation with the same average: 00:00:31
00:03:20
06:01:36
02:48:13
01:08:15
02:16:51
00:20:10
03:35:25
03:55:20
00:22:39
01:14:28
00:38:53
00:44:54
00:27:17
02:12:01
01:32:20
00:03:51
00:23:49
01:08:53
02:03:19
02:06:30
02:02:30
01:18:38
00:54:36
00:11:19
00:19:13
01:12:48
01:12:34
00:08:37
03:28:55
As you see, in the truly random case there are also long periods without blocks, so I think it's ok. You can generate random periods by yourself here. |
|
|
|
if there is say four-five hours gap, then next blocks should came faster, to make an average result equal to the computed average.
How often you will find blocks in the future doesn't depend on how often you found them in the past. This misbelief is called gambler's fallacy. Nothing for six hours on more computers at once, is not normal IMHO, especially if I have experienced this strange behaviour more times, and everytime on majority of my computers. (I run from three to five wallets.) This is strange but not something improbable, probability is usually counter-intuitive. You find blocks and that means that miner works correctly, it would be very strange for it to work incorrectly for some periods of time but correctly for the others. You can search in the debug.log for the following messages "SpreadCoinMiner : generated block is stale" and "SpreadCoinMiner : ProcessBlock, block not accepted" (without quotes). Every such message will mean that mined block was not accepted. While the first one can happen the second one would indicate a bug. (debug.log is located in C:\Users\<username>\AppData\Roaming\SpreadCoin\ on Windows 7 and ~/.spreadcoin/ on Linux) |
|
|
|
64x windows version doesn't work for me, it stops running everytime
Does it show any error? It stops when you launch it or when you try to mine? |
|
|
|
What happened to the whitepaper? It's 404 now.
Fixed |
|
|
|
Didn't know that we are on the voting list on C-CEX, added it to OP and voted. There is also voting on bter: https://bter.com/votingWe already have 7 votes there |
|
|
|
New version 0.9.14.3:Windows wallet (32-bit)Windows wallet (64-bit)Linux wallet (32-bit)Linux wallet (64-bit)Mac OS X walletMining speed is a bit higher for 64-bit build + small UI improvements. Also you can mine on a specific address (this is useful if, say, you are mining on a dozen of computers). To do so: 1. Use existing or better generate a new address. 2. Open debug console, enter: dumpprivkey SYourSpreadCoinAddress 3. You will get your private key. Then open spreadcoin.conf or create it if it doesn't exist (D:\Users\<username>\AppData\Roaming\SpreadCoin\spreadcoin.conf on Windows) and add the following line: miningprivkey=YourPrivateKey 4. Restart your wallet if it was running. In Mining tab you will now see notification that all mined coins will go to this address. I haven't yet mine a single block with this version but mining on testnet worked fine so it should be just a bad luck and my low hashrate.
|
|
|
|
Like this? I'll send commit
For me this looks a bit strange, what do others think, should we add logo to overview page? Incrementing nonce is easier (faster) than changing k.
Err, what? If you increment nonce (and I mean above the mask) you need a new k anyway. There is no need to change k, built-in miner doesn't change it. You forgot about SHA-2 hashing of the whole block. It will be slower and not just "slightly". By the same reason CPU mining is slower.
Not sure I follow what you mean here. The SHA is not iterated, so it is again just more cycles not more memory scheduling. The factor of performance advantage is dominated by memory bandwidth, so the relative gain should be largely unaffected. In other words, both the cpu and the gpu need to spend approximately the same extra effort there, so it shouldn't have much impact on the overall performance ratio. You said "it will always be slightly slower than just x11 because of the added signature step". This is what I was answering, if you talk about absolute hashrate than SpreadX11 will not be as fast as X11 because of added SHA-2 hashing, if you talk about gpu/cpu ratio than it may be comparable to X11. Some of your writings seem very strange: then produce the encrypted signature bits as output. The pool would give the output mapping from pairs of encrypted bit values to bit states so the worker could know the output without needing to decrypt it. Getting unencrypted value from an encypted one is exacty what decrypting is. You couldn't descrypt value without a need to decrypt it. I for sure I will read carefully all your arguments and look into how it could affect SpreadCoin. The worst thing is probably that in several years we can get some pool with very high overhead compared to solo mining. |
|
|
|
I want create events here in Brazil to speak about SPREADCOIN .
We need more marketing and we have a newspapper here to write about Spreadcoin.
We need more events/marketing and giveaway.
All this have a low cost.
Wow, you have newspapers writing about cryptos? When I think about cryptocurrency promotion I usually think about online activity. Yes, I will do a giveaway after releasing new version. I imported optimizations from elmad's cpuminer 1.3, it slightly improves hashrate for cpus with AES-NI. Also there are some minor improvements like displaying hashrates in units like kH/s and MH/s instead of just H/s. I will make builds when I will come back from work. |
|
|
|
I only mentioned FHE to cement the notion with "overkill" on the math, it certainly wouldn't be the best approach at an SFE delegation solution.
By some very rough number I estimate that state of the art in "general" SFE would probably put the cpu performance on the order of tens of milliseconds per signature, at best. (I haven't actually built a circuit for it, so I could be way off, this is just based on a guestimate of gate/layer counts based on my experience with similar circuit topology on contemporary processors.) Considering you get 64 rounds per signature I think 1kh/s is not so lofty of an initial goal.
My main concern is that this low performance is assumed with generalized approaches, but there might be (probably is, from my understanding) a special case transform of the puzzle into a secured "delegated work" puzzle which would be reasonably efficient to evaluate, at least within the same order as signing directly. In other words, an "application specific SFE" scheme might vastly outperform our notions of resource requirements from generalized approaches.
SFE refers to some network protocol where there are several parties each of which has some private information and they want to compute public function based on this information without revealing this information to each other. Is this what do you mean by SFE? In our case only pool has private information - private key (and random k) which it doesn't want to share, in this case SFE is trivial - pool should compute signature on its own and share it which is not suitable for our case. In FHE you have encrypted inputs and encrypted outputs, but to proceed further with the mining miner must decrypt the output which probably implies that he can also decrypt the input which defeats the whole purpose. Do you have some more specific description of a your scheme? Address is always recoverable from the signature. This fact is also used to make SpreadCoin transactions smaller. This simply isn't true in general, but might be true in the particular implementation. I'm not sure yet, but a simple brute force address generation should find one quickly and easily, or something like crypto-mini-sat should find one slowly and with some work. I'll let you know of an example that doesn't extract if I do find the time to find one, and also by which route I found it.  Ok, you can try but you won't find it. Avoiding GPUs/ASICs is not a goal because it is probably not possible. I don't see how can you get any gains by ignoring nonce, this will only make mining slower because by iterating on r values you will have more work to do. You can use the same method that you describe but with nonce iteration; it can save you memory bandwidth but it won't be as fast as X11 because there is simply more work to do.
I didn't make clear that the optimization to iterate k instead of nonce applies to any processing element, it eliminates the repetition of nonce increment and initial hash. Basically, this coin is somewhat unique in that it might as well not even have a nonce field in the block header at all, since the signature field can serve the same purpose. (Since you are looking for any place to reduce block history size, you may actually even want to make this change?) I haven't tried any mining of the coin, but I might mine just to try comparing performance of this change. Incrementing nonce is easier (faster) than changing k. Although changing k instead of nonce eliminates the need to recompute hash used for signature so it may or may not be faster. My point was basically that, because of this optimization, the thing that might initially make this algorithm appear to be particularly "gpu hard" is a bit misleading, and the algorithm is not really any more "gpu hard" than x11 itself. Yes, it will always be slightly slower than "just" x11 on any processing element, because of the added signature step, but it is only some added cycles and not more memory hardness. The performance *advantage* from parallelism of gpu or fpga should be roughly the same as that of x11 itself. You forgot about SHA-2 hashing of the whole block. It will be slower and not just "slightly". By the same reason CPU mining is slower. And I never said that this algorithm is GPU hard. |
|
|
|
Most importantly, what prevents a pool from using indistinguishability obfuscation of garbled circuits or Gentry style FHE to deliver (each block) a circuit to a worker that allows the worker to sign valid work, but nothing else? This would add quite a bit of overhead to the signing step for the worker (hitting 1kh/s might even be optimistic, heh) but pooling can still occur and that overhead will only come down in time.
(This is generally an open question going back to at least 2011. My understanding is it is commonly held that avoiding pooling in general is just mathematically impossible, and specifically because of secure function evaluation.) I doubt that you will hit even 1kh/s with homomorphic encryption. Overhead will definitely be lowered in the future by further researches but it is very unlikely that it will ever be possible to perform encrypted computations with the same speed as unencrypted ones without significant overhead. Creating pool with very large overhead may be possible even now. Similarly, it seems like a *blinded* multisig escrow (as discussed at https://bitcointalk.org/index.php?topic=440572.0 and elsewhere) could be employed for a decentralized pool, assuming a specific participant is trusted with redistribution of funds. (However I may have missed a check that would preclude this. It does seem like it would be possible to avoid, and even not all that difficult, unlike the SFE problem.) This scheme is used to hide both data being signed and resulting signature from the signer. How do you want to apply it here? You can try to hide data being signed from the miner but then miner will need to send each generated blind signature to the server for unblinding. If you are ready to do this than you can do it without any blind signatures, this will move considerable amount of work to the pool and will require very high network bandwidth for the pool. Of lesser concern, I haven't seen any check during address generation or signing that the address is actually able to be extracted from signatures. Not all addresses will be. It isn't immediately clear to me what happens in this case. I suspect it just means stales that die somewhere under processblock and never get broadcast. (?)
Address is always recoverable from the signature. This fact is also used to make SpreadCoin transactions smaller. Finally, it seems like the goal of avoiding immense gpu/fpga/asic gains over CPU is somewhat precluded by the scheme itself. By ignoring nonce (other than perhaps the 64-way parallelism you can get "for free" from the masking) and instead iterating on r point values (parallel deterministic selection of k) you can maintain an efficient single-point "wave-front" (and as such a minimum of memory bandwidth utilization) against only one block instance in memory by having each hasher just fill in its distinct signature of the same nonce. By churning just signature+hash instead of nonce&hash+signature+hash you would eliminate the secondary bottleneck for parallelism, and get performance much more comparable to "just" x11 hashing. Avoiding GPUs/ASICs is not a goal because it is probably not possible. I don't see how can you get any gains by ignoring nonce, this will only make mining slower because by iterating on r values you will have more work to do. You can use the same method that you describe but with nonce iteration; it can save you memory bandwidth but it won't be as fast as X11 because there is simply more work to do. |
|
|
|
Right now I'm working on further optimizing CPU mining. GPU miner is inevitable and we want CPU mining to be more competitive to it when it will appear and if this miner will be private we want network to have higher hashrate compared to any GPUs which will use it. If all goes well I will release optimized version today. After that I will hold a giveaway (or several giveaways in different places) to spread SpreadCoin. Mr. Spread, if there are some interesting and still unimplemented concepts in bitcoin that you still want to implement?
Yes, I already wrote about it: I have several great ideas about possible features (never implemented before in other altcoins) in addition to poolless mining but they all require thorough design and thought so they will take considerable amount of time.
You, of course, want to know what are these ideas but I cannot disclose them; other developer (or even a team) can steal my ideas and implement in other coins. What I can say now is that I will not introduce any new controversial changes (e.g. pool absence is both good and bad as you said). All further changes will be strictly positive and will not be disruptive (i.e. changing mining algorithm is probably not an option). Anyway, any new features can only be introduced in a more remote future, currently we need to focus on promotion and exchanges. |
|
|
|
What do you mean by bigger version, what resolution? Qt wallet has 256x256 logo. Where should it display big logo?
I don't see any logo in the windows wallet in any version.  It doesn't matter, really, but anyway. That's what i had in mind.  You said it like it is something usual but I never saw logo in this place in other coins. Mr. Spread, can you add the option to show network and local hashrate in kh/s or mh/s? It will make client a bit more userfriendly.
Will do |
|
|
|
We are also on AllCrypt: https://www.allcrypt.com/market?id=1195Is there any ideas?
But we need bigger version of current logo for QT wallet (maybe Mr. Spread has it but he forgot/don't care to add it to the wallet). What do you mean by bigger version, what resolution? Qt wallet has 256x256 logo. Where should it display big logo? |
|
|
|
I optimized mining and used optimizations from darkcoin cpuminer. Improvements are not dramatic but hashrate is noticeable faster. This is for 64-bit only. It uses extended instruction sets, I tested in on my CPU but I cannot guarantee that it will work for you, please test (except for the mining these builds are exactly the same as current version). Windows wallet (64-bit)Linux wallet (64-bit)If you want to build from source then checkout the 'cpuminer1.2' branch. I plan to further optimize mining. Anyone had any issues with this version? If not I will make this optimized version as the default for download. And I just found a bug in displaying average time between mined blocks, it thinks that hour has 24 minutes  . I will fix and update builds soon. EDIT: builds updated: Windows wallet (32-bit)Windows wallet (64-bit)Linux wallet (32-bit)Linux wallet (64-bit)Mac OS X wallet |
|
|
|
Dev,when can we use GPU miner? Currently there are no plans to develop GPU miner. Wondering what speed gains would an external miner provide...
Miner cannot be faster just because it is external. Anything that can be done with an external miner can be done with internal one. |
|
|
|
Some vps Howto? I want mine it on my debian vps
Are there CPU Miner or i have to use solomining
You will need to use solo-mining with spreadcoin daemon. To get your mined coins you will need then either download wallet.dat or send coins to your wallet using command-line. Currently there is no way to mine running network node on one computer and miner on the other. Here are instructions how to run solo-miner in case you don't know. Set user and password in ~/.spreadcoin/spreadcoin.conf rpcuser=user
rpcpassword=pass Launch spreadcoind daemon. Then you can start mining using the following command: spreadcoind -rpcuser=user -rpcpassword=pass setgenerate true and stop using: spreadcoind -rpcuser=user -rpcpassword=pass setgenerate false If your wallet is password protected you will need to unlock it using walletpassphrase command. |
|
|
|
roadmap if any?
I also want to know that Ultimate goal is world domination Our current task is to add SpreadCoin to exchanges. Also, I plan to hold a giveaway (is there anyone who wants to join me to donate some coins?). As for development I will further optimize CPU mining. I have several great ideas about possible features (never implemented before in other altcoins) in addition to poolless mining but they all require thorough design and thought so they will take considerable amount of time. |
|
|
|
You may want to contact allcrypt.com. They pretty friendly for new coins.
Yes, I will do it. But keep in mind that exchanges want pressure from community to add coins so I encourage everyone to contact exchanges on which you want to trade SpreadCoin. You can do it in Twitter and on relevant IRC channels. Bittrex: irc.freenode.net channel: #bittrex ( web version) https://twitter.com/BittrexExchangeCryptsy: irc.freenode.net channel: #Cryptsy ( web version) https://twitter.com/cryptsyAFAIK, the only voting list that we are on is AskCoin and we already have mane votes there but we need more. |
|
|
|
|
Show Posts
