Gold collapsing. Bitcoin UP.

[hodl]

this isn't good:

 

[Justus Ranvier]

Linode? What's that?

 

[Dusty]

Once the malleability bug was identified as a risk, it could have been fixed with a simple hard-fork change, implemented in the same manner as the increase in the block size limit. It is only in Greg's bitcoin that hard forks are forbidden, and thus that bug must be fixed by the ungainly SegWit soft-forked hack.

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.

 

[hodl]

how many BackTracks have we seen over the years? bottom line; don't worry:

https://stopthefud.wordpress.com/2018/02/15/jpmorgan/

 

[Norway]

New logo for the norwegian bitcoin domain: https://bitcoin.no/

I wonder what kind of bitcoin it's going to be about...

 

[awemany]

Hey Guys,

there's an interesting read over on Reddit where thezerg discusses his take-away from a dev meeting on OP_GROUP. I think all BU folks should read it:

https://www.reddit.com/r/btc/comments/7yovto/response_to_op_group_criticism/

I am kind of neutral on OP_GROUP in particular and am fine with a slower approach than @theZerg likes to take.

But I think a very important point that the whole discussion raises is:

- ABC is the currently dominant implementation
- devs disagree now and will disagree in the future
- someone (TM) needs to end the bikeshedding and pick and choose

This is why I think it would make sense to have a public, majority-HP-agreed-upon contest where dev proposals are implemented, preselected and finally voted into being new chain consensus (or rejected, of course).

What do you think about this? Also, miners, if you read this, any input?

 

[Bagatell]

@awemany

"If BitcoinABC is honorable, they'll add OP_GROUP as well as support Counterparty Cash. The ecosystem and market will make the decision on what method of creating tokens is the best. If they keep fighting against OP_GROUP for selfish reasons, then we need to throw more support into the other Bitcoin Cash clients and limit BitcoinABC's power withing the Bitcoin Cash community."

Were there any BU reps at the last Satoshi Roundtable? Was this discussed there?

 

[hodl]

This is why I think it would make sense to have a public, majority-HP-agreed-upon contest where dev proposals are implemented, preselected and finally voted into being new chain consensus (or rejected, of course)

How is that any different from the failed bip9?

What happened to the concept of if a dev or team disagrees and wants something that another doesn't, that they take the lead, put the work into coding it up, releasing it, and seeing if the miners pick it up? Only then should the brow beating and lobbying begin. Wasnt this the Satoshi method?

 

[freetrader]

Might a way to resolve this be to specify a BIP9 or similar signaling bit for OP_GROUP?

BCH miners could then signal with hashrate to show significant support without locking it in, making it clear that they want it (couple with public statements) and that other clients should get ready with compatible consensus changes (within a timeframe of a few months).

My understanding is that the consensus changes are ready and BUCash could release with signaling + functionality and be the first out the gate to support it.

Miner signaling is much better than dev teams having to get defensive about their choices. Miners are an amorphous collective, and there is no one to blame for a decision, just the collective. That's as good as it gets, I think.

 

[Windowly]

Craig Wright has some interesting thoughts about enabling OP_GROUP this May:

 

[awemany]

@hodl: No it wouldn't be much different from BIP9 on the technical side.

But what I am aiming at is rather a common understanding on how changes are implemented.

I would be fine if we basically have contests to activate on version bits and some kind of agreement between devs to select non-conflicting version bits.

But it seems to me we're creeping towards implementation monoculture again.

I think BIP9 failed exactly because of implementation monoculture, annoying/malicious devs (ironically partly the same ones drafting BIP9) and extreme consensus - which were all things not due to BIP9 itself. (Granted, details of BIP9 voting would likely need to be adjusted)

Because, if you think about it, we could have easily gotten miner support for a blocksize increase through version bits without the extreme consensus and squatting/manipulation of the main comms channels.

So again, what I'd be aiming at is some kind of common understanding - and I think that would develop with most of the HP backing such a plan forward - on how to implement changes.

And it would need to be without extreme consensus, obviously.

We need to get something going where we can agree to disagree and still move forwards and break stalemates.

The alternative is ossification of BCH, which I don't think would be disastrous without the blocksize limit. But I think avoiding it would be even better.

 

