-
Notifications
You must be signed in to change notification settings - Fork 93
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
Funding transactions created in quick succession attempt to spend the same output #477
Comments
After some testing, I think the solution is to immediately trigger a BDK sync after the transaction is broadcasted, so BDK picks up the broadcasted tx from the mempool and marks the output as currently being spent. The next time a funding transaction is generated, BDK will correctly use another output. This applies in general - we should always resync whenever any transaction is broadcasted, whether it comes from LDK's |
If there's an API to tell BDK that a particular transaction has been accepted into the mempool, we can avoid the overhead of doing an actual sync. I asked about it here. Update: Will get around to trying to tomorrow, but I think we can set |
Yes, this has been a known issue for years at this point, see my feature request here: bitcoindevkit/bdk#849 Unfortunately it got pushed back and back again, and is still pending a resolution on BDK's end.
Hmm, I haven't closely looked at the BDK-internal code regarding this exact approach, but previous discussions concluded that there currently is no way you could 'unlock' the locked UTXOs again. This means that at the very least might need to keep track of which UTXOs you locked and then explicitly double-spend them again if the transaction never ends up confirming. I'm of the opinion that all of this tracking is really the concern of the onchain wallet itself, and hence should be handled by BDK internally. |
Hiya, I've noticed an odd behavior in our logs during JIT channel opens. When JIT channel opens are triggered in quick succession, multiple funding transactions are broadcast that try to spend the same outpoint. Naturally, only the first broadcast succeeds, and subsequent ones are rejected by the mempool. I looked over to ldk-node to see how it handles
FundingGenerationReady
and ldk-node has almost the exact same behavior as us, so I figured ldk-node probably has this problem too. It seems likely that this problem may even apply to BDK sends in general. At this point I'm not sure if this should be fixed on the BDK side or via external tracking or syncing in LDK node; just wanted to start a discussion.Here are some sample test logs from us. Note how the last three groups of logs (each corresponding to a JIT channel open) all attempt to spend the same txout
f7a25f4f4eee9ee1da0972076bfbf83e61b2ca589e4e591abb9e070e868d1129:0
, with only the first broadcast succeeding.The text was updated successfully, but these errors were encountered: