Mining on cgminer (no block yet):  PS> Ty Taco for suggestions. BTW, if you're getting HW errors it probably means that the hashes aren't being confirmed by the CPU. Double check that you implemented the code in scrypt.c correctly and that you are using a high enough thread concurrency (set your network target to something like diff 4 then try to submit there, they will all come up as rejected by the network but you can verify you wrote the code correctly if they are). |
|
|
|
I hooked up an old pc turn it on put yacoin there and start mining instantly i get block found before wallet is synced with 100 yac...
WTF
It'll end up as an orphaned block. Current block-reward is less than 50 YAC (reward goes down with # of blocks in the chain, started at 100). No, it goes down with difficulty increases, same as PPC/NVC. It looks like it uses the same reward algo as NVC. int64 GetProofOfWorkReward(unsigned int nBits)
{
CBigNum bnSubsidyLimit = MAX_MINT_PROOF_OF_WORK;
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
CBigNum bnTargetLimit = bnProofOfWorkLimit;
bnTargetLimit.SetCompact(bnTargetLimit.GetCompact());
// ppcoin: subsidy is cut in half every 64x multiply of difficulty
// A reasonably continuous curve is used to avoid shock to market
// (nSubsidyLimit / nSubsidy) ** 6 == bnProofOfWorkLimit / bnTarget
//
// Human readable form:
//
// nSubsidy = 100 / (diff ^ 1/6)
CBigNum bnLowerBound = CENT;
CBigNum bnUpperBound = bnSubsidyLimit;
while (bnLowerBound + CENT <= bnUpperBound)
{
CBigNum bnMidValue = (bnLowerBound + bnUpperBound) / 2;
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : lower=%"PRI64d" upper=%"PRI64d" mid=%"PRI64d"\n", bnLowerBound.getuint64(), bnUpperBound.getuint64(), bnMidValue.getuint64());
if (bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnTargetLimit > bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnTarget)
bnUpperBound = bnMidValue;
else
bnLowerBound = bnMidValue;
}
int64 nSubsidy = bnUpperBound.getuint64();
nSubsidy = (nSubsidy / CENT) * CENT;
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : create=%s nBits=0x%08x nSubsidy=%"PRI64d"\n", FormatMoney(nSubsidy).c_str(), nBits, nSubsidy);
return min(nSubsidy, MAX_MINT_PROOF_OF_WORK);
} |
|
|
|
Did you completely skip the op?
Using scrypt(N, 1, 1) means that only solo cpu mining will work until someone will fork mining pool software or implement GPU miner. All existing miners aren't compatible.
The core idea is that we have to use and to try different hash algos to make cryptofinances more secure and stable. I guess someone (multiple people) figured out how to copypasta from scrypt-jane into the cgminer scrypt kernel with a few tweaks and mine with cgminer. You do have to make cgminer verify the hash after by also altering scrypt.c, too. |
|
|
|
PS> Ty Taco for suggestions.
NP. |
|
|
|
|
The bigger concern is onset GPU miners and the fact that the concept behind it makes no sense (as soon as N>1024, GPU will have a huge advantage because memory bandwidth GPU >> memory bandwidth DDR3). That, and that at the max N factor it'll take years for the blockchain to even download and confirm.
|
|
|
|
I also believe the OP may be a bit BIP incompliant. I do not see an RPC command or a Field in getwork - getworkex or getblocktemplate that gives the current Nfactor. I may be wrong and missed it, but withholding vital mining information from RPC is ,shall we say "dirty pool"  Here is where it's calculated in the source // yacoin: increasing Nfactor gradually
const unsigned char minNfactor = 4;
const unsigned char maxNfactor = 30;
unsigned char GetNfactor(int64 nTimestamp) {
int l = 0;
if (nTimestamp <= nChainStartTime)
return 4;
int64 s = nTimestamp - nChainStartTime;
while ((s >> 1) > 3) {
l += 1;
s >>= 1;
}
s &= 3;
int n = (l * 170 + s * 25 - 2320) / 100;
if (n < 0) n = 0;
if (n > 255)
printf("GetNfactor(%d) - something wrong(n == %d)\n", nTimestamp, n);
unsigned char N = (unsigned char)n;
//printf("GetNfactor: %d -> %d %d : %d / %d\n", nTimestamp - nChainStartTime, l, s, n, min(max(N, minNfactor), maxNfactor));
return min(max(N, minNfactor), maxNfactor);
} Note that "N factor" means 2^N, so minimum is N=16. But it doesn't really matter what N is, you can just keep increasing the lookup_gap on higher N values and I think you still will get 5-10x better GPU performance (particularly once you offload onto DDR3 memory with the CPU, when N > 1024 or N factor is > 10; you're outside of the L2 cache at that point and the DDR3 is slooooow in comparison to GDDR5 so you should see at least 10x performance I would guess). |
|
|
|
"moneysupply" : 1,545,669
Yep. |
|
|
|
So, instead of getting raped by GPU farms, we are now getting raped by multi-CPU server farms  No, just the CPUs on GPU farms.  Probably you're getting raped by GPU farms, too. You don't need to change the kernel from cgminer or reaper all that much to GPU mine this coin right now, and at the current value of N I would wager that most GPUs get 1000+ KH/s. |
|
|
|
// yacoin: increasing Nfactor gradually
const unsigned char minNfactor = 4;
const unsigned char maxNfactor = 30;
unsigned char GetNfactor(int64 nTimestamp) {
int l = 0;
if (nTimestamp <= nChainStartTime)
return 4;
int64 s = nTimestamp - nChainStartTime;
while ((s >> 1) > 3) {
l += 1;
s >>= 1;
}
s &= 3;
int n = (l * 170 + s * 25 - 2320) / 100;
if (n < 0) n = 0;
if (n > 255)
printf("GetNfactor(%d) - something wrong(n == %d)\n", nTimestamp, n);
unsigned char N = (unsigned char)n;
//printf("GetNfactor: %d -> %d %d : %d / %d\n", nTimestamp - nChainStartTime, l, s, n, min(max(N, minNfactor), maxNfactor));
return min(max(N, minNfactor), maxNfactor);
} maxNfactor = 30... or 1,073,741,824 or 134,217,728 KB used. Yikes. If the chain gets to even 32 MB in the first year the thing will trainwreck. I suspect a GPU miner is already out for this one, if not in public. There's not actually that much that needs to be changed in litecoin-reaper.cl, and right now GPUs should destroy CPUs. |
|
|
|
Version 0.04 alpha is uploaded. Enjoy, and sorry cudaminer doesn't work perfectly, but it will make batch files automatically.
Other than cudaminer, what other changes did you implement? see op |
|
|
|
Update coming (hopefully) soon, code is done but cudaminer isn't reporting to stdout properly. As soon as this issue is solved with the cudaminer dev 0.04 will be out. A few bugs were also fixed.
One little request. Different icon, so it's distinguishable between multiple instances that use the same icon in the tray(a lot of different CryptoCurrency proggies are using the same icon.)  Whipped this up for you to use however you want, if that helps.  http://ge.tt/49tPFyf/v/0?c <-already packaged ico download link of the 4 above icons. Thanks, I have used this for 0.04 |
|
|
|
|
Version 0.04 alpha is uploaded. Enjoy, and sorry cudaminer doesn't work perfectly, but it will make batch files automatically.
|
|
|
|
|
I will release v0.04 with broken cudaminer support today. Unfortunately, I haven't heard from the programmer about fixing the program, and I have no way to get its output from stdout right now. You can still start/stop it with guiminer and see if it's getting shares through the proxy. In addition to this, it writes a .bat file in the cudaminer folder that runs the command line version of the program with the settings you've selected.
A few other bugs have been patched, notably one that fixes the "Starting..." hang when trying to start a miner when your windows username has a space in it.
|
|
|
|
Fault tolerance (it's not guaranteed that you will find exactly the same hash) and because if you reject blocks with only one Nay vote you may not invalidate any block you'd like to with only 20%. 10% stake means half the blocks, etc. You also don't want to invalidate blocks based one one or two MIA signatories, as with 3 signatories the chain still works fine.
You also add a very easy attack vector by unanimous voting requirement, as you only need to DDoS one node per block to control the chain.
No. If you have 20% of tickets, then you will have one or more votes on 1-0.8^5 = 67% of blocks. You can make 2/3 of blocks empty, but the other 1/3 will go through. That is money burning fail, not a credible DDOS. Perhaps you meant something else? Invalidation of draws that lack unanimity increases PoW attack resistance. By a lot. I will show you the math if it helps. As a comprimise, how about 4 yay's or more, instead of 3 or more? That would still help. Alternatively, You can also strengthen the system by increasing the number of voters. Say 6 out of 10 instead of 3 out of 5. Again, I will show you the math if this helps. This would not be my first choice, but I think it would be fine. Anyways, these are still parameter choices. Easily forked. It is still the core algorithm that matters. I'm still not sure of your argument. You can simulate a blockchain with this stakeholder signing agreement (and the assumption that 100% of stakeholders will vote) in the following python program: import math, os, random
random.seed("wefkw34DfsQ3A75")
stake_percent = raw_input("Enter stake percent of attacker (0.0000-1.0000): ")
blocks = raw_input("Enter number of blocks for simulation: ")
stakeholder_pool = raw_input("Enter number of random stakeholders: ")
stake_requirement = raw_input("Enter stake requirement to invalidate block: ")
blocks_passed = 0
blocks_invalidated = 0
print("Calculating...")
for i in range(int(blocks)):
vote_sum = 0 # The total number of attacker votes
for j in range(int(stakeholder_pool)): # Run loop for all stakeholder tickets
if float(stake_percent) > random.random(): # Calculate whether or not a ticket has been afforded to a malicious or non-malicious stakeholder
vote_sum += 1 # If it has been given to an attacker, add +1 attacker votes towards invalidating the block
if vote_sum < int(stake_requirement): # If we have don't enough attacker votes...
blocks_passed += 1 # The block passes through the blockchain as valid
else:
blocks_invalidated += 1 # The block is invalidated by the attacker
final_percent = float(blocks_invalidated) / (float(blocks_passed) + float(blocks_invalidated))
print("Blocks passed: " + str(blocks_passed))
print("Blocks invalidated: " + str(blocks_invalidated))
print("Percentage of blocks invalidated: " + str(final_percent)) Now, if we run it for the round of 5 scenario you described with unanimous voting required, Enter stake percent of attacker (0.0000-1.0000): 0.2000
Enter number of blocks for simulation: 100000
Enter number of random stakeholders: 5
Enter stake requirement to invalidate block: 1
Calculating...
Blocks passed: 32712
Blocks invalidated: 67288
Percentage of blocks invalidated: 0.67288 With majority voting required to invalidate: Enter stake percent of attacker (0.0000-1.0000): 0.2000
Enter number of blocks for simulation: 100000
Enter number of random stakeholders: 5
Enter stake requirement to invalidate block: 3
Calculating...
Blocks passed: 94160
Blocks invalidated: 5840
Percentage of blocks invalidated: 0.0584 Now the attacker succeeds only 5.8% of the time. What about if the stakeholder has 51% stake? Enter stake percent of attacker (0.0000-1.0000): 0.5100
Enter number of blocks for simulation: 100000
Enter number of random stakeholders: 5
Enter stake requirement to invalidate block: 1
Calculating...
Blocks passed: 2855
Blocks invalidated: 97145
Percentage of blocks invalidated: 0.97145 Enter stake percent of attacker (0.0000-1.0000): 0.5100
Enter number of blocks for simulation: 100000
Enter number of random stakeholders: 5
Enter stake requirement to invalidate block: 3
Calculating...
Blocks passed: 47981
Blocks invalidated: 52019
Percentage of blocks invalidated: 0.52019 As expected, the malicious stakeholder gets about 51% (0.52019) in the scenario of a 3 of 5 requirement, but in a 1 of 5 requirement, the stakeholder now has 97% control of the blockchain. It get worse quickly with increasing malicious stakeholder wealth with the unanimous system; at 30% we see 83% control of the chain, and at 40% we see 92% control of the chain. This is a totally valid attack vector to consider, because it makes stakeholder-mining pool collusion extremely likely. The mining pool uses the stakeholder to invalidate the blocks of all competing PoW miners on the network, gives a fraction of their earning to the stakeholder, and then themselves now gets 100% of the network income as opposed to only a fraction before. Miners, unable to get any coins, drop off the network, difficulty goes down, and the malicious pool now gets even more coins. The malicious pool and stakeholder wins, everyone else loses, and the system is effectively centralized. |
|
|
|
What's going on now?
New PoS system proposed along with a few other modifications; see new whitepaper I'm going to sleep |
|
|
|
Fault tolerance (it's not guaranteed that you will find exactly the same hash) and because if you reject blocks with only one Nay vote you may not invalidate any block you'd like to with only 20%. 10% stake means half the blocks, etc. You also don't want to invalidate blocks based one one or two MIA signatories, as with 3 signatories the chain still works fine.
You also add a very easy attack vector by unanimous voting requirement, as you only need to DDoS one node per block to control the chain.
No. If you have 20% of tickets, then you will have one or more votes on 1-0.8^5 = 67% of blocks. You can make 2/3 of blocks empty, but the other 1/3 will go through. That is money burning fail, not a credible DDOS. Perhaps you meant something else? Invalidation of draws that lack unanimity increases PoW attack resistance. By a lot. I will show you the math if it helps. As a comprimise, how about 4 yay's or more, instead of 3 or more? That would still help. Alternatively, You can also strengthen the system by increasing the number of voters. Say 6 out of 10 instead of 3 out of 5. Again, I will show you the math if this helps. This would not be my first choice, but I think it would be fine. Anyways, these are still parameter choices. Easily forked. It is still the core algorithm that matters. I'm super sleepy and will risk sounding stupid, but I'm considering that you require unanimous voting to be 5/5 signatories signing, and that 4/5 Yea signatories and 1/5 Nay signatories means a rejection of the previous block. If you own 20% of the stake tickets, the probability for you getting a stake ticket drawn by the lottery is 1 in 5 (0.20). All stake ticket lottery selections are independent events, thus the probability of repealing the previous block is 1.00 (100%) given that a minimum of 1 in 5 signatories signing Nay is required to invalidate the previous block and that the attacker has an average of 1 in 5 tickets per block. But I welcome elaboration of your formula above, as it's very possible I'm wrong. Increasing the number of signatories per block increases block bloating of the entire chain by multiplication by a constant, so ideally it should be left as low as possible. I'm not averse to 7 per block, though edit: Sorry, I'm confusing expected value with probability Say 1 is for the malicious attacker M probability of rolling a 5 sided die five times and never getting 1 (M never included into block) is (4/5)^5 = 0.32768 therefore the probability of rolling a 5 sided die five times and getting at least one 1 (M is included in the block at least once) = 1 - 0.32768 = 0.67232 |
|
|
|
It is just a matter of time... there will allways be someone smarter
- just my humble opinion
As litecoin has already changed the algo once, they can change it again. It is doubtful that much can be done beyond GPU's with scrypt due to the memory requirements. You could create an ASIC but with the RAM requirements it would be large and one quick change to the formula would increase the ram requirements in an instant killing the usefulness of the ASIC. No, you just increase the number of scratchpad recalculations using the same amount of memory. You can calculate a scrypt hash of any memory size on less memory, it just takes longer (memory usage is not fixed; it's just the amount of memory that yields the least number of ALU cycles possible). |
|
|
|
|
Show Posts
