Nostr Web Client

Bitcoin Transaction Fees and UTXO Management

----------------------

- when bitcoin blocks are full, highest fee transactions are confirmed first

- pending transactions sit in node mempools awaiting confirmation: can conceptualize mempools as a line to enter a restaurant sorted by who is willing to pay the most

- your bitcoin wallet may show a single balance but the reality is that it is made of many different unspent transaction outputs (UTXOs)

- when you make a bitcoin transaction your wallet will select as many UTXOs as necessary to reach the amount of bitcoin you wish to send

- onchain transaction fees are calculated based on size in bytes not the amount of sats sent

- the more utxos required on the input side the higher the fee paid

- from a cost perspective you want to consolidate UTXOs, fewer UTXOs with larger amounts

- consolidation has privacy tradeoffs though: you link any UTXOs you consolidate as owned by the same person + larger UTXOs mean you will dox more of your stack to anyone you pay in the future

Therefore you want to reduce the number of UTXOs you have while being mindful of the privacy concerns.

Lightning Transaction fees are calculated differently: based on the amount in sats sent. Opening lightning channels when fees are low can enable you to save money in the future when fees rise. 🤙

https://werunbtc.com/utxos

Reply to this note

Please Login to reply.

Discussion

Doug Brown 2y ago

So given that this is designed for freedom to transact and supposed to be to allow the rich to still get ahead (by being able to pay the fees easily) should transactions be decided by random or “lottery” like and the miners are awarded based mining efficient blocks over

“Largest” blocks?

Rydal 2y ago

Interesting concept but it would undermine the balance of game theory in block creation. The only safe assumption to make is that miners will (generally) act I. Their own financial interest. Having some sort of lottery mechanism would fundamentally change the way blocks are built and not necessarily for the better.

Instead of changing the incentives perhaps another tool my be developed to help smaller actors all pool their funds into a single transaction and share the fee burden. Efficient transaction creation (with many in/outputs) may be a way to pool smaller resources, like transactions carpooling. Def would need some way to fleshing out the method by which the transactions are built/signed and submitted, but it could be an interesting area for development.

As we get higher fees/reduced space new tools will be developed for users to make the most of the resources available.