Put locktime into FullTxOut

[rajarshimaitra]

Describe the enhancement
To calculate maturity for time-locked transactions, the lock time needs to be included in FullTxOut. #926 (comment)

This could be done in together with bitcoindevkit/bdk_wallet#156

Use case
Enchance maturity calculation.

[LLFourn]

Do you mean the lock time for the transaction that the output is on or do you mean time at which this output could be spent?

[rajarshimaitra]

Could be both. Either the locktime fields directly from the transaction the utxo is sitting in, or the final time/height at which it becomes "spendable".

Unlike coinbase, time-locked txs are in mempool. But unlike normal mempool utxos, which are spendable, we should not include them in coinselection. So they need to be filtered out via is_mature or some other function.

As in terms of what data to include. It can in-theory be both, the actual locktime fields from the transaction, or the final unlocking time/height. But both will need knowledge of confirmation heights somewhere to work out maturity.

My personal preference would be towards putting the final unlocking time/height in FullTxOut and handle the calculation in TXGraph::try_list_chain_txouts. In is_mature only check if the height <= tip.

Reasoning: it hides the complex part in TxGraph. Makes maturity function simple. Gives a clear understanding where confirmation height information fits best in TxGraph. makes FullTxOut simpler to interact with.

[rajarshimaitra]

Another idea:

Why not just put this final maturity time/height in TxGraph itself for each tracked utxos? For both coinbase and time locked transactions we can do this.

Benefits:

• This can be done at the sync time while inserting relevant txs in IndexedTXGraph.

• removes the need of storing confirmation heights in anchor.

• Clone the same field in FullTxOut and maturity is as simple as height <= tip.

I don't know which one is more complex or simpler. Doing this way is a burden on the user to do this right.

[rajarshimaitra]

As per this comment #951 (comment)

We can go with Idea 1. And put the final time/height of unlocking in FullTxOut.

I will make a draft implementation for it.

[rajarshimaitra]

Oh.. We also need to know the block-time from chainoracle at a given height to handle time-based locks. Also need the blocktime at confirmation height to handle time-based relative locks. How to do that?

We can punch in these data into Anchors. But is there any other plan for handling them?

cc: @evanlinjin

[rajarshimaitra]

I made some trials, and it seems we need the following: (More complex than I initially thought)

• ChainOracle to tell time given a height. This changes the details of LocalChain as well as the ChainOracle trait. We need to blocktime at tips to tell if something by nLocktime matured or not.

• A new Anchor that stores both confirmation height and time. Probably need a new trait too as the current Anchor don't return time.

• Ensure the previous TxNodeInternal is stored in the graph even if it's not "relevant". We need it for relative time-locks. But we need to do this in IndexedTxGraph::insert_relevant_tx() and the user needs to ensure they put the previous tx in the relevant txs list too.

Does this seem like a reasonable approach? Or else open for suggestion.

[LLFourn]

Could be both. Either the locktime fields directly from the transaction the utxo is sitting in, or the final time/height at which it becomes "spendable".

1. We don't always have the full transaction for an output in the graph. We could do a "best effort" locktime for both absolute and relative and put it here. I feel it's not very useful since txs that are not yet valid because of timelock are unlikely to be in the graph at all and so it feels weird to include this information on the txouts. It can be queried by querying the transaction. We could have a bool returning method to tell you whether a tx is valid with respect to lock times at the given height/time.
2. We don't know when am output becomes spendable because we don't necessarily have the descriptor. I think this kind of filtering needs to be done at another level.

[rajarshimaitra]

I agree that this can be done in another layer. Maybe at the wallet level.

While ensuring we include confirmation time for the input transaction too, while doing the sync. It doesn't have to be a full Tx. Could be the Partial Tx like we store in the TxGraph. But it would require another Anchor type with confirmation_time as a parameter.

[LLFourn]

I agree that this can be done in another layer. Maybe at the wallet level.

While ensuring we include confirmation time for the input transaction too, while doing the sync. It doesn't have to be a full Tx. Could be the Partial Tx like we store in the TxGraph. But it would require another Anchor type with confirmation_time as a parameter.

I meant that we can't know what the nlocktime field is of a partial transaction. Closing this for now. We'll have to deal with the concerns brought up here at some point but the tooling does not belong in FullTxOut since that it just some convenience type that we return in some places. Business logic doesn't belong on it I don't think.