Gold collapsing. Bitcoin UP.

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797
@Richy_T You've understood.

Liquidity can not be designed by an engineer, for the same reason that prosperity can not be designed by an economist. The liquidity of a currency and the prosperity of a society are emergent phenomena of an extended order; a central authority can promote, discourage or punish them, but never create them.
That's the theory of the Austrian School and praxeology: socionomics without empiricism (aka Religion:sneaky:).

Unfortunately (!), a minimum quantum of centralism is a necessary condition to create a society and an economy.
The absence of censtralist authorities = anarchy, which at the same time is the absence of the economy. In an anarchist environment there is no such thing as an economy, because you are self-sufficient there and are not forced to produce surplus.

The question is simply: which quantum of centralism is optimal and generates the most (material) prosperity? The most decentralised society with the most decentralised authorities is Switzerland and it's also the most successful society, measured in money.
 
  • Like
Reactions: lunar

cypherblock

Active Member
Nov 18, 2015
163
182
"As it happened, on 31 August at Bangkok, nChain did propose a "no Change" for 15 November as part of a holding pattern, with the view of having an upgrade about 15 February 2019 instead."
(from @solex I think)

There is still time for teams to postpone. They should. It would be ridiculous for BCH to fork into 2 coins now and lose network effect.

My own stance (aside from not wanting a fork) is that CTOR/LTOR is not really needed at this time (and perhaps not for a while) and that DSV/CDS also does seem to change fundamentally what BCH can be used for. Which is not something that should be done lightly or because it meets the business plans of a small group. As for block size, staying at 32mb for now is the correct move. The other opcodes, and script length are fine as long as sufficient analysis/testing has been done. If not those should not be added either.

Oddly I find my position closer to nChains than ABCs even though I prefer the ABC team in general.
 
  • Like
Reactions: AdrianX and witly

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
@cypherblock
Strenuous efforts were made to compromise by getting all the developers and miners together in one room. Today is it even more difficult as conflicting versions of software are deployed. It is really up to the miners and major users now. I remain optimistic that one fork will prevail and BCH gains further global market share with a tail wind of publicity from all this drama.
 

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
The key to compromise does still exist as is baked into the BUCash-1.5.x releases due to BIP135.
All the new features in ABC and SV can be individually activated by miner voting. If the BCH miners run this code before 15 November then the forking risks fall away.

Of course the forking risks also disappear if the miners use just ABC or just SV. The difference here is that there is a route forward for all coded changes without further developer involvement,
 
  • Like
Reactions: AdrianX and lunar

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410


Bitcoin Script Lacks Good Tools, Not Opcodes


This text was originally written as a reply to a discussion in the comment section of an article about OP_CHECKDATASIG. I'm publishing it as an article of its own since I think the reply came out as good explanation of why I consider it bad to add new fairly high level opcodes like OP_CHECKDATASIG to Bitcoin.


Continue >>
 
Last edited:

throwaway

Member
Aug 28, 2015
40
124
Question about BU 1.5.0.1:
Is the failover for unsuccesful graphene still xthin, or a graphene retry with bigger settings?
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@Dusty: LOL. Seems like he's reading this thread here, even the Elon Musk comparison is in the video :D

Though I have to say that I think this psychological language adds a lot of fluff that doesn't really help in bringing the point across. That's IMO much easier to say with everyday language: Some folks are assholes.

But he makes good points still.
 
Well, these aren't two distinctive set ...

So, I do agree, that ABC is a problem and that deadalnix and his followers are a pain the ass. But imho that should be dealt with after the 15th.
It's nice to see that we mostly agree on the assessment of the situation, and are able to politely discuss our differing interpretations.

I just don't believe that doing the wrong thing today will result in getting the right thing tomorrow; than giving ABC everythings they want without a fight, will help us to deal with them.

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.

Two of the proposed features are Merklix Trees and Schnorr signatures. Out of my head (and possibly wrong): Merklix trees are a new hash tree that replaces / is added to the current Merkle tree. It is Amaury's version of the path to UTXO commitments (which is the ONLY thing I'm really interested in). Schnorr increases capacity by 20 percent if fully adopted (= never), increases privacy of Multisig-signatures and eliminates Malleability (huhu, Adrian, Lightning coming to BCH :)

Both changes are interesting. But the timeline to discuss such complicated things is insane. If - IF - there is a consens about implementing these features (I doubt), they need to be assessed in detail, compared with alternatives, and implemented with a consultation of merchants, wallet-providers, exchanges and so on. If not sneaked into P2SH in a SegWit-style, Schnorr will need to be implemented by every wallet, if you don't want to lose fungibility (make a wallet fail when it gets a transactions). Just as an example.

So, what will happen? There will be discussions, there will be fights, again. But as people tend to repeat successfully exerciced strategy, ABC will continue what they do since the beginning. And you really think you can stop them this time? After a significant part of the hashrate has left / surrendered, after parts of the community, that are against ABC dictatorship, has lost interest, after exchanges made it clear that they define BCH as ABC's coin, independently of the hashrate? I don't think so. The odds will only get worse.

And about the larger picture ... Here is a reddit-comment of Top-ABC-shill Kain_niaK


Here's the quote:

"We have a window of opportunity to get some change in to the protocol that will get us to 100 MB blocks that the network can handle witout orphan rates playing the party pooper. That would give us the capacity for 5-10% of what Visa does.

ABC knows they are currently able to get these changes in the protocol but it's already getting harder and harder as you can tell."

ABC must be BCH dictator to make the protocol of Bitcoin Cash scale well enough ...

If Bitcoin Cash is a developer-dictatorship, and if it is changes to CTOR - Schnorr - Merklix in just 6 or 7 month, doing a large redesign to deal with an imaginery demand for transactions,
it will no longer compete with Bitcoin, the hard, immutable, decentralized P2P cash money. It will just be another (unused) Altcoin which claims to have good scalling attributes, like Dash, IOTA, EOS, Cardano and so on.

And you tell yourself you prevent a takeover by CSW, while it is VERY clear and open what's really going on.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
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.
 
  • Like
Reactions: AdrianX

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
Better ways of deploying change have been proposed, no compromise from SV.
Nov 15 will come and go, let's see how the "hashwar!" plays out.

I want to see @imaginary_username 's Adaptive blocksizes on the agenda for the next upgrade (whenever, however).

I suggest BU allocates/reserves version bit 8 for it right now.

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.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
afaik, q6mo hard forks are/were a BU thing nothing to do with SV.
 
  • Like
Reactions: AdrianX

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
afaik 6-monthly HF's were an idea that the dev groups ABC, BU and XT (not sure about Classic) sort of agreed on at the beginning (before the Aug 2017 HF), but consensus for that has diminished pretty significantly and obviously.
SV obviously wasn't around then, only starting its development in late Aug 2018 and releasing in October 2018.

Jonald proposed reconsidering the 6mo schedule already, but I think that all got swept under the table with this contentious November fork, just like BIP135 which BU and XT currently prefer (and which I still think is a better long term option, but may require much more hashpower on BCH for miners to feel secure in using it).

p.s. https://github.com/bitcoin-sv/bitcoin-sv/issues/5
 
Last edited:
  • Like
Reactions: throwaway and witly