Bitcoin Forum
June 19, 2024, 12:19:47 PM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »
1  Bitcoin / Bitcoin Discussion / Re: what is SegWit's arbitrary discount rate of witness data segment on: June 15, 2017, 10:27:25 PM

You are confused as to how it works.

Segwit actually does _eliminate_ the size limit.   The weight limit is constructed in a way which is compatible with the old limit, such that pre-segwit nodes will not think their limit is violated under any condition.

There are not two distinct limits, avoiding that was a design _requirement_ because multiple limits require multidimensional optimization in mining which would be a serious computational burden and because it would make accurate fee estimation intractable.  (because the fees you would need to pay would depend on the relative contention of the various limits, which depends on the compositions of the transactions in the future after you author your own.)

Weight = 3 x witness-stripped-size + size; and the limit is that the weight must be less than 4 million.   Old nodes receive witness stripped blocks and so they always accept the blocks under their own limits.

(And, FWIW, this is how Bitcoin does all the calculations since 0.13-- the results are the same as the only logic when there are no segwit txn-- so the size is already gone, just witness tx are not yet in use).

Selecting transactions by highest fee per weight is the unique income maximizing solution, no other priority order can produce more fee income (+/- small knapsack boundary effects-- e.g. you might skip a higher rate input in order to fill the block more completely).

Ok, thank you for the thorough response.  It makes sense now and I understand segwit a bit better.
2  Bitcoin / Bitcoin Discussion / Re: what is SegWit's arbitrary discount rate of witness data segment on: June 14, 2017, 06:46:48 PM
Segwit eliminates the size limit and replaces it with a weight limit.  The weight is computed so non-witness data (e.g. the above outputs) count 4x as much towards the limit as witness data (signatures).   The fixes the incentives by balancing the costs of signatures vs outputs to be roughly equal.  It's also how segwit achieves a capacity increase in a way which is fully backwards compatible with old nodes.

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?
3  Bitcoin / Development & Technical Discussion / Re: Blockchain size proposal - Very Slow Voted Changes on: March 31, 2017, 03:30:52 AM
I don't like proposals which involve "voting" of any sort.

I think that the blocksize should be controlled by people who generate transactions

That would just work out to voting with money Sad

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.

And the best way to achieve it would be like follows:

1. Set unlimited blocksize limit
2. Calculate average block size over past 20k blocks
3. If a miner wants to create a block larger than the average, he'll have to solve a puzzle with exponentially higher difficulty. Something like Exp[(new_block_size/average_block_size -1)]*difficulty

This setup increases probability that the miners will attempt to create larger blocks only if consumers (e.g. people who create transactions) actually need them and signal that the larger blocks are needed by posting transactions with larger fees

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.
4  Bitcoin / Development & Technical Discussion / Re: Blockchain size proposal - Very Slow Voted Changes on: March 31, 2017, 03:26:12 AM
You propose to allow exponential growth. Exponent is a scary thing. Did you calculate how big blocks can become in 10, 20 years? Let's suppose moderate 50%/year size increase:
10 years: 57.66MB
20 years: 3325MB
30 years: 191751MB

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.
5  Bitcoin / Development & Technical Discussion / Re: Blockchain size proposal - Very Slow Voted Changes on: March 31, 2017, 03:05:03 AM
I think this is a reasonable proposal.  But if you want serious discussion, the place to make it is on the bitcoin-dev email list.  A little bit of reworking into BIP language and you might win some support there.

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.
6  Bitcoin / Development & Technical Discussion / Re: Blockchain size proposal - Very Slow Voted Changes on: March 29, 2017, 08:38:49 AM
Two days, 444 views, zero replies?

Anyone?
7  Bitcoin / Development & Technical Discussion / Re: hard forks questions on: March 28, 2017, 07:21:47 AM
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.
This is not true. In the event of a chain split, the exchanges would likely temporarily suspend deposits/withdrawals temporarily. Exchanges would then "split" some of their coins by sending a transaction to one address on one chain, then sending a transaction that depends on the same inputs to another address on the other chain. Once both transactions are confirmed, the exchanges may repeat this process in order to have a greater number of coins that are outright "split". After this happens, any withdrawal that the exchanges processes will be dependent on the split transaction(s) on each chain -- exchanges could use two inputs, one from the "combined/unsplit" chain, and one from a specific chain, and this transaction would only be valid on one chain.

Due to certain mining incentives, it is unlikely that very many new blocks will be found on the minority chain with the same type of PoW. If "Bitcoin Core" chain is to survive, then the Core dev team would most likely HF to a new PoW, which would mostly eliminate the risk of a "wipeout" and 51% type attacks on either chain. Until this happens, it is most likely that deposits and withdrawals will not be processed due to the high risk of monitory loss.

Exchanges would only trade in the original (core) fork until BU adds the necessary replay protections to their fork, and have said as much.
This is also not true. Exchanges will list coins that have sufficient demand by their customers. (see my above comment).


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.
8  Bitcoin / Development & Technical Discussion / Re: How many lines of code do I have to change to move the protocol to 10mb blocks? on: March 28, 2017, 03:42:27 AM
I bet it's a few 0 to add, and it's done? I read that 10mb blocks require more computational power to be processed by miners before being distributed and as such costing time which may lead to the block being orphaned or that 10 mb blocks would be to big to be move through the internet.

please let's move to the future. most pools have gb/s internet connection and super server machines. a few ns or ms more may truely be a little bit slower but if everyone has to process the 10mb block there is no edge.

and with pruning it will be as light on the disk...

You'd have to convince an overwhelming majority of bitcoin users to accept your code change.
9  Bitcoin / Development & Technical Discussion / Re: hard forks questions on: March 27, 2017, 10:34:58 PM
Thanks,

In case of a split, which coins the major bitcoin exchange (bitfinex, kraken, bitstamp) will choose? WHat would be consider as the real bitcoin?

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.
10  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: March 27, 2017, 08:54:13 PM

  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.
This is observably and provably false to any objective observer, as this thread is laden with my citations

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.

bitcoin will ultimately because a settlement system for major players and will not be scaled as a coffee money.

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.
11  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: March 27, 2017, 08:37:13 PM
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.

I didn't make that argument. I'm building an altcoin with unlimited transaction scaling.

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.

But BU will never get you there. All you do is enable the mining cartel to create a billion tokens out of thin air.

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

It is the whales who will decide, whether you like it or not. That is the reality of the PoW. If you don't like it, find a different design that is not PoW.

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.


So either the whales are for BU or they are for Core. And they will decide. I analyzed all the technical and economic game theory in great detail already. The Bitcoin whales have to choose small blocks, else they enable the mining cartel to HF to a billion tokens in the future. They will never allow this. BU will be destroyed if they attempt a HF. All of you who buy the BU token will end up bankrupt.

You've been warned. So don't cry later.

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?
12  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: March 27, 2017, 08:23:32 PM
He could possibly be a disinformation agent but you are incorrect to state that he is not responding to your arguments with sound logic.

He is an academic who is pointing out some economic theory.

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.

He has some valid points, but his mistake is he thinks unregulated fractional reserve banking is not a massive bankster fraud. He doesn't seem to understand how the banksters were able to manipulate the USA economy in the 1800s under the very laissez faire system he is advocating. He thinks competition would somehow violate the power-law distribution of banker power and control.  Roll Eyes

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. Smiley
13  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: March 27, 2017, 08:10:26 PM

Logic stands on its own. Authority has to rest on valid logic. Refute my logic.


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

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.
14  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: March 27, 2017, 07:57:41 PM
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.

You're responding to a misinformation agent, a normal person simply doesn't think or respond like that, not with this kind of pattern. If you look beyond the bs he's spewing, you can see his pain, he is obviously someone who is forced to support something he doesn't even believe in, he has no passion, his reply is robotic and he is tired, but he can't stop because it is part of his job and his boss is watching, can you imagine how boring and stressful it is to have to think and respond like a broken robot all the time.


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.
15  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: March 27, 2017, 08:13:15 AM

Your proposal is based on the tacit assumption that increasing the block size is necessary and valuable which is based on the tacitly held assumption that increasing the tps solve a significant problem.

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.

Quote
These assumptions are not based on any accepted economic theory, they are simply perpetuated by people that don't understand the foundation for reason.

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.

Quote
The people that are in favor of either very slow scaling or none at all are the ones that are most educated and read on related economic theory.  They are the one's quoting peer reviewed papers.

That there is a whole faction of people trying to steer bitcoin in a certain direction does not at all give validity to their argument and there is no reason at all to compromise with such irrational behavior.  The system was clearly designed to resist tyranny of the majority.

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

Quote
Core's resistance to hasty scaling and any significant change is simply an extension of Satoshi's designed of a system that cannot be usurped by an ignorant impatient uneducated mob.

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.
16  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: March 27, 2017, 07:53:52 AM
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.
17  Bitcoin / Development & Technical Discussion / Blockchain size proposal - Very Slow Voted Changes on: March 27, 2017, 03:33:19 AM
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.
18  Bitcoin / Bitcoin Discussion / Re: The Golden Ratio Attack. Blocks more than half full lead to mining monopoly. on: July 16, 2015, 04:45:35 AM
(Updated:  I said 1/phi, I should have said 1 - 1/phi.  The attack works for any miners who controls more than 38% of hashing)

The so-called "stress test" was successful.  The attack it was testing is underway.  

Any miner who cotrols more than one minus 1/phi of the mining power, makes a profit while paying the fees it takes to maintain a permanent backlog of transactions, for as long as the blocks are more than half full of other transactions.

The mining-expenses market is unstable when there are enough legitimate transactions to fill more than half a block, because such a miner will reap more per yuan invested in mining power than any other miner.  This leads to a monopoly.

Well, crap.  I have done the math now.  

I know exactly what's happening.  It's a Golden Ratio Attack.  This is serious.  It ends with a mining monopoly.

What we have now is no longer a test.  The test was apparently successful.  What we have here is the new business model that was being tested.  

This backlog will probably be sustained FOREVER, because the people doing it make a profit by doing so.

The following assumes expenses roughly equal for miners relative to the amount of hashing power they control.  This is not exactly true, because a miner someplace where electricity is subsidized (like China) has substantially lower expenses.  In such a place the fraction of mining power required to make it profitable would be even less.

The *initial* "stress test" was a test to see whether the miner controlled sufficient hashing power to make a profit by doing this.  We can assume that test was successful, because now this miner is doing it.  Probably permanently.

The miner decides how much they want per transaction (anything that the traffic will bear, as long as it keeps blocks more than half full of real transactions), then keeps the backlog sufficiently full with bogus transactions to prevent any tx that pay less than that from going through.

Maintaining the backlog subsidizes other people's mining as well as their own, but means they don't need to compete with miners willing to process transactions for less money in fees because those miners aren't willing to process transactions for less fees when any transactions with more fees are available.

Let's work the math.  If 2/3 of the transactions actually processed are "real", then whoever is maintaining the backlog is paying the tx fees for 1/3 of every block. If this is someone with half the mining power then they get half of their third back, so their average cost per block is the fees for 1/6 of the block.  If we are talking about someone with half the mining power, their average return per block is 1/2 the fees for a block.  Because 1/2 is greater than 1/3, they are making a profit.  

The breakeven point for the biggest miner was when his fraction of the mining power plus the fraction of each block devoted to legitimate transactions was equal to one.  We can conclude that whoever is doing this, if he started the instant it was profitable, controlled 1 - 2/(1 + sqrt(5)) of the mining power at that time.  This happens to be one minus the inverse of the Golden Ratio.

It will continue to be in the financial best interests of any miner controlling more than 1 - 2/(1 + sqrt(5)) of the mining power for as long as blocks are more than half full with legitimate transactions.  

This does not affect, and is not influenced by revenue from block subsidies AT ALL.

All miners will see increased fee revenues in the competitive market.  They will respond to more revenue by  investing more in equipment.  Those miners are still competing fairly with each other, though they will make less on their investment than whoever's maintaining the backlog.  It is not in their best interests to add bogus transactions to the queue because with a smaller fraction than 38% of the mining power they would lose money on the fees they invest.

But any miner for whom this IS profitable, will make additional revenue that the fair market among miners does not.  What percentage more, depends on what fraction of the hashing power he controls. Any such miner is competing at an advantage and will eventually drive all other miners out of the market.

Miners for whom this is profitable must control at least 38% of the mining power.  Therefore there can be no more than two miners doing it at a profit.  And it's got positive feedback, so those two cannot compete fairly. Assuming there are two, the instant one of them has more hashing power than the other, he has a competitive advantage over the other (gets back as revenue a greater fraction of all fees spent) than the other miner) and will eventually drive him out of the market.



> 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.
19  Economy / Service Discussion / Re: Stay away from ASICSPACE on: May 07, 2015, 09:00:46 PM

Hm... i only now, when you mentioned this, realized that toomim brothers are a competitor of AsicSpace. Even though the investigation sounds trustworthy... this can hardly be seen as an independent investigation then. I thought they are hardware nerds who can check those things out. But letting the competitor decide if the competition made an error is not really something that comes to mind when one wants an independent investigation about the source of the problems. I dont say anything, i only point out a conflict of interests.

Yes, I have a conflict of interest. Sorry if that wasn't very clear. I'll edit a note of that into my initial analysis.

Edit: It's also worth mentioning that I used to be business partners with Robert and Damir, and my brother and I originally planned to design and fund most of their datacenter for them in exchange for free hosting for our SP30s and partial ownership of the business. My brother and I decided that we did not want to be involved with them (mostly because of Damir), so we broke off and forged on our own. They claim we acted inappropriately and dishonestly, and that our original intent was just to deceive them and use them to find a location to build our own facility. I claim that they were not competent enough to continue collaboration with, and that we didn't realize this until after we were heavily involved with them.
You can read about that history here.

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

Quote
truer words have never been spoken. You always come up with the most ridiculous claims and the request for a observatory stance like this is Kindergarten.

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

Quote
Fuck this. Damage has been done, ASICCRAP is not paying up and customers of theirs are not getting reimbursed for the damage.

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?

Quote
For now, you got to live with what is on the table and you either take that or you don't.

Hmm....
20  Economy / Service Discussion / Re: Stay away from ASICSPACE on: May 06, 2015, 07:03:13 PM

Someone else might read this wondering how hot things need to be to damage an S5. I don't want people to think that they magically start to burn up as soon as the intake temperature exceeds 40°C. Accuracy is useful even when it's not necessary for the immediate task.

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.

Quote
Quote
I wasn't saying that air pressure did the bend, air pressure only influenced the direction of bend at best.

I posit that air pressure, primarily, caused the runaway temperatures localized to a certain point on the boards.
Quote
Specifically to this case... I looked up the coefficient of thermal expansion for PE and found from 80F to 135F you get ~0.5% expansion.  Putting that in a right triangle gives you a bowing outwards of about 2.5cm from a ~17.5cm plastic strip.  You said you measured 2cm at worst, so that's about right.
(Minus the expansion of steel and aluminum, which is much smaller.)

Most of the plastic deformation indicates a shear stress, not compressive stress. The only exception to this is the buckling that was observed in a small number of the most severely deformed plastic. The buckling of the plastic occurred entirely along the short axis of the plastic shields. If thermal expansion were the culprit, I would expect to see buckling along the long axis as well, especially along the line in between the front and back screws. That line is the least deformed part of the side panels.  The bottom edge is more securely attached than the top edge as well, so if the main cause of deformation was thermal expansion, one would expect the bottom edge to show more buckling and deformation. The opposite is true. The greatest deformation occurred on edges which I expect had the greatest airflow (evenly along the top edge, plus the back and front edge near the holes for the tail exhaust and fan).


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.

Quote
Much of the deformation occurred on the top edge, above the highest screw attachment point. That edge typically is relatively straight, but it sags outward and downward. Since this edge was not being squeezed, and if it were it wouldn't cause the edge to sag like that, I don't think thermal expansion is a satisfactory explanation. Thermal softening combined with airflow is.  The apparent buckling I observed on a few panels might actually have been fluid dynamic effects similar to ocean waves or sand dunes being created by wind rather than actual buckling.

Something just occurred to me. If the airflow was anterograde but slow through the whole intra-heatsink space, the air coming out the exhaust port would be very hot. The side spaces would not maintain their pressure as well, so airflow there would be more likely to turn retrograde. This would pull the hot exhaust air around 180° back in the side ports before flowing either out the top of the miner or through the gap in the panel between the screws. This could explain the pattern of deformation pretty well.

To be clear, I don't believe airflow played no part in what we see, that would be silly of me.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!