[POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)

[AngryDwarf]

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

[1713259929]

1713259929

[1713259929]

1713259929

[1713259929]

1713259929

[franky1]

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

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

BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% under the old approach.  basically when it activates, the 95% will have to be willing to potentially orphan the blocks of the 5% that remain
If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

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

[AgentofCoin]

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

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)
...

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.

[kiklo]

I have read this compromise proposal from "ecafyelims" at Reddit and want to know if there is support for it here in this forum.

Compromise: Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF)

Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) into a single HF (with overwhelming majority consensus).

Since Segwit changes how the blocksize is calculated to use weights, our goal with the merger would be 2MB of transactional data.

Segwit weighting system measures the transaction weight to be 3x(non-witness base data) + (base data with witness data). This weight is then limited to 4M, favoring witness data.

Transactions aren't all of base or witness. So, in practice, the blocksize limit is somewhere between 1MB (only base data) and 4MB (only witness data) with Segwit.

With this proposed merger, we will increase Segwit weight limit from 4M to 8M. This would allow 2MB of base data, which is the goal of the 2MB HF.

It's a win-win solution. We get 2MB increase and we get Segwit.

I know this compromise won't meet the ideals of everyone, but that's why it's a compromise. No one wins wholly, but we're better off than where we started.

It's very similar to what was already proposed last year at the Satoshi Roundtable. What is the opinion of the Bitcointalk community?

Guy, there is No Compromise , no matter how , if Segwit is Activated the Miners are Fucked.
Segwit allows LN to function without Trust and will allow LN to Steal Transactions Fess directly from the miners.

There is No Compromise Possible as long as they want Segwit.

 

FYI:

LN Does Needs Segwit so that LN can be trust less.
Otherwise LN requires a separate Trust system in place or very long extensive Time Locks , Both of which LN Devs don't want.

https://www.reddit.com/r/Bitcoin/comments/5eqm2b/can_ln_work_without_segwit/?st=izzovrzk&sh=b2fe8b0a

Yeah you can do LN without segwit. It's less efficient, and there are some features you won't be able to do.

With segwit, you can have a 3rd party "watch" your channel for you in case your counterparty tries to broadcast an old, fraudulent transaction.
The 3rd party can automatically grab your money back for you. And the watcher doesn't even know about your transactions or your balances while watching.

That whole feature is pretty much gone without segwit.
You'd have to tell the watcher everything about your channel, and the only thing they'd be able to do is e-mail you to let you know if fraud occurred.

The other main disadvantage to segwit-less LN is that channels would have a preset duration. That's a pretty big downside.

If segwit doesn't activate after a long time, we could re-program some of the current code to work without segwit.
I think everyone's hoping we don't have to as that'd be a bit disappointing, but doable.
As I meme'd at scaling HK, there are levels of LN we are prepared to accept

In Short , without Segwit any version of LN is going to be Crap and No threat to the Miners at all.  

FYI2:
Bitcoin Unlimited Fixes the issue for good without segwit, Nothing else needs to happen.

BTC Core Devs placed their own personal interests in front of BTC performance , they have to be fired as they can no longer be trusted.
Segwit is a Trojan, once activated it can never be removed from the blockchain.

https://www.reddit.com/r/btc/comments/5vbofp/initially_i_liked_segwit_but_then_i_learned/

You wanted people like me to support you and install your code, Core / Blockstream?

Then you shouldn't have a released messy, dangerous, centrally planned hack like SegWit-as-a-soft-fork - with its random, arbitrary, centrally planned, ridiculously tiny 1.7MB blocksize -
and its dangerous "anyone-can-spend" soft-fork semantics.

Now it's too late. The market will reject SegWit - and it's all Core / Blockstream's fault.

The market prefers simpler, safer, future-proof, market-based solutions such as Bitcoin Unlimited.

