You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had previously done some testing with my main minting address for minting a subasset with an IPFS description at the time of minting
I had an issue each time with the sat/vb being the correct amount FW showed me, but the Effective Fee Rate was showing as about 1/2 (or less) than the sat/vb
After a couple tests and consolidations with Electrum I could not seem to get the Effective Fee Rate to go away.
Process was:
Use electrum to send all of the BTC on the address to itself
create a situation where an address has only 1 BTC input
sadly I kept running into this issue with minting this subasset, but it also came up when doing a longform BTNS description:
I found I could simply do a consolidation of my BTC using Electrum to 'push' these unconfirmed tx's forward and I could get them confirmed, but it was a bit of a hassle and an experimentation.
So I thought. Hmm. Maybe there is some hidden UTXO's that Electrum is not seeing and is holding up that address and that address was just too "dirty" with unseen UTXO's for low fee unconfirmed tx's stuck there.....
So I tried on a new address. One that I had previously done some dispensers on and bought some XCP..... (but not as "dirty" as my other address)
I used the same process to consolidate my BTC balance into 1 input using Electrum before testing this function......(and confirm with Electrum and block explorers that this address FOR SURE only had 1 input)
But I ran into the exact same issue... :( .... is the new address "dirty" as well?
^ i understand the fee here says "custom" but this was the fee recommended by the "high" setting (which again is the correct sat/vb but not effective sat/vb.... in which I am trying to clean up the "effective fee rate" to be the same as the sat/vb FW shows)
The text was updated successfully, but these errors were encountered:
v0.9.28
I had previously done some testing with my main minting address for minting a subasset with an IPFS description at the time of minting
I had an issue each time with the sat/vb being the correct amount FW showed me, but the Effective Fee Rate was showing as about 1/2 (or less) than the sat/vb
After a couple tests and consolidations with Electrum I could not seem to get the Effective Fee Rate to go away.
Process was:
Use electrum to send all of the BTC on the address to itself
create a situation where an address has only 1 BTC input
sadly I kept running into this issue with minting this subasset, but it also came up when doing a longform BTNS description:
https://blockstream.info/tx/bc6dfa7d90d0b2b21b48aad21531da5c91d4d96d878a6e99ae59fab39747e6b2
I found I could simply do a consolidation of my BTC using Electrum to 'push' these unconfirmed tx's forward and I could get them confirmed, but it was a bit of a hassle and an experimentation.
So I thought. Hmm. Maybe there is some hidden UTXO's that Electrum is not seeing and is holding up that address and that address was just too "dirty" with unseen UTXO's for low fee unconfirmed tx's stuck there.....
So I tried on a new address. One that I had previously done some dispensers on and bought some XCP..... (but not as "dirty" as my other address)
I used the same process to consolidate my BTC balance into 1 input using Electrum before testing this function......(and confirm with Electrum and block explorers that this address FOR SURE only had 1 input)
But I ran into the exact same issue... :( .... is the new address "dirty" as well?
https://mempool.space/tx/cab8304e31fe0f5502174c330251843accc45f94b4f16cff97028b49df9d764b
screenshots from FW when tx was broadcasted:
^ i understand the fee here says "custom" but this was the fee recommended by the "high" setting (which again is the correct sat/vb but not effective sat/vb.... in which I am trying to clean up the "effective fee rate" to be the same as the sat/vb FW shows)
The text was updated successfully, but these errors were encountered: