True that unconfirmed transactions are highly risky in crypto trading. Recently I read an article about a dust attack through bitcoin funding. It’s actually a great post that helps to get an idea on how to avoid such unconfirmed transactions.
This discussion thread is totally different from dust attack discussion. This thread is about replace-by-fee and child-pay-for-parent transactions which can be used to unstuck unconfirmed transactions, also addressing the issue of enabling replace-by-fee while making transaction to be able to pump the fee during any stuck transactions. Dust attack transactions can be confirmed, and which is very important for the receiver to use coin control to freeze the dust coins, or using a mixer or CoinJoin wallet like Wasabi to avoid the negative effect of such dust transaction so that the attacker will not be able to trace the next transactions to you after been mixed or coinjoined. 
Topic: How to cancel Bitcoin transaction? (Read 551 times)
True that unconfirmed transactions are highly risky in crypto trading. Recently I read an article about a dust attack through bitcoin funding. It’s actually a great post that helps to get an idea on how to avoid such unconfirmed transactions.
Although you will save on disk space, you will not save bandwidth if you run a pruned node. They use the same bandwidth as a full node.
Most of the people I know in western countries already have unlimited bandwidth for downloading and uploading so I really don't think that should be a problem, except if you live in some restrictive region or country with bad internet connection.
How about if you run Pruned Bitcoin node?
They perform almost exactly like a full node, you don't need to have complete copy of the blockchain stored on your hard drive and I believe you can also verify Bitcoin transactions.
You are right, a pruned node can relay blocks and transactions to other nodes, In this regard, a prune node can also still verify blocks and transactions. It is just an exeption, but pruned node is not entirely different from full node, as it is the continuation of a full blockchain (which means prunned node begins from previous full blockchain, and continue as a prunned node) which makes it just act like a full node in blocks and transactions validation.They perform almost exactly like a full node, you don't need to have complete copy of the blockchain stored on your hard drive and I believe you can also verify Bitcoin transactions.
I agree.
As far as I know, a pruned node validate/verify all transactions since the genesis block, but they do not keep the records of the full blockchain like a full node.
Quote
The pruned nodes, they are a type of node which performs almost all the functions of a full node. In fact, your only exception is that the pruned nodes do not have a complete copy of the blockchain. That is, the pruned nodes only maintain a substantial part of the blockchain, using it to carry out their verification processes like any other full node.
https://academy.bit2me.com/en/what-is-a-pruned-node/
https://academy.bit2me.com/en/what-is-a-pruned-node/
Although you will save on disk space, you will not save bandwidth if you run a pruned node. They use the same bandwidth as a full node.
How about if you run Pruned Bitcoin node?
They perform almost exactly like a full node, you don't need to have complete copy of the blockchain stored on your hard drive and I believe you can also verify Bitcoin transactions.
You are right, a pruned node can relay blocks and transactions to other nodes, In this regard, a prune node can also still verify blocks and transactions. It is just an exeption, but pruned node is not entirely different from full node, as it is the continuation of a full blockchain (which means prunned node begins from previous full blockchain, and continue as a prunned node) which makes it just act like a full node in blocks and transactions validation. They perform almost exactly like a full node, you don't need to have complete copy of the blockchain stored on your hard drive and I believe you can also verify Bitcoin transactions.
Yes, that is correct.
SPV nodes, which are the nodes which doesn't have the full blockchain, are described in the whitepaper
SPV nodes, which are the nodes which doesn't have the full blockchain, are described in the whitepaper
How about if you run Pruned Bitcoin node?
They perform almost exactly like a full node, you don't need to have complete copy of the blockchain stored on your hard drive and I believe you can also verify Bitcoin transactions.
Does this process involves transactions with much coins.
The amount of bitcoin being sent in the transaction is more or less irrelevant to whether or not it can be replaced.Does it mean once a transaction is made and it is been sent to a wrong address it can be cancelled and resent to the correct wallet.
If the transaction has been flagged as opted in to RBF, and has not yet received any confirmations, then yes, the transaction can be redirected to the correct wallet.Because I have read in someother article that bitcoin sent to another address cannot be recovered or traced to the owner.
Even if a transaction has no confirmations but is not RBF enabled, then double spending those coins to a different address will be very difficulty. Once a transaction has one confirmation, the chances of reversing that transaction are essentially zero unless you operate a significant proportion of the network's hashing power.
I never knew transactions could be cancelled. Does this process involves transactions with much coins. Does it mean once a transaction is made and it is been sent to a wrong address it can be cancelled and resent to the correct wallet. Because I have read in someother article that bitcoin sent to another address cannot be recovered or traced to the owner. I need clearity
SPV nodes, which are the nodes which doesn't have the full blockchain, are described in the whitepaper:
Pool mining nodes as I have explained earlier also do not have the full blockchain. Which means, it is also not a full node. But I don't understand a little about the Cancel (double-spend) feature, will this feature return the bitcoin that we sent (unconfirmed) to the same address or to another address? Honestly, I haven't tried the Cancle (double-spend) feature so far. I need a little explanation on this. However, I do know that this feature can cancel the first transaction for a low fee.
In this case, like on electrum wallet, you can cancel the transaction if replace-by-fee is enabled, it is double spend because the original transaction which is unconfirmed will be diverted into another address entirely, the address will be the address on your wallet. But, I have heard cases that it is possible to also divert the unconfirmed transaction to another address on another wallet. This is why it is good to make sure bitcoin transaction is confirmed before accepting it as a valid transaction. 
So far, the RBF feature has been very helpful for bitcoin users and almost every transaction and I activate this feature to anticipate congestion. But I don't understand a little about the Cancel (double-spend) feature, will this feature return the bitcoin that we sent (unconfirmed) to the same address or to another address? Honestly, I haven't tried the Cancle (double-spend) feature so far. I need a little explanation on this. However, I do know that this feature can cancel the first transaction for a low fee.
CPFP might not work in every case though, even if you're receiving the change. If the minimum mempool fee is below the fee rates for that specific transaction, it'll be evicted from the mempool and thus making it an orphan transaction. It would probably not have very good propagation though in this case, the best course of action is to just resend the transaction and RBF won't be needed either. Two of the three options are not cancelling the transaction.
Well, nodes (full nodes) verify everything. Since the genesis block, they verify block information, headers, each block hash, each transaction and each UTXO and so on.
As you are referring to a full node, you are 100% correct. A full node verify all transactions and blocks. But I don't think a node (I mean a non-full node) verify all transactions inside a block one by one. A non-full node relies on other full nodes instead of verifying all transactions one by one.
Am I right? Someone correct me if I'm wrong please.
Yes, that is correct.
SPV nodes, which are the nodes which doesn't have the full blockchain, are described in the whitepaper:
Quote
8. Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
https://bitcoin.org/bitcoin.pdfIt is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
It is important that full nodes verify all transactions since genesis block. So if a miner insert an invalid transaction all (full) nodes will instantly reject that block and the miner will waste all the processing power he spent.
Well, nodes (full nodes) verify everything. Since the genesis block, they verify block information, headers, each block hash, each transaction and each UTXO and so on.
As you are referring to a full node, you are 100% correct. A full node verify all transactions and blocks. But I don't think a node (I mean a non-full node) verify all transactions inside a block one by one. A non-full node relies on other full nodes instead of verifying all transactions one by one.
Am I right? Someone correct me if I'm wrong please.
Thanks for simplifying it for us I already know that canceling unconfirmed transactions is possible but I can't find any information on how it works. This is the most simple and yet easy-to-understand method I've come across. Especially when my transaction got stuck after I only pay a little number of transaction fees. This should be done to lessen the hassle of long confirmation some other people took some days to confirmed their transactions and with this method, they won't need to wait for that long anymore.
I think it should be like this: Transactions are not confirmed by nodes. They are confirmed by miners. Nodes only verify blocks and transactions.
Well, nodes (full nodes) verify everything. Since the genesis block, they verify block information, headers, each block hash, each transaction and each UTXO and so on.
There is no "only" here. That's my point. They verify everything, as they have a copy of everything that goes into the blockchain.
They cannot confirm transactions, because a transaction is only confirmed when a block is mined. Nodes do not mine blocks, but they verify/validate each one of the transactions that goes inside it and also the ones in the mempool.
Any transaction can be included in a CPFP transaction. It is not like RBF where the transaction must be marked as opted-in before it being made. Any unconfirmed output can be included as an input in a new transaction with or without additional inputs and used to make a CPFP transaction. As you say, it might be that the person who made the first transaction cannot make a CPFP since all the outputs from the first transaction are to other people and there is no change output, but that does not mean the transaction itself does not support CPFP.
I get the point now, thanks. Although, there are some situations the sender can not be able to use CPFP due to not having change address in previous transaction, but this should not be considered that not all situation is a transaction not supporting CPFP because CPFP can still be used by the receiver so far he can spend unconfirmed transaction. You are absolutely correct. About child-pays-for -parent (CPFP), bitcoin users needs to really know the reason why a transaction can support CPFP, because not all transactions can support CPFP.
Any transaction can be included in a CPFP transaction. It is not like RBF where the transaction must be marked as opted-in before it being made. Any unconfirmed output can be included as an input in a new transaction with or without additional inputs and used to make a CPFP transaction. As you say, it might be that the person who made the first transaction cannot make a CPFP since all the outputs from the first transaction are to other people and there is no change output, but that does not mean the transaction itself does not support CPFP.CPFP also doesn't fit in the topic of "cancelling" a transaction. Only RBF allows you to change the outputs of an unconfirmed transaction and reroute the coins back to yourself. CPFP only allows you to speed up an unconfirmed transaction.
<...>
I think it should be like this: Transactions are not confirmed by nodes. They are confirmed by miners. Nodes only verify blocks and transactions.Transactions are not confirmed by nodes. They are confirmed by miners. Nodes only verify blocks.
Nodes not only verify blocks, they also verify/validate transactions that go into the mempool and at every block.
Transactions are validated by all nodes. The network more decentralized than it looks like at first.
Antonopoulos describes more about bitcoin nodes in Chapter 8 of Mastering Bitcoin.Transactions are validated by all nodes. The network more decentralized than it looks like at first.
Miners can have their own full nodes or just SPV nodes/ lightweight nodes and they have to rely on the pools they are participate in to mine bitcoin for data of the full blockchain.
More information about RBF can be found on Bitcoin Core website
Electrum wallet has a document for Replace-by-FeeMy transaction has been unconfirmed for a long time. What can I do?
If you have made a transaction that is unconfirmed, you can:
If you have made a transaction that is unconfirmed, you can:
- Wait for a long time. Eventually, your transaction will either be confirmed or cancelled. This might take several days.
- Increase the transaction fee. This is only possible for “replaceable” transactions. To create this type of transaction, you must have checked “Replaceable” on the send tab before sending the transaction. If you’re not seeing the “Replaceable” option on the send tab go to Tools menu > Preferences > Fees tab and set “Propose Replace-By-Fee” to “Always”. Transactions that are replaceable have the word “Replaceable” in the date column on the history tab. To increase the fee of a replaceable transaction right click on its entry on the history tab and choose “Increase Fee”. Set an appropriate fee and click on “OK”. A window will popup with the unsigned transaction. Click on “Sign” and then “Broadcast”.
- Create a “Child Pays for Parent” transaction. A CPFP is a new transaction that pays a high fee in order to compensate for the small fee of its parent transaction. It can be done by the recipient of the funds, or by the sender, if the transaction has a change output. To create a CPFP transaction right click on the unconfirmed transaction on the history tab and choose “Child pays for parent”. Set an appropriate fee and click on “OK”. A window will popup with the unsigned transaction. Click on “Sign” and then “Broadcast”.
I guess you are not getting something as well... he said that nodes do not verify transactions and only miners verify them. That's not correct. Then I explained that full node verify transactions, and they are not miners.
I didn't say nodes don't verify transactions. I said that nodes don't confirm transactions. I didn't say only miners verify transactions. I said that only miners confirm transactions.
"Verify" is different from "confirm".
Jump to: