Topic: [Aug 2022] Mempool empty! Use this opportunity to Consolidate your small inputs! - page 44. (Read 88546 times)

That's quite surprising, considering fees aren't that high at all now. Transactions with 6 sat/byte are being confirmed.

That would mean fees can get even lower.

https://diff.cryptothis.com

the site above shows the difficulty of btc.

it also shows block pace.

at the moment we are over 250 blocks behind the pace.

less blocks means a more crowded mempool— a general concept.

so it you wait until next difficulty adjustment it will be easier to hit a block and blocks may be at a faster pace. say +8% vs -14%

obviously if you are supposed to make 100 blocks in 16-17 hours and make

108 blocks mempool tends to empty

and if you are supposed to make 100 blocks in 16-17 hours

86 blocks and the mempool tends to fill up.

doing a check on block pace
doing a check on mempool both help out.

Based on Johoe's site: 6 sat/byte is enough now for a fast confirmation. Since you're only sending 0.0001 BTC, that's already high, but if you go lower than 5, it may take days/weeks/months to confirm. My advice: try to avoid such small Bitcoin transactions.

Kraken has nothing to do with "internal" Electrum options. All Kraken does is wait for your deposit to be confirmed.

I'm not sure what you're asking: blocks are limited by size (in bytes), not in "money".

I'll need to catch up to what's written first. Became curious how much "money fits into a block" as some swaps for 130k go with 130 Satoshis.

The lowest I've seen it go was 12 at low prio. 5-10 makes it definitely likely to hit the mempool anywhere at all..

I'd rather not answer with an estimated time of arrival since mempool is unpredictable, but I'd say 2.7 or 1.3 sat/B are a bit low even for a normal priority fee.
If more transactions are added, it may take days or weeks, if vice versa, the next hour or so.

With the current standing, you can go as low as 7sat/B and it will still be cheap as long as your transaction isn't large in size (not the amount to be sent).
The (virtual) size of the transaction heavily depends on the number of inputs it spend and their (script) address types, quite affected by the number of outputs.
I believe that's already explained in the OP of this thread.

I'll respond to the other thread I made with a link over here, unless you edit your response.

Ohh I see. When I downloaded the APP; or even when I used in in Tails some (longer time) ago there was no introduction to this function. You can just tap the Feerate (Number) which isn't visual to change the rates.

So would you recommend this option? How likely is it to ever arrive when I go cheap with Fee rate 2.7 or 1.3 sat/B?

Edit: I am aware of the blockspaces btw: https://mempool.space/de/

That is indeed electrum. It is supposed to move over to Kraken. I'm unsure if Kraken offers changing ETA to Mempool..

That's Electrum (right?), the problem is your selected target fee algorithm,
you can change "ETA" into "Mempool" and you'll see that even "1mb from tip" will suggest lower fee rate than the minimum of ETA.

-edit-
My reply from your own thread:

If you we're to guess when the fees are on a lower niveau again, what would you suggest? 42 Satoshi feels a bit out of pace. https://imgur.com/a/IZCrNkj

Maybe they're aiming at (say) 98% certainty of being included in the next block. I can imagine that takes a higher fee.
But the fee to be confirmed within 10 or 25 blocks is also very high, and that doesn't depend on just the gap between 2 blocks.

I just made a 1.8 sat/vbyte transaction, which confirmed within a few blocks.

I believe they are also looking back to see what fees have been needed recently. Just looking at the mempool doesn't account for what happens if there is a long gap before the next block.



I marked 2 points, the first shows where 7 Sats would get you 0.2MB from the tip and then the second is 35 minutes later when only 50+ got confirmed in the next block.
If you look back that you'll see in the last few hours there had also been several occasions where similar fees were needed to get into the next block.

Yes, it would probably require a hard fork. The benefit of using balanced based addresses, versus individual outputs being spent is that transactions would become more efficient. It would save block space when one address receives many transactions, and more than one input is being spent. All that would be necessary would be a single input, a nonce and a single signature versus at least two inputs, at least two signatures, and two outputs under the status quo. It would also reduce UTXO bloat, as it would no longer be necessary to send to a change address when spending less than an entire output; this would save both blockspace, and the amount of required memory to run a node.
Noted. There could be some other clear distinction for addresses that are using "balances" instead of individual inputs.

Lots of corrections and fixes lately  

Probably we have till Monday, we are ~24 hours away from the weekend and we're entering this period with the smallest mempool in months, so unless something really really weird happens in terms of block time and hashrate or some other moron starts tweeting God knows what it might be that the fees will still be low on Sunday, averaging the same price as now. The last weekend we had no major events the mempool did drop from around 150MB to 110MB Friday to Sunday, so normal it would offset the drop in the extra 25-30 blocks a day we had.

And yeah electrum and fees
- next block fee 80.2 sat/b
- 1.0 MB from the tip 4.0 sat/b
Wonder what algorithm they use for the next block estimate

I didn't check the difficulty, I only looked at mempool.

Let me correct myself: last call for low fees

I think that you've chosen a dangerous moment for this recommendation. The difficulty has just jumped + 21.53 %, hence there will be quite a slow down in blocks.
We're back from ~8.3 minutes to ~10 minutes and I expect that get pretty soon visible in the fees.

That requires a hard fork and a significant change in the database and chainstate which is harder than it sounds. There is no benefit in "balance base" bitcoin that I can think of either since it could be implemented using the way it is.

BTW "bc" is the fixed human readable part of SegWit addresses, "1" is the separator not the version, and the next letter after separator (in addresses) represents the version with "q" being first, "p" second, "z" third and so on.

It would probably be better if any implementation of my proposal would only apply to transactions sent after a cutoff date.

It could that effective block number x, transactions can be sent to addressed starting with bc2 that are "balanced based" addresses, and that after block number x plus n, no transaction will be valid until all outputs are sent to a "bc2" address that keeps track of address/key balances.

I hope that at least the withdrawals from exchanges will become smaller. That would be your [1] I guess.

I know that big variations in price make tx fees go crazy. I've suspected the arbitrage traders/bots, but it's more than that. However, as long as LN is "advertised" as beta, unfortunately the exchanges can easily make a point of not adding the LN support. And even afterwards it could be difficult to get all of them use LN (I'm sure you remember the we had the same with the adoption of SegWit).

If 2 things happen we won't see any big fee spikes any time soon even with price surges or even if we see another small hashrate drop.
1. (smaller effect) If multi-sig users start using Schnorr instead after activation of it.
2. (biggest effect) If we move the traffic from big bitcoin exchanges to lightning network. If you look at each big fee spike in history they are almost always happening because bitcoin price either goes up A LOT or drops A LOT. That means the extra on-chain transactions are from traders. If that is moved to LN the on-chain capacity is left for other transactions. Not to mention the ability to deposit/withdraw bitcoins in an instant with virtually no fee while being in full control of the keys instead of having to leave them on the exchanges.

Bitcoin design is based on outputs not addresses and balances so it is not possible to do this without significant changes to the protocol.
However it could be implemented as a softfork with a new witness version for example. Something like this:
Assume an address has 5 UTXOs and you want to spend 2 of it (input 1 and 3) in a transaction while aggregating their signatures: (P2W3 is pay to witness version 3 as an example)
[1][3] are integers saying the follow up signature is for inputs at index 1 and 3 then signature and public key is used in OP_CHECKSIG and witness3 is empty because we have already added the signature for both inputs in witnessB

If you have 10 inputs in a transaction, all 10 inputs will need to be in the transaction, even if they are all from the same key. If each address had a balance instead of unspent outputs, a transaction with 10 inputs could be potentially reduced to a single input with a nonce and an amount (and a signature).