Almost makes one wonder why the oh-so-prescient core devs/blockstream employees/AXA proxies choose a 95% activation rate.

You've made some support of logical leap here that omits several steps. How about you show your work?

I support BU. Run it too.

As measured by hash rate, more and more continue to run BU as well.

So sad for you.

Well, no. But thanks for playing. We've got a lovely consolation prize for you on your way out.

One BU miner lost out on the gains they would have made, due to their otherwise solved block being orphaned. Absolutely nobody else experienced any untoward effects. As for me, my BU node remains chugging away, happily, as always.

Sorry but no. Do to an accident of 2^10 being within a couple % of 10^3, lazy people have misused the kilo prefix to refer to a unit of 1024. However, all standards committees of which I am aware are united in the fact that kilo==1000. Period. If you want a convenient unit to refer to 1024, the world has standardised the unit of kibi, or Ki. Similarly, 2^20 is referred to as mebi or Mi, 2^30 is gibi or Gi etc.

So 1024 bytes is 1 KiB. Not 1 KB. Period.

While this seems pedantic to some at first, the ambiguity of using SI units that approximate powers of two has killed people.

Just. Fucking. Stop. Before it kills again.

Given the expense of such a resource, that seems unlikely. Source for this claim?

There's also money to be lost when the market moves faster than that for which you have prepared.


In BTC, I found it pretty easy. Until the moves got unpredictably violent. This is not the sedate stock market. This is Bitcoin. It do dat.

No. In the period before the late 2013 skyrocket, I engaged in some laddered day trading. It taught me a hard lesson. I made a moderate gain in both BTC and fiat while volatility was moderate. However, when the skyrocket came, I was left holding a bag of stinky fiat, with no hope of buying back in at anywhere near the price at which I sold.


I don't understand the question.


'zackly.

Mostly not.


I have generally found that selling at the bottom to be a poor trading strategy. But what the hell do I know? I mostly don't trade.


Suit yourself. In a chaotic inscrutable market, the only consistent indicator being an 8-year bull run amounting to something like a 100,000-bagger, the only rational trade is to buy and hodl.

'In the past' is entirely inapplicable to activation of The SegWit Omnibus Changeset. Core decided to package it up as a soft fork. In a soft fork, non-mining nodes don't count for doodley-squat. Only miners can make the choice as to whether or not to include any SegWit transactions in a given block. It is the nature of the soft fork.

The Core-eans made their bed - all that is left is to sleep therein. Fitfully.

Not at all. Nothing in your tirade answered the question of what you think is problematic about such a thing.

And what about that is problematic?

The issue is not that B's block has a chance of being orphaned due to A's not being valid. Whether or not A's is valid is irrelevant, because C's block is proven valid before A's. Accordingly, it is irrational for B to mine atop A's block. B should mine atop C's block, as C's block will propagate and validate across the entire network before A's block does. And if C's block causes A's block to be orphaned, any block built atop A will also be orphaned.


So then why do you advocate for an artificial limit upon the size of a single transaction?

Now I'm pretty convinced you have no idea what I am trying to convey. I am not speaking to why it is that empty blocks get mined. I am speaking to the point that no changes to the protocol are necessary to solve the 'quadratic hash time issue', as incentives already solve it.

I repeat: a majority of non-mining nodes does not activate The SegWit Omnibus Changeset.

You're a special kind of special, aren't you?

I'm not convinced you are understanding what I am saying. Your description above may be the way things work today (is it?), but it is a stupid design.

The problem is that Pool B is trusting that Pool A's block is valid. The empty blocks are not mined because Pool B is yet to validate Pool A's block, it is due to Pool B not yet knowing which transactions to exclude from the candidate block it (Pool B) is building on top Pool A's (possibly solved but possibly invalid) block. In this I agree, but is irrelevant to the quadratic hash time issue - that is a different concern.

The issue I describe is that, until validated, Pool B has no idea whether or not Pool A's block is or is not valid (duh - tautology). Pool A may be an attacker merely claiming to have solved a block. If this block also contains an expensive to validate transaction (e.g., one in which the quadratic hash issue demands excessive time to validate), then much time will elapse before Pool B knows whether or not it can build a valid candidate block atop the Pool A block.

In this instance, suppose Pool C solves another block which has the same parent as Pool A's block. Let us further suppose that this block is cheap to validate (does not take inordinate time). Rational miners will build atop this Pool C block, rather than Pool A's block. This is because validation can be completed more quickly. These miners are incentivized to stop the expensive validation of Pool A's block, once they validate Pool C's block.

The net result is that Pool A's problem block gets orphaned. The system already has the incentives for rational miners to solve the quadratic hash time issue without recourse to any new fixes such as artificially limiting transaction size.

Again, I don't know current mining implementations. They may be ignorant of this fact. But any miner implementing this idea would then have a natural competitive advantage in any case where problem blocks (containing expensive-to-validate transactions) exist.

Net-net: The problem solves itself.

Nice try. 51% of non-mining nodes don't accomplish jack shit.

Too bad, so sad.

Always? A thousand times no.

Fiat was a receipt for metals initially, this is true. But that was just the bait in the bait n switch scheme. Today, fiat is completely divorced from metals. Further, these days, most 'metal' investments are a bait n switch as well, with 'investors' buying paper gold that ultimately is not redeemable for gold.

Because alts ain't nuttin' but warts on Bitcoin's ass.

franky1 - I see that you are fighting the good fight here, but this is one point I don't think you've thought through. No new magic constants are required. We do not need to artificially limit sigops size. the problem solves itself.

Consider:

When a miner is working on a block, it is trying to earn the block subsidy + transaction fees for its proposed block. It will abandon its attempt to find the hash for its proposed block if and only if it is provided with proof that another block spending some of the same transactions has been found. So when a potentially solved block is presented, it needs to validate that block. In the case of a block with excessive sig in a single transaction, this validation process will take an excessive amount of time (indeed, this is the supposed 'nightmare scenario' that makes quadratic hashing such a scary issue). So what is a miner to do? Stop everything, and devote all processing to validating the incoming potentially-solved block? Hell no. A rational miner will spawn off a single thread to validate the potentially-solved block, and devote the rest of its resources to trying to find the solution hash to its proposed block. Anything else would be self-defeating.

As all rational miners would engage in this process, it is likely that some miner will find an alternate block solution while is is still trying to validate the incoming possibly-good but large-sig-containing block solved by the first solving miner. It is free to propagate its solved block to the network at large.

Upon receiving such a block, rational miners will devote (e.g.) one thread to validating the new block - even as they are still trying to validate the first possibly-good but large-sig-containing block. Whichever is the first to be validated is the block which they will propagate and the block that they will build atop. This would be the second-arriving block that does not engender the quadratic hashing issue.  The first solution block - containing the large sig transaction - gets orphaned. Problem goes away.

What, me worry?