Transaction - Revision history

NotATether: /* Witness */

2024-01-17T09:52:15Z

Witness

← Older revision		Revision as of 09:52, 17 January 2024
Line 133:		Line 133:
	It is important to note that when parsing a raw transaction, the witness fields are '''not''' congregated together into one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.		It is important to note that when parsing a raw transaction, the witness fields are '''not''' congregated together into one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.

	Transactions which do not have any native segwit (such as P2WPKH or P2WSH) inputs must use the legacy transaction format. Witness fields are only added for native segwit inputs, so a transaction with no such inputs cannot use the segwit transaction format, including the marker and flag.		Transactions which do not have any native segwit (such as P2WPKH or P2WSH) inputs must use the legacy transaction format. Witness fields are only added for native segwit inputs, so a transaction with no such inputs cannot use the segwit transaction format, including the marker and flag. Additionally, each witness field corresponds to its respective native segwit input in the order which they are defined in the transaction. This means that in the raw transaction, the first witness field is for the first native segwit input in the transaction, and so on.

	===== Verification =====		===== Verification =====

NotATether: /* Witness */

2024-01-17T09:44:33Z

Witness

← Older revision		Revision as of 09:44, 17 January 2024
Line 133:		Line 133:
	It is important to note that when parsing a raw transaction, the witness fields are '''not''' congregated together into one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.		It is important to note that when parsing a raw transaction, the witness fields are '''not''' congregated together into one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.

	Transactions which do not have any native segwit ~~inputs, i.e.~~ P2WPKH or P2WSH, must use the legacy transaction format. Witness fields are only added for native segwit inputs, so a transaction with no such inputs cannot use the segwit transaction format, including the marker and flag.		Transactions which do not have any native segwit (such as P2WPKH or P2WSH) inputs must use the legacy transaction format. Witness fields are only added for native segwit inputs, so a transaction with no such inputs cannot use the segwit transaction format, including the marker and flag.

	===== Verification =====		===== Verification =====

NotATether: Explain how the witness stack works.

2024-01-17T09:43:37Z

Explain how the witness stack works.

← Older revision		Revision as of 09:43, 17 January 2024
Line 131:		Line 131:
	For Segwit transactions, there is a list of witness fields after the outputs, with each witness field corresponding to an input of the same index. Each witness field contains a varint which tells the number of elements on the witness' stack, and the stack elements themselves contains pairs of varints, signifying the length of the data, followed by the data itself.		For Segwit transactions, there is a list of witness fields after the outputs, with each witness field corresponding to an input of the same index. Each witness field contains a varint which tells the number of elements on the witness' stack, and the stack elements themselves contains pairs of varints, signifying the length of the data, followed by the data itself.

	It is important to note that the witness fields are '''not''' congregated together into one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.		It is important to note that when parsing a raw transaction, the witness fields are '''not''' congregated together into one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.

			Transactions which do not have any native segwit inputs, i.e. P2WPKH or P2WSH, must use the legacy transaction format. Witness fields are only added for native segwit inputs, so a transaction with no such inputs cannot use the segwit transaction format, including the marker and flag.

	===== Verification =====		===== Verification =====

NotATether: Add detail

2024-01-03T05:20:02Z

Add detail

← Older revision		Revision as of 05:20, 3 January 2024
Line 47:		Line 47:
	\|4 bytes		\|4 bytes
	\|}		\|}

			There is no version 0 transaction - it is undefined. Versions greater than 2 are reserved for future use by the protocol. Flag and Witness are mandatory for any transaction that includes [[Segwit]] inputs, and should be omitted for legacy transactions that do not make use of Segwit.

	=== Principle example of a Bitcoin transaction with 1 input and 1 output only ===		=== Principle example of a Bitcoin transaction with 1 input and 1 output only ===

NotATether: /* General format of a Bitcoin transaction (inside a block) */

2024-01-03T05:14:26Z

General format of a Bitcoin transaction (inside a block)

← Older revision		Revision as of 05:14, 3 January 2024
Line 16:		Line 16:
	\|-		\|-
	\|Version no		\|Version no
	\|currently 1		\|currently 1. Set to 2 if you use OP_CHECKSEQUENCEVERIFY to enable timelocks
	\|4 bytes		\|4 bytes
	\|-		\|-

NotATether: /* Witness */

2023-07-25T07:27:42Z

Witness

← Older revision		Revision as of 07:27, 25 July 2023
Line 129:		Line 129:
	For Segwit transactions, there is a list of witness fields after the outputs, with each witness field corresponding to an input of the same index. Each witness field contains a varint which tells the number of elements on the witness' stack, and the stack elements themselves contains pairs of varints, signifying the length of the data, followed by the data itself.		For Segwit transactions, there is a list of witness fields after the outputs, with each witness field corresponding to an input of the same index. Each witness field contains a varint which tells the number of elements on the witness' stack, and the stack elements themselves contains pairs of varints, signifying the length of the data, followed by the data itself.

	It is important to note that the witness fields are '''not''' congregated together in one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.		It is important to note that the witness fields are '''not''' congregated together into one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.

	===== Verification =====		===== Verification =====

NotATether: Add note for deserializing witness

2023-07-25T07:27:25Z

Add note for deserializing witness

← Older revision		Revision as of 07:27, 25 July 2023
Line 128:		Line 128:

	For Segwit transactions, there is a list of witness fields after the outputs, with each witness field corresponding to an input of the same index. Each witness field contains a varint which tells the number of elements on the witness' stack, and the stack elements themselves contains pairs of varints, signifying the length of the data, followed by the data itself.		For Segwit transactions, there is a list of witness fields after the outputs, with each witness field corresponding to an input of the same index. Each witness field contains a varint which tells the number of elements on the witness' stack, and the stack elements themselves contains pairs of varints, signifying the length of the data, followed by the data itself.

			It is important to note that the witness fields are '''not''' congregated together in one "witness" field in structured, deserialized output, but each witness is placed in its own "witness" key under the respective input.

	===== Verification =====		===== Verification =====

NotATether: Add witness explanation

2023-07-23T04:07:52Z

Add witness explanation

← Older revision		Revision as of 04:07, 23 July 2023
Line 124:		Line 124:
	An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block can claim it by inserting it into the coinbase transaction of that block.		An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block can claim it by inserting it into the coinbase transaction of that block.
	[[File:bitcointransactions.JPG\|thumb\|A sends 6.102 BTC to C and C generates 6.25 BTC. C sends 3.12009 BTC to D, and he needs to send himself some change. D sends the 3.12009 BTC to someone else, but they haven't redeemed it yet. Only D's output and C's change are capable of being spent in the current state.]]		[[File:bitcointransactions.JPG\|thumb\|A sends 6.102 BTC to C and C generates 6.25 BTC. C sends 3.12009 BTC to D, and he needs to send himself some change. D sends the 3.12009 BTC to someone else, but they haven't redeemed it yet. Only D's output and C's change are capable of being spent in the current state.]]

			===== Witness =====

			For Segwit transactions, there is a list of witness fields after the outputs, with each witness field corresponding to an input of the same index. Each witness field contains a varint which tells the number of elements on the witness' stack, and the stack elements themselves contains pairs of varints, signifying the length of the data, followed by the data itself.

	===== Verification =====		===== Verification =====

NotATether: Fix outpoint hash size

2023-07-03T03:01:02Z

Fix outpoint hash size

← Older revision		Revision as of 03:01, 3 July 2023
Line 77:		Line 77:
	\|Outpoint hash		\|Outpoint hash
	\|The previous transaction that contains the spendable output		\|The previous transaction that contains the spendable output
	\|4 bytes		\|32 bytes
	\|-		\|-
	\|Outpoint index		\|Outpoint index

NotATether: Create table

2023-07-03T03:00:25Z

Create table

← Older revision		Revision as of 03:00, 3 July 2023
Line 102:		Line 102:

	===== Output =====		===== Output =====

			{\| class="wikitable"
			\|-
			! Field
			! Description
			! Size
			\|-
			\|Value
			\|The monetary value of the output in satoshis
			\|8 bytes
			\|-
			\|Script length
			\| positive integer [[ Protocol_specification#Variable_length_integer\|VI = VarInt]]
			\| 1 - 9 bytes
			\|-
			\|Script
			\|A calculation which future transactions need to solve in order to spend it
			\|Variable
			\|}

	An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block can claim it by inserting it into the coinbase transaction of that block.		An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block can claim it by inserting it into the coinbase transaction of that block.