<p>I'm not sure if you will have already seen this:</p>
<blockquote>
<p>From: Satoshi Nakamoto &lt;satoshin@gmx.com<br />
Date: Wed, Mar 9, 2011 at 5:15 PM<br />
To: Mike Hearn mike@plan99.net<br />
Subject: Re: Open sourced my Java SPV impl</p>
<p>[...]</p>
<blockquote>
<p>I haven't fully
understood why sequence numbers are a property of the tx inputs rather
than the tx itself.</p>
</blockquote>
<p>It's for contracts.  An unrecorded open transaction can keep being replaced until nLockTime.  It may contain payments by multiple parties.  Each input owner signs their input.  For a new version to be written, each must sign a higher sequence number (see IsNewerThan).  By signing, an input owner says &quot;I agree to put my money in, if everyone puts their money in and the outputs are this.&quot;  There are other options in SignatureHash such as SIGHASH_SINGLE which means &quot;I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.&quot;.  If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.</p>
<p>The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature.  The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.</p>
<p>One use of nLockTime is high frequency trades between a set of parties.  They can keep updating a tx by unanimous agreement.  The party giving money would be the first to sign the next version.  If one party stops agreeing to changes, then the last state will be recorded at nLockTime.  If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out.  Intermediate transactions do not need to be broadcast.  Only the final outcome gets recorded by the network.  Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.</p>
</blockquote>
<p>Quoted from <a href="https://www.bitcoin.com/satoshi-archive/emails/mike-hearn/13/" rel="noreferrer">https://www.bitcoin.com/satoshi-archive/emails/mike-hearn/13/</a><br />
Also seen at <a href="https://plan99.net/%7Emike/satoshi-emails/thread4.html" rel="noreferrer">https://plan99.net/~mike/satoshi-emails/thread4.html</a></p>
<p>Mike Hearn replied</p>
<blockquote>
<p>Ah ha. A whole unexplored area of the system opens up before my eyes :-) The concept of forming distributed contracts and escrow transactions without needing to trust an intermediary is a concept nearly as novel as BitCoin itself, I think.</p>
</blockquote>
<hr />
<p>I believe the above explains Nakamoto's motivation for the choices initially made with respect to sequence and locktime. Or at least I believe Nakamoto believed it answered that specific question.</p>
<hr />
<p>As I expect many people know, use of these data fields has subsequently been affected by adoption of ideas such as <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="noreferrer">BIP-68</a> and <a href="https://bitcoin.stackexchange.com/q/115549/13866">forced closure of Lightning channels</a> etc.</p>

CC BY-SA 4.0
2023-01-11T17:00:03.663Z
2023-01-11T18:16:47.590Z
2023-01-11T18:16:47.590Z
RedGrittyBrick
<p>See @RedGrittyBrick's <a href="https://bitcoin.stackexchange.com/a/116722/208">answer</a> for historical context for why there is a per-input <code>nSequence</code> field. The evolution since includes:</p>
<ul>
<li><code>nLockTime</code>'s meaning has been unchanged since the early days; it indicates the earlier time or height when the transaction can be included in a block (consensus rule). <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="noreferrer">BIP65</a> later added script functionality for putting constraints on the spending <code>nLockTime</code> value, but the semantics of <code>nLockTime</code> themselves have been unchanged.</li>
<li><code>nSequence</code> was designed for transaction replacement, and in the original design for transaction replacement, every input could be replaced independently (and could signal independently whether it could be replaced). Originally, <code>nSequence</code> only had one consensus-affecting impact: if all <code>nSequence</code> were 0xFFFFFFFF, the transaction is always eligible for inclusion (even if <code>nLockTime</code> hasn't passed yet). The meaning of <code>nSequence</code> was however changed completely:
<ul>
<li>The original replacement semantics were disabled in <a href="https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7" rel="noreferrer">August 2010</a>, rendering the distinction between all non-0xFFFFFFFF <code>nSequence</code> values meaningless.</li>
<li>Non-eligible-for-inclusion-in-blocks transactions were disallowed in <a href="https://github.com/bitcoin/bitcoin/pull/2223" rel="noreferrer">January 2013</a> for relay and mempool acceptance (due to DoS concerns) entirely.</li>
<li>Later, <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="noreferrer">BIP68</a> added a consensus meaning to <code>nSequence</code>, as a &quot;relative locktime&quot;, repurposing the old field that had become redundant. Simultaneously <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="noreferrer">BIP112</a> added script functionality to put constraints on the spending <code>nSequence</code>.</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="noreferrer">BIP125</a> added new transaction replacement rules that didn't involve sequencing anymore.</li>
</ul>
</li>
</ul>
<p>In retrospect however, I believe it would actually have been better if both absolute and relative locktimes were per-input. Absolute locktimes (the per-transaction <code>nLockTime</code> field) suffer from the problem that one cannot specify both a height-based and a time-based one, which implies that two UTXOs which (through BIP65's <code>OP_CHECKLOCKTIMEVERIFY</code>) require distinct types of locktimes cannot be spent simultaneously in the same transaction.</p>

CC BY-SA 4.0
2023-01-11T18:57:22.033Z
2023-01-11T19:46:48.983Z
2023-01-11T19:46:48.983Z
Pieter Wuille
<p>Giacomo Zucco <a href="https://twitter.com/giacomozucco/status/1612057324662702080" rel="noreferrer">pointed out</a> the oddity of there being one timelock field per transaction, but one sequence per input.
Even for the original use of determining the order of replacement, it would seem that only the maximum sequence is relevant in the context of the whole transaction rather than each input. Is there a known reason or benefit for each input having a sequence or is it a quirk in the transaction design? What about locktime, would there be a benefit if it also was set per input instead of only once per transaction?</p>

<transactions><transaction-input><locktime><sequence>
Why is the locktime set at transaction level while the sequence is set at input level?
Murch
# Why is the locktime set at transaction level while the sequence is set at input level?

(Asked by: username_0 on 2023-01-10)

Giacomo Zucco [pointed out](https://twitter.com/giacomozucco/status/1612057324662702080) the oddity of there being one timelock field per transaction, but one sequence per input.
Even for the original use of determining the order of replacement, it would seem that only the maximum sequence is relevant in the context of the whole transaction rather than each input. Is there a known reason or benefit for each input having a sequence or is it a quirk in the transaction design? What about locktime, would there be a benefit if it also was set per input instead of only once per transaction?

**Tags:** transactions, transaction-input, locktime, sequence


---

## 2 answers

### Answer by username_2 on 2023-01-11. Score: 7 | Accepted answer

See @username_1's [answer](https://bitcoin.stackexchange.com/a/116722/208) for historical context for why there is a per-input `nSequence` field. The evolution since includes:

* `nLockTime`'s meaning has been unchanged since the early days; it indicates the earlier time or height when the transaction can be included in a block (consensus rule). [BIP65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) later added script functionality for putting constraints on the spending `nLockTime` value, but the semantics of `nLockTime` themselves have been unchanged.
* `nSequence` was designed for transaction replacement, and in the original design for transaction replacement, every input could be replaced independently (and could signal independently whether it could be replaced). Originally, `nSequence` only had one consensus-affecting impact: if all `nSequence` were 0xFFFFFFFF, the transaction is always eligible for inclusion (even if `nLockTime` hasn't passed yet). The meaning of `nSequence` was however changed completely:
  + The original replacement semantics were disabled in [August 2010](https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7), rendering the distinction between all non-0xFFFFFFFF `nSequence` values meaningless.
  + Non-eligible-for-inclusion-in-blocks transactions were disallowed in [January 2013](https://github.com/bitcoin/bitcoin/pull/2223) for relay and mempool acceptance (due to DoS concerns) entirely.
  + Later, [BIP68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) added a consensus meaning to `nSequence`, as a "relative locktime", repurposing the old field that had become redundant. Simultaneously [BIP112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) added script functionality to put constraints on the spending `nSequence`.
  + [BIP125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) added new transaction replacement rules that didn't involve sequencing anymore.

In retrospect however, I believe it would actually have been better if both absolute and relative locktimes were per-input. Absolute locktimes (the per-transaction `nLockTime` field) suffer from the problem that one cannot specify both a height-based and a time-based one, which implies that two UTXOs which (through BIP65's `OP_CHECKLOCKTIMEVERIFY`) require distinct types of locktimes cannot be spent simultaneously in the same transaction.


---

### Answer by username_1 on 2023-01-11. Score: 6

I'm not sure if you will have already seen this:

> From: Satoshi Nakamoto <satoshin@gmx.com  
> Date: Wed, Mar 9, 2011 at 5:15 PM  
> To: Mike Hearn mike@plan99.net  
> Subject: Re: Open sourced my Java SPV impl
>
> [...]
>
> > I haven't fully
> > understood why sequence numbers are a property of the tx inputs rather
> > than the tx itself.
>
> It's for contracts. An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH\_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH\_NONE and bow out completely.
>
> The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP\_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.
>
> One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.

Quoted from <https://www.bitcoin.com/satoshi-archive/emails/mike-hearn/13/>  
Also seen at [https://plan99.net/~mike/satoshi-emails/thread4.html](https://plan99.net/%7Emike/satoshi-emails/thread4.html)

Mike Hearn replied

> Ah ha. A whole unexplored area of the system opens up before my eyes :-) The concept of forming distributed contracts and escrow transactions without needing to trust an intermediary is a concept nearly as novel as BitCoin itself, I think.

---

I believe the above explains Nakamoto's motivation for the choices initially made with respect to sequence and locktime. Or at least I believe Nakamoto believed it answered that specific question.

---

As I expect many people know, use of these data fields has subsequently been affected by adoption of ideas such as [BIP-68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and [forced closure of Lightning channels](https://bitcoin.stackexchange.com/q/115549/13866) etc.


---

