Topic: How does bitcoin prevent theft via rebroadcast? (Read 196 times)

You can Use a VPN for Your Transactions: When trading cryptocurrency, make sure to use a virtual private network, or VPN. These networks scramble your data so hackers, even if they access it, can't read it. That you wanted to confirm those transactions that were unconfirmed via rebroadcast you can It looks like your transaction finally went through. I've had a transaction take longer than 24 hours due to not including a large enough miner's fee.

A transaction to transfer bitcoins includes a set of inputs and outputs, with its unique hash value. However, the owners of transferred bitcoins can only sign on the transaction to provide integrity for its content without guarantee for its output script. This is considered as transaction malleability in Bitcoin system, which allows an attacker to intercept, modify, and rebroadcast a transaction into the Bitcoin network. This attack deceives the transaction issuer into believing that the original transaction failed to be recorded in blockchain. The vulnerability has been utilized by attackers leading a bankruptcy of the largest Bitcoin exchange at that time. To avoid this situation happens again, to present an efficient strategy to secure user wallet. If you use the scheme that confirms success of a transaction not only relying on its unique hash value, but also relying on the address balance it spends. This strategy doesn't add too much complexity and is easy to implement in existing wallets. It is resistant to transaction malleability and helps Bitcoin users to protect their property from malicious entities. This precautionary measures would also prevent bitcoin theft via rebroadcast

It seems u got ur assurance already, however here r some useful links ...
1-Double spending attack, and how it's avoided by waiting 6 blocks
(A consensus problem that comes from the time the minted block takes to get approved (confirmed, observe the increment in any block no. of confirmation with time here https://blockstream.info/testnet/block/00000000000000167572bba29bdcec2cbb0e6926b61d33233b927d44fb75cc33) by different nodes thru the network (what if someone tries to re-spend the same money in a different block that get confirmed simultaneously by a different set of nodes? a similar problem to X&Y going to different bank branches to simultaneously withdraw all the money they have in their joint account, or X withdrawing from the bank & giving his ATM card to Y to simultaneously withdraw from the ATM m/c)
Watch here from min 25
https://youtu.be/q5GWwTgRIT4

.
2-Replay Attack & MEV Miner Extracted Value
From the paper
 "Quantifying Blockchain Extractable Value:
How dark is the Forest" Jan2021
https://arxiv.org/abs/2101.05511
A problem that probably happens in DEXs when a malicious miner tries to replay ur Transaction before or after you to get benefit from the currency change of balance in the AMM Automated Market Makers.
.
I have a problem posting images here from my chrome mobile browser, So u may view them in the following  tweet
https://mobile.twitter.com/ArafatShymaa/status/1389324968677322755

And even then, the answer to the OP question: "what prevents that signed transaction from being rebroadcast later" is...

The blockchain.  Once the transaction is confirmed in the blockchain with sufficient confirmations, you cannot change the fee, the inputs, the outputs, or anything about the transaction with or without RBF.

It's in the protocol but you'll have a hard time finding a wallet that lets you double spend by arbitrarily changing the outputs (a feature of RBF). The closest they do is simply change the transaction fee while keeping the same inputs and outputs, or change the outputs to be ones that'll go to one of your other addresses.

For others that see this thread and don't fully understand what achow101 means when he says:
"Bitcoin operates on a UTXO model, not an accounts model".

Here are some details to understand.

#1. There are no addresses in the blockchain.  Addresses are an abstraction that we humans use to make it easier to talk about the transfer of control over value.  When we put an address into the "send to" part of a user interface, that software uses information embedded within that address to create a standard set of instructions.  That set of instructions is what is actually stored in the blockchain.  Then when other bitcoin software sees the standard set of instructions, it translates those instructions back into an address with embedded information to show to us humans.

#2.  The instructions don't say "transfer this amount to..." or "this identifier has this balance" or anything like that.  Instead a transaction has two sections.  The first section (commonly called the INPUTs) says "here is some value that I can prove I have control over, I am providing proof that I have control over this value and as such ALL of this value is now under the control of this transaction".  The second section (commonly called the OUTPUTs) says "of the value under the control of this transaction, this amount is to be put under the control of whomever can provide a digital signature associated with a public key that hashes to the following value".

#3.  When I want to supply value to a transaction that I'm creating, I MUST provide a list of OUTPUTS that have NEVER before been used as INPUTS. I must also provide a digital signature for each of those listed OUTPUTS proving that I'm the whomever that is authorized to spend them.  Once I list those as INPUTS, they can NEVER again be used as INPUTS to another transaction.

So, lets imagine that I've received 10 BTC.  Those were sent to me in 3 separate transactions (one for 1 BTC, one for 2 BTC and one for 7 BTC). Each of those are a separate OUTPUT that I have control over and can spend.  My wallet software recognizes the scripts and tells me that I have 10BTC, but internally it knows that what I ACTUALLY have is 3 OUTPUTS valued at 1, 2, and 7 BTC respectively.

Now, I want to send 2.5 BTC to someone.  My wallet software might choose to spend the 1 BTC output and the 2 BTC output as INPUTS to this transaction (providing 3 BTC of value to the transaction).  It will provide the necessary signatures for those two INPUTS. Then it will create an OUTPUT that says that (of the 3 BTC of value provided to the transaction) 2.5 BTC are to be put under the control of whoever can provide the signature associated with the public key that hashes to the value embedded in the address that I'm "sending to".

That still leaves 0.5 BTC of value associated with the transaction.  If I want that 0.5 BTC to be back under MY control, then my wallet software needs to create ANOTHER new OUTPUT with instructions that puts that 0.5 BTC under control of whoever can provide the signature associated with the public key that hashes to a value embedded in one of MY bitcoin addresses (either the same address that the 1 BTC and 2 BTC were originally sent to, or some other address that my wallet software knows it has the keys to). This additional OUTPUT that puts the excess into a new OUTPUT still under my control is often called a "change output" or "transaction change" since it is analogous to the "change" that you get back from a cashier when you give them more money than needed to pay for whatever you are buying.

Note that ANY value that is left over (SPENT in the INPUTS and not accounted for in the OUTPUTS) is what is commonly called a "transaction fee".  This is the value that the miners (or mining pools) get to reward to themselves when they've included the transaction in a block that they've successfully "mined". So, if you wanted to pay a 0.01 BTC transaction fee in that transaction we just discussed, then instead of assigning 0.5 BTC to yourself in the "change output", you would just assign 0.49 BTC.  The remaining 0.01 BTCC would be left for the miners to claim for themselves when they confirm your transaction into a block.

If you try to re-broadcast my transaction, every node on the network will recognize that the specific 1BTC and 2BTC outputs that the transaction is attempting to use as INPUTS are no longer available (they've already been spent). Therefore, the rebroadcast transaction is not valid as a new transaction.  If the original transaction is not yet confirmed, then the nodes will see that the transaction which spends those inputs is ALREADY in their mempool, so they won't bother to add it to the mempool again.

Bitcoin operates on a UTXO model, not an accounts model. A transaction does not deduct some amount from an account balance; there are no accounts in Bitcoin.

Rather how Bitcoin works is that transactions create transaction outputs, and other transactions spend existing transaction outputs. Transaction outputs specify an amount and the conditions that a future transaction must meet in order for the output to be spent. There is a set of standard conditions that can be encoded as addresses. Once a transaction output is spent, it is gone and cannot be spent again. Only the Unspent Transaction Outputs (UTXOs) can be spent in a new transaction. Rebroadcasting the same transaction does not do anything because nodes will either consider the UTXOs spent, or say they have already seen this transaction and have already updated their state to accomodate it, so the rebroadcast does not do anything.

Confirmed transactions (on the accepted chain) are immutable and cannot be changed or duplicated. The inputs from the first transaction are already spent to balance on X, a rebroadcast attempting to send the same inputs to the same address is not possible.
Also, someone without the private keys cannot send coins from a wallet.

In this situation, I assume the signed transaction has already been broadcast and visible on the network.
Rebroadcasting a transaction does not change the details (inputs, outputs or public addresses) and cannot facilitate theft, if you rebroadcast a transaction it's simply being run by the nodes again, in cases where it may have been dropped from the mempool.

Double spending is one feature which can be used to change details of a transaction before confirmation

Please forgive the newbie question: if address X has a balance of 10 BTC and the holder of that private key signs a transaction that sends 1 BTC from X to Y, what prevents that signed transaction from being rebroadcast later and another 1 BTC transferred to Y?

Thanks.