No decent wallet will only give you one static address. It is both less secure and less private to only be using one address. Wallets should always be giving you a new address every time you click on "Receive". However, that does not mean that old addresses are suddenly unusable. Addresses which you have previously given out, received at, and sent from will still work for all of those things. You can still give it to other people and receive Bitcoin there. You can still use it to sign messages and send Bitcoin if it has any to spend. Your wallet still tracks transactions to and from that address so you can use it multiple times, it just is not recommended to do that, although many people still do.

You should however stop using Blockchain.info's wallet. They frequently have bugs and do not provide enough control to the user for you to actually be in control of your Bitcoin. You should use any wallet that is listed on https://bitcoin.org/en/choose-your-wallet

Rescanning should only take at most a few hours, usually somewhere in the tens of minutes I think. Rescanning is not the same as redownloading or reindexing.

As much as possible from the bottom. Preferably including the entries around the time of when you sent the transaction in question.

Copy and paste the output to a text editor and use the search function there.

The testnet is for development and testing only and coins there have absolutely no value whatsoever.

You want to use the mainnet. Make sure that when you run Bitcoin Core and Armory that you do not have the -testnet option set anywhere in their startup commands. Make sure that you are using the normal Bitcoin Core shortcut, not the testnet shortcut. The normal shortcut has an orange icon, the testnet one is green.

You are using testnet. Are you trying to do that or are you trying to use the main Bitcoin network?

No, you are wrong. Entropy is used in every single operation that involves generating random numbers, and that includes private keys.

Private keys are 256 bit integers, not just a 52 character string in base58. The private key must fall within a certain range and actually using a random number generator and key generating software ensures that the private key is valid.

You don't need to run that command now, just right click the transaction in question and choose the "Abandon transaction" option.

Yes. You may need to start Bitcoin Core with -upgradewallet however in order to make sure that everything works.

---

P.S. I split your question into its own thread. Please do not hijack someone else's thread with your own questions and issues even if you think the problem is the same.

Try running a rescan. Start Bitcoin Core with the -rescan option. This will rescan the entire blockchain for all transactions related to your wallet.

Can both of you also please post your debug.log file?

Please post the dbLog.txt file which can be found in the Armory data folder.

BU, Segwit, Classic, and XT are all over the news and even hit mainstream media. It has been nearly what everyone has talked about for months, practically years. Just take a look at the first page of Bitcoin Discussion and of both subreddits; BU and segwit (and previously Classic and XT) comprise a significant portion of what people are talking about. And yet a significant number of people still don't know what they are and ask questions about them, just like the OP of this thread. The current situation is comparable to said hypothetical hard fork and yet many people are still asking questions about the proposals and confused about what they are and what they do.

You have in no way addressed my counter points to your "solutions" to my objections.

Bitcoin has quite a large userbase, and I'm pretty sure that a significant portion of the community would not really be aware of a hard fork (just like a significant portion of the community doesn't really seem to be aware of BU or segwit or know anything about them). Furthermore, there is an issue of transaction replay, what the new coins are listed as in exchanges, and what they are calling themselves. If both forks are calling themselves "Bitcoin" or some variation of that (e.g. "Bitcoin Original" or something), then that can be confusing. It is also especially confusing for new users who just started using Bitcoin or are about to start using Bitcoin when the fork happens as they don't know enough about what is going on to make an informed decision. Unless a hard fork actually gains consensus (i.e. practically everyone in the community agrees with it), I think there will be confusion when a hard fork happens.

A hard forks require not just a majority but practically everyone involved. That means it must have nearly all miners and nearly all users. Just a "clear majority" (e.g. 75%) is not enough as the remaining can still keep the original chain going, albeit rather slowly for a few weeks. Even if all of the current hash power forked away, users who did not go along with the fork can also keep the original chain going by using older mining hardware which had been previously retired.

Segwit also offers an already coded, tested, and reviewed (flextrans has not had the same level of testing and review. IIRC the current implementation has many vulnerabilities in it as well) solution to quadratic sighashing. However, changing to flextrans is a lot more work than changing to segwit. It completely rewrites the entire transaction format. Doing a complete rewrite of that in every single wallet software will take a lot of time, and there are a lot of things that can be messed up in rewriting that. As someone who has partially implemented segwit for a wallet, segwit is really not that bad to implement as it is an extension on the existing transaction format.

Limiting the transaction size is not really a solution. It also prevents people from making those large transactions which can, at times, actually be useful. For example they can be used to clean up a large amount of spam UTXOs but cost less than multiple transactions. F2pool did this with the large 1 MB transaction they made when they cleaned up a lot of small, spam UTXOs from broken brainwallets.

As I said, the concern is not just on disk space but also bandwidth.

Do you also realize that people aren't going to be buying new hard drives every year just to store the blockchain? Maintaining a growth of 1.68 TB a year would be quite burdensome on node owners as they would constantly have to get new hard drives and have the bandwidth to allow that much data to and from their node to multiple peers while still also having disk space for their personal data and bandwidth for personal use.

