Exchange response

[Joel Dalais]

Background - http://www.coindesk.com/bitcoin-exchanges-unveil-emergency-hard-fork-contingency-plan/

It's been under discussion in slack most of the evening, here is the current draft version of the response letter from BU. Please feel free to offer suggestions, comments, etc, PM me if you feel like doing that instead.

If you are a Bitcoin Unlimited Member and you are happy with how it is then post an YES, or a NO if you don't like it at all (including suggestions with a NO is most welcome).

If a majority agree then it will be forwarded to Peter.R and relevant crypto news media outlets contacted with the response.

I would like to give this a 24 hour window before forwarding it on, responses in that time would be greatly appreciated. By a 'majority', I mean a majority of replies (as many BU members might not see/respond).

---------------------------------

Dear Community and respective exchanges,


We are happy to hear that exchanges are making preparations to safely handle a transition to a >1MB block chain. We agree that it is important to minimize the risk of such a split through appropriate planning and preparation. We share your goals of ensuring a smooth transition, protecting users, and avoiding confusion.

We encourage you not to list the coins of a minority chain post-fork as BTC (XBT). Although you desire to remain neutral as the market determines which fork shall be declared Bitcoin, this would send a very strong message to end users that the minority chain is still Bitcoin and that it would be safe to use.

This is not the case, as the minority chain will need considerable time for a mining difficulty adjustment. The combination of high difficulty, low hashrate, a 1 MB block size limit, significant exposure to a 51% attack risk, and volume will severely congest transaction capacity on the minority chain. End-users will find it exceedingly difficult to make any transactions.

Nodes currently consider the valid chain with most proof of work the correct one, and will keep extending that chain regardless of the size of specific blocks below the historic limit of 1MB.

Not only would this be detrimental to the current user experience, but it would also be viewed as a disaster by the outside world looking in. End users, mistakenly guided to believe that the minority chain is still Bitcoin, may incur significant financial damages.

The probability of a minority hashpower catching up diminishes exponentially as subsequent blocks are added.

We understand and accept the need for respective exchanges to safeguard the monies of their customers during a potentially turbulent coin split. Thus, we encourage you to use the identifiers BTC-c (or XBT-c) and BTC-u (or XBT-u) for coins on the minority and majority chains, respectively. As already stated, the identifier BTC (or XBT) can be assigned to the dominant coin at a later, more appropriate time.

The majority's choice is represented by the chain which has the greatest proof-of-work effort invested in it. This chain will grow the fastest and outpace any competing chains.

We would ask that exchanges, for the benefit of their customers and the bitcoin sector, clarify what they consider as Bitcoin. Whether it is defined by the majority hash rate, or defined by the Core development team. This will enable end users, in the event of a fork, to make better decisions as to whether they wish to trade on a less secure ever diminishing minority chain, or to continue to trade on the majority chain.

With regards to replay risk, we feel the topic is too big for this initial response and we will provide a clear guide on how exchanges can best protect against this in the coming days.

"The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem."

It might also be prudent for exchanges to notify users as to whether it is defined by the SHA256 majority hash rate if the PoW of the minority chain is changed by Core development.


Sincerely,


Bitcoin Unlimited

-----------------------------------------

Quotes is from - https://www.bitcoin.com/bitcoin.pdf

-----------------------------

edit notes will be below this;

fixed grammar in replay paragraph
quotes placed in italics
made more changes, as per my post lower down in this thread

 

[Joel Dalais]

yes.. the title is missing an s... 'exchange response'

anyway..

 

[bitsko]

Joel I think its great.

perhaps these exchanges have not seen this document?

https://github.com/digitsu/splitting-bitcoin

 

[Bloomie]

Fixed the title

 

[freetrader]

YES

request: place the quotes in italics so they stand out more as being quotes vs. the rest of the statement

 

[AdrianX]

my position has not been formulated but my gut reaction is:

"replay protection" by other name is "transaction incompatibility" with the existing bitcoin network.

While BU can implement such a feature - the ultimate control of the bitcoin protocol resides with the bitcoin users who run BU, so "replay protection" would be a user activated setting according to BU founding principals.

Given most nodes do not do Proof of Work they are vulnerable to sybil attack, bitcoin in accordance with the design intent as expressed in section 5 of the white paper and section 12 allows only the nodes that perform Proof of Work the authority and and capability to implement such a change. So it would be up to the miners to activate it.

The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.

Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

the BU development team has the ability to include such a feature but in accordance with the founding principals not the authority to activate it.

I also respect there attempts to change bitcoin but bitcoin governance is managed not through centralized agreements but Proo- of-Work.

I believe Bitcoin Core being a centralized authority in this matter is in a better position to implement "replay protection" and push it to there network more effectively than the bitcoin miners pushing such a change onto the bitcoin network.

 

[freetrader]

@AdrianX : I'm confused by your first quote and the rest that follows about replay. How are the two related?

It looks to me like you must have misread or misquoted the first quote.

Because it's simply saying that the majority work chain is Bitcoin, from where we stand, which does agree with the whitepaper description.

 

[AdrianX]

LOL - my suspicious mind misread the first quote. "minority" for "majority" thanks. post edited. dyslexia has some great advantages - that's not one of them.

and

yes

 

[adamstgbit]

I want to organize a BU bug bounty,
it would go somthing like this.

i manage an address which we donate sums too

when hackers, BU devs, Core dev, whoever find a bug they get a % of the current total on that address

A bug = 50% of the pot
B bug = 25% of the pot
C bug = 5% of the pot
KS bug ( Known Shippable ) = 0.5% of the pot

the pot never runs empty

i'd put a good 50$ donation. maybe "BU foundation" could put a couple thousands dollars in?

just a thought.

Edit: OPS i thought i posted this in the gold collapsing thread... ohwell

 

[Joel Dalais]

BU bug bounty - definitely something to work on .. added to my 'to do' list, but re-directing this back to the exchange response.

 

[freetrader]

Another suggestion re: the Exchange Response (addition in bold):

Whether it is defined by the SHA256 majority hash rate, or defined by the Core development team.

This makes their stance towards the current miners clear, in case Core decides to pull the POW fork move while trying to hang on to BTC / Bitcoin as name for their coin.

At the very least, the exchanges would have to begin arguing against why SHA256 should be disregarded, if they want to adopt that stance.

 

[Mengerian]

It should start out on a more positive note, IMO.

Start with something like:

"We are happy to hear that exchanges are making preparations to safely handle a transition to a >1MB block chain. Although not certain, this transition also holds the risk of a chain split. We agree that it is important to minimize the risk of such a split through appropriate planning and preparation. We share your goals of ensuring a smooth transition, protecting users, and avoiding confusion.

With these common goals in mind, we believe that the plan outlined in the recently announced Exchange Contingency Plan has some areas that could be improved, and we offer the following suggestions:"

I would also similarly tone down the language in the rest of the statement. Don't phrase it like you're trying to convince them ("strongly encourage"..etc). Just say what we think is a better approach and why.

 

[Zangelbert Bingledack]

I'm afraid I'll have to vote against this letter as written.

My comments from Slack:

Be careful not to play right into Core's hands here. There is no such thing as BTU, BTC-u, or BU coin. BU doesn't create any specific coin. ViaBTC's proposal that the miners are following would produce one kind of fork, and someone else's proposal would produce another. Using BU. The "temporary pet name" would be YangCoin, BTY, or BTC-y. (Or whatever the proposal the miners go with is.)

Anyway, BTC-c and BTC-y would be a fair temporary naming in that case because it is Core's proposal versus Yang's/etc. We cannot assume the majority of hashpower is enough because the traders can change where the majority of hashpower goes in a matter of SECONDS.

Miners decide the rules is the original Satoshi design, but miners do have a possible chance of misreading the market. That chance grows as the split approaches 50-50.

Fork futures avoids all this. That is what I think we should say to the exchanges first and foremost, as it is the solution to all of this. Then once that point is made clear, we can note that the minority hashpower chain is very unlikely to survive BUT the trading determines where the hashpower goes AND that outcome could be different from expected if somehow the miners mess up (unlikely, and even unlikelier with fork futures done in advance, but still a possible event). To prepare for the possible event, the two coins have to be listed with neutral names and ordering, BTC-c and BTC-y, and here we slap them in the face (gently) for not even knowing that BU doesn't make any specific coin, unlike XT and the old Classic2MB plans. Again emphasize that fork futures are the way to avoid issues here, as they let miners be more sure what the market actually wants, and maybe describe technically how that works from Ben Davenport's article. Then close. That's how I'd suggest doing it.

I do think the appeals to Satoshi will burn us (Appeal to Satoshi), and I don't think leaving his name out makes it any better. Everyone knows where those quotes come from.

 

[freetrader]

I sort of agree on rather dropping the Satoshi quotes, rather re-word them to avoid the 'Appeal to Satoshi' argument and relate to current situation.

Suggestions:

"Nodes always consider the longest chain to be the correct one and will keep working on extending it."
-->
Nodes currently consider the valid chain with most proof of work the correct one, and will keep extending that chain regardless of the size of specific blocks below the historic limit of 1MB.

