Daniel thanks we could get into that then if I am free to work.

I like GUI programming so that is no problem for me assuming the incentives are well aligned.

Can we have infos about Stealth vs RingCT vs ZKT ?

Differences, cons & pros.

Assuming you mean by Stealth what I think you mean Stealth Addresses, which is ECDH exchange so that the payee's address is different on each transaction (but I thought Daniel already implemented that in BTS2.0?), then I explain what the others add to that. Stealth Addresses provides unlinkability but not untraceability. Those two terms are defined in the Cryptonote (CN) white paper.

CN (one-time rings) mixes payer's identities which adds the untraceability.

CT (Blockstream's Confidential Txns) hides the values of the transactions in homeomorphic proof-of-sums and proof-of-positive small values.

CCT is another way of doing CT that appears to be about 10X smaller use of space. Note I have claimed to have eliminated the proof-of-square thus making it even more efficient but my paper is unpublished and thus not vetted yet.

RingCT combines CN and CT.

ZKT is my unpublished paper that combines CN with CCT which I claim was completed before July 15 much earlier than RingCT was invented. So I claimed to be first, but again I chose not to publish because at the time I thought I was reserving it as feature for my coin that I was working on (but since changed my mind on priorities).

I would also suggest considering offering a mixer based on Zerocash because I think that is the holygrail, because it doesn't matter if your IP address is not obfuscated because ZC (not Zerocoin) hides everything. Theoretically all the other anonymity paradigms can be unmasked by correlating IP addresses. That doesn't mean the others are useless, just not as 100% certain as Zerocash. Zerocash has some issues and I made some suggestions on how to overcome them:

https://bitcointalk.org/index.php?topic=1290263.msg13269624#msg13269624

Hope that helps you all in your decision process.

Everyone wants a free lunch, but nobody wants to pay for it.  Why shouldn't he get lifetime royalties?  Its a privatized feature and they put in the money to get it running.

I would agree with your statement if the investor is not receiving a guaranteed monopoly on the feature. Given the threat of competition, the investor would need to adjust the fees accordingly.

But will the investor allow the feature to be open sourced if the investor isn't granted a monopoly?

Quote from: AnonyMint on November 19, 2013, 12:26:17 am

Hahaha. You will soon see how incorrect that selfish appraisal is. As well, you reneged on what you already said you would do, which was send a tip. And I told you, I didn't care the amount, only the gesture.

But this is fine, because it is excellent motivation for what you will soon see.

Tip paid.

Confirmed. Thank you. Favor returned here:

https://bitcointalk.org/index.php?topic=339902.msg3646754#msg3646754

Gpu miner still matters because perhaps if he thought deeply about the information I gave him, he could eliminate gpus, if that is desirable. Yet all my work on  a CPU-only miner, I can't get the hash to be fast enough for what I think bytemaster needs in his design.

What is the slowest hash your design can tolerate?

Where you able to defeat gpus with Gigawatt's help?

Not having a gpu miner doesn't mean someone won't have one and thus this is very risky unless you've proven it can't run faster on a gpu. So the way I presented thinking about it, is very important I think. But I don't know what Gigawatt has come up with.

To recap, either you provide a gpu miner to all, or you prove beyond any reasonable doubt that no one can make one. That is very important I think. But you may have other priorities?

Quote from: Proto on November 11, 2013, 01:16:08 pm

I can play with a 16 core (32 threads w hyperthreading) machine and 64 gig memory. Let me know if you want me to test something new.

Would it be possible to set it for so little memory that everything takes place on L2 cache? That memory should be a lot faster than main RAM - so might see some dramatic improvements at that level - don't know if they could be reproduced on GPU though.

That won't beat the GPU, because then you use much less memory so the GPU can run so many more threads and more assuredly hit its 10x faster main memory bandwidth. At best if you increase throughput compared to main memory and if the GPU was already at full memory bandwidth (had hid all the latency) on the existing algorithm, you might cut the advantage of the GPU down by a multiple, which is what Litecoin obtained. However, the GPU will then also be running more copies of the hash in that case too (more threads and memory available), so I doubt this would be an improvement at all.

I am looking for algorithmic weaknesses in the Momentum Proof of Work: http://bitsharestalk.org/index.php?topic=21.msg24#msg24 

If you can identify an alternative algorithm for solving the proof of work that does not require the target RAM and yet is able to find hashes at a rate greater than  MomentumAlgoHashRate / (TARGET_RAM_USE/ALT_RAM_USE)  then you could win this bounty.

For example:  Suppose momentum as specked requires about 1 GB of RAM for maximum performance and produces hashes at 1hz.   If you design an algorithm that only requires 1 MB of RAM and can find hashes at .001 hz then you win because you will have proven that computational complexity is linear with RAM use rather than non-linear like I believe the problem calls for.          I paid out a tip for showing this property doesn't quite hold as I thought, but this was more a weakness in my devising an effective / objective measure for determining whether or not momentum is "broken' or 'hacked'.

For the record, I did not receive any tip.

Quote from: bytemaster on November 08, 2013, 09:10:12 pm

1) What is the performance of SCRYPT on CPU vs GPU? 

From the Litecoin Wiki, I seem to remember roughly 5 - 10 times faster for high-end GPU compared i7. Compared to roughly 100x faster for Bitcoin. You can double-check.

https://litecoin.info/Comparison_between_Litecoin_and_Bitcoin
https://litecoin.info/Mining_hardware_comparison
https://en.bitcoin.it/wiki/Mining_hardware_comparison

If we compare the i7 2600 both on pooler's cpuminer, then ratio to the HD7970 is roughly 30 for Bitcoin and 15 for Litecoin. So Litecoin is only a 2x improvement over Bitcoin, not the order-of-magnitude I had indicated.

Some high-end CPUs don't have AGPUs. Look at the Bitcointalk thread for your protoshares launch, you see many Xeons and high-end i7. The server chips don't have AGPUs.

Integrated Graphics can saturate its memory bus (60 GB/Sec on latest hardware)

Is that limited amount of sideport memory or the full main DRAM?

The fastest I'd seen was the 40 GB/sec for Ivy-E and those don't have AGPUs.

On Haswell, Ivy, Sandy with AGPU I saw roughly 20 GB/sec, but I wasn't clear if the AGPU can attain that since it has worse latency to main memory than the CPU.

though I think in this particular use case moving more than 64 bytes (cache line size) per cycle doesn't help due to the random access nature.   In fact, it may hurt the GPU by being forced to consume its memory bandwidth in larger than necessary chunks when it is randomly accessed.

If you have enough parallel threads they will to some extent statistically clump in locality of memory. I haven't attempted to quantify that effect.

Hashtables would point to arrays of items in the bucket.

So there is a 26x difference between average CPU based systems and high end graphics cards.

Rough estimate agreed. On Haswell or latest, maybe half that.

Then higher if no AGPU integrated.

1) What is the performance of SCRYPT on CPU vs GPU? 

From the Litecoin Wiki, I seem to remember roughly 5 - 10 times faster for high-end GPU compared i7. Compared to roughly 100x faster for Bitcoin. You can double-check.

2) Does momentum have a lower performance ratio than SCRYPT?

Appears to be worse than Litecoin. But you gain fast verification, so for you that might be the correct tradeoff, especially if integrated graphics will be improving on CPUs (so you might reach parity with Litecoin or better in future) and the ASIC risk is not higher than Scrypt (or if you are not so worried about ASIC near-term).

3) When it comes to making an ASIC, which would be harder SCRYPT or Momentum?

I haven't analyzed this for Momentum. I have analyzed it for Scrypt. I can comment after others have summarized if I have something to add.

As far as how to divided the bounty among the various contributors I am thinking that AnonyMint and gigawatt have both provided some reasonable contributions.   I will wait to see gigawatt's proof-of-concept implementation to be sure there is a cycle and that the computational time is not larger than available parallelism before making the final decision about relative payout.   Gigawatts proof-of-concept shows more time and energy invested and is also more compelling than theoretical estimations of performance gains provided by AnonyMint.  Clearly writing code is of greater value than writing forum posts and also more definitive.

I have no problem with that. I am not expecting anything, but I think it does help you in the community to be fair and reward help. But I see we have a new comment claiming that Gigawatts vulnerability is not valid. I would go slowly and be sure first.

Good work everyone, it is a pleasure debating this with you all.  I hope you recognize that I am in this to find the best algorithm and NOT to defend my ego and put my head in the sand.   This bounty and ProtoShares has brought out great minds and we sharpen one another.

I appreciate your clarification. I know you were sick the prior day, because you mentioned it.

Wow great work guys!   I am taking some time to digest it all and really wish the bounty would have been taken more seriously prior to launch.

I didn't know about it. You could have PM'ed me.  I had told you in the past I was researching CPU-only.

Quote from: AnonyMint on November 08, 2013, 04:20:13 pm

Quote from: AnonyMint on November 07, 2013, 07:58:57 pm

Quote from: bytemaster on October 19, 2013, 06:42:06 pm

The point of Scrypt was to make parallel operation difficult and its primary weakness is that validation time suffers as you scale it.

If you don't require that the first match in the sequence of generated pseudo-random numbers, then my upthread described parallelism attack works to allow GPUs to blow away CPUs, assuming the pseudo-random sequence can be generated much faster than the random memory latency bound on the CPU so the GPU can try 100s of values from the same pseudo-random sequence in parallel to hide the memory latency.

If you do require it, then you lose the fast validation time.

Do you get it now or you going to continue to ignore me?

I expended the time to explain this in more detail:

https://bitcointalk.org/index.php?topic=325261.msg3520992#msg3520992

I think that is the last effort I will apply to this.

Even if you allow that a GPU is "leaps and bounds" faster than CPUs, you still run into major problems.

The time complexity of searching with a CPU using memory lookups is O(n), whereas brute-forcing combinations with a GPU is still O(n^2).
Regardless how much faster a GPU is, it's faster by a constant multiple, but the number of calculations is almost squared.

bytemaster wrote that upthread but I don't understand why you say so? He never answered.

The GPU is using the same amount of memory and the same number sequence. It is searching the same thing.

Why do you claim that the GPU has a squared time complexity? I see no basis whatsoever for that claim.

I have only described how to speed up the search of the same sequence and memory as the CPU is using, by employing more simultaneous lookups.

I must assume both of you are not reading carefully. I am not writing about replacing any memory storage with computation. I made that clear from my very first post. You are apparently not taking the time to understand what I wrote.