Topic: If initiate sending bitcoin, it can't be reversible? (Read 325 times)

Not 'anyone' can reverse the transaction.
Only the sender can try to perform a double spending attack. You can read more about a double spending here: https://coinsutra.com/bitcoin-double-spending/.




The amount of confirmations represents the possibility for an (powerful) entity (with x% of the total hashrate) to 'replace' this block (simply speaking; technically not correct).
Such an attack is difficult and expensive.

If your transaction partner is not the head of a mining pool and the transaction value is way below the mining reward of 12.5 BTC, yes 1 confirmation is 'safe enough'.

For a layman it is not possible to perform a double spending AFTER 1 confirmation has been aquired.

If Luno wallet stops the process before sending, then it never hits the Blockchain. Accordingly it doesn't show up on any block explorers (assuming that's how Luno does this, I've never heard of this wallet before).

Regardless of that, a con similar to the one you describe is possible, only it involves trying to send the transaction back to your own wallet after receiving the money. This is called a double-spend attack and one of the reasons why Bitcoin has been invented in the first place and why Bitcoin uses a blockchain. It's the reason why exchanges and merchants wait for multiple confirmations until they update your account balance. It's why face-to-face trades usually involve a cup of coffee and a nice chat until the first few confirmations have hit and cash is exchanged


Here's some further reading regarding confirmations and attack types:

https://en.bitcoin.it/wiki/Confirmation

https://en.bitcoin.it/wiki/Irreversible_Transactions#Attack_vectors

I know there is a new australian exchanger that is launching an insurance for this kind of issues, in the next couple of weeks.
I don't remember the name, but i try to find it out and write you back.
It would be an interesting service

So then, following con is possible? Meet victim offline, Send bitcoin, as soon as, show him detail at block explorer with transaction ID (confirm is 0), and then take the real money from victim, then after apart from him, then anyone can reverse (or cancel) that sending?

To block this, at least 1 confirm is needed?

The chances of an orphaned block happening rely mostly on the interval between blocks and the network connectivity between miners and nodes. With Bitcoin the chances of orphaned blocks are rather slim. To find out the probability of an orphaned block in practice you'll probably have to look at the orphaned block rate of the last few years and make an estimate based on those numbers. You'd probably have to check various sources though, because not all nodes are aware of all orphaned blocks.

If a block with a newly confirmed transaction is orphaned, and the transaction is not included in one of the other blocks, it simply remains unconfirmed until it gets included in a block. So basically -- it's been sent, but the confirmation never happened.



Orphaned blocks happen all the time, the last being recorded by blockchain.info on January 2018:
https://blockchain.info/orphaned-blocks

Note that different nodes may see different orphaned blocks. Some orphans you see may not be seen by other nodes and vice versa. The only thing that is kept consistent across nodes is the blockchain -- consistency across nodes being one of the blockchain's main intent.

So how much probability this orphaned block can happen? And if it happen, it does not sent to receiver actually?

I found that orphaned block occured few times in a month at last year (2017-04), but from then to now, no orphaned block occured. Why?

None of that is true.

Please do not try to give advice in the Technical sub-forums if you don't know what you are talking about...


There is no such thins as "the mempool".  Each peer on the network maintains their own list of unconfirmed transactions.  That list is sometimes referred to as the node's mempool, but transactions which are in a "mempool" in one node are not guaranteed to be in a mempool in any other node.


A valid transaction that had net been included in a block by a miner is called an "unconfirmed" transaction, not an "orphaned" transaction. The miners (or mining pools) don't "pick up" transactions from some non-existent "mempool".  They just select transactions from their own personal list of unconfirmed transactions. Until the transaction shows up in a completed block, there is no way to know whether any miners or mining pools have included it in any of the blocks they are working on.


Accelerators are just a way to ask a specific mining pool (or set of mining pools) to consider adding your transaction to the blocks they are working on.  The mining pool may or may not ask you to send them some money to pay for the privilege.

RBF (Replace BY Fee) is used to increase your transaction fees.


Bitcoins are never "returned to the original address".  Until the transaction is confirmed, the bitcoins have never actually left the sender's wallet.  The user interface of the wallet might choose not to display the bitcoins (since the wallet assumes that the transaction will eventually confirm), but there is nowhere to "go back to" since the bitcoins never actually left.  Depending on how the creator of the wallet chooses to handle unconfirmed transactions, the user interface of the wallet might show the bitcoins as available to spend again after some amount of time, but that does not in any way stop the original transaction from being confirmed.  The bitcoins haven't been "sent back".  The user interface has just chosen to ASSUME that the transaction won't confirm.  If it does confirm, the bitcoins will still vanish from the wallet.


