Ok, thank you for the thorough response.  It makes sense now and I understand segwit a bit better.

I'm really confused on this, can you clarify?

As far as I understand it, segwit does not eliminate the size limit.  The size limit is still 1mb.  It just adds a weight limit of 3+1=4mb.  Correct?

And the witness discount is only used for relative fee prioritization, right?

So in that light, miners could easily decide they can earn more by modifying the code to prioritize transactions differently, primarily by the limit that gets hit first(probably the 1mb limit).  Right?

It seems to me that the witness discount is an inherent property of the lower blocksize limit versus the higher blockweight limit.  And in the decade-long persepctive, there would/should be no cost for the witness data, as that isn't the constraint the miners have to prioritize on (unless blockweight is consistently hit before blocksize).  Am I confused on how this works?  Does witness data weight actually count against the blocksize limit itself?

That would just work out to voting with money

I don't understand the dislike of miner voting systems.  It assumes that miners want substantially different things than users, but I don't see any real evidence that the differences are significant.  Maybe they are, but I have yet to see someone show that they are with data or game theory.


I've seen proposals like that before.  I mean, they're better than nothing.  But miners accidentally create higher-difficulty blocks all the time, so the size could continuously increase as well, just restrained by randomness.  Might as well just give it a time-bound scaling ratio then.

Yes, I calculated that.  You can check the spreadsheet to play with the numbers.  Firstly, 191 GB blocks aren't a possibility.  At 31 GB blocks we'd catch up to 100% of the worldwide non-bitcoin transaction volume even accounting for the growth of that number.  There's no way that many businesses/people are going to switch to Bitcoin in 30 years.  If we got 5% that'd be awesome, and that's 900mb blocks.  900mb blocks may sound terrifying, but even without major improvements to the protocol businesses and nonprofits like the EFF could run nodes for less than $2000 a month.  That's a rounding error in most business' IT budgets, and nodes would be running in every nearly every country on the planet by that point, massively geographically distributed.  Early adopters could easily run a node for the rest of their life without breaking a sweat.  That doesn't seem scary to me at all for 5% of the world's transaction volume.  Shit, if we had 5% of the world's transaction volume, the price would probably be upwards of $60,000 per BTC, or more.

Secondly, 50% growth year over year is offset by a 17% decline in bandwidth and hard drive prices, so ~33% increase per year in node operational costs.  Bitcoin prices have been increasing by 44% per year for the last 4 years, so for anyone who actually holds more than a few bitcoins, the node costs remain trivial.

Thirdly, 50% growth year over year for 10-30 years requires a continuous agreement of 60% of the miners for that full time period, with no miner waving.  Historically getting 60% of miners to agree to signal the same thing has been very difficult, much less getting them to continue supporting it for a year.  All it would take is one miner agreeing that node costs were becoming problematic and switching his vote and the growth would stall dramatically.

So yeah, those numbers look scary at first.  They did for me too.  But given the possible rewards for Bitcoin, it really isn't that scary.

Thanks for the feedback.  I joined a few days ago and am feeling it out.  I get the idea right now that there's too much resistance to nearly any blocksize increase except SW.  Unfortunate, really.

Two days, 444 views, zero replies?

Anyone?

I mean, you can hypothesize all you want, but every large exchange literally already said they are doing what I wrote and exactly not doing what you described.

You'd have to convince an overwhelming majority of bitcoin users to accept your code change.

Forks suffer from a problem known as transaction replaying - If you tried to spend coins on one fork, it would probably be spent on the other fork too, which makes it nearly impossible for exchanges to accept/trade both.

Exchanges would only trade in the original (core) fork until BU adds the necessary replay protections to their fork, and have said as much.  It isn't a matter of supporting one or the other so much as a necessity because of the technical problems.  BU, naturally, does not wish to add replay protections as it could reveal very low numbers of adoption and use, and also represents the point of no return.

