Bitcoin follows a Unspent Transaction Output (utxo) model.
Our modern banking systems follow an account model - you're assigned a bank account number (similar to an address), and send and receive money from it. Any incoming funds increase your total account balance, and any outgoing funds decrease it. The bank does not keep track of which funds came from ...
There are a lot of good answers, but I want to point out the most obvious answer.
Say you have 1 bitcoin and you send 0.2 bitcoin to me and the design leaves it so that you still have 0.8 bitcoin in the same place as the 1 bitcoin you had originally. What stops someone from simply processing that transaction again? You still have the funds.
Designing the ...
And if so, why don't you just send 0.4 BTC in the beginning?
Bitcoin was designed to allow single-in multi-out or multi-in multi-out payments. In Ethereum, only one address fills the whole "to" field of transactions. (This doesn't apply to contracts. Does that mean, in Ethereum, users are 2nd class citizens?)
If you were Satoshi and you were to ...
You generally would not be able to receive a single satoshi.
The Bitcoin Protocol defines something known as a "dust limit".
The exact value of this limit varies based on the receiving address type, but it is defined as the minimum amount of BTC required to spend an input for a given address type.
It is calculated by using a basic 1 input 1 output ...
Any address that a spender will send to is provided by the receiver. As the owner of the address, the receiver knows these details and will be able to provide the correct sending instructions to the spender. This holds true even for the outdated original multisig construction that required the spender to know the pubkeys, but today most multisig transactions ...
Pubkey script alone is not enough to verify a transaction, you'll need:
Pubkey script, to evaluate the scripts
Amount, in order to check if the sum of inputs is bigger than or equal to sum of outputs
Index (in TxOut list) and tx hash of the transaction being spent
Block height so that you can set the consensus rules
After gathering all the above (should be ...
How does the blockchain know that BTC address1 got 3.5 BTC?
It doesn't know anything, it's just a list
Wallets and other software know by looking through the whole list of transactions from the beginning of time† and adding up all the amounts received by address 1 and subtracting all the amounts spent from address 1.
† Bitcoin time effectively started 12 ...
Is that right?
why don't you just send 0.4 BTC in the beginning?
Because you need to consume the last transaction (called "input" of your second transaction, in your example the 1 BTC) entirely (*), or the delta will end up paid in fees.
The amount paid in fees to the miner including your transaction is the amount of the input(s) you unlock,...
In modern times, this problem is solved using P2SH (and later P2WSH). It means the sender only needs to know a hash of the actual script the receiver wants to use, which has its own address format so it's easy to convey.
If your question is how was this done before P2SH: the answer is simply that multisig was not used in practice. Note that P2SH was ...
I was wondering, how is this attribute populated?
The site uses an index that simply remembers this information. If a block B is seen that contains a transaction T, an entry is stored in the database that signifies "transaction T is in block B".
by looking at transaction inside of your UTXO, check in which block transaction was included (and then ...
About the phrasing, there is really no "plan" on Bitcoin as there would be if a centralised authority governed the protocol. Instead, there are proposals and sometimes supermajority consensus for the network to deploy a proposal.
Regarding your question you can already do this today using the locktime features of Bitcoin transaction.
You can either:...
The following transactions are not broadcastable with the default bitcoin core configuration but could be found in new mined blocks:
Transactions whose fee is smaller than 1 sat/vB (and RBF bumps that increment less than 1 sat/B).
Transactions with size greater than 100 vkB (and smaller than ~ 1 vMB)
Transactions with outputs amounts smaller than 566 ...
One major advantage of this Unspent Transaction Output(UTXO) is that it simplifies handling of cheating. Consider the case where I have $20, and then cheat to buy two things for $11 each with the same money. The system has to reconcile this, figuring out who gets paid and who does not. Now amplify this to a scale where I might make a thousand purchases, ...
There are some good answers here, but I'm surprised nobody has mentioned privacy.
Having coins sent to a new change address can improve your privacy in many ways. Consider this simple example: a one-input two-output transaction. Which output is change? If the transaction is carefully constructed, it may be difficult for a third party to tell.
There are more ...
2 confirmations means the transaction was included in a valid block and that block was continued by another valid block.
Option 3, although it should be next block (older than the one that contains the transaction) instead of previous block.
A transaction (that is not a coinbase transaction) will have specified inputs and outputs. The inputs must be comprised of valid, existing UTXOs (referenced by transaction ID and output index number, called the 'outpoint'), which will be 'consumed' to create the outputs (newly created UTXOs).
To spend any UTXO, you need to satisfy the conditions of the ...
First, the common lingo for these "cashback transactions" is "change outputs", and "chain analysis" is a thing whole businesses have sprung up around. There are a few indicators that allow making educated guesses on which outputs may be change, e.g.
round numbers (e.g. three outputs with round amounts and one not)
wallet fingerprinting (e.g. all inputs are ...
When it comes to transactions, I think that a hex representation can explain more unambigiously than words.
That's why my answer uses hex along every step of the signature.
Given your P2PKH transaction with two inputs, here's the raw transaction that has to be signed with the private key corresponding to the first outpoint: