Gold collapsing. Bitcoin UP.

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
Craig Wright has some interesting thoughts about enabling OP_GROUP this May:

i'm just reading up on this OP_GROUP thing.
first impression is that this is a neat feature that would be very nice to have. but i can understand CW's NO GO for may.
theirs no reason to rush this... write the code, have an alpha version on a test net, test test test.
I guess their no harm to bitcoincash itself if a show stopper bug is found / exploited in OP_GROUP, all the colored coins simply die, and bitcoin cash remains.
but that's no reason to not test test test and delay the official release of this powerful feature.

[doublepost=1519164416,1519163788][/doublepost]Well this was interesting. Care to comment @deadalnix?

shouldn't counter party LOVE OP_GROUP? cant they use it, and thereby get their token TX's validated by miners?

i'm out of the loop on this one...
 

BCH King

New Member
Jan 15, 2018
15
31
Have you even read the linked text?
This is no fix at all, it's a (tentative) workaround that can work only in very special cases, and totally useless, imvho.
Yes I read the entire thread. I actually agree with u/jstolfi in most things. He is wrong to descibe bitcoin as a ponzi scheme and slightly wrong to describe it as a pyramid scheme, but that's a conversation for another day.

Back to your argument that segwit is the only way to solve transaction malleability, I still disagree. FlexTrans seems to be a good fix. From what I've read, it is also solvable in other ways without the stinking pile of poo that was implemented in BTC.
 
  • Like
Reactions: majamalu
Honestly, I'm sincerely pissed ... again

With the next hard fork Bitcoin Cash will reactivate a wide scope of old OP_Codes. Nobody has ever given a concrete reason why we need them, beside adding new risks and attacks. CSW made some nebular statement about it but, but honestly: As long as nChain does not present some of the code it promises for nearly a year, I consider them worse as Blockstream, and I don't give a shit about what CSW thinks about the reactivated OP_Codes or OP_Group. I don't see anything other than risks and no benefits with the OP_Codes.

With OP_Group, however, I see enormous benefits, they could be the dealbreaker fo Bitcoin to compete with Ethereum tokenwise. Bitcoin Unlimited agreed to implement them, there is a hard fork, but they are not implemented because Armaury did not test it yet, but he will have no time to test it ever ... It's like Tom Zander said: It's Core over and over, but worse, with Amaury being the dictator, nChain his main supporter ... We get OP_Codes, we don't know why we need them, with no discussion of risks and benefits, while we don't get an OP_Code, which has very clear benefits and whose risks have been discussed -- OP_Group.

Bitcoin Unlimited is the only grass roots group of Bitcoin development. It, not BitcoinABC, is the hub of big blockers and free minds in Bitcoin Space. Bitcoin Unlimited teached Amaury to work with Bitcoin, it even paid him for learning how to do Bitcoin. Bitcoin Unlimited has a growing, vibrant community, it attracts some of the brightest, honest and most polite people in Bitcoin, it initially raised support of Miners and Roger Ver. Bitcoin Unlimited is the only Bitcoin development group which has an idea about economics.

We noticed Amaury's style of decisionmaking without joy, when it came to the DAA and to new addresses, and, honestly, everyone being involved with BU for some time know that his personality is sometimes complicated when it comes to cooperating or being challenged in his beliefs. People have warned and complained since month, but did not revolt, because they want to keep unity in Bitcoin Cash. The OP_Codes affairs blatantly shows that ABC's promise after DAA to improve decision making process was not serious. If this pattern continues - and it seems it will - Bitcoin Cash will be the project of Amaury and nChain and the claim of "decentralized development" will be nothing other than a marketing lie.

This trajectory the project goes is a pervertion of the motives it started in the first place.

I hereby propose that Bitcoin Unlimited, as a commuity, will revolt.
- Reject the reactivated OP_Codes, until there is public consensus about its benfits and the absence of risks
- implement OP_Group as a softfork, gather miner support for them
- ask mining pools to let users decide which Bitcoin Cash node they use
- spin up more Bitcoin Unlimited nodes
- lobby with XT and parity for our case
- brigade reddit, the mailing-list, the slacks and so on with our complaints against BitcoinABC
- lobby freetrader to distance himself from BitcoinABC
- pledge that Bitcoin Unlimited will never adopt software that is patented like CSW announces
- distance from nChain

Be angry. If not, this will become a take-over.
 
Last edited:

Dusty

Active Member
Mar 14, 2016
362
1,172
Back to your argument that segwit is the only way to solve transaction malleability, I still disagree. FlexTrans seems to be a good fix. From what I've read, it is also solvable in other ways without the stinking pile of poo that was implemented in BTC.
I'm not saying (at all) that segwit is the only way: only that I understand quite clearly that it solves the problem in a backward compatible way, and that I'm unable to find a more cleaner way maintaining compatibility.

FlexTrans is a nice concept but if I'm not wrong it requires a totally new set of software because it renders the whole ecosystem totally useless. This is quite a big problem because we can't expect everybody (library mantainers, software developers, wallets, exchanges, etc) to rewrite all their code at the fixed date of a fork.
 
  • Like
Reactions: BCH King

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
@Christoph Bergmann : I am maintaining what I consider a healthy distance (for myself) from any one particular project.

I don't think we will ever reach "public consensus" on the absence of risk with the new operation codes, but I also think they have been poorly motivated, and I suspect they are being pushed so hard because they are needed to enable certain applications on top of Bitcoin.
Applications that may align with nChain's financial interests, or not. I would not really mind that so much, but I do mind a lack of transparency about motivation for putting them in.
I don't expect we're going to get a straight answer, so I would say this needs some investigative journalism to uncover (e.g. which patents depend on new opcodes).

We also have to remain open minded and consider the case that there is no ulterior motive, just people thinking it would be cool to activate these codes again safely, and see what others can build from them.

It does not seem fair to me to argue that OP_GROUP potentially unlocks some unanticipated risky system behavior and therefore needs more thorough examination, when the draft document on the other new opcodes does not address broader interaction risks but only narrow technical risks.

About OP_GROUP:

I'm not sure a soft fork will be better suited to achieve the result of it being used.
The final decision maker is hashpower. If miners don't like OP_GROUP in its present form, for any reason, they can mine on top of a branch which is invalid for current OP_GROUP rules, thus destroying the current OP_GROUP (and forking BU off hard in the process).
It seems better to me then to propose it as a hard fork in the first place, and be clear about where we stand with it from the start. Probably less messy too than a SF implementation.

Preferably to me would be to get signaling of hashpower to know if OP_GROUP as currently designed and implemented is something they want to support or not, or if they want changes in the direction that recent criticisms have expressed.
I certainly don't support taking the word of ABC's developers as a kind of proxy for what miners want.
The Bitcoin Cash ecosystem and industry deserves a much more objective signal.

Finally, with all new/recycled opcodes, I think there should be a time for hammering them on the public testnet before the decision is reached to put them in place operationally. The point that "consensus rule changes could break Bitcoin Cash" applies equally to all new codes.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
Be angry. If not, this will become a take-over.
I disagree. I think it should be "look for better governance. If not, this might become a take-over."

I see this as a crisis in BCH governance. Simply due to human nature of always disagreeing at some point. Sure, there might be incentives and conflicts of interests in the background that I do not know about (though I think that's unlikely and at most I see egos clashing here at the moment). But that doesn't really change the fundamental problem.

BU member @singularity wrote a draft of what I think makes most sense for a way to resolve these kinds of issues, and although I and likely everyone else who thinks the general idea is good could bikeshed this to death, I would actually like to express my support for him to make this some kind of BUIP which when passes would be floated to the miners, with explicit request for open feedback or adoption (potentially with changes from the miners) by them.

A few things make me optimistic that it won't become that bad: Your anger (and visibly other people's anger on reddit :D) and that, in general, people here have been burned already with BTC and remember that. On top of that, our comms channels are in much better shape.

