fix: Fixed issue causing send transaction to get stuck after fee refactor #83
Conversation
andhikayuana
changed the title
|
Tyvm @andhikayuana ...checking |
| * Previous value: 2500L (2.5 satoshis per byte). From legacy minimum. default min is 1000 as Litecoin Core version v0.17.1 | ||
| * Updated to 8000L (8 satoshis per byte) on 2023-11-16 | ||
| */ | ||
| private const val defaultEconomyFeePerKB: Long = 8000L |
There was a problem hiding this comment.
From my recollection...the Android client was just pulling these numbers , but in iOS I was using the calculation so we (iOS) always had the right amount for network fees....my mind is a blur @andhikayuana
There was a problem hiding this comment.
My point is this might be all academic but reverting this to the pre (40% stuck) mode is the safer bet anyway.
|
@kcw-grunt please test with this core gruntsoftware/core#8 |
| final Context ctx = BrainwalletApp.getBreadContext(); | ||
| if (ctx != null) { | ||
| BRSharedPrefs.putScanRecommended(ctx, true); | ||
| TransactionDataSource.getInstance(ctx).deleteTxByHash(hash); |
There was a problem hiding this comment.
Neat code, nice @andhikayuana
I have question, why is the deleteTxByHash called here?
There was a problem hiding this comment.
Neat code, nice @andhikayuana
I have question, why is the deleteTxByHash called here?
Oh @josikie you are missing out on the 'fun' 😭
When we implemented live tx fees there was a miscalculation and some tx were send below the minimum 10 lits/byte to the network. So it needs to be deleted from wallet mempool so that is not sent out again.
Otherwise...users get stuck at 40% because that bad tx goes back and forth out to the network.
|
@kcw-grunt pls test with core from source branch from this PR gruntsoftware/core#10 |
|
We may or not revisit ass we needed to ship |
|
Closing |
Overview
Fixed issue causing send transaction to get stuck after fee refactor
Internal Issue
Tested on Emulator
Core
please test with this core gruntsoftware/core#8