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

Don't double spend created transaction just because they haven't been broadcasted #1748

Open
LLFourn opened this issue Nov 27, 2024 · 0 comments
Labels
module-blockchain new feature New feature or request

Comments

@LLFourn
Copy link
Contributor

LLFourn commented Nov 27, 2024

This was a comment from a discussion elsewhere. I don't want to restrict the design space too much but I personally think the right way to deal with this is:

  1. Insert the transactions into the tx graph right after they are created (without signatures)
  2. Mark the txid as "unbroadcasted" at the tx graph level or application level
  3. Assume it's canonical whenever you do canonicalization
  4. Once it's signed, add the signatures to the tx graph. This can be done by re-inserting the transaction and adding it to the changeset with the new signatures.
  5. When it gets a last_seen remove it from the unbraodcasted state.

I think in (2) it probably should be done inside the tx graph. #1147 should be done first.


The user has to decide the fate of their transactions. And I claim each unconfirmed tx is either in a state of:

  1. The user has not broadcasted it (maybe it's still being signed) and wants to confirm it eventually
  2. It's broadcasted and the user still wants it to be confirmed
  3. It's broadcasted but the user wants to replace it
  4. It's not broadcasted and the user no longer wants to broadcast it.

We have to consider the state when creating a new tx: in (1,2) we want to treat the tx as canonical regardless of whether it has been seen in the mempool recently or not and therefore it's UTXOs can be candidate inputs. In (2), if it hasn't been seen for a while this will mean we want the user to broadcast it again along with the new child tx.
In state (3) the application has to treat it as non-canonical and double spend it with the replacing tx. In state (4) it's just non-canonical and remains that way.

I don't think there is a fifth state we have to model where the user is thinking "I broadcasted this tx but you know I don't really care if it gets confirmed. If it hasn't been seen for a while I kinda want to prune it so I might inadvertently double spend it with my next tx...or I might not..whatever".

There are several ways in which these four tx states are not modeled correctly in BDK so there definitely is a design bug but it seems we are not in agreement to the nature of it. I think states (2) and (4) are easy to express, YMWV with (3) and (1) doesn't exist.

Originally posted by @LLFourn in #1666 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module-blockchain new feature New feature or request
Projects
Status: Discussion
Development

No branches or pull requests

2 participants