Gold collapsing. Bitcoin UP.

[cypherdoc]

i get the sense johoe is a big blocker; despite what his boss thinks:

https://github.com/trezor/trezor-crypto/pull/120#event-1558280450

 

[Windowly]

Regardless of whose fault it was that BitcoinABC got their foot first out the door with a Bitcoin Cash client in the beginning, BU Bitcoin Cash clients seem often to be released after the BitcoinABC clients. One example is now, when it doesn't seem like there is a BU client yet that is compatible with the May15th BCH upgrade.

What are the reasons for it and is it possible to get upgrades out faster?

On reddit it seems a lot of BU fan node owners switch first to BitcoinABC because BU clients is late in coming out.

 

[freetrader]

Nevertheless, a fuller record of the history around how Bitcoin hardforked is of importance to me.
I realize these accounts are always influenced by individual perspective.

Predating ABC, I started working on a Core-based version of the MVF client in the context of the BTCfork project after it became clear to me that the attack surface in BU's code was too big a risk for a successful minority fork based only on a BU-derived hardfork client.

In BU slack, after BU's majority HF attempt fizzled but before the Cash fork, when discussions around BUIP055 etc just started, I advocated for BU devs to construct a big block fork client based on recent Core, to avoid a potential repeat of the multiple exploits situation that badly damaged BU node reputations shortly before. I don't care if any other BU devs back me up on this - one day if BU pays to be able to access its own Slack history, these things would become searchable and evident.

This idea received no real support from @theZerg, although I think other BU developers saw the benefit of not attempting a minority fork solely using BU's client.
Some starting supporting ABC development as well shortly after I joined up with Amaury, who had by then changed the purpose of his repo from general experiments to a dedicated fork client for UAHF.

IIRC correctly, the discussion within BU around creating a Core-based client happened before ABC repo was created, but I don't have the exact slack logs to prove the timing anymore. It may have even overlapped as at that point, I was not aware of Amaury having set up the ABC repo yet.

From my memory it was @Zangelbert Bingledack, on this forum, who coined the term "Adjustable Blocksize Configuration" or "Adjustable Blocksize Capacity" of which I was an immediate fan as an alternative approach to BU's Emergent Consensus (EC), which had basically not received the chance to prove itself as an upgrade path. EC had come under academic challenge too, and was perhaps not defended robustly enough. I didn't see a way to refute all of the criticisms of it either, but that's moot - it didn't present a safe enough way in the eyes of the miners, and they probably had less than 50% of the hashpower anyway.

I don't know if @Zangelbert Bingledack 's term inspired Amaury's naming of the ABC repo, but I know we viewed the direction on ABC repo as working towards a client implementing this adjustable blocksize configuration for the initial fork. This work began before BUIP55 came into existence.

In interviews I've seen @deadalnix did not mention clearly his view of why he called the repo 'Bitcoin-ABC'. But I only learned about the repo some weeks or months after its creation.

In the time leading up to that, I had suspended work on BTCfork's clients in order to work on BU, because BTCfork did not receive adequate support, neither from other BU developers nor from miners. I would say there was significant interest though from people who saw how previous attempts at consensual majority forking (XT, Classic and now BU) were attacked and scuppered.

So it should be clear why, when I heard of Amaury's intent to develop ABC as a forking client based on Core, I thought this was worth putting some effort in. I may be a BU member, but I pledged no exclusive allegiance to it. I've always considered that the development I do is for Bitcoin, not specifically BU or any other project.

 

[Christoph Bergmann]

In the month before the fork I was very regularly on BU-slack and had private chats with deadalnix, thezerg and freetrader. From my point of knowledge, I can confirm freetrader's version of the story.

@Windowly

What are the reasons for it and is it possible to get upgrades out faster?

Unlike BitcoinABC Bitcoin Unlimited is not an "UAHF only" client. Correct me if I'm wrong, but BitcoinABC focuses almost exclusively on the UAHF-execution. Nothing wrong with it, the opposite, it is gread to have a strong team dedicated to lead the hardforks and to focus on being a resiliant reference client for Bitcoin Cash. But Bitcoin Unlimited has other priorities. Just take a look in the BUIP-section of this forum. The spectre of discussion and development is much broader. Nothing wrong with this, too, this is the beauty of decentralized development.

Another factor is the governance model. BitcoinABC seems to be more monolothic with deadalnix as a benevolent dictator and the rest of the team in line with him. Again, nothing wrong with it. Bitcoin Unlimited however has another governance model. It is the only implementation of Bitcoin governed by a constitution. This is a more integrating approach, maybe less efficient and more deflected, but also more open for controversies and disagreements. Currently not every BU member is much happy about how the hardfork was decided - and about its content - which is somehow problematic for BU's president and developer.

