<p>TL;DR: The aim is to discourage reorganizations and increase privacy. </p>

<p>In <a href="https://github.com/bitcoin/bitcoin/blob/fb0ac482eee761ec17ed2c11df11e054347a026d/src/wallet/wallet.cpp#L2133" rel="noreferrer">wallet.cpp, just above where nLockTime gets set</a>, it says:</p>

<pre><code>// Discourage fee sniping.
//
// For a large miner the value of the transactions in the best block and
// the mempool can exceed the cost of deliberately attempting to mine two
// blocks to orphan the current best block. By setting nLockTime such that
// only the next block can include the transaction, we discourage this
// practice as the height restricted and limited blocksize gives miners
// considering fee sniping fewer options for pulling off this attack.
//
// A simple way to think about this is from the wallet's point of view we
// always want the blockchain to move forward. By setting nLockTime this
// way we're basically making the statement that we only want this
// transaction to appear in the next block; we don't want to potentially
// encourage reorgs by allowing transactions to appear at lower heights
// than the next block in forks of the best chain.
//
// Of course, the subsidy is high enough, and transaction volume low
// enough, that fee sniping isn't a problem yet, but by implementing a fix
// now we ensure code won't be written that makes assumptions about
// nLockTime that preclude a fix later.

txNew.nLockTime = chainActive.Height();

// Secondly occasionally randomly pick a nLockTime even further back, so
// that transactions that are delayed after signing for whatever reason,
// e.g. high-latency mix networks and some CoinJoin implementations, have
// better privacy.

if (GetRandInt(10) == 0)
  txNew.nLockTime = std::max(0, (int)txNew.nLockTime - GetRandInt(100));
</code></pre>

<p>As Martin Habovštiak noticed, the sequence number is set to <code>MAX-1</code> for every input. It's in the code just <a href="https://github.com/bitcoin/bitcoin/blob/fb0ac482eee761ec17ed2c11df11e054347a026d/src/wallet/wallet.cpp#L2324" rel="noreferrer">below the previously mentioned code section</a>.</p>

CC BY-SA 3.0
2016-09-03T09:04:04.850Z
Seems like sequence is set to max()-1 for every input. The code is just [bellow of what you mentioned](https://github.com/bitcoin/bitcoin/blob/fb0ac482eee761ec17ed2c11df11e054347a026d/src/wallet/wallet.cpp#L2324) Thank you for your answer!
Martin Habovštiak
CC BY-SA 3.0
2016-09-09T05:53:21.927Z
Do you have a text version of the explanation? The code you posted is really unreadable on mobile, because you need to scroll to the right for every line
Ferrybig
CC BY-SA 3.0
2016-09-09T12:37:41.650Z
@Ferrybig: I've put the TL;DR at the top.
Murch
CC BY-SA 3.0
2017-11-07T08:10:52.780Z
is there a reason for that weird sequence number? the reasons stated in this answer only seem to explain the nLockTime, not the sequence number
knocte
CC BY-SA 3.0
2017-11-09T06:45:48.727Z
@knocte: `nLockTime` is only active if the sequence number is below `UINT_MAX`.
Murch
CC BY-SA 3.0
2016-09-03T08:10:00.030Z
2016-09-09T12:37:29.727Z
2016-09-09T12:37:29.727Z
Murch
<p>I've noticed recently that Bitcoin Core is producing transactions with non-zero lock-time and sequence numbers of inputs being 0xFFFFFFFE, even though I didn't instruct it to do so. The lock-time appears to be current block number.</p>

<ul>
<li>What is the reason for this behavior?</li>
<li>What is the algorithm for
setting sequence number?</li>
</ul>

<p>(I know that at least one input must have sequence number less than 0xFFFFFFFF. Does the Core set just first input or all inputs? I couldn't check this because I have no transaction with more than one input.)</p>

<p>Thank you for your answers!</p>

<bitcoin-core><locktime>
Why Bitcoin core creates time locked transactions by default?
Martin Habovštiak
# Why Bitcoin core creates time locked transactions by default?

(Asked by: username_0 on 2016-09-03)

I've noticed recently that Bitcoin Core is producing transactions with non-zero lock-time and sequence numbers of inputs being 0xFFFFFFFE, even though I didn't instruct it to do so. The lock-time appears to be current block number.

* What is the reason for this behavior?
* What is the algorithm for
  setting sequence number?

(I know that at least one input must have sequence number less than 0xFFFFFFFF. Does the Core set just first input or all inputs? I couldn't check this because I have no transaction with more than one input.)

Thank you for your answers!

**Tags:** bitcoin-core, locktime


---

## 1 answers

### Answer by username_1 on 2016-09-03. Score: 18 | Accepted answer

TL;DR: The aim is to discourage reorganizations and increase privacy.

In [wallet.cpp, just above where nLockTime gets set](https://github.com/bitcoin/bitcoin/blob/fb0ac482eee761ec17ed2c11df11e054347a026d/src/wallet/wallet.cpp#L2133), it says:

```
// Discourage fee sniping.
//
// For a large miner the value of the transactions in the best block and
// the mempool can exceed the cost of deliberately attempting to mine two
// blocks to orphan the current best block. By setting nLockTime such that
// only the next block can include the transaction, we discourage this
// practice as the height restricted and limited blocksize gives miners
// considering fee sniping fewer options for pulling off this attack.
//
// A simple way to think about this is from the wallet's point of view we
// always want the blockchain to move forward. By setting nLockTime this
// way we're basically making the statement that we only want this
// transaction to appear in the next block; we don't want to potentially
// encourage reorgs by allowing transactions to appear at lower heights
// than the next block in forks of the best chain.
//
// Of course, the subsidy is high enough, and transaction volume low
// enough, that fee sniping isn't a problem yet, but by implementing a fix
// now we ensure code won't be written that makes assumptions about
// nLockTime that preclude a fix later.

txNew.nLockTime = chainActive.Height();

// Secondly occasionally randomly pick a nLockTime even further back, so
// that transactions that are delayed after signing for whatever reason,
// e.g. high-latency mix networks and some CoinJoin implementations, have
// better privacy.

if (GetRandInt(10) == 0)
  txNew.nLockTime = std::max(0, (int)txNew.nLockTime - GetRandInt(100));

```

As username_0 username_0 noticed, the sequence number is set to `MAX-1` for every input. It's in the code just [below the previously mentioned code section](https://github.com/bitcoin/bitcoin/blob/fb0ac482eee761ec17ed2c11df11e054347a026d/src/wallet/wallet.cpp#L2324).

> **Comments:**
> **username_0**: Seems like sequence is set to max()-1 for every input. The code is just [bellow of what you mentioned](https://github.com/bitcoin/bitcoin/blob/fb0ac482eee761ec17ed2c11df11e054347a026d/src/wallet/wallet.cpp#L2324) Thank you for your answer!  
> **username_2**: Do you have a text version of the explanation? The code you posted is really unreadable on mobile, because you need to scroll to the right for every line  
> **username_1**: @username_2: I've put the TL;DR at the top.  
> **username_3**: is there a reason for that weird sequence number? the reasons stated in this answer only seem to explain the nLockTime, not the sequence number  
> **username_1**: @username_3: `nLockTime` is only active if the sequence number is below `UINT_MAX`.  

---

