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 |
|
|
|
GPU?
Nah, this is only with a CPU (2700K) yacoind on Linux x64? yes |
|
|
|
|
I get 400 KH/s on a 2700K using
-O3 -march=core-avx-i
with the QT client.
|
|
|
|
GPU?
Nah, this is only with a CPU (2700K) |
|
|
|
Wheeeee -O3 -march=core-avx-i 11:31:08

gethashespersec
11:31:08

422148
|
|
|
|
A 51% PoW attacker can patiently mine in secret. His PoS difficulty will slowly adjust downwards. Eventually, his PoS difficulty will go low enough that he is able to overtake the main chain with negligible stake. PoS becomes a sham and only PoW matters. Okay. Such an attack when you manipulate stake difficulty seems pretty unlikely. The following reasons are why: 1) The stake difficulty adjusts every 4.5 days and is based on the linear weighted average of the previous four 4.5 day periods (no per-block adjustments ever occur). 2) You need to wait 29 days after submitting the ticket for it to mature before you even have the chance to spend it. This means that an attack like this will involve mining a hidden chain for at least one month, probably closer to two depending on your hash power. 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) where n is the current block in the chain. Now it should be difficult for the attacker to manipulate the chain, because his chain should have a lower score if he tried to lower either the PoW or PoS difficulty. Again, this attack is not an easy one and requires you to mine for a long time. Let's say an attacker has 51% PoW and 10% PoS. The attacker can generate more PoW blocks in his chain, but he can never validate the majority of them and his cumulative difficulty score will certainly be lower than the main chain, making a double spend impossible. Let's say an attacker has 10% PoW and 51% PoS. The attacker can validate or invalidate any block they choose, but the attacker's likelihood of a successful double spending is very low (the same as with bitcoin with 10% of the network hash rate). 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, and now I'm really worried and losing sleep over it. X) I will try to come up with a simulation program for this so we can play with it and see what the longest valid fork you can make is. |
|
|
|
It's really unfortunate that there were/are so many problems with orphans.  I started off trying the Windows client but I was getting only orphans and very few at that. So then I started up Linux in VirtualBox and compiled the Yacoin-qt client and ran it with the following command: ./yacoin-qt -gen -genproclimit=6 -addnode=82.211.30.212 I got a surprising number of blocks and had only a ~10% orphan rate. I don't know why the Linux version seemed to work so much better (and in a VM, too!). As for location, I'm in the US. My ping to the 82.211.30.212 node is 120ms. 64-bit compiler. On 2700K I get 400 KH/s |
|
|
|
|
I see. Let me sleep on it and I'll think further about it.
|
|
|
|
For shits and giggles, finally compiled this on unix too. Was able to get 400 KH/s on Ubuntu with a single 2700K. All you need to do is compile the QT program with the chacha AVX extensions bundled with scrypt-jane and use GCC 4.7 x64, and boom, really high hash rates.
any way to help us for windows? Install ubuntu and compile with g++/QT-creator is my best advice. This is probably why people on Linux are reporting so many more blocks than everyone else. |
|
|
|
|
For shits and giggles, finally compiled this on unix too. Was able to get 400 KH/s on Ubuntu with a single 2700K. All you need to do is compile the QT program with the chacha AVX extensions bundled with scrypt-jane and use GCC 4.7 x64, and boom, really high hash rates.
|
|
|
|
Coins are already bought with straight coins instead of coin time.
Right, sorry I got confused. In the best case (that the majority of both proof of stake and proof of work miners are honest), it's about twice as secure I would say. Hence, the time for a secure confirmation should be one half that of Bitcoin, in that ideal case. If a network attacker emerges to the scene, the case in Bitcoin is that there is no secure amount of confirmations. In the case of MC2, no blocks will go through the network (>50% PoW) or only blocks that the attacker selects will go through the network (>50% PoS). Only in the case of >50% PoW and >50% PoS can the attacker double spend.
I'm not understanding you here. You will always have 51% attacks. Attacks will involve a weighted combination of PoW and PoS that exceeds 51%. Regardless of the resource combination used, the attacker will be able to 1) select which blocks go through the network, 2) double spend, AND 3) prevent all txns. This is true in bitcoin. I'm near certain it will be true for your coin as well. You are perhaps confused because of an omission in your whitepaper. You need a single-valued function that compares proof across blockchains. In Bitcoin PoW, the single-valued function is the summation of difficulty targets for each block in the blockchain. If you copy this directly, you run into trouble. Block Proof = PoW Difficulty Chain Proof = Summation of Block Proof A 51% PoW attacker can patiently mine in secret. His PoS difficulty will slowly adjust downwards. Eventually, his PoS difficulty will go low enough that he is able to overtake the main chain with negligible stake. PoS becomes a sham and only PoW matters. I see. You need a way to prevent such a fork from happening. Why not just not disallow reorgs for any length of valid blocks greater than five? There should be an easy way to detect this attack and reject it from ever entering the network. I understand that you need to have reorgs to prevent the chain from forking, but it seems like a 12 minute string of blocks seen by no one else on the network is really unlikely. You are using two difficulties. PoW difficulty, PoS difficulty. You need to consider two proof relevant numbers for each block.
To do this, define a single-valued function that maps the (PoW difficulty, PoS difficulty) pair into overall block difficulty.
The two difficulties make analysis of 51% attacks complicated. Resource requirements most likely depend on attack duration. That's a bit messy, but I don't think it is a problem.
My suggested single-valued function is a geometric average.
Block Proof = (PoW Difficulty)^0.5 * (PoS Difficulty)^ 0.5
Chain Proof = Summation of Block Proof = (PoW Difficulty in Block 1)^0.5 * (PoS Difficulty in Block 1)^ 0.5 + (PoW Difficulty in Block 2)^0.5 * (PoS Difficulty in Block 2)^ 0.5 + ...
Ideally, there would be some clever function that keeps the long-run and short-run resource requirements identical. Not sure what that clever function would be. The above will work though.
Another option would be to fix the ticket price permanently and allow the number of lottery tickets issued to grow with inflation and shrink with txn demand.
Benefit: Attack analysis is simpler.
Cost: Not sure. Probably more blockchain space is used up by the lottery data.
Well, in order for stake difficulty to go down on the other chain you need to use submit less stake Tx per block. As the stake Tx go down, stake difficulty goes up (as it's a fraction of the supply needed to claim a stake submission Tx). We can rate the trust in the block as the stake submissions * (1/stake difficulty) and select the chain based on this stake trust value too, which will likely be larger after summation among all the blocks up to where the fork emerged. This may be untrue if few people in the network are submitting stake at the time and the malicious stakeholder has a lot. If you fix reorgs to a certain length and incorporate the above it may be very difficult to perform a double spend, as stake difficulty only decreases once every 4.5 days. Okay. This behaviour can probably be simulated too, although it's a little more complicated, and I'm tired. I'll think about it more later. |
|
|
|
Anyway, I know this is another get rich quick-scheme, however from previous releases (FTC, CNC and BTB) I've learned that no matter how much you expose the flaws and scams from these coins, peoplre are going to still buy it.
What I learned from those releases is that you buy early when it's being heavily mined and it's "cheap", few days after everyone forgets how much of a scam the release was and the price starts going up, after a few days or weeks its price is 2x or 4x what it was on release and 1 week after that it duplicates again when it reaches an exchance.
So yea I'm stocking up on YAC
Well, it's a self-fulfilling prophecy. Everyone knows that the pump is going to happen, so people will try to hop onto it, creating the pump itself. Eventually someone is going to lose a lot of money and people will start to just ignore the launches of all these random coins. If you look at BTC-e these new random coins like ChinaCoin etc are doing much more poorly than NVC or LTC at release. |
|
|
|
I think three points there that will catch the eye of the ordinary non-uber-technical user :
Improved security
Uses less disk space
Faster payment
Now, how much more secure is it, how can this be conveyed to the user in a daily life situation ?
For marketing I'd focus on those 3 things for the main big marketing push, ( plus any other innovations say on the wallet side, see my edit in OP ) and move the others to the 'small print' where people that are really interested and capable of understanding them will find them if/when they need to
In the best case (that the majority of both proof of stake and proof of work miners are honest), it's about twice as secure I would say. Hence, the time for a secure confirmation should be one half that of Bitcoin, in that ideal case. If a network attacker emerges to the scene, the case in Bitcoin is that there is no secure amount of confirmations. In the case of MC2, no blocks will go through the network (>50% PoW) or only blocks that the attacker selects will go through the network (>50% PoS). Only in the case of >50% PoW and >50% PoS can the attacker double spend. One of the PoS arguments is that with PoW, the government can easily attack it by getting enough hashing power. With MC2, by this attack vector you can only temporarily stop transactions from going through, and then, if this becomes a problem, you can force PoW miners to also have some PoS when minting a block. This is a pretty unlikely case, though. But, in any case, it should be more secure than Bitcoin from this type of attack. But what PoS people like to ignore is that the government can also destroy these chains just by buying a lot of it if they wanted to. Right now, if Bitcoin were PoS the cost to destroy it would only be about $1 billion USD (actually, way less if you write an algorithm to try to buy at the VWAP and bought progressively over a couple of years). That's not really all that much money to a major world government. MC2 makes the assumption that it's no more likely for persons with stake to be any more honest than PoW miners. |
|
|
|
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.
I don't disagree with your calculations. In fact, they accomplish just what I want. We don't want the same things (you prefer work; I prefer stake; you think energy use is okay; I think it is a big waste). Edit: However, I thought about it a bit more and decided it is not worth making a fuss over. Here are approximate percentages on attack resistance (this is for permanent 51% attacks, not lucky streaks from minority attackers; majority voting performs better against lucky streaks). 4 out of 7 majority voting: (99.95% work 5% stake; 99.5% work 10% stake ; 94.4% work 20% stake) 3 out of 5 majority voting: (99.90% work 5% stake; 99.1% work 10% stake ; 94.1% work 20% stake) 3 out of 3 unanimous voting: (99.985% work 5 % stake; 99.86% work 10% stake; 98.46% work 20% stake) 5 out of 5 unanimous voting: (99.99996% work 5% stake; 99.998% work 10% stake; 99.9% work 20% stake) 3 out of 5 majority voting is adequate when paired with a nonnegligible PoW block reward. I was fanatic for PoW protection because I wanted minimal energy use. I forgot about your big PoW rewards. There is another issue I forgot, the waiting issue. To me it is no big deal, but I expect a huge fuss from others. You should remove this weakness to avoid future problems. You can always hoard coin-age by waiting (see numerous rants by killerstorm). To attack, you need 5% of stake-days, not 5% of stake. (e.g. so if you have x% of stake and bide your time for y voting cycles, then you can attack just like someone with xy% stake) How about you buy most tickets with straight coins rather than coin-time? Coins are escrowed up until the tickets win or get invalidated. This approach sidesteps the waiting issue. Sadly, it also excludes small holders from direct participation, though they could still use lottery pools, banks, etc. You have what ~ 60000 tickets. That is 160 coins a ticket if there are 10 million coins. A bit steep. To let small holders participate directly, perhaps allocate 10% of tickets based on coin-age and 90% based on straight coins. That would allow for some token grassroots participation. Honestly there will be a bulky blockchain to store. Smallholders would end up PoS mining via a banking system anyway. No point in designing a system that allows for infeasible use cases. Question: When you purchase a ticket, could you then send the ticket key to a pool to manage for you (in exchange for a cut)? Or does transferring your ticket impose some risk? In my opinion, it would be good to attach some risk to letting other people mine for you (e.g. allow the ticket holder to steal the winnings). It would be bad to attack a huge risk to letting other people mine for you, (the principal used to purchase the ticket should be safe from theft). This strikes a balance between discouraging centralization and encouraging participation in PoS mining. Coins are already bought with straight coins instead of coin time... You submit the coins to the chain and then they wait for the 29 days until maturity and are issued a ticket, but being able to purchase them has nothing to do with the age of the coins used to purchase them. The 29 day lag phase is to help prevent manipulation of the tickets, which is another attack vector on the chain (if you can manipulate the block headers over this time period and before the time of the stake submission Tx, you can effectively select who the lottery winners are and which tickets are issued). I like that there are absolutely no coins generated for 29 days, too. But if you wanted to eliminate the lag phase, you could also use all previous odd blocks for ticket generation and even blocks for lottery generation, or whatever. I'm not sure it's hugely advantageous to an attacker, as the window to claim the coins is so large (91 days). To the question, you can transfer the tickets by just sending the private key used to purchase the stake Tx somewhere. The risk would be that it becomes stolen along the way or by the pool itself, and the pool would risk having you steal the reward, so I'm not sure a pool would form by this means (seems pretty unlikely). Rather, a stake pool would involve you sending a little of your coins their way, them using them to buy the stake ticket, then spending it to secure the blockchain and sending back the coins back to the user with interest at a certain time. Large enough stake pools should be able to give daily interest, similar to PoW pools. The risks will be for the pool operators to assess, as it's likely that people will try to hack them constantly, but if you transfer the tickets to effectively shielded and quiet network nodes, they should be difficult to find. |
|
|
|
Let me play devils advocate for the moment.
Can someone give me a short list of reasons ( bullet list ), why Joe-public will use this coin rather than the already established Bitcoin ?
The list needs to be free from techno jargon, so anyone can understand it.
If such a list can be produced, and it is convincing, then this coin stands a chance of success and perhaps grab a decent share of bitcoins 'market'
This is important, as such a list needs to be used aggressively in a strong marketing exercise if uptake of the coin by users and merchants is to occur. Otherwise this coin will just be another btce / Bter exchange toy, which will make some miners some BTC for a while.
Okay - Uses a new approach to secure hashing algorithms for the hash tree of a given block that should increase FPGA/ASIC resistance
- After 27 coin years it employs a system of voting to manipulate the interest rate of the block chain (users act as the central bank and regulate the rate of inflation)
- Difficulty is based on the linear weighted average of the block times for the past 18 days for PoW blocks
- New block reward adjustment algorithm is given that yields an 8% decrease in block reward per year
- Simple PoS design (tried to strip it of as many complexities as possible)
- PoW and PoS systems are designed to happily coexist, with favour slightly given to the PoW system
- PoS system also intended to prevent 51% attacks
- Coloured coins, e.g. for rewarding projects that you create arbitrarily
- Ledger system for regular coins that allows for a lightweight version of the blockchain instead of having to download the entire blockchain If that's too technical: - Chain will be GPU mineable for a little while longer than Litecoin
- Difficulty is similar to Bitcoin but harder to game
- Blockchain is more secure due to the presence of a proof of stake system
- Secure confirms expected to be obtained in 6 minutes
- Double spends are very unlikely, even more so than with bitcoin because they require 51% proof of work power and 51% stake
- Support for people who want to make their own random coins within the blockchain, e.g. if you wanted to reward people based on their contribution to cancer research
- Lightweight client that is intended to max out in the hundreds of MB at most of on-disk storage |
|
|
|
Someone is messing with 50% attacks maybe? In log file I see attempts to inject huge number of consequtive blocks in blockchain, that so far didn't worked.
They might be trying to mangle the network time to further manipulate difficulty, as that's what happened when TRC implemented the per-block difficulty adjust procedure. |
|
|
|
I forgot to respond to something.
Do not just ignore people who abstain. Abstaining should be equivalent to voting Nay.
You will never see a Nay vote in attack blocks. Double spenders mine in secret.
That means their blocks have missing votes, not Nay votes. To offer significant PoS protection you must treat Nay and abstain as equivalent for block validity purposes.
That's true. I had considered this before (and had noted in the paper to be aware that this indicates a possible attack on the network), but it's probably best to just invalidate any block without a majority Yea vote. I'll get back to your other post soon. |
|
|
|
If you want this coin I'll just fork solidcoin2 and use their hash algorithm, as it runs similar on nVidia as compared to AMD GPUs. But it's had no cryptanalysis so it's possible the implementation is just poor and someone will figure out a faster AMD implementation eventually.
I would be interested in this. Why not make a separate topic and see public opinion? Must be other people like me around with nvidia cards that can only mine cpu coins like Yac. Sure thing. I'd have to check and see if I have an SC2 source kicking around somewhere. It might be fun to make a crypto that used the MC2 reward/difficulty algorithm too. My wife is going away for the weekend, I'll consider it. I'll probably premine it a little before release, but I don't think it'll be a serious coin. |
|
|
|
Now all we need is a useful coin for nvidia cards too and the cryptos be set for life growth.
If you want this coin I'll just fork solidcoin2 and use their hash algorithm, as it runs similar on nVidia as compared to AMD GPUs. But it's had no cryptanalysis so it's possible the implementation is just poor and someone will figure out a faster AMD implementation eventually. |
|
|
|
|
Show Posts
