< kallewoof>
Any idea why the linker would give 'undefined reference' even though the .a file containing the reference is included in the command?
< kallewoof>
Also only happening in travis, not when building locally.
< sipa>
kallewoof: the order of arguments to the linker matters
< kallewoof>
sipa: Yeah I know. I tried shuffling around, but it didn't help in this case.
< kallewoof>
sipa: What's weird about it is, this literally works on all machines on my end. Linux and mac. Only travis is failing. Linkers are flakey beasts...
< kallewoof>
Failure happens on ubuntu < 17.10 and >= 16.04 apparently. *shakes head* So random. At least I have a machine to work with now.
< kallewoof>
Figured it out.
< swap>
hi where is the mining algo stored on the repo? thanks.
< bitcoin-git>
bitcoin/master 2dcd7b4 mruddy: logging: avoid nStart may be used uninitialized in AppInitMain warning
< bitcoin-git>
bitcoin/master c9eb8d1 Wladimir J. van der Laan: Merge #13577: logging: avoid nStart may be used uninitialized in AppInitMain warning...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13577: logging: avoid nStart may be used uninitialized in AppInitMain warning (master...dev1) https://github.com/bitcoin/bitcoin/pull/13577
< gmaxwell>
petertodd: re: removing the minimum relay fee entirely.. I think to do that we'd need to eliminate time based mempool expiration, implement mempool sync, and probably reduce mempool sizes.
< gmaxwell>
petertodd: the issue is that if we just remove the limit, what will happen is that during quiet periods the limit will effectively become zero (or close enough to it) then a bunch of spam will flood in and get relayed, then expire before it gets mined.
< gmaxwell>
so then a bunch of bandwidth will be wasted on things with no realistic chance of getting mined.
< gmaxwell>
If expiration were gone, and we actively synced, the network would keep a constant queue, and then that would keep the rates from falling. ... and then maybe that would be enough. maybe.
< gmaxwell>
ISTM that doing not what you said, and just lowering it 2x or 10x or whatever, would be a lot simpler.
< provoostenator>
gmaxwell: how long is mempool expiration? It takes 1 day to mine a 300 MB mempool if the spammer uses SegWit, which I guess they wouldn't...
< gmaxwell>
provoostenator: it takes 1 day to mine a 300 MB if no more transactions are coming in!
< gmaxwell>
it takes infinitely long to mine a 300 MB mempool if there is a flux of higher fee txn equal to the network capacity.
< gmaxwell>
Expiration right now is two weeks.
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Jul 5 19:00:13 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
so if there are features that still need to make it in, we certainly have to make them high prio for review
< gmaxwell>
sipa: Is #12196 'compatible' in what it matches with your new work on wallet scanning? I haven't looked at that PR for a while, but I recall that at one point it expected you to provide pubkeys as the thing you scan for.
< aj>
wumpus: #13547 or #12458 would be nice to have for 0.17, as would #13072 (though that needs a rebase now)
< gribble>
https://github.com/bitcoin/bitcoin/issues/13547 | Make signrawtransaction* give an error when amount is needed but missing by ajtowns · Pull Request #13547 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/11658 | During IBD, when doing pruning, prune 10% extra to avoid pruning again soon after by luke-jr · Pull Request #11658 · bitcoin/bitcoin · GitHub
< wumpus>
gmaxwell: the xpub stuff was removed for that reason
< sipa>
gmaxwell: yes, discussed in previous meeting
< gmaxwell>
sipa: Thanks!
< wumpus>
so that when it gets added it's compatible with sipa's proposal
< sipa>
i'm almost done with an implementation for "output descriptors" which we'll just be able to plug into scantxoutset
< wumpus>
nice!
< sipa>
i'd very much like to see PSBT in 0.17
< wumpus>
aj: ok, thanks
< wumpus>
me too
< wumpus>
I'll add that to high priority
< achow101>
wumpus: #13557 for high prio please (psbt)
< gribble>
https://github.com/bitcoin/bitcoin/issues/13298 | Net: Random delays *per network group* to obfuscate transaction time by naumenkogs · Pull Request #13298 · bitcoin/bitcoin · GitHub
< wumpus>
achow101: done
< nmnkgl>
This is probably for high prio.
< wumpus>
so does aeveryone agree with the PRs that aj proposes?
< wumpus>
nmnkgl: I think that needs a lot of discussion still
< wumpus>
nmnkgl: there's some security worries
< wumpus>
nmnkgl: agree it's important, but not something to rush for 0.17
< wumpus>
though if other people think so I'm happy to concede
< sipa>
i think sdaftuar and nmnkgl have worked it out pretty much
< gmaxwell>
I think that 13298 is basically done? no?
< nmnkgl>
I think it is.
< wumpus>
ok
< gmaxwell>
I'm always happy to see stuff like that get out sooner rather than later, since it'll take months for its effects on the network to be observed.
< wumpus>
adding it for review then
< sipa>
nmnkgl: rebase it though
< Randolf>
Hello.
< r-f>
hello. any chance for #13414 gitlab support, it's like 2 screens of python only (plus comments)
< wumpus>
r-f: yes, makes sense, but not relevant to 0.17 I think
< sipa>
yeah, that seems independent of releases
< wumpus>
ok added al the PRs mentioned by aj too
< wumpus>
that means he now has two things on the high priority list though
< wumpus>
sipa: right
< sipa>
i'll do an effort to review all of them
< sipa>
(so ack from me on that)
< wumpus>
ok :)
< wumpus>
#topic Alternating meeting time
< wumpus>
(provoostenator)
< provoostenator>
My suggestino would be something trivial, e.g. alternate by 12 hours every week
< provoostenator>
e.g. 9:00 and 19:00 UTC
< provoostenator>
(uhh, 7:00 UTC and 19:00 UTC)
< wumpus>
sgtm
< provoostenator>
With the day such that it is thursday morning Asia
< sipa>
7 UTC is pretty bad for eastcoast, though any time will hurt someone
< aj>
thursday evening asia?
< provoostenator>
Sorry, yes, what aj says.
< aj>
(it's friday morning australia/asia now, 700 utc thursday is thursday afternoon)
< wumpus>
sipa: yes, it would be alternatingly bad for asia and eastcoast then
< achow101>
I tend to nack alternating meeting times as that will confuse people and result in probably less attendance as people either forget or get the meeting time switched
< gmaxwell>
unfortunately there is no alternating scheme where a large group of regulars aren't impacted.
< luke-jr>
sipa: depends on who would otherwise come
< achow101>
7 UTC is bad for americas in general
< sipa>
midnight westcoast, 3am eastcoast
< cfields>
I'm ok with awkward east-coast times, but I assume I'm in the minority
< wumpus>
the problem is that the people in favor of the time will likely not be here now
< wumpus>
it's unfair :-)
< phantomcircuit>
probably just need a list of everybody who is likely to attend and their timezone to figure this one out
< phantomcircuit>
wumpus, lul
< gmaxwell>
phantomcircuit: it's bad regardless.
< clarkmoody>
Is there a way to have an Asia meeting prior to the Europe/USA meeting and review minutes prior to this one?
< gmaxwell>
sdaftuar: morcos: I'm guessing you're not going to be showing up between 3am and 4am.
< gmaxwell>
:P
< phantomcircuit>
i more meant for figuring out the time rather than doing an alternating schedule
< aj>
a 3-phase cycle of 8 hours ought to make everyone able to attend 2 of 3 meetings :-/
< wumpus>
we're getting kicked out here
< wumpus>
can someone else take the chair please
< sipa>
endmeeting and i'll start a new one
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Jul 5 19:22:21 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa>
The meeting is dead. Long live the meeting.
< cfields>
heh, mutiny is afoot
< sipa>
what would an 8-hour rotation thing look like?
< sipa>
3:00, 11:00, 19:00 UTC
< sipa>
it's probably too confusing...
< gmaxwell>
probably rather than discussing this here someone should go make some proposals (including times in common timezones).
< cfields>
those annoying doodle availability polls handle this really well.
< sipa>
cfields just volunteered? :)
< cfields>
sipa: sure, I'll take a crack at it.
< gmaxwell>
that would be good data.
< cfields>
as much as people move around, we could potentially re-vote each week and just have a dynamic time-slot...
< gmaxwell>
ugh
< cfields>
dunno if that'd be too chaotic
< sipa>
yes.
< gmaxwell>
I'd never remember.
< achow101>
way too confusing
< sipa>
i already miss meetings when i'm traveling
< cfields>
k, fair enough. Will keep it simple.
< achow101>
I already miss meetings when not traveling
< sipa>
any other topics?
< sipa>
#topic Min relay fee (provoostenator)
< gmaxwell>
Someone was suggesting minrelay fee. There was a conversation on twitter I was commenting about.
< gmaxwell>
that.
< booyah>
vote on-chain for the time by donating to one of 24 addresses \o/
< sipa>
good idea
< * sipa>
creates 24 addresses!
< 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.
< 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
< sipa>
min-relay-fee has limited impact, because if tx rate goes up as a result, dynamic feerate kicks in
< gmaxwell>
I admit that I kinda want to decrease it just to get people to stop thinking "1" is special.
< sipa>
but min incremental fee isn't
< sipa>
that's a fundamental relay cost metric
< gmaxwell>
sipa: yes, though not when the mempool limits are too large.
< gmaxwell>
The last time I saw a non-zero automatic min relay fee was months ago, IIRC.
< 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.
< 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?
< gmaxwell>
aj: those suggestions were confused.
< gmaxwell>
it's fine.
< gmaxwell>
units in bitcoin are in sat per 1000 bytes...
< booyah>
0.5 sat/byte? then everyone will assume thisis still the magic 1, but halved "because segwit" :)
< gmaxwell>
the "1s/b" thing is something varrious websites came up with.
< 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
< gmaxwell>
aj: and even if the units internally were an issue, it would be trivial to go around and rescale them.
< sipa>
we internally represent everything as sat/kB
< 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
< achow101>
booyah: really? they should fix that
< gmaxwell>
booyah: How the heck do they do that?
< 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
< gmaxwell>
...
< gmaxwell>
ah, they have the wrong number for the worst case sig size.
< booyah>
gmaxwell: achow101 dunno why, just seen it happen. AFAIR it eventually worked out when manually broadcasting from core after really long time
< aj>
yep
< achow101>
gmaxwell: sigs larger than expected probably. I had this problem once with coin selection simulations
< luke-jr>
not sure that's something we can fix for them
< gmaxwell>
they probably just took the size of the first sig they saw, rather than using the actual worst case.
< luke-jr>
if it was 0.5 s/B, they'd end up with 0.49
< gmaxwell>
yea, nothing we do will fix that, I was just curious. :P
< aj>
having a backlog of fees so the target isn't also the minimum would fix it :)
< aj>
backlog of txes i mean
< 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.
< booyah>
gmaxwell: people whill think it is halved "due to segwit, hurrr"
< booyah>
0.4 or 0.6 "fixes" that, if you care for it
< 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
< booyah>
already there is confusing is it s/VB or s/B
< sipa>
luke-jr: it reduces compact block relay efficiency though
< achow101>
booyah: everything in core is s/vb IIRC
< sipa>
node operators generally have an incentive to pick the same values as miners
< booyah>
and above you said "sat/kB" :P see, everyone is confused about this
< luke-jr>
sipa: vice-versa; miners have an incentive to pick the same as users
< gmaxwell>
luke-jr: Trying to make things work minrelayfeeless is probably not worsth the effort.
< sipa>
1 sat/vB is already very low
< luke-jr>
gmaxwell: I tend to agree
< sipa>
(my personal opinion)
< gmaxwell>
There is a bunch of stupid behavior that having a low but non-zero minimum avoids.
< sipa>
booyah: fees are always with vbytes, i don't mention the "v"
< gmaxwell>
I think at least half the benefit of decreasing it would be just shaking this idea that 1 is special. :P
< 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
< gmaxwell>
but also because the mempool is frequently empty now. Some more consolation might be encouraged at lower feerates.
< booyah>
as an user, I can confirm it would fix that idea. (though 0.4 might be better)
< luke-jr>
especially when the side effects of disagreement are harmless
< gmaxwell>
aj: keep in mind that segwit signnificantly reduced transaction vsizes for users that use it.
< aj>
gmaxwell: this chart is per transaction, not per size aiui
< gmaxwell>
luke-jr: I don't think there is 'need' here at all.
< sipa>
so what are we discussing here?
< aj>
gmaxwell: (i haven't checked the numbers myself)
< 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.
< aj>
gmaxwell: sure
< 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
< 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.
< 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
< aj>
sipa: without nodes actively using min fee rate to choose who to peer with, user choice seems pointless?
< luke-jr>
aj: that assumes >7/8 won't change it
< 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.
< sipa>
okay
< sipa>
someone suggest something and create a PR?
< gmaxwell>
K.
< sipa>
°C.
< Varunram>
lol
< sipa>
any other topics?
< 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)
< sipa>
going once
< achow101>
*crickets*
< r-f>
~.~.~.~.
< sipa>
going twice
< sipa>
#endmeeting
< lightningbot>
Meeting ended Thu Jul 5 19:51:21 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< provoostenator>
(back, had to leave for physical reasons)
< provoostenator>
minrelay fee has been 1 for a long time so in a way it _is_ special. In particular if the wallet also allows lower values, users might end up with stuck transactions because none of their peers relay them.
< provoostenator>
Which is made worse by incomplete RBF functionality. So wallet should probabyl hold on to this magic 1 value for a bit longer.
< aj>
provoostenator: shouldn't the fee estimator keep the 1 value in that case anyway?
< provoostenator>
No, 0.5 might get mined for folks who are well connected.
< aj>
provoostenator: if you're well connected, that's fine; if you didn't see it in the mempool before it got mined because you're not well connected, also fine?
< provoostenator>
Ok, but the current fee estimator isn't that smart, is it?
< aj>
think it is
< provoostenator>
Let me look at the documentation... :-P
< provoostenator>
I've actually shot myself in the foot a while ago by having one node (A) exclusively connect to a gateway node (B) which had 1.2 sat/byte as a minimum , while the fee estimator of (A) thought 1 sat/byte would be fine.
< provoostenator>
I may however have ignored the fee estimator and checked the minimum fee box instead, still.
< aj>
oh, that's a good point
< provoostenator>
It could be solved if the wallet indeed was smart enough to warn "Although miner fees are low, there is not a single transaction in your mempool at the fee rate you're trying to use, it may get stuck"
< aj>
even if it didn't get stuck, you'd get that behaviour if miners were getting lots of fees out-of-band
< aj>
well similar behaviour
< provoostenator>
Yes, but out-of-band fees seem less common for now than blog posts with "tips how to spend less on bitcoin fees".
< aj>
yeah, sorry; i mean "such a warning might be relevant even when you're well connected"
< provoostenator>
Yes
< provoostenator>
I assume peers don't and shouldn't announce their relay fees due to fingerprinting concerns?
< aj>
peers already announce their min fees so you can avoid sending them txes they'll ignore
< sipa>
they do announce dynamic fees
< sipa>
bip 133
< provoostenator>
Can that be made cumulative somehow? Like they announce min(their dynamic fee, n degrees dynamic fee)
< sipa>
that seems exploitable
< provoostenator>
Yeah, and I guess it could also get stuck.
< aj>
provoostenator: max(my-dynamic-fee, 0.9*min(peers-dynamic-fees)) or something could be amusing i guess?
< provoostenator>
When mempool isn't full it's probably easiest to just use the lowest fee found in it as the threshold where the wallet warns the user. More tricky if it's full.
< provoostenator>
Right now I think it doesn't warn anyway if the user selects a fee that's lower than what their own mempool accepts.