Gold collapsing. Bitcoin UP.

[Christoph Bergmann]

Better ways of deploying change have been proposed, no compromise from SV.

SV asked for a delay of the fork, ABC rejected BIP135 too.

p.s. @Christoph Bergmann : I don't think a particular method for UTXO commitment is the primary driver for ABC to push for Merklix. You should do some more investigation - I would suggest you try to get @deadalnix to sit down with you for an in-depth interview to hash out the questions you have around Merklix + their entire strategy. I hope he would be willing to give you 1 or 2 hours.

My feeling - I've also not talked this through but it's from what I've read up to now - is that he wanted it more for 2 reasons:
a) data structures efficiency
b) more options for fraud proofs

The first one might make sense to me if demonstrated that at very large scale, this structure would have great benefits over current Merkle tree.

The second one I'm not so sure we need, with the other suggestions already available around fraud proofs that don't depend on changes to the data structure.

But I may be out of the loop on the UTXO commitment developments. If someone can confirm whether that's part of the reason for introduction of Merklix, that would be appreciated.

That's why I said, out of my head and possibly wrong. Disappointing to hear that it has nothing to do with UTXO commitments. I had an interview with Tomas, in which he told me he hopes that the protocol changes for UTXO commitments go in the fork for Nov ...

Anyway ... I think you don't fully understand what I wrote ... I don't know if I continue to be so much interested in BCH after the Nov fork. For sure I will stop fighting the "bcash bcash centralized shitcoin" trolls, and for sure I will have less love for it.

Like at least half of the German BCH community attending my blog and some other social media sources I frequent. You will lose support for gaining NOTHING, and if there is one thing BCH needs more than everything else, it is SUPPORT. It is already very low ... I think you still do not realize all this ...

 

[awemany]

Right now, after weeks of controversy, I did not see a single indication of self-reflection from ABC. Instead, @Mengerian proposes to tighten the feature freeze deadline and already asked to discuss the May fork.

In general, I agree with your assessment here. But ironically, what Mengerian is doing here could actually be him learning from past mistakes: I believe he wants to make the next HF go through smoothly, so he brings up the potential points of contention early. (@Mengerian?)

I agree with the 6 month schedule being way too tight for such large changes.

What I would rather like in May is smaller changes that would allow to simplify the code base. For example, getting rid of the now-introduced TX minsize requirement by implementing Sergio Demian Lerner's solution with new network messages for SPV clients would make a lot of sense, IMO.

 

[solex]

Three months after BCH was launched, a meeting was arranged of developers who supported the big-blocker vision, which led to the fork. It happened in London in November 2017. There was relatively short notice (a few weeks) so the BU developers could only attend via video. nChain was well represented with CSW and several colleagues present. As everyone can imagine, there was a lot of enthusiasm for making scaling improvements, and other changes to attract adoption. This was and still is necessary to overcome the massive inertia of BTC's network effect. A lot of ideas were discussed as it was the first such Bitcoin dev meeting where Core could not veto changes.

At the meeting @theZerg proposed rolling 6-month HFs (general upgrades) so that BCH could advance much more rapidly than it would via a miner voting process. ABC and nChain were in firm agreement as well. It worked well for 15 May, excepting that BU's own proposed changes (OP_Group and DSV) were put on the back-burner at that time.

Because the 15 November changes are proving extremely contentious, BU has pivoted to the BIP135 miner voter process in order to provide a mechanism to avoid similar problems in future.

 

[freetrader]

@Christoph Bergmann
From what I read so far the entire big blocker scaling movement, its various groups like XT, BU etc. had very little support traditionally in the German Bitcoin community, which is a great pity but it doesn't surprise me at all that Bitcoin Cash still has minority support there - as in many other places.

I've heard that the first Bitcoin ATM was only put up very recently in Germany (Munich), due to large regulatory uncertainty...
If so, Germany is somewhat behind the curve when it comes to mainstream acceptance of Bitcoin.
But I expect that to change, and if Bitcoin Cash performs as it should, then community support and sympathy will slowly grow.
Especially the more BTC's store-of-value ponzi / hodler mentality is exposed as flawed.

 

[Christoph Bergmann]

@awemany

Yes, it is highly ironic, that @Mengerian tries to learn but only demonstrates that he does not understand / recognize the problem.

It reminds me of when our government does something the citizen dislike, and "learn" - not that they should do better things in the future, but that they should "communicate" better.

@freetrader

Yes, unfortunately, BCH support in Germany is very small, but not non-existent. Example: 230 people bought my book directly on my website. From them, 115 paid with bank transfers, 60 with BTC and 22 with BCH. That's not that bad, isn't it? But you need to consider that I'm well known as a "bcash shill" and so on. The Nov 15th fork will highly damage the already low support.

Another metric is node count. According to bchnodes.online, Germany has 17% of BCH nodes, second place after the US, more than 3x as much as the next European country.

Another example: Beside me, in German crypto media you only find the Bitcoin Informant, a youtuber, to be BCH friendly. You have exactly one guess where he stands on the debate ... he takes the same side as the few pro-BCH readers who comment since the beginning of BCH or earlier ... I know about two more or less active BCH developers from Germany, who are ok with the Nov 15th fork, but would not mind skipping it, if I get this right.

Again: BCH does in no way lack transactional capacity. It already has a vast oversupply. What it lacks is support to create demand for the capacity it provides. The Nov 15th fork does harm support for - somehow, nebulously, theoretically - creating even more unwanted overcapacity, while installing a dictatorship that thinks this is a wise move to progress.

 

[Peter R]

I came here to rant
but you beat me to it .

still not a peep of acknowledgment from BCH devs about the destructiveness of q6mo hard forks . Nov 15 will come and go. get ready to fight/escalate some more.

I think most BU and XT devs prefer moving to BIP135 and away from the 6-month hard forks.

I've been getting pinged more frequently lately "why can't we stop the fork Nov. 15?" It's been my preference to stop the November fork since it became so contentious -- and with BU miners can do just that. What else can we do (as BU)?

I think only a coalition of miners with support from Jihan could stop the fork at this point.

 

[freetrader]

@awemany
Again: BCH does in no way lack transactional capacity. It already has a vast oversupply. What it lacks is support to create demand for the capacity it provides. The Nov 15th fork does harm support for - somehow, nebulously, theoretically - creating even more unwanted overcapacity, while installing a dictatorship that thinks this is a wise move to progress.

I don't disagree with this. I think it unfortunately applies to both sides of the 'war'. Whoever wins this has won it on a platform of changes aimed at increasing the capacity (this is not bad but goes to show the difference between them is not that big). Either way it will put BCH in a situation where there is more entrenched development control than before. This is bad, and why I supported BIP135 too and would like to get away from the 6-monthly forced forks. The intention at the beginning was definitely aim for a predictable schedule of regular upgrades. Back then, this model was also performing well in Monero and others.
Since then, we've seen contentious battles in those coins too (e.g. over ASICs in Monero) showing that it's not always smooth sailing. They are also more centralized in terms of development teams, making decisions easier.

I don't think any well-intentioned voices calling for postponing of the fork can deter Craig Wright. If he's not actively taking the decisions, then he is a spokesperson for whoever is. And he is saying he will not let up. He is prepared to escalate by any means available to him.

If they muster a majority of BCH hashpower and use it to defraud exchanges and other businesses to make the SV chain win, then I will observe the reaction of the ecosystem. If they do not care, they deserve to live under such a system, and I may choose to exit.

If the majority of users deems the majority of the BCH mining population to be dishonest and/or harming the interests of the currency, then I won't be opposed to measures to ensure that honest miners are once again placed in control of Bitcoin.

The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the
hash begins with a number of zero bits.

[doublepost=1541591405][/doublepost]

@awemanyAnother metric is node count. According to bchnodes.online, Germany has 17% of BCH nodes, second place after the US, more than 3x as much as the next European country.

Yes, certainly due to a good Internet infrastructure and favorable hosting environment attracting customers from all over the world.
Unfortunately that doesn't translate into local support...

 

[cypherdoc]

@awemany

Yes, it is highly ironic, that @Mengerian tries to learn but only demonstrates that he does not understand / recognize the problem.

It reminds me of when our government does something the citizen dislike, and "learn" - not that they should do better things in the future, but that they should "communicate" better.

@freetrader

Yes, unfortunately, BCH support in Germany is very small, but not non-existent. Example: 230 people bought my book directly on my website. From them, 115 paid with bank transfers, 60 with BTC and 22 with BCH. That's not that bad, isn't it? But you need to consider that I'm well known as a "bcash shill" and so on. The Nov 15th fork will highly damage the already low support.

Another metric is node count. According to bchnodes.online, Germany has 17% of BCH nodes, second place after the US, more than 3x as much as the next European country.

Another example: Beside me, in German crypto media you only find the Bitcoin Informant, a youtuber, to be BCH friendly. You have exactly one guess where he stands on the debate ... he takes the same side as the few pro-BCH readers who comment since the beginning of BCH or earlier ... I know about two more or less active BCH developers from Germany, who are ok with the Nov 15th fork, but would not mind skipping it, if I get this right.

Again: BCH does in no way lack transactional capacity. It already has a vast oversupply. What it lacks is support to create demand for the capacity it provides. The Nov 15th fork does harm support for - somehow, nebulously, theoretically - creating even more unwanted overcapacity, while installing a dictatorship that thinks this is a wise move to progress.

to me, its the constant tinkering that makes any crypto distrusted at this point. a simple point but deserves repeating ; money needs to be stable and predictable. when BCH devs introduce major concensus changes every 6mo that clearly have not been tested on any scale it's unnerving, I'm sure, to any large businesses whose previous assumptions could be affected. as the disagreements have ratcheted up these last 6mo I agree with amaury that we need to focus on the big problems, of which none bigger than the limit. imagine the fight several years from now when BCH devs decide its OK to finally deal decisively with it. maybe just maybe, they will never decide its OK.

this is great from Blockstream :

https://i.redd.it/g93vimfs2ww11.png
[doublepost=1541598577][/doublepost]I know I know, the software can't handle it! my answer? remove the limit anyway and we'll deal with any problems as they come up. necessity is the mother of invention.

 

[SPAZTEEQ]

Bitcoin was well on the way in 2015. Then Core. Imagine that all roads lead to fail now unless this: "remove the limit anyway and we'll deal with any problems as they come up. necessity is the mother of invention". ie excising completely the pre 8/1/17 narrative might be the only way left now to get back on track (to show the rest of the world BCH means business).

 

[Christoph Bergmann]

I know I know, the software can't handle it! my answer? remove the limit anyway and we'll deal with any problems as they come up. necessity is the mother of invention.

BU already did this, SV proposed something very similar. But heck, "people".

 

[cypherdoc]

please set these for me then :

1. AD (for EAD) Integer
2. BV (for FGS if BIP100 emulation active) Float, see note (ii)
3. EB (for EBS) Float
4. FG (for FGS if BIP100 emulation inactive [default]) Float, see note (iii)
5. MG (for MGS) Float

 

[chriswilmer]

"I've been getting pinged more frequently lately "why can't we stop the fork Nov. 15?" It's been my preference to stop the November fork since it became so contentious -- and with BU miners can do just that. What else can we do (as BU)?"

My problem with being worried about anything being "contentious" is that there are people who manufacture contention exactly to stop us from doing anything. It would not have mattered whether it was about CTOR or any other issue... the people who want Bitcoin to fail will create division among us by any means necessary, and they find any and every excuse to do so.

My prediction: Once Bitcoin Cash is working really well... the same folks that have been opposed to changing anything will be instead advocating for constant change, because they will switch from preventing us from improving Bitcoin Cash to trying to get us to destroy something that works (kind of how Lighting/Segwit is degrading the BTC network).

 

[Bagatell]

@chriswilmer

Spot on.

 

[satoshis_sockpuppet]

to me, its the constant tinkering that makes any crypto distrusted at this point. a simple point but deserves repeating ; money needs to be stable and predictable. when BCH devs introduce major concensus changes every 6mo that clearly have not been tested on any scale it's unnerving

I very much agree with you. Imho the ideal plan for the next 6 month should be something like:

a) Prepare a final solution for the blocksize limit. (I am pretty sure virtually everyone can get on board with some variant of the "Bitpay" solution). (Also remove the 32 MB protocol limit at this point.)
b) (Re?)introduce miner voting for (potential) new features in the future (e.g. OP_CHECKDATASIGVERIFY would be something that should have been just included anytime miners agreed on it).
c) Use the next HF to do implement these exact two features and freeze every other feature request.
d) Get rid of the 6 month HF schedule.

After that, devs can dev around as much as they want and if a new consensus changing feature is found to be good, miners can include it by using miner voting. (for example all the fancy stuff ABC is planning to do).
But from my point of view it looks like there is huge ton of work to be done that isn't consensus critical at all. I'd say the reason that we do not have the possibility for 1 GB blocks tomorrow isn't that the protocol has to change but that the clients and possibly the hardware of the usual node has to get better.

The ABC devs and some other devs seem to think, that leaving your mark in the BCH protocol will make you the next superstar or something. I'd say avoiding bugs and just bettering the client like the XT guys (and apparently more and more BU) do is the real awesome work that needs appreciation.

We all know, that the current implementations based on the C++ client are still full of a lot of crap in the sense of code quality wise. Imho there should be more clean up, bug hunting, improvements and not a new feature every other month.

 

[Mengerian]

In general, I agree with your assessment here. But ironically, what Mengerian is doing here could actually be him learning from past mistakes: I believe he wants to make the next HF go through smoothly, so he brings up the potential points of contention early. (@Mengerian?)

Yes, exactly. I'm just trying to start discussion about possible upgrades for May 2019 and beyond. It seems part of the problem this time was that the proposed changes weren't adequately discussed, analyzed, etc. by the broader community well in advance before ABC had implemented it. Seems better to discuss first!

(What's ironic about me doing this, by the way?)

I agree with the 6 month schedule being way too tight for such large changes.

What I would rather like in May is smaller changes that would allow to simplify the code base. For example, getting rid of the now-introduced TX minsize requirement by implementing Sergio Demian Lerner's solution with new network messages for SPV clients would make a lot of sense, IMO.

Yeah, I pretty much agree. It seems unlikely that the Merklix stuff will be ready in time for May 2019. I'm raising it because I think it's important for long-term massive scaling. If we never talk about it, or work on it, then it will never be ready. Fixing the min Tx size, as you suggest, seem like a good idea to me.

Yes, it is highly ironic, that @Mengerian tries to learn but only demonstrates that he does not understand / recognize the problem.

What is "the problem", @Christoph Bergmann, according to you?

My problem with being worried about anything being "contentious" is that there are people who manufacture contention exactly to stop us from doing anything.

Yup, I agree with this.

 

[Christoph Bergmann]

@Mengerian

Skipp through my last posts in this forum. I explained it over and over and over. I don't think saying it another time will help.

Oh, I have a hint for you:

It seems part of the problem this time was that the proposed changes weren't adequately discussed, analyzed, etc. by the broader community well in advance before ABC had implemented it.

One of the problems was that a part of the community do not want the changes, but you insist on enforcing them anyway. If you seriously want to answer this with throwing "more discussion" on it, you could have done it by just delaying the Nov 15 fork. But you did not.
[doublepost=1541609587][/doublepost]

I very much agree with you. Imho the ideal plan for the next 6 month should be something like:

a) Prepare a final solution for the blocksize limit. (I am pretty sure virtually everyone can get on board with some variant of the "Bitpay" solution). (Also remove the 32 MB protocol limit at this point.)
b) (Re?)introduce miner voting for (potential) new features in the future (e.g. OP_CHECKDATASIGVERIFY would be something that should have been just included anytime miners agreed on it).
c) Use the next HF to do implement these exact two features and freeze every other feature request.
d) Get rid of the 6 month HF schedule.

This would be the only result that would keep my enthusiasm for BCH alive. @Mengerian, you wanted to discuss the next fork as early as possible, what do you think? Are you willing to vote against the currently proposed changes in favor of this?

 

[Bagatell]

"you could have done it by just delaying the Nov 15 fork."

I don't think @solex s present incumbency gives him that authority. Ponting fingers wont help.

 

[Bagatell]

https://www.reddit.com/r/btc/comments/9v2ail/core_seems_to_be_courting_csw/

 

[awemany]

@Bagatell: This smells fishy and atypical for Greg. I suspect it is a fake.

 

[Bagatell]

@awemany

quite possible but who knows these days.