[hodl]

Might a way to resolve this be to specify a BIP9 or similar signaling bit for OP_GROUP?

BCH miners could then signal with hashrate to show significant support without locking it in, making it clear that they want it (couple with public statements) and that other clients should get ready with compatible consensus changes (within a timeframe of a few months).

My understanding is that the consensus changes are ready and BUCash could release with signaling + functionality and be the first out the gate to support it.

Miner signaling is much better than dev teams having to get defensive about their choices. Miners are an amorphous collective, and there is no one to blame for a decision, just the collective. That's as good as it gets, I think.

i never liked BIP9 and actually predicted it's failure as an upgrade mechanism over a year before it happened. i had plenty of debates here, on reddit, and twitter about this with guys like Lombrozzo and @jonny1000. the problem with it is that it costs nothing to signal.

now, after re-reading @AdrianX & @awemany's thoughts on this OP_GROUP, maybe offering a dev based mining pool is a better method since it allows/forces a risk of hash power on a hard fork proposal as a head start on sentiment prior to release. yes, risky. when there is a disagreement, i can't see any other way that doesn't involve risk.

 

[awemany]

@hodl: Interesting.

the problem with it is that it costs nothing to signal.

Of course the actual signalling itself doesn't cost anything. But the miners picking the right choice for their coin might result in a lot of cost or gain in terms of market share. Also more minor things like technical debt and support needed down the road.

It seems to me to be close to a shareholder vote in a company, except it is for the 'original DAO' - which is Bitcoin.

maybe offering a dev based mining pool is a better method since it allows/forces a risk of hash power on a hard fork proposal as a head start on sentiment prior to release.

The grave disadvantage I see with that is that it is everything at once, and not pick and choose.

As a miner, I might think that OP_GROUP will lead to awesomeness and a great future (or the exact opposite) for BCH.

There might be other proposals on the table as well. So if I have 5 opcodes (or other orthogonal changes) to potentially enable in the next future, do someone(TM) have to spin up 2^5 = 32 BU voting pools just so that I as a miner can pick what I deem to be the right choices for BCH?

I think that's going to cause more headaches than it solves (though for other reasons I ponder about a BU pool as well).

But maybe I am not getting exactly what you are saying here.

 

[rocks]

Miner signaling is much better than dev teams having to get defensive about their choices. Miners are an amorphous collective, and there is no one to blame for a decision, just the collective. That's as good as it gets, I think.

IMHO the past few years demonstrated that miner signaling is broken, that is why there had to be a UAHF. The issue with miner signaling is it requires a super majority of miners who are financially incentivized by the status quo to opt-in to a change. If that did not happen for 2MB blocks, it won't happen for improved functionality. Also, miners are a small fraction of the ecosystem, the concept of miner voting only works if voting is spread among major users, which it didn't work out that way.

Having a development team lead consensus rule changes is closer to end user interests, but it is still not ideal since it will always tend towards single dev team or owner control. We saw this with BTC and it is already true for BCH (the BCH control is better than the BTC control though).

The BCH UAHF put control back in user hands by enabling users to pick their development team. But it is still a very messy process and will likely only be activated when a dev team gets seriously off the rails. Just because users agreed with the new dev team for the UAHF rules does not mean users will agree with them on future rule changes, but that new dev team is now in control regardless.

How to settle relatively more minor disagreements such OP_GROUP is still unknown. For now it's ABC's project for good or bad.

On the OP_GROUP topic, personally I think both sides are equally valid. I like adding it, but also think there is no harm trying to understand it more fully than a May drop will allow for. Now if that is a true wait and understand more or a core style stalling tactic remains to be seen.

 

[hodl]

But the miners picking the right choice for their coin might result in a lot of cost or gain in terms of market share.

except when you have miners like Wang Chun floating around willing to play games when it costs him nothing, we've seen that hasn't played out well.

 

[awemany]

@hodl, @rocks: OTOH, majority hashpower is protecting BCH, else it wouldn't have seen the light of the day. So I think miner HP in the end does work as a decision making process.

Also, regarding f2, who the heck knows how long they knew that 2x is going to fail anyways?

