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 ( msg=tx code=nonstandard reason=non-BIP68-final hash=807d464fff227ce98cfb5f1292069e2793e99f21b0539a1729cc460af32add77.

RPC getpeerinfo:

    "id": 12,
    "addr": "",
    "addrlocal": "",
    "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

1 Answer 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.

  • 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
    Commented Oct 10, 2018 at 1:18
  • 1
    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
    Commented Apr 20, 2019 at 3:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.