for (blockoffset = 0; blockoffset < 18; blockoffset++)
{
oldblocktime = blocktime;
if (pindexLast)
{
pindexLast = pindexLast->pprev;
blocktime = pindexLast->GetBlockTime();
}
else
{ // genesis block or previous
blocktime -= nTargetSpacing;
}
// for each block, add interval.
if (blockoffset <= 5) *avgOf5 += (oldblocktime - blocktime);
if (blockoffset <= 7) *avgOf7 += (oldblocktime - blocktime);
if (blockoffset <= 9) *avgOf9 += (oldblocktime - blocktime);
*avgOf17 += (oldblocktime - blocktime);
}
You are actually counting 6,8,10 and 18 averages (imagine <=1; you would count with 0 and 1, guess it's a typo), but otherwise very interesting algo. It looks at the last 18 timestamps to get the last 17 intervals. At the last 10 timestamps to get the last 9 intervals. Etc. 6,8,10,18 would actually not be as good, because 6 evenly divides 18, making it possible to find a repeating cycle that might trigger in both intervals. |
|
|
|
|
Hey, you're welcome. But it isn't really a miraculous direct and immediate response to you; you just happened to arrive in the thread a few moments before I would have posted it anyway.
If you read back in the thread you'll see that this is essentially what I said at the top of the last page, except I restated it in C++ because people were ignoring it when I said in English.
Also, if you keep reading back, you'll see BCX's observation a few posts earlier than that, when he observed that we needed to implement something with a fundamentally different idea rather than trying to fix the fatal flaw in KGW. He was absolutely right, so I did.
Honestly, KGW (and DGW) are slightly broken. Aside from the Time Warp exploit, they work okay, and they have the virtue of reacting to rapid hash rate changes rapidly, but they can't tell the difference between a genuine increase in hash rate and the natural randomness of a Poisson process. Mining is a Poisson process; when hash rate is constant, every second has an equal chance of somebody finding a block. Just plain randomness gives you a huge variation in individual block intervals.
And KGW & DGW react in a nonlinear way to that inescapable randomness. One or two too-short or too-long block times is enough to make them "panic" and make a nonlinear adjustment that leaves everybody looking at WTF difficulty factors. So, we already knew we needed a replacement, and I'd already done the design work.
This will react slower than KGW/DGW. That's unavoidable, I think. So yes, multipools can cheat it a little bit by "burst mining" to some extent. They get five rapid blocks or so before emergency difficulty adjustments kick in and maybe several more before difficulty reaches correct levels, depending on how much hash power they're jumping on with.
In fact, thinking about how a systematic burst miner with large hash power could affect its ability to track the wall clock, I probably need nSlowInterval to be larger, and adjust the IntervalDesired based on how much of a week out of date it is instead of how much of a day out of date.
On the plus side, at least it doesn't allow them to maximize the cheat by moving in right after a difficulty adjustment boundary when the next adjustment is still far away and then grab cheap blocks right up to that boundary, nor leave the other miners sucking air until another faraway difficulty adjustment boundary arrives after they leave. And time warps can't trigger adjustments opposite the long-term trend by "loading" a short five-block interval with a fiddled timestamp, because when moving against the direction of the longer-term trend they can't simultaneously load the intervals of different lengths.
Hmm. It needs a name.
Multi Interval Difficulty Adjustment System (MIDAS)?
"Using MIDAS for difficulty adjustment..."
Sure, that works.
|
|
|
|
|
I have considered a restructuring of the blockchain. I've even written some code, but I've not fully vetted it yet nor used it in earnest.
It adds to the blockchain header a hash of the UTXO set. You could use a merkle root instead, but I don't think it buys you anything in this case.
This would make the blockchain header take an extra 16 bytes - which due to the way ASICs work and our desire not to invalidate the ASIC investment out there, would force us to add a 64-byte block to each header, increasing the total size of the blockchain headers by a ratio of 3:2.
At the same time, add to each transaction a hash of a recent block within whose chain that transaction is valid. This in turn makes the transactions larger by about 16 bytes each.
What we get in exchange for that is that when you get a transaction, you can look for a block with the matching hash and be absolutely guaranteed that you are not "on the wrong chain" with respect to that transaction. You look in that block for the UTXO hash. This links you to a UTXO set which should match the updated set as it was after processing that block, which you can use that to verify that the inputs used by the transaction exist. Then you look at blocks since the key block to make sure those inputs have not been used by some other transaction.
The result is that unless you're interested in the history and verifying for yourself that the 'deep chain' run from block zero does in fact produce the UTXO tree whose Merkle root you have, you don't have to download all that much of the blockchain.
When you download the last "confirmation depth" blocks, you can start processing transactions that are valid within that chain -- and you know that you're not on a false chain, at least not as far as those transactions are concerned, because they list the block hash and you have a block with a matching hash. Likewise, you know that you have the right UTXO set for that block, because the block has the hash for the UTXO set. That allows you to download the UTXO set directly from an untrusted source, because you can verify for yourself that the hash matches.
I think that's nyfty, but there is a drawback; by tying each transaction firmly to a particular block so that it is not valid outside of a chain descended from that block, you create a situation in which a transaction can be invalidated by any sufficiently-deep chain reorg. Lots of people have deep heebie-jeebies about transactions other than double spends ever becoming invalid due to a chain reorg.
In practice I think there's only ever been one chain reorg that spanned more than a hundred blocks, and that was due to a bug; using a database software that couldn't cope with not getting as many file handles as it wanted. So I'd have no problem with anchoring each transaction to a block 100 blocks previous to where it was to appear in the blockchain.
|
|
|
|
Here. No timewarp. Rapid adjustments when a burst miner jumps on or off. And an experimental feature, adjusts the block interval to keep the blockchain height consistent (in the long run, and approximately...) with the wall clock. Adjusts difficulty potentially every block, based on average block intervals observed within the last 17 blocks. Have fun with it.
// Bitcoin used 10-minute blocks; this uses six minute blocks.
static const int64_t nTargetSpacing = 6 * 60; // seconds per block, nominal.
static const int64_t nFastInterval = nTargetSpacing * 0.95; // seconds per block desired when behind schedule
static const int64_t nSlowInterval = nTargetSpacing * 1.05; // seconds per block desired when ahead of schedule
static const int64_t nTimeZero = 1400000000; // nominal date at which this blockchain starts, since unix epoch
void avgRecentTimestamps(const CBlockIndex* pindexLast, int64_t *avgOf5, int64_t *avgOf7, int64_t *avgOf9, int64_t *avgOf17)
{
int blockoffset = 0;
int64_t oldblocktime;
int64_t blocktime;
*avgOf5 = *avgOf7 = *avgOf9 = *avgOf17 = 0;
if (pindexLast)
blocktime = pindexLast->GetBlockTime();
else blocktime = 0;
for (blockoffset = 0; blockoffset < 18; blockoffset++)
{
oldblocktime = blocktime;
if (pindexLast)
{
pindexLast = pindexLast->pprev;
blocktime = pindexLast->GetBlockTime();
}
else
{ // genesis block or previous
blocktime -= nTargetSpacing;
}
// for each block, add interval.
if (blockoffset <= 5) *avgOf5 += (oldblocktime - blocktime);
if (blockoffset <= 7) *avgOf7 += (oldblocktime - blocktime);
if (blockoffset <= 9) *avgOf9 += (oldblocktime - blocktime);
*avgOf17 += (oldblocktime - blocktime);
}
// now we have the sums of the block intervals. Division gets us the averages.
*avgOf5 /= 5;
*avgOf7 /= 7;
*avgOf9 /= 9;
*avgOf17 /= 17;
}
// This is a novel getnextwork algorithm. It responds quickly to huge changes in hashing power, is immune to time warp
// attacks, and regulates the block rate to keep the block height close to the block height expected given the nominal
// block interval and the elapsed time. How close the correspondence between block height and wall clock time is
// depends on how stable the hashing power has been.
unsigned int GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock)
{
int64_t avgOf5;
int64_t avgOf9;
int64_t avgOf7;
int64_t avgOf17;
int64_t toofast;
int64_t tooslow;
int64_t difficultyfactor = 10000;
int64_t now;
int64_t BlockHeightTime;
int64_t nIntervalDesired;
unsigned int nProofOfWorkLimit = Params().ProofOfWorkLimit().GetCompact();
if (pindexLast == NULL)
// Genesis Block
return nProofOfWorkLimit;
if (TestNet())
{
// Special difficulty rule for testnet: If the new block's timestamp is more than 2* 10 minutes then allow
// mining of a min-difficulty block.
if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
return nProofOfWorkLimit;
else
{
// Return the last non-special-min-difficulty-rules-block
const CBlockIndex* pindex = pindexLast;
while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
pindex = pindex->pprev;
return pindex->nBits;
}
}
// Regulate block times so as to remain synchronized in the long run with the actual time. The first step is to
// calculate what interval we want to use as our regulatory goal. It depends on how far ahead of (or behind)
// schedule we are. If we're more than a day ahead or behind, we use the maximum (nSlowInterval) or minimum
// (nFastInterval) values; otherwise we calculate a weighted average somewhere in between them. The closer we are
// to being exactly on schedule the closer our selected interval will be to our nominal interval (nTargetSpacing).
now = pindexLast->GetBlockTime();
BlockHeightTime = nTimeZero + pindexLast->nHeight * nTargetSpacing;
if (now < BlockHeightTime + 86400 && now > BlockHeightTime ) // ahead of schedule by less than a day.
nIntervalDesired = ((86400 - (now - BlockHeightTime)) * nTargetSpacing +
(now - BlockHeightTime) * nFastInterval) / 86400;
else if (now + 86400 > BlockHeightTime && now < BlockHeightTime) // behind schedule by less than a day.
nIntervalDesired = ((86400 - (BlockHeightTime - now)) * nTargetSpacing +
(BlockHeightTime - now) * nSlowInterval) / 86400;
else if (now < BlockHeightTime) nIntervalDesired = nSlowInterval; // ahead by more than a day.
else nIntervalDesired = nFastInterval; // behind by more than a day.
// find out what average intervals over last 5, 7, 9, and 17 blocks have been.
avgRecentTimestamps(pindexLast, &avgOf5, &avgOf7, &avgOf9, &avgOf17);
// check for emergency adjustments. These are to bring the diff up or down FAST when a burst miner or multipool
// jumps on or off. Once they kick in they can adjust difficulty by a factor of nine or ten every ten blocks, and
// they can kick in very rapidly after massive hash power jumps on or off. The emergency speed-up adjustment uses
// shorter intervals for quicker reaction times measured in blocks - which when it's needed will be longer in
// minutes.
toofast = (nIntervalDesired * 3) / 4;
tooslow = (nIntervalDesired * 4) / 3;
if (avgOf7 < toofast && avgOf9 < toofast && avgOf17 < toofast)
{ //emergency adjustment, slow down
difficultyfactor *= 5;
difficultyfactor /= 4;
}
else if (avgOf5 > tooslow && avgOf7 > tooslow && avgOf9 > tooslow)
{ //emergency adjustment, speed up
difficultyfactor *= 4;
difficultyfactor /= 5;
}
// If no emergency adjustment, check for normal adjustment.
else if ((avgOf7 > nIntervalDesired && avgOf9 > nIntervalDesired && avgOf17 > nIntervalDesired) ||
(avgOf7 < nIntervalDesired && avgOf9 < nIntervalDesired && avgOf17 < nIntervalDesired))
{ // 3 averages too high or 3 too low. Doesn't matter which. This will be executed occasionally on the basis of
// random variation, even if the settings are perfect. It regulates one-fifth of the way to the calculated point.
difficultyfactor *= (5 * nIntervalDesired);
difficultyfactor /= (avgOf17 + (4 * nIntervalDesired));
}
// limit to doubling or halving.... though I'm pretty sure there are no realistic conditions where this will make a
// difference.
if (difficultyfactor > 20000) difficultyfactor = 20000;
if (difficultyfactor < 5000) difficultyfactor = 5000;
uint256 bnNew;
uint256 bnOld;
bnOld.SetCompact(pindexLast->nBits);
if (difficultyfactor == 10000) // no adjustment
return(bnOld.GetCompact());
bnNew = bnOld * 10000;
bnNew /= difficultyfactor;
if (bnNew > Params().ProofOfWorkLimit())
bnNew = Params().ProofOfWorkLimit();
LogPrintf("GetNextWorkRequired RETARGET\n");
LogPrintf("Actual time %d, Scheduled time for this block height = %d\n", now, BlockHeightTime );
LogPrintf("Nominal block interval = %d, regulating on interval %d to get back to schedule.\n",
nTargetSpacing, nIntervalDesired );
LogPrintf("Avg intervals of last 5/9/17 blocks = %d / %d / %d.\n", nTargetSpacing, avgOf5, avgOf9, avgOf17);
LogPrintf("Difficulty Before Adjustment: %08x %s\n", pindexLast->nBits, bnOld.ToString());
LogPrintf("Difficulty After Adjustment: %08x %s\n", bnNew.GetCompact(), bnNew.ToString());
return bnNew.GetCompact();
}
This tends to overshoot a little when making emergency adjustments, but it self-corrects within a dozen blocks or so when it does. |
|
|
|
|
What I don't see in these libraries, that I would very much like to see, is comments that say which things you cannot touch or what kind of changes you can make in the block structure, without breaking compatibility with existing ASIC miners.
Anybody know?
Anybody know who knows?
|
|
|
|
|
ASIC miners work on alts whose blocks conform to some set of rules.
What -- exactly -- are the rules?
I want to add new fields to the block, new transaction types, and a couple of other things - but when I'm done I want the result to be able to take advantage of all that ASIC infrastructure out there. So what kind of binary changes can I make and what kind of changes will result in a block that can't be mined with existing ASICs?
|
|
|
|
|
The exchanges are part of the problem, really.
The fact is they're accepting bribes to list coins instead of listing coins on the basis of value or utility.
Which means they've made their money regardless of what happens to the coin. They'll keep it on the board until it looks like the devs don't have the wherewithal to bribe them again, then they'll take it down.
|
|
|
|
|
Graphics are approximately meaningless to me.
A coin which can survive has at least the following properties.
1. The dev is not anonymous. If a coin has an anonymous dev, it's about three times more likely to be a scam than not. Further, if the dev is not anonymous, there are things you can legally do if it does turn out to be a scam and if the dev is anonymous there aren't.
2. It doesn't halve its remaining coin supply more often than it can double its value. That's kind of hard to predict, but at this point I think the double-value time for cryptourrency is up to about a year, maybe two. It'll get longer until it catches up to double-value period for the rest of the economy, which is 7 to 15 years depending on the industry. This is important because whenever the block reward goes down, the hash rate goes down in the same proportion; and when the hash rate gets too low, the blockchain becomes vulnerable to an attack which can destroy its value completely. Expect any coin that mines out its coin supply too fast, to collapse. I think even Bitcoin is going to be too fast in the long run; there'll come a point when its double-value time is slower than its block-reward halving time and alts will start sucking up the hashing power making bitcoin vulnerable to attacks.
3. It isn't an IPO where you're supposed to "buy" coins for some other form of money. A few of those are honest, but most turn out to be scams.
4. The dev actually knows how to fix problems in the software. This is hard to judge straight out of the gate.
5. There's a point. To put it gently, in order for it to be reasonable for someone who's not scamming to release an altcoin, there has to be something wrong with Bitcoin and they have to believe that they can do better. In order to believe any altcoin has a long-term future, there has to be something wrong with Bitcoin and that altcoin has to be able to survive where Bitcoin cannot. Anytime there's an alt, ask what it does that bitcoin cannot do. Then ask, does that enable it to survive where bitcoin cannot?
6. Don't be taken in by talk of philanthropy. Money, when functioning as money, has no morals whatsoever, good or bad. It flows in the reverse direction of the profitable allocation of resources. Any money that attempts to do anything else will cause market distortions that cripple the economy it's working in and ultimately cause it to function less well than its competition.
7. If there's a premine, be sure that the devs are absolutely honest about the premine. If they claim that it'll be used for the good of the community, then the community is entitled to know how every last dime of it gets spent.
8. If there is any difference at all between the block reward structure they advertise and the one they implement, stay away.
|
|
|
|
|
did you not read the thing about giveaways not being allowed in this forum?
|
|
|
|
|
Today added Limecoin (currently market cap 4406), Gaelcoin (currently market cap 4038), Polcoin(currently market cap 3802), and icoin(currently market cap 2554).
Icoin in particular has had a spectacular drop; I have noted a former market cap of $14700 for it and I think that was only a week and a half ago. Limecoin, at the same time, had a market cap of about $19400, so it has dropped "only" about 75%.
It seems that when the bottoms drop out of these, they drop very fast. Which I wouldn't really have noticed except that I happened to keep former market cap information a few days ago.
|
|
|
|
|
iirc, he did offer his services for a considerable while before actually putting up a website about it. I'll see if I can find anything that confirms the status of these coins - or for now, I'll at least update them to show that they launched before coingen.io was registered.
|
|
|
|
|
Okay, you're getting the problem set up wrong. As long as bitcoin is dominant, it doesn't lose fully half of its hashing power when it halves its reward.
Let's say that there is some unit of hashing power that pays 10$ per hour.
If equilibrium has 90% of the effort on BTC at a given moment and 10% on altcoins, then we can conclude that the value of BTC produced by that hashing, per hour, is worth $9 and the value of altcoins produced by that hashing, per hour, is $1.
Now if BTC cuts its reward by half, suddenly it's producing only $4.50 worth of value per hour for that amount of hashing power. The total value being produced by that hash power - the new equilibrium rate - is now $5.50 per hour.
Bitcoin at its halved speed produces that value when it gets 9/11 of that amount of that hashing power and the alts, at the same speed as before, produce that value when they get 2/11 of that hashing power. This is the new point at which the ratio of hashing power to value produced is equal for bitcoin and the alts.
What happens is that the amount of hashing power devoted to the alts nearly doubles, and the reallocation comes out of the amount devoted to bitcoin.
When he uses UNO as an example, UNO halving its reward has effectively no impact on the rate of value production, so the equilibrium rate is relatively unaffected. That makes it very simple; At the same rate, half the value produced buys half the hash power.
|
|
|
|
The bitcoin protocol reward is not going to be changed. Period. It would be a breaking fork and you will never achieve a super majority to support any fork.
You're probably right about that; it would destroy the value of the sunk-costs in ASICs for starters, which means the miners would scream bloody murder. |
|
|
|
He's also right about the effects of block reward halving on hash power allocation.
No he isn't or at least not his conclusions on what "will" happen are just speculation. His "speculation" is that at least half of miners are willing to switch to mining a different coin if it's more profitable. The rest is just a math problem about how to optimize profits. I don't think that's at all in question. Seriously, you can set this up as an equation. |
|
|
|
|
Currently it is possible to hash (eg, in a pool) without knowing the hash of the block you're trying to build on; that's a security problem because pool miners can be diverted into attacks on other coins, into building a hidden chain, or otherwise away from the chain they think they're working on, without their knowledge. We could fix this by altering the hashing algorithm in a way to make it require separate knowledge of the previous block's hash.
This will never happen in BTC though because it would destroy the value of the sunk cost of miners in ASIC rigs.
|
|
|
|
|
Look, he made one mistake; we don't have a practical distributed timestamp protocol, so his proposed solution to that one problem doesn't work.
But he's right about there being a security improvement if miners have to know what they're mining on.
He's also right about the effects of block reward halving on hash power allocation.
Those are real problems with viable solutions, and we can fix them, so why is everybody focusing on the one thing he got wrong?
|
|
|
|
|
I observed AUR with zero market cap today. That's kind of a spectacular crash; whom should we be thanking?
|
|
|
|
|
I'm not ignoring the advice that Paccoin isn't dead; but I'm having big trouble trying to confirm it.
I found a blockchain explorer that gives its current block height and verifies that the blockchain is still running (currently at a block height of 274920). But that's not enough to know that it's still meaningfully alive.
I have not found any exchange which lists a current price for Paccoin, Without that basic information I can't even try to calculate a market cap that would take it off this list.
|
|
|
|
|
Today, added Bitleu, H2Ocoin, and RainbowCoin.
|
|
|
|
|
Show Posts
