Why are some of my peers rejecting this CSV transaction?

0

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

pinhead

Posted 2018-10-09T23:12:21.860

Reputation: 2 356

Answers

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.

Andrew Chow

Posted 2018-10-09T23:12:21.860

Reputation: 40 910

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 – 2018-10-10T01:18:16.150

1They 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 – 2019-04-20T03:29:56.283

Asked: 2018-10-09T23:12:21.860

Viewed: 85 times

Active: 2019-04-19T22:01:50.340