-
Notifications
You must be signed in to change notification settings - Fork 322
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
Transactions inserted with Wallet::insert_tx
will be replaced by the wallet when creating a new tx.
#1642
Comments
Yeah nothing missing. Few short points
|
It's intended to be an external API. We didn't consider the tx-replacing problem though. Also our wallet examples are too basic to require it. I.e. relying on syncing with the chain source was good enough for them.
The |
Also brought this up on Discord, but I'm also confused by this. What is the intended purpose of |
Basically if the transaction is only inserted it's in the "unbroadcasted" state. Concretely the wallet could show in its list of transactions "failed to broadcast" with a button to retry the broadcast. Unconfirmed txs have been broadcast and are therefore unconfirmed. There is no such thing as "invalid data" in this context (there is certainly useless data). Like @evanlinjin suggest having the optional The more broad solution is to implement UTXO reservation/locking feature. Here are prev discussions:
The main question is whether to persist these "locks" which enlarges the scope of the feature. But by the sounds of it @tnull and @DanGould want this which is enough to say it should exist. The main challenge with persisting reservations is that naively they are not monotone (the locks can be turned off and turned on again). A way around this is to add a lock like |
I can see how this can be useful, and I like your proposed implementation of how to make UTXO-lock changesets monotone. However, I do NOT think UTXO-locking is a fit-for-all solution as it is locking up available funds. I.e. some users would like to use funds from unbroadcasted transactions as well. My Proposed Solution (in addition to UTXO locking)I want to modify how calculating the canonical history & utxo set works.
This allows the wallet to pick UTXOs from unbroadcasted txs. This also implements part of the logic required to replace a tx with children. |
I'm not sure exactly how locking / persisting locks / spending unbroadcasted utxos should work, but I can reiterate the constraints that caused me to raise this issue. In summary, Payjoin receivers must track 2 transactions spending the same foreign input: the original psbt containing only sender inputs, which the sender or receiver may broadcast at any time, and a payjoin psbt containing both sender and receiver inputs which a receiver must wait for the sender to sign and broadcast. My understanding of the BDK wallet design is limited, but If I were deep in this problem, I might contact those from the Bitcoin Core wallet / mempool teams (Murch, Ava, and Gloria come to mind) since they have recorded opinions in PR decisions with historical context to the constraints of that project. Perhaps BDK has different constraints, and at the same time, could be informed by the decision making process of Core's constraints. I believe that Core landed on in-memory UTXO locking long ago. Figuring out why that decision was made, and the problems that come up now with that presumably old design would inform my decision for a design in the relatively greenfield design space that is BDK. edit: optional lock persistence was merged in 2021 |
So those commits fix the issue described in the title however there is a more fundamental issue mentioned by @stevenroose:
In the current state of affairs this still happens by default. I think that having a concept of "unbroadcasted transactions" stored in the wallet which will reserve the inputs for use by that transaction before it is broadcast would solve this. This would involve inserting it into the tx graph as soon as its created and marking it us unbroadcasted. We could persist the designation too as a separate thing as part of the wallet changeset. This doesn't solve @DanGould's problem at the wallet level but I think that the improvements to |
The headline issue has been fixed. Can we continue the discussion on related issue of locking unbroadcast spent utxos in new or exist issues? ie #1669 |
Sure I made an new issue: #1748 |
Describe the bug
When a caller manually inserts a transaction into wallet via
Wallet::insert_tx
, it is an intuitive assumption that the transaction inserted will not be replaced by a new transaction created withWallet::build_tx
.However, the current default behavior of
Wallet::build_tx
replaces the transaction inserted withWallet::insert_tx
since purely inserting a transaction without alast_seen
orAnchor
to the best chain means that the tx will not be part of the canonical chain.Thank you @stevenroose for bringing this to my attention. Am I missing anything here?
To Reproduce
Some simple steps for reproducing.
T1
) from that wallet and send to foreign address A.T1
into the wallet viaWallet::insert_tx
.T2
) that sends to foreign address B.Proposed solutions
insert_tx
:last_seen: Option<u64>
, and document that we need the last_seen value in order for the tx to be seen in the canonical chain.I think
1.
should be the solution for now.2.
will need more thinking.The text was updated successfully, but these errors were encountered: