Abandon scrypt and use straight BLAKE512 or KECCAK512 -- pave the way to easy GPU implementation and then FPGA/ASIC mining for the quickest adoption.
Could you explain the logic for the 2nd step? Yeah. FPGAs won't be much faster than video cards, just more power efficient. ASICs require millions of dollars to invest, so will never be made for the coin until it's worth it to implement them. So, unless you want to write your own scrypt implementation with TMTO for a GPU using some non-SALSA20/SHA256 scrypt algorithm, you may as well just use BLAKE512 or KECCAK512 and quickly port it to a GPU. Actually, save yourself some space on the blockchain and just use KECCAK256. Switch all the hashes to KECCAK256 from SHA256 as well if you want to give your coin faster throughput in general for transactions. |
|
|
|
|
Abandon scrypt and use straight BLAKE512 or KECCAK512 -- pave the way to easy GPU implementation and then FPGA/ASIC mining for the quickest adoption.
|
|
|
|
edit:
There is another problem I think, which is recursive invalidation of the blockchain if you invalidate the previous block. It is what it sounds like; once you invalidate a block previous in a string of valid blocks, all the blocks before it become invalidated because that block confirms all of these blocks reverse sequentially. There needs to be a way to keep the PoS transactions free from the manipulative harm of the PoW chain in some way.
I need to think about this some more, can't think of an easy solution off the top of my head.
Stop relying on PoW for any part of network security. Eh. It's okay for security, but I really like it in there for 1) distribution of new coins and 2) keeping consistent network timing for blocks. |
|
|
|
Sorry, finally getting some time to spend sitting down and thinking about this for a couple hours. But the way to mitigate the attack is similar to what you described (I'm not sure why you described it as the square root of the difficulties?), but just assign a blockchain score of:
block=1{summation}block=n of (PoW Difficulty in Block 1 * (PoS Difficulty in Block 1)^-1) + ... + (PoW Difficulty in Block n * (PoS Difficulty in Block n)^-1)
 I don't get this. This is the weight for the total blockchain right? PoS difficulty is the price of a ticket in terms of % of total coins available. The price is adjusted to sell a constant # of tickets. If the PoS Difficulty is low (tickets are cheap), then only a small fraction of total coins are participating in the lottery. The chain should be penalized for this. Your formula rewards the attacker for lowering PoS Difficulty, making the problem worse not better. Again I suggest you use: block=1{summation}block=n of (PoW Difficulty in Block 1)^0.5 * (PoS Difficulty in Block 1)^0.5 + ... + (PoW Difficulty in Block n)^0.5 * (PoS Difficulty in Block n)^0.5 Yeah, now I get it. The only time you can get absolute certainty that a double spend can succeed is with 51% PoW and 51% PoS. But you suspect there is a flaw in this logic...
Nothing to lose sleep over. Even though your logic is flawed, it does not reflect a fundamental flaw in your design. One chain will always be either better, equal to, or worse than another chain. The algorithm evaluates proof chains to decide this. One group's chain controls a fraction x PoW and a fraction y PoS. The other group then has corresponding fractions 1-x PoW and 1-y PoS. The groups use their resources to construct long proof chains. Let f be a function evaluating the proof in a chain constructed using a PoW and PoS pair over a long time span. Of course PoW outcomes are random, but let's just ignore that to keep things simple. We must have f (x, y) > f (1-x, 1-y) or f (x, y) = f (1-x, 1-y) or f (x, y) < f (1-x, 1-y). That is the first group wins, it is a tie, or the first group loses. The winning group gets complete control over which txns enter PoW blocks. The losing group becomes completely irrelevant. f (x, y) = f (1-x, 1-y) describes a boundary on 0 <=x <=1 and 0 <=y <=1. If one group (good or bad) is on this boundary and adds on just a little bit of hashing power or a little bit of stake, then this group wins. Bitcoin uses the boundary x = 0.5 My ideal boundary is y = 0.5 (that's what you approach as the number of signatories per block increases) Your boundary needs to simulated because of the two difficulties. But if we ignore that (only matters over long intervals anyway) and make an additional assumption, we can calculate it. Here's the assumption: You are including invalidated empty blocks in the block chain. If these empty blocks contribute to proof just like normal blocks, a 51% PoW attacker can select the winning chain, even with 0% stake. This makes PoS close to pointless. To avoid this, I'm going to assume that the empty blocks do not contribute to proof at all. Then: A PoW block contributes to proof iff it has at least 3 stake votes. Proof Creation Rate = (Rate at Which Group Creates PoW Blocks) * (Probability Group Controls 3, 4, or 5 Stake Votes) Probability Group Controls 3, 4, or 5 Stake Votes is a binomial distribution with Pr (X>=3) for a binomial distribution with parameters n=5 and p=y for group 1 and p=1-y for group 2. http://en.wikipedia.org/wiki/Binomial_distributionPr (X>=3) = Pr (X=3)+Pr(X=4)+Pr(X=5)= 10y³(1-y)²+5y⁴(1-y)+y⁵ for group 1 Rate at which Group 1 creates PoW blocks is x*(total hash rate of both groups / PoW difficulty). So we have, Group 1 Proof Creation Rate = f(x,y) = (10y³(1-y)²+5y⁴(1-y)+y⁵) * (x) * (total hash rate of both groups / PoW difficulty) Group 2 Proof Creation Rate = f(1-x,1-y) = (10(1-y)³(y)²+5(1-y)⁴(y)+(1-y)⁵) * (1-x) * (total hash rate of both groups / PoW difficulty) The two groups are tied if (10y³(1-y)²+5y⁴(1-y)+y⁵) * (x) * (total hash rate of both groups / PoW difficulty) = (10(1-y)³(y)²+5(1-y)⁴(y)+(1-y)⁵) * (1-x) * (total hash rate of both groups / PoW difficulty) Solving for x gives us the boundary x = -6y⁵+15y⁴-10y³+1 on 0<=y<=1 In table form: x y 1 0 0.99144 0.1 0.94208 0.2 0.83692 0.3 0.68256 0.4 0.5 0.5 0.31744 0.6 0.16308 0.7 0.05792 0.8 0.00856 0.9 0 1 So yes, you probably weren't aware that you could win with 90% stake and 0.9% work. But why is that a problem? I guess it's not really a problem. If we include total number of stakeholder votes in a separate weighting function, you may also be able to attenuate double spends by any stakeholder less than 51%. Such a weighting function might be described as block=1{summation}block=n of (Stakeholder Votes in Block 1) + ... + (Stakeholder Votes in Block n) The attacker wishes to double spend and the exchange requires three secured (3+ Yea votes) blocks for confirmation. Now, he must mine a chain in secret and achieve 3 or more secured blocks. In the meantime, the main chain must have three secured blocks to actually get the money to the exchange. However, this honest chain will have great difficulty actually achieving valid blocks without the help of the attacker, who can not dump his alternative chain onto the network unless the sum of his votes on his dishonest chain are greater than for the honest chain. The attacker must now wait a long time to achieve his double spend attack, although it's still not impossible. With two weighting functions, you then end up with four conditions of the network when there are two chains in comparison with one another represented by (0,0), (0,1), (1,0), and (1,1). The first value indicates the condition of chain A being preferred over chain B using the first weighting metric, and the second value indicates the condition of chain A being preferred over chain B using the second weighting metric. For both conditions that are mixed, how should the main chain be selected? Is there some way you can think of to integrate the two weighting functions without further complicating things? You are correct in that invalidated blocks will not contribute to the blockchain for the calculation above. They do, however, contribute the following: 1) Stakeholder tickets used within them are invalidated and their invalidation is included in the blockchain (can't spend stakeholder tickets twice). 2) Entropy from the block header hash is used to calculate ticket selection/lottery (as the block header still represents actual work). There is a new attack that I just thought of if you force stakeholders to use their tickets when the lottery calls them. A PoW miner can submit blocks to the network full of garbage and use them to destroy PoS tickets, because the group of stakeholders in the next block will be sure to invalidate this block. This is a problem. How can this be mitigated? You could return the stakeholder tickets (so long as they actually voted) and let them be used again sometime in the future to validate a different block. Non-reporting stakeholder tickets should still be destroyed. This makes sense. PoS miners should not be penalized for voting correctly on the previous block when the present block is garbage. edit: There is another problem I think, which is recursive invalidation of the blockchain if you invalidate the previous block. It is what it sounds like; once you invalidate a block previous in a string of valid blocks, all the blocks before it become invalidated because that block confirms all of these blocks reverse sequentially. There needs to be a way to keep the PoS transactions free from the manipulative harm of the PoW chain in some way. I need to think about this some more, can't think of an easy solution off the top of my head. Perhaps just to have these stakeholders vote on the last block and then sign the one in which they are included in once it is submitted to the network is enough. |
|
|
|
you need to set environmental variables
easy mode: use guiminer-scrypt
Hi Taco, Funnily enough that's what I am now doing on the 2 that don't work with my .bat file on cgminer. Now happy at ~650kH/s. However, this doesn't help the important learning process of what I was (or wasn't) doing for it to produce the errors! See: https://bitcointalk.org/index.php?topic=117221.msg1256502#msg1256502Update: 3-20-13 cgminer versions 2.11.3 and up can be used to mine with high thread concurrencies now. Follow these instructions: WINDOWS: Open console and type setx GPU_MAX_ALLOC_PERCENT 100 Now, close the console (it will not work if you open cgminer in the same window). Open cgminer using a .bat or a new console, high thread concurrencies will now work. guiminer-scrypt is a bit nicer because it doesn't cause you to permanently alter your environmental variables, though. |
|
|
|
|
you need to set environmental variables
easy mode: use guiminer-scrypt
|
|
|
|
Looks real. Hit 3 TH/s today.  |
|
|
|
in 0.041 can you fix the way cudaminer closes please? It causes driver crash but it should close via Ctrl + C command which never causes driver crash in standalone version. It can cause driver crash or my entire pc to freeze and die.
I'm not sure how to resolve this, I'll try to communicate with the process to send the CTRL+C but I'll have to play with that later (communication with CUDAminer via subprocess appears totally borked at this point in time) In the meantime just execute the .bat file the program generates. |
|
|
|
Taco, due to the seemingly never-ending DDOS attacks on give-me-ltc.com and wemineltc.com (two of the best if not the two best pools), would you consider adding failover as an option for GUIMiner-scrypt?
The way I have my pools set up, they all have the same worker names and passwords on each pool, so the only field I would need to complete would be the site address and port for each of the 3 pools I would use.
I dont know how feasible this is, but I think it would be a great addition.
Also I dont know if I have the latest version, but if you havent replaced the Bitcoin icon with a Litecoin icon, consider doing so!
Failover is already there, you just add it to the "extra flags" field. It works great for me. Hallo FullLife! Can you please show us an example of the syntax for "failover" in "extra flags". Thanks, Blizzen See this post https://bitcointalk.org/index.php?topic=150331.msg1833329#msg1833329Sorry, I will update to 0.041 soon with support for failover pools. |
|
|
|
(mirror 2) has version 0.03 instead of the latest version, 0.04. fixed |
|
|
|
guess many insiders do it at least the ones who are capable to write opencl code and they wont share their code with just everyone as long as they are making profit. as soon as they dont make any profit anymore with mining they will sell the code, then when not making profit with selling anymore you will see it on github for free. If i am wrong prove it and publish working code  The data does not suggest this. According to mtlrt, at current N = 256, a top end video card could get around 2.004 MH/s with a HD6990 and his kernel. That means for a mid-size GPU farm owner with 50 7950s/7970s or such may see around 75MH/s or so, or more (a very rough estimate, based on performance difference between 6990 and 7950/7970). According to yacoind: # ./yacoind getmininginfo
{
"blocks" : 68606,
"currentblocksize" : 2275,
"currentblocktx" : 5,
"difficulty" : 3.01596016,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"networkhashps" : 72345435,
"pooledtx" : 5,
"testnet" : false,
"Nfactor" : 7,
"N" : 256,
"powreward" : 20.80000000
}
Current network hash rate is estimated at 72.3MH (this is with the newest yacoin source). With just ONE mid-range GPU farm owner being able to generate more than the current YaCoin network at this point, this does not look like there are ANY "GPU insiders" mining. Or if there are, they are not hitting it with a decent sized GPU farm. However, this also raises issues of the possibility of a 51% attack if one or two ill-meaning farm owners get a hold of a GPU miner. Let's hope mtrlt either holds on to his GPU kernel like it appears he has to this point, or if released, it's released to all. Anything else risks the stability of the YaCoin network. The other risk here is a possible inadvertent "difficulty attack" if this N=8192 issue is real and a GPU miner is released to all. At that point, difficulty would increase sharply, and once N=8192 is hit, drop off a cliff. I wonder if there would be enough hash power after that to get it back to a sane level without necessitating a hard fork like feathercoin has done (maybe WindMaster has more input on this). Also, whether POS minting would be enough during that time to validate new transactions on the network. Maybe others much more knowledgeable than I on these matters could comment. I am hopeful that the 8192 issue is a more fundamental problem with GPU mining on this coin. Most serious GPU miners have 7950s or 7970s instead of 6990s, so this issue may be run into even earlier on one of those cards, as the memory amount and bandwidth on the 7950 at least is a good amount less than on the 6990. This community is ingenious, however, as the litecoin experience had shown. But if you had the guy that wrote the scrypt kernel for reaper having issues at 8192 after trying multiple lookup gap and TMTO hacks, then there is some real life for this coin I think. It sounds more like a kernel level bug to me. Note that the author said it was throwing invalid hashes, not a very slow rate of valid hashes. |
|
|
|
Any progress or even a plan?
Most of my waking life is spent working right now. I'll update as soon as time affords it. |
|
|
|
|
^^ Have you tried playing with the lookup gap more? You should still hit faster GPU performance as by 8192 you will have moved off the CPU cache and are writing to RAM (maybe also L3).
|
|
|
|
I benched at around 100 ms/hash per thread with a 2700k when using 8 MB. This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two.
Solid, within a year hashes will go from MH/s to double digit H/s  Network difficulty will drop like crazy and block reward will You were off by a pretty large amount at both ends of the numbers you said hash rate would traverse over the course of a year. However, with a more thorough calculation: Best interpretation (most favorable to you) of your statement is that hash rates go from 1MH/sec to 99.999 H/sec over the course of the first year, a decrease in speed of about 10000x. My benchmark showed a decrease of speed over the course of the first year of 358.77kH/sec to 0.606kH/sec with one particular common server CPU, a decrease in speed of about 592x. 10000 vs 592. Or we could calculate that as 10000 / 592 = 16.9 and call that a single order of magnitude (plus change). A strict interpretation of Wikipedia's "order of magnitude" article would suggest that this is the correct way. So, I concede that you were off by a bit more than an order of magnitude if we analyze the most favorable interpretation of your statement. I benched at around 100 ms/hash per thread with a 2700k when using 8 MB. This was more than a year ago using scrypt jane, so maybe the code has been optimized.
Was the scrypt-jane library available somewhere prior to September 13, 2012? If so, I'd like to snag a copy of that earlier version you benchmarked with. Which hashing algorithm in the scrypt-jane library was that benchmark performed with? You're a feisty one. You're correct on the date, it was during the memcoin thread which was apparently November of last year, so I guess only six months old. Guess my memory slipped, but things move quickly these days. If the scrypt-jane library starts having trouble at certain values of N (and it looks fine up through at least N=32768 that I've tested so far), I'd think we would only need to fix the problem in the library and release a new update to the client, rather than hard fork. It works fine above that, I've used it beyond 32768 (see that thread). |
|
|
|
Solid, within a year hashes will go from MH/s to double digit H/s Network difficulty will drop like crazy and block reward will explode, destroying any value the coin might have had. While I often agree with a number of the things you've said, I'm worried you're starting to exaggerate. In the main YACoin thread, today you posted that anyone could've developed a GPU miner days in advance, yet only the original developer (and anyone he tipped off) could've been aware he was going to pull a surprise move and use a different hashing algorithm than anyone was expecting. Changing from scrypt+salsa20/8+SHA256(1024,1,1) to scrypt+chacha20/8+Keccak512(N,1,1) did turn out to be significantly more than just a copy-paste exercise from the scrypt-jane library source, at least for anything that was going to go faster on GPU's than typical desktop CPU's. In your comment above, I think your numbers are exaggerated a bit. I just benchmarked with a Linux build of cpuminer and forced N to various values: Platform: IBM HS21 blade server, 2x Xeon E5450's (similar combined performance to one i7-2600k). For N=32 (at coin's launch), hash rate = 358.77 kH/sec For N=256 (right now), hash rate = 119.25 kH/sec For N=32768 (in one year), hash rate = 0.606 kH/sec So, anyway, when I see exaggerations that are off by 2 orders of magnitude, I'm afraid I'll have to call you out on it (as much as I respect you). I'd prefer to see you discredit a coin with accurate info, not exaggerations. I benched at around 100 ms/hash per thread with a 2700k when using 8 MB. This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two. You need to address the problem with block reward with a hard fork as soon as possible, in my opinion. You'll probably end up with a slightly more valuable coin if you relaunch it later forking from the litecoin code instead once the GPU miner has been released. |
|
|
|
YACoin Technical Data(this post will contain information about the basic parameters of YACoin, including more information on the hashing algorithm which is *not* called scrypt-jane, timeframe for N increases, PoS details when they become known, etc) The schedule of N changes for YACoin is: | Nfactor | | N | | Memory | | UNIX Time | | Date/Time in GMT | | 4 | | 32 | | 4kB | | 1367991200 | | Wed - 08 May 2013 - 05:33:20 GMT | | 5 | | 64 | | 8kB | | 1368515488 | | Tue - 14 May 2013 - 07:11:28 GMT | | 6 | | 128 | | 16kB | | 1368777632 | | Fri - 17 May 2013 - 08:00:32 GMT | | 7 | | 256 | | 32kB | | 1369039776 | | Mon - 20 May 2013 - 08:49:36 GMT | | 8 | | 512 | | 64kB | | 1369826208 | | Wed - 29 May 2013 - 11:16:48 GMT | | 9 | | 1024 | | 128kB | | 1370088352 | | Sat - 01 Jun 2013 - 12:05:52 GMT | | 10 | | 2048 | | 256kB | | 1372185504 | | Tue - 25 Jun 2013 - 18:38:24 GMT | | 11 | | 4096 | | 512kB | | 1373234080 | | Sun - 07 Jul 2013 - 21:54:40 GMT | | 12 | | 8192 | | 1MB | | 1376379808 | | Tue - 13 Aug 2013 - 07:43:28 GMT | | 13 | | 16384 | | 2MB | | 1380574112 | | Mon - 30 Sep 2013 - 20:48:32 GMT | | 14 | | 32768 | | 4MB | | 1384768416 | | Mon - 18 Nov 2013 - 09:53:36 GMT | | 15 | | 65536 | | 8MB | | 1401545632 | | Sat - 31 May 2014 - 14:13:52 GMT | | 16 | | 131072 | | 16MB | | 1409934240 | | Fri - 05 Sep 2014 - 16:24:00 GMT | | 17 | | 262144 | | 32MB | | 1435100064 | | Tue - 23 Jun 2015 - 22:54:24 GMT | | 18 | | 524288 | | 64MB | | 1468654496 | | Sat - 16 Jul 2016 - 07:34:56 GMT | | 19 | | 1048576 | | 128MB | | 1502208928 | | Tue - 08 Aug 2017 - 16:15:28 GMT | | 20 | | 2097152 | | 256MB | | 1602872224 | | Fri - 16 Oct 2020 - 18:17:04 GMT | | 21 | | 4194304 | | 512MB | | 1636426656 | | Tue - 09 Nov 2021 - 02:57:36 GMT | | 22 | | 8388608 | | 1GB | | 1904862112 | | Mon - 13 May 2030 - 00:21:52 GMT | | 23 | | 16777216 | | 2GB | | 2173297568 | | Sat - 13 Nov 2038 - 21:46:08 GMT | | 24 | | 33554432 | | 4GB | | 2441733024 | | Fri - 17 May 2047 - 19:10:24 GMT | | 25 | | 67108864 | | 8GB | | 3247039392 | | Tue - 22 Nov 2072 - 11:23:12 GMT | | 26 | | 134217728 | | 16GB | | 3515474848 | | Mon - 26 May 2081 - 08:47:28 GMT | | 27 | | 268435456 | | 32GB | | 5662958496 | | Sat - 14 Jun 2149 - 12:01:36 GMT | | 28 | | 536870912 | | 64GB | | 6736700320 | | Tue - 24 Jun 2183 - 01:38:40 GMT | | 29 | | 1073741824 | | 128GB | | 9957925792 | | Tue - 21 Jul 2285 - 18:29:52 GMT | | 30 | | 2147483648 | | 256GB | | 14252893088 | | Sat - 28 Aug 2421 - 00:58:08 GMT |
N is calculated from Nfactor as follows: N = 1 << ( Nfactor + 1 ) Solid, within a year hashes will go from MH/s to double digit H/s Network difficulty will drop like crazy and block reward will explode, destroying any value the coin might have had. |
|
|
|
This is a very bad idea. You have just introduced another litecoin cgminer gpu catastrophe
I would not be surprised if people, maybe even many people independently, have forked and created their own cgminer in secret which is capable of utilizing GPUs, giving them several order of magnitude advantage over everyone else.
Actually, this is already happening. I've seen 3 people posting they have working opencl kernels (two of them had relatively low hashrates, the third one claims to be the dev of the Reaper litecoin gpu miner and has hashrates in the Mh/s range). So.. 174 pages. Surely someone pointed this out and brought it to the dev's attention? I pointed out that GPU miners could easily be created days before release. Dev ignored it. |
|
|
|
Aaaaand the truth comes out. Indeed. You passed the test to check if you know what you're talking about. Crafty. I like your style. You would indeed be one of the people I'd expect to have modified your own OpenCL code for scrypt+chacha fairly early on. Anyway, willing to post some hash rate info for your kernel at the current N=128 for a given GPU type and lookup gap (if any)? You can probably post that info safely without giving anyone a head-start on making the modifications themselves.
The knowledge might give others incentive to do it, but oh well. Currently (N=128) it does 3.4MH/s on a core-underclocked (830->738) HD6990, with lookup_gap at 1, thus no gap. As a curiosity, at N=32, it does 7.3MH/s under the same setup.Out of curiosity, how many hours after launch or after you started modifying your OpenCL kernel did it take you to make the changes? Mainly a point of curiosity, for comparison with how many hours it took me. I went from scratch rather than modifying the Reaper/cgminer kernel though, so my hour comparison will differ a bit because of that.
I was a bit late, I started coding the miner about 16h after the launch. It took me 13.5h from start, to a working implementation. It was very intensive, as you might imagine. Difficulty rising like no tomorrow, and my code only gave errors, until it finally worked. Debugging OpenCL code is horrible. :-) |
|
|
|
I also have a working YAC kernel for my own miner, Reaper.
 Just want to know one thing: Do GPUs throw CPUs into the water? I told everyone... |
|
|
|
|
Show Posts
