If not... such contracts would only make sense to those currently positioned in fiat/Long on fiat... what am I missing? 
You are missing that this proposal is bad for Bitcoin in the long run
So... the If not stands?
Topic: Bitcoin 20MB Fork - page 6. (Read 154785 times)
You are missing that this proposal is bad for Bitcoin in the long run
So... the If not stands?
There is no "three-to-one" margin. You don't get to claim agnostic/DGAF as votes to affirm your silly fork, which actually only enjoys 60% support against the negative/status quo default presumption.
His math is correct though, if you have 60% X and 20% Y then you have a 3-to-1 ratio
The math is correct, but it's 60% pro and 40% not-pro. So 3:2. Not remotely close to even rough, much less sipa's extremely wide, consensus.
I don't know why you assume that agnostic/DGAF should be on the anti side. If I wanted, I could arrange the numbers this way:
Anti: 20%
Not-anti: 80%
It makes as much sense as 60% vs 40%. That is, no sense at all.
Logic 101, bro.
Presumption is negative. Burden of proof falls on the affirmative.
Why? Because if presumption was affirmative, we'd have to prove negatives to rebut it. And you can't prove a negative. QED.
You should have learned that in high school. Consider suing your teachers for doing a really shitty job of educating you.
There is no "three-to-one" margin. You don't get to claim agnostic/DGAF as votes to affirm your silly fork, which actually only enjoys 60% support against the negative/status quo default presumption.
His math is correct though, if you have 60% X and 20% Y then you have a 3-to-1 ratio
The math is correct, but it's 60% pro and 40% not-pro. So 3:2. Not remotely close to even rough, much less sipa's extremely wide, consensus.
I don't know why you assume that agnostic/DGAF should be on the anti side. If I wanted, I could arrange the numbers this way:
Anti: 20%
Not-anti: 80%
It makes as much sense as 60% vs 40%. That is, no sense at all.
There is no "three-to-one" margin. You don't get to claim agnostic/DGAF as votes to affirm your silly fork, which actually only enjoys 60% support against the negative/status quo default presumption.
His math is correct though, if you have 60% X and 20% Y then you have a 3-to-1 ratio
The math is correct, but it's 60% pro and 40% not-pro. So 3:2. Not remotely close to even rough, much less sipa's extremely wide, consensus.
not sure if the thought process behind the said shorting contracts make sense though.
Why not ?
So... the If not stands?
Some people, I am among them, are of the opinion that this fork is unneeded, "solves" a problem that does not exist, and has the potential to harm Bitcoin in the long run.
In this world of 4k streaming, advocating the idea of 1MB blocksize limit is analogous to advocating 240p.
IMPORTANT:
There's only five losers in this thread who would advocate such a thing...
... and all of them are MP or part of his Scooby gang.
IMPORTANT:
There's only five losers in this thread who would advocate such a thing...
... and all of them are MP or part of his Scooby gang.
Super-cute graphic. I love that guy in the far right, who is he? Then there's MP over there on the left in his hell no 1MB please world
There is no "three-to-one" margin. You don't get to claim agnostic/DGAF as votes to affirm your silly fork, which actually only enjoys 60% support against the negative/status quo default presumption.
His math is correct though, if you have 60% X and 20% Y then you have a 3-to-1 ratio
I have not read through the full tread but is there a summary of the core developer's positions on this matter?
This is a troll thread. I doubt any core devs participated in any of these 130+ pages. There have been other threads that resolved this long ago. The cool thing is that they continue to improve the solutions beyond expectations. This thread will only end when MP stops paying his shills.MP is not paying me.
Why so eager to denigrate this thread? Why so hasty to claim victory and declare the issue "resolved?"
As if on cue, Gavin suddenly participates, making you wrong once again.
I spent last week talking to some of the largest Bitcoin businesses (much bigger than Paymium/Bitcoin-Central or anything anybody in #bitcoin-assets is involved with), and they all want the maximum block size to increase.
The poll in this thread says people support it by a three-to-one margin.
It is going to happen sooner or later. I want it to happen sooner because Very Bad Things will happen if we get to 100% full 1MB blocks:
The poll in this thread says people support it by a three-to-one margin.
It is going to happen sooner or later. I want it to happen sooner because Very Bad Things will happen if we get to 100% full 1MB blocks:
"Very Bad Things?" How nice that our lead dev doesn't believe in BTC's antifragility and subscribes to the 'fix the endangered delicate flower until it breaks' paradigm.
Thanks for confirming my suspicion BloatCoin is being driven by short-sighted VC avarice, which fervently desires Bitcoin usage at every Starbucks, McDonalds, and gas station in order to fulfill its retail POS fetish.
There is no "three-to-one" margin. You don't get to claim agnostic/DGAF as votes to affirm your silly fork, which actually only enjoys 60% support against the negative/status quo default presumption.
In fairness to our code-monkey overlords, most of them are on the right side of this issue:
Quote
sipa → i'm generally in favor of a larger blocksize, but only under the condition that there is a proposal that has extremely wide consensus
wumpus → I'm still not convinced we require a larger blocksize yet
Luke-Jr → wumpus: we definitely don't yet - but it's probably something to be thinking about
gavinandresen → wumpus: how full do blocks need to be before you think we need a hardfork?
wumpus → gavinandresen: all of them full, and a backlog of serious (not spammy) transactions
gmaxwell → gavinandresen: First stop pretending that there actually is consensus or that this is easy and safe. We couldn't even manage to get BIP34 right without two somewhat ugly unexpected effects (we burned the most significant bit of the block version number; and the switchover criteria we implemented wasn't actually the criteria described in the BIP)
wumpus → I'm still not convinced we require a larger blocksize yet
Luke-Jr → wumpus: we definitely don't yet - but it's probably something to be thinking about
gavinandresen → wumpus: how full do blocks need to be before you think we need a hardfork?
wumpus → gavinandresen: all of them full, and a backlog of serious (not spammy) transactions
gmaxwell → gavinandresen: First stop pretending that there actually is consensus or that this is easy and safe. We couldn't even manage to get BIP34 right without two somewhat ugly unexpected effects (we burned the most significant bit of the block version number; and the switchover criteria we implemented wasn't actually the criteria described in the BIP)
Source.
gmaxwell is absolutely correct. You are pretending a consensus exists and in denial of the fact there will be known and unknown trade-offs/risks. You don't get 20MB++ blocks for free. There must be a cost, although no benefit is guaranteed.
I'm busy writing benchmarks, finding bugs in current code, and generally making sure nothing will break when we increase the maximum block size.
Gavin, could you please explain the reason behind trying to guess and hard-code the optimal limit, instead of doing something adaptive, like "limit = median(size of last N blocks) * 10"?
I have a TODO list you could help out with. Although the last time you agreed to help out, Dave, you didn't follow through on your promises (do you remember when you agreed to help with the testnet?).
Am I missing something?
Showing 1 changed file with 3 additions and 3 deletions.
Are you this annoying in person, or just online?
We met IRL in 2011, you have all the data to figure this one out :-)
I spent last week talking to some of the largest Bitcoin businesses (much bigger than Paymium/Bitcoin-Central or anything anybody in #bitcoin-assets is involved with), and they all want the maximum block size to increase.
And how's convincing core devs going? Any luck convincing anyone else than Hearn?
The poll in this thread says people support it by a three-to-one margin.
That's irrelevant, travel to Greece, ask around if the ECB should print more Euros.
Just because a lot of people think X doesn't make X correct.
It is going to happen sooner or later.
No probs, the faster you publish your altcoin's specs, the faster we'll be able to draft contracts allowing the market to short it into the ground.
I want it to happen sooner because Very Bad Things will happen if we get to 100% full 1MB blocks:
I don't think it's such a bad thing if frivolous transactions are discouraged from being burdened onto every full node's hard-drive.
being an annoying troll
I disagree with you, so I'm a troll... Is gmaxwell also a troll?
I have a TODO list you could help out with. Although the last time you agreed to help out, Dave, you didn't follow through on your promises (do you remember when you agreed to help with the testnet?).
Am I missing something?
Gavin gets it wrong. Big deal.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.
Are you this annoying in person, or just online?You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.
I spent last week talking to some of the largest Bitcoin businesses (much bigger than Paymium/Bitcoin-Central or anything anybody in #bitcoin-assets is involved with), and they all want the maximum block size to increase.
The poll in this thread says people support it by a three-to-one margin.
It is going to happen sooner or later. I want it to happen sooner because Very Bad Things will happen if we get to 100% full 1MB blocks:
Quote
At 100% we're up at a huge 7744 seconds (more than 2 hours)! If the network were ever to reach this 100% level, though, the problems would be much worse as 10% of all transactions would still not have received a confirmation after 22800 seconds (6.3 hours).
http://hashingit.com/analysis/34-bitcoin-traffic-bulletinI'm busy writing benchmarks, finding bugs in current code, and generally making sure nothing will break when we increase the maximum block size. If you want to be helpful instead of being an annoying troll, I have a TODO list you could help out with. Although the last time you agreed to help out, Dave, you didn't follow through on your promises (do you remember when you agreed to help with the testnet?).
You're using wumpus' comments to defend your view and I'm asking if there's anything else posted by wumpus to explain those comments. I want to see his reasoning as to why blocks should be full. Your reading skills need fixing.
Not really, AFAIK he didn't post anything.
If you want to hear his stance why don't you just hop on IRC and ask him directly?
Don't back down, R2D221, you're absolutely right. Davout said himself that he thinks bitcoin is "perfect as it is and doesn't need fixing", so he can't then turn around and say he's not supporting a permanent 1mb block. It's not your fault he's a weasel and openly contradicts himself.
I said "it doesn't need fixing".
I didn't say "it'll never need fixing".
Your reading skills, they do need fixing.
If wumpus thinks blocks should be full, then I'd like to see his reasoning. Gavin has outlined his stance with his blocksize economics and scalability roadmap posts. A continuous stream of full blocks isn't something we've tried before and we need to see a really convincing argument to justify attempting it.
Gavin gets it wrong. Big deal.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.
So there's no reasoning or justification? Just an opinion? Thought as much.
Looks like you missed it the first time it was posted: http://fr.anco.is/2015/gavineries/
You're using wumpus' comments to defend your view and I'm asking if there's anything else posted by wumpus to explain those comments. I want to see his reasoning as to why blocks should be full. Your reading skills need fixing.
Don't back down, R2D221, you're absolutely right. Davout said himself that he thinks bitcoin is "perfect as it is and doesn't need fixing", so he can't then turn around and say he's not supporting a permanent 1mb block. It's not your fault he's a weasel and openly contradicts himself.
I said "it doesn't need fixing".
I didn't say "it'll never need fixing".
Your reading skills, they do need fixing.
But some people arguing here do want a permanent 1 MB block.
Which ones?
I don't remember names, and honestly I won't go dig through >130 pages of mostly garbage.
You made the claim, now back it up with evidence.
Or STFU, and stop making strawman arguments.
OK, I made a bad argument. Please disregard it.
Don't back down, R2D221, you're absolutely right. Davout said himself that he thinks bitcoin is "perfect as it is and doesn't need fixing", so he can't then turn around and say he's not supporting a permanent 1mb block. It's not your fault he's a weasel and openly contradicts himself.
Gavin gets it wrong. Big deal.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.
So there's no reasoning or justification? Just an opinion? Thought as much.
Looks like you missed it the first time it was posted: http://fr.anco.is/2015/gavineries/
You still can't give an answer that doesn't amount to "it works for me, so to hell with everyone else":
Does Bitcoin not work for you?
And you have the nerve to talk about bias? If you can't or won't consider the consequences of a 1mb limit to the majority of users, you don't get to lecture about bias. Again, users aren't going to support a network that doesn't confirm their transactions in a timely and secure fashion. Full blocks means either wait for an available block, or go off chain and introduce risk.
Most users don't really care, they'll transact off-chain if it's more convenient. Users that have enough money that justifies taking the paranoid road will always have either enough money to cover the fees, or wait for some space in a block.
Also, I like how you left Mike Hearn's reply out of your earlier post
That's why intellectually honest people give you the sources of their quotes, so you can research relevant context if so inclined.
The reason I didn't quote Hearn is that the point he makes is pretty retarded. Bitcoin won't crash and burn because mempools increase, it's trivial for miners to drop transactions they don't care about, and merchants should not rely on 0-confs anyway.
Also allow me to highlight some interesting bit in Hearn's post:
Quote
If some people say "no it's too risky" and then there are problems, they look prescient and wise and can easily have a told-you-so attitude. And unfortunately then the people who were trying to improve things can easily lose influence and things grind to a halt.
This is a fucking *feature*, if someone pushes for a change, despite being told that it's risky by intelligent people, and fuck up, of fucking course they should lose influence. What would the alternative be? "O, you broke this system despite being told your idea was stupid, please have some more influence" ?
If wumpus thinks blocks should be full, then I'd like to see his reasoning. Gavin has outlined his stance with his blocksize economics and scalability roadmap posts. A continuous stream of full blocks isn't something we've tried before and we need to see a really convincing argument to justify attempting it.
Gavin gets it wrong. Big deal.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.
So there's no reasoning or justification? Just an opinion? Thought as much.
So far no one has given me a satisfactory response to this:
If the userbase increases and blocks are full, the choices are as follows:
- Pay an average fee and still wait for the next available block that isn't full (which will take longer and longer as more users join, even if you pay a fee)
- Pay an above-average fee and hope that it's more than everyone else is paying (and if you don't guess correctly, wait for the next block)
- Go off chain and hope that whoever you trusted doesn't run off with the coins
- Use another coin
Maybe if you actually phrased it like a question it'd be easier to answer.
And it would certainly be easier for the one who answers to show that the assumptions the question is based, are biased.
I've phrased it multiple ways throughout the course of this thread. You still can't give an answer that doesn't amount to "it works for me, so to hell with everyone else":
Because it is my considered opinion that Bitcoin is perfect as it is and that it doesn't need to be "fixed" to provide tremendous value to humanity at large.
And you have the nerve to talk about bias? If you can't or won't consider the consequences of a 1mb limit to the majority of users, you don't get to lecture about bias. Again, users aren't going to support a network that doesn't confirm their transactions in a timely and secure fashion. Full blocks means either wait for an available block, or go off chain and introduce risk.
Also, I like how you left Mike Hearn's reply out of your earlier post about that reddit quote:
Quote
[–]mike_hearn - 14 points - 6 days ago
If all blocks were full and a backlog was building in memory then Bitcoin would be broken. Bear in mind the mempool is unlimited in size. Transactions would stop confirming, nodes would crash and fall over as they accepted ever more pending transactions. That's clearly the wrong time to try and organise a network upgrade. You do it in advance, not as the system is crashing down around us.
Obviously there are risks to any change in a live system. I am not a fan of consensus driven decision making for this reason - it tends naturally towards stasis. The reason is if some people say "no it's too risky", the change is made and things are fine, nobody remembers the objections. The reputation of the naysayers hardly suffers. Everyone is just happy that the improvement happened and wants to move on. If some people say "no it's too risky" and then there are problems, they look prescient and wise and can easily have a told-you-so attitude. And unfortunately then the people who were trying to improve things can easily lose influence and things grind to a halt. "You're not being careful enough with other peoples money" is the sort of argument that socially has a lot of weight, and can quickly result in nobody doing anything because nobody wants to stick their neck out.
This is the story of many large organisations that get big and slow, and given how many years this block size thing has been playing out over, I think it's easy to say it's happening in Bitcoin too.
At any rate, Bitcoin cannot stand still. Usage is growing and failing to tackle that growth will result in either a technical collapse or (another) fork of the software by people who are building companies on the assumption of mass adoption, but whatever happens stasis will not be it. I think everyone understands that, and Gregory just said in IRC he thinks 1mb is too small. So it turns into a debate about how long we can wait for, exactly, and what has to come first, which is rather different to how you are portraying things.
If all blocks were full and a backlog was building in memory then Bitcoin would be broken. Bear in mind the mempool is unlimited in size. Transactions would stop confirming, nodes would crash and fall over as they accepted ever more pending transactions. That's clearly the wrong time to try and organise a network upgrade. You do it in advance, not as the system is crashing down around us.
Obviously there are risks to any change in a live system. I am not a fan of consensus driven decision making for this reason - it tends naturally towards stasis. The reason is if some people say "no it's too risky", the change is made and things are fine, nobody remembers the objections. The reputation of the naysayers hardly suffers. Everyone is just happy that the improvement happened and wants to move on. If some people say "no it's too risky" and then there are problems, they look prescient and wise and can easily have a told-you-so attitude. And unfortunately then the people who were trying to improve things can easily lose influence and things grind to a halt. "You're not being careful enough with other peoples money" is the sort of argument that socially has a lot of weight, and can quickly result in nobody doing anything because nobody wants to stick their neck out.
This is the story of many large organisations that get big and slow, and given how many years this block size thing has been playing out over, I think it's easy to say it's happening in Bitcoin too.
At any rate, Bitcoin cannot stand still. Usage is growing and failing to tackle that growth will result in either a technical collapse or (another) fork of the software by people who are building companies on the assumption of mass adoption, but whatever happens stasis will not be it. I think everyone understands that, and Gregory just said in IRC he thinks 1mb is too small. So it turns into a debate about how long we can wait for, exactly, and what has to come first, which is rather different to how you are portraying things.
If wumpus thinks blocks should be full, then I'd like to see his reasoning. Gavin has outlined his stance with his blocksize economics and scalability roadmap posts. A continuous stream of full blocks isn't something we've tried before and we need to see a really convincing argument to justify attempting it.
Gavin gets it wrong. Big deal.
You know, there's a reason in business, why it's usually not the code-monkeys who get to make strategic decisions.
So far no one has given me a satisfactory response to this:
If the userbase increases and blocks are full, the choices are as follows:
- Pay an average fee and still wait for the next available block that isn't full (which will take longer and longer as more users join, even if you pay a fee)
- Pay an above-average fee and hope that it's more than everyone else is paying (and if you don't guess correctly, wait for the next block)
- Go off chain and hope that whoever you trusted doesn't run off with the coins
- Use another coin
Maybe if you actually phrased it like a question it'd be easier to answer.
And it would certainly be easier for the one who answers to show that the assumptions the question is based on, are flawed.
Jump to: