Show sat/vB and allow user to set fee rate

[BTCAlchemist]

People often want to set the fee rate in sat/vB to know how quickly their transaction would confirm and how expensive it is relative to other transactions (regardless of # UTXOs used). The fee rates are shown in BTC and $ but not in sat/vB. Could you add sat/vB display for the fee and allow the user to set a custom sat/vB?

Posting here as per @jdogresorg's request.

[BTCAlchemist]

@2weiX @davestaxcp I think this is of interest to you as well. If so, please upvote it.

[davestaxcp]

yes as posted here (mistakenly):

I have been reviewing the issues coming in for users on the Freewallet Telegram (https://t.me/freewallet_io) and I have noticed a big discrepancy between new users and knowledge of UTXO's, how the "high" fee is being calculated and sat/vb on a specific fee. Myself included.

I can give you an example from my own experience:

The first send was just for sending an XCP asset to another address.

The second send was sending ALL of my BTC (lots of UTXO's) to an exchange address.

Despite Freewallet saying this "total btc fee" should be enough, Freewallet did not take into account how many UTXO's had to be sent and thus with the same btc fee amount (0.00004) was 1/3 of the sat/vb

Despite many people in this scene being knowledgeable of these specific small hiccups that may happen, in my experience 90% of the users don't know why their fee "came out too low" and it just "doesn't work." And just telling them to select "high" fee is not enough direction or education provided for them to get their transaction done in a reasonable amount of time. If you do not show an option or explanation on why it will be a higher fee, and they use "high" fee and it isnt high enough, in their experience the "high" setting would be broken.

I think it's really important Freewallet shows not a "total btc amount" but the "full amount of btc for all UTXO's." Making this known when sending BTC especially is needed (most people are sending payment to a dispenser of exchange address in this scenario and need it done FAST). I see on the xchain API there is an option for showing an addreses' UTXO's. Could that be integrated here to show for each address on Freewallet? Basically a UTXO dust fee generator of sorts?

I think it's important for people to know the "total btc amount" to sat/vb conversion as this number can be vastly different if sending all the btc on your address vs. sending 1 xcp token, vs. doing a 300+ multisend.... It should be very accurate and "work" every time from a user perspective when selecting "high." Even if its required to be expensive by the BTC network, I would rank getting the transaction done higher than importance of 'saving a buck on a fee.' This has already been mentioned as described here: #12, but I think it can be explained or displayed in a more "dumb user friendly" fashion.... People wont necessarily care how much it costs if its known by the user to be very accurate.

Another aspect of trying to write a tutorial for CPFP using Freewallet (here: https://gist.github.com/davestaxcp/1e2cc086a13c9a2d045876852b57e5be#help-i-used-too-small-of-a-fee-and-my-transaction-is-not-confirming), is the plain fact users just will use Electrum because they can be using CPFP and picking the specific previous (parent tx) transaction. It would be very nice to either have Freewallet automatically try to use the previous unconfirmed transaction UTXO when doing the next transaction. Or simply having a "UTXO" list for each address to pick from when trying to do CPFP on Freewallet. Maybe even add a CPFP button on freewallet to somehow automatically do this?

Another good "button" or "function" to have would be Consolidating UTXO's. It would be so extremely helpful for Freewallet to show, explain and offer a way to fix this all in the User Interface itself. It can link to FAQ's and more information, but it would solve a hell of alot of issues related to all of these errors: https://gist.github.com/davestaxcp/1e2cc086a13c9a2d045876852b57e5be#failure-to-send-not-enough-btc-in-wallet

[SN-Noop]

Hello,

The 1/3 effective fee happens when multisig is implied (For all stamps mints, and some other txs).

In this case you have to multiply fees by 3. (This is not the exact calculation but it is quite complex to be explained here).

NB: Fees selection on mint is not working in this version, it will always get counterparty automatic calculation that is not very accurate for a quick confirmation time. It is fixed but will be up only in next release. see: #166

For the moment, Freewallet is using 265B as basis to calculate the fee amount (eg: high/medium/low). As some transactions can be higher, if you know that your TX will be "bigger", you'll have to send much higher fees.

I've built a full wallet for stamps and I managed to provide precise calculation of fees and selectable fee/vB for transactions. Feel free to DM me on TG sn_noop2 if help is needed to update this part.

I won't raise a PR as there is no code guidelines and I don't want to write code that will never be merged.

[davestaxcp]

Thank you for this response and the link to #166 - super helpful to know this issue is being addressed (sorry I didn't notice the issue number earlier)

[davestaxcp]

Here's an another example of the user experience of how fee's are shown in Freewallet.

I hope this comment can explain in more simple terms how an average user (like me) will be extremely frustrated for what the wallet shows versus what the outcome of the transaction on the Bitcoin Network.

This time I used the new version 0.9.24 and simply sent BTC to myself.

https://blockstream.info/tx/86aa109e2766ae04738c1868641203070da4c1817e3949e4971a38c84d5d1cfe

The user interface showed this for my transaction:

There is an indication of what the High fee setting will be on the simple BTC send I am doing. In this case I am just organizing my UTXO's and sending the MAX amount of BTC to myself.
But this could also be applied to if someone was buying a token from a dispenser.

When the user interface in Freewallet showed me a fee that would be 'quick' and work fast... hence the "high" setting.... and then I send a transaction and it doesnt get confirmed fast, I get really frustrated. The transaction on blockstream:

As you can see I did more than double the transaction fee (almost triple) that was recommended and was still not enough to get this transaction to be included in a block that will happen soon.

It is with my limited understanding, but it seems I have 8 inputs on my address to make this transaction work:

In the process of writing this the blockchain has been quite unpredictable:

So I understand this is most likely because of the indication of the recent block data beforehand... but what scares me for any new user is that when I input almost triple the fee shown in Freewallet it now put my transaction at a point STILL under the priority for sat/vb

The AVERAGE of the last 10 blocks was 22+ sat/vb... and I shouldn't have to triple my fee to reach the average sat/vb

From this experience it seems Freewallet is not taking into account how many inputs I will need and is not reflecting that data correctly to the user with limited knowledge, thus causing anger and frustration.

This process, feeling and frustration is not just me alone. I know Porkchop has been helping people firsthand for the past week everyday trying to help new users that this happens to. It's burdensome and expensive to fix, especially for a new user just trying things out.

This is why we need a sat/vb calculator AND support for explaining UTXO's while possibly having them visible in some manner in the user interface if they are going to be bumping up the recommended fee's.

Take into account that I assume 80% of users that experience this issue (with other functions too!) are just going to get mad and consequently get turned off to counterparty and freewallet. Most common users do not seek any help, nor voice their opinion publicly.

It's very common even for me to run into this issue personally even after writing an FAQ for 0.9.23 and testing things here.

It's really frustrating and I think its the main cause for people all over this community to get "stuck" when buying from a dispenser, consolidating their UTXO's, sending a multi-send and so many other functions.

I had to learn about what UTXO's were to even write some of the documentation... why not just show the common user what they are and how it's pumping up fee's? Something like how Electrum shows specific UTXO's...

I would rather be writing an FAQ for "Why are the fee's so high on my address?" or "What are UTXO's and how can I see them on Freewallet?"
than having to fix people's issues when they say "Help! I used too small of a fee and my transaction is not confirming!"

[zerog975]

I recently ran into this issue myself. Was using freewallet to buy XCP from a dispenser, with the high fee setting before going to bed.
I ended up waking up in the morning, and found the dispenser was almost drained, and lost 15 xcp as apparently my payment was using two utxos instead of one so the suggested fee was insufficient.
This would be a good improvement.

[davestaxcp]

Thank you for your response ZeroG

Just as an addition to my previous post when I mentioned:

Something like how Electrum shows specific UTXO's...

I went ahead and asked GPT to give more information on how Electrum shows this sat/vb information:

Electrum primarily displays transaction fees in satoshis per byte (sat/vb) rather than showing fee estimates in this format directly within the user interface. Users can typically set custom transaction fees in terms of satoshis per byte when creating a transaction, allowing for flexibility in choosing the fee based on network conditions.

However, Electrum has the feature to provide fee estimation based on current network conditions, often displayed in fiat currency (like USD) or Bitcoin (BTC) rather than explicitly in satoshis per byte. Users could use the fee slider or input a custom fee in satoshis per byte when creating transactions.

When asking the further features of Electrum regarding UTXO's and furthermore CPFP it responded with a short summary:

• Displaying UTXOs:
  Electrum displays the available UTXOs associated with the user's Bitcoin addresses. Users can easily see the unspent outputs and their respective amounts, which provides an overview of the funds available for transactions.

• Transaction History:
  Electrum provides a transaction history that details all past transactions, including both incoming and outgoing transactions. This includes information about UTXOs involved in each transaction, giving users a complete record of their Bitcoin activity.

• Sending Bitcoin:
  When creating a new transaction to send Bitcoin, Electrum allows users to select specific UTXOs to use as inputs for the transaction. This gives users control over which UTXOs are used in a particular transaction, helping optimize the transaction and manage fees.

• Change Handling:
  Electrum handles change from transactions by creating new UTXOs for the remaining funds after a transaction. This ensures that the change is returned to the user's wallet as a new UTXO.

• Transaction Preview and Fee Estimation:
  Electrum allows users to preview transactions before broadcasting them. It also provides fee estimation tools based on the current network conditions, helping users select appropriate transaction fees for timely processing.

• CPFP (Child Pays For Parent):
  Electrum supports CPFP, a mechanism to accelerate the confirmation of low-fee transactions by creating a new transaction (the child) with a higher fee. If a transaction is stuck due to a low fee, the user can create a child transaction with a higher fee, which incentivizes miners to confirm the original transaction.

In summary, Electrum enables users to view and manage their UTXOs, control transaction inputs, optimize fees, and handle change effectively. Additionally, it supports CPFP to address transaction confirmation issues due to low fees.

Just posting this all here as I think it explains in more technical accurate detail than how I would word it personally.

[davestaxcp]

Furthermore, if it is not already apparent, in my opinion after writing the 0.9.23 User Manual/FAQ...

This sat/vb option for fee's is the most needed upgrade to Freewallet for versions in the future.

To explain more about how sat/vb is calculated I input a couple questions to GPT and it came out with this:

---

The term "sat/vb" stands for satoshis per virtual byte and is a unit used to measure the fee rate in Bitcoin transactions. To calculate the satoshis per virtual byte for a Bitcoin transaction, you need to consider the total fee in satoshis and the size of the transaction in virtual bytes.

Here's a step-by-step process to calculate sat/vb for a Bitcoin transaction:

• Determine the total fee in satoshis:
  The fee in a Bitcoin transaction is usually specified in satoshis (1 Bitcoin = 100,000,000 satoshis). This fee is what you're willing to pay for the transaction to be included in a block.

• Calculate the transaction size in virtual bytes (vbytes):
  The size of a transaction in virtual bytes is determined by the number of inputs and outputs in the transaction. Each input contributes to the size of the transaction, and each output adds to the size as well.

• Divide the total fee by the transaction size in virtual bytes:
  This calculation gives you the satoshis per virtual byte (sat/vb) for the transaction.

The resulting value represents the fee rate in satoshis per virtual byte for the Bitcoin transaction.

Keep in mind that the fee rate you choose affects how quickly your transaction gets confirmed. Higher fee rates (more satoshis per virtual byte) generally result in faster confirmations, as miners are incentivized to include transactions with higher fees in the blocks they mine.

---

To calculate the transaction size in virtual bytes (vbytes) for a Bitcoin transaction, you need to consider the number of inputs, outputs, and other factors that contribute to the overall size. The formula for calculating transaction size in vbytes is:

where:

where:

This calculated Transaction Size in vbytes is then used in conjunction with the total fee in satoshis to determine the fee rate in satoshis per virtual byte (sat/vb) for the Bitcoin transaction.

---

In conclusion, this information does not help a user that doesn't understand what is happening technically above.
Furthermore, this information is not easily "decodable" from a users address in an easy way.

Even when I asked GPT:

NONE of these above tools had a place for me to simply input my public BTC address and have it "tell me" the right BTC fee to use in relation to the inputs and outputs on my address.

@jdogresorg could there be some way to scrape the code from Electrum to have it integrated into a future Freewallet version?

[SN-Noop]

Easy step, you can use built in functionnality from bitcoinjs as it is installed.

bitcoinjs.Transaction.fromHex(hex).virtualSize()

[davestaxcp]

Could it be possible for you to incorporate this on a pull request?

How would it look to integrate it into the UI design that already exists in Freewallet?

[SN-Noop]

@jdogresorg If you may, for a very quick win:

not directly to fix this issue but helping users to be aware correctly of the fee/vB depending on what they've put as fixed fees,

VERY QUICK WIN:
In linked code below, in addition of calculating output values, adding (fee / tx.virtualSize()).toFixed(2) would show an approximation of fee/vB to the user.

A bit longer BETTER WIN:
To be more precise, if the "createIssuance tx" is signed before calling tx.virtualSize(), it will be the exact value (in my tests at least).

freewallet-desktop/js/freewallet-desktop.js

Line 6382 in 674500a

msg += '<br><br><div class="alert alert-warning" role="alert">This will include an additional fee of ' + num + ' BTC ($' + usd + ') <br>needed to encode the data to the Bitcoin (BTC) blockchain.</div>';

[jdogresorg]

FYI... I already have issues open for revisiting the BTC fees... right now they are based on an AVERAGE send size, not the actual transaction size.

Redoing the fee estimation is a high priority item for me, and should get into the next release or two.... However, it requires a complete revamp of the way the wallet works, including doing a pre-flight check to generate the transaction via the CP API to determine the ACTUAL size of the transaction, and then show more accurate fee / sats-per-byte fee information.

Here are issues which are open and related to fee esimates

Fee Estimation
Issue #23

Ability to set fee in sat/b instead of absolute
Issue #12

[davestaxcp]

thank you for your detailed response