19:22:24 <sipa> #startmeeting
19:22:24 <lightningbot> Meeting started Thu Jul  5 19:22:24 2018 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:22:24 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:22:34 <sipa> The meeting is dead. Long live the meeting.
19:22:49 <cfields> heh, mutiny is afoot
19:23:05 <sipa> what would an 8-hour rotation thing look like?
19:23:21 <sipa> 3:00, 11:00, 19:00 UTC
19:24:02 <sipa> it's probably too confusing...
19:24:04 <gmaxwell> probably rather than discussing this here someone should go make some proposals (including times in common timezones).
19:24:33 <cfields> those annoying doodle availability polls handle this really well.
19:24:56 <sipa> cfields just volunteered? :)
19:25:16 <cfields> sipa: sure, I'll take a crack at it.
19:25:25 <gmaxwell> that would be good data.
19:25:34 <cfields> as much as people move around, we could potentially re-vote each week and just have a dynamic time-slot...
19:25:40 <gmaxwell> ugh
19:25:42 <cfields> dunno if that'd be too chaotic
19:25:46 <sipa> yes.
19:25:51 <gmaxwell> I'd never remember.
19:25:56 <achow101> way too confusing
19:26:04 <sipa> i already miss meetings when i'm traveling
19:26:26 <cfields> k, fair enough. Will keep it simple.
19:26:30 <achow101> I already miss meetings when not traveling
19:26:33 <sipa> any other topics?
19:27:46 <sipa> #topic Min relay fee (provoostenator)
19:27:52 <gmaxwell> Someone was suggesting minrelay fee. There was a conversation on twitter I was commenting about.
19:27:55 <gmaxwell> that.
19:28:39 <booyah> vote on-chain for the time by donating to one of 24 addresses \o/
19:28:54 <sipa> good idea
19:28:59 * sipa creates 24 addresses!
19:29:00 <gmaxwell> I'm not sure how much there is to say, really our infrastructure is setup to have a minimum.  The amount of relay-spam per $ tends to infinity as the fee goes to zero.
19:29:51 <luke-jr> gmaxwell: I think the idea was that mempool size limits would effectively limit the amount and set an automatic min relay fee based on demand
19:29:55 <sipa> min-relay-fee has limited impact, because if tx rate goes up as a result, dynamic feerate kicks in
19:29:57 <gmaxwell> I admit that I kinda want to decrease it just to get people to stop thinking "1" is special.
19:30:05 <sipa> but min incremental fee isn't
19:30:15 <sipa> that's a fundamental relay cost metric
19:30:17 <gmaxwell> sipa: yes, though not when the mempool limits are too large.
19:30:44 <gmaxwell> The last time I saw a non-zero automatic min relay fee was months ago, IIRC.
19:31:36 <gmaxwell> lack of mempool sync also exacerbates this... even if there is enough data to fill, any given node won't have been online long enough to have it.
19:31:55 <aj> gmaxwell: going from 1 to 0.5 or 0.1 would be nice, i've seen suggestions it doesn't work right in the code somewhere though?
19:32:07 <gmaxwell> aj: those suggestions were confused.
19:32:11 <gmaxwell> it's fine.
19:32:20 <gmaxwell> units in bitcoin are in sat per 1000 bytes...
19:32:25 <booyah> 0.5 sat/byte? then everyone will assume thisis still the magic 1, but halved "because segwit" :)
19:32:32 <gmaxwell> the "1s/b" thing is something varrious websites came up with.
19:33:01 <aj> yeah, my node's been set at 50s/kB for a while, but everything it connects to is 1000s/kB so it doesn't do much
19:33:10 <gmaxwell> aj: and even if the units internally were an issue, it would be trivial to go around and rescale them.
19:33:55 <sipa> we internally represent everything as sat/kB
19:34:05 <booyah> fun fact, there are wallet like Mycelium that sometimes misscalculate and when preparing 1S/B tx, end up with 0.97.. S/B actuall tx and can not broadcast it currently
19:34:41 <achow101> booyah: really? they should fix that
19:34:41 <gmaxwell> booyah: How the heck do they do that?
19:34:46 <aj> yeah, xapo had a bug where the sigs were slightly bigger than estimated, and 1s/B target ended up at 0.9something s/B and wouldn't propogate
19:34:52 <gmaxwell> ...
19:35:02 <gmaxwell> ah, they have the wrong number for the worst case sig size.
19:35:05 <booyah> gmaxwell: achow101 dunno why, just seen it happen. AFAIR it eventually worked out when manually broadcasting from core after really long time
19:35:05 <aj> yep
19:35:07 <achow101> gmaxwell: sigs larger than expected probably. I had this problem once with coin selection simulations
19:35:08 <luke-jr> not sure that's something we can fix for them
19:35:31 <gmaxwell> they probably just took the size of the first sig they saw, rather than using the actual worst case.
19:35:39 <luke-jr> if it was 0.5 s/B, they'd end up with 0.49
19:35:53 <gmaxwell> yea, nothing we do will fix that, I was just curious. :P
19:36:46 <aj> https://www.blockchain.com/en/btc/tx/7f6d969774a6806ed136f892ad3ae8a32ba1dd55378942a00d117ca2837431b1
19:37:08 <aj> having a backlog of fees so the target isn't also the minimum would fix it :)
19:37:13 <aj> backlog of txes i mean
19:37:42 <gmaxwell> In any case, I don't see any harm in halving it. it would probably be prudent, esp as the bitcoin price has stably been something like 6x higher than the ATH at the time the current value was set.
19:37:54 <booyah> gmaxwell: people whill think it is halved "due to segwit, hurrr"
19:38:04 <booyah> 0.4 or 0.6 "fixes" that, if you care for it
19:38:08 <gmaxwell> booyah: oh well, can't cure stupid. :P
19:38:17 <luke-jr> IMO, unless we're going to aim for a minrelayfee-less design, it's a mostly harmless opportunity to let users campaign to have other users change the setting instead of using centrally-planned defaults; and if the default is changed, it'd be best to let some user PR it instead of a regular dev
19:38:28 <booyah> already there is confusing is it s/VB or s/B
19:38:40 <sipa> luke-jr: it reduces compact block relay efficiency though
19:38:49 <achow101> booyah: everything in core is s/vb IIRC
19:38:52 <sipa> node operators generally have an incentive to pick the same values as miners
19:39:04 <booyah> and above you said "sat/kB" :P see, everyone is confused about this
19:39:17 <luke-jr> sipa: vice-versa; miners have an incentive to pick the same as users
19:39:24 <gmaxwell> luke-jr: Trying to make things work minrelayfeeless is probably not worsth the effort.
19:39:38 <sipa> 1 sat/vB is already very low
19:39:42 <luke-jr> gmaxwell: I tend to agree
19:39:48 <sipa> (my personal opinion)
19:39:50 <gmaxwell> There is a bunch of stupid behavior that having a low but non-zero minimum avoids.
19:40:20 <sipa> booyah: fees are always with vbytes, i don't mention the "v"
19:41:07 <gmaxwell> I think at least half the benefit of decreasing it would be just shaking this idea that 1 is special. :P
19:41:35 <aj> sipa: in dollar terms, median fee rate was lower prior to about july 2016 (2c/tx versus 10c/tx) per https://bitinfocharts.com/comparison/bitcoin-median_transaction_fee.html#log fwiw
19:41:37 <luke-jr> anyway, UASF showed that users will take action when they need to; I think encouraging such user-driven action would be a good thing
19:41:41 <gmaxwell> but also because the mempool is frequently empty now. Some more consolation might be encouraged at lower feerates.
19:41:48 <booyah> as an user, I can confirm it would fix that idea. (though 0.4 might be better)
19:41:52 <luke-jr> especially when the side effects of disagreement are harmless
19:42:10 <gmaxwell> aj: keep in mind that segwit signnificantly reduced transaction vsizes for users that use it.
19:42:29 <aj> gmaxwell: this chart is per transaction, not per size aiui
19:42:33 <gmaxwell> luke-jr: I don't think there is 'need' here at all.
19:42:37 <sipa> so what are we discussing here?
19:42:39 <aj> gmaxwell: (i haven't checked the numbers myself)
19:43:00 <gmaxwell> aj: well then that charts useless, because e.g. it would say fees went up when users simply started batching instead of behaving stupidly.
19:43:08 <aj> gmaxwell: sure
19:43:10 <sipa> my personal opinion is that it's fine to encourage people to look into this and choose their own minima, but there's really not a big deal
19:43:45 <gmaxwell> sipa: dunno. people noticing the mempool frequently being near empty, suggested lowering the fee. PT suggested doing nothing unless eliminating it entirely, and I think that it would be a waste of time to try to do that.
19:43:50 <luke-jr> gmaxwell: I agree; the need however is not common, so encouraging users to act when only desire rather than need may be good
19:43:50 <aj> sipa: without nodes actively using min fee rate to choose who to peer with, user choice seems pointless?
19:44:35 <luke-jr> aj: that assumes >7/8 won't change it
19:44:46 <gmaxwell> and since the bitcoin price has consistently been up a lot compared to in the past, even considering the segwit offset, it didn't seem unreasonable to me to lower it some.
19:44:58 <sipa> okay
19:45:46 <sipa> someone suggest something and create a PR?
19:46:03 <gmaxwell> K.
19:46:24 <sipa> °C.
19:46:31 <Varunram> lol
19:46:47 <sipa> any other topics?
19:46:56 <gmaxwell> I'll PR doing something around halving it. (maybe I'll take booyah's 60% suggestion, I'll research what bitcoin price was when it got set where it was, and factor in segwit, yadda yadda)
19:49:07 <sipa> going once
19:49:12 <achow101> *crickets*
19:49:56 <r-f> ~.~.~.~.
19:50:01 <sipa> going twice
19:51:21 <sipa> #endmeeting