< sipa>
dcousens: i think that will be easy to support after we have lightweight mode (which will require that the wallet can also ask for a block to be downloaded)
< sipa>
concept ack, but it may be far out
< dcousens>
sipa: fair enough :), so many other things to fix first, and data duplication isn't that bad in the mean time. Users could still run pruned nodes, they simply have to do it *after* the initial sync
< dcousens>
aka, could use the pruning RPC
< gmaxwell>
dcousens: then you want manual pruning, no
< dcousens>
gmaxwell: well, its not ideal, but it works - unless the `indexd` db is lost, then you need to reset both.
< dcousens>
I think some of the bigger deployments for `indexd` this are either imaging monthly anyway, so they run the pruning about that length
< wumpus>
MarcoFalke: yes, it seems we're not going to get around backporting some of the support PRs, I personally think backporting #10756 is ok, not pretty but trying to patch everything up while backporting is likely more risky than doing that
< BlueMatt>
sipa: sorry, I think there's lots of net context here that is being missed :(
< BlueMatt>
sipa: I have, on a few branches, an explicit goal of net_processing not relying on *when* FinalizeNode is called
< BlueMatt>
plus the ForEachNode garbage needs to die
< sipa>
agree on the last point
< BlueMatt>
where CNodeState will have the CNode* in it (but it is much more restricted as a "socket reference" essentially - a thing you pass to CConnman to tell it where to send a message)
< sipa>
but FinalizeNode should, regardless of when it is called, call the scheduler to remove any pending actions for that peer, no?
< BlueMatt>
but eg the pr I linked to to remove the cs_vNodes lock in ForEachNode almost breaks that logic anyway
< BlueMatt>
scheduler?
< BlueMatt>
FinalizeNode isnt on scheduler?
< BlueMatt>
since it takes things out of vNodes, calls FinalizeNode on it, but the ForEachNode function will be working on a copy of vNodes
< BlueMatt>
cfields: also
< sipa>
BlueMatt: the issue here is that there is an action called from the scheduler which may be running while a node is being finalized, no?
< BlueMatt>
in this case its not, because cs_main, but, yes
< BlueMatt>
keep in mind also that scheduler is allowed to be multiple threads
< sipa>
sure, but thinking a bit ahead when cs_main is broken up
< BlueMatt>
even if it isnt atm
< sipa>
sure
< sipa>
hmm, i see - the scheduled action isn't specific for the peer
< BlueMatt>
when interacting with CConnman I think we should be making essentially 0 assumptions about order of operations cause net frameworks are always all kinds of random
< BlueMatt>
anyway, I think the pr is more than fine as-is
< BlueMatt>
it should not be considered a bug for the nodestate to be missing during a ForEachNode
< BlueMatt>
at least in new code
< sipa>
BlueMatt: yes, i withdraw my comment about the assert - violating it is much less of a assumption failure then i thought
< promag>
for those that have 1 min free, I would like to get some concept ack/nack in #11402
< * MarcoFalke>
picks up a / and hands it to cfields
< wumpus>
hehe
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11596: Add missing cs_main locks when accessing chainActive (master...chainActive) https://github.com/bitcoin/bitcoin/pull/11596
< bitcoin-git>
[bitcoin] kallewoof opened pull request #11597: [trivial] Fix error message & styling for when new fee rate < min mem… (master...171102-feebumper-lowerfeetxt) https://github.com/bitcoin/bitcoin/pull/11597
< jonasschnelli>
Is the meeting now in 1h21min?
< jonasschnelli>
(wintertime)
< sdaftuar>
20 minutes
< jonasschnelli>
Thanks
< sipa>
*drumroll*
< achow101>
meeting?
< BlueMatt>
*rimshot*
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Nov 2 19:01:26 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
the other one is just the backports which need to be done to support all that
< morcos>
i think whichever we can't merge to master and backport right now, we need to just skip..
< achow101>
backports is failing travis right now
< morcos>
BlueMatt: backports for all others are fine... sdaftuar has tiny test fix
< BlueMatt>
yea
< wumpus>
ok
< morcos>
although they could use more review, both sdaftuar and ryanofsky are reviewing now
< morcos>
so we should just make decisions on those last 3 PR's.. 11100 is in master, so question is only whether to add it to backports? any objections?
< wumpus>
none apparently
< gmaxwell>
I really want to see 11100 appear in a release.
< BlueMatt>
backports are already huge, but thats a simple pr and would be very nice to have
< gmaxwell>
It's not the only misconfig now (I see blocks that clearly have minrelay fee cranked up-- e.g. legacy of 0.11-era mempool bloat attacks) but it's the biggest one.
< wumpus>
although I think we should stop moving the goalposts
< MarcoFalke>
ok, will amend the pull with sdaftuar's fix and 11100
< sipa>
11560 is mergable i think
< gmaxwell>
Well, if there are any issues in backporting, feel free to drop IMO.
< BlueMatt>
agreed
< wumpus>
the point of 0.15.0.2 is to protect against an immediate problem, and we should release it if it improves the situation anything from 0.15.0.1
< BlueMatt>
ok, last point of order then is the libevent fix
< BlueMatt>
cfields: you want to say anything?
< jtimon>
ack on #11100 backport
< gribble>
https://github.com/bitcoin/bitcoin/issues/11100 | Fix confusing blockmax{size,weight} options, dont default to throwing away money by TheBlueMatt · Pull Request #11100 · bitcoin/bitcoin · GitHub
< cfields>
i've narrowed the workaround even further, it basically just affects a single stable release
< jtimon>
curious, why backport all in one pr?
< BlueMatt>
(the release that people have been switching to as they upgrade ubuntu, afaiu, fwiw)
< wumpus>
jtimon: because many things depend on each other
< promag>
hi
< MarcoFalke>
jtimon: I am not going to push to non-master branches
< wumpus>
jtimon: many of them are not trivial, stand-alone backports... if only
< MarcoFalke>
also what wumpus said
< cfields>
grr, sorry, irc client fell off
< wumpus>
this way there's at least the chance to review, and for travis to test the backported code
< * sipa>
picks up the irc lcient and hands it to cfields
< MarcoFalke>
So action merge and bp 11560?
< sipa>
MarcoFalke: ack
< achow101>
+1
< jonasschnelli>
BTW: should we also consider upgrading depends openssl due to CVE-2017-3736?
< jonasschnelli>
Only BIP70 stuff is affected though
< jonasschnelli>
but we are using open ssl 1.0.1k which is no longer maintained
< sipa>
The amount of resources
< sipa>
required for such an attack would be very significant and likely only
< sipa>
accessible to a limited number of attackers. An attacker would
< sipa>
additionally need online access to an unpatched system using the target
< sipa>
private key in a scenario with persistent DH parameters and a private
< sipa>
key that is shared between multiple clients.
< gmaxwell>
I'd rather be spending effort into further eliminating openssl. :)
< jonasschnelli>
0.15.1 should be fine IMO
< jtimon>
is anybody using bip70?
< jonasschnelli>
BIP70 without openssl is non-trivial to impossible
< jonasschnelli>
we could remove BIP70 support... *duck* (luke-jr)
< achow101>
jtimon: I'm pretty sure bitpay does
< BlueMatt>
we could remove the ssl-checking part of bip70
< jonasschnelli>
(no tests, no active maintenance)
< morcos>
cfields: are there any changes to our httpserver/libevent code between master and 0.15, or its fine to just backport 11593 without thinking abou tit
< jtimon>
achow101: thanks
< BlueMatt>
and just treat it as a "better payment field"
< gmaxwell>
meh, lets not discuss that now.
< jonasschnelli>
Yes
< cfields>
morcos: i'll double-check, but 99% a dumb backport is enough
< bitcoin-git>
bitcoin/master 2d4327d Suhas Daftuar: net: Allow connecting to extra outbound peers
< bitcoin-git>
bitcoin/master db32a65 Suhas Daftuar: Track tip update time and last new block announcement from each peer
< bitcoin-git>
bitcoin/master ac7b37c Suhas Daftuar: Connect to an extra outbound peer if our tip is stale...
< jonasschnelli>
I'd say action: upgrade openssl depends for 0.15.1 or 0.16
< morcos>
woohoo!
< bitcoin-git>
[bitcoin] laanwj closed pull request #11560: Connect to a new outbound peer if our tip is stale (master...2017-10-stale-tip-new-peer) https://github.com/bitcoin/bitcoin/pull/11560
< achow101>
oh, look at that!
< jonasschnelli>
\o/
< sdaftuar>
yay!
< gmaxwell>
our work here is done.
< wumpus>
whee
< wumpus>
yep, ship it
< sdaftuar>
we're shipping master right
< cfields>
"This only affects processors that support the BMI1, BMI2 and ADX extensions like
< cfields>
Intel Broadwell (5th generation) and later or AMD Ryzen."
< gmaxwell>
:P
< achow101>
it compiles, shit it
< achow101>
*ship
< sipa>
ok, backports are go
< wumpus>
yes, we're releasing 0.16.0.2 instead of 0.15.0.2 :p
< morcos>
achow101: exactly
< sipa>
i do want to stress that these backports may be non-trivial compared to most point releases
< wumpus>
yes, definitely
< BlueMatt>
yea :(
< sipa>
and we should review the patches, and possibly still decide to drop some
< gmaxwell>
all the more reason to get a RC out stat.
< cfields>
right. in addition to the usual checks, everyone should check their own fixes
< meshcollider>
its massive for a point-point release lol
< wumpus>
yes, that's what rcs are for
< sipa>
absolutely
< wumpus>
meshcollider: it's completely silly for a .0.2
< achow101>
we've got two weeks
< MarcoFalke>
its not even a point-release
< sipa>
just pointing out that we're not really done
< meshcollider>
so rc today?
< cfields>
wumpus: don't forget the version bumps :)
< BlueMatt>
hopefully? review backports
< sipa>
meshcollider: review backports first
< gmaxwell>
it's only a pointpoint release because we communicated the extended SW wallet support would be in 0.15.1. Otherwise this would be 0.15.1.
< wumpus>
gmaxwell: I understand, but I expected a much smaller release
< sipa>
wumpus: so did we all, i think
< wumpus>
normally we don't even publically announce minor-minor releases, let alone have an extended rc cycle
< wumpus>
but that's definitely needed now
< achow101>
note to self for future: don't promise things in version numbers
< jtimon>
achow101:
< jtimon>
+1
< sipa>
we should have called it 0.15.$SEGWIT
< wumpus>
achow101: good point
< gmaxwell>
beyond the B2X split fix, I think this release is pretty trivial.
< sipa>
but i agree, achow101
< gmaxwell>
fixes*
< wumpus>
don't promise things, period :)
< jonasschnelli>
^ (especially not on a timeline)
< gmaxwell>
well if you'd be more comfortable calling it 0.15.1 I'd support that too. it's not like it's a big deal to say 'nope segwit stuff got pushed back due to snafu-mitigation'
< jtimon>
I would prefer to call it 0.15.1, but not a big deal\
< cfields>
from now on, we'll promise new features at block heights rather than timestamps :p
< sipa>
we could of course also include #11167 (support for sending to bech32) and call it 0.15.1 *ducks*
< bitcoin-git>
bitcoin/0.15 f224cbc Wladimir J. van der Laan: build: Bump version to 0.15.1...
< achow101>
0.15.1 is fine with me
< wumpus>
an actual point release, this feels much better
< meshcollider>
wumpus: I mean an issue like 11054
< wumpus>
release notes are certainly important, though they don't need to be ready for rc1
< morcos>
one comment about the version
< morcos>
i talked to Alyssa from CoinDesk abou tthis
< morcos>
not sure if they published an article or about to
< wumpus>
meshcollider: no, we don't make topics that for minor releases generally
< meshcollider>
ah ok
< jtimon>
morcos: should be easy to correct their article, no?
< wumpus>
if you're in contact with them please let them know this is not the .1 they're expecting
< jonasschnelli>
morcos: Maybe tell here that the SW2X aware version is now 0.15.1 and SW wallet version is *unknown" for now?
< morcos>
yeah i don't see anything majorly published, i'll tell her now
< morcos>
who knows if she was going to even say anything
< jtimon>
just s/0.15.1/0.15.2 and s/0.15.0.2/0.15.1/
< wumpus>
yes, segwit wallet delayed due to necessary s2x preparations :(
< BlueMatt>
s/necessary/hopefully unecessary, though possibly necessary/
< sipa>
arguably these were necessary preprations anyway - they're not specific to 2X
< BlueMatt>
indeed
< wumpus>
BlueMatt: better to be prepared at least
< BlueMatt>
we now have outbound peer rotation!
< sipa>
we just had to prioritize these P2P improvements
< jonasschnelli>
but more pressing since SW2X
< BlueMatt>
:bottlepop emoji"
< BlueMatt>
:
< wumpus>
sipa: sure, but the reason this was prioeritized over segwit I mean
< gmaxwell>
yes, are generally good improvements which we should have done eventually regardless.
< morcos>
ok i emailed her, i'm fine to switch it, i just wanted to be sure there wasn't already some article out there
< jonasschnelli>
Who cares. :)
< sipa>
i went back and edited some reddit comments i made about 0.15.1
< sipa>
i think it's fine
< gmaxwell>
morcos: inaccurate details in a press article about bitcoin?! Good thing you prevent that from ever happening.
< jonasschnelli>
Things are in-move....
< BlueMatt>
lolol
< wumpus>
then after this we can do segwit wallet as 0.15.2, or 0.16.0, depending on what makes sense in the time frame that things are ready
< jonasschnelli>
Yeah.. I would not promis 0.15.2 now (even if it's very likely to happen with SW Wallet)
< sipa>
ya
< wumpus>
jonasschnelli: indeed
< jtimon>
perhaps we could consider doing 0.16 faster instead of doing a 0.15.2 release with segwit?
< jonasschnelli>
features are not tied to releases... releases are tied to the planed timeframe
< jtimon>
I guess it would be a bad precedent
< BlueMatt>
ok, more topics?
< wumpus>
jtimon: I'm ok with that - though the original reasoning was exactly opposite, add some time to 0.16 to be able to do a segwit release in between - but yeah, things have changed
< gmaxwell>
so 0.16 release next week?
< * gmaxwell>
ducks
< jonasschnelli>
;-)
< BlueMatt>
#action activate segwit?
< wumpus>
jtimon: also to not have another hairy, big set of backports
< wumpus>
gmaxwell: always optimistic :)
< jtimon>
wumpus: yeah I'm perhaps more worried about the latter
< * MarcoFalke>
have been obtained by ChainCode
< jonasschnelli>
\o/
< sipa>
MarcoFalke: congrats!
< wumpus>
congratulations MarcoFalke
< cfields>
MarcoFalke: congrats :)
< gmaxwell>
MarcoFalke: congrats.
< jonasschnelli>
MarcoFalke: Congrats. Have fun in NY!
< sdaftuar>
MarcoFalke: welcome! :)
< instagibbs>
what does that bring the commit % to :P
< jtimon>
yeah, cool
< BlueMatt>
instagibbs: shhhhhhhhhhh
< instagibbs>
congrats!
< cfields>
heh
< BlueMatt>
in the future, all coredev.tech events are required to occur in ny to minimize total flight time =D
< meshcollider>
\o/
< jtimon>
chaincode conspiracies coming...
< instagibbs>
Eastern US powerhouse too :)
< MarcoFalke>
instagibbs: It's not retroactive ;)
< morcos>
instagibbs: which ones, the ones we do ourselves or the ones under our blockstream contract?
< jonasschnelli>
ChainCodeLabs marketing departure must confront now with new ChainCode Core conspiracy
< instagibbs>
morcos, one and the same, right?
< jtimon>
BlueMatt: lol
< achow101>
chaincore
< jonasschnelli>
heh
< cfields>
BlockChain
< cfields>
wait...
< sdaftuar>
lol
< gmaxwell>
lol
< morcos>
took you long enough
< jonasschnelli>
lol
< sipa>
ChainStream
< wumpus>
hah!
< jtimon>
codestream
< jtimon>
anyway, other topics?
< wumpus>
let's get backporting then
< gmaxwell>
I thought we were gonna ship master! :P
< jtimon>
but that's afterwards, release 0.15.1, then rc master the day after, no?
< wumpus>
we coulld do that too and make people choose :p
< gmaxwell>
WE HERD U LIK CHOICES
< wumpus>
YAH
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Nov 2 19:42:15 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< cfields>
MarcoFalke: any especially non-trivial backports we should give extra scrutiny?
< MarcoFalke>
cfields: They are mostly clean cherry-picks (beside one or two minor conflicts)
< MarcoFalke>
I am mostly worried about silent merge conflicts
< cfields>
ok great, i was nervous that the signals/interface change might've introduced a bunch of conflicts
< MarcoFalke>
but it compiles, so everything must be right
< MarcoFalke>
right?
< cfields>
hah, good enough
< BlueMatt>
I mean our tests are prefect, right?
< sdaftuar>
nothing could possibly go wrong
< jtimon>
MarcoFalke: of course, it even passes travis, can't be wrong
< BlueMatt>
someone wanna close #11575? Looks like his wallet got corrupted by sitting around for a few years....nothing to be done, he's just asking for support now...
< karelb>
Oh. I came to watch the meeting, I am one hour late because of daylight saving time.
< karelb>
FINE
< meshcollider>
heh DST is fun like that ;)
< * instagibbs>
wondering if US DST will screw me up
< achow101>
DST ends on sunday in the US
< meshcollider>
does the whole US have one DST shift, or is it different for different parts?
< instagibbs>
depends on state I believe
< achow101>
It's state by state, but those that have DST shift at the same time IIRC
< BlueMatt>
hey! we can make travis bitch on here when master builds fail
< BlueMatt>
...maybe we should do that
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11598: Make travis complain on #bitcoin-core-dev when builds fail (master...2017-10-travis-irc-notifications) https://github.com/bitcoin/bitcoin/pull/11598
< bitcoin-git>
[bitcoin] TheBlueMatt closed pull request #11598: Make travis complain on #bitcoin-core-dev when builds fail (master...2017-10-travis-irc-notifications) https://github.com/bitcoin/bitcoin/pull/11598
< bomberb17>
?
< travis-ci>
TheBlueMatt/bitcoin#674 (2017-10-travis-irc-notifications - f9cd8b4 : Matt Corallo): The build passed.