What version of Bitcoin Core are you using? Can you please post the Armory log files?

Certainly. You can have the hex of the signed transaction in a text file, and once you need to broadcast the transaction, copy and paste the hex of transaction into any transaction broadcaster service.

Kind of. A block must still contain at least one transaction, the coinbase transaction. That transaction is what generates the Bitcoin and, IIRC, every block must have this transaction. It is not a transaction that is in the mempool; it is one created by the miner and added as the first transaction of their block. However, there is nothing stopping a miner from having just the coinbase transaction.

[Miners are the ones who generate Bitcoin. Without mining, we would need some other way to pay out the block subsidy. Currently miners create the coinbase transaction which creates an output but spends no inputs. The Bitcoin created by that transaction goes to whomever the miner wants it to go to, typically himself.

bitcoin-qt is bitcoind but with a GUI. bitcoind does not have a gui and can only be interacted with through the JSON-RPC interface. You can run bitcoin-qt and bitcoind simultaneously but you will need to point each one to a different data directory (and thus it will download the blockchain for each datadir and have different wallets). They cannot share the same datadir.

It is a matter of policy, but choosing transactions does actually affect the block hash itself. The block header contains a field called the Merkle root. That Merkle root is the hash of all of the transactions in the block. One way that miners change the block header in order to try another hash is to change the transactions selected or just change the order of transactions so that they get another Merkle root.

Sure, but what is that "automated way"? Transaction selection is automated; it's not like some guy is sitting at a computer and manually choosing what transactions he wants to mine next. Transaction selection is typically done by choosing the transactions from the miner's node's pool of unconfirmed transactions (aka the mempool) that pay the highest fee rate. In the case of two conflicting transactions, the mempool will only accept the transaction that it heard of first, but that may not necessarily be the transaction that was actually sent first. The network is also asynchronous so we need mining in order to have everyone know what the blockchain is and what transactions are considered final and settled.

You can create timelocked transactions that cannot be confirmed until after a certain date or block height. However, since the transaction will be unconfirmed, you will need to keep the transaction somewhere and have a server broadcast it at the appropriate times. You could also give the transaction to your nieces and nephews (or their parents) now so that they can broadcast it in the future to receive the Bitcoin.

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1901984.0

Duplicate topic

Bitcoin transactions work by creating outputs and spending the outputs created by a previous transaction. The spending of outputs is called an input in a transaction. You have a transaction which spends some inputs and creates outputs for people that you now don't want to pay. In order to prevent this transaction from ever confirming, you must spend those inputs in a different transaction and get that transaction to confirm. By doing so, you will invalidate the original transaction since you can't spend inputs in two different transactions and have both confirm. That is the only way to guarantee that your Bitcoin actually returns to you.

You can just send the Bitcoin to an address in your wallet. To ensure that you spend the right inputs, you should use the Coin Control option and find and select the inputs that you spent in your original transaction. They are all labeled by the transaction id that created the output you want to spend and the output index (which number output it is). This will ensure that you spend the right inputs.

If you do not attempt to respend the inputs, it is possible that your original transaction will still confirm and the Bitcoin will go to whoever you sent it to.

Both transactions spend from an unconfirmed transaction. Your transactions cannot confirm until the unconfirmed transactions that they spend from also confirm. Your first transaction spends from https://blockchain.info/tx/4bf2eeb61a6fd30312bae53892e5e16d5d7ed682db4146450b0c77bc228236a0. The second one spends from https://blockchain.info/tx/ddee10955b973bf2b9c4a33a7d3963dd310b8130403a66d6c7fdf1394c3d1cd0. Both of those transactions have low fees so it may take a while for those to confirm.

You will gain trust by interacting with other forum members who will give you positive feedback if they think that you are trustworthy. If you are the person in a trade that is in a position where the other party must trust you (i.e. you are a seller and the buyer sent first), then IMO it is fine to ask the other person to leave you feedback once the trade is complete.

zapwallettxes is only for Bitcoin Core.

In Armory, go to Help > Clear All Unconfirmed and then restart Armory. This will have Armory forget about your unconfirmed transactions so you can respend the inputs. Once Armory has started again, just make the transaction as you normally would but include a higher fee. You may run into an issue where Bitcoin Core will reject your transaction because it still remembers the original. In that case, you will need to stop Bitcoin Core, find the mempool.dat file, and delete that file. Then start Core and Armory again.

Miners create the blockchain. They add transactions to blocks and then hash the block headers to find one that is less than the target. That is the proof of work.

Miners secure the network by creating the blockchain which in turn is the "authority" which says which transactions are "real". The blockchain is really just a defense against double spending transactions. If two legitimate transactions exist but spend the same inputs and send to different outputs, those two transactions are said to double spend each other. Miners are the ones who choose which of those two gets to be included in the blockchain and is thus the "real" transaction. That is how miners secure the network.

Your first question does not make any sense.

If you do not need to modify the behavior of a program, you don't need the source code. The released binaries are enough and you can usually interact with them in some way.

That result is a false positive. Antivirus software will frequently flag bitcoin-qt and bitcoind as viruses. If you have verified that the binaries that you downloaded are legitimate, then there is no problem here.

Antivirus software flag bitcoin-qt and bitcoind as coin stealers and mining viruses because they look for a wallet.dat file (since that is the file it uses for the wallet) and they have mining code (for mining testnet and regtest).

Bitcoin Core builds the binaries through the gitian build system which you can read about here: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md and here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md. If you use the same process for an altcoin (assuming that the dependencies and gitian descriptors are correct), then you will get standalone binaries.

The fact that you are getting an HTTP 401 error from connecting to port 8332 means that something (probably bitcoind) is listening on that port and can understand http. Thus bitcoind the issue is likely not related to bitcoind not connecting to the port but rather that you have configured it incorrectly.

You will get a HTTP 401 Unauthorized error if you do not have the "authorization" header or if the username/password in your auth header is incorrect. For the latter case, if you look in the debug.log file for Bitcoin Core, you will see a line like this:
for each attempt at connecting.

Make sure that you are actually sending the username and password correctly and that what you set as username and password is the same thing as you have set in your bitcoin.conf file.

In order for a standalone binary to work, it needs to be statically linked. Bitcoin Core does this through its depends system which builds all of the dependencies and statically links them to the Bitcoin Core binaries. However most altcoins don't do this because most altcoin devs do not understand all of the intricacies involved in making the Bitcoin Core releases.

Possibly. Let bitcoin core finish syncing first before running armory.

No, all full nodes matter and all full nodes are what define the consensus rules. You cannot have just the miners define what consensus is since they then have the ability to change it at will to fit their own agenda. Full nodes enforce that miners are following the same consensus rules by rejecting invalid blocks. Full nodes matter just as much as mining nodes as they determine what everyone else accepts as valid.

You can't just be compatible with the consensus rules, you must use the exact same rules with its bugs, intricacies, and undefined behavior. If you are just compatible, that means that the implementation is different and should that have a bug or do just one thing slightly differently, can cause a chain fork. The entire goal of consensus is to avoid chain forks.

Having multiple implementations of non-mining nodes is still problematic since a bug in one implementation means that people using that implementation can be forked off of the network either by a malicious entity or just accidentally.