Proposal Support

[DooMAD]

but if you can't get behind it (or any of the other proposals) because of your views on the "1 merkle block where all keypairs sit side by side in same area" part, you're just going to isolate yourself.  You have to recognise the main trend in this thread so far, which is that everyone else who has posted has, in some form or another, expressed support for SegWit.  I don't mean to be blunt, but, regardless of your feelings towards it, there's too much momentum behind the idea for you to obstruct it.  With the possible exception of extreme ossification and stagnation where this debate never ends, the only outcome moving forward is one that includes SegWit.  Either accept that, or find yourself moving (of your own volition) to the fringes where your voice won't be heard.  

you do realise that segwit can actually be done in a 1 merkle block..

Yes, you've made that abundantly clear from the dozens of posts you've made on that particular subject.  We get it.  We really do.  But that's not the point, though.  What's happening is that you're allowing your insistence on this particular detail to alienate those around you.  The point is, it doesn't have to be perfect in the eyes of everyone, or more to the point, it can't, because that's impossible.  Consensus doesn't work that way.  It just has to be "good enough" for a significant proportion of users to agree with it.  So far this thread seems to indicate a two-merkle SegWit is indeed "good enough", so each time you draw the line there, you find yourself further out of step with what almost everyone else is deeming to be acceptable. 

Fight the battles you have a chance of winning instead of marginalising yourself like that. 

Sure, I'd prefer adaptive over fixed blocksize, but I'm not going to dig my heels in, take my ball and go home if I can't get that.  Because it achieves nothing.  Consensus steamrolls over that lone-wolf shit.  Sometimes we just have to settle for whatever we can realistically get.  So rather than dismissing everything as weak, get behind something workable and move on.  Because you're not going to get your perfect ideal unless you want an altcoin to your own personal specifications.

[1714918280]

1714918280

[1714918280]

1714918280

[1714918280]

1714918280

[1714918280]

1714918280

[1714918280]

1714918280

[Last of the V8s]

franky1 is far from alone in finding all these proposals weak, deficient, unnecessary, irrelevant, suspicious, laughable, disasters waiting to happen etc.

Generation after generation of older (ok theymos is q old!), richer bitcoiners than represented here have moved away from discussing such things here, or at all.

And they, and we young scamps, can run whatever versions of bitcoin we like, with whatever tweaks we want to take from developer research or not.

pl don't take your thread so seriously

[franky1]

ever thought that all the options are just weak and deficient and that we should not just 'settle' for good enough.

each have flaws, each open up the network to new attack/spam/bloat vectors that can make things worse not better.
we should not just let devs get their way and settle for whatever they do.

if only devs were independent, rather than factions of BS vs 'the others' things would have moved on

what needs to be done is for devs to get off their thrones and start listening to criticism and fix the issues. not let the devs form a faction and send out their reddit scripts to hypnotise and distract the conversations away from the issues.

by saying 'its impossible' to get XYZ is a lie.. it is possible. but when the community want XYZ but the devs just want to offer is X+a or y+a or z+a but refuse XYZA, even knowing this drama can continue right up until 2019('late 2018'),

devs are not ready to give in and offer XYZA.. any time soon.. if ever

.
what a true "reference" client should offer is
the ability for users to turn off and on options, make choices and have settings..

then let consensus decide what goes forward. not spoon feed out v0.xxx every 3 months and wait for people to be hypnotised into following X

[Lauda]

Yes, you've made that abundantly clear from the dozens of posts you've made on that particular subject.  We get it.  We really do.

Just ignore his gibberish. He's in no way qualified to judge a proposal like that anyways.

Sure, I'd prefer adaptive over fixed blocksize, but I'm not going to dig my heels in, take my ball and go home if I can't get that.  Because it achieves nothing.  Consensus steamrolls over that lone-wolf shit. 

Correct. Actually I'd argue that someone who tried to disrupt discussions by forcing proposals which have almost 0 support into them is malevolent. It's absolutely clear that it's either BIP141, BIP148, Segwit2x for the foreseeable future.

pl don't take your thread so seriously

Don't take franky so seriously.

each have flaws, each open up the network to new attack/spam/bloat vectors that can make things worse not better.

No.

[franky1]

each have flaws, each open up the network to new attack/spam/bloat vectors that can make things worse not better.

No.

keep sticking your head in the sand lauda.

[DooMAD]

Correct. Actually I'd argue that someone who tried to disrupt discussions by forcing proposals which have almost 0 support into them is malevolent. It's absolutely clear that it's either BIP141, BIP148, Segwit2x for the foreseeable future.

You're probably right about BIP141 and SegWit2x, but I fundamentally disagree on BIP148.  The general narrative on this board has always been that forced contentious splits are bad for Bitcoin, so I don't see why that narrative is suddenly changing just because the contentious split happens to include SegWit.  That's hypocrisy.

As for some of the other proposals that do clearly have less support, those are somewhat of a chicken and egg situation.  How are those proposals supposed to gain any support if they aren't discussed and no one shines a light on them?  Or is it merely malevolent to discuss any ideas that don't fit neatly into your own personal preferred vision?  

Updated the OP with some greater depth into the various proposals.

[Lauda]

You're probably right about BIP141 and SegWit2x, but I fundamentally disagree on BIP148.  The general narrative on this board has always been that forced contentious splits are bad for Bitcoin, so I don't see why that narrative is suddenly changing just because the contentious split happens to include SegWit.  That's hypocrisy.

You do not fundamentally understand BIP148 then? It is happening for any client running the BIP148 patch. Meaning, if neither BIP141 nor SegWit2x happen in time then BIP148 is happening 100%. This does not mean that BIP148 will succeed, just that it will happen.

As for some of the other proposals that do clearly have less support, those are somewhat of a chicken and egg situation.  How are those proposals supposed to gain any support if they aren't discussed and no one shines a light on them?  Or is it merely malevolent to discuss any ideas that don't fit neatly into your own personal preferred vision?  

Disagreed. Some of those proposals have been around for a while now, and have been debated. Once the upcoming storm clears, then you may start discussing them again. For now, I advise against doing this to avoid further stalling.

[DooMAD]

You're probably right about BIP141 and SegWit2x, but I fundamentally disagree on BIP148.  The general narrative on this board has always been that forced contentious splits are bad for Bitcoin, so I don't see why that narrative is suddenly changing just because the contentious split happens to include SegWit.  That's hypocrisy.

You do not fundamentally understand BIP148 then? It is happening for any client running the BIP148 patch. Meaning, if neither BIP141 nor SegWit2x happen in time then BIP148 is happening 100%. This does not mean that BIP148 will succeed, just that it will happen.

Yes, 100% happening, but (percentages varying a great deal depending on the level of mining support) 33.33% chance of creating an altcoin, 33.33% chance of creating a contentious split with two Bitcoins and 33% chance of a smooth transition and a longest chain with SegWit enabled.  People argue that hardforks are too disruptive and risky, but are seemingly okay with that potential mess?  The result is arguably less certain or predictable than that of a hardfork, so again, complete and utter hypocrisy to argue against hardforks or dismiss them as dangerous whilst simultaneously supporting UASF.

As for some of the other proposals that do clearly have less support, those are somewhat of a chicken and egg situation.  How are those proposals supposed to gain any support if they aren't discussed and no one shines a light on them?  Or is it merely malevolent to discuss any ideas that don't fit neatly into your own personal preferred vision?  

Disagreed. Some of those proposals have been around for a while now, and have been debated. Once the upcoming storm clears, then you may start discussing them again. For now, I advise against doing this to avoid further stalling.

The insistence to dictate what can and can't be discussed evidently doesn't work here.  If anything, it tends to backfire and create more support for the proposals people try to bury than there otherwise would be.  That particular mentality has done far more to stifle progress than anything else, IMO.  Discussions should be as neutral and transparent as Bitcoin itself.

[Lauda]

Yes, 100% happening, but (percentages varying a great deal depending on the level of mining support) 33.33% chance of creating an altcoin, 33.33% chance of creating a contentious split with two Bitcoins and 33% chance of a smooth transition and a longest chain with SegWit enabled.  People argue that hardforks are too disruptive and risky, but are seemingly okay with that potential mess?  The result is arguably less certain or predictable than that of a hardfork, so again, complete and utter hypocrisy to argue against hardforks or dismiss them as dangerous whilst simultaneously supporting UASF.

I did not comment whether a chain split is acceptable, nor the amount of support currently behind BIP 148 in this thread. I merely mentioned that it is happening if the other two proposals fail to activate before it. This is a factual/neutral observation. I don't think this thread is the place to discuss the nature of BIP 148 or BIP 149 for that matter? I'm rather surprised by the lack of spammers submitting their bullshit votes in there.
 

For now, I advise against doing this to avoid further stalling.

The insistence to dictate what can and can't be discussed evidently doesn't work here.  

Suggesting something to avoid stalling == trying to dictate? Bullshit. Do not waste time with unwanted proposals.

[franky1]

Discussions should be as neutral and transparent as Bitcoin itself.

Updated the OP with some greater depth into the various proposals.

yet

BU/EC:  This is Bitcoin Unlimited or "Emergent Consensus", a proposal for miners and nodes to declare the size of blocks they are willing to accept.  The reasoning for this proposal is outlined here.

EC is not a BU branded 'product'

BU brand call theirs 'Adjustable Block-size Cap' (ABC)

commonly people call EC 'dynamic blocksize' which again is not a BU product

seems by making EC a BU option. you will get people to basiedly not vote for EC it purely because YOU branded it as BU, knowing peopl will respond 'oh no i read on reddit that its bad bad bad'

other implementations totally unrelated to BU use EC

[jonald_fyookball]

so I am allowed to vote or does my negative feedback from Lauda and Blockstream CTO Greg Maxwell mean I will be censored?

[DooMAD]

seems by making EC a BU option. you will get people to basiedly not vote for EC it purely because YOU branded it as BU, knowing peopl will respond 'oh no i read on reddit that its bad bad bad'

other implementations totally unrelated to BU use EC

So is it less biased to simply not mention BU?  I don't mind just simply calling it EC.  I'll edit the OP.

//EDIT:  Done, is that better?  And would you like to edit your submission as a result?

so I am allowed to vote or does my negative feedback from Lauda and Blockstream CTO Greg Maxwell mean I will be censored?

I'm too lazy to check everyone's feedback, so if your declaration goes missing from the list, it wasn't me.  Post away.

[jonald_fyookball]

Code:

[tr]
[td]jonald_fyookball[/td]
[td][glow=#FF4444,2,300]No[/glow][/td]
[td][glow=yellow,2,300]#UASF! do it[/glow][/td]
[td][glow=#FF4444,2,300]No[/glow][/td]
[td][glow=#FF4444,2,300]No[/glow][/td]
[td][glow=cyan,2,100]Weak[/glow][/td]
[td][glow=#FF4444,2,300]No[/glow][/td]
[td][glow=#00FF66,2,300]Prefer[/glow][/td]
[td][glow=#00FF66,2,300]Bitcoin. FTFY[/glow][/td]
[/tr]

[Paashaas]

Code:

[tr]
[td]PaasHaas[/td]
[td]BIP141 Prefer[/td]
[td]BIP148 Acceptable[/td]
[td]BIP149 Acceptable[/td]
[td]SegWit2x Acceptable[/td]
[td]Extension Blocks Deficient[/td]
[td]SegWit Adaptive/BIP106 Weak[/td]
[td]BU/EC NO[/td]
[td]Bitmaincoin Hell NO[/td]
[/tr]

[theymos]

Your definitions aren't accurate.

BIP148 and BIP149 are virtually identical except that BIP149 activates 6-12 months later in order to reduce turbulence. Distinguishing BIP148 as a "UASF" and BIP149 as "timed" is misleading: they're both UASFs, and both timed with the possibility of early activation in case of miner cooperation.

There are many very different "Segwit2x" proposals, but BIP91 is absolutely not one of them. It doesn't involve any max block size increase except for SegWit. BIP91 is a way of activating the original BIP141/BIP9 deployment at an 80% mining threshold rather than the original 95% threshold.

There is no single "Segwit2x" proposal that you can clearly point to.

[franky1]

There is no single "Segwit2x" proposal that you can clearly point to.

i have to agree with theymos

all the 'promises' of increase to a 2mb base block miss out on actually including code that actually includes a 2mb base block
thus all same half gestures/ empty promises since 2015

[DooMAD]

Your definitions aren't accurate.

BIP148 and BIP149 are virtually identical except that BIP149 activates 6-12 months later in order to reduce turbulence. Distinguishing BIP148 as a "UASF" and BIP149 as "timed" is misleading: they're both UASFs, and both timed with the possibility of early activation in case of miner cooperation.

There are many very different "Segwit2x" proposals, but BIP91 is absolutely not one of them. It doesn't involve any max block size increase except for SegWit. BIP91 is a way of activating the original BIP141/BIP9 deployment at an 80% mining threshold rather than the original 95% threshold.

There is no single "Segwit2x" proposal that you can clearly point to.

OP tweaked again to rectify.  I think the latest plan to activate SegWit2x is to utilise the signalling bits from BIP91, which is where I got mixed up.

(...)SegWit2x readiness would be signaled using another piece of activation data: “bit 4” instead of “bit 1.”

This makes SegWit2x largely incompatible with BIP141, and especially with BIP148: Different nodes would be looking at different activation bits, meaning they could activate SegWit under different circumstances and at different times; and that would mess up SegWit-specific block relay policy between nodes, potentially fracturing the network.
BIP91

Now, it seems BIP91 has provided the solution.

BIP91 is a proposal by Bitmain Warranty (not to be confused with Bitmain) engineer James Hilliard which was specifically designed to prevent a coin-split by making SegWit2x and BIP148 compatible.

The proposal resembles BIP148 to some extent. Upon activation of BIP91, all BIP91 nodes will reject any blocks that do not signal support for SegWit through bit 1. As such, if a majority of miners (by hash power) run BIP91, the longest valid Bitcoin chain will consist of SegWit-signaling blocks only, and all regular BIP141 SegWit nodes will activate the protocol upgrade.

Where BIP91 differs from BIP148 is that it doesn’t have a set activation date, but is instead triggered by hash power. BIP91 nodes will reject any non-SegWit signalling blocks if, and only if, 80 percent of blocks first indicate within two days that’s what they’ll do.

This indication is done with bit 4. As such, the Silbert Accord can technically be upheld — 80 percent hash power activation with bit 4 — while at the same time activating the existing SegWit proposal. And if this is done before August 1st, it’s also compatible with BIP148, since BIP148 nodes would reject non-bit 1 blocks just the same.

This proposal gives miners a little over six weeks to avoid a coin-split, under their own agreed-upon terms. With a SegWit2x launch date planned for July 21st, that should not be a problem… assuming that the miners actually follow through.

So obviously miners are jumping on board with this.


//EDIT:  -ck sums it up more succinctly in this thread.

//DOUBLE EDIT:  Look at the last 1000 blocks.  This looks like a pretty momentous shift.

[azguard]

This should turn out to be interesting at the end

	BIP141	BIP148	BIP149	SegWit2x	Extension Blocks	SegWit Adaptive/BIP106	BU/EC	Bitmaincoin
azguard	Prefer	Acceptable	No	Prefer	Deficient	Deficient	No	No

Code:

[tr]
[td]azguard[/td]
[td][glow=#00FF66,2,300]Prefer[/glow][/td]
[td][glow=#00BB44,2,100]Acceptable[/glow][/td]
[td][glow=#FF4444,2,300]No[/glow][/td]
[td][glow=#00FF66,2,300]Prefer[/glow][/td]
[td][glow=yellow,2,300]Deficient[/glow][/td]
[td][glow=yellow,2,300]Deficient[/glow][/td]
[td][glow=#FF4444,2,300]No[/glow][/td]
[td][glow=#FF4444,2,300]No[/glow][/td]
[/tr]

[Variogam]

There are many very different "Segwit2x" proposals, but BIP91 is absolutely not one of them. It doesn't involve any max block size increase except for SegWit. BIP91 is a way of activating the original BIP141/BIP9 deployment at an 80% mining threshold rather than the original 95% threshold.

The working group Core code for Segwit2x is at
https://github.com/btc1/bitcoin

I never heard about any other Segwit2x code with which all the NYA signers would agree with.

About the "It doesn't involve any max block size increase except for SegWit" where you got franky1 already tricked by him saying "all the 'promises' of increase to a 2mb base block miss out on actually including code that actually includes a 2mb base block"

Commits on Jun 16, 2017:
https://github.com/btc1/bitcoin/commit/c11c37b0d6cf434b6565b2d70ed5aa2b1e63ba3e

most relevant code for the 2MB:

+/** BIP102 block size increase height */
+static const unsigned int BIP102_FORK_MIN_HEIGHT = 485218;

-static const unsigned int MAX_BLOCK_BASE_SIZE = 1000000;
+static inline bool BIP102active(int nHeight, bool fSegwitSeasoned)
+{
+    if (!fSegwitSeasoned)
+        return false;
+
+    if (nHeight < (int)BIP102_FORK_MIN_HEIGHT)
+        return false;
+
+    return true;
+}
+
+static const unsigned int MAX_LEGACY_BLOCK_SIZE = (1 * 1000 * 1000);
+inline unsigned int MaxBlockBaseSize(int nHeight, bool fSegwitSeasoned)
+{
+    if (!BIP102active(nHeight, fSegwitSeasoned))
+        return MAX_LEGACY_BLOCK_SIZE;
+
+    return (2 * 1000 * 1000);
+}


obviously removed MAX_BLOCK_BASE_SIZE is replaced with new logic to check whether block is invalid at many other lines, just check the Segwit2x pull commit code if interested

[franky1]

good to see an implementation finally showing the main block size increase... and with a ~3 month from now activation.

seems i should keep my eye on updates daily, rather than sporadically(few times a month/when they announce RC versions)

im guessing things like this can change peoples opinions if all the other 'brands' followed suite with the same commits..
lets wait and see

........
i just wonder how many blocks are waving flags.. but not running the actual implementation that has the code. thus basically sybil flagging