< GitHub43>
[bitcoin] TheBlueMatt opened pull request #7174: Don't do mempool lookups for "mempool" command without a filter (master...2015-12-braindead-mempool) https://github.com/bitcoin/bitcoin/pull/7174
< wumpus>
ETA for 0.12 RC1 is 2016-01-06
< wumpus>
0.12.0*
< btcdrak>
wumpus: great.
< Luke-Jr>
paveljanik: :/
< paveljanik>
Luke-Jr, sorry, but this is clear for me now. No need to fight against "wind mills". No need to fight at all.
< Luke-Jr>
paveljanik: but there is, I'm afraid.
< paveljanik>
The only remaining thing in this is why some devs are quite happy to make a decision that has economic effect on some users... In the past this was a huge obstacle...
< paveljanik>
I can accept the fact that it makes their work a lot easier though...
< sipa>
Luke-Jr: if priority is an effective measure against spam, it works (in the default configuration) only for 5% of the block space; miners certainly can change that size during an attack if that is deemed useful, but so can they reenable the priority space altogether
< sipa>
and you're very welcome to work on an alternative that doesn't need special casing a predefined part of the block space
< Luke-Jr>
paveljanik: it doesn't, because now I am forced to maintain it out-of-tree
< Luke-Jr>
paveljanik: and I'm the one who maintains this stuff in the first place
< paveljanik>
technically speaking, from a pure economical view, I do not get it why miners do support priority space at all.
< paveljanik>
and maybe this is the reasoning for other devs about it.
< Luke-Jr>
believe it or not, most miners *do* care to some degree about Bitcoin's success
< paveljanik>
then we have to draw a clear way from this to having prio space in blocks...
< paveljanik>
I think most people do not get it.
< gmaxwell>
Luke-Jr: have you done anything to establish that priority is actually usful for a non-neglibile portion of transactions?
< gmaxwell>
As I laid out the other day, I'd support brining it back if we could show that it was actually useful for users and if we could do so without the huge performance hit.
< Luke-Jr>
because the onus of evidence lies with the one who *doesn't* want to make major changes that are obviously negative.. or we can just remove priority and see how bad the results are. I guess we should just remove the block size limit and see what happens too.
< Luke-Jr>
(and no, I'm not yelling, just extremely frustrated)
< phantomcircuit>
Luke-Jr, either fees become a significant portion of the total block reward and miners acting in their own self interest ignore priority, or we have massively misjudged the economic rational for mining and bitcoin will fail
< phantomcircuit>
personally i like to be optimistic and believe priority is doomed
< gmaxwell>
phantomcircuit: thats not a useful argument and I wish you wouldn't make it.
< gmaxwell>
Because doing so is a distractio[Dn and debases the actually useful argument.
< gmaxwell>
Which is that I have no objective reason to believe that it is of _any_ use today to the vast majority of the users of the system; because unlike us, most don't have years old immobile coins that cut straight through on priority.
< gmaxwell>
Basically, to the extent that priority is doing anything at all; I think it's just acting like a free pass for a small number of oldtimer users; and I think thats wrong.
< Luke-Jr>
do you really use your years-old coins in your hot wallet?
< gmaxwell>
But if a fair number of non-spammy transactions would have priority high enough to matter; then I'm wrong.
< gmaxwell>
A year? two years? yes.
< paveljanik>
gmaxwell, using this argument, this calls for a lot of NEW users to bitcoin to call for "restart" of the network...
< paveljanik>
beucase they do not have access to coins at all.
< gmaxwell>
paveljanik: anyone can pay fees; which is a simple and equitible mechenism available to all commers.
< paveljanik>
I agree with this.
< paveljanik>
The only thing I do not agree is how it was done in the tree 8)
< gmaxwell>
Luke-Jr: and beyond the age, self same wallet is full of coins worth multiple BTC each, which is not generally typical. many users end up with either lots of tiny txins or a few huge ones which lose their priority on their first spend.
< gmaxwell>
AFAIK bitcoin core is the only wallet thats ever supported priority on the send side, and it's never even optimized for using priority wisely.
< Luke-Jr>
looking at my hot wallet quickly..
< Luke-Jr>
0.046 BTC, aged under 2 weeks, is sufficient for priority mining
< Luke-Jr>
or there's a 0.003 BTC aged 40 weeks
< Luke-Jr>
0.005 BTC aged 22 weeks
< Luke-Jr>
0.012 BTC aged 1 week
< midnightmagic>
whew, young coins.
< Luke-Jr>
actually, that last one might not be ready yet
< Luke-Jr>
the 1 week is 0.142 BTC
< phantomcircuit>
Luke-Jr, would you be opposed to simply making the "priority" adjust the effective fee rate?
< Luke-Jr>
these are all reasonably obtainable sizes
< Luke-Jr>
phantomcircuit: it's too late for that in 0.12
< phantomcircuit>
and only calculating it when inserted into the mempool (remembering that things age out of the mempool every 72 hours by default)
< phantomcircuit>
Luke-Jr, we both know miners are all running with a bunch of crazy patches
< Luke-Jr>
phantomcircuit: some are. others are stupidly obstinate about using vanilla with defaults :/
< GitHub32>
[bitcoin] gmaxwell closed pull request #7174: Don't do mempool lookups for "mempool" command without a filter (master...2015-12-braindead-mempool) https://github.com/bitcoin/bitcoin/pull/7174