Mainstream UTXO wallets set (memoless Savers deposit) LockTime to the current block by default, but THORChain ignores any LockTime greater than 0
Copying from this Discord discussion:
https://coinguides.org/bitcoin-lock-time/
"Bitcoin core, electrum and most other Bitcoin wallets will have lock_time set to current block height by default."
[Edit: Bitcoin Core and Electrum relevant code here and here.]
In the cases I've seen the LockTime was earlier than the transaction's block
(and by that default setting couldn't be later than its block unless there was a reorg?),
so in theory didn't limit the spendability in any way,
but a user following the instructions at
https://dev.thorchain.org/thorchain-dev/saving-guide/quickstart-guide#3.-send-memoless-savers-transactions
(which doesn't mention LockTime I believe)
will find that after following the instructions their coins are gone and they have no Savers position.
func (c *Client) getTxIn(tx *btcjson.TxRawResult, height int64, isMemPool bool) (types.TxInItem, error) {
if c.ignoreTx(tx) {
c.logger.Debug().Int64("height", height).Str("tx", tx.Hash).Msg("ignore tx not matching format")
return types.TxInItem{}, nil
}
func (c *Client) ignoreTx(tx *btcjson.TxRawResult) bool {
if len(tx.Vin) == 0 || len(tx.Vout) == 0 || len(tx.Vout) > 4 {
return true
}
if tx.LockTime > 0 {
return true
}
Below in that discussion, I propose that
"Bifrost code be changed to have ignoreTx
take height as an argument and check if tx.LockTime > height
instead,
so only ignoring future-timelocked transactions."
As further context, LockTime can also be used to specify a date rather than a height.
However, my current impression is that this is specified with a threshold,
such that a date will always be a number greater than the current block height
(and so the condition tx.LockTime > height
will still exclude dates).
Edit:
For tx.LockTime
uint32 type and height
int64 type,
tx.LockTime > uint32(height)
condition.
Please tell me if there is a reason to prefer int64(tx.LockTime) > height
.