The quadratic hashing issue is a non-problem.
Any miner that creates a block that takes inordinate time to validate will find himself bankrupted by other miners who continue hashing on the same parent to find a peer solved block. Such a peer solved block will validate well before the aberrant block, leading to the aberrant block being orphaned. 'Problem' solved. With the incentives as they exist today. Unchanged.
Any miner that creates a block that takes inordinate time to validate will find himself bankrupted by other miners who continue hashing on the same parent to find a peer solved block. Such a peer solved block will validate well before the aberrant block, leading to the aberrant block being orphaned. 'Problem' solved. With the incentives as they exist today. Unchanged.
I love the semantic hair split between "issue" and "problem" that you start off with. Great spin. Very Comical Ali of you.
Spin? WTF? No spin here.
I could have used the word 'aspect' instead of 'issue'. Or 'attribute'. Or some other. Wouldn't have made much difference.
Quote
But how can you predict exact future scenarios like that? Are you psychic? Do you have visions or hear angels?
It is not a 'prediction', it is pointing out an essential element of the incentives already baked in to Bitcoin. I know you know that Bitcoin only works _at_all_ because the incentives are such that 'doing the right thing' is profitable. Right? Well, this is just one more instance of doing the right thing being profitable.
I'll admit that I don't know if any significant miners currently implement this policy. Then again, aberrant blocks -- in the sense that they take a huge time to validate -- are rare. Indeed, I am aware of only one ever being created. But if such blocks ever became A Thing, rational miners will implement the mode I describe above. Because orphaning such aberrant blocks by others guarantees increased profitability.
Sure, we might choke down several aberrant blocks in the meantime. But that won't bring the network down. It merely forestalls block completion time in the same manner that a variance outlier does. We've choked down at least one of these blocks before -- indeed one crafted intentionally to max out validation time -- to no ill effect.
Quote
The rest of us simply don't know the specifics about the situation (which seems to be both empirical and theoretical!) you are describing.
Don't blame me for your being unable to game out this perfectly rational scenario. It is the only such scenario that makes sense in the case of such aberrant blocks.
Quote
Doesn't the percent of total mining power the putative attack block creator determine the likelihood of his attack fork will be reclaimed by the defending chain?
Of course. A 51% attacker always gets to define the chain. What's your point?
Quote
Doesn't variance also play a non-computable role in determining whether the attack block-based or defending chain-based side will win?
Of course. These things are all probabilistic. But the incentives are aligned to render this (::ahem::!) attribute a non-problem.
Quote
If the quadratic hashing issue is a truly a "non-problem" then why did Gavin write an unforgivably kludgy, quick and dirty, non-futureproof workaround for it? 
Because Gavin is a pragmatist that endeavored to give the users what they wanted, as long as it did not cause any actual harm? I dunno - you'd need to ask him.
Incidentally, I'm not aware of any 'unforgivably klugy' such work by him. To which pull req are you referring?
Yes, I understand what makes Bitcoin work is its (magnificent, sublime) alignment of incentives.
No, you can't simply assert ("waaaah, it's not a prediction") you have concrete knowledge of future events, because another way to describe your "perfectly rational scenario" is "anointed vision."
Quadratic sigop validation is an ISSUE. You may try to furiously backpedal and retroactively substitute in less self-incriminating terms like "aspect" or "attribute" but the damage is done. Everything you pile on top of your inadvertent admission are excuses at best and lies at worst.
Your problem is that you don't know what the fuck your talking about.
You aren't even familiar with Gavin's sigop/sighash patch and the situation/history surrounding it, yet feel perfectly comfortable telling those of us who are you know more about the situation. That some nice Entitlement Syndrome you got there, Mr. Comical Ali.
GTFO and come back when you are less ignorant of the critical nuances involved in this complex area of non-linearly interacting multidisciplinary subjects.
Here, I'll even spoon feed you like a baby so you can't whine about how mean I'm being.
Accurate sigop/sighash accounting and limits is important, because without it, increasing the block size limit might be dangerous. You can watch my presentation at DevCore last November for the details, but basically Satoshi didnt think hard enough about how transactions are signed, and as a result it is possible to create very large transactions that are very expensive to validate. This commit cleans up some of that technical debt, implementing a new ValidationCostTracker that keeps track of how much work is done to validate transactions and then uses it along with a new limit (MAX_BLOCK_SIGHASH) to make sure nobody can create a very expensive-to-validate block to try to gum up the network.
Quote from: https://github.com/bitcoinclassic/bitcoinclassic/pull/65/commits/52caa87bb5a3074c4888d6afad8b292659f9acef
Do not relay or mine excessive sighash transactions
This is a belt-and-suspenders fix to make sure CreateNewBlock() or external mining software can never produce a block that violates the MAX_BLOCK_SIGHASH rule.
It does this by rejecting transactions that do too much signature hashing -- they are not added to the memory pool, and so will not be considered for inclusion in new blocks.
gavinandresen committed on Feb 2, 2016
This is a belt-and-suspenders fix to make sure CreateNewBlock() or external mining software can never produce a block that violates the MAX_BLOCK_SIGHASH rule.
It does this by rejecting transactions that do too much signature hashing -- they are not added to the memory pool, and so will not be considered for inclusion in new blocks.
gavinandresen committed on Feb 2, 2016
See? We don't need to ask Gavin anything. He's already rubbished your entire position. You'd be aware of that if you read more and played Nostradamus less.