mempool

Willtech

00:20

@chytrik Some of the cost returned to them, they can already include their own transaction for 0 sat/byte so I guess the rebate is 0.

chytrik

@Murch Gotcha, so the burn-rate would be a specified value in satoshis then, rather than (for example) a percentage of the total fees. So larger blocks would only be economical in times of network congestion. Interesting idea

@Willtech Right, miners can do that already, but they incur an opportunity cost for doing so. If a miner could include their own txs while simultaneously increasing the block size, that changes the game theory.

Willtech

As I said, embeddng a burn in the protocol gives Bitcoin a limited life.

@chytrik Yes, instead of not getting fees for including transactions for others and including their own instead, they include their own transactions for free as additional transactions, increasing block size for free. Whether the fee penalty is burnt or returned to inputs this is not mitigated.

chytrik

@Willtech Not necessarily, the total number of units in the system doesn't matter, so long as the remaining units are infinitely divisible. If there were just one bitcoin left, and each satoshi of that coin was divided 21 million more times, it would be functionally no different than 21 million coins divided into satoshis.

Willtech

@chytrik oky, but we currently do not have infinite divisibility.

Murch

@Willtech Including your own transactions has an opportunity cost equal to including a higher paying transaction.

@chytrik Yeah, that's how I meant it. I just did a spreadsheet, bytes² [sat] is way too much and prohibitive, though.

Willtech

00:26

@Murch But if I can just include the higher payng transaction and then add my own for free on op of that...

Murch

Ah, I shouldn't reply until I read everything, chytrik already said that. ;)

@Willtech I sincerely doubt that the effect would be so pronounced. One could still run the world economy on a few thousand bitcoins, and when we're doing hardforks anyway (as the above proposal would need one), we could also hardfork to add more divisibility.

Willtech

@Murch I agree, not a pronounced effect, however, an inevitable effect.

Murch

yeah, but does it have a bad influence?

(I did it again, maybe I should just go to bed)

chytrik

@Willtech whether the fees are burned or returned does matter to a miner though. Burned = higher costs for including your own transactions.

Murch

exactly

burning the fees actually makes them pay the cost for requiring nodes to use more resources

Willtech

00:32

Your own transactions are already free only vs opportunity cost. If the block is allowed to be larger and you can already include your own transactios for free then the only lost opportunity is a reduced share of the fees for fee-paying transactions, in which case it makes no difference to the miner if the fees are burnt or returned to the inputs, except for the additional outputs required.

So, the cost is actually higher if the fees are returned to the inputs.

Murch

@Willtech Under my rules above, larger blocks are never free.

chytrik

As Pieter mentioned above, its probably very hard/impossible to measure the centralizing affects of larger blocks. But it seems like an important factor to consider nonetheless. If the cost of 'burning' fees is lower than the extra returns for large-miner-large-block advantage, then we'd expect large miners to routinely create massive blocks and eat the burn cost.

Murch

The cost has to be paid regardless of whether fees are paid for the transactions.

Willtech

Yes, agreed, the cost is losing more of the fees.

Murch

The additional cost is exclusively dependent on the additional size of the block.

Willtech

00:35

Right, pay the cost even if an included transaction pays no fees.

Just means that the additional cost is taken from the fee paying transactions.

Murch

So, what you'd want to achieve is some sort of dampening effect on congestion, right?
At fees of 1 sat/B, there is no congestion. At 10 sat/B, hardly any, at 100 sat/B, the first people start to get antsy. At 1,000 sat/B, it's definitely pretty high. 10,000 sat/B would probably be shit hitting the fan.

So, at 1 sat/B, it should not be economic to create any blocks greater than the standard size.

at 10 sat/B, at best a few more transactions. Maybe 1 kB more.

Willtech

Yes, agreed.

Murch

at 100 sat/B, you might want to allow 20% increased blocksize, so it should be economic to include up to 20% more block data paying 100 sats/B

at 1,000 sat/b, we really want to flush the mempool faster than usual, so let's say 50% more blocksize or even 100% more.

at 10,000 sat/B, at least 200% more

Willtech

Agreed all.

Murch

Now if we were to put those points on a chart of fee rate versus cost, we'd be able to find a curve that fits those points.

And that curve should then be the general rule for creating blocks bigger than the standard weight.

that's in the essence what I was suggesting above

it's infeasible because it needs a hardfork, and the bikeshedding over the exact points for the curve would never end

Willtech

00:41

Okay, yes I am prett sure that I followed. The idea still has merrit even though a hardfork is required, the resistance/benefit curve may crossover at some point. It would still be worth having it written up as a BIP.

chytrik

Yea, defining that curve would be quite the battle

Willtech

You only need to define reducing benefit vs block size and have it sound to provide economic benefit vs any given fee rate, the arguement after that is academic.

Ther arguement is squared away if you define an upper and lower limit curve as examples and then define it right up the middle.

chytrik

The large-block-advantage is difficult to estimate... but the optimum shit-hitting-the-fan sacrifice is probably even tougher to quantify!

Willtech

Originally I suggested that the optimum block size for any given can be defined as:

(current average valid transaction pool size) x ( 1 / (144 x n days ) ) = number of transactions to be included in the current block.

Where n days must be a consensus value and, a consensus is required how to define the valid transaction pool size.

So, if you can estimate the current fee for any valid average mempool size then you have some targets resulting in the current mempool being all processed in n days. That should make your minimum block size, larger if you want to reduce the mempool size.

chytrik

Requiring consensus on mempool stats is a whole can of worms in itself though. Rather than a node expecting a block of a certain size based on a mempool consensus, why not just let each node validate the block according to the fees included in that new block?

Willtech

00:49

Note that previous arguements are the there is no consensus as to the mempool, whereas I contend that such a consensus is not what is called for.

Yes, the new case put forward is probably easier to work.

Since, it was not possible to enforce block size under the previous discussion and it was left up to the miners understanding market forces to not be stupid about it. The current discussion allows enforcement.

BTW, I suggested a new peer network service to discover mempol information with rules, and eventually discarding the lowest 75% of values average the rest.

The discard could probably afford to be higher but no testing has yet been done.

chytrik

I think that the total fees collected for mining a larger block would have to be less than the fees for simply mining the current max size of block. Otherwise there will always be economic pressure to create larger blocks (even if there is a burn that makes it uneconomical for a miner to fill a block with their own transactions), and in general this isn't seen as a good thing (its a centralizing force).
So instead, miners only gain incentive to create larger blocks during 'shit hitting the fan' type congestion, in order to preserve the usability/UX of the network they've invested in.

Willtech

So, the idea @Murch put forward certainly has merrit. If it could be integrated with current mempool information it could be accurately enforced.

Yes, the idea of negative benefit for increased block size on a curve vs sat/byte level seems to give what we are after.

As fees go up, there is small incentive to create a slightly larger block. If fees increase dramatically the best economical block size increases more. How large a block should be does not depend direclty of fess, it depends on network capacity vs mempool size.

If the mempool currently consists of 2,000 transaction paying 10,000 sat/byte then there is no expectation to create a larger block, in fact a smaller block is called for.

The fee rate is a derivation of the expectation of users vs the current mempool.

Murch

02:27

@chytrik: Interesting idea.

@Willtech: Mempool is not something that can be verified at a node level or at a later time.

WHat if my computer was off and I just come back online, my mempool is flushed immediately by the new blocks I sync up to.

Suddenly I don't accept blocks others can accept, because I don't see the mempool pressure?

@Willtech: My proposal has also the advantage that as you add transactions with ever lower fee rates to your block, at some point the equilibrium is reached. It thus sets a level of lowest acceptable fee rate to the block.

chytrik

03:21

@Murch I was thinking that the miner could take the fees for the top paying 4k WU worth of tx (less some percentage as a 'burn/fee'), and then any other txs included would have their fees burned. You could have a sliding scale of burn-percent for the collected fees, depending on how much extra weight the large block has.

You'd have to ensure the burn-percent is high enough to not give larger miners an incentive to make larger blocks (that is, more of an incentive than a smaller miner would have to do the same).

But I don't think it'd be too delicate of a balance, you could make the burn penalty harsh enough to only incentivize miners to use it in high congestion periods. I think that way the game theory stays simple and in line with what is wanted: no one can abuse the new rule to gain an advantage, but a miner can unselfishly take a hit in order to preserve usability of the greater network. If the miner doesn't take the hit, the network continues to function just fine as is.

Willtech

@Murch As I said, with rules, I did not specify but in the case of the node being off and just coming back online there is a wait time. This is also the reason for such a large discard, since any reportd mempool value could be lower than the actual but could not under ordinary circumstance be higher.

chytrik

What about nodes that choose not to keep a mempool? I would imagine some percentage of nodes only validate and archive new blocks.

Using mempool stats also make DDoS attacks much more of a risk to node operators.

Murch

05:08

@chytrik A burn percentage would always be more revenue, hence essentially making the blocks unlimited. That's why my proposal was not linked to the fees of the transactions but strictly to the blocksize only.

chytrik

@Murch The percentage would come off the fees for the first 4k WU worth of txs, any additional weight would be 100% fee burned

Murch

@Willtech: Currently the mempool is transient data that is not necessary for most people to operate reliably on the blockchain. Your proposal changes the very nature of the mempool data to be consensus critical.

@chytrik oh, I see

@chytrik Why not just off of all transactions in the block?

chytrik

@Murch my thought was that taking a cut off the first 4k WU would potentially be easier to decide upon, rather than having to haggle over what a proper burn rate would be for larger sized blocks. It seems to me the game theory may be more simple. I'm kinda just going off the top of my head though :p

That said, there may be gamethoery implications for burning fees. The total 'unclaimed fees' in the mempool became a considerable amount of value back in Dec/Jan. If a miner burns a huge amount of the unclaimed fees, leaving only smaller fee txs behind, what would the effect be? Miners are depending on fees for revenue, seeing high fee txs burned isn't necessarily what a miner wants.

That sort of affect would only become amplified as fees take over from block reward as the primary source of revenue

Murch

@chytrik If you do that, there is never an economic incentive to mine bigger blocks, except for the greater good. Isn't that a classic tragedy of the commons?

also, my proposal is just as well at the brainfart stage, so no worries there

@chytrik That's a very important ponit

If you're just gonna lose all of the reward for the block anyway, but doing it for the greater good, you might as well include the whole mempool right now.

That's why I would prefer a construction that incentivizes bigger blocks when there is higher demand but reduces the incentives at low demand. When it makes economic sense to act positively for the network is when the real wins are made.

If the supply is dampened in some fashion, it'll still flush the mempool faster at higher demand, but not destroy all the revenue for the following blocks

Willtech

06:09

I was not suggesting syncronising the mempool, only distributing information about the mempool. If some nodes do not participate in mempool then they do not contribute to the information about it either. @chytrik DDos Attacks? How so?

Willtech

07:12

It seems useful to remember that at present the fee model is an auction model for limited bandwidth. I do not agree that it is the most beneficial model for Bitcoin to use, however, it is currently in miners interests for transaction bandwidth to be far exceeded so long as overall uptake of Bitcoin is not greatly reduced. Doing things like flushing the mempool is likely to be strongly objected to by miners as it destroys their auction and is one of the various reasons that ...

... a balance of having all transactions processed in n days was sought. Even better with a further yet-to-be-discussed-here change in addition so that the auction model is shifted from limited bandwidth to a fee-for-priority-service model.