Once BU adds replay protections, most exchanges will list both coins until one fork dies.  The price of BU coins are most likely going to be much, much lower (though the prices of both forks will drop significantly), which is going to put revenue-sensitive miners in a world of hurt.

It isn't going to be pretty for anyone.  Ethereum's price will go up.

I love how I pointed out that much of your citations is you citing yourself, and in response you proceed to do exactly that.  Hilarious.


I used to believe this point completely.  I agree with the first part, and I do agree that Bitcoin will never be scaled as a coffee money.  That said, there is a middle ground between "settlement system for major players only" and "coffee money" that Bitcoin can achieve, and eventually this choice will become self-evident (but maybe too late). For example, $2 per transaction does not restrict Bitcoin to major players only, but is also not usable for coffee money, a target that I have reason to believe is achievable.

The reason the choice will become self-evident is simple - Currently it costs a minimum of roughly 0.01 BTC per month to operate a node(based on bandwidth, hdd costs alone), and ~0.0003 BTC to reliably send transactions to use that node.  Over time technology improves, adoption increases, and crypto prices rise, which causes the cost of operating a static-blocksize node to fall dramatically and the cost of sending a transaction to rise dramatically, with no growth limits on either number.  Without blocksize increases, it will eventually cost more to operate a node for one month than it costs to send a single transaction, at which point home users will stop running nodes anyway because they are not using Bitcoin, which defeats the only reason we would arbitrarily keep node operational costs low in the first place.

The solution is simple - we have to stop thinking of acceptable node operational costs in terms of dollars and instead think of acceptable node operational costs in terms of BTC/month.  What exactly qualifies as an acceptable node operational cost per month is highly debatable, but changing the math/thinking in that way changes the problem entire.  It allows growth that can almost completely offset increased transaction demand.  It won't lower tx fee costs - I think they still have to rise a bit - but it prevents them from going exponential or locking out home users.

If your altcoin doesn't solve blockchain sharding, then no you are not building any such thing.  There are too many humans on the planet and bandwidth costs are not trending anywhere near fast enough to make an unsharded blockchain feasible for the levels of transactions that humans demand.  Worldwide transaction volume in 2015 was 426 billion transactions, which at 600b per transaction works out to needing a 2 gigabit per second link to the internet for every single node - nearly 1/5th of the internet link of some whole datacenters.  That's just for 2015; It is growing by ~8% a year while bandwidth is improving at only 8-18% per year, and that's with the vast majority of humans on earth not sending any transactions at all (unbanked).  18% does not outpace those numbers in our lifetimes.

Computers don't do unlimited.  That said, I don't know anything about what you are building, not trying to insult you, but people need to understand the scope of the problem.


I don't support BU so that's a mute point.  This is my proposal that I would like feedback on: https://bitcointalk.org/index.php?topic=1844059.0


That much I'm inclined to agree with.  However, I do believe that weakness of PoW is not as bad as the weaknesses in PoS, which are subject to a very different kind of abuse by a whale attacker - namely the fact that "emptied" addresses on the main chain still retain historical staking value of coins that aren't supposed to exist according to the consensus chain.  Without checkpointing, there's no way to invalidate the historical staking value those addresses no longer contain, but checkpointing is vulnerable to attacks by authorities like what EU regulators are hoping they can do.



Aside from the BU-specific stuff, which I most likely already agree with you on, I'm curious about your game theory findings.  What do you mean the mining cartel will HF to a billion tokens in the future?  Did you find something that indicated that the Bitcoin whales could not support a blocksize increase on core?

Dude, I read his posts in this thread from the start.  For every 5 times he claims to be citing theories(and that no one else is / no one but his position does science properly), he actually cites his own comments twice and maybe links to something else once or name drops once.  When he does link elsewhere or name drop, he doesn't explain how their writing relates to his, what conclusion he is pushing or what specific point he is referencing.  It is a garbage throw-shit-at-everything debating strategy.  His strategy works really well for young earth creationists and 9-11 truthers.


That's only one of the points he has thrown out, and I don't think either of you could provide conclusive evidence to convince the other, nor could either of you convince me.  From what I have read, macroeconomics is heavily laden with bullshit (on all sides) and effectively boils down to a Rorschach test whenever it deviates from game theory questions or microeconomic evaluations.  And yes, that statement is based upon research findings comparing the popularity of macroeconomic theories versus time periods and politics at that time.  Your statements about unregulated fractional reserve banker fraud make me wonder if you either have a mostly-inapplicable definition of "unregulated" (compared to the modern day), or else are a conspiracy theorist.

It doesn't matter, I'm not saying you're wrong either.  Almost none of that dispute substantially relates to the discussions of Bitcoin at hand, as far as I can tell.  And I don't care for either argument, though I do appreciate that you are far more rational and polite than he is, so thank you.

Excellent quote, well said.  I want to steal that.

FYI, I disagree with both of you regarding the idea that transaction volume is not essential to Bitcoin's growth because Bitcoin can function like gold.  Many things can function like gold and have attempted to do exactly that over human history.  Despite that, there is only one gold.

Gold's dominance is predicated upon nearly 4000 years of acceptance in every commercially-connected location on the planet - to this day, you can exchange gold for local money in nearly any city at almost the same exchange rate.  Doofus-spammer's theory that Bitcoin doesn't need tx volume because it will function like gold ignores the obvious discrepancy between Bitcoin's 8-year, unstable, and limited-acceptance history and gold's massive scope.

Bitcoin **may** function like gold due to its advantages over gold, but almost any other altcoin could function in the exact same manner and surpass Bitcoin and/or gold.  The competing coins must differentiate themselves, and Bitcoin's best differentiation - the first mover advantage and relatively high stability - will be forced to face off against other competing coin's relative ease of transacting.  If Bitcoin becomes decisively more difficult/costly to transact with than competing coins who replicate all other features that Doofus-spammer's theory relies upon, Bitcoin's first mover effect will be eclipsed, and we will all lose.

Bitcoin is in no position to claim that it can win on its merits simple because gold wins on similar merits.

After reading his comments I realized how pointless arguing with him is.  While I think it is far more likely that he is just not intelligent enough to see the flaws in his own posting, I will say his grandiosity and bad behavior is so bad it makes me embarrassed to think that I still support/agree with many of the same things as him.

You are correct that I believe that a block size increase is both necessary and valuable, but that is not what my proposal is based upon nor was it something I said anywhere in the proposal.  The proposal is a compromise because the vast majority of Bitcoin users and holders think you are the retarded one, just like you think they are.  Regardless of whether you are right or not, they are going to severely damage the prospects of Bitcoin if you do not compromise.

You should probably know that I used to vehemently support your argument, day in, day out.  Until I spent a month working out the math in great detail and realized that I was arguing for the wrong thing.


This is the same kind of bullshit mudflinging that needs to stop.  First you make an appeal to ignorance and mischaracterize other people's arguments, and then you insult everyone who disagrees with you.


Zero proof, sources cited, or any arguments of substance.  Much appeal to authority fallacy, yes.


And while committing logical fallacies and being a jackass, you claim the higher ground.  Nice.

I hate to break it to you, but you are acting like the garbage that you proclaim to abhor.

How about we break the cycle of mudflinging and insults - against both sides - and go back to searching for a compromise solution.

I proposed one today after days of research and refinement and weeks of toying with the idea.  I would like some rational feedback:

https://bitcointalk.org/index.php?topic=1844059.0

The infighting and mudflinging is hurting all of us.

Intro

The Bitcoin blocksize debate is giving altcoins their golden opportunity to break Bitcoin's dominance, primarily because several extreme ideological factions are completely unwilling to compromise with the opposing side, and now frequently promote drastic threats against the other side.  The net result regardless of who is right and wrong is that all bitcoiners are losing, and all altcoins are winning by default.

Simplest summary: "Very slow voted changes." This proposal attempts to fairly and evenly balance the power and concerns of all of the competing ideologies.

Here's the idea: Miners vote on blocksize changes, up or down, in very small steps up to an 80% increase in blocksize per year.  The voting caps on miners are as tight as possible, to handle a frequent objection to any miner voting proposals - "Miners gaining dangerous levels of control" - or relatedly - "miners' best interest diverging from users'".  80% is the best fit because it is sufficient to allow unanimous agreement match our very-high 2-year transaction growth(+81/80% YoY), whereas anything higher decreases the protection for those who favor small blocks.

As shown in the scenario analysis below, even a small amount of disagreement among miners restricts growth massively. I reference the discrepancies between signaling over the past 2 years(Classic, XT, BU, SegWit, No signal) that even if miner's disagreements are not equivalent to users', significant differences of opinion naturally occur among miners.  Even without any divisions, the growth is slow enough that miners have ample time to learn(or be persuaded) from bad voting decisions and correct them.

Block validity is deterministic, and thus does not attempt to redefine "consensus" like BU does.  Most important of all, the math is structured to allow a minority vote to provide a disproportionate slowdown mechanism on growth.  The net result should change conflicts (incomplete compromises -> anger and zero progress) into cooperations (partial compromise -> partial progress).

So, how does this proposal accomplish those things?  The proposal is closest to Garzik's BIP100 current version, but with some important changes.

This idea vs BIP100 and other related ideas

BIP100:
1. The original BIP100 allowed 20% increases per difficulty(Max: 1.2^26th% per year). The current BIP100 allows 5% per difficulty which compounds to ~270% per year, or 8mb blocks before 2018 ends.  This proposal is 80%/year (2.3% per diff), or 8mb blocks by early 2021 if all miners vote unanimously.
2. BIP100 planned re-evaluation at 32MB. Re-evaluation is not needed under this proposal, as the slow pace encourages analysis and opinion adjustments, and the strong influence of the minority encourages mutual cooperation.
3. BIP100 allowed a cutoff minority(21% originally) to veto blocksize increases, and gave 100% of the decision power to the lowest moderate voters.  This proposal includes all positions, without significantly favoring any.
4. The original BIP100 gave a non-veto minority no influence on blocksize growth; This one gives them the ability to constrain growth by more than double their minority percentage.

After writing this up, I found two other proposals that were somewhat similar.  The first, by "BTC Drak" (dev email list, Aug 2015), had the too-high-limits flaw (max ~1,200% per year) that he attempted to offset with a cost for voting for increases.  The second, by "PondJohn" (bitcointalk.org dev section, Jan 2017) proposed a reasonable scaling limit(~100%/y, ~2.7% per difficulty), but it intentionally unbalanced increase votes against decrease votes by adding a cost to increase votes and changing the numbers.  That unbalanced approach makes it difficult to estimate how the proposal might play out in reality.  It also seemed to assume that size adjustments occurring naturally at every difficulty change is not desirable.

I originally attempted to design the math to favor the minority and/or small blocks, like all similar vote proposals, but I discovered by digging through almost 100 different split-vote scenarios that it simply wasn't necessary, and those approaches unintentionally broke other split-vote scenarios.  I also considered a few approaches that penalized extreme votes, but found that the system worked quite well even when every vote is for an extreme.

How it works

This proposal would allow (after activation) all miners to add a vote for blocksize to their blocks, with all numbers larger than 1MB being valid votes.  At every difficulty change, the votes from that difficulty period are tallied, with missing votes counted as a vote for no change.  Each vote is clamped between ~1.594x and ~0.419x times the current maximum blocksize, and then averaged together.  The reason for the odd multipliers is that there are roughly 26.9 difficulty changes in a year, and 59.4% compounded on 26.9 intervals works out to 80% YoY growth (2.3% per diff).  The minimum vote clamp is calculated such that one extreme-shrink blocksize vote is perfectly offset by a subsequent extreme-growth blocksize vote; Mathematically, this maximizes the slowing power of a small-block minority without allowing attacker(s) to shrink the blocksize faster than it could be regrown.