Altcoins don't have the same number of users, network conditions, market cap, or development situation as Bitcoin does. Bitcoin and altcoins are not comparable.

It is not an issue of "kicked off the main chain" but rather that a short-term, abrupt hard fork would almost certainly result in two chains and a lot of uncertainty about which is Bitcoin.

The address you won't recognize is called a change address. You won't be able to actually see what your change addresses are as they are handled internally by the wallet and typically never shown to the user. Just because you don't recognize it does not mean that you don't control the address.

To make sure that the address is yours, go to Help > Debug Window and click on the console tab. Then type
where <address> is the address in question. Then hit enter.

In the output, look for the field "ismine". If that is true (will look like "ismine": true,), then the address is yours and is controlled by your wallet.

Double check that your balance is actually what you expect it to be. The transactions list should say that you are sending 3 BTC, not 3.2.

0.95.1 has issues with starting it's own bitcoind (Bitcoin Core). You will need to start Bitcoin Core manually.

In Armory, go to File > Settings and uncheck "Let Armory run Bitcoin Core in the background for me". Then stop Armory, start Bitcoin Core, let Core sync, and then start Armory.

Bitcoin Core version 0.14.1 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.14.1/

This is a new minor version release, including various bugfixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

To receive security and update notifications, please subscribe to:

https://bitcoincore.org/en/list/announcements/join/

Compatibility

Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable changes
RPC changes

• The first positional argument of createrawtransaction was renamed from   transactions to inputs.
  
• The argument of disconnectnode was renamed from node to address.
  

These interface changes break compatibility with 0.14.0, when the named arguments functionality, introduced in 0.14.0, is used. Client software using these calls with named arguments needs to be updated.

Mining

In previous versions, getblocktemplate required segwit support from downstream clients/miners once the feature activated on the network. In this version, it now supports non-segwit clients even after activation, by removing all segwit transactions from the returned block template. This allows non-segwit miners to continue functioning correctly even after segwit has activated.

Due to the limitations in previous versions, getblocktemplate also recommended non-segwit clients to not signal for the segwit version-bit. Since this is no longer an issue, getblocktemplate now always recommends signalling segwit for all miners. This is safe because ability to enforce the rule is the only required criteria for safe activation, not actually producing segwit-enabled blocks.

UTXO memory accounting

Memory usage for the UTXO cache is being calculated more accurately, so that the configured limit (-dbcache) will be respected when memory usage peaks during cache flushes.  The memory accounting in prior releases is estimated to only account for half the actual peak utilization.

The default -dbcache has also been changed in this release to 450MiB.  Users who currently set -dbcache to a high value (e.g. to keep the UTXO more fully cached in memory) should consider increasing this setting in order to achieve the same cache performance as prior releases.  Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter.

Additional information relating to running on low-memory systems can be found here: reducing-bitcoind-memory-usage.md.

0.14.1 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

RPC and other APIs

• #10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
  
• #10139 f15268d Remove auth cookie on shutdown (practicalswift)
  
• #10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
  
• #10144 d947afc Prioritisetransaction wasn't always updating ancestor fee (sdaftuar)
  
• #10204 3c79602 Rename disconnectnode argument (jnewbery)
  

Block and transaction handling

• #10126 0b5e162 Compensate for memory peak at flush time (sipa)
  
• #9912 fc3d7db Optimize GetWitnessHash() for non-segwit transactions (sdaftuar)
  
• #10133 ab864d3 Clean up calculations of pcoinsTip memory usage (morcos)
  

P2P protocol and network code

• #9953/#10013 d2548a4 Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt)
  
• #10176 30fa231 net: gracefully handle NodeId wrapping (theuni)
  

Build system

• #9973 e9611d1 depends: fix zlib build on osx (theuni)
  

GUI

• #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)
  

Mining

• #9955/#10006 569596c Don't require segwit in getblocktemplate for segwit signalling or mining (sdaftuar)
  
• #9959/#10127 b5c3440 Prevent slowdown in CreateNewBlock on large mempools (sdaftuar)
  

Tests and QA

• #10157 55f641c Fix the mempool_packages.py test (sdaftuar)
  

Miscellaneous

• #10037 4d8e660 Trivial: Fix typo in help getrawtransaction RPC (keystrike)
  
• #10120 e4c9a90 util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj)
  
• #10130 ecc5232 bitcoin-tx input verification (awemany, jnewbery)
  

Credits

Thanks to everyone who directly contributed to this release:

• Alex Morcos
  
• Andrew Chow
  
• Awemany
  
• Cory Fields
  
• Gregory Maxwell
  
• James Evans
  
• John Newbery
  
• MarcoFalke
  
• Matt Corallo
  
• Pieter Wuille
  
• practicalswift
  
• rawodb
  
• Suhas Daftuar
  
• Wladimir J. van der Laan
  

As well as everyone that helped translating on Transifex.

There are multiple problems with a block size increase in general, regardless of how big you make it. While 4 or 8 MB might sound reasonable to you, it in fact is not really that sustainable when you consider everything else that can result from having larger blocks.

An important thing to keep in mind when designing large robust systems is that you must always assume that the worst case scenario can and will happen.

Firstly, there is the problem with quadratic sighashing. Increasing the block size to 4 MB means that we would be allowing a theoretical 4 MB transaction which, due to its size, can take a long time to validate. A block was mined a while back that took ~30 seconds to validate since it was just one gigantic 1 MB transaction. Due to quadratic sighashing, a similar 4 MB transaction in a 4 MB block would take 480 seconds to validate since sighashing is quadratic.

Secondly, increasing the block size in general increases the burden on full nodes in terms of bandwidth and disk space. Right now the blockchain is already fairly large and growing at a fairly fast pace. It gains ~1 GB every week or so. Considering the worst case scenario, that would mean that the blockchain would grow at a rate of 4 GB per week. That growth is quite large and hard to sustain. Full nodes need to download that amount of data per week and upload it to multiple peers. That consumes a lot of bandwidth and people will likely stop running full nodes due to the extra cost of that bandwidth. Furthermore, it will become more and more difficult to bring new nodes online since it consumes so much bandwidth and disk space so it is unlikely that people will be starting up new full nodes. Overall, this extra cost is a centralizing pressure and will result in fewer full nodes and an increased burden on those who are currently running full nodes. And larger blocks don't just effect the bandwidth and disk space, they also require more processing power and memory to fully process, so that raises the minimum machine requirements as well.

There was a paper published a year or so ago which analyzed the ability of the network to support certain sized blocks, and I think they concluded that based upon network bandwidth alone, the network might have been able to support 4 MB blocks and still keep most of the full nodes. However they did not consider machine specs and requirements for larger blocks so if you factor those in, the maximum handleable block size is likely smaller.

Lastly, such a change would require a hard fork. Hard forks are hard to coordinate and to get everyone on board and upgrade at the same time. By this time, 2 block size increase hard forks have been attempted, and both have failed. With all of the politics, contention, and toxicity going on right now, I highly doubt that we would be able to get the consensus required to activate such a hard fork. Additionally, planning out, implementing, and testing a safe fork (regardless of hard or soft) takes a long time, so such a fork would not be ready for months, if not a year or more.

All soft forks were done through the BIP process. Take a look through the BIP list: https://github.com/bitcoin/bips/blob/master/README.mediawiki. Anything that has "Consensus (soft fork)" for Layer and "Final" for status is a soft fork which has already activated.

When BIP 16 activated, it created a new standard output type of the form OP_HASH160 [20-byte-hash-value] OP_EQUAL. Any output of that form is considered a P2SH output. Any P2SH output will always have the last item in the stack after the scriptsig eval (i.e. after the redeemscript was pushed to the stack) evaluated as a script even if it is not a script.

He did not just "exploited this uncertainty to pervert the meaning just for lulz". If you have read any of what Luke-Jr has said about block sizes and capacity, he genuinely believes that the block size is currently too large because it is difficult to start running a new full node. It is also becoming unsustainable to continue to run a full node since it costs so much in bandwidth, processing power, RAM, and disk space. It wasn't proposed "just for lulz" or to troll anyone but rather because Luke-Jr genuinely thinks that decreasing the block size would help Bitcoin by allowing more people to run full nodes.

It does not give both sides what they want. Many who support segwit clearly don't support the proposal. A lot of that is because they think that having a 2 MB base block size is too large (that means that witness block sizes can go up to 8 MB). Furthermore, that still allows a 2 MB legacy transaction which takes a long time to validate due to the quadratic sighashing issue. Additionally, since it is a hard fork, there are a number of other things that should be included into it as we don't want to have multiple hard forks but rather one with everything that we want that needs hard forking. Segwit2MB does not address that.

Yes, that one. It does more than that as it actually grows on a fixed schedule.

No. The Core devs at that meeting did not represent Core. As I understand it, they made it very clear at the meeting that they only represent themselves as contributors, not representatives of the project itself.  Furthermore the only statement binding them to do something hard fork related is
Notice how it does not say that the Bitcoin Core project will adopt said proposal, only that the contributors present will make such a proposal which they can recommend to Core.

His proposal is not in conformity with the agreement. It came way past the deadline (luke-jr's came before the 3 month deadline), he was not at the meeting so his proposal does not count, and his proposal is not recommended by the Bitcoin Core contributors present at the meeting.

Anyways, the Hong Kong agreement is really not in effect and not binding anyways so this is pointless to argue. Technically all parties upheld their parts of the agreement due to the vagueness and loose wording of it.

The transaction fee is dependent on the size in bytes of the transaction, not the actual amount being transacted. We need to know what the transaction ID of your transaction is to actually know what is wrong with it.