In his AMA Mike Hearn yesterday made some very interesting comments about the governance of Bitcoin and why he thinks that Bitcoin Cash will repeat the same mistakes Bitcoin made. I will made some lengthy quotes, because I think it is very important what he said:

We normally recognise this in the context of national politics as left wing vs right wing, but in the Bitcoin community this same conflict arose as Big vs Small Blockers, in Ethereum as Classic vs Original, in Russia as Red vs White, and in the UK in recent years it has been Leave vs Remain. All these conflicts are typified by the same characteristics:

• Bitter, enduring conflicts between two opposing camps of roughly equal size who can never make up.
• Very different attitudes towards perceived experts, intellectuals, towards academic qualifications etc.
• A win-at-any-cost mentality by one of the camps.
• Different views on the validity of the preferences of the majority / "will of the people" etc.

The reason they are so similar is because they share the same root cause, a root cause that traces to a disagreement about the span of human nature. Societies split into two camps because ultimately the underlying disagreement is over a unidimensional variable, so disagreement runs along a 1-dimension spectrum.

These conflicts cannot be avoided but they can be contained and channelled. If the Bitcoin community doesn't establish systems for containing this conflict it will arise again over some issue that appears superficially different to the block size debate, but underneath looks much the same.

Asked, what are the similarities between the Core and the Cash community, Mike answered:

• It still uses reddit to coordinate the community.
• There is no formalised governance mechanism. Old Bitcoin used "rule by obscure IRC chats between Core devs" and the different Cash devs coordinate .... how?
• It still uses proof of work and miners still don't care about the health of the network.
• The community still appears somewhat opposed the idea of voting in any kind of formalised governance procedure (e.g. ABC fork is not waiting to see if miners agree, or if users agree, they just picked a time and went for it

I tend to agree. It seems to be a rule of history that if you don't regulate decision-making processes by something like a constitution, things went wrong. Even people heavily commited to decentralize the power - revolutioners like Fidel Castro, but also economists like Friedrich von Hayek - fall into supporting an empowerment of central forces. We saw this with Blockstream / Core, and many of us have warned that this happens again with ABC.

Strengthening a decentralized development, inclusing teams which are rules by a constition, seems to be the only chance to prevent this. So, to finally answer your question: It is not a bug, but a feature that Bitcoin Unlimited is slower than ABC to implement the hard forking code. If there ever will come a moment, when Bitcoin Unlimited does not go its own way, does not think for itself, does forget its constitution to comply with ABC, it will be a major damage for Bitcoin Cash. Some of us are not sure, if this did not already happen ...

On the other side, I'm ok with having a 32mb limit and never again changing anything except fixing bugs. This does not need a consitution, or anything like this, but could be a success by itself.

 

[freetrader]

On the other side, I'm ok with having a 32mb limit and never again changing anything except fixing bugs. This does not need a consitution, or anything like this, but could be a success by itself.

If adoption happens (and why wouldn't it) we would run into 32mb limit fast. It's only ~100 tx /s (approx).

As Gavin said we should design for success! BU already doesn't have a fixed 32mb limit, and that's good.

 

[deadalnix]

Just to make sure I'm getting the whole "memoryless" kerfuffle going on across the internets, all that really means with respect to mining is that statistically, producing hashes does not deplete any finite set of possible trials, right?

No it is because the chances of one trial working do not depend on what have been tried or not before.

 

[sickpig]

Regardless of whose fault it was that BitcoinABC got their foot first out the door with a Bitcoin Cash client in the beginning, BU Bitcoin Cash clients seem often to be released after the BitcoinABC clients. One example is now, when it doesn't seem like there is a BU client yet that is compatible with the May15th BCH upgrade.

As I see it from here these are the reason why ABC releases usually are out before BU (in no particular order):


- probably ABC dev process organization is more efficient than BU's
- we are still maintaining 2 branches (BTC/BCH)
- as @Christoph Bergmann said a lot of effort and energy are spent not only on the release process (see the gigablock intitiative, @awemany's subchain implementaiton, @theZerg's op_group and op_datasigverify)
- valid only for the last release and not that matter much, but nChain devs prioritize ABC to develop the code to re-enable the op_codes we agreed upon.

 

[jessquit]

I may be a BU member, but I pledged no exclusive allegiance to it.

The entire BCH space would be better off with a degree of developer team rotation.
[doublepost=1523018702][/doublepost]

I think that what need to be proved would be the absence of any detrimental effects on monetary usage of BCH.

It is pretty well understood that nonmonetary uses of money are bad for the "money properties" of money.

More specifically, besides the deleterious effects on its use as a unit of account, we're already straining credulity by claiming that we can handle virtually all P2P cash applications onchain.

Now we're saying, "that's just the beginning, we can also handle all the NONMONETARY use cases as well."

Now. You're Amazon, or Google, or VeryBigCo, and you want to build a B2B value chain app that uses a cryptocurrency for value exchange.

Aren't you going to be incredibly skepical that BCH can possibly scale to meet your needs, and more importantly, won't you be concerned that the nonmonetary use cases might crowd out your monetary use cases? Wouldn't you prefer a chain that was "just money?"
[doublepost=1523017919,1523017002][/doublepost]

We are receiving the privilege of BCH being the sound money with the tightest coupling to these tokens (effectively the USD in the international oil market). This will increase the use and consequently the value of BCH. And we are gaining the ability to control what those tokens look like (will they respect property rights, etc).

Hi Andrew, thanks for replying again.

I remain unconvinced but not enough to fight you

However this quote got me thinking in a strange direction.

I realize that we want BCH to be used as cash, but of course we are simply mining tokens. We can't choose what gets done with them.

Now, it's long been understood by economists that if your money has non-monetary use cases, that's bad. Gold makes for poor money precisely because so many industrial use cases exist. Tomorrow gold is found to cure cancer, by Wednesday bread costs half a penny. Then we learn that we were wrong, gold doesn't actually cure cancer it was just hype, and bread prices skyrocket. But guess what? Gold is an important metal for nuclear fusion! Boom! Bread prices plummet again.

If you're an economist looking for sound money, then that's bad.

On the other hand if what you're doing is mining and selling gold, then maybe you want all the use cases you can find.

So....

This raises a very painful question.

Are we mining the equivalent of digital gold after all?

And if so, while I can see how the blockchain might scale to support digital cash usage, if you include every conceivable nonmonetary use case as well, then I can't see it scaling to support all of them.

So....

Were Core & Szabo right all this time?

 

[Zarathustra]

Does silver extend the gold supply?

Yes, it does, like palladium extends the platinum supply et vice versa. If only platinum or palladium were available to the automotive industry, its price would be higher.

 

[jessquit]

@Zarathustra in point of fact palladium does NOT increase platinum supply, it reduces platinum demand. An important detail. You are otherwise correct WRT influence on price.
[doublepost=1523019469][/doublepost]

On the other side, I'm ok with having a 32mb limit and never again changing anything except fixing bugs.

Only 32MB never more?

NACK

 

[Christoph Bergmann]

We needed 10 years to get from 0 to 1mb, and Bitcoin Cash is still at 0.1mb. I don't believe that there will ever be a demand for filling 32mb blocks, as long as banks, fiatmoney and credit card exists. Bitcoin will always be a special purpose money, e. G. paying coffee on an international airport, but not paying coffee at your local coffeeshop, and so on.

I have no problem being proofen wrong, and I'm sure, whenever we hit the 32mb limit, we don't need to have a constitution or a governance model to raise the limit. I also have no problem to have a flexible limit. This is the reason I support Bitcoin Unlimited since Early 2016.

However, I think Bitcoin would be great for a very long time if we let it like it is, don't care about extra features, don't care about any change of the consensus model and so on, but just use it and harden the non-consensus software. I even think it is possible that it would be greater than making Bitcoin subject to an unconstituted development process, which always risks to let Bitcoin being damaged by a cartel of developers which tries to win with its own, very special, very intelligent solutions, like SegWit and Lightning. As deadalnix said in Arnheim, engineers tend to engineer for the goal of engineering.

 

[Tomothy]

Hi Everyone, I think there has been some cool stuff put out on the interwebs lately. In case anyone missed it Joannes Vermorel put out some really interesting drafts of projects he's been thinking about vis-a-vis bitcoin and scaling. You can find that here.

http://blog.vermorel.com/journal/2018/4/6/addressing-a-few-loose-angles-of-bitcoin.html

The two articles that I found especially intriguing are his Ansible paper which discusses 0-confs and faster than speed of light tx safety or something. It's a bit above me but I would assume this should get some interesting discussion. Although it talks first about centralized authenticator it goes on to talk about peer-to-peer later in the article so don't freak out at firstl One concern that was brought up was the 100 blocks, some smaller miners may not find a block in that time period so it's a concern they would be further ostracized.

http://media.lokad.com/bitcoin/ansible-2018-05-05.pdf

The other article talks about utxo and tokens. Overall it's some really interesting ideas discussed that for the most part are above me. I'll try to read them again in the future.

For social media drama, I saw this post from Flibbr and it made me scratch my head. What do you guys think about this? My gut tells me this is weird april fools. But first we have Cobra expressing displeasure at Core and now Flibbr? If true this is, well, stuff's getting interesting.


And i'm seeing more and more complaints of failure on LN. As an aside anyone know of IOS LN app? Friend wants to try for themselves to see how this works. Hope everyone is well, I know tempers are stressed but this is a Marathon and not a Sprint. Steady wins the race.

 

[witly]

I feel the same. Sometime we have to believe and wait. Make developers outside the cryptocurrency community aware of bitcoin cash and make it very easy for them to integrate bitcoin cash into their projects are also very important in my opinion. Writing tutorial with bitcoin cash as an example and building SDKs for more languages are two effective methods.

We needed 10 years to get from 0 to 1mb, and Bitcoin Cash is still at 0.1mb. I don't believe that there will ever be a demand for filling 32mb blocks, as long as banks, fiatmoney and credit card exists. Bitcoin will always be a special purpose money, e. G. paying coffee on an international airport, but not paying coffee at your local coffeeshop, and so on.

I have no problem being proofen wrong, and I'm sure, whenever we hit the 32mb limit, we don't need to have a constitution or a governance model to raise the limit. I also have no problem to have a flexible limit. This is the reason I support Bitcoin Unlimited since Early 2016.

However, I think Bitcoin would be great for a very long time if we let it like it is, don't care about extra features, don't care about any change of the consensus model and so on, but just use it and harden the non-consensus software. I even think it is possible that it would be greater than making Bitcoin subject to an unconstituted development process, which always risks to let Bitcoin being damaged by a cartel of developers which tries to win with its own, very special, very intelligent solutions, like SegWit and Lightning. As deadalnix said in Arnheim, engineers tend to engineer for the goal of engineering.

 

[Richy_T]

if you don't regulate decision-making processes by something like a constitution, things went wrong.

And even if you do. It does make it take a bit longer though.

Personally I'd like us to see a permanent solution to this issue. Possibly we have found it in the form of voluntary association and permissionless forks. It may be a bit messy and not look the way we'd like it but I'm always skeptical about Utopianist schemes anyway.

There's a RAH (character) quote I'm fond of using. I think it applies well to Cryptos and community forks/splits. I'd advise everyone to ponder it because I think it's fairly deep.

I am free, no matter what rules surround me. If I find them tolerable, I tolerate them; if I find them too obnoxious, I break them. I am free because I know that I alone am morally responsible for everything I do.

I supported XT, I supported Classic and I definitely supported BU (which was the most voluntarist of the three) but it was always clear to me that a fork was likely necessary.
[doublepost=1523040327][/doublepost]It seems like some of the unfolding drama above might have been due to miscommunicated expectations. You were all doing good work under tricky situation guys, I'd like to encourage you to bury the hatchet and not play the blame game. We're on the same side here.
[doublepost=1523040468][/doublepost]I'd question the wisdom of using a communication method for which logs are not available unless you're willing to pay for them. Particularly if no one is willing to pay for them.
[doublepost=1523040805,1523040046][/doublepost]What I don't like about OP_GROUP is it seems a very narrow change to support something which seems to have questionable value beyond chasing the latest hype. I think colored coins *are* interesting and having them work within the existing protocol, that's great. I also liked the original idea of programmable money so I'm happy about re-enabling the previously disabled op codes. Is there any way that colored coins could be supported in a more generalizable way that could potentially allow much wider uses of internal protocol cycles?
[doublepost=1523040936][/doublepost]

We needed 10 years to get from 0 to 1mb

Not a very interesting measure. What was the time to get from 0.25 to 0.5 and 0.5 to 1.0? (I did have this number to hand at one point and it's not huge). That's probably the time for 1->2 and 2->4, 8, 16, 32. If I recall correctly, we could be looking at 32MB within a decade if the pattern holds.

I'm not really OK with having any hard limit. it's lazy programming and eventually leads to problems. There will be *practical* limits but those typically change with technology and should be addressed as needed, just as the soft limit was adjusted on a regular basis when it became clear that more transactions were both needed and not going to cause issues.

There was no justification for a 1MB limit, it was just a round number that was orders of magnitude higher than the current usage at the time. There is no justification for a 32MB limit, it's just whatever some programmer put in his Bitcoin-unrelated network library a decade ago. These magic numbers should be eliminated wherever reasonably possible and as early as possible to avoid it becoming a lever of power and the accumulation of useful idiots as happened with the 1MB limit.

 

[torusJKL]

There is no justification for a 32MB limit, it's just whatever some programmer put in his Bitcoin-unrelated network library a decade ago.

I'm all for removing the limit altogether at some point in the future and let the market define the soft limit.
From what I have heard this is currently not possible because of how the client is designed/developed, hence we will have a limit of 32MB for now.

I believe 32MB will give us enough time to work on removing the limit.
Hopefully this work will be done way before the next block size crisis.

 

[jessquit]

Posting this here...

From what I can find, CSW is getting roasted over something he never even said!

> the effect of this attempt to increase gamma (γ) is actually negative

"The effect is negative."

Not "gamma is negative."

Seriously. What the hell. Did he even ever claim "negative gamma?" I can't find it.

 

[Richy_T]

I think the 32MB is at the network layer. It is de-facto part of the consensus but is not a consensus rule as such. It would need some care to be changed but should not be all that tricky. The network stuff is something I'd like to see abstracted away anyway. The Bitcoin gossip network does its job and is a fair default but the internal stuff really shouldn't care. Blocks should be able to be transferred via HTTP or Usenet or email or carrier pigeon.

 

[freetrader]

I'd question the wisdom of using a communication method for which logs are not available unless you're willing to pay for them. Particularly if no one is willing to pay for them.

Good points, just a thought on this one. People *are* willing to pay for Slack.

As a regular user I would gladly be able to pay for historical data in channels to which I belong, and for Direct Message logs of my conversations. Their business model unfortunately doesn't allow this yet.
I think they are depriving themselves of some revenue.

Charge me some satoshis by volume, similar to how blockchair.com charges for more complex blockchain queries. Let the slack admin decide whether participants on their slack can get access to the history.

 

[theZerg]

I thought that slack logs were available individually to anyone who paid, but now I seem to be learning that they are only available if you pay for everyone.

It was important at the time to not stick all the BU eggs in one basket which is why Peter_R wrote the BUIP055 but I publicly remained neutral (but note that ultimately I was the one who wrote and merged all the BU changes needed for the fork so I guess that should give you a hint about how neutral I was). If the fork died we did not want the large block movement to be dead.

ABC released first this time because they limited the opcodes only those that were developed on their client, and rather than re-implement these opcodes we chose to merge PRs from them. These PRs have only just firmed up. In fact, we grew impatient and grabbed them ourselves a little early. I think that moving forward is absolutely critical as the price of BCH declines both relative to USD and to BTC. Otherwise I'd be complaining about PRs that were supposed to be ready by Feb 15 only entering their final form a day or two ago.

@freetrader and I have been talking about things on slack. Ironically, he has logs of that day and they strongly support what I'm saying. With his permission I'll post the same excerpts as I posted on the slack.

But ultimately the details of the "why" doesn't matter. What matters here is that BU has always been a strong advocate of the Bitcoin Cash fork. We initiated it, and we had a compatible client at the time of the first fork. We just weren't the first client to release. Note however, the first ABC release was incompatible with the fork -- I spent lots of time towards the end patching in last minute changes.

As was mentioned above, before ABC we also proposed that someone fork a minimum-change version of the latest Core version and I personally replied at that time that I thought it was a great idea and that BU shouldn't be the one to do it.

tldr; We have always been strongly supporting Bitcoin Cash, ABC (and the multi-client strategy in general).
[doublepost=1523046115,1523044939][/doublepost]

What I don't like about OP_GROUP is it seems a very narrow change to support something which seems to have questionable value beyond chasing the latest hype. I think colored coins *are* interesting and having them work within the existing protocol, that's great. I also liked the original idea of programmable money so I'm happy about re-enabling the previously disabled op codes. Is there any way that colored coins could be supported in a more generalizable way that could potentially allow much wider uses of internal protocol cycles?

OP_GROUP is simply a unique tag on vouts with conservation of quantity across transactions. Its about as general as you can get. You can use it for many things now, and use cases will grow as BCH script complexity grows. You didn't explicitly pigeon-hole it into ICOs but your "chasing the latest hype" comment implies that. But I didn't build it with that in mind. Note that I proposed it BEFORE the ICO and Tether fever hit.

Ironically, many other people criticize it by effectively saying that its too general -- they need specific features to implement their thing: for example "it can't handle options; I need a way for the admin to claw back tokens after a date, paying out BCH". I have always replied that this is a BCH Script issue (maybe we should enable something like covenants), not an OP_GROUP issue.

 

[deadalnix]

Posting this here...

From what I can find, CSW is getting roasted over something he never even said!

> the effect of this attempt to increase gamma (γ) is actually negative

"The effect is negative."

Not "gamma is negative."

Seriously. What the hell. Did he even ever claim "negative gamma?" I can't find it.