Gold collapsing. Bitcoin UP.

[VeritasSapere]

I think BU should include replay protection, but it would have to be triggered during the fork or as @Richy_T mentioned it might be possible to add some sort of optional check box for replay protection? That would be amazing! I suppose such a checkbox could create a new type of transaction that only one side of the chain recognizes? I am not sure how this would work we will have to have one the devs report back on that possibility. And I also think holding a vote on this issue is a good idea.

Even though it is true that when BU forks it will fork as the majority chain and should be considered Bitcoin and therefore the smaller chain arguably should be the side that adds the replay protection. However, I think we should take the high ground here, we can be the side to compromise, a lot of good people lost money during the replay attacks in Ethereum, it would be best if we could avoid that scenario from taking place in Bitcoin. It might be easy for us to deal with splitting coins but that is certainly not the case for all users.

Furthermore this statement from the exchanges should be seen as an extremely positive development over all, even though we might not like the language they are using, I am sure they had to compromise as well to come together like that. During a chain split exchange support is extremely important, they just gave us an opening, an olive branch even. We should take it and use this opportunity to advance the vision of Satoshi and not let our pride get the better of us.

 

[Justus Ranvier]

Bitcoin already has "replay attack" prevention due to not being Ethereum.

 

[Roger_Murdock]

It seems to me that, despite rapidly worsening congestion and rising transaction fees, there's been a lot of complacency regarding the block size limit for the past year or so. Because, hey, "the price is up." The problem is that the price, at least in my opinion, isn't really "up." We're trading in a zone that we achieved over three years ago. That's an eternity in Bitcoin time. Bitcoin is still a young technology that should be experiencing significant (albeit volatile) exponential growth. But the opportunity cost of lost growth that would have occurred isn't (easily) visible. The rise of alts is starting to change that by putting Bitcoin's still rather pathetic market cap in context. Hopefully it's beginning to wake up the miners and other stakeholders who are still sleeping.

Re: replay protection, this approach seems sensible to me, but maybe I'm missing something:

 

[OWSLEYBEATSBIGCARTEL]

replay attack protection only make sense if there is a network to replay onto
if BU forks bitcoin with majority hashing power, nodes, and coins their won't be a chain to replay TX onto

^ADAM IS IT YOU???[CONFIRMED]===> SEND ME 1337 ABSTRACT COINS ASAP!! :-D WEEEE

 

[adamstgbit]

Confrimed

user[adamstgbit]->SendAC(1337, ownletbeatsbigcartel);

LOL

 

[Peter R]

I think Reddit has not understood the "replay risk" concern and has put the cart before the horse. Exchanges will support the large block chain regardless of replay risk. They essentially have to; if they don't, then they open themselves up to lawsuits.

The Bitcoin community wants the process of getting our first 1.1 MB block to be as painless as possible, and so we (Bitcoin Unlimited) should work with exchanges to help them understand the mechanics of how any possible blockchain split may play out and help them to mitigate the associated risks.

There are lots of ways we can do this, and some initial ideas include:

1. Minimizing the probability that a minority chain survives.

There is no replay risk if there is no blockchain split. I think this is the likeliest outcome (99% IMO). I think if the community simply had a better understanding of the huge cost an ideologically-driven miner would have to pay to keep the minority chain alive, it would go along way to quelling concerns. Beyond that, miners have proposed orphaning non-large-block signalling blocks prior to the first 1.1 MB block to act as a wake-up call to non-large-block-signalling miners. Should a minority small block chain form after the first 1.1 MB block, majority miners have suggested continually re-orging the minority chain, so that no transactions can be confirmed.

2. Create a new replay-resistant transaction format.

This could be done by making some currently "non-standard" transaction-type standard in BU, so that large-block nodes propagate these new transactions but small-block nodes do not. There would still be replay risk, but now it would require the cooperation and effort of small-block miners to perform replays whereas with regular transactions anyone can sniff the large block chain and mirror all transactions.

3. Make post-split coins readily available and provide clear instructions for how these can be mixed in to new transactions to guarantee replay protection.

This is the most natural solution (assuming a minority chain exists in the first place), but is also the most difficult to implement for large exchanges like Coinbase.


Anyways, I think these new developments with the exchanges is very good news because (a) it's become obvious that they will support the large block chain (along with the small block chain should it survive), (b) they would prefer to have no split at all and for any minority chain to immediately die.

 

[_bc]

Long time, first time. Big fan.

8MB-signaling miners are moving over.

https://coin.dance/blocks

37.5% of blocks today support Bitcoin Unlimited
28.5% of blocks today support SegWit
2.1% of blocks today support 8MB blocks

It still adds to less than 40%, but it's a positive sign, I think.

 

[lunar]

@Peter R

Beyond that, miners have proposed orphaning non-large-block signalling blocks prior to the first 1.1 MB block to act as a wake-up call to non-large-block-signalling miners.

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?

 

[Zangelbert Bingledack]

@Mengerian and others:

Hmm, I don't understand the anti-replay protection sentiment. I do understand that since we would only fork with majority hashpower, it would be Core's job to implement replay protection to protect their own chain. Is that all that is meant by it being a poison pill? Seems one side has to swallow that pill.

I haven't considered it deeply so I'm open to being convinced, but on first glance the refusal to allow for replay protection seems the same kind of thinking we reject from Core, that of using the software as an "inconvenience cudgel" to beat the community into a certain outcome. This time it would be ensuring that the dominant software (BU, say) does not allow an easy way for its users to send their txs only on one chain.

The market will of course ensure that there are not two coins, by selling the straggler to oblivion, if the market believes there should only be one. They should compete fair and square, shouldn't they? And in fact if the market wants two chains, it should have two. (Acknowledging the reality that miners aren't a *perfect* representation of the market.) Though I don't see why the minority wouldn't change the PoW immediately in that case.

Out of prudence it seems at least the minority side must prepare for an ETH/ETC situation just in case, or else AFAICT we unfairly favor the incumbent (Core; the exchanges are telling us this as well).

Or perhaps this is another one of those cases where the problem can be solved by making it an options feature? Then likely both Core and BU/etc. would have the option, just in case they ended up in the minority.

 

[Zangelbert Bingledack]

My latest rant about BU misconceptions, and judging from the slack channel talk that I've been unable to keep up with, some of these are affecting our side as well.

https://www.reddit.com/r/btc/comments/602vsy/clearing_up_some_widespread_confusions_about_bu/

 

[Richy_T]

However, I think we should take the high ground here, we can be the side to compromise,

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.

 

[Zangelbert Bingledack]

Anyone remember /u/muyuu, of the all-time hardest-bitten small blockers? BitcoinEC is the compromise that finally got him (and many others). Good wording, too: "it allows miners to separate concerns."
The way I see it, even if everyone who signals EC also signals Segwit, Segwit still has no chance to get to 95% before EC gets to 75%. And of course many will never signal for SW but will signal for EC. BU and its fellow EC travellers are winning!

 

[solex]

I just thought I would take a look at the forum where 90% of the OPs are referencing BU. Did manage to find one comment which deserves the daily prize:


I want a crystal ball like biosense has!

 

[Christoph Bergmann]

Hei, some thoughts about the statement of the exchanges:

1. It's great that they (and coindesk) finally have become able to use the word "Bitcoin Unlimited" and considerung the option that it is successfull. Some might even be ok with letting Emerging Consensus find a new blocksize in the long run. Thanks your this!

2. There are several interpretations of the document. A hard reading would result in the notion that the exchanges use the ticker name "BTC" not to represent "BiTCoin" but "BiTcoin Core" as they clearly stated that in event of a fork, BTC will be reserved for Bitcoin Core, independently of the hashrate and the stakes (vote.bitcoin.com). The decision to reseve the existing ticker for core's chain, even if it has support of a minorty or hashers, holders and users, is irresponsible against the customers. I also hope they had a lawyer at their side when underwriting this document, as it could be understand as a legal obligation to consider the product of Bitcoin Core developers as the one and only real Bitcoin, independently of all other factors. If so, this would be the most dangerous thread Bitcoin ever faced and can be understood as a coup.

3. Censorship works. The paper indicates that the exchanges don't properly understand Bitcoin Unlimited. Maybe some of them understand and made sure that this document will not be binding in case of a Bitcoin Unlimited hardfork by reducing its effects on "contentious forking event." 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". The interesting question is, what happens in this case. Will they list the old chain under the new ticker BTU? Or will still stick with core, even against an ecosystem wide consensus?

4. Replay attacks. While I'm all for making a possible fork as easy for exchanges as possible, I strongly advocate against implementing replay protections that change the transaction format. The point of BU is to find a consensus on a new blocksize. Breaking compatibility with every existing bitcoin-application is a safe way to fail with this. The idea however, that miners give exchanges some freshly mined dust-utxo to enable them to fork coins, does make sense and should be the

