Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[chain] last_seen_unconfirmed should have a default of None not 0 #1396

Open
LLFourn opened this issue Apr 3, 2024 · 4 comments · May be fixed by #1416
Open

[chain] last_seen_unconfirmed should have a default of None not 0 #1396

LLFourn opened this issue Apr 3, 2024 · 4 comments · May be fixed by #1416
Assignees
Labels
api A breaking API change module-blockchain
Milestone

Comments

@LLFourn
Copy link
Contributor

LLFourn commented Apr 3, 2024

Current implementation of TxGraph insert_tx is:

    /// Inserts the given transaction into [`TxGraph`].
    ///
    /// The [`ChangeSet`] returned will be empty if `tx` already exists.
    pub fn insert_tx(&mut self, tx: Transaction) -> ChangeSet<A> {
        let mut update = Self::default();
        update.txs.insert(
            tx.txid(),
            (TxNodeInternal::Whole(tx.into()), BTreeSet::new(), 0),
        );
        self.apply_update(update)
    }

The 0 in the tuple represents the last time the transaction has been seen unconfirmed. I think it is wrong to set 0 here because you should be able to insert transactions into the graph (or wallet) that have never been broadcast and have never been seen. When you list canonical transactions1 you don't want to list transactions that have been inserted but never actually seen. In other words the field should be an Option which is still monotonically increasing with None being the smallest value.

I don't think this change affects the changeset struct, it just changes how you interpret a missing last_seen.

Footnotes

  1. Incidentally we should rename try_list_chain_txs to canonincal_transactions

@notmandatory notmandatory added api A breaking API change module-blockchain labels Apr 3, 2024
@notmandatory notmandatory added this to the 1.0.0-alpha milestone Apr 3, 2024
@DanGould
Copy link

DanGould commented Apr 4, 2024

What is the exact distinction between None and 0? The assumption that the tx has been seen by the outside world? I understand this as making the fuzzy line fiction between "the mempool" and "my mempool" a concrete distinction.

@LLFourn
Copy link
Contributor Author

LLFourn commented Apr 4, 2024

None would be in no ones mempool (not even yours). You can have a transaction that is valid but has never left application memory. But I realized after writing this we don't have a way of inserting a transaction into Wallet that would have a last_seen of None. The api forces you to specify either confirmed or unconfirmed with last_seen.

Maybe the reason we didn't do an Option in the first place is that we didn't have motivation for inserting these kinds of transactions into the graph. I think the motivation is to be able to store and analyze a transaction chain in the context of the graph without yet broadcasting it.

@ValuedMammal ValuedMammal changed the title [chain] last_seen_unconfirmed should not have a default of None not 0 [chain] last_seen_unconfirmed should have a default of None not 0 Apr 26, 2024
@ValuedMammal ValuedMammal linked a pull request Apr 30, 2024 that will close this issue
7 tasks
@ValuedMammal ValuedMammal self-assigned this May 1, 2024
@ValuedMammal
Copy link
Contributor

Assuming we treat a last_seen of 0 as effectively None, could this be fixed by just filtering list_chain_txs to exclude those that have no anchors and a last_seen of 0, or is there an extra advantage to making last_seen an Option ?

@LLFourn
Copy link
Contributor Author

LLFourn commented May 6, 2024

Indeed an alternative proposal is to treat 0 as a magic value. But this means that two states have the same semantics (when the last_seen is 0 and when it doesn't exist). It's better not to have this ambiguity and just have explicit None for no last seen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api A breaking API change module-blockchain
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

4 participants