How to Ensure Connection is made to Safe Software [XT / Core user decision]

[ABISprotocol]

Recently I made the following post to the bitcoin-dev list:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010398.html

The questions raised there got no answers and so I am kicking off a question session here.

Namely,

A) How to make sure that you are actually connecting to a node
that is running Core with the most current version (that is to say, _not_ XT and _not_ Core in some much older and dated version)?

(Note: I do not feel that guidance at
https://bitcoin.org/en/alert/2015-07-04-spv-mining
entirely answers this question.)

B) During a fork, or during an attempt to create a fork, how do you authoritatively determine:
1) which side of the fork an Electrum server is on
2) Same question but for Core, etc....

C) What are the ways to do this (ensure that you are actually connecting to a node running Core with most current version) for:

1) hardware,
2) desktop,
3) web, and
4) mobile wallets?
(Please provide examples, such as how you would do it for Electrum vs. how you would do it for Coinkite or Coinbase.)

The end user should be able to decide at all times what they are connecting to.  When or if it becomes apparent that we can no longer connect to Core nodes or Core servers for Electrum (in the event that the network turns into XT) then users should be able to see this so that can get out of bitcoin before we are locked out from spending.  There will be many of us who will not switch to XT and consider it essentially the end of bitcoin.  All we are looking for is a way to not connect to it until such time as it is clear that XT is either gone for good or until it is evident that it will "become bitcoin" (which actually means, because of how XT is designed, that it will "diverge from bitcoin and become an altcoin") in early Jan. 2016.  If it is clear that XT is going to "become bitcoin" so to speak then we want out of bitcoin before Jan. 11, 2016, so that we will not be forced into XT.
Some "whys" in case you were wondering:
https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hearn_and_why_you_should_not/

Thanks in advance for your answers to the questions in this post.

References:
https://bitcoin.org/en/alert/2015-07-04-spv-mining
https://github.com/bitcoin-dot-org/bitcoin.org/pull/933
https://en.bitcoin.it/w/index.php?title=July_2015_chain_forks
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010398.html
https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hearn_and_why_you_should_not/

[1714472878]

1714472878

[1714472878]

1714472878

[1714472878]

1714472878

[mezzomix]

As several users will keep using the original BTC chain the most important point is to differentiate between the original BTC and the forkcoin BXT. In addition you might need to change your client to drop clients that deliver bad blocks. It make no sense to stay connected to peers that deliver garbage.

If the naming and the connection problem is resolved BTC can coexist with one or more forkcoins.

If it is clear that XT is going to "become bitcoin" so to speak then we want out of bitcoin before Jan. 11, 2016, so that we will not be forced into XT.

As long as BTC is alive, which means there are users and miners, BXT cannot become BTC. There is no need for you to go out of BTC.

[ABISprotocol]

As several users will keep using the original BTC chain the most important point is to differentiate between the original BTC and the forkcoin BXT. In addition you might need to change your client to drop clients that deliver bad blocks. It make no sense to stay connected to peers that deliver garbage.

I agree that it makes no sense to stay connected to peers that deliver garbage.  Hence my rather specific questions about how to authoritatively determine what software the peers you are connected to are running, how to determine (beyond the banner information provided in Electrum) whether the information they provide about the software the server you are connecting to is correct, which side of the fork an Electrum server is on, same question but for Core, and ditto for other wallets... people should be able to have (reasonably) simple instructions for determining how to avoid connecting to clients that are either old versions of Core or the XT (in any version).

The questions I have are, how?  That is why I posted the questions in the way I did in my post above.

If the naming and the connection problem is resolved BTC can coexist with one or more forkcoins.

If it is clear that XT is going to "become bitcoin" so to speak then we want out of bitcoin before Jan. 11, 2016, so that we will not be forced into XT.

As long as BTC is alive, which means there are users and miners, BXT cannot become BTC. There is no need for you to go out of BTC.

The following is taken from digitsu99's post at
http://wallstreettechnologist.com/2015/08/19/bitcoin-xt-vs-core-blocksize-limit-the-schism-that-divides-us-all/

"Why is this situation really bad?  Because of the exact reason why Hard Forks are dangerous.  If they have a consensus, they are resolved quite quickly with one fork winning over the other. (and it doesn’t matter which is longer!) That’s how it was resolved in the past, by unanimous endorsement by core to choose one over the other (and upgrade or downgrade accordingly).  IF there is no clear winner, because each side wants to stick by their guns due to ideological reasons, then we have a problem.  Why?  Consider Alice, who uses wallet A, and Bob, who uses wallet software B.  Wallets need to communicate with nodes to get their block confirmations. If wallet A is connected to a Bitcoin (John) chain node, and Bob’s wallet B is connected to a node running the XT (Judas) chain then they are no longer going to see the same block confirmations, and they won’t know about it!  Alice will send bitcoins to Bob, she sees a confirm, but Bob will never see a confirm, if the coins are originally minted from a post-Judas block.  If it is from Jesus block or less, then her transaction with Bob will work and be seen by both of them, BUT then Alice can re-spend those same coins with a counterparty on the John chain!  (and this goes both ways).  This breaks the fungibility of bitcoins, and will likely cause a massive loss of confidence of Bitcoin as payments will no longer be able to be reliably confirmed.  Because both are operating on the same network (IP ports, QR codes, URI etc) there is no way to detect a-priori if your payment is being made to a receiver who can receive it, until after you try (or unless they are really tech savy and you both know which side of the fork you are on).  This bad situation can happen as early as 100 blocks after Judas block. (about 16 hours).  Much of the chatter in the social channels portraying the XT upgrade as perfectly safe seems to be deliberately ignoring this fact.  And for understandable reasons.  IF (and only IF) everyone does upgrade to XT, then we will have no problem."

