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:
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 ...
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 ...
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 ...
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 ...
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 (...
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 long-term transaction fees.
Non-dust change creation
It would be ...
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 ...
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 ...
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 ...
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.
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"...
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 ...
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 ...
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.
The primary advantages of the UTXO model are simplicity of implementation and improved privacy.
With the UTXO model, transactions just consume some UTXOs and create some UTXOs. This tight constraint on what transactions can do makes transactions simpler and easier to execute in parallel.
The UTXO model also improves privacy by making it more difficult to ...
In Confidential Transactions (as used in Blockstream's Elements and Liquid), there are still identifiable UTXOs.
The only change is that instead of the amount, a homomorphic commitment to the amount is stored. While not technically correct, you could see it as a form of encryption that is compatible with addition and subtraction. So if a+b=c+d then E(a)+E(b)...
With vanilla Bitcoin Core, there is no efficient way to do this.
I see two options:
a) Slow and very inefficient RPC loop (not recommended)
Get the genesis block hash (RPC getblockhash 0)
Get the block with all transaction (RPC getblock <hash> 2, 2 stands for verbosity with transaction)
Loop through all transactions and all its outputs, call ...
This is implementation dependent, but in Bitcoin Core there is not just a single UTXO set:
The UTXO set on disk in the chainstate/ directory in a database. It corresponds to the state as of the last flushed block (and does not include the effects of any mempool transaction, or of any block since the last flush).
The in-memory coins cache is a cache on top ...
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 figure ...
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 ...
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 ...
What might be confusing you, and which is a common misconception, is that the addresses themselves somehow "hold" the bitcoin balances, and gain and lose the coins via transactions. In fact all the blockchain does is link up previous outputs to new inputs, and the keys make sure only the correct person is allowed to send the coins.
Your balance is just the ...
1) ...How's my total UTXO calculated?...
Each node calculates it's own UTXO set, there is no single 'global UTOX set'. You may own some subset of the UTXOs, but there is no pooling. If you receive payments to the same address more than once, each one will be it's own UTXO.
2) ...If all public addresses have their own UTXO, then the wallet has to choose a ...
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 = ...