---

"We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added."
-->
The probability of a minority hashpower catching up diminishes exponentially as subsequent blocks are added.

This needs to be checked for best accuracy [1] . Strictly speaking, I think the wording there still holds true. Perhaps @Peter R could give us some advice here on whether we can leave it as is.

---

"The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU (hash) power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains"
-->
The majority's choice is represented by the chain which has the greatest proof-of-work effort invested in it. This chain will grow the fastest and outpace any competing chains.

---

"The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem."
-->
Maybe leave this quote untouched.

[1] http://cyrilgrunspan.fr/wp-content/uploads/2017/02/DoubleSpend.pdf

 

[Joel Dalais]

I've taken Mengerian's 1st paragraph and put that at the start, removed the previous (similar) last paragraph. I didn't use the full paragraph though as i'm very certain there will be a split (judging from 'die-hard' miner support for Core).

I've added a small paragraph about SHA256/changing PoW near the end.

Regarding Zangelberts/Forkius post - whereas I hear you on the BTC-c / BTC-y, I think that many people (end users and exchanges) are already confused about the scenario, and labeling our advice as BTC-c / BTC-u is more understandable for the wider community (the BTC-c / BTC-u advice is also a nod towards coinbase).

Re: the approach to 50-50, I'm not that concerned, traders will trade on hype, but I believe there will be very advanced warning from miners who will discuss with BU as to the best time (and giving far enough public warning) when to activate. So we could comfortably go 75-25, and still wait for the pre-set activation date.

I'm really not sure what to say on 'Fork Futures' .. should this be included in this particular letter? Would it be better to include something about this in the 'replay guidance' instead?

Is the naming btc-u / btc-y your main concern?
[doublepost=1489868543][/doublepost]removed/changed quotes as per suggestion

edit: have discussed 'Fork Futures', we won't include reference to it in this particular letter, but will be discussing it in the near future, more to come on that at a later date.

 

[AdrianX]

u/tl121 on reddit made this point I think it is a good argument for who is responsible for replay protection.

Replay protection should be the responsibility of the holder of any coins. This is the default situation today (since by not signing with the private key the holder isn't playing or replaying the coins).
After the chain has split and is deemed to be a real split (not just random orphan event) then there are various ways a holder can move his coins to an address that is valid on only one chain and this can be done twice, creating two piles of coins, one pile for each chain.
>This can be done locally by each holder of coins, including making the decision to do this or not and defining what it means to be a real split or just a normal orphan event. This is a purely local decision requiring local action, so there is no need for any consensus on how to do this.
Since this is purely local, then each exchange can divide its holdings using whatever method it deems fit. And each exchange can name the forks each way it seems fit. There is no need for a central authority. Debating about how these matters should be handled serves no purpose, unless one's purpose is to create FUD that will delay people from proceeding with the fork.

I think we should offer to help exchanges with strategies to mitigate all risk to any loss.

 

[Joel Dalais]

>I think we should offer to help exchanges with strategies to mitigate all risk to any loss.

Definitely. It's not just in the interest of exchanges, but end users, and how the 'outside' world will view this event.

Discussion is going on how best to do this, I'm prodding development of a 'replay protection guidance' that we will forward to all stakeholders and the wider public when its ready.

 

[freetrader]

Someone on Reddit made a comment about a simple tool that could be written to split coins that are under control of a user. I like this idea for several reasons.

Firstly, it could be available to anyone without the needing to register at some exchanges which might not be available to them due to jurisdiction or other factors.
Secondly, it could offer a level of convenience similar to the contract-based splitting which was available for Ethereum's hardfork.
Thirdly, something like that could probably be re-used easily in the future, or even extended to a situation where there are multiple forks.

On the 'replay protection guidance', I'm for the idea of drafting and informational / educational materials.
But I would like to urge that at the same time we should point out the terms under which people use Bitcoin software.

 

[AdrianX]

>I think we should offer to help exchanges with strategies to mitigate all risk to any loss.

Definitely. It's not just in the interest of exchanges, but end users, and how the 'outside' world will view this event.

Discussion is going on how best to do this, I'm prodding development of a 'replay protection guidance' that we will forward to all stakeholders and the wider public when its ready.

this is less of a headache for exchanges and more a concern for wallets particularly SPV wallets.

 

[Joel Dalais]

Final/published version - https://medium.com/@solex1/bitcoin-exchanges-and-the-delicate-balancing-of-fork-coins-33dedc9c9486#.5plp3gmga

Happy to say pretty much none of it is my original words, this is what 'collaboration' really means