Topic: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) - page 18. (Read 14409 times)

That's just silly hysteria. You should be made aware that BU blocks have been mined into the main Bitcoin blockchain for over a year now.

Maybe you can help to dispel some commonplace FUD about the sigops DDoS attack.

Bitcoin already has a sigops per block limit to mitigate the risk of this attack (despite the FUD that introducing such a limit is all that's needed to solve the problem, which is pretty dumb considering that's already what happens )




Now, surely this limit could continue to apply to the base 1MB block _after_ segwit is activated (which can only contain sigs from non-segwit transactions)? Is this how the fork is coded anyway?

Core would not because they're all convinced we must have segwit before increasing the block size to prevent a quadratic scaling sigop DDoS happening... though segwit doesn't change the sigops included in regular transactions, it only makes segwit transactions scale linearly which is why the blocksize increase proposal is still not on the hard roadmap for core as is. If block generation is biased against heavy sigop transactions in the core code (this does not need a consensus change, soft fork or hard fork) then pool operators would have to consciously try and include heavy sigop transactions intentionally in order to create a DDoS type block - would they do that? Always assume that if a malicious vector exists then someone will try and exploit it, though it would be very costly for a pool to risk slow block generation/orphanage by doing so.

firstly core bypassed community consensus using bip9 by going soft..


secondly read bip 9, yep it can be changed. even gmaxwell admits this.

^ this is where the UASF comes in (A leads to B leads to C)

secondly you personally know about banning nodes. you have often highlighted yourself as the guy with all the 'know' of the node IP's everyone should ban

its not rocket science

I agree with this and for some reason the community is blind to it.
There seems to be a denial and slight delusion about all this.
This is mainly why I have come to the unfortunate conclusion that a hardfork to
attack or to split the community is not far off now. We are just chasing the tail.

Also, I'm sure if the ETF is denied on Friday, Core supporters and BU supporters
will blame the other, and if accepted (which IMO is not likely) each side will take
the credit. The point being that those two sides are locked into perpetual hate.

It most likely will not work. As I have outlined in a recent post, there are too many different and "entrenched" camps.

We can even expand on this. There are people that think 51% of hashrate (node percentage is irrelevant) is adequate for a hard fork as an upgrade, and there are those who think that 100% is required. Both of these ideologies are absurd.

I do have to add that, while I think that it would be still extremely hard to gather 90-95% consensus on both ideas, I think both would reach far higher and easier support than either Segwit or BU.

Core can not stop community/miner consensus. Let me see a viable BIP + code first, then we can talk about that.

I have read DooMAD's proposal now and I like it a bit. It would give less powers to miners as they only can vote for small block size increases, but would eliminate the need for future hardforks. The only problem I see is that it could encourage spam attacks (to give incentives to miners to vote higher blocksizes) but spam attacks will stay as expensive as they are today will be even more expensive than today because of the "transaction fees being higher than in last period" requirement, so they are not for everyone.


That certainly sounds like a good idea, if the community decides to support this proposal. Would Core allow to activate that kind of compromise proposal coded into a real pull request?

No Offense but if you truly believe what you just said, You should sell every crypto coin you own and stick with cash.
You are too timid for this environment.


 

No hard fork please, you know the price crashed due to Chinese Antpool mined BU block? Hard fork will 100% kill bitcoin, or hazard the price.

When you get a transaction stuck on the chain for days on end with the standard fee and you have a two to three hour window to lock in a rate on a Bitcoin exchange to convert to fiat.
Yep BIP102 most certainly will start acquiring more support from the average users.

On the topic of compromise if people can get the support to do this scaling compromise then sure lets go with it.
In the end as long as the block-size rises in the short term we can keep kicking the bucket and that works for now.

While were at it someone could make a MSR on what Bitcoin's operating requirement is for the Chinese miners.

I worry that a scaling compromise may be just perpetual kicking  of the can and if we can't even kick the can we may really just end up with two chains.
A hard-fork may be the only way we will see consensus, as the capabilities and requirements where the miners are located is part of the current issue and a stakeholder mandate is needed not just a miner one.
https://randomoracle.wordpress.com/2016/01/25/observations-on-bitcoins-scaling-challenge/



I agree no one would want to do a purposeful hardfork if it can be resolved with a soft-fork but someone would at least try to get a general feel of the best solution in the case that a hardfork is the resulting outcome.

As you pointed out there are two clear development paths.

 - BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
This is to bring about a more currency like device now, instead of later.
They do not mind network centralization or do deny/ignore its possibility of occurrence.

 - CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).
This is to maintain the unregulatibility and other like aspects now and later.
They do not mind slowed user growth or high fees or do deny/ignore their possible impacts.

Whether it becomes two over one and we see a bi-lateral hardfork is what the real question is.


(Mumble sometimes someone bumps an old post and necros but this one is relevant to today)
https://bitcointalksearch.org/topic/whats-with-this-odd-generation-48

For the sake of clarification for users who wish to know what I was referring to,
it would be a "controversial hardfork". Node banning due to a majority of miners
being out of consensus does not matter, since those miners are intentionally leaving
the node network for good to create a chain that will directly fight with the old (replays).
In a sense, it is like dragging the old network with it. It would be a test in whether
network follows hash or the hash follows the network.

No one would want to do a purposeful bilaterial hardfork since then there will be time to
protect against such an situation and economies will be able to choose one or the other.
Bilaterial fork is when two parties agree to disagree. A controversial hardfork is by its
nature malicious since it will cause issues if performed correctly.