Now, What I think you want to look out for are signs that this crisis in governance is used to attempt a hostile takeover again:

I think that point is reached when members of any particular project (such as ABC with its dominance right now, but essentially that goes for BU as well) start to stall on or being noticeably unwilling to address the underlying issue of governance in a way that would pave a way forward to conflict resolution.

That is when one should start to really worry, IMO.

So, yeah. I think that this is going to happen was actually predictable, some have put more effort into addressing this than others (@singularity) but I urge all to think about abstracting a bit from the actual situation to the more general issue of conflict resolution.

I personally do not see anything but hash power voting resolving this, but I am all ears to other answers that aren't extreme consensus or something :D

Hash power resolves it in the end anyways, but I think it makes a lot of sense to structure any governance around this 'fundamental law of blockchain nature' - to avoid fiascos like the BCH/BTC split from occuring again. I think if @singularity works on a BUIP, he should make clear that his proposal isn't a change in governance as much as it as a gentlemen agreement between miners to express their governance in this way - which would also foster communication about proposals and make them more like an open vote contest.

@freetrader : Good points.

@hodl: A way to make miners and the community care would be for all devs to agree to go forward with exactly one HF - and that all current clients have to stop operating right at the HF.
If that HF is then hashpower voted (or better: features of it are), there's going to be a lot of stake in deciding on the right choice. I am not 100% sure this is going to be necessary or the best way to solve this, but there are ways.

It is my optimistic hope and expectation that attempts to subvert any agreed-upon process will be much more visible and much less likely to succeed with an informed BCH public and more diverse communication channels.

Even if not, I think it is strictly better than the alternatives: The governance process might fail. Not trying means failing right from the start.

And there is and always will be the option for a group of people to start their own fork!
 
Last edited:

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
@Christoph Bergmann
revolt?
what we need is hashpower! and lots of it.
how about bitcoin.com's hash power are they just bending over for the hardfork?

the bottom line is that if you dont have any hashpower to go along with your argument, then you don't have an argument...
 
  • Like
Reactions: AdrianX

79b79aa8

Well-Known Member
Sep 22, 2015
1,031
3,440
in addition to hashpower, and irrespective of the outcome of the present juncture, higher hashrate share improves BU's ability to promote the health of the bitcoin cash development-mining relation. i think this is in the interest of everyone, including nChain.

one way to increase hashrate share would be directly, by pool mining (@AdrianX). another, by asking pools to give users choice among clients (@Christoph Bergmann). a third, bylobbying miners, possibly using the BUIP process (@awemany).

@solex, are you viewing this as a priority?
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
another way to incress hashpower, is to make it easy to own hashpower, and "lobby" USERS to buy some.

