§ 05 · Transactions
Inputs
Which coins you are spending
On this page 7 sections
An inputInput: The part of a transaction that names an earlier output and spends it, all of it at once. says which coin you are spending. It doesn’t hold the coin or its value. It just points at an output of an earlier transaction, the way a cheque names an account.
Each input is 41 bytes: a pointer, an empty field and a sequence number. The signature that proves you may spend the coin isn’t in the input at all. It travels in the witness, matched to the input by position.
Try it
Pick the two-input example and hover each input’s fields.
What’s in an input?
| Field | Size | Type | Description |
|---|---|---|---|
| txid | 32 | hash | The transaction that created the output being spent, in internal (reversed) byte order. |
| vout | 4 | uint32 LE | Which output of that transaction, counting from 0. |
| scriptSig length | 1 | CompactSize | Always 00 on Pearl, except in a coinbase. |
| scriptSig | 0 | script | Empty. Coinbase only: 2 to 100 bytes starting with the block height. |
| sequence | 4 | uint32 LE | Replace-by-fee signal and relative locks. Pearl wallets write ffffffff. |
Here is the one input of a real payment from block 130,825, highlighted:
| Field | Bytes | Value |
|---|---|---|
| Version version | 4 @0 | 1 int32 little-endian. Pearl wallets and pearld coinbases use version 1; relay policy accepts 1-2. |
| Marker marker | 1 @4 | 0x00 Segwit marker (BIP-144): says witness data follows the outputs. |
| Flag flag | 1 @5 | 0x01 Witness flag; 0x01 is the only value Pearl accepts. |
| Input count vin.length | 1 @6 | 1 CompactSize number of inputs. |
| Previous txid vin[0].txid | 32 @7 | 33218153e215d1a1e80941850a696af178fc83bd6cf266be92e7ba9170553959 The transaction being spent, stored byte-reversed (internal order); shown here in normal display order. |
| Output index vin[0].vout | 4 @39 | 683 Which output of that transaction is spent (uint32 LE). |
| scriptSig length vin[0].scriptSig.length | 1 @43 | 0 Always 0 for non-coinbase inputs in Pearl: every spend uses the witness instead. |
| Sequence vin[0].sequence | 4 @44 | 0xffffffff Final (0xffffffff): no RBF signal, no relative locktime, and locktime is ignored for this input. Pearl wallets use this. |
| Output count vout.length | 1 @48 | 2 CompactSize number of outputs. |
| Amount vout[0].value | 8 @49 | 295,646,640 grains (2.95646640 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains). |
| Script length vout[0].scriptPubKey.length | 1 @57 | 34 CompactSize length of the locking script. |
| Locking script vout[0].scriptPubKey | 34 @58 | prl1p674s9jt2xs4amk6aq7ul867kcp8qwll5zsvpzzu6revewsu5z6eqv9d5z4 OP_1 OP_PUSHBYTES_32 <output key Q>: a Taproot output. |
| Amount vout[1].value | 8 @92 | 200,000,000 grains (2.00000000 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains). |
| Script length vout[1].scriptPubKey.length | 1 @100 | 34 CompactSize length of the locking script. |
| Locking script vout[1].scriptPubKey | 34 @101 | prl1pvt5a5d5z42egswfv7uscht7rv2rj3z4m8n3qp3w35592ydq88v4seuhn70 OP_1 OP_PUSHBYTES_32 <output key Q>: a Taproot output. |
| Witness items witness[0].length | 1 @135 | 1 Number of witness stack items for input 0. |
| Schnorr signature length witness[0][0].length | 1 @136 | 64 CompactSize length of this witness item. |
| Schnorr signature witness[0][0] | 64 @137 | 4686c7014749649b25555874c7772ecb7a44e85454893ed5888db11ebcdc82a22d74ce1a1671d02810f5ba1dca3277409e95a653ba9644099f7da26be7a86ba2 64-byte BIP-340 signature (R.x ‖ s) with SIGHASH_DEFAULT: a Taproot key-path spend. |
| Locktime locktime | 4 @201 | 0 0: no time lock. |
Previous txid
- Size
- 32 bytes
- Type
- SHA256d hash
- Format
- Internal byte order (reversed from how explorers show it)
The bytes start 5939557091bae792…. Explorers show transaction IDs with their bytes reversed, so this is the transaction 33218153e215d1a1e80941850a696af178fc83bd6cf266be92e7ba9170553959. The txid page explains why the two orders exist.
Output index (vout)
- Size
- 4 bytes
- Type
- Unsigned integer
- Format
- Little-endian
ab020000 is 0x2ab = 683. So the earlier transaction had at least 684 outputs, and this input spends number 683. The txid and index together are an outpointOutpoint: A pointer to one specific output: the ID of the transaction that made it, plus the number of the output within that transaction.: a unique name for one output, written 33218153…553959:683.
scriptSig
- Size
- 1 byte (the length, 00)
- Type
- Script
- Format
- Empty
In Bitcoin’s original design, the scriptSig held the signature and public key. On Pearl it’s always empty, for a simple reason: every output you can spend is a witness program (Taproot or P2MR), and Pearl’s script engine refuses a non-empty scriptSig on those (“native witness program cannot also have a signature script”). The only scriptSig with content is a coinbase’s.
Sequence
- Size
- 4 bytes
- Type
- Unsigned integer
- Format
- Little-endian
ffffffff, the maximum, which Pearl wallets always use: no replace-by-fee, no relative lock. Other values have meanings explained in locktime and sequence.
What doesn’t an input say?
Two important things: how much the coin is worth, and how it’s locked.
Every node already knows both. It keeps a table of every unspent output, the UTXO setUTXO: An output that has not been spent yet: a chunk of PRL waiting to be used. Your balance is the total of the UTXOs your keys can unlock., and looks up the outpoint there. For the payment above, the lookup says output 33218153…:683 holds 495,654,555 grains locked to prl1pfvyle3p7penvnezpg9awpa03ylfl0n30z3usygzvf8kt77wyra8suvzxy2.
Leaving them out saves space, but it means a signer has to trust whoever tells them the amounts. Taproot fixes that: the signed message includes every spent amount and locking script (see sighash), so a signer who’s lied to produces a signature that’s simply invalid.
What happens with several inputs?
They are listed one after another, after a count. This payment from block 130,822 has two, each spending output 0 of a different transaction:
| Field | Bytes | Value |
|---|---|---|
| Version version | 4 @0 | 1 int32 little-endian. Pearl wallets and pearld coinbases use version 1; relay policy accepts 1-2. |
| Marker marker | 1 @4 | 0x00 Segwit marker (BIP-144): says witness data follows the outputs. |
| Flag flag | 1 @5 | 0x01 Witness flag; 0x01 is the only value Pearl accepts. |
| Input count vin.length | 1 @6 | 2 CompactSize number of inputs. |
| Previous txid vin[0].txid | 32 @7 | c50fea91a819feb5ba4a9855428ebf6438194c29394c70830321af5ac8ec7d20 The transaction being spent, stored byte-reversed (internal order); shown here in normal display order. |
| Output index vin[0].vout | 4 @39 | 0 Which output of that transaction is spent (uint32 LE). |
| scriptSig length vin[0].scriptSig.length | 1 @43 | 0 Always 0 for non-coinbase inputs in Pearl: every spend uses the witness instead. |
| Sequence vin[0].sequence | 4 @44 | 0xffffffff Final (0xffffffff): no RBF signal, no relative locktime, and locktime is ignored for this input. Pearl wallets use this. |
| Previous txid vin[1].txid | 32 @48 | f7adce4f58c72f964418112dde7f1a600968b77ff28ee17c364adbc96c31dad5 The transaction being spent, stored byte-reversed (internal order); shown here in normal display order. |
| Output index vin[1].vout | 4 @80 | 0 Which output of that transaction is spent (uint32 LE). |
| scriptSig length vin[1].scriptSig.length | 1 @84 | 0 Always 0 for non-coinbase inputs in Pearl: every spend uses the witness instead. |
| Sequence vin[1].sequence | 4 @85 | 0xffffffff Final (0xffffffff): no RBF signal, no relative locktime, and locktime is ignored for this input. Pearl wallets use this. |
| Output count vout.length | 1 @89 | 2 CompactSize number of outputs. |
| Amount vout[0].value | 8 @90 | 125,578,616 grains (1.25578616 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains). |
| Script length vout[0].scriptPubKey.length | 1 @98 | 34 CompactSize length of the locking script. |
| Locking script vout[0].scriptPubKey | 34 @99 | prl1pdupm33flla60pv3ggjnzlv5lsgha5h6wqck5jtcajxl4vump5dqq3mvacr OP_1 OP_PUSHBYTES_32 <output key Q>: a Taproot output. |
| Amount vout[1].value | 8 @133 | 199,000,000 grains (1.99000000 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains). |
| Script length vout[1].scriptPubKey.length | 1 @141 | 34 CompactSize length of the locking script. |
| Locking script vout[1].scriptPubKey | 34 @142 | prl1pusrlal5eu7h9j476y7c4vk6vj450e598cxcpa69hne557rk9977skn6lrw OP_1 OP_PUSHBYTES_32 <output key Q>: a Taproot output. |
| Witness items witness[0].length | 1 @176 | 1 Number of witness stack items for input 0. |
| Schnorr signature length witness[0][0].length | 1 @177 | 64 CompactSize length of this witness item. |
| Schnorr signature witness[0][0] | 64 @178 | bcdee9e8c70a956f0faf3f19324ff7595aa9d6d377010f12a392d5dfb8a20b05076090f11d7d6523f995c316c40b5c4c635853491a29dd5367e54e899e460638 64-byte BIP-340 signature (R.x ‖ s) with SIGHASH_DEFAULT: a Taproot key-path spend. |
| Witness items witness[1].length | 1 @242 | 1 Number of witness stack items for input 1. |
| Schnorr signature length witness[1][0].length | 1 @243 | 64 CompactSize length of this witness item. |
| Schnorr signature witness[1][0] | 64 @244 | 9c9a3f1689bc718d7cbf2639e1433e7bb0f01896c7f2c14a565d515c41a5b5cd0e4a748978492d8dbda559088b66ef79003d421098cc25ef4ab05b39256790b8 64-byte BIP-340 signature (R.x ‖ s) with SIGHASH_DEFAULT: a Taproot key-path spend. |
| Locktime locktime | 4 @308 | 0 0: no time lock. |
The count byte is 02. In the witness, the first stack belongs to input 0 and the second to input 1. Each input carries its own signature, even if the same wallet owns both coins.
Inputs add up. This transaction spends 113,300,000 + 211,289,266 = 324,589,266 grains and creates outputs worth 324,578,616 grains. The difference, 10,650 grains, is the fee.
Does the order of inputs matter?
Yes, in two ways. The witness stacks follow the inputs in the same order, so the first stack proves the first input, and so on. And each signature commits to the index of the input it signs (see sighash), so moving a signature to another input breaks it.
Which coins to use, and in which order, is the wallet’s choice. Pearl’s wallet picks the largest coins first by default, then adds a change output at a random position. Spending several coins together tells the world they probably share an owner, one of the reasons wallets give out a fresh address for every payment.
What does a coinbase input look like?
The first transaction of every block creates new coins, so it has nothing to point at. Its single input uses a null outpoint, 32 zero bytes and index ffffffff, and its scriptSig starts with the block height:
| Field | Bytes | Value |
|---|---|---|
| Version version | 4 @0 | 2 int32 little-endian. Pearl wallets and pearld coinbases use version 1; relay policy accepts 1-2. |
| Marker marker | 1 @4 | 0x00 Segwit marker (BIP-144): says witness data follows the outputs. |
| Flag flag | 1 @5 | 0x01 Witness flag; 0x01 is the only value Pearl accepts. |
| Input count vin.length | 1 @6 | 1 CompactSize number of inputs. |
| Previous txid vin[0].txid | 32 @7 | 0000000000000000000000000000000000000000000000000000000000000000 All zeros: this input creates new coins (coinbase). |
| Output index vin[0].vout | 4 @39 | 0xffffffff 0xffffffff together with a zero txid marks a coinbase. |
| scriptSig length vin[0].scriptSig.length | 1 @43 | 39 CompactSize length of the scriptSig. |
| Coinbase script vin[0].scriptSig | 39 @44 | 0309ff01048393d76a2f706f6f6c2e6b7279707465782e636f6d2f1550cad31e016e7bf00f2ecb Coinbase data. It starts with the block height 130825 (BIP-34, required in every Pearl block), then anything the miner likes. |
| Sequence vin[0].sequence | 4 @83 | 0xffffffff Final (0xffffffff): no RBF signal, no relative locktime, and locktime is ignored for this input. Pearl wallets use this. |
| Output count vout.length | 1 @87 | 2 CompactSize number of outputs. |
| Amount vout[0].value | 8 @88 | 223,838,373,068 grains (2238.38373068 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains). |
| Script length vout[0].scriptPubKey.length | 1 @96 | 34 CompactSize length of the locking script. |
| Locking script vout[0].scriptPubKey | 34 @97 | prl1puv0gqv4x0wd0ylwz086y3sqrg4a6umza9r08aecehjrmdqq7mctsmqaqsh OP_1 OP_PUSHBYTES_32 <output key Q>: a Taproot output. |
| Amount vout[1].value | 8 @131 | 0 grains (0.00000000 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains). |
| Script length vout[1].scriptPubKey.length | 1 @139 | 38 CompactSize length of the locking script. |
| Locking script vout[1].scriptPubKey | 38 @140 | witness commitment 78cc1a61dcfcee9c59ddd9f4d56a98764c071e077bcc36fe9d1cf0aad50ebac3 OP_RETURN aa21a9ed ‖ SHA256d(witness Merkle root ‖ nonce): the BIP-141 witness commitment. |
| Witness items witness[0].length | 1 @178 | 1 Number of witness stack items for input 0. |
| Witness reserved value length witness[0][0].length | 1 @179 | 32 CompactSize length of this witness item. |
| Witness reserved value witness[0][0] | 32 @180 | 0000000000000000000000000000000000000000000000000000000000000000 The coinbase witness is one 32-byte value (the witness-commitment nonce); pearld uses zeros. |
| Locktime locktime | 4 @212 | 0 0: no time lock. |
That’s how nodes recognize a coinbase. The coinbase page decodes its scriptSig.
What rules does an input have to follow?
- The output must exist and be unspent. Spending the same outpoint twice is a double spendDouble spend: Trying to spend the same coins twice, for example paying two people with one coin. Stopping this without a bank is the main job of a blockchain.; only one of the two transactions can ever be in the chain.
- New coins must wait. An output from a coinbase can’t be spent until it is 100 blocks deep.
- Parents first. If an input spends an output created in the same block, the parent transaction must come earlier in the block. Pearl enforces this from v1.5.1.
- There must be a witness. Pearl’s mempool rejects a transaction with no witness data at all.