Quick Community Ask
I need community help testing which BCH wallets/services set transaction locktime to the current block height. If a wallet continues setting nLockTime to current height, it will break when we activate faster blocks (CHIP-2025-03). Wallets that set it to 0 will be unaffected. To mitigate, we first need a list of wallets and their behavior.
How to test:
- Send a small transaction with the wallet or service you want to check.
- Open the TXID on bchexplorer.cash and look at “Locktime” under Details.
- Report the wallet or service name and whether Locktime = 0 or equals the current block height (or something else).
Report by replying to this post with something like Wallet: MyWallet; nLockTime: 0;.
Here’s a start:
| Wallet | nLockTime |
|---|---|
| Electron Cash | height |
| BCHN | height |
| Cashonize | 0 |
| Selene | 0 |
| … | … |
Background: Because of Peter Todd’s anti‑fee‑sniping patch, some wallets set nLocktime = tip_height . Our faster‑blocks upgrade normalizes locktime to 10‑minute ticks, so those transactions would only become valid many blocks later than expected (they’d be locked far into the future). Changing the default to 0 before activation prevents breakage. Wallets like Cashonize and Selene already do this; Electron Cash and BCHN do not.
The nLocktime = tip_height default was supposed to guard against hypothetical fee sniping issues but really this is anti-user: why should a user care if his TX gets into an earlier block? There was no analysis done about which conditions could even result in these scenarios. If it’s still a concern, forward-compatible way is to set it to MTP, but just setting it to 0 is simpler, and many wallets already do exactly that.