BUIP098: (passed) Bitcoin Unlimited’s Strategy for the November 2018 Hard Fork

[freetrader]

I think the flipside to Emil's question is: what is the BU strategy for November if this BUIP doesn't get accepted?

Can't seem to answer that myself based on the available data.

 

[solex]

@Emil Oldenburg

This is my overview and I invite @theZerg to provide his.

Bitcoin Unlimited was founded upon the principles of returning Bitcoin (BTC) back to its original goal as a p2p global currency. This goal was being subverted by the Core developers who are prepared to cripple its network effect in the pursuit of 2nd-layer solutions, while weaving a whole new paradigm based on voodoo economics. The only way to salvage BTC was by enforcing Nakamoto consensus with miners who were also dismayed by the change in goal. This proved a very long battle, so BUIP055 was successfully proposed to obtain BU membership support for creating a spinoff. In the end the spinoff (Bitcoin Cash) was created by the ABC team, of which @freetrader played a major part.

Bitcoin Unlimited's strategy for Bitcoin Cash since has been to work within multi-implementation developer consensus, supported by the the vast majority, if not all, of the miners. Miners have hitherto been satisfied to allow developers to advance the software in the manner which maximises miner profit from block rewards, fees and capital gains. This worked well for the 13 November 2017 and 15 May 2018 upgrades. So, the default position of BU is to follow developer consensus when there is evidence that Nakamoto consensus exists to support that roadmap.

Further, the reality is this background has shifted and there is now dispute between significant portions of BCH hash-rate as to the acceptability of the 15 November upgrade specification. The developers and miners closer to the dispute know the exact details, but this is for the history books, not for action necessary today. Part of that action was a major effort at reconciliation, which we saw at Bangkok. @sickpig, @awemany and I attended on behalf of BU, and we sought compromise, as did many others, including bitcoin.com.

When Nakamoto consensus is in play some miners and users will be on an orphaned fork. This will cost miners money, and maybe some users will also lose money. In fact it may cost everyone money by reducing global trust in BCH, creating a PR disaster for the whole community and damaging the BCH coin value for a long time to come.

BUIP098 recognises that BU has responsibility to its users to mitigate as much of the above risk as possible, so it seeks authority to support both proposed change-sets for 15 November i.e. by ABC and Bitcoin SV.

Absent of any change of direction by the BU membership, an assessment will be made of where Nakamoto consensus exists at the time of the BUCash software is being built for release before 15 November 2018.
At present we assume that majority hash-rate lies with ABC, so the BU client will by default support the ABC change-set.

Such an assessment is not simple as there is already smoke and mirrors over which miners are using which implementations.

So, a vote for BUIP098 is a vote to continue tracking Nakamoto consensus on BCH, regardless of whether the most-PoW chain-tip has the ABC or SV change-set active, rather than risk being forked off. If this BUIP is passed, depending upon development time and effort needed, the BU client may offer a hot fail-over rather than manual config. Users will also be able to pre-select one change-set as an override if that is their preference.

 

[lunar]

So just to confirm, as there's a lot going on in this BUIP.

Assuming this passes. If the user does nothing, the default action of the client will be to follow Nakamoto Consensus and most PoW?

I also think 'We' is very mistaken here: "At present we assume that majority hash-rate lies with ABC, so the BU client will by default support the ABC change-set.

Time will tell. Anyone up for a bet, or setup a prediction market?

 

[Mengerian]

Yeah, it's a bit unclear what this vote means.

I want BU to support the upgrade plan that came out of the developer collaboration from the last several months, and be compatible with what is implemented by Bitcoin ABC.

So does that mean I should vote "NO"?

 

[solex]

@Mengerian
Correct, if you only want BU to be compatible with ABC for the 15 Nov upgrade, then vote "NO".

@lunar,
BU should follow Nakamoto Consensus for BCH. Following NC is the default for BU.
To be clear, the BU developers had BU membership approval to follow a minority spinoff (via BUIP055, 2 months before BCH was launched), so that provided membership approval for ignoring NC (on the BTC chain).

This BUIP is designed to save its users the aggravation of being forked off onto a minority chain if ABC-compatible blocks are rejected by the majority of hash-power. It also gives users the choice of ABC or SV compatibility and a hot failover. BU is all about user choice and this fits with the paradigm, especially when user choice is the choice of following NC or not.

 

[reina]

Hi @solex! I have a few questions, in between your quotes

Solex: "So, the default position of BU is to follow developer consensus when there is evidence that Nakamoto consensus exists to support that roadmap."

"BUIP098 recognises that BU has responsibility to its users to mitigate as much of the above risk as possible, so it seeks authority to support both proposed change-sets for 15 November i.e. by ABC and Bitcoin SV."


"Absent of any change of direction by the BU membership, an assessment will be made of where Nakamoto consensus exists at the time of the BUCash software is being built for release before 15 November 2018."

When is it being built for release? How far along are all these features, and the ability to switch rulesets automatically etc?

"At present we assume that majority hash-rate lies with ABC, so the BU client will by default support the ABC change-set."

Does that mean if this turned out untrue anytime during development up to the nov release, that the default rule set would be switched to SV rules? How are XT and other clients counted in terms of what ruleset they support? Are they uncounted?

More importantly, when is the release client going to come out? If hashpower fluctates and say SV or something has majority, is BU client still sticking to that ABC ruleset default, or do you keep updating the clients default ruleset relative to hashpower ratios, all the way up to nov 15? It's only a month or so away.

Thirdly, how does the softeare realise its on the less pow chaintip?

"So, a vote for BUIP098 is a vote to continue tracking Nakamoto consensus on BCH, regardless of whether the most-PoW chain-tip has the ABC or SV change-set active, rather than risk being forked off. If this BUIP is passed, depending upon development time and effort needed, the BU client may offer a hot fail-over rather than manual config. Users will also be able to pre-select one change-set as an override if that is their preference."

Will the software flip flop between chains/rulesets when the hashpower ratios are very close? How sensitive is it? Does it switch over when there are 1% more sv nodes than ABC? How are XT and other clients counted in terms of ruleset support?

Will all of this be ready before Nov 15? When will the release client likely be out?

Thanks!
[doublepost=1538769055,1538767956][/doublepost]

Appendix A: A few notes on BIP135

BIP135 is a superset of BIP9. BIP9 has hard-coded activation thresholds and times and these are quite optimistic. For example, it proposed a 95% activation threshold, yet during the fight for larger blocks it became clear that well over 5% of the hash power actually had much larger investments in alt-coin hashing hardware. Although the economic model of Bitcoin assumes that 51% of the hash power wants what is “best” for the currency, its is a flawed to assume that for 100% of the hash power.

BIP135 allows activation thresholds and times to be configured. Note that these can be configured with the BIP9 values to make a particular activation bit backwards compatible with BIP9-only full nodes."

Hi, just a small question @theZerg, who would decide the configuration for an activation threshold? Is it something miners need to go to a meeting to decide, or can the desired threshold for each feature be voted on by miners and pools, within the software itself?

 

[solex]

@reina
Bitcoin software has always tracked the most-PoW chaintip within the same rule-set. The most work chain is just mined blocks. Node counts / percentages are not relevant to PoW, only to gauge the proportion of the ecosystem which are by default on one side. This is currently the ABC side and is a factor in the BU default position to adopt the ABC changeset, as well as its presumed hashpower majority.

One of the first things @theZerg did in BU was support chaintip tracking regardless of block limit and provide user configurability to select a preferential limit and acceptance depth. The changes proposed in BUIP098 extend this from the block limit to ABC and SV changesets. This means the BU developers do not have to guess on behalf of its users where the majority hashpower will remain at the November upgrade.

BU membership approval needs to be obtained for such functionality to go live, hence the current vote.
@theZerg proposed BUIP098 so he would not make a proposal which is not feasible in the time limit remaining.

 

[Mengerian]

@Mengerian
Correct, if you only want BU to be compatible with ABC for the 15 Nov upgrade, then vote "NO".

OK, great, thanks for the info. That's what I want, so I will vote no

 

[reina]

@reina
Bitcoin software has always tracked the most-PoW chaintip within the same rule-set. The most work chain is just mined blocks. Node counts / percentages are not relevant to PoW, only to gauge the proportion of the ecosystem which are by default on one side. This is currently the ABC side and is a factor in the BU default position to adopt the ABC changeset, as well as its presumed hashpower majority.

BU is the second most used client. So by choosing ABC ruleset as a default, users of BU end up by default, voting for ABC's ruleset, which further increases the proportion of hashpower supporting ABC ruleset.

If they don't want to support ABC ruleset from the outset, they can preselect the SV ruleset (hopefully this feature is easy to access?).

If they preselect a ruleset, but end up on minority chain, they can autoswitch ruleset to majority ruleset by default? And this BUIP would also allow users to force their software to follow just one ruleset no matter what? Is that correct? They can both preselect their ruleset and force their software to follow that ruleset whether minority or majority chain?

Are miners going to be well aware of this before the fork? What is the strategy for explaining or promoting this well, because even BU members seemed to need clarification?

So preselected ruleset activates exactly at the agreed block where the fork starts. If someone uses BU software, but sets their preselected ruleset to SV, can others on the network see this preference? If you change your default ruleset and want to signal support just to indicate to others on the network, does it autosignal this for you in blocks you mine before the fork?

So to clarify, are the choices on this vote:

YES = Support ABC ruleset as default at fork, but follow majority if ABC ruleset is not majority.
Default behaviour is to switch to ruleset of the most PoW chain always (switch chains if on minority).
Also allow users to preselect a override (SV) ruleset.
Allows users to override autoswitching ability between rulesets.
AKA User choice

NO = Support ABC ruleset as default at fork.
AKA No user choice


Thanks!

 

[solex]

Yep, you have summed it up very well and basically answer your own questions.
All major miners should be in the picture about the options as they had a 2-day meeting in Bangkok where everyone made their opinion known. Sadly, there was no compromise at the meeting, so we are left with a possible messy situation in November. Having said that, I hope that the event goes smoothly and BCH continues grabbing market share.

 

[imaginary_username]

To be honest I don't think this is going to be very beneficial (because the window for development, testing and deployment is really short) come November, but developing the mechanism itself is very valuable anyway in the future and will be especially useful if/when we attain majority status - so I'm voting yes.

 

[reina]

Yep, you have summed it up very well and basically answer your own questions.
All major miners should be in the picture about the options as they had a 2-day meeting in Bangkok where everyone made their opinion known. Sadly, there was no compromise at the meeting, so we are left with a possible messy situation in November. Having said that, I hope that the event goes smoothly and BCH continues grabbing market share.

Hi @solex,
Thanks for the confirmation! There is still one I am wondering: If you preselect a ruleset prior to the fork, does it automatically signal this choice in the blocks you mine so other miners see, or will the miners signal this themselves only if the want to?

Considering it's such an important time, why aren't any of the miners signalling support and intent on the ruleset they want? All the signalling is for BIP9, that's old. Are they deliberately not signalling?

