BUIP096: (closed) BCH November upgrade - Enforced lexicographic transaction ordering

[solex]

BUIP096: BCH November upgrade - Enforced lexicographic transaction ordering
Date: 14 August 2018
Proposer: solex

Motivation
Bitcoin Cash is advancing through decentralized development. Perhaps this was easier early-on, but now the dust has settled from the fork and a year has passed, there are many different voices pushing and pulling development priorities. The upcoming 15 November 2018 general upgrade is a major event, hence it would help if Bitcoin Unlimited, as an organization, had an official position on the major elements of the upgrade. This position is determined by the membership.

Objective

The purpose of the BUIP is to determine whether the BU membership supports using an enforced transaction ordering method after the scheduled November upgrade (this is a forking change).

Summary of Proposed Changes

Enforced lexicographic transaction ordering in blocks

For further information see:

Pro:

https://blog.vermorel.com/pdf/canonical-tx-ordering-2018-06-12.pdf
https://medium.com/@j_73307/canonical-block-order-or-dbe3ac48bcd3

Con:

https://www.docdroid.net/pvFaNUq/critique-canonical-order.pdf
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1218#post-78745

Budget

N/A

Impact

This BUIP has the potential to fork BU off the BCH blockchain. This BUIP is not intended to facilitate a chain split.BU does not desire unintended forks in the BCH blockchain, so the BU client will remain compatible with the final specification of the November upgrade.

 

[AdrianX]

I have an opinion as a random guy on the internet.

As someone whos going to vote on this, I'd like to know what the BU Devs think in general, as this is not my area of expertise. A one line for the pro's and cons - I will catch up on the general discussion, so I'm just looking for a summary as the outcome is ultimately going to fall in your domain.

In addition, can someone tell me when this idea was first proposed, and when did work on it start?

Thank's in advance.
Adrian.

 

[solex]

@AdrianX This proposal for canonical ordering came from the ABC team late last year. It has recently seen a lot of discussion on the gold collapsing thread, so I recommend reading all the posts which discuss transaction ordering. The main risk I see are the unknown consequences of losing the time-ordering of parent/child transactions (in the same block).

 

[freetrader]

BU does not desire unintended forks in the BCH blockchain, so the BU client will remain compatible with the final specification of the November upgrade.

A better stance IMO would be to declare this BUIP as binding on the future direction of BU after the fork, i.e. it's fine to remain in consensus for November, but BU software should make its choice based on the technical merit (or not) of canonical ordering enforcement. Not sure that's been fully explored after reading the conversation initiated by @awemany.

Otherwise, if BU lets things be even though its membership may (hypothetically) disagree with canonical ordering, why are we even having a vote on this? If the outcome is non-support, I think BU should propose in code to remove the feature for the next hard fork (May '19 or miner-activated) unless further data comes to light that makes removal (sticking to the current status quo of non-enforcement) a bad option.

 

[solex]

@freetrader
I disagree that these BUIPs should be binding on the future direction, as they are simply to determine/quantify the sentiment of the BU membership on the changes. Ideally, if there is low support then we would hope this is taken into account before the Nov 2018 specification becomes final (October?).
We should not fall into a trap where every disagreement on software changes leads to talk of forking. The 1MB was (and still is in BTC) a huge impediment, and very much a special case. IMHO, none of the proposed Nov 2018 changes are remotely critical enough to warrant forking,

 

[freetrader]

@solex: Bitcoin Unlimited Improvement Proposal

While I agree with all the other points (such as changes not being critical enough to split BCH), I disagree that with using BUIPs to conduct mere "polls" of the membership. How is this improving BU?

 

[Peter R]

Thanks for posting these three BUIPs, @solex!

 

[solex]

@freetrader
Indeed, where is the BU improvement in this case?
Well, I see it as indirect, collaborative than confrontational. The November upgrade is a major event for BU, so any input into the event by BU membership voice can be considered an improvement if changes occur, arguably even no changes, if the membership proves to be aligned with the upgrade specification.

 

[torusJKL]

Could we implement but give miners the choice to deactivate it?
(Together with signaling what they did opt-in/out)

BU stands for unlimited coices and whether one wants to support canonical ordering or not should be a choice made by the one running the software.

 

[Norway]

... will remain compatible with the final specification of the November upgrade.

What is this "final specification"? Is it a document created by a committee of devs from different implementations?

I'm 100% behind @torusJKL that we should make all these hardforking changes optional for the miners.

 

[torusJKL]

Could we implement but give miners the choice to deactivate it?
(Together with signaling what they did opt-in/out)

BU stands for unlimited coices and whether one wants to support canonical ordering or not should be a choice made by the one running the software.

@theZerg has written BUIP098 which addresses exactly this.

 

[Norway]

BUIP098 is not going to be voted over now. So I guess I have to vote no to this proposal at this point, unless someone convince me to vote yes.

 

[steffen]

NACK. Bitcoin Cash doesn't need any change in transaction ordering in blocks. Haven't seen sufficient evidence that this is an improvement. BCH needs a higher block size limit to be prepared for more adoption.

 

[Christoph Bergmann]

BUIP098 is not going to be voted over now. So I guess I have to vote no to this proposal at this point, unless someone convince me to vote yes.

Me too

 

[reina]

A better stance IMO would be to declare this BUIP as binding on the future direction of BU after the fork, i.e. it's fine to remain in consensus for November, but BU software should make its choice based on the technical merit (or not) of canonical ordering enforcement. Not sure that's been fully explored after reading the conversation initiated by @awemany.

Otherwise, if BU lets things be even though its membership may (hypothetically) disagree with canonical ordering, why are we even having a vote on this? If the outcome is non-support, I think BU should propose in code to remove the feature for the next hard fork (May '19 or miner-activated) unless further data comes to light that makes removal (sticking to the current status quo of non-enforcement) a bad option.

I agree with freetrader that BU needs to have the freedom to go on it's own path and strategy and judge by merit and general direction of its members. Otherwise, it is not much more than follow the "leader", when someone publishes something first, then always being in the position to avoid forks or discord would mean also to never have decisions at all. That is not decentralised development. All the teams should do their best to offer their *best* offering, not compromise.

This is actually a better way to resolve quickly what miners and market want, by making them choose. It does not render a team useless if their solution was not chosen this time, but the point is that the offerings are actually different enough to allow choice. When miners and users are given options to make choices from, that's when we see what they actually want. I think each implementation needs their own autonomy, because when implementations are "almost the same", that is the worse situation for the implementation itself, because the leader will continue to be popular when noone dares to oppose or offer a different solution.

Each implementation team should have the freedom to present and pursue what they see best for the Bitcoin mission and purpose, and not sacrifice their own beliefs to follow someone else's. Bitcoin must be battle worn and get stronger, when there will be a time of "no more nice guys".

Many people will rise and fall, users, devs, busineses. Tides change. But within this, the underlying purpose and mission of functional peer to peer money should be always kept at the heart of what we pursue for Bitcoin.

The design of Bitcoin 0.1 is still there to be tested, and it's scaling still continues forward, and I do not believe at this time, or even another, that we need to change from the natural ordering that gives us information for free, like timing and order, to another ordering, which removes that information.

Lexographical ordering is purported to help get to 1TB blocks, and help parellelisation, but thus far, we are nowhere near 1TB, and devs like Tom Zander even voice the concern that parellelisation can be greatly harmed by lexographical ordering, along with graphene as Awemany mentions.

It's by this token that I would not wish a contentious change to the protocol that has theoretical upsides that are not proved, and nameable downsides and even that it does not disprove, issues that Awemany and Tom Zander have pointed at.

https://www.docdroid.net/pvFaNUq/critique-canonical-order.pdf#page=5

 

[Mengerian]

People may be interested to read Shammah Chancellor's article about Canonical Transaction Order before casting their ballots:

https://medium.com/@Bitcoin_ABC/sharding-bitcoin-cash-35d46b55ecfb

 

[theZerg]

I am going to vote no, and expect that BUIP098 (enabling miner voting or emergency override for this feature) passes, although I do not think that CTOR is worth deploying.

The article linked above is poor quality. I don't have a time to endlessly debunk bad arguments, but please note at least two things:

1. There is no analysis whatsoever to show what the actual bottlenecks are. It could be network bandwidth, SHA256 merkle tree calculation, signature validation, or UTXO lookup. This "pivot" towards claiming CTOR is useful for sharding only solves the merkle tree calculation and signature validation portions. But if these are the problem, much simpler solutions exist.

2. The proposed architecture is fully realizable today, without the CTOR change.

3. The article does not explain how sharding would fully work. It grabs a small (and in my opinion, not that important) piece. What I mean is that to enable massive scalability we need an architecture where the block is NEVER fully assembled in any one machine and transactions are not broadcast to every node worldwide.