< zookolaptop>
Makes sense. Also I'll bet there are quantization effects and "economies of scale" more locally, too, e.g. bufferbloat.
< gmaxwell>
well mining inequality of delay throws this all out.
< * zookolaptop>
squints.
< zookolaptop>
What's that?
< gmaxwell>
zookolaptop: e.g. if a miner is a super majority hashpower they don't ever have to get orphaned; so there is little to harm in terms of orphaning to make blocks as big as they want.
< gmaxwell>
In any case, formula for marginal feerate in order to overcome subsidy loss; there are an infinite number of tiny miners who all have the same constant and size sensitive delays is (41.6623*e^(((-0.00166649*size)/bytes_per_sec)-0.00166649*delay_sec))/bytes_per_sec (this is just the derivative of the orphaning cost for a given size/delay/bandwidth assuming 600s blocks)
< gmaxwell>
(thats for btc per 1000 bytes, which is usually the unit we use for fees)
< gmaxwell>
For 2.491s/90415 bytes/s which were the straum observed measurements; this function is nearly linear in the domain 0-1mb, 0.0004588 to 0.000450 BTC/kb.
< gmaxwell>
so the irritating thing here is that the negative slope is opposite of what a stable control law needs here. So I think effort to make the behavior sensible needs to just abandon being rationally optimizing; at least for right now.
< zookolaptop>
I don't know what that function looks like.
< zookolaptop>
I can't graph that function in my head.
< zookolaptop>
And see the slope you mean.
< zookolaptop>
And I don't know about the straum observed measurements, but I'm very glad to hear there were empirical measurements,
< zookolaptop>
and I conclude from theexample numbers--0.0004588 BTC/kb--that nobody cares about this. :-)
< zookolaptop>
Because that's too little to care about.
< zookolaptop>
Do you disagree?
< gmaxwell>
over 0-1mb it looks like a straight line. Overall it looks like e^(-x). (starts out high, goes down)
< zookolaptop>
I think my conclusion then is the same as yours: bounded rationality here, or at least "Zooko's estimation of likely behavior of near-future miners", is to ignore the fees.
< gmaxwell>
zookolaptop: yes/no. It's actually considerably higher than gees being paid right now.
< zookolaptop>
Ok.
< zookolaptop>
Oh, it works out to about 0.45 BTC for a full 1 MB block?
< gmaxwell>
Yes.
< zookolaptop>
That's 2% of current reward, instead of the 1% that I estimated from empirical measurements above.
< zookolaptop>
So... I'm *fairly* sure that still most miners don't care? But then we get to the next reward halving, in which case this gets to be 4%?
< gmaxwell>
Yes.
< zookolaptop>
Hm.
< gmaxwell>
I think the fact that miners haven't all gone and computed this themselves and set their minfee higher suggests we still don't _currently_ need to worry that much about short term rational behavior for most miners.
< zookolaptop>
Right, and I my only modification to that point is to argue that not doing this is rational for them.
< zookolaptop>
Because tweaking a config param in their system endangers their operations, which could suddenly cost them $30K/day if it goes wrong,
< zookolaptop>
and the best possible outcome they could get from the "rational" tweak you propose is, like, $50/day or so ?
< gmaxwell>
And many other effects too. Of course, all thats fragile, e.g. someone publishes another version.
< zookolaptop>
And because whoever is focusing their attention on that tweaking should probably get to work and optimize what really matters: reducing costs so that more of the $30K/day revenue is margin instead of lost!
< zookolaptop>
It's too bad you weren't in Hong Kong. The miners panel was awesome.
< zookolaptop>
amiller: same to you!
< gmaxwell>
zookolaptop: well thats part of the tradeoff I'm talking about. The reason that 0.0004etc is the lowest they really should accept is because lower than that increases the odds they lose the 25 BTC subsidy, by more than the fees gained.
< gmaxwell>
In any case I brought that threshold amount as only a point that limiting ourself strictly to short term income maximizing behavior isn't necessary.
< zookolaptop>
Um, isn't that an argument that tweaking this config could improve profit by *more* than $50/day ?
< zookolaptop>
Okay, I accept your point.
< gmaxwell>
And it's not good; because the current "sort by fees, take the target_size off the top" encourages dumb behavior by the users: You should gamble if the target is going to be met, pay very low amounts (just enough to get relayed) ... and then be shocked-shocked! when the target gets met and the system is operating in an totally different region of behavior.
< gmaxwell>
esp since the random block finding makes the fullness at any instant pretty unpredictable.
< gmaxwell>
and also undermines the utility of fee as an anti-spam, e.g. someone keeps a huge backlog of junk and any time some blocks are found in quick succession, miners are dipping into transactions that paid almost nothing.
< zookolaptop>
Sounds reasonable.
< zookolaptop>
So, under the assumptions laid out above, is there a nice simple alternative?
< zookolaptop>
The goals would be: 1. not so bad for miners that they choose to diverge from it, in the short term
< zookolaptop>
which as discussed should be easy to meet.
< zookolaptop>
2. Predictable behavior for users ?
< gmaxwell>
So what bitcoin did pre-2012 was more reasonable; in the sense that it provided gradual back pressure, but it depended on future state and it was strangely order dependant. (e.g. first txn into a block could go in with low fees, then higher paying things were excluded later).
< zookolaptop>
*nod*
< gmaxwell>
perhaps something as simple as having a target-size; sorting blocks by their feerate, and keeping a moving average of the rate at the target size; and using some function of that as a threshold for mining.
< gmaxwell>
so even if there is a fast run of blocks, it won't mine a bunch of spam... and if it takes a long time between blocks, it'll just produce a larger block.
< zookolaptop>
Target blocksize?
< zookolaptop>
Moving average of fees from recent blocks ?
< GitHub130>
[bitcoin] accraze opened pull request #7200: Checks for null data transaction before issuing error to debug.log (master...null-tx-debug) https://github.com/bitcoin/bitcoin/pull/7200
< btcdrak>
gmaxwell: that's a pretty interesting conversation regarding fees.
< Luke-Jr>
gmaxwell: supporting that has been one of my goals with trying to rework the mining code (but as one of many possible options)