After the clamped vote average is calculated, the next difficulties' consensus maximum blocksize is defined as 1/26.9th of the voted increase or decrease.  Since the votes are clamped to a minimum and maximum, averages give a minority significant influence over a majority without changing end results.

How does this play out?  This image summarizes the numbers under different split-vote scenarios:

https://goo.gl/w52VTc

Of note from this summary, only with a constant overwhelming majority favoring increases are 5mb+ blocks possible within 5 years.  In the 3 cases where not all votes went towards the extremes, the growth quickly came close to a balanced compromise and then stopped.

There are two anomalies that slightly favor larger blocks, visible in the above situations.  The first is that when the current blocksize is smaller than 2.4mb, the minimum vote is arbitrarily constrained(1.0mb) and the maximum is not(first situation small-block majority).  The second is a side effect of allowing any possible unanimous decrease step to be offset by one subsequent unanimous increase step("perfect disagreement" situation).  Both advantages have a very small impact on long-term results.

I've also made an excel spreadsheet to examine different split-vote scenarios that can be downloaded from here: https://goo.gl/CdLz41

Any miners that do not vote further decrease these growth numbers.  Those miners can be approached by the community and convinced to vote for one side or the other.

Potential attacks

This has one potential vulnerability apparent to me thus far: A majority could easily collude to orphan all blocks they disagree with to accelerate growth(and punish dissent).  A block-orphan attack like this is not new, and is already a possibility in our current situation.

For example, if all Chinese miners pooled together, they could orphan all blocks not mined to a cartel-whitelisted address, decreasing the difficulty, and thus take control of 100% of the mining.  Even if the network took the drastic step of changing the PoW algorithm, the vulnerability would still exist due to natural inequalities in suitable mining locations and efficiencies of scale.

Ethereum(Or whoever originally generated the concept) has a workable solution: Uncle block rewards.  Unlike Ethereum, our financial supply does not grow forever, so it requires some adjustment.

Simply put, recent orphan blocks may be referenced by other valid blocks(nephew includes uncle reference) to split the "lost" orphan reward for both miners(smaller fraction to nephew).  Transactions that would have been valid if included in the nephew are counted towards the orphan block reward split and are considered confirmed by the nephew's inclusion.  To prevent exploitation, referenced uncle blocks(but not unreferenced orphans) count for the purposes of votes and difficulty calculations.  Further, time limits/uncle limits would be included.

Not including an orphan-attack fix would not be fatal to this proposal, but including it would have significant other benefits and encourage miner support in the face of alternatives currently preferred by miners.  Given the massively increased complexity of uncle changes, after the rules are agreed upon it could be forcibly activated after a pre-determined 6-12 month delay (I.e. further static delay after activating this proposal), preventing the need for a second hardfork.  This could give ample time for testing and third party code updates without delaying the much simpler blocksize voting changes.

Responses to each conflicting ideology

1. No Blocksize increases: Those favoring no blocksize increases at all are in the extreme minority.  Refusing to compromise may result in even bigger blocks than would be possible by compromising, after significant damage from a contentious hardfork.  Refusing to compromise hurts all Bitcoin holders, miners, users, and developers.
2. Small blocksize increases only:  This proposal will most likely exhibit the kind of growth these users can swallow.  Under most scenarios even a moderate amount of dissent allows only slightly faster blocksize growth than technology's increases(8-18%/yr) and puts 4mb blocks more than 5 years away.  Growth rates are predictable years in advance with narrow margins of error for any hardware/bandwidth planning, personal or otherwise.
3. Big blockers:  This proposal allows the possibility of growth rates that can achieve a main goal of big blockers - Preventing transaction demand from driving fees up.  Big blockers would know which pools to talk to about changing their vote, and could attempt to resolve those miners' concerns.  In addition, steady growth is nearly guaranteed given the popularity of bigger blocks.
4. BU Proponents: This proposal could end the war between BU and core while accomplishing most of the goals BU set out to accomplish.  Everyone's coins would increase in value.
5. Segwit-solves-everything: Segwit only provides a limited, one-time blocksize increase.  We will face this contentious issue again soon without more than segwit.  Segwit activation could also be a prerequisite for this proposal's adoption as part of the compromise.
6. Miners-must-never-control: The only practical alternatives either require multiple contentious hardforks or require developers to accurately predict the proper future limits many years in advance.  This proposal has developers setting upper bounds as low as is reasonable and gives the minority tremendous slowing power without blocking the majority.
7. Miners-must-have-control: This approach gives miners the main control lever, and strongly encourages cooperation between differing ideologies.

I welcome any rational feedback.  Thanks.

> But any miner for whom this IS profitable, will make additional revenue that the fair market among miners does not.  

Um.  How on earth do you conclude that?

The miner jacking up fees will have his mining-fee-profits increased by some small amount.  Every miner not wasting money on the attack would have their mining-fee-profits increased by several orders of magnitude more since you are talking about small margins.  The attacker is making it much much easier for his competition to beat him in mining share.

Interesting, it is good to finally know the rest of the story.  Edit- Hmm, found more info I didn't know.  Removed negative comment.


Yes, being an asshole to longtime highly trusted members of the community is going to go REALLY well for your war on Asicspace.


You might want to review your hosting agreement with Toomim.  No hosting company anywhere is going to reimburse customers for miners(according to the contract).  They can't.  The margins are too slim, and there's too many things that can possibly go wrong with miners, many of which(not all, and not necessarily in this case) aren't under the control of the hoster.  Some may reimburse in some situations, but it won't be a standard thing except perhaps with the highest cost providers(at a net loss to their customer base).

For all your kicking and screaming, if you take this to court, you will almost certainly lose.

So your intent as you have made clear is to make Asicspace suffer economically.  Might I suggest that if you really want to tarnish Asicspace's reputation, being an asshole about it will only make people doubt your statements?  Or did you not notice Toomim's statements, being a stand-up guy(respect): "When I was at ASICSPACE earlier today, the conditions were considerably improved."  Are you going to rant and rage at toomim now for saying something positive like you did to SebastianJU for saying something neutral?


Hmm....

True but equally frightening.  A miner burning up is a factor of a lot more things than intake temperature as you agree with the two S5's example.  Normally we talk about "intake" temperatures because it simplifies the discussion down to a workable set, but doing so makes some basic assumptions, such as that exhaust airflow isn't constrained.  As soon as someone starts violating those assumptions, everything changes.

It is possible(though not practical) to get a S5 to run safely with a 65 degree intake as well as to fail with a 15 degree intake.  We do the readers no favors by glossing over this reality in my opinion.


Remember when talking about temperature under cases where normal assumptions are violated, it is useless without also talking about specifically where the temperature is.  The middle of the plastic sheets didn't warp because the middle didn't get so hot.  The edges did because the edges touched the metal, a better heat conductor, and the exhaust edge specifically had higher heat. In the pictures you have provided, one perhaps 2 of the plastic have deformations on both sides.  6 or 7 have deformations on one side with far smaller or no deformations on the opposite side.  Of all of the sheets in the picture, one shows minor top-edge deformations, one shows a lot of top edge deformation, and the only other one with top edge deformations is very close to the screws/my proposed hot spot.  6 show no top edge deformation at all.


To be clear, I don't believe airflow played no part in what we see, that would be silly of me.