New answers tagged transaction-verification
1
The Bitcoin Network does not keep track of 'account balances', instead it uses an 'unspent transaction output' model. Each node will keep an updated list of all unspent transaction outputs (UTXOs), so that when it hears about a new transaction, it can verify that the transaction is only spending valid UTXOs. This check is done quite simply: the UTXOs used in ...
4
Let's run through the program.
The stack starts as <A sig> <A pubkey>.
You run OP_DUP. The stack is now <A sig> <A pubkey> <A pubkey>.
You run OP_HASH160. The stack is now <A sig> <A pubkey> <A pubkeyhash>.
You push (A expected pubkeyhash). The stack is now <A sig> <A pubkey> <A pubkeyhash> &...
0
All the above steps are correct although. The only catch over here is that except for the Scripts, everything else is captured in the Little Endian format (for whatever reasons). So except for Step 5 and Step 9 all other data is stored in the Little Endian format. Took me a while to get to this answer! Just a small tip to keep in mind when implementing!
4
What you described only works for transactions with one input and one output.
In general, what you do is you take the transaction that you want to verify, remove the scriptSigs from all of the inputs, and for the particular input you want, you place in the scriptSig the scriptPubKey (prepended by its length) of the output that input spends. If the output ...
1
What is signed is a simplified version of the transaction (replacing the scriptSig, since that is what we are creating). There is a lot here so hopefully I covered it all:
* `version` (4 Bytes) - Transaction format version
* `flag` (2 Byte Array) - Optional flag, if present, must be 0001, which indicates there is witness data in this transaction
* `input ...
3
When a transaction is created by your node and relayed to full nodes, they will check to ensure that the transaction is valid (no double spending is one condition amongst them). Full node maintains a set of UTXO list in the chainstate folder and is aggressively cached in memory. If a transaction is valid, the full nodes will remove the UTXOs that are ...
-1
The fake block is ignored and you have to wait until the next block, 2 blocks, 4 blocks, or 6 blocks, depending on how many confirmations the miner wants to be mined. But, if you are using Lightning, this can't happen unless you are taking out of lightning. The invalid block will not be added. If the miner will mine your block (ignoring other factors such as ...
3
An attacker can forge fake block.
Yes, but an invalid block would be rejected by all other participants that see it, and not relayed. Thus, such a block has little to no impact.
This is great but what happens if my transaction is in the fake block? Let’s suppose i am buying a car. Should i wait 6 blocks to be generated to be sure? But I have to wait one ...
3
what happens if my transaction is in the fake block?
It is also in the memory pool (mempool) of pending transactions at other nodes run by more honest people and will be included in a new and valid block in the normal way.
Let’s suppose I am buying a Tesla car. Should I wait 6 blocks to be generated to be sure? But I have to wait 1 hour!
Yes.
There are ...
Top 50 recent answers are included