The real difference is that one is programmed to split and the other is an accidental split
that is purposefully attempting to maintain an invalid chain to the point in which it may
become a valid chain. In this event, malicious miners could in theory, with enough hash,
continue indefinitely, never needing to provide forewarning, like a bilaterial.

A controversial hardfork is malicious. A Bilateral hardfork in theory, is not.

side note for you both,
"malicious forking"
many people are over using umbrella terms. of "forking"

try to stick with clear definitions (even im using gmaxwells buzzwords to keep things clear(so even he cant poke the bear))

EG soft = pools move without node
EG hard = node move and pools follow

consensus = if its near unanimous agreement(few orphans orphans now and again but one chain)
controversial = if its arguable low agreement (lots of orphans before it settles down to one chain)
bilateral split = intention avoidance of consensus/orphans/opposition (an altcoin creator with second chain sustaining life)

---

now then
segwit is in essense a soft consensus.
segwit has 2 parts. although pools change the rules without nodes consent. segwit has other things. like changing the network topology (FIBRE) so that they are upstream (central/top close to pools) able to translate and pass downstream block data in a form nodes can consent to/accept.

however putting segwit aside and looking at bip9 which is how pools were given the vote. a soft bilateral split can happen
bip9 allows
soft(pool) BILATERAL SPLIT

in essence ignoring opposing pools where by those other pools still hash
which can lead to:
a split of 2 chains where they continue and just build ontop of THEMselves, or
they give up and find other jobs, or
they change software and join the majority

---

totally different bip not even in any bitcoin version right now..
hard(node and pool) BILATERAL SPLIT
new UASF does this. (although the buzzword is meant to make it sound easier by stroking the sheep to sleep by pretending its a "soft" (S of UASF)fix. but because its node caused. its hard)

because it involves intentionally rejecting valid blocks purely based on who created it. it leads to the pool:
split of 2 chains where they continue and just build ontop of THEMselves, or
they give up and find other jobs, or
they change software and join the majority.

however because nodes are doing this. it can cause further controversy(of the nodes not pools) because the nodes are then differently selecting what is acceptable and hanging onto different chains

which is where UASF is worse than hard consensus or hard bilateral due to even more orphan drama

I see your point about malicious forking. At this point I need others view points to consider.

That doesn't matter. Miners can fork away without node validators
and the minority hash chain's difficultly will be too high (and may not
adjust in time to prevent possible failure). Meanwhile the Miner nodes
are on a new chain, mining & semi validating away. The minority hash
chain, could in short time, have no hash at all, in theory.

Your statement only applies if there is no malicious forking.
When the two node systems split, this possibility came into existence.
Prior to this, they always moved as one, since there was only one.

But non mining nodes are the majority of the network. Miners have to produce blocks that follow the network consensus or they get orphaned. Hard fork consensus means nodes update first, miners follow.

No, you missed my point. I thought it was more evident.
Non-mining nodes are not incentivized the way Miners Nodes are.

The point being:
both can have opposite votes now (two sides), instead of the vote
always tending toward the same incentivized choice by Hardfork.
Now there are more possibilities such as Softforks. (User activated
fork is now another one, but is a new theory which is riskier than
either soft or hard.)

All I'm saying is when you cite Satoshi about Nodes, it was before
the Node split and is entirely in a different context that no longer
exists.

Changing MAX_BLOCK_SIZE to 2MB + segwit literally means we will see 4-8MB blocks.

No thanks ,

I don't care is this HF proposal comes from core or another repo , I will reject it and stay on the original chain. Developers have no power over what software I choose to run .

4-8MB blocks is too big and I am only interested in HF that include many HF wishlist items and permanently solve the scaling problem instead of kicking the can down the road a few months.


Here are some academic papers that reflect how dangerous blocks over 4MB currently are and one reason why segwit limits blocksizes to 4MB max.

http://bitfury.com/content/5-white-papers-research/block-size-1.1.1.pdf

http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf

This is a dangerous precedent giving control to miners or developers without community consensus. Hard forks should be a matter of last resort and when a SF is on the table that offers the same essential blocksize increase as classic we should be greatful and take it instead.

There is significant moral hazard and social hazard in forcing a HF on the community and how that will make us all insecure in the future. If the Developers or miners are viewed as a group that is perceived they can change the protocol without overwhelming consensus of the bitcoin users than they can easily be manipulated and attacked by bad actors like states and others.

There will guarantee be a split where 2-3 coins exist for one thing which will cause short term havoc due to uncertainty, loss of immutability , breaking the 21 million limit promise, moral hazard , social hazard, ect...(Remember Bitcoin is actually used for things unlike Ethereum which is 100% speculation, thus a split is far more damaging to bitcoin)

The ETF follows the most worked chain only, thus if the miners are swayed back to the originally chain after many of us dump our split coins all those ETF investors lose their investment value.

4-8MB blocks will lead to centralization, increase miner and node centralization and force me to shutdown my personal node.

your putting words into people mouths.

1. Bu/bigblockers dont want one brand running anything... most bu/bigblockers are happy with bitcoinj, xt, classic, btcd, etc all running on the same level playing field all using real consensus to come to agreement.. and if core got rid of blockstream corporation. would be happy with core too.(main gripe is blockstreams centralist control)

2. small blockers have shown distaste for anything not blockstream inspired/funded..  (rekt campains agains bitcoinj, xt, classic and bu)

3. correct(people keep funds on thier personal privkeys and use future LN services voluntarily)

4. correct(people move funds to new keys and multisigs where payments need an LN counter party signing. but done forcefully due to politics/fee war games)

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.