Of course, I would not agree with the concluding statement that "IF ... everyone does upgrade to XT, then we will have no problem."  The problem will be massive.  Why?   Because people that don't upgrade won't be able to spend their coins (at least not in the way that they once did; it will have set bitcoin progress back by years).  The fork will have moved forward; Hearn has stipulated he is perfectly comfortable with leaving people behind if they don't upgrade to XT. 

In the end however these details seem almost OT to the post. 

I'm truly interested in answers to some very specific questions:

During a fork, or during an attempt to create a fork, how do you authoritatively determine:
1) which side of the fork an Electrum server is on
2) Same question but for Core, etc....

What are the ways to do this (ensure that you are actually connecting to a node running Core with most current version) for:
1) hardware,
2) desktop,
3) web, and
4) mobile wallets?
(Please provide examples, such as how you would do it for Electrum vs. how you would do it for Coinkite or Coinbase.)

Thanks in advance for any answers that specifically address these questions.

[mezzomix]

The questions I have are, how?  That is why I posted the questions in the way I did in my post above.

You cannot prevent connection to a bad client but the consensus rules will sort it out and you can drop the connection. As the blocks before the fork are identical you can even use forkcoin peers to bootstrap your client.

During a fork, or during an attempt to create a fork, how do you authoritatively determine:
1) which side of the fork an Electrum server is on
2) Same question but for Core, etc....

See above. The only way is to use the consensus rules.

What are the ways to do this (ensure that you are actually connecting to a node running Core with most current version) for:
1) hardware,
2) desktop,
3) web, and
4) mobile wallets?
(Please provide examples, such as how you would do it for Electrum vs. how you would do it for Coinkite or Coinbase.)

Thanks in advance for any answers that specifically address these questions.

I think the question is, how do SPV clients deal with the situation?

[TierNolan]

A) How to make sure that you are actually connecting to a node
that is running Core with the most current version (that is to say, _not_ XT and _not_ Core in some much older and dated version)?

When connecting to a node, all you can do is hope that at least one is honest and on the chain that you are looking for.

Next, you download the header chain from each of them and find the longest chain.

The XT chain is always the one with the most POW.

The core chain might be the one with the most POW.

If the XT chain hasn't produced a bigger than normal block, then they are both the same chain.

Additionally, if a majority of miners are mining the core rules (1 MB max block size), then the XT chain will be the same as the core chain.

If you want the XT chain, you just go with the most POW and done.

If you want core, then you need to determine if the chain you are on is valid.

This requires a fraud proof.  Core nodes could send you the first block on the XT chain that is more than 1MB.  That proves that that chain is invalid (for core rules).  You can then blacklist that block header and all children.

This fraud proof is probably worth adding to the protocol.  Core nodes could store the first invalid block on the XT chain and send it to peers who try to download its children.

[ABISprotocol]

The questions I have are, how?  That is why I posted the questions in the way I did in my post above.

You cannot prevent connection to a bad client but the consensus rules will sort it out and you can drop the connection. As the blocks before the fork are identical you can even use forkcoin peers to bootstrap your client.

During a fork, or during an attempt to create a fork, how do you authoritatively determine:
1) which side of the fork an Electrum server is on
2) Same question but for Core, etc....

See above. The only way is to use the consensus rules.

What are the ways to do this (ensure that you are actually connecting to a node running Core with most current version) for:
1) hardware,
2) desktop,
3) web, and
4) mobile wallets?
(Please provide examples, such as how you would do it for Electrum vs. how you would do it for Coinkite or Coinbase.)

Thanks in advance for any answers that specifically address these questions.

I think the question is, how do SPV clients deal with the situation?

An SPV client such as Electrum can handle the situation in the way described here:
https://en.bitcoin.it/w/index.php?title=July_2015_chain_forks
However, as noted in the wiki,
"Please note that this information" (by which they mean the software and version information in the banner)
"is provided voluntarily by the server administrators. It is not validated."
The question remains therefore how to validate that.  It suggests further the use of a Get Block Header custom plugin in order to determine which side of the fork an Electrum server is on, which is not a perfect solution but is better than not checking.

Most users are not knowledgeable (or interested) enough to go through the steps here to get that plugin, as it's not an option in Electrum that you can "checkbox" in:
https://bitcointalk.org/index.php?topic=1110912.msg11800126
So it's difficult for most users.  

SPV clients should provide a way for users to simply know what side of the fork the Electrum server they are connected to is on with a few simple clicks without the users having to go through these gymnastics.  If they realize they are using a server which is running either old Core version(s) [Bitcoin Core 0.9.4 or earlier] or has XT, then they can make sure not to use that server.