if i could go to bitcoin.com buy hashpower, and there by have a voice, ( and be able to auto reinvest all coin's produced, back into buying more hashpower... ), I would.

i've bought/sold some "hashpower" here and there, some we're rip offs i'm sure... but when i did that I was looking for a way to mine bitcoin profitably with 0 effort.
 
@freetrader @awemany

My words have been too harsh, too strong, too angry, too attacking. I am happy for having with ABC a new client which takes the lead in pushing the UAHF forward and in providing companies with a software they trust.

It was a reaction on "they did it again". If this will be the new reality of Bitcoin Cash, I will lose my motivation to support it. I'm happy that you understood the intention and share the need that something changes.

There's so much to say and discuss about it, and all of you made great points, I need to let sink in.

Freetraders speculation that OP_Codes are needed for something nChain wants to patent are a case to worry. If this was the case, I would support an UASF to softfork the codes away. At least this should be an option.

Letting hashpower decide would be the most fair way. When they become the dictator, it is at least in Bitcoin's consensus model.

Edit: Here's an interesting comment of tomtomtom

 
Last edited:

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
Freetraders speculation that OP_Codes are needed for something nChain wants to patent are a case to worry. If this was the case, I would support an UASF to softfork the codes away. At least this should be an option.
nChain produces something useful and makes money as a result of some new OP_codes, so what? why would this be bad for BCH?
 

hodl

Active Member
Feb 13, 2017
151
608
here's what i would do if i were BUCash and wanted to seize back the dominant BitcoinCash implementation @theZerg @solex @Peter R @sickpig: come May, and simultaneous with ABC'S hard fork, do a BUCash hard fork with a 32MB blocksize increase and nothing more (yes, this will fork off ABC). no OP_CODE's at all, including no OP_GROUP. this literally and simply extends the logic behind what made Bitcoin Cash successful from the start with the backing of the big blockists in the community who mainly originated from this thread.

in addition, between now and May, engage in open discussion calmly yet firmly arguing this case (which Amaury clearly hasn't made a priority in regards to his OP_CODE panoply) here, on Reddit, and Twitter about the intentions, which are:

1. continue the original vision of Bitcoin Cash as sound money/cash first and foremost.
2. argue that it is just too soon to open up the original objectives of Bitcoin Cash which were to simply become a working/viable currency with SOV properties. the endpoint here being once BCH unseats BTC.
3. argue that CP introduces a parallel currency, XCP, the economic effects of which are unclear and need more study. i'm not against CP necessarily altho i was one of the one's who argued against it way back when b/c of the "competing" XCP and bizarre proof of burn. it's also a distraction away from the sound money objective at this early stage, imo.
4. make the concession likewise of OP_GROUP being too early and maybe reaching beyond the original goals of making Bitcoin a new revolutionary money as opposed to a smart contracting system.
5. acknowledge that Bitcoin as Money is developmentally (coding wise) boring, yet simple, with the larger primary objective of becoming the next world reserve currency. world reserve currencies need to be simple and stable for confidence and adoption. and maybe function as just that; Money.
 
Last edited:

hodl

Active Member
Feb 13, 2017
151
608
i happen to really really like the idea of going from 8MB to 32MB, even with blocksizes as small as they are currently in BCH. it feels very elegant to me to be able to say we are restoring the original blocksize that was in place right before Satoshi inserted the 1MB limit. it feels like coming home to the original original vision. 8MB was always arbitrary, even tho i know there are some nebulous anchors as to that choice, like "8 is what the network can handle", a tie to the XT proposal, etc. but 32 takes us back to the original protocol constraints (anything above that requires a major hard fork iirc) and maximum limitations which just feels right and will probably be good for scaling going out at least 5 years. furthermore, i have not seen ANY pushback from true big blockists regarding this move, so i think it's a no brainer (minus the noise) that would be easily accepted without the risk of OP_CODE drama and politics.
 
Last edited:

rocks

Active Member
Sep 24, 2015
586
2,284
The disagreements popping up now were always to be expected, and it is important to remember these disagreements are a part of the process and a sign of a healthy system IMHO. No one is being censored and everyone is able to communicate their views. I agree with @awemany on "look for a better governance model. If not, this might become a take-over." @Christoph Bergmann I don't think's ABC's actions on OP_GROUP are anything similar to core's stalling tactics, yet, so far it is a one time let's evaluate more and consider for the next round, if ABC stalls again without good reasons it needs to be looked at.

On the OP_GROUP topic, after looking at it more I think there are potential issues that warrant being careful and having an adequate testing period.

The reason is it has the potential to introduce new spam attack vectors that are not present in Bitcoin's current design, because the nature of the new tokens are different.

The current Bitcoin tokens are limited in supply, this means that a spam attack generally requires spending the same tokens over and over again causing storage bloat. Storage is cheaper than fees so this is has not been an issue.

However my understanding (please correct me if I'm wrong on this) is OP_GROUP introduces the ability to create near infinite supply of tokens that are spendable. As a result it is easier to focus a spam attack on bloating the UTXO set. Instead of churning the same tokens on storage, an attacker can create tokens and create as many spendable outputs as they desire. The current 8MB would allow for bloating the UTXO set by 1GB per day. Doing that on the blockchain is not an issue, doing that on the UTXO set is.

If anything I think it is valid to expect OP_GROUP to be tested on a testnet for at least a few months. I think if I was given a few hundred BCH and a few months I could write a script that takes down a good portion of the network. Maybe I am wrong, but I think this should be a legitmate enough concern to require more testing.

I still think colored coins are a great idea and have thoughts to get around this, but first wanted to hear people's thoughts on the above.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
@hodl
that's a crazy.

these OP_codes were always meant to be part of bitcon, 10 years in... ya its time to turn them on...
if not now then when? you'd want to fork because of different time table? on top of that BU is pushing for its own OP_code "Group".

if the OP_codes are sound and reviewed and everyone agrees they are no bugs. wtf are we waiting for?

the idea that nChain might make some patents that make use of these op_codes, is a not a good reason to block this, its not the op-codes fault poeple want to use them!

I would strongly appose any BUIP that refuses to implement perfectly sound and useful code.
 

hodl

Active Member
Feb 13, 2017
151
608
except BCH is not 10 years in; it's 7 mo in and scraping to overtake BTC, which is 10 years in. this is the tragedy of Bcore; it's set us back. let us not forget the allure behind BCH that made it successful in the first place; the return of Bitcoin as Money (Cash). not smart contracting.
 

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
@Christoph Bergmann
Thanks for the rant. I got the same gut feeling from this secret process where ABC and nChain seem to run the show. We had a transparent voting process on OP_GROUP in BU, and then it's shot down in a secret meeting. (Or is it? To me, it's not yet clear whether OP_GROUP could be included in the May hardfork or not.)

Do we have a governance problem?
I would say no. Because we have the awesome decision making machine called bitcoin.

I see the situation with multiple dev teams like this:
The teams are like political parties, and the miners are the voters. They vote, every single block.

We now have more than one political party (unlike BTC). So the fundamentals are in a very good shape.

The election process is messy and dirty. It always is in politics. But it works.

If good proposals like OP_GROUP can be pushed to the side, it's because Bitcoin Unlimited does not have enough miner support.

It's a good thing that the dev teams come together and try to find the best solutions.

But when there is disagreement among dev teams, the individual teams must win the hearts and minds of the miners.
 

hodl

Active Member
Feb 13, 2017
151
608
@adamstgbit i agree. but not everyone is convinced.

i think the recent BCH pullback is reflective of Amaury's unilateral, non communicative insertion of those multiple OP_CODES into the May hard fork w/o any community discussion/feedback thus arousing suspicions/analogies to Bcore authoritarianism. but that's just speculation on my part. i know i'm reeling from the suddenness, out of the blue, decision making on his behalf.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
@hodl

I just came to the forum a day ago to check up what was happening in the bitcoin world these days. as always bitcoin never disappoints! always some interesting drama.

I didn't realize they haven't been very transparent. but did they simply :
a)haven't been shouting their intentions from the roof tops.
b) been secretive, and are now pushing this threw ASAP so the rest of the community dosnt have time to react.

maybe nChain / ABC run the show, because they have the man power to do that.

However my understanding (please correct me if I'm wrong on this) is OP_GROUP introduces the ability to create near infinite supply of tokens that are spendable. As a result it is easier to focus a spam attack on bloating the UTXO set. Instead of churning the same tokens on storage, an attacker can create tokens and create as many spendable outputs as they desire. The current 8MB would allow for bloating the UTXO set by 1GB per day. Doing that on the blockchain is not an issue, doing that on the UTXO set is.
this is a very good point.
this is the kind of reason why they are saying that they need more time to review OP_GROUP.
as simple as it seems, their are always unforeseen consequences.

bitcoin itself faced a similar potential problem when BTC had no value. we all know how they solved that problem... 1MB limit! but i guess this analogy dost make prefect sense .
 
Last edited: