An unspent output is simply an output of a transaction which isn't yet an input of another transaction.
To take the example from ripper234's answer (in which generated coins are immediately spendable, and we don't have to wait 100 blocks for them to mature), where:
The first block contained 50 mined BTC in address A (A = 50)
The second block contained 50 ...
There is no such thing as a transaction "balance". I am going to assume if I jump right to the answer it won't make much sense so the first two sections are to make sure we are how Bitcoin "really works" (at a very high level abstracted view). We need to speak the same language for the answer to make any sense. For this question the two required concepts ...
Bitcoin Core provides the gettxoutsetinfo RPC that has exactly the information you want. Note, it takes that call up to a minute or two to run (and maybe longer as the UTXO set keeps growing).
Here's what my node says right now:
The choice between the UTXO model and the balance model is primarily one between privacy incentives and apparent intuitiveness.
If one follows the standard advice of not reusing addresses/outputs/scripts, as to not gratuitously reveal which coins belong to the sender and which belong to the receiver, the two models are actually equivalent. In this case ...
In order to be sure that an address balance is correct, you need to check that all the transactions on that address are valid. So in order to generate a list of addresses and balances that you trust, you must first download and verify the entire block chain.
Actually, the way Bitcoin works, what you actually need is a list of unspent transaction outputs (...
Every full Bitcoin node maintains a database of which unspent outputs are left.
When verifying a transaction, all its inputs are fetched from the database. If one is missing, validation fails. Among the data retrieved is the value of those unspent outputs, and their script (od address), which define the conditions under which the output can be spent. This ...
It means "Bitcoins that were not spent".
Imagine the early days, when the blockchain was of length 3 (imaginary chain of events):
The first block contained 50 mined BTC in address A
The second block contained 50 mined BTC in address A, a TX sending 20 BTC to address B, and putting the change in address C
The third block contained 50 mined BTC in address A, ...
I assume this question is about Bitcoin Core's internal operations. This description is valid for version 0.8 and later (up to 0.14 at least).
One part of the system deals with the active chain, which is the longest valid chain of blocks (stored in $DATADIR/blocks) that we know of. This active chain gets blocks appended to - and occasionally removed when ...
Very interesting question, let's see what the smallest transaction we can build is. For it to be minimal it has to be a single input and a single output. The non-segwit part would look something like this:
4 bytes version
1 byte input count
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes ...
It's in fact a little more advanced than you imagine it. (So expect this answer to be a bit more in-depth.)
There is no such thing as an accounts "balance". It only exists implicitly.
When people make transactions, they actually create outputs for a certain amount of bitcoins. Using a special script language, the person making the transaction can specify ...
Transaction inputs use Unspent Transaction Outputs (UTXO).
UTXO are created by transactions. They are uniquely identified by the transaction id and the output position in the transaction that created them.
Once UTXO are used as inputs in another transaction, and that transaction is included in a block, nodes that parse the block will mark them as spent.
No, miners do not need the entire block chain to be accessible. Technically, they don't even need it at all. The blocks themself are only needed for rescanning wallets, reorganisations, and serving blocks to other nodes. That is why pruning them away will likely become viable in the future.
What you need for validating blocks and transactions (a fundamental ...
The challenge for picking a Coin Selection Algorithm is that there are multiple goals to optimize for:
The Coin Selection should reveal as little as possible about the user's wallet contents.
One wants to minimize the current transaction fee, but also the overall longterm transaction fees.
Non-dust change creation
It would be ...
Redis and LevelDB solve very different problems. We tried using SQLite and its performance was abysmal.
Bitcoin Core needs a database to store the set of unspent transaction outputs (UTXOs). This means we need fast simple reads, and fast batches of random updates.
We don't need a server/client architecture, as we can't have multiple applications accessing ...
Transactions are money orders to the Bitcoin network that reassign value from one owner to another. To that end, transactions reference pieces of Bitcoin in the inputs and reassign this value to recipients in outputs. When the transaction is accepted on the network, the pieces of Bitcoin referenced in the inputs are spent and new "unspent transaction outputs"...
Can two UTXOs ever be combined into one UTXO?
Yes, absolutely. Each transaction can have any number of inputs and outputs; it can certainly have fewer outputs than inputs.
Here for example is a transaction with four inputs and one output, leading to a net decrease of three UTXOs.
An output ("coin") is by definition either fully unspent or completely spent. There is nothing in between. A transaction has one or more inputs (which refer to the unspent outputs of earlier transaction) and it fully consumes them.
A transaction can also have 1 or more outputs. For each output a value is specified (number of Satoshis), so by being a little ...
The fork serves two purposes:
Local modifications that are hard to bring upstream:
Windows support (which is partially based on the existing Windows port, but needed changes for building in MinGW)
Removal of compression support, as it doesn't help, and complicates the build.
Strict control over changes. Given the previous experience with the BDB to ...
A bitcoin is not a piece of data, and therefore does not have a length. A bitcoin, the unit of currency, is just like any other unit of measurement. It wouldn't make sense to ask "how much data is a meter?", and likewise it doesn't make sense to ask how long a bitcoin is.
That said, the amount of bitcoin that is stored by an individual is the sum of all ...
When you pay someone using a number of utxo's to fund your payment, the output being created is a new single utxo with the total amount of all those input (minus change and fees). Effectively, you are consolidating utxo's as inputs to fund your payment.
UTXO consolidation and breakage happens all the time by normal payments and doesn't usually require ...
Bitcoin Core since v0.8 maintains "undo files" that contain the information necessary to undo the effect of a block on the UTXO set.
In a way you can see blocks as authenticated patches to be applied to the UTXO set; they list new outputs to be added, and which inputs to be spent. In order to support rolling back the UTXO set, undo blocks are created as a ...
As of June 19 2019, using the following query:
bitcoin-indexer=> select reverse_bytes(output_tx.hash_id || output_tx.hash_rest),
input_tx.current_height - output_tx.current_height from output
inner join input on input.output_tx_hash_id = output.tx_hash_id AND input.output_tx_idx = ...
An address is a shortened notation for a particular script. As a transaction output contains exactly one script, it has at most one address (it is possible that the script does not correspond to a particular address, though).
Due to historic reasons, a (normal pay-to-pubkey-hash) address is however also used to refer to keys (by giving the address that ...
Updated as my earlier answer was wrong
Quoting from BIP 0030:
Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain.
This rule is to be applied to all blocks whose timestamp is after a point in time
This means that a transaction can have the same hash multiple ...
This is an interesting problem, one that has been studied and discuss within the bitcoin community quite a bit.
The basic way to do this is to keep track of a normalized TXID alongside of the actual TXID used in the protocol. Then to calculate the normalized ID of a transaction, you serialize it:
With the inputs' txids replaced by their normalized ...
I've looked into this before, and I've never been able to find an explicit rationale from Satoshi, but there are a couple of possible reasons.
For: Simplifies SPV verification
Imagine that rather than using the spent/unspent model, you track the balance of each address. You get a zero-confirmation transaction that pays to you from an address.
Now, to ...
One thing you might be missing is "there are no balances". The network doesn't know about wallets or balances, it only knows about outputs. These outputs are either spent or unspent. Once you have this concept it's easier to understand.
If your wallet says you have a balance of 1.2345 BTC that means it "thinks" there are X number of unspent outputs that ...