Gold collapsing. Bitcoin UP.

[lunar]

@_bc Welcome to the forum.

8MB-signaling miners are moving over.

Stated as fact, any source on this, reason for confidence, or just speculation?

2.1% of blocks today support 8MB blocks

Also according to https://www.blocktrail.com/BTC the weekly variance on a 8MB vote accounts for about 8% of the network.

 

[molecular]

@torusJKL

There was once discussion here about the possibility of creating a viable minority fork away from Core. As I remember, those technically competent - I am not - seemed to think it possible.

look at /r/btcfork

it's possible, of course

and if you get to take the name "bitcoin" and those "wizard coders", it's not a bad idea.

Core will do it, imo.

 

[Richy_T]

It might be interesting to note which Core devs are keeping their heads down at the moment.

 

[awemany]

The Bitaddress.org developer comes out in strong support of Bitcoin Unlimited.

Which is awesome! Someone has some balls left. If Jihan is right, at lot of people apparently fear to have a clear position on blocksize.

 

[VeritasSapere]

The problem is, there will always be 'one more compromise'. The time for compromise is over and by giving ground, we appear weak. A line has been drawn. Let's stick with it.

I think this is different to other compromises, I think the time for compromise with the block size limit issue is indeed over, we tried that with Bitcoin Classic. However in the case of replay protection I think it is important to do what we can to protect users from accidental loss. Both sides are very stubborn and I can not see the Core side compromising on this issue at all, the superiority complex and cognitive dissonance is to great and will prevent Core from implementing this protection even though they are the side that actually should implement this.

We saw the same thing happening during the Ethereum fork, both sides where arguing with each other ideologically that it should be the other side that implements the replay protection, and in the end nobody did and a lot of people lost money, and both sides for the most part regretted not implementing this protection. We have the opportunity to mitigate some of the pain that will be felt in Bitcoin when it splits, not just in terms of people losing money but also how that would effect market capitalization and public perception.

As long as this can be an optional feature, as one of the options that @Peter R suggested in the form of a new optional transaction format, just making it easier for to split coins. People would still lose money but it would mitigate the potential damage and ensure a better user experience. This way we would also not break compatibility with other wallets and it might even make it easier for various wallets and services to integrate replay protection as well, which would be another practical reason for them to run BU as their primary node software instead of Core.

 

[VeritasSapere]

I really do think it is unavoidable that there will be a split and that there definitely will be more then one surviving chain if not more, I think attacking the smaller chain is also unethical, they have the right to exist and I think any attacks will be futile anyway, the chain can be adapted again and again, their ledger can survive and they should have that freedom of choice as well to pursue their own vision.

I would even consider the destruction of the smaller chain a political failure of Bitcoin, I would seriously consider its governance to be fundamentally flawed at that point. I am sure many of us here must know people that do seriously believe in the Core vision and are diehards who will not give up on their principles. I certainly do know people like this and on some levels we can respect that even if we disagree, it is the same types of people who will ensure that Bitcoin will never die and I count myself as one of those types of people, we just happen to be on different sides of this debate. Because of people like this however we can be certain that when we increase the blocksize limit the chain will split regardless of the size of the dissenting minority or circumstances.

Eveybody who studies Bitcoin Unlimited knows that it is exactly the goal of if to achieve a blocksize increasing hardfork which is no "contentious forking event" but an "emerging consensus".

I entirely agree with you on this point, however I think we are now in a more unique situation, where there is contention and the only way to go forward is for the network to split, to better reflect the split communities and the divide in vision. This way both sides gain a network with a more clear purpose and consistent vision.

I think that under "normal" circumstances Emergent Consensus will be able to increase the blocksize limit without a "contentious forking event" but this first time has to be a contentious event and there is no other way around that. It is the realist political reality of the landscape and time we find ourselves in.

 

[Zangelbert Bingledack]

Pretty fair graphic to put things in perspective (via reddit):

 

[bluemoon]

@VeritasSapere
I think attacking the smaller chain is also unethical, they have the right to exist and I think any attacks will be futile anyway

There is a struggle between two opposing sides and the prize is domination of the rules governing the operation of the Bitcoin blockchain: only one side can win that prize. Large and small blocks cannot co-exist on the same blockchain.

The only way both sides can continue is if one side (presumably the losing side) creates its own independent blockchain, spawning it from the forked blockchain.

I have no problem with the loser creating an independent blockchain if the loser goes it's own way. The market can give its verdict in various ways and confer viability or not. That seems to be the ethereum outcome.

What could not be tolerated would be an ongoing war where the loser nursed its chain while mounting dirty tricks to undermine and displace the hashpower winner, tricks such as: ddos attacks, running off with the intellectual assets, communication and information manipulation, personal intimidations, etc, etc. Sometimes poison must be removed and it is not always a pleasant task. I am not convinced BS Core is willing to lose gracefully and if they are not I have no problem with them being excised.