If the block that confirms the transaction is orphaned, and the transaction is not in the replacement block, then it will return to unconfirmed status.  If a competing transaction that spends the same inputs is confirmed in the replacement block (or any future block) then the original transaction will become invalid and will vanish.  In this way the original transaction can be effectively "reversed" or "cancelled".

Once u send(broadcast) a bitcoin transaction, the transaction goes to the mempool(which is where all unconfirmed transactions are stored) assuming that the fees were low than its possible that miners will not pick it up(orphaned transaction). In this case you can generally use an accelerator to increase your transaction fees to incentivize a miner to pick it up otherwise to my knowledge the bitcoin should be returned to the original adress after a certain no of blocks(not sure on specifics).

However once a transaction has received even one confirmation it cannot be reversed

What do you even mean by this? That the receiver doesn't know the originating adress of the sender, or the credit card information of the sender  ?


As state by Danny, 6 confirmations for big transactions is the most plausible due to the chances of an attacker trying to reverse the bitcoin blockchain/network almost being nil.

See https://bitcoin.stackexchange.com/a/1882 for a more detailed answer.

I don't see why you should wait 30 minutes, or what the correlation with that is with the amount of confirmations?



This seems like something you should ask on stackoverflow, and is impossible to answer accurately for us/me without knowing more details.

Thanks.

So receiver doesn't know all of senders.

And some sender can send few thousand dollar or even over 100,000$.

So then, at least 2 or 3 confirmations needed? Then wait for at least 30 minutes?

And how to make automatic process when bitcoin daemon receive, it command to webpage refresh (increase sender's bitcoin balance at webpage).

Answer:

There is no amount of time that makes the sentence true.  Sometime the transaction will be in the very next block and that block will be solved in less than one second.  Sometimes a transaction will wait many months or years to be included in a block.

The person sending the transaction can include a transaction fee as an incentive to encourage a solo-miner (or mining pool) to include the transaction in their blocks (since the solo-miner or mining pool gets to decide what to do with the fee).  A voluntary higher transaction fee means an increase in likelihood that the transaction will be included in the next block.


When the user has the technical expertise to know how to do it, or when the user's wallet software chooses to allow them to do so.  There is no protocol rule about this, it is an implementation decision made by the wallet software creator.  The longer the user waits before sending the replacement transaction, the more likely that the replacement transaction will be relayed (if the original transaction is not yet confirmed).  The is because peers will generally not relay the replacement transaction if they still have the original transaction in their mempool (unless the transaction was marked as a RBF transaction when it was created).


When he sees enough confirmations to meets his risk tolerance. Each receiver needs to decide for themselves how many confirmations they need to feel comfortable with any specific transaction.  That will depend on may conditions, such as:

• What is the risk tolerance of the receiver?
• What is the value of the transaction?
• Does the receiver have an existing trust-relationship with the sender?
• Does the receiver have valid identifying information about the sender (name, address, phone, etc)?
• Does the receiver have an alternate method to extract payment from the sender (lawsuit, credit card on file, deposit on hold, etc)?
• Did any popular node software recently release a software update?

Generally (unless the transaction is millions of dollars) 2 or 3 confirmations will be fine. In some cases 1 or 0 confirmations might be acceptable.


6 confirmations is a common choice made by wallet creators.  In my opinion it is more than necessary for most use cases, but might be needed in extreme cases.


When the transaction is in a block in the blockchain.


When 5 more blocks are added to the blockchain after the block that has the transaction.


If what is true?

Thanks.

[if the transaction is not yet confirmed, ] -> how long time it need to wait for make this sentence true?
 
[then it is sometimes possible for the sender to send a new transaction ] -> exactly when that is possible?


All this question boils down to this issue.

From point of view of bitcoin receiver, when he should recognize incoming bitcoin as sure thing?

1. When bitcoin daemon knows? I tested with bitcoin daemon testnet, the balance of receiving bitcoin address recognize its own balance after 6 ~ 8 confirmations.

2. When that transaction earn at least 1 confirmation?

3. When that transaction earn at least 6 or more confirmation? (if this is true, why?)

Huh?


Make up your mind.

Are you asking about "when someone confirm" or are you asking about "waiting for confirm"?

When someone sends bitcoins, the transaction is shared with all the other peers on the network.  It is NOT immediately registered in the blockchain. At that time, it is still waiting for confirm status.

Then, eventually, a miner includes the transaction in a block that they solve.  The miner shares their block with all the peers on the network.  As each peer adds the block to their blockchain, the transaction is seen as having 1 confirmation by that peer.


No.

The transaction remains unconfirmed until it is included in a block in the blockchain.  A new block is added to the block chain on average every 10 minutes, but it can sometimes be much faster (even just a few seconds) or much longer (even more than an hour).  The amount of time between blocks is completely random with the average over many blocks being approximately 10 minutes.

If the transaction is included in the block, then it is confirmed when the block is added to the blockchain.  If the transaction is NOT included in the block, then it must continue to wait.


A few times per week.


No.

When a block is orphaned, the transaction might ALSO be in the new block.  In that case, it is still confirmed.

When a block is orphaned, if the transaction is not in the new block, then it must continue to wait for confirmation.

As long as the transaction is valid, it can still be confirmed.  There is no way to stop a valid transaction from being confirmed.  The bitcoins never "return to the sender".

However, if the transaction is not yet confirmed, then it is sometimes possible for the sender to send a new transaction that spends the same bitcoins.  Since a transaction output can ONLY be spent once, it is not possible for BOTH of the transactions to confirm.  When one of them confirms, then the other will be invalid.

BitcoinTrash's Chain (BCH) will eventually get orphaned once their shilling and pretending has ended, just joking.

If you search via google, you will find some history regarding the split from block #173928 which was 4 blocks long.
The Value Overflow Bug too is an incident worth researching.

Thanks for the clarification, I will take note of that.
But there's a gut feeling that somewhere in the past, things like an attack is not a rare occasion.

---

Off-topic/Piggy-back Question: Could slow miner ISP connection result in orphan blocks?

I wonder if there was a chain longer than 2 blocks that was eventually orphaned in BTC?

Also are there any special blocks - with some weirdness inside ?

No.  Just no.  It is not mostly from attacks, but from blocks being mined nearly simultaneously.

This has a reasonable explanation below, but improvements in Bitcoin Core have improved propagation time etc so frequency has dropped over the years.  There was a discussion about them if I can find the link.
But this is a quick overview:
https://blockchain.info/orphaned-blocks

In addition,
Orphan blocks are mostly a result of a direct attack to the Blockchain or a Faulty miners configurations/hardware.
Those are common during the early years when a Core2Duo/P4 PC can participate in Bitcoin mining. With that cheap hardware, any regular Joe can mine making invalid blocks not-too-uncommon.
Today, most of Bitcoin's miners consist of Huge mining pools or ASIC Farms, doing an attack is not profitable while overseeing a misconfiguration isn't common for a well-planned industrial scale mining.

Yes, but if your wallet has the "rebroadcast" function or if you're re-broadcasting it before it gets flushed out of the mempool, it will still  continue to wait for confirmations.
And as others have mentioned me: the coins weren't sent out of your wallet in the first place.
In other words, the unspent output(s) are simply requested (transaction) to be moved (from the block they're included) as input(s) to a new block and if that request (transaction) didn't get included in a block, they aren't moved at all (still unspent).

Almost true, when someone send bitcoin (by broadcast the transaction to network), all they need to do is wait for confirmation. The transaction is only registered after the transaction is included in block.


Wrong, that depends on :
1. Amount of fees included.
2. Total unconfirmed transaction.
3. Time of each mined block, usually 10 minutes, but sometimes is faster or slow (1 second to 1 hour)


I've no data, but it's rarely happen since block weight and block generation time already set to prevent orphaned block.
Usually happen when a miner mine 2 blocks/more in short time or when more than a miner mine block at same time.


True, it won't be confirmed until other miners include that transaction (Only if other block with same height which accepted as longest PoW/block don't have the transaction). But actually the bitcoin never sent in first place. CMIIW.

As far as I know, when someone confirm send bitcoin, it immediately registered at blockchain, and waiting for confirm status, right?

Then from there, always 100% it will be confirmed after 10 around minutes?

I heard about orphaned block, how often frequently it happens?

And when it happens, that transaction will not be confirmed and bitcoin will return back to sender?