5. Exchange are not in the position to demand anything. The new Bitcoin chain will be backed by 70-80 percent of the power of the world's most powerful computernetwork, and the fork event could be the biggest opportunity for Bitcoin exchanges to earn money ever. If the exchanges miss this they mostly harm themselves.

6. Prices: Nearly immediately after the document was published, price fall. Combine this with the fall of the price and the leak into altcoins after the Bug in BU, it seems that markets want BU to succeed over Corecoin.

7. Outlook: Let r/bitcoin teenies celebrate that bitcoin unlimited has become an altcoin. Bring the hashrate on 70-80 percent. And do nothing. R/Bitcoin and Core will be become crazy. The attacks on Roger, Jihan and anybody else will peak. There will be constant DOS. Maybe we see some more bugs exploited, but since we soon have bitcoinEC, they will do no damage. Then start talking. Calm, sane, serious. With exchanges, wallets, companies and so on. Encourage them to use BitcoinEC or BU with a setting of EB1. Make the network ready to find a consensus about a new blocksize limit without depending on Core. Core or the Core-warriors will get so mad, that they start a UASF. As soon they do, persuade exchanges to list it as BTU. End of the story.

Edit: Looking at the hashrate distribution of the coin the exchanges want to list as BTC: BitFury alone has more than 40 percent, maybe more than 50 if you consider BitClub their toy. BTCC has 26 percent. Nice idea selling such a centralized and insecure chain as the real Bitcoin.

 

[freetrader]

but since we soon have bitcoinEC, they will do no damage

Unless you actually review the changes going in to that, this is a big assumption. More projects = more need for review, not less. If they actually get reviewed, then that is good, and probably benefits the overall Bitcoin system.
But it's certainly a long shot to say anything about BitcoinEC's quality just yet - no code has been written, it's still at the sales pitch stage. Hopefully they get good supportive developers and can build an enticing system.

Also to remind, it is a big assumption that latest Core does not have DOS-exploitable bugs which the Core developers know about from their issue backlog or internal tests.

These attacks can be targeted at specific groups of nodes - there is nothing in particular which guarantees that a close Core derivative would be spared any attacks if it threatened the plans of some people who think they run that show.

Anyway, I wish their project well - they have set themselves an interesting goal of marrying SegWit with EC. Let's see how they pull it off.

 

[Mengerian]

Hmm, I don't understand the anti-replay protection sentiment. I do understand that since we would only fork with majority hashpower, it would be Core's job to implement replay protection to protect their own chain. Is that all that is meant by it being a poison pill?

Yes, I agree. What I meant is that BU should not be bullied into changing to a transaction format that is incompatible with existing wallets and infrastructure.

 

[bluemoon]

BS Core invested a lot of effort to capture the Bitcoin reference client, which they did.

They also captured the principal means of communication and information exchange.

Now they have persuaded most Bitcoin exchanges to recognise BS Core's implementation to be identified with the Bitcoin name (rather than Bitcoin simply being the name of the dominant blockchain).

What else do they want?

I do not see them waiting for their opponents to organise properly. In a situation where their position is weakening, once BS Core have organised themselves, I foresee them forking themselves off the main chain with a changed PoW, taking the Bitcoin name with them. The sooner they do this the greater the confusion they will cause their opponents, and the less chance the exchanges will have to resile from their 'agreement'.

As a separate independent version of Bitcoin operating as 'Bitcoin' it will be hard to recover the brand name to the alternative BU client chain even if the Core chain is a mere shadow of the BU one.

 

[torusJKL]

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.

BU does not need to compromise but we need to get the exchanges on board.
Even with a majority fork, if the exchanges do not allow trading, miners will very quickly switch from the majority to the minority fork (making it the new majority fork)

In a situation where their position is weakening, once BS Core have organised themselves, I foresee them forking themselves off the main chain with a changed PoW, taking the Bitcoin name with them.

Wouldn't that put them back to CPU and GPU mining?
They would loose all their supporting pools hash power.

 

[bluemoon]

@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.

 

[Justus Ranvier]

The way I see it, even if everyone who signals EC also signals Segwit, Segwit still has no chance to get to 95% before EC gets to 75%.

A successful block size limit hard fork would demonstrate the viability of hard forks as an upgrade method, and then the designers of segwit could go back to the drawing board and come up with a better solution.