Willtech

07:32

Using the suggested method I posted earlier for determining block size, the mempool is always topped up with n days worth of transactions. That way, with the additional change, the fee level can determine the priority directly, whether you are likely to be included in the next block, or whether you are likely to have to wait the whole n days.

This should serve miners well, since the utility value is retained even with a large mempool and, since there is still limited space in any given block the action model is protected, albeit a different auction model.

The two main problems I found were; accurately determining the mempool size and, enforcing block size. I supposed that miners would not want to make blocks any bigger than they needed to for fear of destroying the auction, the incentive to make them larger was the addition fees, so I supposed that there would be an equilibrium, however, history shows us that in a market not all people are so smart and some are greedy.

With no way for the individual node to determine if the presented block size is correct, the method I considered only allowed for a node to consider what would be the optimum block size to make in its view but provided no method to enforce that, the new suggestion we have been discussing, of providing a fee penalty based on additional block size, if carefully crafted, would make block sizes economically enforceable. Of course, there would still be nothing stopping the occasional ...

... anarchist miner from including the entire mempool in a block if they chose even at a great loss.

chytrik

08:00

@Murch One incentive I mentioned above is good public relations for bitcoin, it may be more profitable for a miner to forgo some fees in the hopes of maintaining a higher coin price. But price is affected by so many other variables, and the tragedy of the commons is there.

Hmm actually there could be ways to game something like this

If you were a miner, you could solicit businesses in the bitcoin economy, to be the exclusive miner for their transactions. Something like

"Hello I control 20% of the hashpower. Send me all of your transactions through a private channel, make every one of them have a set fee (just slightly more than the penalty fee), and I'll always include them in the next block I find"

Err, actually in the above it should be "set the actual tx to zero fees, pay the miner privately"

chytrik

08:21

So with any of our proposals, the person making the transaction is now paying a premium to make the block larger, instead of just paying a premium to secure some limited blockspace.

@Murch I agree, its absolutely best when incentives align. I guess thats always been my worry with dynamic block size schemes: giving the participants control over one of the variables that affects their profitability seems like it just complicates the situation greatly. I see no reason a good balance couldn't exist in a system like that, but I think it may not be trivial to find.

Murch

16:11

@Willtech Actually, even the maximum size of blocks would be limited by this, because a miner would not be able to burn more than the amount that they would get in revenue.

@chytrik They can already do that, and this monopoly is broken easily by other users on the network paying more than the agreement yields the miner. Also from the perspective of the monopolizing customer, this will make the confirmations less reliable than to just offer them for the same cost on the network.

@chytrik Yes, that's the point. If there is no economic incentive to make bigger blocks, nobody (rational) should be doing it.

chytrik

21:11

@Murch I could imagine a scenario where a customer 'always pays 100sat/WU', no matter the network congestion. During low activity times this would be a premium, but during high activity times it could be a nice discount, while still guaranteeing (somewhat timely) confirmations.

Of course there are problems with it: difficulty to predict future congestion (and thus the set fee), or the ability of the business to sneakily publish some transactions to the network, with lower fees during low congestion times.

For some businesses, paying a slight premium over the 'expected average fee' might be worthwhile though, in that you could more accurately define your budget ahead of time. If your biz sends a lot of txs and fees go 10-20x for a week or two, that could be trouble! For example BTM operators were feeling the heat during the Xmas congestion, buys/sells under ~$50 became prohibitively expensive

But I digress.. it still seems to me that the ability to pay for larger blocks is a larger existential threat to the network than the ability to pay for limited space. Or at least, given the advent layer 2+ solutions it is. Our proposals seem like a lot of meddling for marginal capacity gains XD

@Willtech Murch sorta touched on this: if a node is DDoSd or otherwise taken offline, and they depend on their mempool stats to validate blocks, then once that node boots back up it may have additional trouble getting back into consensus.

Transcript for