People who code: we want your input. Take the Survey
21

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 ...


18

I'm sorry to say this is a scam. Put it in dollar terms. Someone is telling you that you've won a surprise $20,000 (not very believable in the first place). But to get it, you have to send $600 for "verification" -- what possible reason could there be for this except to enrich the scammer? They'll never send the $20,000, and you'll be out the $...


13

Yes! The trick is to count each input with its effective value rather than its nominal value. Transactions are composed of three parts: the overhead, the inputs and the outputs. Outputs: The size of the output scripts is determined by the recipient addresses, so their size is given by the transaction instructions. We do not know whether we will need a ...


10

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 ...


10

A coinbase transaction can have as many outputs as the miner who created it wants. You may see that there are not just one output for the reward, sometimes there are multiple outputs so that the coinbase transaction pays to multiple miners. Additionally, there may be other 0 value OP_RETURN outputs if the miner so chooses. Typically this is because the miner ...


10

This is a question of definition. The blockchain doesn't store anything, it's an abstract data structure that's collectively maintained by nodes in a network. Those nodes are the ones that store things. That may or may not include the actual transaction data - it doesn't matter. The Bitcoin blockchain consists of hash-linked block headers. Every block header ...


9

You must reveal the secret in order to spend the output, else there is no way other users could verify that your hash is indeed the correct one. Once you reveal that secret, anybody could attempt to create a competing transaction which spends to a different output - miners in particular would be able to confirm this transaction into a block and ignore your ...


9

Just to give a little background first: Bitcoin uses a so-called UTXO model. You own UTXOs (or "coins", to give an analogy). Every coin has a value (which can be any number of satoshis) and has an owner (script) "stamped" into it. Every transactions "melts down" a number of existing coins, and "forges" new coins. The ...


7

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 ...


7

Advantages of OP_CHECKMULTISIG over Shamir Secret Sharing for k-of-n: There is no need to reconstruct the actual secret key on one specific machine. With SSS, you're inherently relying on that one machine being able to verify that what it's going to sign is what is intended - otherwise you may e.g. be sending your entire balance instead of just the payment ...


7

When you spend from a Bitcoin address, your transaction includes both the public key corresponding to the hashed address you're trying to spend from, as well as a signature that can be verified with that public key. Your link is to a block, which is not signed itself. However, let's look at a transaction from your block: https://www.blockchain.com/btc/tx/...


6

At the protocol level, Bitcoin has no concept of "balances" or "addresses", and their common interpretation isn't relevant during verification. Every transaction spends "coins" and reforges them into new "coins" (called UTXOs). Every UTXO has a value (in number of satoshis) and an locking script. UTXOs are always spent ...


6

Yes, but only if A -> B is placed before B -> C in the list of transactions. Here is a graph of the percentage of transactions spending each other in the same block, it is usually around 10%.


6

First of all, what is the goal? The Bitcoin consensus rules already completely eliminate the possibility of an "double spend" within any individual version of history ("chain"). The concern is about individual wallets accepting a transaction as a fullfilled payment, before it is certain that that transaction will end up in the winning ...


6

The issue here is that the two transactions are different, and combinerawtransaction does not operate on different transactions (it apparently just silently does nothing). It sounds like you expect combinerawtransaction to take two separate transactions and create a new one which has the inputs and outputs of both transactions. (or perhaps take two ...


5

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 ...


5

Kind of, but coin selection is hard in general. The idea is that inputs pay for themselves. It is easy to compute how much in fees you will need to pay for an input at a given fee rate. So when you do coin selection, instead of selecting on the actual value of the input, you use the value of the input minus the fees it will pay. This is known as the ...


5

This is intentionally not possible. If a transaction would be valid in block X, we want it (absent double spend) to remain valid in any successor of X. This guarantees that (temporary, otherwise harmless) forks that result in small reorgs will never invalidate unrelated transactions - and they will just be able to be mined again in the new branch. It also ...


5

The Bitcoin network uses the blockchain to form consensus on the journal of transactions. The blocks commit the network to a specific order of events and guarantee propagation. Blocks are found roughly every ten minutes and are limited to 4,000,000 weight units (or 1,000,000 vbytes). Said blockweight limit and cadence of blocks are what limits network's ...


5

That's a question about Ethereum, a system that's notoriously difficult to accept payments with due to some incredibly bad design decisions. Ethereum has operational costs for making new addresses which make this sort of poor engineering attractive. We have no need to do anything ridiculous like that to try to distinguish payments, we can just make a new ...


5

This is normal. Here you can see a chart of average transacted value every day: https://blockchair.com/bitcoin/charts/average-transaction-amount-btc There are 2 things that contribute to this: The very large transactions skewing the numbers. This becomes more apparent if you take a look at the median transaction values, which are around the 0.02-0.03 BTC ...


5

From https://en.bitcoin.it/wiki/Protocol_documentation#Transaction_Verification we learn : Almost all integers are encoded in little endian. Only IP or port number are encoded big endian. You should look at the https://en.m.wikipedia.org/wiki/Endianness and flip the order of the bitstring to have the bit at the correct position Using an online hex ...


4

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 ...


4

Can it safely be said that the first input in the inputs of the transaction is the sender's? No, no such ordering exists. Transactions consume UTXOs as inputs, and create new UTXOs as outputs. A transaction can have multiple inputs from one person, or inputs from multiple people. In some cases, more than one person can own an input. So there isn't really ...


4

If you create a raw transaction yourself, then that is the raw transaction. Whatever you put in it is exactly what the transaction will be, in the same order. There are some conventions around output ordering. Some software will randomly permute the outputs; other software uses BIP69 which specifies a deterministic ordering. There is however no requirement ...


4

Blocks do not contain transcation ids at all, they contain the full transactions themselves. If you are using the getblock rpc and seeing txids, that's just because showing the details of all of the transactions is extremely verbose, so only the txids are output. You can see the full transaction details of a block by setting the second argument to 2.


4

This cannot happen. Every block contains at least a "coinbase" transaction that distributes the subsidy and fees to the block's miners. Blocks without coinbase are invalid, even if the subsidy were 0.


4

As @chytrik already described, address reuse does not solve your problem for UTXO-based coins, each transaction output must be individually referenced regardless. When your users deposit into your site, you want to give them separate addresses, so that you can track whose internal balance should be credited. After that, the funds are in your custody, though. ...


4

It is the position of your txo in the outputs array of the transaction that created it. You can see that this transaction created 2 outputs and that your output is the first one (0). This index is also sometimes refer to as vout.


4

There are approximately 800,000 unique addresses on the blockchain with some Bitcoin held at those addresses at the present time according to blockchain.com. Let's assume these addresses are all bech32 (to simplify the calculation, in reality these are the minority). The witness program in a bech32 SegWit v0 P2WSH address is 32 bytes. In theory this means ...


Only top voted, non community-wiki answers of a minimum length are eligible