A new BIP being discussed on the Bitcoin-dev mailing list is aiming at
making variable Bitcoin block size depending on the fee the sender is willing
to pay, the BIP is aiming at making the block space small, decrease the impact
of spam transactions, balancing fees with smaller fees increasing in a higher
percentage than higher fees, allow larger block size if the sender is willing
to pay for it, allow wallets to display the amount, and price, of free block
space left and allow senders to have more control on their fee/priority
structure.
Feed for tag: fees
Lightning Network is currently starting to build up, it has recently passed 2 Million dollars in capacity, but its still far from being perfect, there’s currently very little ways of assessing how much fees a payer will pay, although its currently mostly a negligible value, it may not be in the future.
A use case of the Payee paying the fees of the transaction is used in almost every exchange platform, because on the main blockchain you can assess the current average fees and even figure out how much, on average, it will take your payment to be accepted by the network if you sent it with a definite amount, this currently does not exist in Lightning.
If the payee pays the fees the payer can route the payment towards complicit nodes that charge way higher fees than average.
Dmitry Petukhov presents a different approach to the UTXO consolidation problem called Organic Consolidation.
For UTXO-based cryptocurrencies, it is important to have the set of managed Unspent Transaction Outputs in optimal shape, because if you have too much small UTXO, you will have to create bigger transactions to send the same amount of funds, and hence pay bigger network fee, or even need to send several transactions to transfer the needed amount.
Typical approach to handle this is to do periodical sweep of UTXO, bundling them all together, at the time when network fee is low.
We implemented another approach, that does not require manual UTXO consolidation, and at the same time, conserves network fee - when fee in the network is high, the algorithm tries to use less UTXO per transaction, and when network fee is low, it will create bigger transaction, effectively performing UTXO consolidation along with regular payments. This organic UTXO consolidation allows to maintain healthy UTXO set automatically, without manual consolidation runs.
Following the last few months of low transaction fees, many have used the opportunity to consolidate their UTXOs . Xapo, a company that makes an online bitcoin wallet, recently published a report on their experience consolidating millions of UTXOs.
The idea behind UTXO consolidation is essentially this: when your average outgoing payment is larger than your average incoming payment (or when they’re the same, but you’re batching outgoing payments), you’ll often have to combine many UTXOs in order to fund an outgoing transaction, which increases the size of your transactions and hence the fees you pay. By consolidating UTXOs in advance, you can combine inputs ahead of time, giving you more control over when most of those costs are incurred. If you can do it when fees are low, that lets you reduce those costs pretty substantially.
The largest problem we are having today with the lightning protocol is trying to predict future fees. Eltoo solves this elegantly, but meanwhile we would like to include a 546 satoshi OP_TRUE output in commitment transactions so that we use minimal fees and then use CPFP (which can’t be done at the moment due to CSV delays on outputs). Unfortunately, we’d have to P2SH it at the moment as a raw ‘OP_TRUE’ is non-standard. Are there any reasons not to suggest such a policy change?
OP_TRUE is an operation code used in Bitcoin Script. Its function is to push “1” onto the stack, which will later be popped and evaluated in conjunction with standard lightning commitment transactions. Every operation code yields a computational weight because they are all components of a smart contract. Fundamentally, the commitment transactions for Lightning are “hacky”, meaning they take advantage of unusual protocols and combinations of operation codes. The impact of this on the user is an inability to consistently calculate transaction fees.
The last thing lightning users would want would be to close a channel only to see their funds suspended in the memory pool or to close a channel and overpay. While transaction fees can be adjusted following transactions, lightning transactions ought to occur with a degree of precision that circumnavigates a scenario where a user would ever have to adjust an on-chain transaction fees.
Prior to SegWit, when blocks were at their transaction maximum and major wallets were not transaction batching, many wallets were generated and discarded with minuscule sums. In the Bitcoin source code, these balances are referred to as “dust” (the following comment is adjusted for formatting):
“Dust” is defined in terms of dustRelayFee, which has units satoshis-per-kilobyte. If you’d pay more in fees than the value of the output to spend something, then we consider it dust.
A discussion was started on Reddit’s
/r/BitcoinDiscussion
that initially wanted to look into the possibility of spam transactions. Much
discussion occurred regarding the topic as it is highly debatable. However, out
of the discussion one redditor put a quick project together to collect some fee
statistics from recent Bitcoin blocks.