Secondly, for gauging who is likely to follow each ruleset (if they won't signal), isn't % of blocks mined in last 7 days a better indicator than node count? For the mining network.

Right now, bch blocks mined in the past week:

Coingeek + BMG 33.5% (SV supporting)
ViaBTC + Antpool + BTC.com 23.2 % (ABC supporting)
Bitcoin.com 8.2% (BU supporting, ? ruleset)
BTC.top 13.9% (? Ruleset)
Smaller pools + unknown 21.2% (? Ruleset)

If I had to look at the *overt* ruleset support via miners by their ratio of mining power on BCH, there's actually *more* SV ruleset support (from Coingeek and BMG) than the overt ABC ruleset mining support (from the pools known to be anti-SV).

Even if we supposed Bitcoin .com would want ABC ruleset, adding them still makes that overt anti-SV group have less % than Coingeek and BMG. If SV ruleset has a majority in known support, why is BU software not defaulting to that ruleset?

Do we run the risk of prolonging the hash war by not adding support to the current *known*, majority of overt mining stance on ruleset, and instead adding default support to the smaller percentage of overt support, making both of them really close in percentage?

Ofcourse noone can know how much hash is going to jump out of the woodwork come Nov, but if I had to work from only publicly visible info, that's all I have to judge from.

Would a default signaling their preselected or current selected ruleset be useful? (They can override this if they like).

 

[solex]

Hi @reina
Indeed no one can be sure of the exact makeup of full node implementations in the mining percentages. We need to start from a known base, and that is 100% of the miners are using ABC compatible software from 15 May 2018. We can only assume the same will happen at 15 November unless miners publicly state otherwise. This is via their official social media accounts, or via coinbase input scriptsig free text.

We know 30-40% of the hash-rate is publicly advocating for SV client usage, rejecting the ABC change-set, from 15 November. That leaves 60-70% either continuing to support the ABC change-set or not voicing an opinion. This obviously includes the mining power using the BU client at present.

Further, the SV node count is 1% of the total ecosystem node count, and this is itself a major factor. In 2015, non-mining nodes possessed inertia which economically persuaded >70% of the BTC mining power, signalling for BIP100, from lifting the 1MB limit at the time. Non-mining nodes have an importance which is relative to their economic footprint and some of these are large, e.g. Bitfinex, BitPay, Coinbase, Bitstamp, Bitkan, Yours.org, etc, so their situation needs to be considered. It is irresponsible to ignore them and have them scrambling to maintain business uptime with an emergency upgrade if they wind-up on a minority fork. I suspect that the vast majority of BCH-using businesses do not have a preference for the ABC or SV roadmaps, but just want to make profit tracking the most-PoW BCH chain-tip.

So, BU needs to continue on the path of assuming the BCH multi-implementation development model holds. The one which delivered 13 November 2017 and 15 May 2018 general upgrades, as a default position. I do note however, that BUIP098 has significant BU membership support*, so it does look like BU will be providing a client that will support both ABC and SV change-sets. It is certainly the intention to make this as easy for users as possible to select preference, ideally adding an automatic setting too.

*voting in progress at the time of writing

 

[Christoph Bergmann]

Indeed no one can be sure of the exact makeup of full node implementations in the mining percentages. We need to start from a known base, and that is 100% of the miners are using ABC compatible software from 15 May 2018. We can only assume the same will happen at 15 November unless miners publicly state otherwise. This is via their official social media accounts, or via coinbase input scriptsig free text.

We know 30-40% of the hash-rate is publicly advocating for SV client usage, rejecting the ABC change-set, from 15 November. That leaves 60-70% either continuing to support the ABC change-set or not voicing an opinion. This obviously includes the mining power using the BU client at present.

Why do we vote about anything at all, when you just follow ABC?

BU has a mechanism to deal with forks, AD. If ABC's hardfork gets enough depth, BU nodes should override their consens-setting. But defaulting to ABC while BU members clearly voted against breaks with the constitution.

 

[reina]

Hi @reina
Indeed no one can be sure of the exact makeup of full node implementations in the mining percentages. We need to start from a known base, and that is 100% of the miners are using ABC compatible software from 15 May 2018. We can only assume the same will happen at 15 November unless miners publicly state otherwise. This is via their official social media accounts, or via coinbase input scriptsig free text.

I think the problem with using this 'known base' is that we also know all the miners were compatible to BU, or XT, or any Bitcoin Cash implementation that existed on 15th May 2018. So that's perhaps a bad metric to use, because now all these implementations have different strategies.

I think Tom Harding and XT's position here is solid (emphasis is my own):

"We intend for XT to follow the most-work chain and will add whatever software support is needed to do that.

Right now it is unclear what rules the most-work chain will follow after November and we have not added software support for any changes, though we are preparing for likely scenarios.

XT recommends and will support what we consider to be a superior way to upgrade the network in November and thereafter. That is by activating individual features using BIP135 which defines an orderly way to activate an upgrade that has an agreed supermajority level of mining support. If your client supports BIP135 and the network defines the potential upgrades consistently, you will not be forked off regardless of whether the upgrade succeeds or fails.

BIP135 is an extension of BIP9 which has been used successfully in the past -- both to activate an upgrade (relative locktimes) and to reject an upgrade (segwit, though it was later activated by other tactics)."

I wonder what are your thoughts on that? And @theZerg's thoughts?

The way we push ABC's changes into default is very contrary to miners making a conscious decision to signal for particular features, and phase them in when they are ready and want it. Especially features that are totally incompatible with the existing network, like CTOR, the consequences of which are not fully tested.

And because this BUIP only gave these two options, it is like being stuck between a rock and a hard place: Choosing choice is better than no choice (ABC ruleset only) but I think there is now a layer of complexity for miners and upcoming disturbance for the mining network, because they only have a rough idea of the hash that is going to be involved. There is no clear hash majority.

We know 30-40% of the hash-rate is publicly advocating for SV client usage, rejecting the ABC change-set, from 15 November. That leaves 60-70% either continuing to support the ABC change-set or not voicing an opinion. This obviously includes the mining power using the BU client at present.

I stand by my original assessment of the visible BCH pool's alliances as far as we can assume based on what they say and their affiliiation:
33% SV rule support
23-33% ABC rule support
33%-43% ? support or even no-forkers (havent really said anything public about what they will support)

It's could possibly be a mexican standoff at this rate. 14.9% of BCH blocks were mined by unknown miners, someone or multiple people or pools have hash that's not currently pointed to mine BCH. It's one big cowboy rules shootout. I still haven't found anyone give a convincing reason to why CTOR needs to be included in Nov, rather than any time it's more tested or fully fleshed out or proven. It's costly to Bitcoin Cash and to Bitcoin. I wish the best to miners to defend the future of Bitcoin.

Non-mining nodes have an importance which is relative to their economic footprint and some of these are large, e.g. Bitfinex, BitPay, Coinbase, Bitstamp, Bitkan, Yours.org, etc, so their situation needs to be considered. It is irresponsible to ignore them and have them scrambling to maintain business uptime with an emergency upgrade if they wind-up on a minority fork.

It is true that businesses are part of this framework, I wonder if they were present at the miner summit too? Any public opinions from these businesses?

I suspect that the vast majority of BCH-using businesses do not have a preference for the ABC or SV roadmaps, but just want to make profit tracking the most-PoW BCH chain-tip.

It could be a dangerous assumption. I know that for Lighthouse Cash project, the ABC changes for Nov would actually break what they are working on, they mentioned this. It would require code changes for them, and they could be representative of other projects and businesses too: Unwanted hassle from an unwanted network "upgrade" from ABC, with no realisable reward, either now or in the near future. Could go down in Bitcoin Cash history as perhaps the worse feature since the DDA, worst than the chain-splitting ABC bug that was discovered by Cory Fields.

Now we are just all here staring at this high risk thing in plain sight, watching as we slowly glide into Nov with merchants and users shaking in their boots, worried. It's not a good sight, and the burden should be on the feature to proof it is good and beneficial first before it is added. I think everyone here who is a BU member has agreed to the Articles of Federation, and

The merchants and services have no assurances on what is the majority in Nov, while one of the rulesets may break their currently functional services. Many businesses may not be at the luxury or position of BU to be able to support two different rulesets, at the flick of a switch.

The SV ruleset doesn't seem to require any reworking of current products or services. The SV ruleset introduces maybe stuff they don't use (some OP_codes) but not the stuff absolutely everyone uses, like natural ordering. Tom Zander argued forced CTOR may even hurt parallelisation.

But now here we are: Default ABC rules. There are so many risks and concerns coming from many directions, and even unknown factors, that I don't know how this can be considered ok to add into the network next month, let alone give to the user as the default.

I do note however, that BUIP098 has significant BU membership support*, so it does look like BU will be providing a client that will support both ABC and SV change-sets. It is certainly the intention to make this as easy for users as possible to select preference, ideally adding an automatic setting too.

*voting in progress at the time of writing

If we really wanted users to make a conscious decision on this important situation, maybe it helps to have a popup when you load the new BU release, where it asks you to preselect the ruleset you want the software to follow: ABC or SV. Then ask if they want to follow this ruleset no matter what, or automatically follow the rules of the most-work chain when it appears.[/QUOTE]

 

[reina]

To finish off, from the Articles of Federation:

"In the Bitcoin Core variant, we do NOT see a venue for these actors to formally express their desires in regards to the evolution of the network. Instead we see a project controlled by a small group of developers employed by finance-oriented forprofit startup companies, and the emergence of corporate products (Lightning network, Side-chains and permissioned ledgers) that would materially benefit from a Bitcoin network that is incapable of handling the transactional demand required for a worldwide public good"

Does this sound familiar? I think we need to be conscious of how this can happen yet again.

A network that is screwed up from stupid features is a network unable to continue for public good. I think we should all be cautious of what things are actually improvements to Bitcoin and what isn't. Andrew's ATMP bottleneck fixes are a good example of improvements to Bitcoin's code, with no detriment to the network. Optimisation with real and provable results is something miners, merchants, users, & devs all support. Not at all the same for unproven "upgrades".

I think any new features that any dev team offers, should be read cautiously.

 

[solex]

@reina,

I think the problem with using this 'known base' is that we also know all the miners were compatible to BU, or XT, or any Bitcoin Cash implementation that existed on 15th May 2018. So that's perhaps a bad metric to use, because now all these implementations have different strategies.

I think Tom Harding and XT's position here is solid (emphasis is my own):

"We intend for XT to follow the most-work chain and will add whatever software support is needed to do that.

Right now it is unclear what rules the most-work chain will follow after November and we have not added software support for any changes, though we are preparing for likely scenarios.

XT recommends and will support what we consider to be a superior way to upgrade the network in November and thereafter.

BUIP098 proposes to follow the most-work chain and Tom Harding was first to vote for it. BU and XT are aligned in this respect. The only potential difference is the default user settings offered.
If a counter-BUIP was raised which proposed BU adopt just the SV features then it would have been put up for vote.

The way we push ABC's changes into default is very contrary to miners making a conscious decision to signal for particular features, and phase them in when they are ready and want it. Especially features that are totally incompatible with the existing network, like CTOR, the consequences of which are not fully tested.

Most elements of the 15 November change-sets, be it CTOR or the re-enabled/new opcodes are incompatible with the existing network. While I have advocated for delaying CTOR, I certainly do not believe that ABC are advancing it "untested". They are professional developers. BU is independently testing it. So is XT and Bitprim.

And because this BUIP only gave these two options, it is like being stuck between a rock and a hard place: Choosing choice is better than no choice (ABC ruleset only) but I think there is now a layer of complexity for miners and upcoming disturbance for the mining network, because they only have a rough idea of the hash that is going to be involved. There is no clear hash majority.

If Bitcoin SV grabs all the hashrate then BUIP098 ensures that BU users are not forked off.

I stand by my original assessment of the visible BCH pool's alliances as far as we can assume based on what they say and their affiliiation:
33% SV rule support
23-33% ABC rule support
33%-43% ? support or even no-forkers (havent really said anything public about what they will support)

It's could possibly be a mexican standoff at this rate. 14.9% of BCH blocks were mined by unknown miners, someone or multiple people or pools have hash that's not currently pointed to mine BCH. It's one big cowboy rules shootout. I still haven't found anyone give a convincing reason to why CTOR needs to be included in Nov, rather than any time it's more tested or fully fleshed out or proven. It's costly to Bitcoin Cash and to Bitcoin. I wish the best to miners to defend the future of Bitcoin.
[

The brilliance of Satoshi's design is that Mexican standoffs don't happen in blockchain building. The majority fork pulls inexorably ahead. There will not be three forks, all the undecided will jump one way or another, to ABC or SV. It is not nice and polite, but that is where we are headed.

It is true that businesses are part of this framework, I wonder if they were present at the miner summit too? Any public opinions from these businesses?

Only developers and miners were present. Some miners have non-mining activities, such as bitcoin.com, and they are as concerned as anyone about the breakdown in development consensus.

...Could go down in Bitcoin Cash history as perhaps the worse feature since the DDA, worst than the chain-splitting ABC bug that was discovered by Cory Fields.

It is not possible to guarantee the absence of bugs, and we saw a whopper bug from Core recently. All that can be done is learn from each incident and put test scripts and controls in place to improve the whole development cycle.

If we really wanted users to make a conscious decision on this important situation, maybe it helps to have a popup when you load the new BU release, where it asks you to preselect the ruleset you want the software to follow: ABC or SV. Then ask if they want to follow this ruleset no matter what, or automatically follow the rules of the most-work chain when it appears.

I think it's best for @theZerg to advise further how BUIP098 will look from a UX perspective.

..materially benefit from a Bitcoin network that is incapable of handling the transactional demand required for a worldwide public good

I really don't see how ABC can be tarred with this brush when they are currently running with a block limit 500x larger than organic real-world BCH txn demand. They are certainly not small-blockers.

Anyway, it looks like BUIP098 will pass with a big majority vote.

 

[reina]

HI @solex, thanks for your detailed answer.

To clarify, the 'disruption to the functional network' I was thinking of wasn't the blocksize, it was about CTOR. Tom Zander, @theZerg, Mark Blundeberg, nChain have raised the criticism that compulsory (rather than optional) canonical transaction ordering entails all the risk with zero reward, when the same thing, if proven useful in the future, can be done with optional sorting, or even the current topological or natural sorting.

If we literally can't find any other experts apart from ABC to give a *proven* reason why CTOR is needed and why it is needed at *this* point, that's incredibly concerning. It is a hardfork change that is not justified by any realisable gains, but entails risk and problems that can lie further down the road. And we more or less don't have many chances to push undo buttons, because this is other people's money that is being messed with if it fails. One good reason not use this as a default.

Quote from Andrew: "An optional, no hard fork, not consensus enforced, transaction sort provides the much the same benefits as CTOR. Should we accept the risk of an accidental fork that a major consensus change brings when it is unnecessary?"
https://medium.com/@g.andrew.stone/why-abcs-ctor-will-not-scale-8a6c6cf4a441

Quote from Tom Zander:
"The idea behind this statement is that after making the sorting predictable and making the merkle tree into a merklix tree (source), you can now hand over processing of a long list of transactions to several machines and they will all create a sub-set of the merkle-tree which one final machine can merge into a block header than can be send to the mining hardware.
The mistake that the blog makes is that it seems to assume you need a sorted merklix tree to accomplish the goal; to split this over many machines.
In Satoshi's original transaction ordering you can still simply use a merkle tree and still split up the creation or validation or a subset of the block among many machines. The only requirement is that each has the same amount of transactions. Which is really not a very difficult requirement to meet in a private sharded system."
https://www.yours.org/content/private-vs-trustless-sharding-12d00d1fd865

From nChain analysis doc:
https://nchain.com/app/uploads/2018/09/Canonical-Transaction-Ordering-A-Critical-Evaluation-Final.pdf

"/u/markblundeberg (co-author, Simple Ledger Protocol) analyses the code changes between Bitcoin ABC version 0.17.1 and 0.18.1. He: (i) notes that the parallel algorithm proposed for validating CTOR blocks (referred to as Out-Then-In or OTI) works equally well with the existing TTOR (assuming one minor non-consensus change to carry a transaction ordinal in internal data structures); (ii) observes that Graphene can be implemented under current consensus rules by following a suggestion from Gavin Andresen; and (iii) draws a number of conclusions, including that the most disruptive part of the CTOR suggestion is the removal of TTOR, and that CTOR will not provide any near-term benefits for block validation, remaining undecided on long-term benefits"

nChain stance:
"Even with sufficient testing, and even with sufficient evidence produced from multiple implementations on testnet, changes may introduce subtle bugs that are not immediately obvious. Edge cases that only show after significant uses may present, the result of which may be of any severity up to and including an inadvertent chain split. This is not without precedent."

"While some of the CTOR proposal’s goals may appear at first glance to be admirable, there is insufficient demonstration that those goals are actually achieved by the implementation of CTOR. Further, as a consensus change - and a highly contentious one - there is significant associated risk with implementing CTOR, without proven benefit. For these reasons, nChain believes the CTOR proposal should not be implemented."
[doublepost=1539107370][/doublepost]I guess a counter BUIP could actually be interesting to get an idea of how people feel about SV's ruleset. I know there are also alot of people who vocally don't want any HF in Nov, but if they have to choose also... The impression I get is, the majority do not see any benefits in a compulsory CTOR.
[doublepost=1539107515][/doublepost]@solex

There is no time specified in the Articles of Federation about when a counter-BUIP can be proposed. Can you clarify how this works?

"If a counter-BUIP is proposed, voting occurs in a twofold manner: first each member votes his preference, BUIP, counter, or none, with a 33% majority. Then if the BUIP or counter-BUIP wins, each member votes to accept it or not with the normal majority requirement. Note that members could make both votes simultaneously (I vote for the counter, but if BUIP wins I vote to accept it), depending on the Secretary's implementation of this process"

 

[theZerg]

@reina BIP135 is merged in BU, and this BUIP is about enabling BIP135 voting bits for the features under proposed by ABC and SV. We are doing this in concert with XT. Its also about enabling manual override and/or emergent consensus for this same feature set. Obviously EC is the best option, but as others have said, there is limited time and much to do. Since it looks like this is going to pass, we hope to get a release out within a week or two that implements some of the features but most importantly enables the BIP135 voting.

Its ok to allow voting for a feature you haven't implemented yet. Doing it that way is actually an intentional part of the process -- BIP135 gives developers time between when its clear that a feature will be enabled and when it actually goes live to develop it.

However, we don't know who will be using BIP135 voting bits. I know ABC is not, but I hope to talk to nChain and convince them to signal their features using them. Regardless, the intent of this BUIP it to be ready to follow either fork even if its a surprise fork. The recent coingeek statement from Ayre implies that they will call bitmain moving hash power to BCH "unfair" and so we may see a minority coin split coming from them. In that case, you'll be able to configure BU to follow that fork.

 

[reina]

@theZerg Can you clarify what @solex meant by default rulesets?

I thought those ABC and SV rulesets could only be selectable by the users as a package deal. When solex said the default ruleset would set to following ABC rules I thought it is all of ABC rules.

If the version you are making uses voting bits, does it mean that the default is actually just current rules, and then every single rule needs to be voted in individually, like in XT?