Topic: [ANN] SpreadCoin | True Decentralization (No Pools) | Testing New Masternodes - page 415. (Read 810079 times)

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 wallet

Mining 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:
3. You will get your private key. Then open spreadcoin.conf or create it if it doesn't exist (D:\Users\\AppData\Roaming\SpreadCoin\spreadcoin.conf on Windows) and add the following line:

Quote

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.

For me this looks a bit strange, what do others think, should we add logo to overview page?

There is no need to change k, built-in miner doesn't change it.

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:
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.

How can we add to Spreadcoin http://www.cryptocoinrank.com/# ? 

Contacted Gliss, done.

could anybody request http://coinmarketcap.com/ to add SPR?

Like this? I'll send commit

Yes, online and offline here.

Events and charity ideas.

No, that would be a general description of Secure Multiparty Computation (SMC) not Secure Function Evaluation (SFE) which is a specific, 2-party, subset case.  SFE simply refers to the ability to find enc(y)=F(x) given only some encrypted enc(x) of plaintext x and a correspondingly transformed F.  The evaluation of F certainly learns enc(y) and possibly learns y (depending upon the scheme employed) but does not learn anything about x.  As such, it can not learn anything about F except its logical topology.

Yao's Garbled Circuits are the canonical example of SFE, and do not necessarily require interaction protocols.

In the case of an iterative puzzle, SFE can be done offline by giving the evaluating party the ability to selectively choose some inputs like nonce, knowing their representation, "on behalf of" the issuer.  The solver can independently re-evaluate the circuit as many times as he'd like choosing new inputs.


Right, that would not be SFE.  The point is that the pool can construct a "program" that others can run that will sign headers without the servers further involvement, and without disclosing the private key, but will not sign non-header data.


The encryption of the input and output do not necessarily relate.  Some inputs could be encrypted with one key and some with another.  Outputs could be encrypted with not just these keys but possibly third and fourth and fifth keys, and so on.  Some might be encrypted with both, so both parties could learn some result. (This may put some constraints on the construction of F.) This principle is one way that SFE can be extended into more general SMC.


It would probably be best to have the pool generate a circuit per user, per block.  This circuit would take in just a nonce value as "worker determinable"  The circuit would compute the header hash and a deterministic k, and 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.  The output could then be inserted back into the block header for use in the 64 rounds of hashwholeblock hash by the miner.

Implementation would be straightforward on something like FairplayBI, if you don't mind Java.  (Personally, I'd go for something less straightforward and much more efficient, but most importantly not Java.)


I've probably missed something obvious and you're probably right.  We'll see.


Err, what?  If you increment nonce (and I mean above the mask) you need a new k anyway.


Right, that is precisely what I meant.  You don't ever strictly need more than one hash as input to signing.


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.


I never said that you did, but you do seem to have it as a goal to try to keep CPUs competitive, so I was just discussing some details toward such an end.

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.

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?

Ok, you can try but you won't find it.

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.

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.

Cool, I'm glad you at least see and agree with this.  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.

The real elephant in the room is that the outcome is basically inevitable assuming that the coin doesn't otherwise fail, so the premise of the coin ends up being self-defeating, particularly if we consider something like "garbled fpga" hardware.  (I highly suspect that this technology is just around the corner anyway.)  Assuming the coin doesn't otherwise fail then eventually either the coin gains enough traction that a pool becomes rational despite the short term losses, or else secure function evaluation technology becomes cheap enough that a pool becomes rational from minimized short term losses.  Regardless of which we reach first, on a long enough curve the centralization of your coin ultimately ends up no different from that of BTC with open participation pools dominating mining.  Rational investors should consider this eventuality *today* particularly considering that the time-frame of it is entirely open ended - it could happen in an hour, a year, or a decade with the likelihood just asymptotically increasing toward certainty along some unknowable curve.

Personally, I suspect that we are looking at a time-frame of less than a year to see a "useful" pool here, if the project is successful at all.  The pace of SFE technology has been startling.  The addition of applicable hardware cryptography primitives into most every recent COTS processor has helped significantly in advancing the art.  I suspect that the eventual introduction of specifically "SFE enabling" hardware will have an even more significant impact.  On the outside, I'd say within 5 years a reasonable pool will become "easy" to make.  I could be wrong.


It could hypothetically be done in a way that wouldn't require the "redeemer" to unblind every iteration, by using something like a commitment contract.  However, after another reading through CheckProofOfWork stuff I now see that the script is appropriately constrained in a way that prevents any of these sorts of "blind output relation puzzle" shenanigans, as they would all be predicated on nonstandard scripts in coin-base that would fail the size check and extraction, as implemented.  As such, that whole family of potential concerns is right out, and we can forget that I ever even brought it up. 


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. 


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.

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.

This is IMO overall a good project, even if the premise is known to be mathematically impossible and seemingly likely to be pragmatically difficult too.  It is obvious that you put a good deal of thought into your approach.  Even if someone launches a useful pool in a few months and the project itself falters, I think that you will be able to call your work a success for having created incentive toward advancements in SFE technology.    Further, I think that with some work specifically put toward hardening the process against SFE pools, you might at least have an opportunity to drag out a reasonably long "cat and mouse" game with the progress of the technology.  For example, you could pretty easily modify the signing process so that it *would* require full homomorphism over a *very* large circuit to delegate, likely buying yourself some years.  (I'd probably even have some interest in helping you with such an effort, if you decide it is worthwhile.)

I will be very interested to see the outcomes!

Last 24h mining only 13 Spreadcoin... few.

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.

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.

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.

Address is always recoverable from the signature. This fact is also used to make SpreadCoin transactions smaller.

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.