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
wallet: respect policy-level transaction size limits when crafting regular and funding transactions #4760
Comments
Actually, reading the |
Just want to get some feedback re the scope of this before diving any deeper: seems to me there are 2 issues here with ranging scopes:
This would involve some changes to the ChannelReservation logic to ensure that the funding tx it builds is below a certain size (would need to fetch that size somewhere) and to then retry with different coins if size is too big. ie, this becomes a coin selection issue.
This is a lot trickier than problem 1 since with this, we have already sent our tx out into the wild and cant ever be 100% sure that it has not actually broadcast. Not entirely sure what the fix for this should be... yes we can examine the returned errors but i dont think we can assume the errors are trustworthy enough to release the inputs and forget the channel. Are the above assumptions correct? And if so, should the scope of the fix for this issue address both? (any thoughts would be much appreciated @yyforyongyu , @Roasbeef @ & @Crypt-iQ (saw that you posted some thoughts on the linked PR)) |
Fixing both at once sounds good (could split up into 2 pr's)
2a & 2b could be combined so that 2b falls back to 2a after some time. |
I don't think this is something we want to deal here. We use the interface Basically we rely on this interface here, and it must do what it guarantees. Otherwise we'd have an issue not just in funding, but every call site of this interface in As for the scope, I think this issue deals specifically with the error
|
I believe elle is referring to the case where we send a transaction and we receive a malicious MsgReject in neutrino. Or another scenario like maybe we're eclipsed and have sent it out, but it hasn't propagated. This neutrino case should definitely be fixed in addition to the PR that fixes this issue.
I still think having some API that calls PublishTransaction and continues to do so until some block-timeout would be useful.
This is what a testmempoolaccept api could pre-emptively handle. This is already something that we need as having one would have caught the high-S signatures CVE. I do think though that a minimum fix would be something along the lines of your original PR, but we'd want to catch more than just tx-size since there are other policy checks that can fail besides size. As an example, an error that is returned that is not policy and wouldn't be caught if we'd only catch tx-size is mempool min fee not met. If all non-double-spend errors are caught, however, I think it would be a good idea on error to wait until the input is double-spent or the channel is confirmed on chain (either we missed something or the user took their raw tx and broadcast it elsewhere) before cleaning up as a safety measure in case something was missed. |
@Crypt-iQ If we want to handle more than tx-size error, it'd be nice but another story. This
If this happens it's nice to handle it but not necessary or urgent IMO. Meanwhile, curious why would a user do that? |
Users pretty much do anything and everything given some large timeframe. I was thinking this would happen using the psbt api. |
Seeing this in #6566 but odd in that if you go to my last linked comment there, in the code we should always remove the transaction on startup when/if we go to rebroadcast it, but also the very first time we go to broadcast it (unless that fails for some reason). |
…ore broadcast In this commit, we start to use the `CheckTransactionStandard` function from the `mempool` package to validate transactions further before broadcast. This'll help catch instances where we make a massive transaction, and therefor can't actually propagate it across the network. Fixes lightningnetwork#4760 Fixes lightningnetwork#6556
…ore broadcast In this commit, we start to use the `CheckTransactionStandard` function from the `mempool` package to validate transactions further before broadcast. This'll help catch instances where we make a massive transaction, and therefor can't actually propagate it across the network. Fixes lightningnetwork#4760 Fixes lightningnetwork#6556
Tracking this here instead of the
btcwallet
issue for more visibility. As is, we don't always ensure that a transaction either we construct manually (for funding) or withinbtcwallet
itself is below the current widely used policy that constraints transaction sizes. Thankfully, we can simply start using the existing policy level function withinbtcd
itself to enforce these limits: https://github.com/btcsuite/btcd/blob/master/mempool/policy.go#L271When a user encounters this issue, they'll see this in the logs:
And then end up with a dangling transaction that'll keep being rebroadcast, when instead we should remove it from the tx store.
The text was updated successfully, but these errors were encountered: