Gold collapsing. Bitcoin UP.

[Richy_T]

@jtoomim: by natural order I mean the order the blockchain is already in. There is only one possible ordering because it's an event that's already happened.
[doublepost=1534714431][/doublepost]More broadly, I think the term "natural ordering" is useful. It could be defined precisely as the order in which transactions entered a node's mempool. Indeed, my node's natural ordering may be different than your node's natural ordering, but I don't think that makes the concept less useful.

It's worth noting that "natural ordering" already is used in database nomenclature and it means providing a result in whatever order the data is stored in, not sorted in any particular manner. Often this will mean time sorted (but sometimes not depending on database transactions that have occurred [these transactions typically do not apply for blocks which are write-only]). I think it's fair that it's used in the manner that it has been in this discussion. It is a term of art and we should not shy from using it.

 

[cypherdoc]

i think we continue what has worked heretofore; continue the blocksize increases. i'd rather remove it altogether right now but 128MB is a good start if it makes the miners more comfortable. i don't think many ppl know what @deadalnix is up to as he's so non-communicative. i don't think i've ever read a true technical discussion from him. and there are too many questions around CTOR right now to shove it thru.
[doublepost=1534819483,1534818504][/doublepost]imo, the fundamental makeup of the big blockist is one who understands and trusts the financial incentives surrounding miners and PoW mining. the year's long debate was about making it possible for miners to transition from rewards to tx fees according to the original vision as outlined in the WP. this was the solution to the Byzantine's General problem we all became enamored with which solved concensus across a hostile internet. we split from BTC b/c devs got out of hand; the devs gotta dev syndrome. ABC is dangerously careening off towards becoming that same problem. even BU got carried away with GROUP & OP_GROUP. if the choice comes down to choosing btwn implementations introduced by miners (Coingeek and nChain) vs devs, devs are gonna lose, imo, esp when the miner proposal is primarily about increasing to 128MB and beyond as a first priority.

 

[wrstuv31]

Favoring Canonical Ordering implies that preserving the order of arrival does nothing to help grow the network effect of money. At the very least it implies that the network propagation savings provide a greater benefit to the network effect than preserving the order. I am against Canonical Ordering until I can understand how it alters the sound money network effect.

It's very strange that people are pushing for this change during these times, nothing was learned. All BCH needs is use, not change.

 

[sickpig]

if the choice comes down to choosing btwn implementations introduced by miners (Coingeek and nChain) vs devs, devs are gonna lose, imo, esp when the miner proposal is primarily about increasing to 128MB and beyond as a first priority.

you should first asses if ABC has miners support and if this is case you need to measure it.

 

[Tom Zander]

I don't know if anyone actually wants to split the chain, but it is clear that various parties are finding their ability to write code not enough, they need to feel that the miners will follow them blindly like they did Core. Because a developer has no power since people can just choose to not run their code. The developer only has power that is given to them by the people that the developer serves.

There is a very strong parallel with an Rand book where those parties are like the big publisher Gail Wynand who finds out he has no power when he finally wants to go against his readership.

The following months are going to be interesting as there will be 2 or 3 incompatible clients all hoping to be the one that miners run.

I expect lots of behind the scenes chatter.

 

[freetrader]

Maybe it would help to suggest a concrete coinbase signaling in advance of the next upgrade.
Something like -X and +X to indicate aversion or support for a feature, and a list of features. Absence of signaling for a feature would indicate neutrality on that item.

Here's what I would see if you (miner) wanted to be compatible with ABC [1, 2]:
+32MB+CTOR_LEXICAL+OP_CHECKDATASIG+OP_CHECKDATASIGVERIFY+100B_MINTX+PUSH_ONLY

And here's what I see CG/nChain currently proposing [3]:
+128MB+OP_MUL+OP_LSHIFT+OP_RSHIFT+OP_INVERT-OP_GROUP+NO_201_OPS_SCRIPT_LIMIT-OP_CHECKDATASIG-OP_CHECKDATASIGVERIFY-CTOR_ANY

And @Peter R 's current "compromise" proposal tweet [4]:
+OP_MUL+OP_LSHIFT+OP_RSHIFT+OP_INVERT-CTOR_ANY-OP_GROUP+BIP101

BU's current default position would probably need to await clarification in the upcoming voting round.

