<p>First of all, the Bitcoin network does not have a time granularity of minutes. At best, you can expect things to be within hours of what you want the time to be. So timelocking something for 10 minutes is useless and not very helpful as the "network time" updates only every 10 minutes. The time that you set does not correspond to real time, it corresponds to "network time" which is nowhere near real time.</p>

<p>The "network time" is the median time stamp of the last 11 blocks which will generally be an hour or so behind real time. But it is based on the block timestamps so it does not increase at a fixed increment nor is it a consistent amount of time behind. Combined with the fact that blocks are not found on a consistent timing, the "network time" has a granularity of a few hours at best.</p>

<p>So your transaction has a locktime of 10 minutes in the future from real time. But for network time, that's at least an hour, probably an hour and a half, before "network time" catches up to your transaction's locktime. So your transaction will remain non-final until that time.</p>

CC BY-SA 4.0
2019-04-20T03:29:56.283Z
They almost certainly didn't, why do you think they did?   re time, I think you are not understanding achow's response.   "Time" for the purpose of locktime is block MTP based... relative or not.
G. Maxwell
CC BY-SA 4.0
2018-10-10T01:18:16.150Z
Thanks, in my script I set the CSV locktime to 1 "unit" in time mode (not blocks), defined as 512 seconds by BIP68, and did not send the redeeming tx until 20 minutes had passed since the CONFIRMATION of the funding tx. This is a relative time-lock so even if wall-clock-time and network mean time are wildly divergent, I thought the relativity would still work. On testnet, there was something like 20 blocks in the following 15 minutes :-) so again, I expected the MTP to be sufficient. Perhaps the better question is, why did some of my peers ACCEPT this tx?
pinhead
CC BY-SA 4.0
2018-10-10T00:57:03.277Z
2018-10-10T00:57:03.277Z
Ava Chow
<p>The CSV-redeeming TX I broadcast: <a href="https://www.blocktrail.com/tBTC/tx/807d464fff227ce98cfb5f1292069e2793e99f21b0539a1729cc460af32add77" rel="nofollow noreferrer">https://www.blocktrail.com/tBTC/tx/807d464fff227ce98cfb5f1292069e2793e99f21b0539a1729cc460af32add77</a></p>

<p>The locktime was set for ten minutes, and the redeeming tx (linked above) was broadcast after twenty minutes.</p>

<p>I have 8 peers and 4-5 reject CSV txs every time for <code>reason=non-BIP68-final</code> Here's one example...</p>

<p>Log messages (running bcoin):</p>

<pre><code>[W:2018-10-09T22:43:03Z] (net) Received reject (52.62.75.209:18333): msg=tx code=nonstandard reason=non-BIP68-final hash=807d464fff227ce98cfb5f1292069e2793e99f21b0539a1729cc460af32add77.
</code></pre>

<p>RPC getpeerinfo:</p>

<pre><code>  {
    "id": 12,
    "addr": "52.62.75.209:18333",
    "addrlocal": "18.191.117.102:57474",
    "name": "ec2-52-62-75-209.ap-southeast-2.compute.amazonaws.com",
    "services": "0000040d",
    "relaytxes": true,
    "lastsend": 1539125540,
    "lastrecv": 1539125540,
    "bytessent": 445546,
    "bytesrecv": 465329,
    "conntime": 13977,
    "timeoffset": 0,
    "pingtime": 0.195,
    "minping": 0.194,
    "version": 70015,
    "subver": "/Satoshi:0.16.2/",
    "inbound": false,
    "startingheight": 1414448,
    "besthash": "00000000210004840364b52bc5e455d888f164e4264a4fec06a514b67e9d5722",
    "bestheight": 1414433,
    "banscore": 0,
    "inflight": [],
    "whitelisted": false
  },
</code></pre>

<p>The peer is running updated software and besides CSV has been locked in forever</p>

<peers><checksequenceverify>
Why are some of my peers rejecting this CSV transaction?
pinhead
# Why are some of my peers rejecting this CSV transaction?

(Asked by: username_0 on 2018-10-09)

The CSV-redeeming TX I broadcast: <https://www.blocktrail.com/tBTC/tx/807d464fff227ce98cfb5f1292069e2793e99f21b0539a1729cc460af32add77>

The locktime was set for ten minutes, and the redeeming tx (linked above) was broadcast after twenty minutes.

I have 8 peers and 4-5 reject CSV txs every time for `reason=non-BIP68-final` Here's one example...

Log messages (running bcoin):

```
[W:2018-10-09T22:43:03Z] (net) Received reject (52.62.75.209:18333): msg=tx code=nonstandard reason=non-BIP68-final hash=807d464fff227ce98cfb5f1292069e2793e99f21b0539a1729cc460af32add77.

```

RPC getpeerinfo:

```
  {
    "id": 12,
    "addr": "52.62.75.209:18333",
    "addrlocal": "18.191.117.102:57474",
    "name": "ec2-52-62-75-209.ap-southeast-2.compute.amazonaws.com",
    "services": "0000040d",
    "relaytxes": true,
    "lastsend": 1539125540,
    "lastrecv": 1539125540,
    "bytessent": 445546,
    "bytesrecv": 465329,
    "conntime": 13977,
    "timeoffset": 0,
    "pingtime": 0.195,
    "minping": 0.194,
    "version": 70015,
    "subver": "/Satoshi:0.16.2/",
    "inbound": false,
    "startingheight": 1414448,
    "besthash": "00000000210004840364b52bc5e455d888f164e4264a4fec06a514b67e9d5722",
    "bestheight": 1414433,
    "banscore": 0,
    "inflight": [],
    "whitelisted": false
  },

```

The peer is running updated software and besides CSV has been locked in forever

**Tags:** peers, checksequenceverify


---

## 1 answers

### Answer by username_1 on 2018-10-10. Score: 1

First of all, the Bitcoin network does not have a time granularity of minutes. At best, you can expect things to be within hours of what you want the time to be. So timelocking something for 10 minutes is useless and not very helpful as the "network time" updates only every 10 minutes. The time that you set does not correspond to real time, it corresponds to "network time" which is nowhere near real time.

The "network time" is the median time stamp of the last 11 blocks which will generally be an hour or so behind real time. But it is based on the block timestamps so it does not increase at a fixed increment nor is it a consistent amount of time behind. Combined with the fact that blocks are not found on a consistent timing, the "network time" has a granularity of a few hours at best.

So your transaction has a locktime of 10 minutes in the future from real time. But for network time, that's at least an hour, probably an hour and a half, before "network time" catches up to your transaction's locktime. So your transaction will remain non-final until that time.

> **Comments:**
> **username_0**: Thanks, in my script I set the CSV locktime to 1 "unit" in time mode (not blocks), defined as 512 seconds by BIP68, and did not send the redeeming tx until 20 minutes had passed since the CONFIRMATION of the funding tx. This is a relative time-lock so even if wall-clock-time and network mean time are wildly divergent, I thought the relativity would still work. On testnet, there was something like 20 blocks in the following 15 minutes :-) so again, I expected the MTP to be sufficient. Perhaps the better question is, why did some of my peers ACCEPT this tx?  
> **username_2**: They almost certainly didn't, why do you think they did?   re time, I think you are not understanding achow's response.   "Time" for the purpose of locktime is block MTP based... relative or not.  

---