Similarly, I remember that ViaBTC said, before S2X failure, that 'they are mainly interested in BCH now' or something along these lines. Similarly for that other huge pool of which I forgot the name right now.

So I would actually disagree with the reading that HP as a signalling process does not work.

Also note that if all devs would agree that HP (simple) majority rules, the kind of extreme consensus shenanigans, posing with swords for UASF and so forth would not be accepted by any sizable part of the BCH community.

Especially so when it becomes a tried and proven method for decision making.

The most that might needed by a dev team then is to go and repeatedly annoy the miners until they actually start voting for or against a proposal (should they stay ignorant).

 

[rocks]

@awemany, the role of miners in Satoshi's WP is only to fix, agree on and protect transaction ordering within a set of rules. But it is always the end users themselves who determine what the rules are. To me this is probably the biggest misunderstanding of Satoshi's POW mining invention.

A perfect example is the BCH fork. Currently by miner hash power the BTC chain is the valid chain. The only reason we are operating on the BCH chain is we (as end users with no hash power) have determined for ourselves that the longer BTC chain is invalid and the BCH chain with the 2MB block in Aug is the longest valid chain.

We as users set the consensus rules in the UAHF, the miners only determine transaction ordering within those rules. Trying to ascribe to them with signaling more power than they have or should have according to Satoshi's WP has been the cause of much delay and lost of time.

 

[awemany]

@rocks: Interesting. I have a different perspective. In retrospective essentially see the miners as having explicitly opened a second option (BCH) because it was in their sense the most effective way to route around the bullshit that was going on with the BTC "community" plus take in all the sweet fees from the folks willing to pay them for all the supposed decentralization benefits of 1MB.

Both forks have majority hash power support. Either actively mining or as "standby MAD nukes". (Should someone dare to attack BCH)

This seems to be an equally valid view to me - what would be data that breaks this symmetry?

Of course, the miners gauge community and market support for their actions. Which makes it looks like ABC and those that supported ABC started the fork. But I rather think it was and is the miners doing this.

What you say would support the UASF view, if I am not mistaken?

On UASF, I think the miners went and simply 'let them win' (by activating SegWit before the UASF deadline) - to basically let all of the BTC distractors drive against the wall, in full confidence of being right and in charge.

 

[hodl]

>OTOH, majority hashpower is protecting BCH, else it wouldn't have seen the light of the day.

i agree with this but we still don't know if BCH is going to work in the long run.

i come down somewhere in between @rocks & @awemany, as i have always done in my bucket theory.

certainly both users and miners are big components of the equation. you could also divide the participants further into exchanges, payment processors, and developers. the question becomes, how do you measure sentiment of the various participating actors in the system in a reliable way? i say it's impossible until or unless there are costs involved in signaling and even then it's dubious what the results say in the absence of a full commitment towards the new rules via a hard fork. since each of these interested groups are subgroups of the entire market, not one of them can or should carry more sway than the others since they are all needed to make the economy function in some way. the trouble with trying to measure sentiment is that whatever signal measuring process you may choose to employ, the noise becomes unbearable/intolerable to the point the results are useless. mainly b/c virtually all of the signaling systems to date have been costless (BIP9).

sorry, this is alot of babbling w/o offering solutions but the only way i can think will work in the long run is for a dev, or team of devs like @freetrader & @deadalnix or BU, to do the work coding their inevitably controversial hard fork and releasing it out into the market for ALL participants to decide if they wish to run it. it's risky to the development team, but that's what hard forks do over soft forks, offer the market a choice between controversial ideas.
[doublepost=1519164416,1519163788][/doublepost]Well this was interesting. Care to comment @deadalnix?

 

[SanchoPanza]

Miners need users, users need miners. Trying to divorce the two ends up with two broken halves.

Before the big block fork, there were various ways proposed to get a better idea of miner opinions.
These were actually supported by big block favoring miners at the time. It might be time to look again at what use could be made of those.

The main problem with BIP9 was always its inflexibility, designed as such and exploited by Core. That which is too rigid, breaks easily. This was not the miners' fault, except perhaps by not being quick enough to see through the politics and the tools put in place to favor an agenda.