Difference between revisions of "TXID"
AlexMackay (talk | contribs) |
Todd Price (talk | contribs) |
||
| (15 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | A Transaction ID or TXID is | + | A Transaction ID or TXID is the '''double SHA256 hash''' or '''SHA256d''' of a serialised [[Bitcoin Transactions| Bitcoin transaction]]. TXIDs are not part of the transaction, as the hash cannot be generated until the transaction is complete. A TXID and VOUT (or ''prevout_n'') [[index]] are used to reference [[UTXO|UTXOs]] when they are added to a transaction as an input. |
| + | ==Data== | ||
| − | |||
| − | |||
<pre> | <pre> | ||
transaction: | transaction: | ||
| + | { | ||
"inputs": [ | "inputs": [ | ||
{ | { | ||
"prevout_hash": "b8ed28aa87b92328e26a20553ac49fcb21e1f68daeb6cf7bcf4536e40503ffa8", | "prevout_hash": "b8ed28aa87b92328e26a20553ac49fcb21e1f68daeb6cf7bcf4536e40503ffa8", | ||
"prevout_n": 0, | "prevout_n": 0, | ||
| − | "scriptSig": " | + | "scriptSig": "4830450221008824eee04a2fbe62d2c3ee330eb2523b2c0188240714bb1d893aced1c454fa9a02202d32dbccc2af1c4b |
| + | 830795f2fa8cd569a06ee70cb9d836bbd510f0b45a47711b4121028580686976c0e6a7e44a78387913e2d7508ff2344d | ||
| + | 5f48669ba111dcd04170a8", | ||
"sequence": 4294967294, | "sequence": 4294967294, | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
} | } | ||
], | ], | ||
| Line 33: | Line 28: | ||
} | } | ||
], | ], | ||
| − | |||
} | } | ||
| − | serialized | + | serialized transaction: "0100000001a8ff0305e43645cf7bcfb6ae8df6e121cb9fc43a55206ae22823b987aa28edb8000000006b4830450221008824 |
| + | eee04a2fbe62d2c3ee330eb2523b2c0188240714bb1d893aced1c454fa9a02202d32dbccc2af1c4b830795f2fa8cd569a06e | ||
| + | e70cb9d836bbd510f0b45a47711b4121028580686976c0e6a7e44a78387913e2d7508ff2344d5f48669ba111dcd04170a8fe | ||
| + | ffffff0208070000000000001976a9146b0a9ed05da7223a1fe57e1a4d307556f7d6200788ac905f0100000000001976a914 | ||
| + | b993e512cb186f3f1c3f556a09716a1580eb99a188ac09230900" | ||
| − | transaction id: d8c5c42cbd1df7e48acab76fe05f2c9e612a20996fd37f4ffd4dc251385b6ba3</pre> | + | transaction id: "d8c5c42cbd1df7e48acab76fe05f2c9e612a20996fd37f4ffd4dc251385b6ba3" </pre> |
===Explanation=== | ===Explanation=== | ||
| − | The double SHA256 hash can be used | + | The double SHA256 hash enables network participants to identify and communicate transactions efficiently. They are used at all levels of the ecosystem, including [[Simplified Payment Verification|wallets]] and [[Block explorer|block explorers]]. |
| + | |||
| + | Transaction IDs are used extensively in the [[Protocol|peer-to-peer protocol]]. For example, peers on the network synchronise their transaction database using a 3 message sequence. A node will send out an ''inv'' message containing one or more transaction IDs. In the case that the receiving node/peer does not have a copy of the full transaction, he can respond with a ''gettransaction'' message containing the transaction ID. This is responded to with a ''tx'' message containing the full serialised transaction. Using transaction IDs to broadcast transaction database information, greatly reduces the volume of data that has to be sent over the network. | ||
| + | |||
| + | The double hash property can be used in another interesting way. The user can know that a corresponding party has a copy of the full TX by requesting the intermediate hash, which can only be generated by hashing the full transaction. This 'proof of possession' is present across Bitcoin and enables complex functionality and checking of resources when Bitcoin is being used in a fully peer to peer environment. | ||
==See Also== | ==See Also== | ||
| − | + | * [[Bitcoin Transactions]] | |
| + | * [[Transaction Malleability]] | ||
| + | * [[Transaction Pools]] | ||
Latest revision as of 03:26, 22 April 2022
A Transaction ID or TXID is the double SHA256 hash or SHA256d of a serialised Bitcoin transaction. TXIDs are not part of the transaction, as the hash cannot be generated until the transaction is complete. A TXID and VOUT (or prevout_n) index are used to reference UTXOs when they are added to a transaction as an input.
Data
transaction:
{
"inputs": [
{
"prevout_hash": "b8ed28aa87b92328e26a20553ac49fcb21e1f68daeb6cf7bcf4536e40503ffa8",
"prevout_n": 0,
"scriptSig": "4830450221008824eee04a2fbe62d2c3ee330eb2523b2c0188240714bb1d893aced1c454fa9a02202d32dbccc2af1c4b
830795f2fa8cd569a06ee70cb9d836bbd510f0b45a47711b4121028580686976c0e6a7e44a78387913e2d7508ff2344d
5f48669ba111dcd04170a8",
"sequence": 4294967294,
}
],
"lockTime": 598793,
"outputs": [
{
"scriptPubKey": "76a9146b0a9ed05da7223a1fe57e1a4d307556f7d6200788ac",
"value": 1800
},
{
"scriptPubKey": "76a914b993e512cb186f3f1c3f556a09716a1580eb99a188ac",
"value": 90000
}
],
}
serialized transaction: "0100000001a8ff0305e43645cf7bcfb6ae8df6e121cb9fc43a55206ae22823b987aa28edb8000000006b4830450221008824
eee04a2fbe62d2c3ee330eb2523b2c0188240714bb1d893aced1c454fa9a02202d32dbccc2af1c4b830795f2fa8cd569a06e
e70cb9d836bbd510f0b45a47711b4121028580686976c0e6a7e44a78387913e2d7508ff2344d5f48669ba111dcd04170a8fe
ffffff0208070000000000001976a9146b0a9ed05da7223a1fe57e1a4d307556f7d6200788ac905f0100000000001976a914
b993e512cb186f3f1c3f556a09716a1580eb99a188ac09230900"
transaction id: "d8c5c42cbd1df7e48acab76fe05f2c9e612a20996fd37f4ffd4dc251385b6ba3"
Explanation
The double SHA256 hash enables network participants to identify and communicate transactions efficiently. They are used at all levels of the ecosystem, including wallets and block explorers.
Transaction IDs are used extensively in the peer-to-peer protocol. For example, peers on the network synchronise their transaction database using a 3 message sequence. A node will send out an inv message containing one or more transaction IDs. In the case that the receiving node/peer does not have a copy of the full transaction, he can respond with a gettransaction message containing the transaction ID. This is responded to with a tx message containing the full serialised transaction. Using transaction IDs to broadcast transaction database information, greatly reduces the volume of data that has to be sent over the network.
The double hash property can be used in another interesting way. The user can know that a corresponding party has a copy of the full TX by requesting the intermediate hash, which can only be generated by hashing the full transaction. This 'proof of possession' is present across Bitcoin and enables complex functionality and checking of resources when Bitcoin is being used in a fully peer to peer environment.