Greg Maxwell, who is levels above and beyond any altcoin developer in terms of ideas. He's too busy doing core implementations to mess around with coding forks extensively, though.
|
|
|
|
|
i am working with othe too on a new difficulty algorithm borrowed from mc2, i guess if that tests okay maybe it'll be pushed to master in a hardfork
|
|
|
|
without and computerese jargon.... or a pyramid of numbers to verify that you are so clever...could someone just past a simple bat file for an asus r9 290 using either cgminer3.7.2 or vertminer 5.2? Is that too much to ask? Are you' all trying to make this hard?? JUST POST A BAT FILE ALL US NON COMPILERS AND REGULAR PEOPLE CAN COPY AND PASTE....PLEASE.
Download latest guiminer-scrypt, there's a gui now enter your info, select gpu, hit "start" https://bitcointalk.org/index.php?topic=150331.0 |
|
|
|
Sent 50 VTC
Thank for supporting Vertcoin
Thanks! |
|
|
|
I am having this issue ONLY on p2pool(s). Regular pools these show 99.9% accepted. Oh. High stale rates are normal for p2pool, especially if your node is slow or your peers have high latency. |
|
|
|
update for quick vertminer support there may be a few updates in the future as now i need money  |
|
|
|
I don't feel like belabouring the first point more, you'll see a bad thing happen when it happens. It has nothing to do with SHA256d preimage resistance. Which aspect of orphans worries you?
However, proof of stake, as implemented in nearly every currency so far, has one fundamental flaw: as one prominent Bitcoin developer put it, “there’s nothing at stake”. The meaning of the statement becomes clear when we attempt to analyze what exactly is going on in the event of an attempted 51% attack, the situation that any kind of proof-of-work like mechanism is intended to prevent. In a 51% attack, an attacker A sends a transaction from A to B, waits for the transaction to be confirmed in block K1 (with parent K), collects a product from B, and then immediately creates another block K2 on top of K – with a transaction sending the same bitcoins but this time from A to A. At that point, there are two blockchains, one from block K1 and another from block K2. If B can add blocks on top of K2 faster than the entire legitimate network can create blocks on top of K1, the K2 blockchain will win – and it will be as if the payment from A to B had never happened. The point of proof of work is to make it take a certain amount of computational power to create a block, so that in order for K2 to outrace K1 B would have to have more computational power than the entire legitimate network combined.
In the case of proof of stake, it doesn’t take computational power to create a work – instead, it takes money. In PPCoin, every “coin” has a chance per second of becoming the lucky coin that has the right to create a new valid block, so the more coins you have the faster you can create new blocks in the long run. Thus, a successful 51% attack, in theory, requires not having more computing power than the legitimate network, but more money than the legitimate network. But here we see the difference between proof of work and proof of stake: in proof of work, a miner can only mine on one fork at a time, so the legitimate network will support the legitimate blockchain and not an attacker’s blockchain. In proof of stake, however, as soon as a fork happens miners will have money in both forks at the same time, and so miners will be able to mine on both forks. In fact, if there is even the slightest chance that the attack will succeed, miners have the incentive to mine on both. If a miner has a large number of coins, the miner will want to oppose attacks to preserve the value of their own coins; in an ecosystem with small miners, however, network security potentially falls apart in a classic public goods problem as no single miner has substantial impact on the result and so every miner will act purely “selfishly”. http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/ |
|
|
|
What could happen when you don't include PoW blocks and you're only using entropy bits from PoS blocks (GetStakeEntropyBit() from main.cpp)? Especially if you're producing most of the previous PoS blocks?
If attakers are producing most of blocks they can double spend and so on. If not then chanches to influence to the modifier are too low. Unless the attackers start with a small percentage of stake and then progressively begin to burn more of it. By the way, comment in code says it should favor PoS blocks  kernel.cpp: // the selection hash is divided by 2**32 so that proof-of-stake block
// is always favored over proof-of-work block. this is to preserve
// the energy efficiency property Yes, but no where does it say to completely remove PoW. Okay; how do you select which chain is the correct one?
The longest in terms of cumulative difficulty. You see no issue with this at all? What would happen to Bitcoin if the cost of generating PoW blocks was negligible and an orphan was generated? |
|
|
|
If I understand this correctly, there was additiotal search space caused by insufficient timestamp check and difficulty retarget every block. Both have nothing to do with PoW. bool ComputeNextStakeModifier(const CBlockIndex* pindexPrev, uint64& nStakeModifier, bool& fGeneratedStakeModifier)
{
nStakeModifier = 0;
fGeneratedStakeModifier = false;
if (!pindexPrev)
{
fGeneratedStakeModifier = true;
return true; // genesis block's modifier is 0
}
// First find current stake modifier and its generation block time
// if it's not old enough, return the same stake modifier
int64 nModifierTime = 0;
if (!GetLastStakeModifier(pindexPrev, nStakeModifier, nModifierTime))
return error("ComputeNextStakeModifier: unable to get last modifier");
if (fDebug)
{
printf("ComputeNextStakeModifier: prev modifier=0x%016"PRI64x" time=%s\n", nStakeModifier, DateTimeStrFormat(nModifierTime).c_str());
}
if (nModifierTime / nModifierInterval >= pindexPrev->GetBlockTime() / nModifierInterval)
return true;
// Sort candidate blocks by timestamp
vector<pair<int64, uint256> > vSortedByTimestamp;
vSortedByTimestamp.reserve(64 * nModifierInterval / nTargetSpacing);
int64 nSelectionInterval = GetStakeModifierSelectionInterval();
int64 nSelectionIntervalStart = (pindexPrev->GetBlockTime() / nModifierInterval) * nModifierInterval - nSelectionInterval;
const CBlockIndex* pindex = pindexPrev;
while (pindex && pindex->GetBlockTime() >= nSelectionIntervalStart)
{
vSortedByTimestamp.push_back(make_pair(pindex->GetBlockTime(), pindex->GetBlockHash()));
pindex = pindex->pprev;
}
int nHeightFirstCandidate = pindex ? (pindex->nHeight + 1) : 0;
reverse(vSortedByTimestamp.begin(), vSortedByTimestamp.end());
sort(vSortedByTimestamp.begin(), vSortedByTimestamp.end());
// Select 64 blocks from candidate blocks to generate stake modifier
uint64 nStakeModifierNew = 0;
int64 nSelectionIntervalStop = nSelectionIntervalStart;
map<uint256, const CBlockIndex*> mapSelectedBlocks;
for (int nRound=0; nRound<min(64, (int)vSortedByTimestamp.size()); nRound++)
{
// add an interval section to the current selection round
nSelectionIntervalStop += GetStakeModifierSelectionIntervalSection(nRound);
// select a block from the candidates of current round
if (!SelectBlockFromCandidates(vSortedByTimestamp, mapSelectedBlocks, nSelectionIntervalStop, nStakeModifier, &pindex))
return error("ComputeNextStakeModifier: unable to select block at round %d", nRound);
// write the entropy bit of the selected block
nStakeModifierNew |= (((uint64)pindex->GetStakeEntropyBit()) << nRound);
// add the selected block from candidates to selected list
mapSelectedBlocks.insert(make_pair(pindex->GetBlockHash(), pindex));
if (fDebug && GetBoolArg("-printstakemodifier"))
printf("ComputeNextStakeModifier: selected round %d stop=%s height=%d bit=%d\n", nRound, DateTimeStrFormat(nSelectionIntervalStop).c_str(), pindex->nHeight, pindex->GetStakeEntropyBit());
}
// Print selection map for visualization of the selected blocks
if (fDebug && GetBoolArg("-printstakemodifier"))
{
string strSelectionMap = "";
// '-' indicates proof-of-work blocks not selected
strSelectionMap.insert(0, pindexPrev->nHeight - nHeightFirstCandidate + 1, '-');
pindex = pindexPrev;
while (pindex && pindex->nHeight >= nHeightFirstCandidate)
{
// '=' indicates proof-of-stake blocks not selected
if (pindex->IsProofOfStake())
strSelectionMap.replace(pindex->nHeight - nHeightFirstCandidate, 1, "=");
pindex = pindex->pprev;
}
BOOST_FOREACH(const PAIRTYPE(uint256, const CBlockIndex*)& item, mapSelectedBlocks)
{
// 'S' indicates selected proof-of-stake blocks
// 'W' indicates selected proof-of-work blocks
strSelectionMap.replace(item.second->nHeight - nHeightFirstCandidate, 1, item.second->IsProofOfStake()? "S" : "W");
}
printf("ComputeNextStakeModifier: selection height [%d, %d] map %s\n", nHeightFirstCandidate, pindexPrev->nHeight, strSelectionMap.c_str());
}
if (fDebug)
{
printf("ComputeNextStakeModifier: new modifier=0x%016"PRI64x" time=%s\n", nStakeModifierNew, DateTimeStrFormat(pindexPrev->GetBlockTime()).c_str());
}
nStakeModifier = nStakeModifierNew;
fGeneratedStakeModifier = true;
return true;
} Notice how ComputeNextStakeModifier typically includes PoW blocks; you can visualise this if you turn on the debug flags. What could happen when you don't include PoW blocks and you're only using entropy bits from PoS blocks (GetStakeEntropyBit() from main.cpp)? Especially if you're producing most of the previous PoS blocks? Of course, we can be generally assured that entropy bits from PoW miners are completely random because for them not to be would involve them throwing away a lot of work... I don't think there's any easy fix not including PoW, and if you make the chain completely PoS you run into the forking issue (that miners can mine both forks of a chain easily and without consequence, so when forks are started they continue to propagate forever). Nodes do not propagate double stakes. Okay; how do you select which chain is the correct one? |
|
|
|
Ok, that makes sense from what I've read from the post. Haven't has a look at the code yet though so I haven't messed around with it myself. Truly a difficult problem to find a permanent fix for while remaining PoS only. What of the reported work-around by Sunny King, the PPC developer? Has he made it available? And moreso, does it work as intended?
Sunny King's workaround was to compute the modifier using PoW blocks for entropy so you'd couldn't game them by rapidly computing PoS blocks (as far as I could tell) And to prevent the forking issue (although not a huge problem with the current state of PoW), he centralized the blockchain by constantly signing new checkpoints into the network. This allows him to select which chain he thinks is the valid one, and then miners mine off of that. |
|
|
|
Have you read this post? And have there been any counter measures taken work around the problem?
I don't think there's any easy fix not including PoW, and if you make the chain completely PoS you run into the forking issue (that miners can mine both forks of a chain easily and without consequence, so when forks are started they continue to propagate forever). You can just turn PoW back on and make the block reward 0 at block 10,000. |
|
|
|
ComputeNextStakeModifier uses hashes of 64 blocks (both PoW and PoS) as source of entropy.
Compare 64 blocks to forge StakeModifier with 10 blocks to confirm transaction.
Read this thread more closely: https://bitcointalk.org/index.php?topic=131901.0And diff PPCoin 0.2 and 0.3 You'll see why it's a bad idea to turn off PoW |
|
|
|
Uh, I'm not sure what the developers did, but you should probably be aware that without PoW blocks a PeerCoin/NovaCoin fork is vulnerable to the stake burnin vulnerability. Interesting, I was under the impression that the POS vulnerability was fixed in the next update. It was -- by using modifiers derived from the entropy of the PoW blocks.  See in kernel.cpp: bool ComputeNextStakeModifier(const CBlockIndex* pindexPrev, uint64& nStakeModifier, bool& fGeneratedStakeModifier){
...
} |
|
|
|
10 BlackCoin $ 16,852,543 $ 0.23 74,477,878 BC* $ 58,196 +445.30 % http://coinmarketcap.com/ Wonderful bug makes BC more exposures !!! sigh |
|
|
|
Uh, I'm not sure what the developers did, but you should probably be aware that without PoW blocks a PeerCoin/NovaCoin fork is vulnerable to the stake burnin vulnerability. |
|
|
|
No, the problems are all the ways that PoS is insecure.
Read up on it.
Having hybrid, so blocks can also be mined by proof of work, is one of the most commonly used fixes, but this coin is being touted as having done away with that.
So what mechanism is it using instead to fix the problems?
-MarkM-
MarkM is totally correct. I've spent about a year trying to design a good PoS/PoW hybrid system, and gmaxwell still thinks my system is going to eventually explode itself into oblivion. Gmaxwell himself tried to design 4 different PoS systems and abandoned the work because he felt like it could never be secure. The original source code of nxt could be allow anyone to burn through blocks by tweaking the nonces, and all that required changing was two lines; it's dubious whether or not pure PoS could ever work, or even if it's a good idea. Further, if they forked Peercoin, they should probably be aware that the security for the PoS block mining algo depends on the timing of PoW blocks on the network... so expect that to break if you just forked the coin and decided to turn off PoW at block 10,000. |
|
|
|
|
Show Posts
