craigraw
commented
7 months ago Near duplicate of #1264, since the same considerations apply. If Sparrow maintains state independently from the server it is connected to, it will need to ultimately resolve that state when conflicts occur, leading to a requirement to replicate consensus code in the application. Fwiw I already spent 2 weeks last year trying to implement this, only to reach this conclusion.
For a number of reasons the correct way to implement this is on the server (Bitcoin Core) side.
AndySchroder
In https://github.com/sparrowwallet/sparrow/issues/847 I was concerned about having the ability to re-broadcast transactions without doing a RBF or CPFP in case the rest of the network forgot about it, even after the mempool cleared out. From my experience, it seems as though for right now it is reasonable to think a few big nodes out there will remember the transaction and then it probably get mined once the mempool clears out. This is not guaranteed to be the case forever though.
In https://github.com/sparrowwallet/sparrow/issues/1264 there is a discussion about having sparrow try and later re-broadcast transactions that are currently rejected from the mempool and never enter it.
This new issue is mainly about transactions that have made it to the mempool, but have been evicted to the mempool that one later wants to boost the fee to get it back into the mempool. There are two scenarios that we have a problem and can't do that:
(1) User is sending, they scan a QR code, set the fee, create a transaction, sign it, broadcast it. It reaches the mempool of other nodes, but it doesn't get mined for a while. They decide they want to do a replace by fee. However, the transaction has disappeared from sparrow because it has now been evicted from the mempool. They don't want to create a new transaction because they don't want to accidentally pick some different UTXO to use and they also forgot the receiving address because they no longer have the QR code to scan. Since sparrow has forgotten the transaction, it can't be referenced to avoid both of these issues.
(2) The second case is the user is receiving funds and wants to do a child pays for parent. If the transaction has disappeared from sparrow, there is no way to do that.
Both of these scenarios happen even if sparrow stays open the entire time and is never closed. I think sparrow should not forget transactions while it is open and save transactions when sparrow is closed. Let's call this the "wallet mempool". Of course if a received transaction enters and leaves the mempool when sparrow is closed, there is no way for us to know about it, but if sparrow sees it, it should not forget it.
In this case with a "wallet mempool" caching our wallet's transactions and showing them in the transaction list, we should still be able to do a RBF or CPFP if needed.
As a workaround to https://github.com/sparrowwallet/sparrow/issues/1264 , I suggest any sending transactions that are broadcast are first sent to the "wallet mempool" so that they show up in our transaction list and then attempted to be broadcast to the electrum server.
When sending in https://f-droid.org/en/packages/de.schildbach.wallet/ , that wallet keeps track of whether it hears back about the transaction from the mempool of its peers, that way we know the transaction was successfully broadcast to someone. It would be nice if sparrow did the same thing. Then add an indicator/icon in the transaction list to say if unconfirmed transaction was ever propagated successfully.
Next, allow right clicking on an unconfirmed transaction and attempt to re-broadcast it (whether it was already successfully broadcast or never successfully broadcast). This will provide a manual fix to both https://github.com/sparrowwallet/sparrow/issues/847 and https://github.com/sparrowwallet/sparrow/issues/1264 .
If one sees the indicator/icon that shows that the transaction did initially broadcast successfully, the user may defer to not manually re-broadcast a transaction unless it has set there for a very long time and they see it should definitely fit in the mempool but isn't there for some reason. However, if they see the transaction never broadcast, the next time they open sparrow, they might want to try again because they know the fee markets have shifted and it might not be rejected from the electrum server this time.