When it comes around time to finally release this, I would like, for once, for there to be a 48 hour announcement period BEFORE the clients are released.
Same here. I want some notice so that I can get my miner set up before the action commences. This coin looks like it could be around for the long haul, and I'd love for my early-adopter investment to pay off. Client (along with a CPU and GPU miner) will be encrypted by scrypt and packaged with a program to decrypt it long before the actual release. A time will then be given for mining to begin. At this time, you get the password, and everyone gets to mine at the same time. Depending on the interest expressed, the starting difficulty will be set at around 2000-6000 7970's worth of power for 2 minute/block target time. Multiple pools are also planned to be available at launch. |
|
|
|
Can we close this thread?
MODS!!!
 |
|
|
|
So instead of safely and securely mining the 5% yearly PoS, they would spend a lot of money in energy and hardware and hope the god of the random numbers doesn't yield a wooping total of zero profit. Risk has to be priced in too.
...not sure if serious. I could mine a block at N=2^20 and diff 1 right now, it'd just take a little while to calculate. |
|
|
|
No, because suddenly you have blocks that are worth 100 coins because the difficulty is so low and no one can mine quickly.
If electric and hardware cost is higher than PoW/day reward at that point, then PoW dies regardless of the difficulty and block reward and all mining happens by PoS. Ultimately, reward could be infinite and difficulty zero, if my hashing rate is zero I won't get any coins. It won't be zero, just really really slow -- so diff 1 or 2. At difficultly 1, every other hash you make gets a block statistically. Increasing the amount of resources required to mine (and thus decreasing the difficulty required to solve a block out of necessity) is completely counterintuitive to the energy efficiency model proposed by PPC and later by NVC in their reward adjustment algorithm. |
|
|
|
Time has proven that Artforz wasn't aware of the TMTO tradeoff that he later tried to address with TMTO defeaters that weren't released to public (because he eventually defeated them again himself, at which point he gave up). There is not a simple, magical solution to this problem and it remains at the forefront of crypto research. Now you're just arguing on the internet... |
|
|
|
Yet the Windows build gave me 60 KH/s while my Ubuntu build gave me 400 KH/s with my 2700K -- totally different story.
Anyway, who wants to buy some YAC?
400 KH/s? I'm getting merely 200-400kH/s on my Intel hexacore. That said I cannot use the AVX optimisation as it runs inside Virtualbox. However, I don't see how this is a totally different story -- we have the same with ASICs for Bitcoin, GPUs that arrived for Litecoin etc. YAC might not be more "pure" than other coins. But at least it is a new concept and not a simple clone such as FTC and CNC. I have my doubts whether it is the right concept. But only time will tell. I also find it hypocritical to ask for a "fair" coin. What is fair? Fair, so that everybody can profit? Fair, so that "I" can profit enough and in particular more than the other guy that I'm envious of? Fair, so I can dump it onto buyers and cash out? Is anybody even remotely thinking about the original motivation of a coin? To make digital payments easy and secure. Mining surely was more of a necessary evil (consuming Megawatts and 100k$/day) than a wanted aspect of the network. I could think of a strategy that should limit the required mining power. Unfair is when I make lots more than everyone else for no greater effort -- which is what I've done repeatedly. Like I said, I got a bunch of YACs. But I figure people not into the crypto p'n'd' scene will fail to see the value of something that has ponzi-scheme like distributions in the first week that it's out. |
|
|
|
This is one of the reasons that the YACoin chain makes no sense itself, because it eventually intends to use values of N in the gigabyte range.
Won't people be mainly mining PoS by the time Scrypt PoW uses more memory than a cheap home computer can hold? At worst it's just a kill switch for PoW to try to make it economically unfeasible to use specialized hardware. No, because suddenly you have blocks that are worth 100 coins because the difficulty is so low and no one can mine quickly. The difficulty algorithm in the code increases block reward with decreasing difficulty. |
|
|
|
I meant scrypt(1024, 1, 1) should be set to something like scrypt(1024, 128, 1)*. Setting the second parameter to "1" means that IT'S NOT GPU RESISTANT. Artforz fucked a lot of guys with his set of parameters.
* scrypt(CPU cost, memory cost, parallelization cost)
N isn't CPU cost, it's CPU and memory cost. And even at that, there's little different between using N or r to increase memory usage past a certain point because you become very quickly memory bandwidth limited. You're welcome to test it out with scrypt-jane if you want to, though. You'll see that when memory consumption is equivalent with either N or R being used to increase it the time to get a hash is about the same past 128 KB or so of memory usage. |
|
|
|
You might be thinking of the GPU mining code -- no one knows if Artforz was able to get a GPU miner for Litecoin running after he realized that the TMTO issue with scrypt allowed for faster mining by GPU. It's still a possibility; Artforz mined privately with his GPU miner when he implemented it for the Bitcoin chain, then only gave out the source code later.
I recall an issue related to the chosen parameters (1024, 1, 1). This set of parameters leads to degeneracy of the algo (in mathematical sense), making it's easier to create GPU mining soft. Indeed, at the time someone immediately called out ArtForz about the choice of scrypt(1024,1,1) in pretty much the very next forum post. I believe the wording was something along the lines of "are you joking?" and "don't you know anything about OpenCL?" when ArtForz suggested it would be GPU resistant. Artforz logic was that the L2 CPU cache would be fast enough that it could compete with a GPU implementation. I spoke with him myself around the time of the release of Tenebrix; the numbers he gave me for his naive GPU implementation were in line with those when running reaper with lookup_gap = 1 (which offers at most a 200% advantage). |
|
|
|
You might be thinking of the GPU mining code -- no one knows if Artforz was able to get a GPU miner for Litecoin running after he realized that the TMTO issue with scrypt allowed for faster mining by GPU. It's still a possibility; Artforz mined privately with his GPU miner when he implemented it for the Bitcoin chain, then only gave out the source code later.
I recall an issue related to the chosen parameters (1024, 1, 1). This set of parameters leads to degeneracy of the algo (in mathematical sense), making it's easier to create GPU mining soft. That wasn't the problem (although the author of this coin is trying to use that to sell you on it). Regardless of the value of N, the GPU will likely be faster until you hit some value in the hundreds of megabytes that requires all of the 8-16 GB of RAM available on a modern computer. The reason for this is because you can adjust the amount of memory usage in exchange for number of ALU cycles (this is exactly what the "lookup_gap" variable does in reaper/cgminer). But at a value of N large enough to prohibit faster GPU mining, a single hash is measured in seconds to minutes. This makes it impossible to use for a blockchain hash and was detailed in the memcoin thread I created a long time ago. Most of the ideas for YACoin came from the specifications for that coin, which were later revealed (to my chagrin) to make no sense. This is one of the reasons that the YACoin chain makes no sense itself, because it eventually intends to use values of N in the gigabyte range. |
|
|
|
Are you kidding me? I was one of the first Tenebrix and Litecoin miners, and I mined with an AMD cluster. Artforz just had trouble optimizing for Intel, so for a while AMD and Intel were neck and neck until pooler did some tricks with cache access and assembly to finally get the performance out of intel GPUs that everyone was expecting from them. End of the day, a few months after Tenebrix was released you could finally mine with 60 KH/s on your Intel CPU as compared to 40 KH/s with Artforz' original code. Whoop-de-doo, a 50% improvement.
Well. I may be wrong and that was unintentional. You might be thinking of the GPU mining code -- no one knows if Artforz was able to get a GPU miner for Litecoin running after he realized that the TMTO issue with scrypt allowed for faster mining by GPU. It's still a possibility; Artforz mined privately with his GPU miner when he implemented it for the Bitcoin chain, then only gave out the source code later. |
|
|
|
tl;dr pretty much everyone running the Windows binaries from the onset was screwed.
The same was with Litecoin. Almost everyone was mining on unoptimized miner until pooler published his optimized version. Scams everywhere. Are you kidding me? I was one of the first Tenebrix and Litecoin miners, and I mined with an AMD cluster. Artforz just had trouble optimizing for Intel, so for a while AMD and Intel were neck and neck until pooler did some tricks with cache access and assembly to finally get the performance out of intel GPUs that everyone was expecting from them. End of the day, a few months after Tenebrix was released you could finally mine with 60 KH/s on your Intel CPU as compared to 40 KH/s with Artforz' original code. Whoop-de-doo, a 50% improvement. Yet the Windows build gave me 60 KH/s while my Ubuntu build gave me 400 KH/s with my 2700K -- totally different story. Anyway, who wants to buy some YAC? |
|
|
|
Ahh, It's always the same.... A small bunch calling premine and crying about being late.
In 2 hours time there will be 10 new altcoins launched and new folks to whinge about those.
So. Fair play, but this ain't going to spoil YacCoin.
I'm not complaining, I have lots of them. |
|
|
|
tl;dr pretty much everyone running the Windows binaries from the onset was screwed.
Possible alternative, everyone that didn't immediately start figuring out how to port the scrypt chacha code and (relatively slowly changing) variable N to the cgminer GPU kernel were actually screwed from the onset regardless whether they were running Windows or Linux? From experience running a substantial server farm mining YAC yesterday, and looking at the difficulty and block solving rate today, I'm pretty skeptical that CPU mining accounts for most of the apparent hash rate. This is pretty likely. If I can pull 400 kh/s on a 2700k, my guess is that a 7970 could pull several mh/s at the current difficulty/N. |
|
|
|
Can't help but think there are either some huge cpu farms working this now, or it's being gpu mined now.
Probably a mix of both. I was stuck in "newbie jail" so I couldn't weigh in earlier (this was the first thread I thought worth actually registering to post in). I got a late start, about 8 hours after the coin was released. I commenced mining with 800 servers with 2x Xeon E5450's (rows and rows of IBM BladeCenters) when difficulty was reaching 0.008. Shortly after, I provisioned an additional 760 Amazon c1.xlarge instances, starting when difficulty was reaching 0.020. I shut everything down when difficulty reached 0.1 last night. Observations, orphan rate was about 20% across all 1560 servers, with an average of ~60 connections (modified outbound connection count in the client). At the time I shut everything down with difficulty at 0.1, I was solving roughly 15% of the blocks. Hash rate on the 2x E5450 servers averaged about 300kH/sec, and the Amazon c1.xlarge instances averaged about 200kH/sec, so I was mining with apprx 392,000kH/sec. Based on that, I estimate the network hash rate was actually about 2,613,333kH/sec at that time. Yeah, I know I could probably calculate a better figure from the block spacing vs. difficulty, but I didn't feel like digging into the source to determine the exact relationship between hash rate, difficulty and block solving rate. And I know from trying to estimate block solving rate with litecoinpool's calculator that Yacoin's difficulty calculation differs significantly from LTC. It's entirely possible that a large number of people also had the same bright idea to spin up a huge number of Amazon EC2 instances and that could possibly account for the hash rate, but I suspect the reality is that GPU farms were crunching Yacoin based on my observations. Either that, or Amazon was the party that profited the most from Yacoin (so far). :-) Just for kicks, I fired 100 servers back up a bit ago to mine for a while starting when difficulty was 0.3, just to see how things compare. I see 0% orphan rate now over the last couple hours and I'm definitely still solving blocks.. People trying linux for the first time, you need to run this command before you can make it with QTcreator Code: sudo apt-get install qt4-qmake libqt4-dev build-essential libboost-dev libboost-system-dev libboost-filesystem-dev libboost-program-options-dev libboost-thread-dev libssl-dev libdb4.8++-dev More details here: http://ubuntuhak.blogspot.ca/2012/11/bitcoin-basics-and-ubuntu-1204.htmlI really like that people here were all raving about the lack of a premine. Apparently you've all been had if you've been running the Windows binaries of the program that were released at launch, because my Linux binaries are about 10x faster. OP on linux probably had 10,000 blocks before anyone else. Good call though for OP, release a Windows version that 95% of people on here will use that mines 10 times as slow, and it doesn't look like you've got an actual premine but you yourself are mining an order of magnitude faster than everyone else. He'll probably be walking away with bags full of money. tl;dr pretty much everyone running the Windows binaries from the onset was screwed. |
|
|
|
you might want to change "People trying linux for the first time," to "People trying Ubuntu linux for the first time," some might install something like fedora linux  Who runs fedora?  But yeah, I use Ubuntu, those instructions are for Ubuntu too. |
|
|
|
People trying linux for the first time, you need to run this command before you can make it with QTcreator sudo apt-get install qt4-qmake libqt4-dev build-essential libboost-dev libboost-system-dev libboost-filesystem-dev libboost-program-options-dev libboost-thread-dev libssl-dev libdb4.8++-dev More details here: http://ubuntuhak.blogspot.ca/2012/11/bitcoin-basics-and-ubuntu-1204.htmlI really like that people here were all raving about the lack of a premine. Apparently you've all been had if you've been running the Windows binaries of the program that were released at launch, because my Linux binaries are about 10x faster. OP on linux probably had 10,000 blocks before anyone else. Good call though for OP, release a Windows version that 95% of people on here will use that mines 10 times as slow, and it doesn't look like you've got an actual premine but you yourself are mining an order of magnitude faster than everyone else. He'll probably be walking away with bags full of money. |
|
|
|
Miner shows some pretty strange numbers occasionally so you would need to do that command multiple time during some longer period to find out what the hash really could be.
Number hovers around 350-425 KH/s As I said above, all I did was compile with those flags in Linux Trying this now. I'm still downloading the blockchain in ubuntu so I'm assuming that my gethashespersec of 0 will change once that is done? Here are the instructions Edit the qt .pro QMAKE_CXXFLAGS += -O3 -march=core-avx-i
QMAKE_CFLAGS += -O3 -march=core-avx-i Compile, run ./yacoin-qt -gen -genproclimit=8 YH1q1wuVyznBAzKJN19akXgFaBSdbgbQih |
|
|
|
Because it's bad in terms of throughput in a software implementation doesn't necessarily mean that there will be no advantage from using an ASIC. In fact, I would be surprised if fast syndrome based hashes or chaotic hashes weren't still much faster on an FPGA/ASIC, as at the end of the day it likely just boils down to yet more logical gates being used. I'm leaning much more towards algorithms that have had more extensive cryptanalysis done on them so that I can ensure the blockchain is secure rather than applying a hash that requires a bloat of logic gates (which may or may not be reducible; a lot of these implementations are probably just straight C++). In fact, an FSB hash has already been done on FPGA: http://csg.csail.mit.edu/6.375/6_375_2009_www/projects/group2_report.pdfAs stated earlier, our first approaches to implementing FSB failed to fit on the FPGA. We
had problems with both too much on-chip memory usage and too much combinational logic.
The tables below lists our resource usage before and after we made the area reducing changes.
Component First Version Final Version
ROM Bits 2,477,824 435,968
Combinational Logic 158,518 60,327 As I said before, with optimization it's like you can get these chaotic based hashes to fit into an FPGA too. |
|
|
|
I get 400 KH/s on a 2700K using
-O3 -march=core-avx-i
with the QT client.
windows or linux?what is the full command? Linux Edit the qt .pro QMAKE_CXXFLAGS += -O3 -march=core-avx-i
QMAKE_CFLAGS += -O3 -march=core-avx-i Compile, run ./yacoin-qt -gen -genproclimit=8 YH1q1wuVyznBAzKJN19akXgFaBSdbgbQih |
|
|
|
|
Show Posts