Of course, whether it is possible to excise them if they have created an independent chain is another matter.

 

[freetrader]

@torusJKL

There was once discussion here about the possibility of creating a viable minority fork away from Core. As I remember, those technically competent - I am not - seemed to think it possible.

Yesterday on BU Slack, I posed a general question whether people would be interested in me to submit a BUIP for replay protection as implemented on MVF-BU

https://github.com/BTCfork/hardfork_prototype_1_mvf-bu/pull/67

The replay protection scheme in MVF-BU is optional - just by choosing a chain ID of zero (0) , you ensure that your transactions can be replayed. If you choose any other allowed value in [1, 2^24-1], then the receiver has to explicitly test for that to determine validity of the transaction signature.

I do agree, personally, with arguments put forward by many others (not only from BU) that an upgrade which is planned as a supermajority hard fork at 75%+ , should leave it up to the minority chain to make itself incompatible with all transaction-generating and validating software which would need to be upgraded. I'm not sure the impact is correctly assessed by supporters of this scheme, and there has not been a published cost-benefit analysis accompanying the recent statement by the exchanges who wish to impose part of this cost on BU and others.

I think that methods outlined in [1] for exchanges could already suffice well enough for a smooth transition.

It is a different matter when considering things from the viewpoint of a minority hashrate spin-off, which is how the MVF clients were conceived/specified.

But of course, we could put the matter to a BUIP vote, which will bring out much more discussion and perhaps important arguments that we have overlooked so far.

There are certainly technical issues (e.g. the delicate matter of existing timelocked transactions) that need to be considered carefully. Of course there are various proposals on bitcoin-dev too regarding how to do replay prevention in an opt-in manner. I believe @dgenr8 published one of the first ones.

[1] https://github.com/digitsu/splitting-bitcoin/blob/master/README.md

 

[yrral86]

@Peter R




Couldn't miners organise something like this themselves?

First they build up a transaction backlog of say 100MB, then once say 75% hashrate was achieved and the first >1MB was about to be produced, they decide to ONLY produce blocks larger than 1.1MB for 100 blocks and orphan everything else?

Would this work as a sort of replay resistance and also kill off the weaker chain faster?

I believe the idea is to not fork until everyone capitulates and runs BU. That way we can eliminate the argument that BU forked bitcoin and is an alt coin. By orphaning non-compliant blocks first, we are essentially soft-forking to a BU compatible network.

 

[VeritasSapere]

@VeritasSapere
I think attacking the smaller chain is also unethical, they have the right to exist and I think any attacks will be futile anyway

There is a struggle between two opposing sides and the prize is domination of the rules governing the operation of the Bitcoin blockchain: only one side can win that prize. Large and small blocks cannot co-exist on the same blockchain.

I am not saying that we will be on the same blockchain and I agree we can not co-exist on the same network, this is why a split is the best solution, obviously increasing the blocksize limit will create a split, even if some people just choose to stay behind. Sure the smaller chain can be attacked, then they can just change the POW, it could be attacked again under GPU/CPU, they could maybe then introduce points of centralization temporarily or they could even reboot the chain using older checkpoints if the chain completely stops or is taken over by malicious actors, this would be like a rewind ironically, they could even introduce something like POS, just to survive such a chain can do a lot when faced with attack. These networks are anti fragile, some of these people have the will to continue with their chain no matter what, I think it is better we embrace that and even support it out of the principle of the freedom of choice.

The only way both sides can continue is if one side (presumably the losing side) creates its own independent blockchain, spawning it from the forked blockchain.

Exactly, this happens without there even being any intervention, for the chain to survive intervention like I mentioned might be required though.

I have no problem with the loser creating an independent blockchain if the loser goes it's own way. The market can give its verdict in various ways and confer viability or not. That seems to be the ethereum outcome.

Exactly that is what I am saying, we are in agreement, maybe you misunderstood what I said?

What could not be tolerated would be an ongoing war where the loser nursed its chain while mounting dirty tricks to undermine and displace the hashpower winner, tricks such as: ddos attacks, running off with the intellectual assets, communication and information manipulation, personal intimidations, etc, etc. Sometimes poison must be removed and it is not always a pleasant task. I am not convinced BS Core is willing to lose gracefully and if they are not I have no problem with them being excised.

I very much doubt they will lose gracefully but we do not need to scoop to their level.

Of course, whether it is possible to excise them if they have created an independent chain is another matter.

I suppose my point was that it wont be possible to excise them once they have created an independent chain which I am certain will happen. This is part of the beauty of these networks however we do not need to attack them and as separate networks we can co exists. Live and let live.

 

[Dusty]

I believe the idea is to not fork until everyone capitulates and runs BU. That way we can eliminate the argument that BU forked bitcoin and is an alt coin. By orphaning non-compliant blocks first, we are essentially soft-forking to a BU compatible network.

This idea seems great!
As soon as BU get a majority hash rate miners must orphan blocks not signalling bigger blocks.
Since there is the rumor that some miners are falsely signalling BU while in reality running Core this would be a real test for BU, but a non destructive one: if the orphaning does not succeed we know that BU has not enough hash power to fork Bitcoin and succeed, and must wait until he has more.

And this would be a SOFT FORK, the one Core was looking for

The Core miners would begin losing tons of money and should immediately decide to
1) Signal BU while running core
2) Switch to BU

But after a while, in a way or another, 100% of the network will signal big blocks and the first step of the soft fork would have succeeded.

Second Step would be to find EC to raise blocks, as in BU philosophy!

 

[HostFat]

Miners can just start some to orphan some random core blocks after reached the 51%.

 

[painlord2k]

EC miners should coordinate their actions about this behaviour or they risk to damage themselves.

They should just orphan not EC block when their number is odd during odd days.
Or something like that.

 

[Mengerian]

@Zangelbert Bingledack

Bitfinex is introducing a fork arbitrage market: https://www.bitfinex.com/posts/195

 

[Dusty]

Too bad that there is no future market, otherwise the fork could be resolved even before the beginning...
[doublepost=1489882148][/doublepost]https://www.reddit.com/r/btc/comments/6060i2/why_coinbase_didnt_sign_the_industry_letter/

Coinbase didn't sign this letter because I think the intention behind it is wrong.

On the surface it is a communication about how exchanges would handle the hard fork, and a request to BU for replay attack protection. But my concern was that it was actually a thinly veiled attempt to keep the BTC moniker pegged to core software. I think a number of people who put their name on it didn't realize this.

A couple thoughts:

• Certainly it makes sense to list forked assets separately on exchanges, especially during periods of uncertainty. But it doesn't make sense to say BTC can only be modified by one development team. If there is overwhelming support from miners and users around any new version of the software (regardless of who wrote it), then I think that will be called Bitcoin (or BTC).
• The replay attacks are a real concern. We spent some time talking with Peter Rizun from BU last week and he/they seem very open to hearing ideas on replay attack protection and coming up with solutions, which was great to see. It is not as trivial for them to add as I originally thought, because it seems adding replay protection would break SPV clients (which includes a number of mobile wallets). We as a community could probably use more brainstorming on how to solve this generally (for any hard fork). I'll make a separate post on that.
• I think regardless of what was stated in the letter (and people's personal views), pretty much every exchange would list whatever version got the overwhelming majority of miner and user support as BTC. I also think miners know this.
• A number of exchanges (GDAX, Poloniex, Gemini) didn't sign the letter, or later clarified their position on it (ShapeShift, Kraken), so I think there are a variety of opinions out there.
• I think creating public industry letters that people sign is a bad idea. They haven't been very effective in the past, they are "design by committee", people inevitably say their views were not accurately represented after the fact, and they tend to create more drama. I'd rather see private communication happen to move the industry forward (preferably on the phone, or in person - written communication is too easy to misinterpret people's tone). Or to have each exchange state their own opinion.
• My goal is to have Coinbase be neutral in this debate. I think SegWit, BU, or other solutions could all be made to work in bitcoin. We're here to provide whatever our customers want as best we can across all digital currencies, and work with the wider community to make forward progress.

 

[Mengerian]

Devil is in the details though, for the Bitfinex fork market.

It seems vague how they decide what the token corresponds to. The tokens are for " Bitcoin Unlimited blocks that are not compatible with Bitcoin Core clients".

But what if Core releases a client that accepts >1MB blocks, compatible with BU, and there is not fork? The way they have worded it, the "BCC" token would then be redeemed, and the "BCU" token would be worthless.

It is also asymmetrical. It defines what happens if there is no fork, BCU token is worthless. But it doesn't specify conditions under which BCC token would become worthless.

It needs to specify more objective criteria. Like say that BCU token can be redeemed for BTC on a block chain that includes >1MB blocks, even if there is no competing chain, and BCC token is retired in this case.

 

[albin]

I'm not down with that Bitfinex scheme.

Prediction markets are ok but this is begging to be fraud.

They get to arbitrarily drive the fork token to zero simply by not listing by the end of the year.

On the other side of the coin, they create perverse incentive to chain split prematurely simply to give the fork tokens value.

Either way, they have asymmetric information that they can insider trade against their customers.

 

[HostFat]

By orphaning the losing chain, "before the hard fork", also there isn't anymore reasons to solve the replay attack.

 

[adamstgbit]

I'm not down with that Bitfinex scheme.

Prediction markets are ok but this is begging to be fraud.

They get to arbitrarily drive the fork token to zero simply by not listing by the end of the year.

On the other side of the coin, they create perverse incentive to chain split prematurely simply to give the fork tokens value.

Either way, they have asymmetric information that they can insider trade against their customers.

Makes me wanna send 1BTC over there and trade BU BC