Topic: 2MB Pros and Cons - page 8. (Read 9735 times)
Fear not madjules007 I will copy and paste your post into ever block size debate thread going forward followed by "TLDR- holy war"
Hark fork is not a con. bitcoin has hard forked several times. Many altcoins have hard forked to change features. If you give a few months notic, there is no problem.
There seems to be an unhealthy amount of confusion over the implications of a hard fork, particularly one that is controversial.
There has never been a planned hard fork in bitcoin. The 2013 hard fork was a crisis situation with unanimous consent and agreement on how to move forward. That is very, very different from the current situation, where the community is divided against itself.
Any speculation on how it will play out is just that -- pure speculation. The success of a hard fork is primarily dependent on network nodes upgrading, not hashpower, as the issue is "validity" and not "the longest chain."
And any data we have in that regard is extremely opaque. Reachable nodes =/= all nodes. Many people run in listen-only mode; they are not reachable, but they do depend on their node to validate transactions. This incomplete information is made further incomplete when we consider that a proportion of Classic and XT nodes are pseudonodes that do not support a future hard fork's consensus rules.
The biggest problem is that users will lose money if there is any hashpower left on the original chain. That includes the situation where the hashpower went to zero at one point, and therefore an attack scenario where a miner exploits "old" nodes who cannot see the new, invalid fork that most miners are building on. One might expect those nodes to see no new blocks, a dead chain. Since there was never an upgrade to their software (because the fork was contentious), they are in the dark. Even if all honest miners left the minority chain, an attacker could (particularly after difficulty readjustment) build a fake chain confirming payments several blocks deep to a user, merchant, etc. This could work particularly well against an automated system in the latter situation. Since the payment is confirmed below significant proof-of-work, the merchant releases the goods, only to have the the inputs he received double-spent shortly after, since most or all of the hashpower on the network is owned by the attacker.
That's if all miners move to the new chain. What if they don't? The less hashpower left on either chain, the more at risk users of either chain are to double-spend attacks. This problem is compounded by the game theory proposition that a miner stands to increase his relative hashpower on the minority chain by a function of the hashpower that is mining on the majority chain. A miner may take a calculated risk to do so, based on his information about which chain most nodes recognize as valid and therefore which chain most users are using. I.e. if most miners temporarily point their hashpower at the new fork, then realize that most nodes did not change their consensus rules, what do you think they will do? Many will return to the original chain.
As I've said in the past:
Quote
Miners are at the whims of nodes. Running an ASIC farm doesn't give you any rights over what node software I run. And an army of nodes enforcing bitcoin's rules is here to tell you that they do not give a shit about the opinions of miners. We have our own interests to worry about.
Consider a situation where the majority of hashpower is mining under the new consensus rules, while the majority of nodes are enforcing the old consensus rules. Before immediately shooting that down with "but economic majority!" I think there has been very little evidence offered that miners temporarily pointing their hashpower at another chain will force all or even most network nodes to "upgrade" to the new rules. Many operators of "old" nodes won't even notice that a fork occurred -- the only reason they might notice (if unaware of all the reddit/bitcointalk drama) is that confirmation times will take longer than usual until the next difficulty readjustment (due to reduced hashpower on their chain), at which point everything returns to normal. The invalid chain goes unnoticed because it is invalid.
The result? Mass confusion. Users making irreversible payments to other peers, merchants, etc. who may not receive said payments on what they consider to be the "valid" blockchain. Once newly minted coins on the respective chains are circulated into their networks and are sufficiently mixed with old inputs, this would become the everyday expectation. Exchanges and brokers that allow the sale of bitcoin may be open to fraud lawsuits if they deliver "invalid" coins to customers on an "invalid" blockchain. Incompatibility across the entire network(s) and the lack of wallet software that can distinguish for users which blockchain their inputs are valid on, will lead to chaos. In the end, all versions of bitcoin will probably plummet in value, given the difficulty in using it, the lack of clarity of what bitcoin even "is" anymore, and the corresponding erosion of all trust in the protocol. I doubt bitcoin could ever recover from this basic failure of its reason for existing (the decentralized enforcement of rules to trustlessly store and transfer value)
The biggest losers, of course, will be SPV users. SPV protocols are so lacking that users have no way of knowing which chain and rule set the nodes they connect to are following. One time, they may be connecting to an "old" bitcoin node. The next time, they may be connecting to a forked node. An SPV user does not know the difference; he will simply send his transaction to anybody that will accept it. But that transaction may be valid on one, but not the other chain. The question then becomes, which chain was the recipient expecting payment on? The SPV user has no control over that.
Consider these dangers, and then compare to a soft fork:
In a soft fork, partitioning will only happen if miners supporting the new rules drops below 50% (hence activation at 95%). Non-mining nodes (most of the network, particularly when extended to all the SPV nodes that connect to them) need not upgrade, since the new, more restrictive rules are backwards compatible with the old, less restrictive rules. As long as > 50% of miners are supporting the new rules, no one gets forked off.
A minority miner could include invalid transactions based on the new rules, but as long as a majority of hashpower agrees on the new rules, it won't be confirmed and the block will be rejected. So non-upgraded (and therefore SPV nodes, depending who they connect to) could be at risk of seeing invalid transactions that will not confirm. Of course, no one should ever trust an unconfirmed transaction to begin with (we have short chain forks on a regular basis) even without considering possible attacks.
Okay let me try to play devil's advocate and give a pro.
Pro: less reliance on side chains to handle micro transactions.
I think this is a pro because I don't trust side chains to much, I just don't trust them. I don't know a whole lot about them but I fear if just a few of them are successfully attacked that the trust in all of them could be lost and it would reflect back on Bitcoin poorly. I think average users will wrongly assume side chains will be just as safe as the main chain and this could cause a great deal of confusion if side chains start dropping like flys.
Pro: less reliance on side chains to handle micro transactions.
I think this is a pro because I don't trust side chains to much, I just don't trust them. I don't know a whole lot about them but I fear if just a few of them are successfully attacked that the trust in all of them could be lost and it would reflect back on Bitcoin poorly. I think average users will wrongly assume side chains will be just as safe as the main chain and this could cause a great deal of confusion if side chains start dropping like flys.
He was blowing me off so I pushed the point I think its a certainty but I only wanted him to consider the possibility. I will consider larger blocks becoming one day a necessity but its not a certainty.
If were going to make a list of pros and cons that have to be certainties then it would be a very short list.
We should consider the possibility the user base might shrink.
If were going to make a list of pros and cons that have to be certainties then it would be a very short list.
We should consider the possibility the user base might shrink.
every point i make include something like "if" "may" or "could".
No... I honestly "hand of god" don't think its a marginal risk at all, I think its a certainty.
Except that one, right?
I'm suggesting possibilities
About the future, which involves making predictions. Stop playing semantics.
I'm suggesting possibilities you on the other hand "Larger blocks will become a necessity" are making statements as if they are fact immutable forever.
And I'm allowed to think and say it's a certainty, just like you did earlier. That's why the OP is frequently updated to include only the most neutral wording, so everyone can have their say without any one opinion drowning out the others. Can we get back on topic now, please?
CON: if the user base ever shrinks it will put a unnecessary burden on a smaller user base.
Shrinking user base... I understand thats the plan of small blockers, or at least dont allow increase Bitcoin user base.
But it is just limit, not actual block sizes. Few years ago block size limit was 1 MB and miners created small blocks like 100 KB. Now if there was 5 MB limit instead of 1 MB since 2011, guess what? The Bitcoin blockchain size would be the same as today, around 60 GB.
Most people still dont get it is just limit, which by definition can only limit the number of people which can use Bitcoin.
You joined 6 months ago Welcome to the pit
I'm worried about network latency, future users and holy wars, I'll agree I'm a tin foil hat nutter but I want to grow the Bitcoin user base just as much as everyone else here.
CON: if the user base ever shrinks it will put a unnecessary burden on a smaller user base.
Shrinking user base... I understand thats the plan of small blockers, or at least dont allow increase Bitcoin user base.
But it is just limit, not actual block sizes. Few years ago block size limit was 1 MB and miners created small blocks like 100 KB. Now if there was 5 MB limit instead of 1 MB since 2011, guess what? The Bitcoin blockchain size would be the same as today, around 60 GB.
Most people still dont get it is just limit, which by definition can only limit the number of people which can use Bitcoin.
every point i make include something like "if" "may" or "could".
I'm suggesting possibilities you on the other hand "Larger blocks will become a necessity" are making statements as if they are fact immutable forever.
Please stop insinuating you can predict the future; Bitcoin may become unpopular we could lose a huge chunk of our user base; what then? With all that free unused block space just sitting around spam attacks will put a unneeded burden on a smaller community that no longer need large blocks.
*complains about people trying to predict the future*
*proceeds to immediately make a negative prediction about the future in the very next sentence*
Seriously?
I'll stop being worried about the future when I see a scalability roadmap I agree with. You just worry about the code you're choosing to run and not forcing your opinion on everyone.
CON: if the user base ever shrinks it will put a unnecessary burden on a smaller user base.
franky your analogies are the worst.
DooMAD unless your fucking Psychic stop trying to predict the future.
franky your analogies are the worst.
DooMAD unless your fucking Psychic stop trying to predict the future.
If increase block size to 2MB is difficult because it requires hard fork and it won't be final solution, why don't increase block size to bigger size so we don't need another hard fork because i'm sure hard fork will be harder because bitcoin'll be more popular and it means more miners, pool, company and so on.
Hard froks aren't necessarily bad. There's even a school of thought that suggests we ought to be doing them at regular intervals.
@Lauda please respond to my post in context. It's clearly not the same thought after you cut it up like that and totally miss the point?
they way i see it. bitcoin can be analogicaly like Iphone.
softforks are like random OS updates, where somepeople get great new apps to use if they update
hardforks are like new generation iphones. and if you dont upgrade every two years you are no longer in fashion and ridiculed because your hanging on for life to outdadted crap.
if we were to make it a regular thing. like the date of it happening linked to the reward halving or every 110,000 blocks. then people can be aware and prepare for it.
even now just 1 month before april we still dont know if segwit is going to be ready and if blockstream will include the buffer or not.. even after a couple roundtables there is still uncertainty. so making it planned an organised.helps.. instead of delayed then suddenly rushed.
after all, if apple can release a new product every couple years without worrying about the old one, knowing milions of people will use it.. i certainly think 6000 people using bitcoin out of 2million shouldnt be much different. . aslong as its not delayed or not made official until the last minute
Please stop insinuating you can predict the future; Bitcoin may become unpopular we could lose a huge chunk of our user base; what then? With all that free unused block space just sitting around spam attacks will put a unneeded burden on a smaller community that no longer need large blocks.
You can't have micro transactions and good spam protection at the same time. You have to pick one.
Yawn. It's been stated enough times by now that everyone's bizarre fixation over microtransactions is just deflecting the issue:
People tend to make the assumption that a larger blocksize would encourage more microtransactions or other transactions sent without a fee. To an extent, that's possible (but not a certainty by any means), so there is a balance to be struck to ensure there is space enough for legitimate fee-paying transactions, but not so much space that most of the traffic being processed doesn't give any reward for the miners securing the network. 1MB almost certainly isn't enough, but how much is too much? That's where most of the discourse seems to focus, and rightly so.
Third party layers should be strictly reserved for micropayments and transactions that don't include a fee. And as much as small block proponents obsess about micropayments, they really aren't the issue. Even after they're swept under the carpet, Bitcoin still needs to support more than two-thirds of a floppy disk every ten minutes. If it doesn't, something else will.
Just about every single opponent of larger blocks is completely fixated on micro-payments and thinks that once those are swept under the carpet that the scalability issue is magically solved forever. That's just plain wrong. Larger blocks will become a necessity as the usage increases and prolonging the inevitable is only going to result in more disruption later.
Please. Stop. Whining. About. Microtransactions.
LN are fine for micro transactions but I won't be using them anytime soon.
You may not be, but people who want to make micropayments likely will be.
If you don't want LN and don't want fees that keep spammers out, there's always Doge...
Fair point but were suppose to be talking about 2mb blocks not the LN; they are fine for micro transactions but I won't be using them anytime soon.
You can't have micro transactions and good spam protection at the same time. You have to pick one.
As for sigwit causing 4mb blocks that's not true they will be adding limiters into the code to prevent that.
Con: less spam protection.
As for sigwit causing 4mb blocks that's not true they will be adding limiters into the code to prevent that.
Con: less spam protection.
Yes you can - LighteningNetwork.
The LN may get spammed but the blockchain won't be spammed.
You can't have micro transactions and good spam protection at the same time. You have to pick one.
As for sigwit causing 4mb blocks that's not true they will be adding limiters into the code to prevent that.
Con: less spam protection.
As for sigwit causing 4mb blocks that's not true they will be adding limiters into the code to prevent that.
Con: less spam protection.
he statement makes it sounds like changing the system to support 2MB blocks would cause miner transaction fees to increase regardless of the actual size of the block.
Exactly. We can't really know that the amount of fees will get increased. It is just an assumption I guess. Perhaps the wording should read:
"4) More fees potentially collected by miners on each block"
Not sure that even is true, as smaller block can result in higher fees.
I actually want the fees to remain high enough to make spamming the blockchain expensive. And I want the block small enough that if someone is willing to pay to spam the blockchain, it won't grow fast enough to reduce what decentralization there is.
E.g. could a corporate interest pay to spam the block such that it consistently has 16 MB blocks knocking a lot of miners out so that the corporate interest can seize control of the blockchain in their data center ?
With 2 MB blocks I don't think that specific fear exists, but at some point it does exist.
It all depends on the traffic we're getting at any given moment. Any time that transactions would currently be left in the mempool queue waiting for a non-full block, those transactions and their fees could then be processed, so, in theory at least, the fees collected in that block will then be higher. More traffic equals more fees in total.
he statement makes it sounds like changing the system to support 2MB blocks would cause miner transaction fees to increase regardless of the actual size of the block.
Exactly. We can't really know that the amount of fees will get increased. It is just an assumption I guess. Perhaps the wording should read:
"4) More fees potentially collected by miners on each block"
Not sure that even is true, as smaller block can result in higher fees.
I actually want the fees to remain high enough to make spamming the blockchain expensive. And I want the block small enough that if someone is willing to pay to spam the blockchain, it won't grow fast enough to reduce what decentralization there is.
E.g. could a corporate interest pay to spam the block such that it consistently has 16 MB blocks knocking a lot of miners out so that the corporate interest can seize control of the blockchain in their data center ?
With 2 MB blocks I don't think that specific fear exists, but at some point it does exist.
Jump to: