What is "amount" and "balance"?

[9thsky]

So when you send coins to your Electrum wallet, in the history tab there is Date, Description, Amount, Balance.

Could someone explain what exactly unconfirmed and subsequently 1 confirmation means, and if there are any actions you (the receiver) has to do?

Also what does the "amount" and "balance" numbers represent because they don't seem to be the btc nor fiat amount that was sent.

Thanks in advance!

[1714097754]

1714097754

[1714097754]

1714097754

[1714097754]

1714097754

[1714097754]

1714097754

[1714097754]

1714097754

[ranochigo]

Could someone explain what exactly unconfirmed and subsequently 1 confirmation means, and if there are any actions you (the receiver) has to do?

It's when your transactions are not yet mined by a miner. At this point, the transactions are easily reversed since it hasn't been mined into a block yet and the efforts needed for it to be reversed is relatively little. The more confirmations you have, the more effort the attacker has to put to reverse that transaction. You don't have to do anything, in fact you can also spend unconfirmed transactions.

Also what does the "amount" and "balance" numbers represent because they don't seem to be the btc nor fiat amount that was sent.

The amount is the amount of Bitcoins sent in the transactions to a recipient and the balance is the amount of Bitcoins left in your wallet at that point in time after that transaction. That's weird though, it is represented as such for me at least.

[TryNinja]

Unconfirmed = the transaction hasn't been confirmed on the blockchain yet.
X confirmations = the transaction has X confirmations on the blockchain.
Amount = the incoming/outgoing amount you sent/received in the transaction.
Balance = your wallet balance after that specific transaction, so previous balance - amount.

The receiver just needs to wait for a couple of confirmations. One is probably enough for most people. If you are dealing with a lot of money (a few thousands), probably wait for 2 or 3 if you want to be safe. The more the better, but as soon as its confirmed, the transaction is irreversible.

Watch this video for a simple visualized explanation: https://www.youtube.com/watch?v=adDTkjffN1U

[9thsky]

Could someone explain what exactly unconfirmed and subsequently 1 confirmation means, and if there are any actions you (the receiver) has to do?

It's when your transactions are not yet mined by a miner. At this point, the transactions are easily reversed since it hasn't been mined into a block yet and the efforts needed for it to be reversed is relatively little. The more confirmations you have, the more effort the attacker has to put to reverse that transaction. You don't have to do anything, in fact you can also spend unconfirmed transactions.

How and why would and attacker reverse the transaction. By "reverse" I'm assuming you mean back to the sender.

Also what does the "amount" and "balance" numbers represent because they don't seem to be the btc nor fiat amount that was sent.

The amount is the amount of Bitcoins sent in the transactions to a recipient and the balance is the amount of Bitcoins left in your wallet at that point in time after that transaction. That's weird though, it is represented as such for me at least.

I think it's in mbtc that's why.

Thanks!

Unconfirmed...

Thanks for the info!

[o_e_l_e_o]

How and why would and attacker reverse the transaction. By "reverse" I'm assuming you mean back to the sender.

Why - They have changed their mind and want to effectively cancel the payment, or they are trying to scam by broadcasting the transaction, receive the goods or other payment promised, and then reversing the transaction.

How - If a transaction is flagged as Replace-By-Fee (RBF), then it is as simple as broadcasting a new transaction which spends the same coins but with a higher fee. If the transaction is not flagged as RBF, then it is a more difficult and usually involves either broadcasting different transactions to different miners and hoping it works, or involves controlling 51% of the hashrate (which would be incredibly expensive). There are a couple of other more unusual ways to reverse a transaction, but the bottom line of all of them is if you wait for a handful of confirmations (typically 6 in most recommendations), then they are all effectively impossible.

[BitMaxz]

How and why would and attacker reverse the transaction. By "reverse" I'm assuming you mean back to the sender.

By making double-spend transactions.
However, I never heard someone succeed in reversing a transaction with 1 confirmation but I heard mostly unconfirmed transactions can be easily reverse by using the same input and increasing the fee.

That's why exchanges or any shops online that accept bitcoins is waiting for 3-5 confirmations to make sure the transaction won't reverse back.

Read more about double-spend here https://en.wikipedia.org/wiki/Double-spending

[khaled0111]

Could someone explain what exactly unconfirmed and subsequently 1 confirmation means, and if there are any actions you (the receiver) has to do?

An unconfirmed transaction means that the coins are not really yours yet and the sender can reverse/cancel it.
To mitigate this risk, the receiver can create what's called a CPFP (Child Pays For Parent) transaction which spends the unconfirmed outputs and pays higher fees.
Paying higher fees will incentivize miners to include both transactions in the block they are working on. Think of it like bumping the received transaction fee.

[Russlenat]

It's like an accounting of your transactions.

As you can see in the amount section, when you send bitcoin from your wallet, that will be (-) it will deduct on your balance, and (+) additional if you will receive bitcoin on your electrum address, it's pretty simple to understand if you have a little background in account.

It's important as it's the history of your transactions so you'll not be having a hard time to trace the in and out your bitcoin.

[ranochigo]

An unconfirmed transaction means that the coins are not really yours yet and the sender can reverse/cancel it.
To mitigate this risk, the receiver can create what's called a CPFP (Child Pays For Parent) transaction which spends the unconfirmed outputs and pays higher fees.
Paying higher fees will incentivize miners to include both transactions in the block they are working on. Think of it like bumping the received transaction fee.

I'm really not a fan of this. Yes, it's the only method that works if the sender doesn't want to pay a sufficient fee but it shouldn't fall on the receiver. CPFP does however, result in the transaction fees being way higher than required and introduce unnecessary spam by generating an additional transaction when the network is congested enough. It's possible that a small output could be generated and it would just result in you having to pay additional fees to spend that smaller output in the future.

[pooya87]

An unconfirmed transaction means that the coins are not really yours yet and the sender can reverse/cancel it.
To mitigate this risk, the receiver can create what's called a CPFP (Child Pays For Parent) transaction which spends the unconfirmed outputs and pays higher fees.
Paying higher fees will incentivize miners to include both transactions in the block they are working on. Think of it like bumping the received transaction fee.

I'm really not a fan of this. Yes, it's the only method that works if the sender doesn't want to pay a sufficient fee but it shouldn't fall on the receiver. CPFP does however, result in the transaction fees being way higher than required and introduce unnecessary spam by generating an additional transaction when the network is congested enough. It's possible that a small output could be generated and it would just result in you having to pay additional fees to spend that smaller output in the future.

It is a necessary evil.
Sometimes the receiver has no other option when receiving bitcoin from for example some terrible service that pays very little fee and refuses to be helpful at all. Specially during the long mempool congestion times the receiver can't just leave the tx be unconfirmed and hope for the terrible service to not double spend the output when it drops from its mempool.

[ranochigo]

It is a necessary evil.
Sometimes the receiver has no other option when receiving bitcoin from for example some terrible service that pays very little fee and refuses to be helpful at all. Specially during the long mempool congestion times the receiver can't just leave the tx be unconfirmed and hope for the terrible service to not double spend the output when it drops from its mempool.

I know. I'm saying if there's an alternative, then it really shouldn't be used. There was this one time, I did CPFP (with a pretty hefty fee) and it didn't get confirmed for hours, RBF wasn't my first choice as I went to spend the unconfirmed UTXO already  . I got frustrated and just RBF-ed it and it got confirmed in the next block and the fees were lower than those that I spent in the combined TX. I'm not sure what's the composition of miners that accepts CPFP TXes too.

I would simply just rebroadcast it continually till it confirms but if your service is using a 1sat/vbyte fees, then I think everyone should steer away from them.

[o_e_l_e_o]

I got frustrated and just RBF-ed it and it got confirmed in the next block and the fees were lower than those that I spent in the combined TX.

Using RBF will generally work out cheaper than using CPFP, since with RBF you replace the first transaction and so do not need to pay for it, whereas with CPFP you build on top of the first transaction and end up having to pay for two transactions.

I'm not sure what's the composition of miners that accepts CPFP TXes too.

I am not aware of any miner which does not accept CPFP. It's not like these transactions have to be specifically flagged like RBF transactions do, and they are also not replacing anything already in the mempool, so there is no real reason for miners to refuse them.

[pooya87]

I am not aware of any miner which does not accept CPFP. It's not like these transactions have to be specifically flagged like RBF transactions do, and they are also not replacing anything already in the mempool, so there is no real reason for miners to refuse them.

I don't think there are any mining pools that don't have CPFP accepting capabilities but it is not about refusing to accept it but about not having the ability to recognize it as CPFP. The pools usually have custom applications and it has to fetch the parent unconfirmed tx, compute its CPFP fee and see if that is what they want. All of this is additional steps that has to be coded into the software.