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.

First of all, please do not hijack months old threads with your own issues. Make your own thread instead.

Your blockchain looks like it is corrupted. If you run just Bitcoin Core, does it sync properly and not give you any errors?

Yes. 34c is the original transaction as considered by every other node so c1c is rejected as a double spend of 34c.

Yes. The blockchain is what determines that a transaction is the "real" one. Once one transaction confirms, then your wallet will automatically update to fit what the blockchain says.

Since you did zapwallettxes, you removed 34c from your wallet before you sent c1c. Thus your wallet saw c1c first and uses that as the "real" transaction and not 34c which is what all other nodes will think is the "real" one. Once one of those transactions confirm, your wallet will automatically update to fit what the blockchain says.

No. Satoshi did not even have the project on Github originally. Gavin took over the project after Satoshi disappeared since he was the most experienced and active contributor at the time. I have found no evidence for Satoshi handing anything over except for Gavin's own statements. There is no indication from Satoshi that there was any plan for a "line of succession".

A precise definition of the consensus rules are necessary. Everyone must be following the exact same consensus rules, with its bugs, intricacies, and undefined behavior, in order to not have any accidental hard forks. The 2013 accidental hard fork is an example of such failure of different consensus implementations. On paper, all nodes were following the same rules. But in implementation, one version of the implementation had a bug which in turn caused an accidental chain fork. If everyone follows precisely the same rules, then this cannot happen. The only way for everyone to follow precisely the same rules is for every node to be share the same consensus implementation.

Addresses are not single use. They can be used many times. If two people send money to the same address at the same time, then everything will work fine and nothing bad will happen. Both transactions will arrive.

Since you used zapwallettxes, your transaction made at p.3 is a double spend. The transaction fee for your other transactions is not so low that they are rejected from many nodes' mempools. Because of that, your p.3 transaction is rejected by nearly all nodes since it is considered a double spend. Thus that transaction did not propagate well so you won't find it on block explorers.

Your Bitcoin is safe. Bitcoin does not just "disappear". It will either go to who you sent it to (i.e. the transaction will confirm) or it will not and you can spend it again (i.e. the transactions are dropped from the network after a while).

Your forum account? If that is the case, then you are just doing everything wrong. All of those campaigns are not affiliated with Bitcointalk in any way whatsoever. If you are not telling the operators of those campaigns that you have performed the task and that they should pay you, then you are not going to be paid. Furthermore, you will need to give them a Bitcoin address since the forum has no functionality to pay accounts. The issue is between you and the campaign managers. Contact them for help.