Bitcoind shouldn't be crashing. Instead of making bitcoind restart on every crash, it would be better to figure out why it is crashing in the first place.

Can you please post your debug.log file?

One way to keep bitcoind up is to make a cronjob that just starts bitcoind. If it is running, the cronjob will do nothing since you can't have two bitcoinds running from the same datadir. If it is not running, the cronjob will start it.

What are you trying to do?

If you are thinking you can just make your own seed by thinking of 12 "random" words, it won't work. BIP 39 is much more than just a bunch of random words, it is an encoding for a random number. It includes a checksum, so you can't just think if 12 random words and call that a valid BIP 39 mnemonic. It is far better to use a wallet that supports BIP 39 to generate the mnemonic for you since they actually generate the random number first and then encode it as a mnemonic.

You could get rid of it in this hypothetical. It doesn't serve a consensus purpose, but it does help to track who mines a block as miners usually will put some identifying text in the coinbase.

No, that is not ASIC resistance. ASIC resistance means that the PoW algorithm (in this case sha256d) is hard to implement on an ASIC. Merkle root calculations are also SHA256d; the data for calculating a merkle root can just be passed through the same SHA256d hashing chips on an ASIC. The processing that is required to do this is also very minimal and could be done on an FPGA before being sent to the chips to be hashed. I don't think the actual hashing chips themselves are even the ones that change the nonce. IIRC the onboard FPGA processes the header and then sends it to the hashing chips to actually be hashed. That FPGA would just need to process a little bit more to make the merkle root.

We cannot rely on there always being some minimal number of transactions to be included into a block except for the coinbase transaction. While requiring a minimal number of transactions would solve several issues, I don't think that should be done as we need to consider the scenario where few transactions are being made. The network would grind to a halt if for some reason transactions are not being made (could be from Bitcoin falling out of use and becoming an even more niche thing, some layer 2 solution makes onchain transactions few and far between, some vulnerability is discovered that people stop making txs but the blockchain must go on, etc.).

No, that's the nBits field. The nonce is the field that is changed in order to find a valid hash as it is more efficient than changing the other fields.

---

First of all, this would require a hard fork.

Secondly, removing the nonce field won't really help. Miners can just keep changing something in the coinbase transaction which can effectively act as a nonce. In fact, since the coinbase part of a coinbase transaction can include whatever data a miner wants, they could just move the nonce into the coinbase transaction and basically continue as they do now. It would add an additional 13 hashes for each block header hashed so it effectively reduces the network hashrate to 1/13 of the current hashrate. However, that won't suddenly make CPU or GPU mining viable again and it most certainly does not make Bitcoin ASIC resistant. ASIC resistance is in the hashing algorithm itself, not the data that is being hashed.

Since miners can and will essentially move the nonce into the coinbase itself, selfish mining is not effected at all. All of the other transactions in the block would remain the same and only the coinbase transaction would change. That is enough to change the merkle root.

Just an update on this:

The transaction is actually partially signed, but it isn't very obvious that it is with the errors showing up in the output. There isn't actually any issue here except that it looks scarier than before.

What wallet software are you using? Please read https://bitcointalk.org/index.php?topic=1802212.0

It would require people to trust that you are providing them the correct blockchain. If they were to verify the blockchain after downloading it from you, it wouldn't be anymore help than you hosting a node on that server and people just connecting to your node too.

First of all, technology isn't stagnant. Better computing power and storage will come even as the blockchain grows larger. There certainly are ideas for shrinking the blockchain, but they all require a hard fork and research is still being done about that.

Yes. Armory's database has both been significantly shrunk (down to only a few GB at most) and completely redesigned, so the old format is old, unused, and incompatible.

First, post in the right thread (hint: this one isn't it. check the stickies). Also post the Armory log files. You will probably also want to use the 0.96.1 testing build 2 as that has many bug fixes for 0.96.

Transactions were cheaper because there were less transactions. Blocks weren't full so there wasn't any fee pressure and thus you didn't really have to pay any fees. That has nothing to do with inflation or miners.

You are wrong. The purpose of creating Bitcoin was to create a money system which did not rely on a central authority. It was not to create a global currency that had cheap transaction fees.

If you are upgrading from any Armory version earlier than 0.95, you will need to build a new database as the database format changed. To do this, just go to the Armory datadir and delete the folder named "databases". Then start Armory.

You will have to run a modified version of Bitcoin Core which enforces the BIP 148 rules. Those binaries can be found here: https://github.com/UASF/bitcoin/releases/tag/v0.14.1-uasfsegwit0.3

The uacomment can only take effect after bitcoind has been restarted. The bitcoin-cli stop tells bitcoind to stop. The sleep 5 is to wait 5 seconds for bitcoind to actually shut down, and bitcoind is for starting bitcoind again.

However you are not using bitcoind so this won't work for you. Just do the first command, stop Bitcoin Core from the GUI, and launch it again once it is fully shut down.

In Bitcoin Core, go to Help > Debug Window and you will see a field for the User Agent. From there you can see that the User Agent Comment has been set to support BIP 148. Note that this does not mean that you are actually supporting BIP 148 and will enforce its rules. You are merely saying that you will support it before the activation deadline of August 1st.

You don't have to uninstall or remove any of the previous files. Make install will overwrite the old ones with the new ones automatically.

What do you mean by "making upload"?

There isn't such a thing as an Armory "profile". I assume what you are talking about are your Armory wallets.

You can copy the Armory wallet files from one machine to another and use them in another install of Armory. You can get those files by going to Armory's datadir and copying the files with the .wallet extension.

No, that is completely incorrect. Transactions have nothing to do with IP addresses. Blockchain.info is just one node among many thousands. They are not the actual bitcoin blockchain nor are they special in any way whatsoever.

Bitcoin uses a gossip protocol; when someone makes a transaction, they send it to the nodes they are connected to who then send the transaction to other nodes that they are connected, and so on and so forth. The process of receiving a transaction from one node and sending it to the other nodes you are connected to is called relaying. None of that involves IP addresses​ except for opening the connection between two nodes, which is done before any relaying happens and typically stays open after a transaction has been relayed.

What you should be checking is your router, not the firewall on your computer. Since the program opens up the port, you shouldn't need to do any extra configuring on the computer unless you have specifically set up such firewalling rules.

Only TCP is necessary.

The nodes that are connected to blockchain.info is not the definitive list of all nodes. Bitnodes.21.co's list of reachable nodes likewise is also not definitive as their crawler also doesn't necessarily reach all nodes (although it is designed to do that).B

lockchain.info's "relayed by" field is completely irrelevant and useless. They only show the node that is connected to them that first relayed the transaction to them. Even if your node is connected to theirs (and I highly doubt it, they only have a hundred or so nodes connected), you won't necessarily have anything listed for "relayed" if all of the other nodes they are connected to relay the transaction to them before you do.

If Bitcoin Core reports that you have more than any number of incoming connections, then you are accepting incoming connections and are fine. You don't have to be listed on any site like bitnodes in order to be accepting incoming connections.

What do you mean by "no relays"?

You are relaying blocks and transactions to all nodes that you are connected to, regardless of whether the connection is inbound or outbound.

What you probably mean is that you can reach your node, so you are not accepting incoming connections. That, in itself, is not an issue. In order to accept incoming connections, you need to open up port 8333 on any firewalls you have (computer, router, etc.). That is all you need to do.