something is going wrong with dates on transaction history, especially older ones, it doesn’t display the correct date for some, contacted support but I don’t feel comfortable sending address details etc
boost doesn’t seem to work efficiently, I have to readjust it multiple times for it to include enough sats to have the transaction picked up quickly instead of doing it from the first go
Hi @Panicseller, thank you for the suggestions! Replying bullet by bullet:
Envoy should already have the option to change fiat value. Under Settings, enable Fiat, and you should see a dropdown underneath with a selector. However, we are aware of an existing bug affecting some iOS users, and are planning on releasing a new version tomorrow to the stores that should address this bug. Please do let us know if this release fixes the issue for you!
It’s understandable not wanting to share screenshots, don’t worry about that. However, any clue you can provide should be helpful in narrowing it down. Is the delay between the expected date vs displayed date off by a lot? Is the displayed date always later than the expected date? What I think might be happening here, though it’s hard to confirm if it’s your case or not, is that we did change the date we display at around the time we released Envoy version 1.8.0. Up until then, we showed the timestamp in which the transaction was mined. So if you broadcasted a transaction on a Monday, but due to mempool congestion the transaction was mined that Friday, the date we would show was Friday. However, we updated that logic and after 1.8.0 we realized it made more sense to display the date when the transaction first hit the mempool, instead of the date where the tx confirmed. This would explain why you can find this offset bewteen expected and displayed dates on older transactions but not in new ones. Please let us know if this can explain it! If for whatever reason it doesn’t, any context you can add to the issue would be extremely helpful to try and catch the bug. Thank you!
Boost works the same way as a regular transaction in terms of sats/vbyte selection. When tapping Boost, you will get to the transaction review screen. In this screen you can adjust the fees just like in a regular transaction, see the area highlighted in red below. Here Standard is selected by default, which is typically an ok amount, but might not get you in the next block. If you want it faster, you can tap the Faster tab, and if you are an advanced user you can head to the Custom tab and select a sats/vbyte amount you think should be good enough to make it to the next block. The only restriction here is that you can’t apply a feerate below the original one (you can see this by tapping Custom then scrolling all the way to the left, you will see the smallest number is not 1, but whatever you selected for the original transaction +1). This way, you can decide what feerate to apply to your transaction the first time you boost it, and don’t have to do multiple boost rounds to achieve the desired feerate. Hope this helps!
Yes it’s iOS and I remember it being available and then disappearing, but you say the fix is already in place which is great.
So I have a very predictable pattern for the incoming, two transactions per address. A smaller one as test and a big one after the test hit successfully (same exact address). I have envoy way off on dates on the test transaction and the bigger one, they are always made on the exact same day and address but it seems to assign dates of other transactions or mix them up. It only shows incorrect on Envoy, I have moved this wallet a couple of times and the transactions were always dated correctly. I noticed it when consolidating the tests with the final ones.
So whats the difference between faster and boosted? May I suggest that you just include it on that menu you highlighted? So we have standard, faster and fastest/instant or something similar? It would be more intuitive if you ask me but of course this is personal preference.
Edit: I misread your comment regarding boosting, the idea would be to ask the user before sending if he wants to use standard or faster, fastest instead of having him adjust it afterwards through boosting.
Thanks for the extra info here @Panicseller, very useful.
We haven’t done as much QA testing around reusing the same address multiple times, so perhaps that could be something we explore. Would you mind sharing roughly how recent an example you can find of the dates being completely wrong? No need to be too specific, just ‘within the last N months’.
‘Faster’ is a fee setting that aims to get the transaction confirmed within the next block.
‘Standard’ is a fee setting that aims to get the transaction confirmed in ~1hr
You adjust between these two settings, and ‘Custom’ as @Jack mentioned earlier, before sending any transaction. When any changes to the fee selection are made, the estimated time to confirmation seen just below the fee selection, will update.
‘Boosting’ is for when you have a transaction stuck in the mempool and would like to attempt to speed up the confirmation time. Under the hood what’s actually happening is that ‘Transaction A’ is being replaced by a very similar ‘Transaction B’, that pays the exact same recipient, but with a higher fee.
No problem, would love to see this figured out. Earliest I see this happening is 9 months ago. i have a date difference between test and final transaction of nearly two months, while I am confident it’s the same day as always. There are more misdated transactions going back further.
So i narrowed it down. The the more recent transactions don’t have this issue, these were all made with envoy and passport so maybe that explains it. The incorrect dates all come from transactions before moving to passport/envoy. So I think it’s more of an issue when importing an existing seed.
Thanks for clarifying, I did understand it but I found it a bit confusing. Too many options; standard, fast, custom and then boost.
Ah yes thank you for the followup. We were indeed able to replicate the issue! We are planning on fixing it in our next release 1.8.6, though we don’t have a planned release date yet, likely mid-January or so, TBD. Thank you again for bringing this to our attention!
It’s currently under investigation so we don’t have a root cause yet, probably some incorrect assumption we made regarding the transaction. I will post back when we find what the culprit was!
