|
I don't think it's the only alt coin, obviously LTC is still a major force and likely here to stick.
PPC is interesting, I've been very antagonistic in the past but about half of the arguments I had against it have turned out to be baseless.
I think there are still problems with scaling that are unaddressed, and I still don't know if his theories are economically sound or reasonable.
I'm going to publish another PoS whitepaper this weekend here, feel free to to tear it apart because that's what makes a strong chain.
|
|
|
|
What do you mean guaranteed voltage control? I have three of these right now, and even though you can move the slider up and down in Afterburner, GPUZ doesn't read any change in voltage. Actually, now that I've looked, neither does the graph in Afterburner.
Contact MSI in their forum, they should all allow voltage control through afterburner. |
|
|
|
Have not tried it yet for 7950s. I use GUIMiner-Scrypt on my 7770 (no overclocking or such).
Is there any kind of benchmark for GUIMiner-Scrypt for 7950s that I could see? I'd LOVE to use GUIMiner as opposed to CGMiner, but was unsure if I'd lose some performance.
Well, it's just a frontend to cgminer. The performance is the same; it even gives you the command it send to cgminer if you check the console. |
|
|
|
This is my humble opinion but as far as I understand it, the Proof-of-Stake model offers better protection from 51% attack as the attacker would have to own 51% of all coins which would be virtually impossible to accomplish (even if, say, the Chinese Gov't wants to buy all ppc the price of the ppc would increase exponentially, making it impossible even for them to own the majority). - It's easier to control majority of processing power than majority of coins. - This is just my partial understanding of the PPC whitepaper, I'm still struggling with it.
This would be a special case situation in which no one is using PPC for currency and in which we disregard any effect of PoW I would think, as PPC only generate stake blocks after sitting and doing nothing for 30 days. In the case where 50% of the coins in the network are being actively transferred between persons, you only need 25% or more of the network to perform such an attack using stake blocks if we were to disregard PoW entirely. The more coins that are being actively traded, the less stake required to perform an attack. But PoW is never disregarded by the chain, rather Sunny King just assumes that PoW blocks will be mined with exponentially increasing hash rate with the same overall power output. PoS actually makes it quite a lot easier to attack the network in the event that the PoW hash rate isn't very high and a lot of PPC is being actively traded, so long as the attack is well premeditated (as you need to wait to accumulate coinage). |
|
|
|
If the logic is litecoin is superior due to the 2.5 minute conformation times, would not a new coin with 1.25 minute confirmation times be even better than litecoin?
Not necessarily, the faster the confirmation time the more orphans you get and the more power inefficient your chain becomes. You also double the amount of bandwidth in the network. |
|
|
|
|
Finally got a set of 7970s. Hit 720 KH/s on first try with
--thread-concurrency 8192
-g 2
-I 13
-w 256
Core voltage 1.087 v
Memory voltage stock
Core 1051 MHz
Memory 1744 MHz
|
|
|
|
For me as well, guiminer consistently under reports khash. This is true of 4 different rigs with 7xxx cards. Not a big deal, b/c I can always just check long term hashing with the pool which is the most reliable measure, but it makes hardware tweaking a little more difficult if I can't accurately judge the changes at the machine level.
This is strange. I tested it today with a 7970 and I got the same results in cgminer from the console as with the guiminer. The program just pulls the rates in KH/s from stdout, so they should be the same. I noticed that for some reason after a while rates can decrease, though. I will have to look into it and figure out what's going on. |
|
|
|
That's a fallacy. The absence of bad news is not good news. You have to investigate other factors as well. Eg there is almost no incentive right now to do proper research. Thus it progresses slowly. Before full design documents have been published or reverse engineered, the security level is unknown.
I'll echo this. PPCoin has made sweeping changes to the Bitcoin protocol and it's hard to really tell what will work and won't work in the long run. One of the great things about Bitcoin was its simplicity in the protocol used to generate the network. However, with PPCoin, a number of complexities have been added and it's unknown how well they will pan out in the long term. |
|
|
|
Got the same error on a Win7 32 machine. Won't run.
I did another install on a Win8 machine and it works fine there. Nice work, Tacotime.
Now, how to get around that error on the Win7 machine?
Install 64-bit OS. I don't know why that error comes up on Win7 64-bit, though. Eventually I will build a 32-bit version on XP for more compatibility, I just haven't gotten around to it yet. On my fresh 64-bit installs of Win7 64-bit it works fine, though. |
|
|
|
No. Yours is a limited oscillation. This one would collapse it to 0.
Yeah, I realized it now, I haven't heard about that vulnerability for a while. |
|
|
|
|
Edit: nm, same as time travel with original solidcoin I think.
|
|
|
|
I think few good questions were brought up here; Still trying to wrap my head around this;
You have 10,000 people attempting to mine stake blocks. A has 30,000 coin years, and B has 10,000 coin years, and the rest of the network have less than 10,000 coin years.
B mints a stake block and the rest of the network mints stake blocks on top of B.
Can A fork the chain by declaring a chain in which he mints a stake block in place of B's block? I would guess you made that forbidden by timestamp, but if A decides he doesn't like a transaction in block B, what's to stop A from announcing a new block and in effect destroying that transaction before the next person adds a block? Is there anything in place to stop malicious stake mining like that, or is that the "51%" stake attack?
51% stake attack doesn't seem to require 51% of the coins either, since 51% would be based upon the assumption that everyone in the network is holding coins to mine stake blocks. However, if most coins are being used for actual transactions, the required amount of stake to fork the network is actually only a fraction of 51%.
A problem also may arise when you have 10,000 people all making hundreds of possibly valid chains at the same. If all these 10,000 people are announcing valid stake blocks at the same time, how do you avoid network congestion because the users are all required to figure out what the most valid chain is (chain with the most coinstakeage)? Won't you generate hundreds or thousands of orphan chains? I'm curious to see how the PPC network would work if we generated a massive number of clients with large coin age all competing for stake blocks at the same time. Additionally important is the theoretical mathematical problem of exactly how much stake investment (cumulative coin age) it will take to fork the network given a percentage of users actually using the coin within a 30 day period. I'm wondering if the eventual massive stake competition will actually lead to PPC being energy inefficient in terms of network bandwidth, which would defeat the purpose of the chain's claimed energy efficiency. |
|
|
|
|
If Sunny can answer them well, I'll buy more PPC.
This forum is public material, and if Sunny answers these questions people will be able to google them later and find the answer. I'm just trying to further my understanding of the coin, rather than placing my money in it before understanding it. And of course, Sunny need not answer anything if he doesn't want to; someone else who has gone through the code is welcome to.
For instance, I can ask any number of technical questions in the bitcoin dev board and have them answered within a few hours because the number of persons understanding the protocol is vast and the number of people involved in development great. However, the same can not be said for PPC as Sunny is largely the only dev.
If the problems above are real theoretical problems with the chain, however, they represent issues that the userbase should be aware of.
|
|
|
|
The cap is based on the assumption that the hash rate of the network will increase exponentially, and that this exponential increase in hash rate will drive reward down according to the algorithm for reward decrease (reward decreases exponentially with network difficulty). Is there a cap on total money supply like Bitcoin's 21 million?
There is no hard cap other than a 2 billion coin max put into the code for now. But that should not be interpreted as an approachable cap, as it might never get anywhere close to that. It should not be considered a hard cap either as it may get lifted but that's likely not needed in a very very long time. Due to the nature of the mint rate design it's not possible to predict a final limit as it depends heavily on market participation, as well as the influences between proof-of-stake minting and fee destruction (there may not even be a mathematical limit if minting continues to outpace fee destruction). What we do know is that the proof-of-work minting would slow down exponentially according to Moore's Law (we are aware that Moore's Law eventually would stop to apply), and proof-of-stake minting introduces at most 1% annual inflation. So generally speaking it is still a very low future-inflation design comparable to Bitcoin.
In 0.2 release a 'moneysupply' stat is included in the getinfo output so everyone can see how many coins are in the market. In my opinion this assumes at least a semi-stable monetary value for PPC, which in less than guaranteed. |
|
|
|
Yes, that is known as Moore's Law and is explained in the design paper.
Right, but you didn't address what happens to PPC if the hash rate suddenly plummets, for instance, if there is some economic destabilization unrelated to PPC's code which causes people to stop mining. Because of the exponential increase in PPC's reward as hardcoded, if the rapid generation of PPC is large enough won't the PoS system eventually be compromised by the PoW system? |
|
|
|
|
Still trying to wrap my head around this;
You have 10,000 people attempting to mine stake blocks. A has 30,000 coin years, and B has 10,000 coin years, and the rest of the network have less than 10,000 coin years.
B mints a stake block and the rest of the network mints stake blocks on top of B.
Can A fork the chain by declaring a chain in which he mints a stake block in place of B's block? I would guess you made that forbidden by timestamp, but if A decides he doesn't like a transaction in block B, what's to stop A from announcing a new block and in effect destroying that transaction before the next person adds a block? Is there anything in place to stop malicious stake mining like that, or is that the "51%" stake attack?
51% stake attack doesn't seem to require 51% of the coins either, since 51% would be based upon the assumption that everyone in the network is holding coins to mine stake blocks. However, if most coins are being used for actual transactions, the required amount of stake to fork the network is actually only a fraction of 51%.
A problem also may arise when you have 10,000 people all making hundreds of possibly valid chains at the same. If all these 10,000 people are announcing valid stake blocks at the same time, how do you avoid network congestion because the users are all required to figure out what the most valid chain is (chain with the most coinstakeage)? Won't you generate hundreds or thousands of orphan chains?
|
|
|
|
As the network hash rate increases with the advancement of Moore's Law, the proof-of-work mint rate is reduced, so it would be more and more difficult for such attackers to gain significant wealth via proof-of-work and then launch attack on proof-of-stake after 30 days.
Question regarding this from an economic and technological standpoint: Are you assuming that the proof of work rate will increase exponentially given time? Unlike Bitcoin there is no hard cap on the amount of coins that will be created. Bitcoin is limited to 21 million coins where PPCoin only has a hard cap of 2 billion coin in the code. There is no intention to limit the amount of coins that can be generated. It seems there is no long term method to limit the generation of coins in PPC. If the hash rate of the network were to suddenly fall, coin generation increases exponentially to a maximum, correct? Additionally, if there is a dependence on the network for PoW to generate less and less coins over time (if proof of work rate somehow crashes, a great number of coins are produced and will potentially destabilize the PoS system after 30-90 days), what makes the chain more energy efficient than a PoW-only chain? Is the intention to keep the network at the same amount of energy over time by assuming technology will increase hash rates but, from PPC's difficulty algorithm, doing so will decrease reward? |
|
|
|
I assume you are referring to The hash target that stake kernel must meet is a target per unit coin age (coin-day)
consumed in the kernel (in contrast to Bitcoin’s proof-of-work target which is a fixed
target value applying to every node). Thus the more coin age consumed in the kernel, the
easier meeting the hash target protocol. For example, if Bob has a wallet-output which
accumulated 100 coin-years and expects it to generate a kernel in 2 days, then Alice can
roughly expect her 200 coin-year wallet-output to generate a kernel in 1 day.
In our design both proof-of-work hash target and proof-of-stake hash target are adjusted
continuously rather than Bitcoin’s two-week adjustment interval, to avoid sudden jump in
network generation rate. ? So, after a certain point, only people with older coins or with vast quantities of coins (producing greater coin age more quickly) will be able to mint stake blocks? |
|
|
|
|
Show Posts
