These.

The PR operates under the assumption that miners are not actually supportive of Segwit2x and not actually using the btc1 software. From some discussions with various miners and other trustworthy sources related to miners, this appears to be the case. From what I have heard, most miners are not using btc1 and will not be supporting the 2x part of segwit2x. When BIP 91 activated, they were actually running James Hilliard's Segsignal patch instead of btc1, with the exception of a few miners controlled primarily by Bitmain.

Even if this assumption is false and that miners are actually supporting the 2x part of segwit2x, the Bitcoin Core developers do not support segwit2x and will not be implementing it in their software. Either way, there will be a fork in the blockchain, with some miners supporting one fork, and others supporting the other one. It doesn't matter which chain has the majority hash rate since nodes on both chains will reject the other chain's blocks.

The whole purpose of this PR is to ensure that when the fork happens, it happens cleanly. The goal is to make nodes not ban each other, not have cross talk between chains, and avoid partitioning the network. By disconnecting (not banning) peers with these service bits, we are making it easier and more likely for those peers to be able to connect to other peers that will be using the same consensus rules, i.e. btc1 peers are more likely to make connections to other btc1 peers. This minimizes the risk of network partitioning following the fork as the btc1 nodes will be connected to each other.

In the PR thread, people mentioned that this will encourage nodes to lie about what their version is and the service they support. This behavior would actually be detrimental to btc1 peers. The service bit is used for preferential peering. By removing their service bit, they will be less likely to connect to other btc1 peers and more likely to end up partitioned from the rest of the btc1 network following the fork. In order to avoid that, it would be best for them to use the service bit for preferential peering and maintain connections to other btc1 nodes before the fork so as to have the same connections after the fork.

Lastly, the PR ensures that the network topology changes gradually. At the time of the fork, what will happen is that the network topology will change suddenly and possibly fracture the network into multiple partitions. By disconnecting the peers that we know will be following different consensus rules than us, we are ensuring that the network topology will gradually shift from a mixed pool of nodes, to two pools of nodes mostly separated, but still connected to each other. At the time of the fork, this will split in two instead of into multiple pieces.

If your blockchain is synced to be past the fork point, then you should not copy the chainstate. If that is the case, then only copy the blocks folder and run ABC with -redinex-chainstate so that it builds its own correct chainstate.

If you are not synced past the fork point, then it is fine to copy both the blocks and chainstate folders.

This topic has been moved to Trashcan.

Duplicate thread

Flextrans is not better than segwit and that table you posted is very miseleading. Flextrans has several problems. You can read explanations for why segwit is better than flextrans here: https://bitcointalk.org/index.php?topic=1822954.0

You are probably not synced yet. Bitcoin Core is probably still syncing. Stop Armory and start just Bitcoin Core. Let it fully sync. Once it is synced, then stop Bitcoin Core and start Armory. Armory should then start Bitcoin Core (the daemon, bitcoind) in the background for you. Armory will then sync its own databases from Bitcoin Core. Once that is all done, you should be able to access your Bitcoin.

Several of the video tutorials are outdated as the wallet software has changed significantly since those were made, including removing one of the tabs.

There is currently an open PR which will have Core disconnect any Bitcoin Cash or Segwit2x peer as those are or will become altcoins in the future.

That is expected when your transaction has less signatures than is required to spend the Bitcoin.

No. You can only get BCH coins either by mining after the fork or having those Bitcoin before the fork on August 1st (and of course buying them).

Since OP's question has been resolved and because of continuous spam, I am locking this topic. OP, if you want me to unlock this thread, please PM me.

What happens if you just click the "Receive Bitcoins" button on the main window, not in the Wallet Properties dialog?

I don't see any problem here. Is it just crashing on you?

Can you also post the armorycpplog.txt file?

Segwit and Segwit2x are not two distinct things. Segwit2x is an extension of Segwit, so when Segwit activates, so will part of Segwit2x. Segwit2x contains additional things on top of Segwit but those will activate later.

Currently Segwit is not activated yet.

Posting about such things on this forum is not going to be helpful at all; very few of the Core developers actually visit this forum. Additionally posts like these are usually ignored as they typically have no substance and only serve to fuel public hysteria and FUD. If you believe that you have found a critical security issue, send an email to security@bitcoincore.org. If you are concerned about the privacy of the email, then encrypt your message with some of the PGP keys found here: https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys (you probably want to encrypt to at least laanwj, gmaxwell, jonasschnelli, luke-jr, bluematt, and sipa)

Litecoin's thing is completely unrelated and irrelevant to Bitcoin. The current addresses will work and continue to work; making them not work would be a backwards incompatible change. Segwit will eventually have its own addresses which you can choose to use if you wish, but for now, segwit will work via P2SH addresses (3... addresses) instead of a native segwit address.

Please post your armory log files. You can find them in the Armory datadir.

Please post the entirety of your Armorylog.txt file. The error snippet you posted is completely irrelevant and benign.

It's possible that changes to the memory pool itself and how accepting transactions works is slowing it down. Several things have been added to and changed in the AcceptToMemoryPool functions which could impact performance. These include handling CPFP, minrelayfee that adjusts based on the mempool size, etc.

Could you show us the numbers you are getting for relay time and the methodology you used to get those numbers?

You can't. You could set up a script which checks the list of peers that you are connected to and then bans the ones that you don't want to connect to.

You don't need to upgrade, but upgrading is recommended as there are many bug fixes, features, and optimizations made between each major release.

Make sure you are connected to an Electron Cash server, not a normal Electrum server. Electron Cash has had numerous issues with this and routinely connects to the wrong servers thus potentially causing you to lose coins.