The damage which would be caused by SegWit (at the financial, software, and governance level) would be massive:

    Millions of lines of other Bitcoin code would have to be rewritten (in wallets, on exchanges, at businesses) in order to become compatible with all the messy non-standard kludges and workarounds which Blockstream was forced into adding to the code (the famous "technical debt") in order to get SegWit to work as a soft fork.

    SegWit was originally sold to us as a "code clean-up". Heck, even I intially fell for it when I saw an early presentation by Pieter Wuille on YouTube from one of Blockstream's many, censored Bitcoin scaling stalling conferences)

    But as we all later all discovered, SegWit is just a messy hack.

    Probably the most dangerous aspect of SegWit is that it changes all transactions into "ANYONE-CAN-SPEND" without SegWit - all because of the messy workarounds necessary to do SegWit as a soft-fork. The kludges and workarounds involving SegWit's "ANYONE-CAN-SPEND" semantics would only work as long as SegWit is still installed.

    This means that it would be impossible to roll-back SegWit - because all SegWit transactions that get recorded on the blockchain would now be interpreted as "ANYONE-CAN-SPEND" - so, SegWit's dangerous and messy "kludges and workarounds and hacks" would have to be made permanent - otherwise, anyone could spend those "ANYONE-CAN-SPEND" SegWit coins!

    Segwit cannot be rolled back because to non-upgraded clients, ANYONE can spend Segwit txn outputs. If Segwit is rolled back, all funds locked in Segwit outputs can be taken by anyone. As more funds gets locked up in segwit outputs, incentive for miners to collude to claim them grows.

[freedomno1]

Code them up together, but allow each component to be activated *separately* thus allowing clients to choose which component they wish to support... I suspect support for BIP102 will be a lot higher now (yes I know about quadratic scaling issue.)

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/

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.

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://bitcointalk.org/index.php?topic=48.0

[Anon TumbleBit]

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.

[kiklo]

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.

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.


 

[d5000]

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.

Code them up together, but allow each component to be activated *separately* thus allowing clients to choose which component they wish to support... I suspect support for BIP102 will be a lot higher now (yes I know about quadratic scaling issue.)

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?

[Lauda]

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

There are a lot of different "camps":
1) BU only.
2) Core only.
3) Soft-fork only.
4) Hard-fork only.
5) Only block-size increase.
6) Only block-size decrease.
7) No hard-fork at any cost.
8.) Other?

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 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.

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.

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

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

[AgentofCoin]

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

There are a lot of different "camps":
1) BU only.
2) Core only.
3) Soft-fork only.
4) Hard-fork only.
5) Only block-size increase.
6) Only block-size decrease.
7) No hard-fork at any cost.
8.) Other?

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 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.

[franky1]

Core can not stop community/miner consensus.

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

Let me see a viable BIP + code first, then we can talk about that.

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

BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% (C) under the old approach.  basically when it activates, the 95% will have to be willing to potentially orphan the blocks of the 5% that remain(B)
If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.(A)

^ 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

[-ck]

Code them up together, but allow each component to be activated *separately* thus allowing clients to choose which component they wish to support... I suspect support for BIP102 will be a lot higher now (yes I know about quadratic scaling issue.)

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?

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.

[Carlton Banks]

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.

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?

[jbreher]

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.

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.

[jonald_fyookball]

Forgive me if i'm a bit skeptical that segwit is a good idea.  It sounds very complicated and
that once we do it, we'll be stuck with it.

I thought it was initially promoted as a way to avoid a hard fork but if we're going to
be forking to 2MB anyway, what is the point?

[AngryDwarf]

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.

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.

It's just a flag added to the block to show whether the pool is voting for segwit or BU, nothing more. The blocks are exactly the same otherwise as far as I know.

[jbreher]

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.

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.

It's just a flag added to the block to show whether the pool is voting for segwit or BU, nothing more. The blocks are exactly the same otherwise as far as I know.

Well, yes. I was just illustrating how hysterical the notion that "the price crashed due to Chinese Antpool mined BU block" was.

[franky1]

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 )

cores limit is not low enough

MAX_BLOCK_SIGOPS_COST = 80000;
MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

who the damned F*ck should be allowed to build a single tx that uses 20% of a block!!
who the damned F*ck should be allowed to build a single tx has 16,000 sigops!!

lower the TX sigop limit to something rational and you wont have the worry of delays due to sigop validation

also. one thing CB is missing out on

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

meaning native transaction users can still sigop SPAM.
segwit has nothing to do with disarming the whole block.. just segwit transaction users

again because carlton is not quite grasping it

though segwit doesn't change the sigops included in regular transactions,

[Lauda]

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

No.

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

Banning nodes is completely fine.
Anyone ready for the altcoin called BTU?




https://twitter.com/zaifdotjp/status/839692674412142592
https://twitter.com/SatoshiLite/status/839676935768715264

[Carlton Banks]

apparently, Sigop DDoS attack is possible now, because the Sigops per block limit is too high.


Why isn't anyone using the attack then?

Always assume that if a malicious vector exists then someone will try and exploit it