smite: make funding and broadcast respect bitcoind default policy#137
Open
NishantBansal2003 wants to merge 4 commits into
Open
smite: make funding and broadcast respect bitcoind default policy#137NishantBansal2003 wants to merge 4 commits into
NishantBansal2003 wants to merge 4 commits into
Conversation
Prevent funding transactions from reusing the same inputs across multiple transaction constructions. Without this, independently built funding transactions can select overlapping UTXOs, causing later broadcasts to fail as non-fee-bumping RBF replacements or making signing fail once the shared inputs have already been spent. Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
The fuzzer may broadcast a transaction that is already confirmed. Its inputs are spent, so the wallet can no longer fully sign it. Check the confirmation count before signing and return early when the transaction is already on-chain. Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
Pass a maxfeerate of 0 to bitcoin-cli sendrawtransaction so broadcasts are accepted at any fee rate, bypassing the default high-feerate safety cap. Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
Reject funding transactions that would not be accepted under Bitcoin's default relay policy. Funding construction now fails for feerates below the minimum relay feerate and funding outputs below the dust threshold, avoiding transactions that cannot be relayed or mined by default. Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There were a couple of crashes while I was running the funding-flow generator, where we were getting panics in smite because of the restrictive assert statements we have set. These commits fix those issues in smite.
So now we can’t create two transactions with overlapping inputs. We return early when signing or broadcasting a transaction if it has already been broadcast and confirmed, since the wallet can’t sign a transaction whose inputs have already been spent. There were also a couple of crashes around broadcasting, where either
funding_satoshisitself was below the dust limit, or the feerate used to calculate the transaction fee was too low compared tobitcoinddefault policy. So now we reject those inputs as well.These cases do not really contribute to fuzzing, because in practice, if
bitcoinddefault policy rejects them, Lightning nodes should also reject thoseopen_channelmessages before sendingaccept_channel. But let’s say they are not rejected, then I think those cases can be caught once we add theopen_channelandaccept_channeloracle. So in either case, we don’t need to relaxbitcoinddefault policy to exercise the full funding flow