Gold collapsing. Bitcoin UP.

[freetrader]

@Roy Badami :
This "automatic replay protection" thing was first introduced in the May '18 upgrade, look at the bottom of
https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/may-2018-hardfork.md
and you'll see that it takes effect the first time for this planned November '18 upgrade.

It was renewed in the Nov '18 spec (remember, its optional) meaning its effect has now been postponed until May '19 for the clients that implement. Other clients have decided simply not to implement it.

---

About the wallet/node distinction, the term 'wallet' is used here to mean any wallet that could be an SPV wallet or a node itself, the reference is there to point out that wallets of any kind MUST NOT implement this protection change. Otherwise they would fork themselves off the chain in case of a successful upgrade.

I'm not convinced this mechanism ever had a solid rationale - certainly there was none given in the spec - but miners may differ on the practical benefits. I don't believe it makes a difference to the upgrade schedule in a material way since it is fully optional and already some clients have decided not to implement it.

 

[cypherdoc]

old clients will apply a different forkid which will make them incompatible with existing wallets.

this seems backwards. you mean that come Nov 15, all current ABC full node clients are expected to fork themselves off the network in deference to the new upgraded 0.18? if this is indeed the case, then b/c SV won't be implementing this auto-replay protection, they in fact will subject both ABC & SV chains to cross replay risk?

 

[freetrader]

b/c SV won't be implementing this auto-replay protection, they in fact will subject both ABC & SV chains to cross replay risk?

SV removed the change, so they stay compatible with the existing wallets just like upgraded ABC nodes do. And NayBC nodes, and BU nodes, and ...

 

[cypherblock]

That's an interesting statement. Calvin and Craig are the first miners who understand, but @shadders and @Otaci are too incompetent to transform their knowledge into code. Maybe then they are even more motivated to prove the opposite.

Does @Peter R know that @shadders was hired by nChain in large part for his work in simulating selfish mining?

 

[lunar]

@Bagatell

I think it's going to be brutal. There's no chance in hell Craig is going to back down. It's the Original Bitcoin Whitepaper version 0.1 or ashes.

Bitmain and ABC ""we will be forcing DSV on everyone to so as *not* to split" Verbal gymnastics if i've even seen them.

CToR Changes the block ordering, messes with the dynamics of of reorgs and fundamentally alters the original mining game theory.

The problem with this is if miners are colluding to set blocks up, then they are not *competing*.

The way mining/block propagation works is that there's really 2 kinds of races.
(1) Solving the block (2) block propagation and having it accepted.
(2) is not obviously seen at this current level of adoption, but as Bitcoin scales it becomes one of the key elements in network competition.

In other words
(1) race to solve a block (has various components).
(2) race to have your propagated block accepted by the majority of the network (has various components). CToR messes with this part of the original design.


The small world nature of the network emerges from incentives of miners to be as connected as possible to the rest of the network. (It's like a gravitational force pulling them together)
The connectivity of the miners, due in part to the need to seek each other out, and maximise profit (economic incentive)
If you break/alter the rate of orphans (Exactly what CToR is doing) the connectivity dynamic weakens considerably from the original design. Competition is the force that keeps it all together, agreeing not to compete is foolish, not to mention all the wallets and services that get bricked by a new ordering design.

r/btc and twitter are on #Crazy pills

To me ABC ruleset is a huge untested deviation from the original design. There appears to be quite a few BU members who have confused their hatred of one mans personality, with rational thought.

Do nothing. A simple blocksize increase. Or extended it with the SV re-enabled original opcodes are the only ways forward.

 

[lunar]

@Peter R invite sent. Welcome aboard.

what happens if neither the new ABC nor the new SV rulesets are adopted? By my reading of the terms, I think I would win. Do you agree?

Bet considered void and funds returned, if either ABC or SV capitulate and announce they are calling off the fork prior to 2018/11/10

The intent of this is pretty clear. No change, bets are returned.

I'm not a lawyer, and no wording is bulletproof, especially as it's meant to be a bit of fun, amongst colleagues. I certainly wouldn't want to win via an equivocation or a technicality, so if some obscure thing happens, that the text doesn't quite cover, I'll leave it up to the regulars here to decide, but let's err on void if in doubt.

 

[Bagatell]

@lunar

"To me ABC ruleset is a huge untested deviation from the original design."

And as I see it, SV is a wedge being driven between the BCH factions. CSW continues his mission to disrupt Bitcoin.

 

[Peter R]

That's an interesting statement. Calvin and Craig are the first miners who understand, but @shadders and @Otaci are too incompetent to transform their knowledge into code. Maybe then they are even more motivated to prove the opposite.

In hindsight, I think my tweet was a bit mean, because I do respect @shadders and @Otaci as developers. I didn't mean to imply that _they_ were incompetent, but rather that their leader CSW was incompetent and will screw up most of what he touches.

 

[Christoph Bergmann]

Got this response from @solex on Slack:

Today I talked with Bitcoin.de about the fork, and I said "BU wants to release a client with the option to support SV soon". Reaction: Whaat? Are you serious? There are ten days left!!!

Not having released a client with support of SV ten days before the fork makes you either siding with ABC or a fool. Sorry to say so. This is absolutely inacceptable. Andrew wrote a great proposal to deal with the fork, and I know very well that he and Andrea want to do the right thing and provide the right software. I know that you take this serious. But the software that exists right now is not much different than just kowtowing to ABC. It is an insult to BU membership votes.

 

[Peter R]

@Christoph Bergmann

There is only so much time and so many developers. Things can only move so fast. If you want things to move faster, then help make that happen.

Adding SV-support to BU is last-minute because SV itself was last-minute.

 

[Christoph Bergmann]

@Peter R

I know. I don't intent to insult anybody, I know how difficult and stressy all of this is for the developers, and I am aware that they need to make decisions, which can be terribly wrong, no matter what you do, and I feel very sorry that I feel no other choice than to stress this out publically.

Things are like things are: BU software supports ABC, while giving users, miners and exchange no chance to test SV support with the needed diligence. Intentional, or not intentional - it sides with ABC, which seems highly contrary to the feature preferences BU members indicated in votes.

 

[Peter R]

@Christoph Bergmann

I agree that the way things rolled out gave ABC the advantage over SV (I'd say "doing nothing" is equally advantaged though). But ABC had their ducks in order earlier than SV so this is a natural consequence. Had SV been more organized, and ABC less organized, I suspect the situation would be different.

 

[cypherdoc]

this seems like a good time to bring this back up. I like it:

https://github.com/bitcoincashorg/bitcoincash.org/blob/5f087230d2d2aafa0490fe6cf58c807f8d8c31ba/spec/bip-adaptiveblocksize.mediawiki

 

[Christoph Bergmann]

@Peter R

Like every discussions these days it ends with "CSW / nChain is so bad". Like this was the answer for everything.

I don't care about faults. I care about the state of reality: BU members already support the idea that you don't need any hard limit to keep Bitcoin stable. If not, they should have left long ago (like every ABC dev, obviously). With the last fork they also accepted the reactivation of the old OP_Codes (not a fan myself, but in the end I accepted it). At the same time BU members voted very strongly against CTOR. This makes SV, independently of nChain or CSW, much closer to the will of BU membership than ABC.

That the real software defaults on CTOR and gives users not even the option to use SV, is a slap in the face of memberships. The whole "voting", and the whole "decentralized development" thing seems nothing but a charade to deflect from the fact the Amaury is the (non-benevolent) dictator of BCH.

I don't care about whose fault it is. This is the state. As it seems, the Nov 15th fork does not only harm the brand of Bitcoin Cash and split / reduces the community, but also destroys the vision of BU as development driven by membership-votes. And all that was needed was one unpopular individual supporting a popular vision.

 

[Peter R]

@Christoph Bergmann

I believe I understand your frustration. I just got off a call with a Coindesk reporter about the Nov. 15th fork. She asked "if you don't want CTOR and if you eventually want to implement the upgrades SV proposes anyways, why are you so opposed to SV?"

And I told her that at this point it wasn't about software or technical debate, but really about politics and power. That it was my opinion that SV was using what they perceived as pent-up frustration to "devs gotta dev" to cause a schism in the community from which they could take further control. And I felt a bit odd saying this, because my earlier mantra was "it's not about personalties" yet clearly the personalities behind SV affect the choices I make (I don't want to have anything to do with SV).

I think @chriswilmer made good points about this a few days ago. It no longer matters to me what SV proposes technically. I am convinced they are bad actors and that their interests are NOT aligned with mine, regardless of how things may appear or what they may say.

But yeah this whole thing is very weird and I feel pulled in several directions at once. Like I told the Coindesk reporter: "if it were up to me, we would do nothing at all on November 15th."

 

[Norway]

It would be great if the next BU client could be put in RXC mode (Ryan X Charles' latest suggestion) but I guess the time frame is too short.

 

[Christoph Bergmann]

@Christoph Bergmann

I believe I understand your frustration. I just got off a call with a Coindesk reporter about the Nov. 15th fork. She asked "if you don't want CTOR and if you eventually want to implement the upgrades SV proposes anyways, why are you so opposed to SV?"

And I told her that at this point it wasn't about software or technical debate, but really about politics and power. That it was my opinion that SV was using what they perceived as pent-up frustration to "devs gotta dev" to cause a schism in the community from which they could take further control. And I felt a bit odd saying this, because my earlier mantra was "it's not about personalties" yet clearly the personalities behind SV affect the choices I make (I don't want to have anything to do with SV).

I think @chriswilmer made good points about this a few days ago. It no longer matters to me what SV proposes technically. I am convinced they are bad actors and that their interests are NOT aligned with mine, regardless of how things may appear or what they may say.

But yeah this whole thing is very weird and I feel pulled in several directions at once. Like I told the Coindesk reporter: "if it were up to me, we would do nothing at all on November 15th."

Thank you for the honest reply. I know how you feel about CSW - I think I was one of the first supporting you outcalling him despite negative financial effects for BU - and I'm well aware how difficult the situation is for you and for the other seniors of BU. You are much deeper in the personal affairs behind the scenes, and I absolutely believe that your decisions based on certain personalities are made on experiences and good reasons. As I am absolute certain that Andrew, Andrea and other developers of BU try hard to provide the best solution for users and BU members in these difficult circumstances.

But still, I'm speechless, and, honestly, somehow dissapointed. It reminds me when I asked No2x-people about their motivations. Nobody said they are against the hardfork, some even absolutely wished it, but nearly everyone said it was about people, politics and power grabs, some explicitly explained it with hate towards Roger Ver. We are back where we have started, feels like having joined a revolution and seeing the comrades march into the counter-revolution ... let personalities make you decide against what you want.

I think at this point there is nothing to change. Exchanges made their statements based on developer authority and social-media campaigning, like we know it well from our fights inside BTC. I personally find myself hoping that there will be a hashwar, because ABC getting a controversial hard / soft fork without fighting destroys fundamental values of Bitcoin Cash in my view ... If BCH resists this attempt to developer-reingeneering I will be very optimistic that it is the true hard anarchist Bitcoin chain. My trust in BCH would explode ... but maybe I'm just wrong, and the markets and users will love ABC-Coin ... who know's?

@Norway RXC's solution is beautiful in theory, but impractical for exchanges. If we had half a year to go, maybe. But right now exchanges only want to have their ticker symbol compatible with Coinbase and the option to securly split chains without too much effort - which is a really hard mission to get accomplished until Nov 15th, especially for smaller exchanges.

BCH is a sidecoin, not the main source of exchange's income, and an exchange has much better plans to invest their developer's time than to babysit the stability of a minor-volume coin.

That's just another dimension in which the Nov 15th fork is nothing but stupid. It risks everything for nothing, and I'm not very optimistic for a project which has chosen a dictator with such a bad, dumb risk assessment ... It's not just that ABC's success will establish a form of dictatorship on the protocol, it will also be a dictatorship which acts dumb when it comes to the whole picture of BCH ... but again, maybe I'm wrong, as I have been so often ...

 

[cypherdoc]

"if it were up to me, we would do nothing at all on November 15th."

i'm surprised this alternative hasn't been discussed more. assume for a moment that's what happens; then come May, @imaginary_username's or Bitpay's original adaptive blocksize algo is proposed. i'd be for that.

 

[freetrader]

 

[79b79aa8]

it is a deeply engrained academic instinct that an entity whose actions (or more precisely the actions its agents) include obfuscation and laxity with the truth is immediately to be mistrusted and if possible ignored.

on the other hand, it is plain to see that:

(1) during 2018 BCH hashrate and difficulty growth did not keep up with the BTC chain. this is presumably a consequence of the anomalous fact that sha-256 miners are mining on the BTC chain because of profitability, while simultaneously "supporting" BCH. this situation is neither stable nor favorable for BCH. it can't continue for another year; a correction is necessary. to go no further, it is not economically favorable to live under permanent threat of chain upheaval/takeover. to support a coin is to permanently mine it, not merely to be able to mine it if it were more profitable short term or if you needed to throw your weight around at sporadic junctures -- such allegiances must be counted as fickle and short-lived.

so either the nChain mining complex establishes it has the majority BCH-dedicated hash and rightly gets to block off ABC's ability to dictate rule changes, or it manages to permanently attract back sufficient hashpower such that it fails to hold on to a majority, but significantly and permanently increases BCH's hashrate and security (in this case it loses on the ruleset specifics, but given the expected impact of the changes, this is acceptable).

i see a win/win from nChain's perspective. the fact that it has employed diversionary, epistemically dubious tactics to set this situation up is of secondary importance.

(2) the ABC roadmap/upgrade schedule/way to organize work will not continue moving forward. to respond to the present face-off saying "present your proposals on time and we'll consider you for the next upgrade in may" is absolutely naive and tone deaf. ABC will scarcely be in the same position of control by may (and the present situation is not really a form of control). or if it still retains a semblance of control, it is because some very significant hashpower moves over to BCH and choses to continue using its client -- but any big BTC miner / coalition prepared to do this, can also easily do away with ABC's services and have in-house development.

in sum, it apparently needed repeating that if you want to the ability to dictate, you must have the hashpower to back you up. you can't expect to dictate with phantom hashpower that may or may not move over to cover you.