We might need to compress these down a bit for length, and some items would be mutually exclusive, like BIP101 and the 32MB / 128MB options. The "BIP101" would probably also need to be renamed and fleshed out because it would likely differ a little from to the original BIP101.

[1] https://www.bitcoinabc.org/2018-08-20-announcing-bitcoin-abc-0-18-0/
[2] https://github.com/bitcoincashorg/bitcoincash.org/pull/94/files
[3] https://coingeek.com/statement-calvin-ayre-coingeek-bitcoin-protocol/
[4]

 

[Norway]

FYI: The 128 MB proposal from nChain is part of a roadmap.

Nov 2018: 128 MB
May 2019: 512 MB
Nov 2019: 2 GB
May 2020: No limit

My spidey senses tell me that we will not get a persistent split in november, and nChain will get their will. Because nChain/CoinGeek is prepared to do a chain split, and the other miners are not. But I could be wrong.

 

[freetrader]

Bitmain also issued a roadmap for what they'd like to see. Maxblocksize is ahead of their stated preferences.

https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/

Time Block size, Byte
Now 1,000,000

2017 Aug 2,000,000
2017 Sept 4,194,304
2018 April 5,931,641
2018 Aug 8,388,608
2019 April 11,863,283
2019 Aug 16,777,216

After 2019 Aug Depends on further research

They said at the time they'd like to see weak blocks "before the block size increase reaches 8MB". So weak blocks was clearly on their idea of a roadmap at the time.

Not that it's a consensus item (being pre-consensus), but nChain/CoinGeek seem have excluded that from their roadmap through previous declarations.

 

[cypherdoc]

you should first asses if ABC has miners support and if this is case you need to measure it.

agreed. @Jihan apparently favors ABC as of last week. but i doubt he'll risk a chain split.
[doublepost=1534862953,1534861960][/doublepost]again, this mandated q6mo hard fork schedule is causing everyone to crawl all over each other.

 

[79b79aa8]

Maybe it would help to suggest a concrete coinbase signaling in advance of the next upgrade.

or adopt BIP135? (except it would need to be deployed across implementations, and that sounds distant ATM).

 

[Richy_T]

even BU got carried away with GROUP & OP_GROUP.

I think we got carried away with xthin too. It's a great idea but issues in its implementation greatly damaged inertia that BU was building. Hindsight is 20-20, of course.

 

[theZerg]

https://www.reddit.com/r/btc/comments/994ski/buip098_bitcoin_unlimiteds_proposed_strategy_for/

 

[sickpig]

I think we got carried away with xthin too

IMHO it was a fair risk to tale, we needed to do something back then to shake the status quo.

 

[theZerg]

@Richy_T, @cypherdoc Hindsight is selective. The introduction of a significant technology like Xthin showed that we could compete on a feature basis with Core, creating huge excitement at a time when the movement was stalling and brought funding that is still sustaining us today due to our careful use of it.

The exploitation of bugs did damage the movement that the feature helped build. But what about all the prior Core bugs? What about the recent ABC hard-forking bug created in the service of no feature at all (just code cleanup AFAIK)? No damage for arguably worse bugs. The situation is more complex than your pithy summarization. In particular, the bugs were a convenient excuse for swing miners that had more investment in altcoin mining and so were dramatically benefiting by BTC stagnation.

Current tokenization proposals can be, and in some cases already are, easily deployed onto other blockchains. They offer BCH no competitive advantage. People may use them because they are already on BCH or use them as an on-ramp, but they aren't going to use BCH to gain access to these tokens. They are undistinguished, dropping into a competitive landscape of altcoin token solutions. If we had deployed Group tokenization, we might have needed to fix a bug or two (but maybe not because the team is much more experienced with this codebase), but like Xthin that would be small compared to the value it brought.

 

[sickpig]

Graphene specification draft has been published

https://www.reddit.com/r/btc/comments/995mu4/graphene_specification_draft_released/

 

[Richy_T]

The exploitation of bugs did damage the movement that the feature helped build. But what about all the prior Core bugs? What about the recent ABC hard-forking bug created in the service of no feature at all (just code cleanup AFAIK)? No damage for arguably worse bugs. The situation is more complex than your pithy summarization. In particular, the bugs were a convenient excuse for swing miners that had more investment in altcoin mining and so were dramatically benefiting by BTC stagnation.

I agree. The mistake was a combination of trying to build complex stuff on top of crappy code (which I am not trying to hang on Core since much came out of Satoshi but at the same time, Core have been slack about getting the code in good shape) and the timing of the push to release to production. It was completely understandable but at the same time, it was a mistake. The bug exploit came at a time when BU was pushing 50% of blocks and possibly getting to a tipping point. There's not much point wondering about "what ifs" but it definitely wasn't helpful.

We could go into how it could have, perhaps, been avoided but that is case specific. I think there's a broader lesson to be learned about rushing to integrate new technologies though and, perhaps more importantly, priorities.

 

[AdrianX]

he "BIP101" would probably also need to be renamed and fleshed out because it would likely differ a little from to the original BIP101.

if you time it right you can get BUIP101

 

[Peter R]

@Richy_T

It was Xthin that put BU on the map as a real competitor to Core. Without Xthin, Core wouldn’t have been forced to compete by releasing Compact Blocks, and arguably block propagation would still be like it was in 2014 when even sustained 4 MB blocks would stress the network.

It was also the Xthin work that lead to the 750 BTC donation that allows BU to organize conferences, fund projects, and do community outreach. Without Xthin, I wouldn’t be surprised if BU would have already shutdown.

 

[AdrianX]

Bitcoin politics. We all understand the notion of cooperation and the 51% attack and that security is a result of incentivized cooperation that results in consensus, and that is the only guarantee there is.

So we look at the hash rate distribution as a measure of confidence.
The skeleton in the closet is the 51% hash security model is predicated on the notion that the consensus rules are set in stone. (they haven't been, yet.)

The result developers in charge of code have an advantage when it comes to changing rules. And more so when we have a Hard Fork (an essential commitment to upgrade and accept changes whatever they may be.)

We need to be vigilant and avoid the 51% ring of power (the code/implementation that controls them all) It is more dangerous than the 51% hashrate distribution as we've seen with Core it developers are not invested to the same extent as miners. As a side note, I'm excited to see Bitcoin SV, enter the bitcoin space it's degrading that ring of power.

The politics around changes in bitcoin hinges around developers lobbying/leveraging the exchanges and business to use there software. (this is what people object too when thinking of nChain'spatents)

If you have 51% of the hashrate running your software you have the power to force the miners to follow your changes by getting the industry to pressure miners to pick your fork.

The Ring passed to Isildur, who had this one chance to destroy evil forever, but the hearts of men are easily corrupted. And the ring of power has a will of its own. It betrayed Isildur, to his death. And some things that should not have been forgotten were lost. History became legend. Legend became myth.

Locking the layer one protocol can't come soon enough it's figuratively the tale of the Lord of the Rings.

The ring cannot be destroyed, Gimli, son of Gloin, by any craft that we here possess. The ring was made in the fires of Mount Doom. Only there can it be unmade. The ring must be taken deep into Mordor and cast back into the fiery chasm from whence it came. One of you must do this.

I'm liking BUIP98 particularly after reading this
Exchanges payment provides merchants, and other businesses need stability they can't be following fork politics.

What BU has done in the past and BUIP98 does now is it minimizes the politics, it removes the Exchanges payment provides merchants and other businesses as a tool to leverage miners into following developers.

It gives the miners the freedom to direct hashrate without businesses having to worry or about being orphaned by a >1MB block, or having to pick ABC or SV.

 

[Richy_T]

@Richy_T

It was Xthin that put BU on the map as a real competitor to Core. Without Xthin, Core wouldn’t have been forced to compete by releasing Compact Blocks, and arguably block propagation would still be like it was in 2014 when even sustained 4 MB blocks would stress the network.

It was also the Xthin work that lead to the 750 BTC donation that allows BU to organize conferences, fund projects, and do community outreach. Without Xthin, I wouldn’t be surprised if BU would have already shutdown.

Right. I'm not against xthin. Was that donation contingent on pushing out a version of BU for which xthin was opt-out for all nodes though? Could there have been a benefit to taking things more slowly, rolling things out on a slow schedule and perhaps waiting a little before going to production when more and more BU blocks were being produced week-on-week and prioritizing getting a block size limit increase over deploying new tech that there was not an immediate need for?

And I'm as much against Core as anyone but they did produce compact blocks (even as an emergency catch-up scramble) and it didn't cause every Core node on the network to crash. The optics weren't good.

Anyway, the point isn't to reopen old wounds but to provide some perspective on looking to the future.