pull down to refresh

You want to aim to strike a balance between having too few and too many UTXOs. If your wallet is too fragmented, your inputs may incur a lot of fees in the future. If you have too few UTXOs, you may reveal significantly more information to your counterparties about your stash. E.g. if you pay someone 1 m₿, but use a 1 ₿ input, they learn that you at least have a whole coin. On the other hand, if you want to pay someone 1 ₿ and need to combine ten or more UTXOs to fund the transaction, you may also tell your recipient and the people that sent to you a bunch about your wallet history.

I would avoid splitting everything into round amounts as you propose. Doing so would incur unnecessary additional transactions, the round amounts would be a fingerprint, and having multiple UTXOs of exactly the same amount is less versatile than having that sum composed from different amounts. That said, an exponential distribution seems like a good idea. If I were in your situation, I would take a look at my UTXO pool composition and decide which UTXOs you want to keep, and where you have gaps in the value distribution. Then I’d try to create transactions that each give me one or two UTXOs in those less densely populated value ranges. Be sure to spend UTXOs with inefficient script types while the fees are low: P2PKH (legacy) weighs 148 vbytes to spend, P2SH-P2WPKH (wrapped segwit) weighs 91 vbytes, P2WPKH (native segwit v0) weighs 68 vbytes, and P2TR even only takes 57.5 vbytes.

For a private wallet, I’d say that you probably have too few UTXOs if you have fewer than ten, but you may have too many UTXOs if you have over 50 or 100. Those ballpark numbers of course depend on the overall amount of ’corn you stash. If you are more cost-conscious, you may want to aim lower, if you are more privacy-conscious, you may want to aim higher. If you have coins from different sources that you want to keep strictly separate (e.g. business funds and private funds), I find it more straight forward to have separate wallets than to keep them separate manually in one wallet.

On public channels, routing fees and max/min htlc sizes can be used to steer payments in one or the other direction. This is very helpful.

Private channels on the other hand don't need that and can just have a static fee, maybe based on usage patterns.

reply

Among other things, I contacted almost every pool I could find to pitch them on running full-rbf.

Good example of how Bitcoin really works actually: Core developers don't have any direct power. To make something change, users and miners have to be convinced to run new code and/or change configuration options. In some cases, not very many people have to be convinced: full-rbf just needs a few miners opting in to be useful. In other cases, pretty much everyone needs to be convinced: tail emission isn't going to happen without a hard fork and wide support.

https://petertodd.org/2023/why-you-should-run-mempoolfullrbf

Of course, I'm personally being sued by Craig Wright, who claims I among other people can give him coins that he claims are stolen (with zero hard evidence). It's a laughable lawsuit: can't even get full-rbf widely enabled without convincing a lot of people. 😂

reply