< bitcoin-git> [bitcoin] practicalswift opened pull request #10493: Use range-based for loops (C+11) when looping over map elements (master...map) https://github.com/bitcoin/bitcoin/pull/10493
< bitcoin-git> [bitcoin] laanwj closed pull request #10459: I found I needed to use gmake on FreeBSD 10.3 (0.14...patch-2) https://github.com/bitcoin/bitcoin/pull/10459
< bitcoin-git> [bitcoin] laanwj opened pull request #10495: contrib: Update location of seeds.txt (master...2017_06_seeds_source) https://github.com/bitcoin/bitcoin/pull/10495
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/18ba984140be...10e8c0a298b3
< bitcoin-git> bitcoin/master 1983c87 Wladimir J. van der Laan: devtools: Retry after signing fails in github-merge...
< bitcoin-git> bitcoin/master 10e8c0a Wladimir J. van der Laan: Merge #10486: devtools: Retry after signing fails in github-merge...
< bitcoin-git> [bitcoin] laanwj closed pull request #10486: devtools: Retry after signing fails in github-merge (master...2017_05_githubmerge_sign_error) https://github.com/bitcoin/bitcoin/pull/10486
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/10e8c0a298b3...ef2d062c9f72
< bitcoin-git> bitcoin/master 1b6602f Russell Yanofsky: Fix bumpfee rpc "errors" return value
< bitcoin-git> bitcoin/master ef2d062 Wladimir J. van der Laan: Merge #10450: Fix bumpfee rpc "errors" return value...
< bitcoin-git> [bitcoin] laanwj closed pull request #10450: Fix bumpfee rpc "errors" return value (master...pr/berr) https://github.com/bitcoin/bitcoin/pull/10450
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef2d062c9f72...f259263a7b11
< bitcoin-git> bitcoin/master cd5622d Wladimir J. van der Laan: Make bitcoind invalid argument error message specific...
< bitcoin-git> bitcoin/master f259263 Wladimir J. van der Laan: Merge #10447: Make bitcoind invalid argument error message specific...
< bitcoin-git> [bitcoin] laanwj closed pull request #10447: Make bitcoind invalid argument error message specific (master...2017_05_bitcoind_commandline_error) https://github.com/bitcoin/bitcoin/pull/10447
< bitcoin-git> [bitcoin] benma opened pull request #10496: Add Binds, WhiteBinds, Whitelistedrange to CConnman::Options (master...connman_options) https://github.com/bitcoin/bitcoin/pull/10496
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f259263a7b11...6a38b79de439
< bitcoin-git> bitcoin/master ac9cd95 Wladimir J. van der Laan: contrib: Update location of seeds.txt...
< bitcoin-git> bitcoin/master 6a38b79 Wladimir J. van der Laan: Merge #10495: contrib: Update location of seeds.txt...
< bitcoin-git> [bitcoin] laanwj closed pull request #10495: contrib: Update location of seeds.txt (master...2017_06_seeds_source) https://github.com/bitcoin/bitcoin/pull/10495
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6a38b79de439...b6b150b01668
< bitcoin-git> bitcoin/master 16d94d3 James Evans: Fixing typo in rpcdump.cpp
< bitcoin-git> bitcoin/master b6b150b Wladimir J. van der Laan: Merge #10469: Fixing typo in rpcdump.cpp...
< bitcoin-git> [bitcoin] laanwj closed pull request #10469: Fixing typo in rpcdump.cpp (master...patch-2) https://github.com/bitcoin/bitcoin/pull/10469
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b6b150b01668...cb1716acc720
< bitcoin-git> bitcoin/master b6fbfc2 Cory Fields: net: only enforce the services required to connect...
< bitcoin-git> bitcoin/master cb1716a Wladimir J. van der Laan: Merge #10441: net: only enforce expected services for half of outgoing connections...
< bitcoin-git> [bitcoin] laanwj closed pull request #10441: net: only enforce expected services for half of outgoing connections (master...serviceflags-required) https://github.com/bitcoin/bitcoin/pull/10441
< bitcoin-git> [bitcoin] benma opened pull request #10497: remove the PAIRTYPE macro (master...pairtype) https://github.com/bitcoin/bitcoin/pull/10497
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/9e3ad500780b284765654cff4144451c7fa5ef6b
< bitcoin-git> bitcoin/0.14 9e3ad50 Cory Fields: net: only enforce the services required to connect...
< bitcoin-git> [bitcoin] practicalswift opened pull request #10498: Use static_cast instead of C-style casts for non-fundamental types (master...static_cast) https://github.com/bitcoin/bitcoin/pull/10498
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cb1716acc720...27b99312bf09
< bitcoin-git> bitcoin/master afc693d Luke Dashjr: contrib/init/bitcoind.openrcconf: Don't disable wallet by default...
< bitcoin-git> bitcoin/master 27b9931 Wladimir J. van der Laan: Merge #10451: contrib/init/bitcoind.openrcconf: Don't disable wallet by default...
< bitcoin-git> [bitcoin] laanwj closed pull request #10451: contrib/init/bitcoind.openrcconf: Don't disable wallet by default (master...openrc_wallet) https://github.com/bitcoin/bitcoin/pull/10451
< instagibbs> wumpus, if you're still looking for things to merge :P https://github.com/bitcoin/bitcoin/pull/10475
< timothy> hi
< timothy> who maintains dev.bitcoincore.org ?
< fanquake> instagibbs I'm sure it'll get picked up tonight
< instagibbs> fanquake, "tonight"? honest question, is there a method to the madness? :)
< instagibbs> Other than ad hoc scanning
< fanquake> instagibbs dev meeting tonight isn't there? Normally a time to get some merging done
< instagibbs> oh yes, I always forget it's irc meeting day
< fanquake> I probably wont be at the dev meeting, but would like opinions on Qt5.9.0 for 0.15. Compilation (brew, osx) looks ok so far, depends patches will need some fixes. Interested to see the results of the new -optimize-size option; claims of 5-20% binary size decrease. We should also be able to pass more -no-* flags to cut more crap out of our build.
< bitcoin-git> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/27b99312bf09...64beb1317912
< bitcoin-git> bitcoin/master 32325a3 Jonas Schnelli: [Qt] hide bump context menu action if tx already has been bumped
< bitcoin-git> bitcoin/master 6d7104c Jonas Schnelli: [Qt] make sure transaction table entry gets updated after bump
< bitcoin-git> bitcoin/master 64beb13 Jonas Schnelli: Merge #10449: Overhaul Qt fee bumper...
< jonasschnelli> cfields: ping
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #10449: Overhaul Qt fee bumper (master...2016/05/bump_qt_overhaul) https://github.com/bitcoin/bitcoin/pull/10449
< bitcoin-git> [bitcoin] ryanofsky opened pull request #10500: Avoid CWalletTx copies in GetAddressBalances and GetAddressGroupings (master...pr/wtxcopy) https://github.com/bitcoin/bitcoin/pull/10500
< jtimon> mhmm FAIL: qt/test/test_bitcoin-qt on master 64beb13... Merge #10449: Overhaul Qt fee bumper
< gribble> https://github.com/bitcoin/bitcoin/issues/10449 | Overhaul Qt fee bumper by jonasschnelli · Pull Request #10449 · bitcoin/bitcoin · GitHub
< jtimon> seems lie #10449 is to blame since this passes: 27b99312 Merge #10451: contrib/init/bitcoind.openrcconf: Don't disable wallet by default
< gribble> https://github.com/bitcoin/bitcoin/issues/10449 | Overhaul Qt fee bumper by jonasschnelli · Pull Request #10449 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/10451 | contrib/init/bitcoind.openrcconf: Dont disable wallet by default by luke-jr · Pull Request #10451 · bitcoin/bitcoin · GitHub
< instagibbs> can someone explain to me where/how "--without-gui" is consumed?
< instagibbs> grepping for it fails :)
< bitcoin-git> [bitcoin] benma opened pull request #10501: remove some unused functions (master...unusedfuncs) https://github.com/bitcoin/bitcoin/pull/10501
< wumpus> timothy: "<timothy> who maintains dev.bitcoincore.org ?" cfields should have access at least, why?
< timothy> nothing, solved :)
< wumpus> instagibbs: it gets converted to --with-gui=no IIRC
< wumpus> --(with|without)-x and --(enable|disable)-x are standard autoconf arguments that have a special handler construct, don't know by heart how it's called though
< instagibbs> oh. there we go
< instagibbs> thanks
< instagibbs> I knew that it was part of autoconf, which is why I asked, because it's a black box to me :)
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/64beb1317912...39039b12a744
< bitcoin-git> bitcoin/master f128f78 Gregory Sanders: getmempool mempoolminfee is a BTC/KB feerate
< bitcoin-git> bitcoin/master 39039b1 Wladimir J. van der Laan: Merge #10475: [RPC] getmempoolinfo mempoolminfee is a BTC/KB feerate...
< * sipa> loves kelvin bytes
< bitcoin-git> [bitcoin] laanwj closed pull request #10475: [RPC] getmempoolinfo mempoolminfee is a BTC/KB feerate (master...poolfeerate) https://github.com/bitcoin/bitcoin/pull/10475
< wumpus> Dizzle: exactly
< Dizzle> instagibbs: the source I linked deals with the flag, sets the bitcoin_enable_qt vars you'll see referenced throughout the rest of the configure/make stuff.
< bitcoin-git> [bitcoin] jtimon opened pull request #10502: scripted-diff: Remove BOOST_FOREACH, Q_FOREACH and PAIRTYPE (master...b15-boost-foreach) https://github.com/bitcoin/bitcoin/pull/10502
< gmaxwell> holy crap Block Filter Digest profiling post on bitcoin-dev.
< bitcoin-git> [bitcoin] sipa opened pull request #10503: Use REJECT_DUPLICATE for already known and conflicted txn (master...more61duplicate) https://github.com/bitcoin/bitcoin/pull/10503
< gmaxwell> Meeting in 12 minutes.
< wumpus> yep
< btcdrak> I might make it this time
< jtimon> I suggest we start with the priority PRs topic, that tends to be short and spring other topics
< wumpus> jtimon: ok, let's do that
< BlueMatt> cfields: is out dealing with life things, apparently
< cfields> BlueMatt: nevermind, i made it!
< BlueMatt> lolk
< btcdrak> jtimon: just needs to be restarted
< cfields> jonasschnelli: sorry, it's moving day (apparently), wasn't around earlier. You around to discuss after the meeting?
< jonasschnelli> cfields: I guess I fall to sleep in 1h. But we may make it tomorrow. :)
< jonasschnelli> No hurry
< gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
< jonasschnelli> But love to hear how we can solve the wallet-tool building
< cfields> jonasschnelli: ah, ok
< sdaftuar> hi
< jonasschnelli> hi
< btcdrak> hi
< morcos> i'm kind of here for the next 25 mins
< sipa> present
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Jun 1 19:00:41 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< achow101> hi
< wumpus> proposed topics?
< luke-jr> suggested topic: safe DoS handling around softforks
< wumpus> ok, we'll start with high-priority review as suggested by jtimon
< gmaxwell> It was proposed we talk about PRs first.
< wumpus> #topic High-priority review PRs
< wumpus> anything to add this week?
< jonasschnelli> Please review HD auto restore... I whised we have this in 0.15. But seems to get late: https://github.com/bitcoin/bitcoin/pull/10240
< jtimon> mine still is #10339 (which contains #9717 )
< gribble> https://github.com/bitcoin/bitcoin/issues/10339 | Optimization: Calculate block hash less times by jtimon · Pull Request #10339 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9717 | Pow: Remove fCheckPOW from CheckBlockHeader by jtimon · Pull Request #9717 · bitcoin/bitcoin · GitHub
< jtimon> did squash and the requested rename
< cfields> wumpus: I _promise_ to review your unix socket changes this week. They slipped off my radar, but I'm aware they're painful rebases.
< gmaxwell> Where have we gotten on multiwallet?
< jonasschnelli> luke-jr: there are compile issues
< sipa> i'm currently squashing #10195, after that i'd like to request review on #10321
< gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
< jonasschnelli> Gitian won't compile I guess because of the test fixtures
< gribble> https://github.com/bitcoin/bitcoin/issues/10321 | Use FastRandomContext for all tests by sipa · Pull Request #10321 · bitcoin/bitcoin · GitHub
< luke-jr> hmm
< jonasschnelli> Once that is fixed, I guess we can merge luke-jr first step
< jonasschnelli> But ideally we work on runtime-wallet loading
< jonasschnelli> shouldn't be that hard
< jtimon> #7729 needs rebase
< wumpus> cfields: thanks!
< gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
< cfields> jonasschnelli: if i'm understanding correctly, that's the tl;dr for fixing the wallet tool build issue as well :)
< cfields> (my proposal, anyway)
< wumpus> jtimon: yes
< jonasschnelli> cfields: wallet-tool build issue could solve salvage, upgrade, etc.
< jonasschnelli> currently multiwallet does only allow all-or-nothing rescans/salvages,zaps, etc.
< gmaxwell> 7729 was mostly API review. I kind of got lost on it becuase I didn't see how the api can be cleanly extended to multiple lables per transaction, but I keep forgetting about it to go read in again what the api was in order to prodice more commentary. :(
< cfields> i see
< kanzure> hi.
< jtimon> just giving heads up, also #10044's tests are failing
< gribble> https://github.com/bitcoin/bitcoin/issues/10044 | Run functional tests in `make check` by jnewbery · Pull Request #10044 · bitcoin/bitcoin · GitHub
< gmaxwell> jonasschnelli: I think it was proposed to make salvage/zap only work when one wallet was loaded.
< wumpus> gmaxwell: multiple labels per transactions simply wasn't a goal there
< gmaxwell> which seemed like a fine stopgap to me.
< wumpus> gmaxwell: I'm fine with doing it later, but let's not scope creep this, it's already getting late
< jonasschnelli> gmaxwell: Seems reasonable.
< gmaxwell> wumpus: I understand; I am not trying to suggest that it should do that, but not sure if the api can be cleanly extended later to support that.
< wumpus> the goal of #7729 was explicitly to offer the same API as the GUI has for labels
< gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
< wumpus> to be able to drop the account system
< wumpus> after that, the label system can be improved, both in the GUI and RPC
< jonasschnelli> ack
< ryanofsky> #10244 would be my priority review, if it could be added
< gribble> https://github.com/bitcoin/bitcoin/issues/10244 | [qt] Add abstraction layer for accessing node and wallet functionality from gui by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub
< gmaxwell> okay. so long as its not an omission. I feel like we end up with our hands tied by the rpc interface pretty often.
< jtimon> sounds reasonable, certainly the priority is to remove the accounts system IMO
< jonasschnelli> setlabel and deletelabel should be multi-label compatible (API wise)
< gmaxwell> (by not an omission I mean that we don't put ourselves in a corner just because we didn't think of it. If you're aware, thats enough.)
< jonasschnelli> 7729 can be perfectly extaned later
< jonasschnelli> (without breaking the API)
< gmaxwell> OK.
< wumpus> I just think we shouldn't aim too far - we've been talking about deprecating the account system for so long and this is blocking it. But if there's suggesting for improving the API to (later) support multiple labels that's very welcome.
< jonasschnelli> Yes. We finally should do it.
< jtimon> other topics?
< wumpus> ryanofsky: sure; though we should first get the multiwallet base in, I think more abstraction around the wallet right now will break various PRs there again
< wumpus> #topic safe DoS handling around softforks (luke-jr)
< cfields> proposed quick topic: 0.14.2
< wumpus> ryanofsky: I'll add your PR to the high-priority PRs, but we need to keep that in mind
< sipa> i think DoS scoring in general needs a rework, but especially for blocks, i think that few is needed after PoW checking
< sdaftuar> #9530
< gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
< jtimon> just add it as a depdendency in the OP and rebase on top of it maybe?
< luke-jr> it's come to light that blocks cause DoS penalties for invalid prev-blocks
< ryanofsky> wumpus, thanks. there is barely anything that would have to be change with current multiwallet prs, but i don't know what multiwallet plans for qt are
< luke-jr> which are liable to get triggered by outdated nodes following softforks
< wumpus> ryanofsky: I don't know either - just that multiwallet is priority for 0.15.0, better abstraction for the wallet can theoretically wait until 0.16
< luke-jr> part of this is easy to fix: just don't DoS-ban for invalid prevblocks
< wumpus> (would be great to get everything in, but in practice resources are limited and we have to choose)
< luke-jr> but there is also a ban for sending headers that "don't" connect (because we rejected an earlier invalid header)
< luke-jr> would there be any harm to checking the PoW on headers earlier, banning for failure there, and not banning for unconnecting ones?
< gmaxwell> luke-jr: if you do not disconnect peers on incompatible consensus rules you will likely become partitioned from nodes on consensus rules which are consistent with yourself.
< morcos> Doesn't it seem safer to keep the current banning behavior unitl we've also improved the ability to make sure we're not partitioned from nodes following our rules
< gmaxwell> One of the totally braindamaged element of BIP148 is that it does nothing to make the network of BIP148 users connected and it sounds like you'd like to make that even worse?
< wumpus> ryanofsky: but if it hardly collides in practice then it isn't a problem (sorry, will shut up about previous topic now)
< luke-jr> gmaxwell: softforks are backward compatible
< gmaxwell> luke-jr: when there is a persistant chain on invalid rules there is a hardfork.
< luke-jr> this is nothing specific to BIP148
< luke-jr> it is an issue for all softforks
< gmaxwell> BIP148 is a softfork but it creates a hardfork, its the hardfork that creates that partitioning issue.
< sipa> gmaxwell: i'm confused
< jtimon> can we stay on the issue as general to all softforks?
< instagibbs> I'm not sure how this topic arose?
< instagibbs> (I get the original topic)
< luke-jr> instagibbs: it was an observation on the current BIP148 PR that I'm investigating; but it applies to any softfork
< sipa> gmaxwell: i thought i understood your concern until you said it creates a hardfork
< BlueMatt> i assume here "hardfork" means "nodes will not converge"
< jtimon> I'm confused, are we talking about 2 different things? #9530 is from january
< gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
< instagibbs> Yes they dont' appear to be connected?
< sdaftuar> perhaps this brainstorming should take place on #9530? the current DoS scoring is broken, and potentially problematic for softforks (though not for segwit)
< gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
< sdaftuar> but there's no urgent issue here
< morcos> sdaftuar: +1
< sdaftuar> and lots of ways to solve, i suspect
< instagibbs> ACK
< sipa> BlueMatt: yes, nodes will risk not converging, but that's a P2P issue, not a consensus issue
< gmaxwell> ::sigh:: I give up.
< kanzure> sipa: from a payments angle, it's not just p2p.
< luke-jr> jtimon: 9530 is unrelated afaik
< gmaxwell> this terminology is too limited.
< gmaxwell> In any case, if your peers are accepting a chain you will not accept you need different peers.
< sipa> of course
< luke-jr> gmaxwell: unless those peers will accept the chain you have too.
< gmaxwell> luke-jr: not unless, you still need different peers.
< gmaxwell> (or at least _some_ different peers)
< luke-jr> or rather, they need you as a peer
< gmaxwell> they might, but you're useless to them if you're only connected to other nodes that are also on chains you won't accept.
< luke-jr> I wonder if we should have a different criteria for our outbound connections, than for inbound
< luke-jr> eg, tolerate more from inbound peers, but be super-strong that we are on the same block as our outbound peers
< gmaxwell> If you want to talk about making some fraction of your connection slots more agressive in enforcement than others that would be reasonable, but you can't have a case where you will never disconnect peers that accept different rules.
< morcos> yes we need a more comprehensive solution.. ideally you could figure out whether they'd accept your chain or not, and that could be a factor as well you knowing whether you'd accept theirs, but we shouldn't make ad hoc changes
< sipa> gmaxwell: am i summarizing correctly... even though DoS scoring for invalid blocks isn't needed as such, it's currently our only protection against accidentally ending up with only peers that will not accept the best chain you'd accept if you'd see it
< cfields> luke-jr: I have a patch-set worked up for making that possible. It doesn't change any current policy, just makes it more flexible to do that kind of thing
< gmaxwell> sipa: ya!
< sipa> ok, in that case i agree with you
< luke-jr> can we currently disconnect nodes, without banning them?
< luke-jr> I guess just set fDisconnect?
< morcos> which is what you guys said to each other on 9530
< gmaxwell> I think it would be sufficient to disconnect in those cases, yes.
< gmaxwell> (or very short ban)
< luke-jr> gmaxwell: I'm thinking of a conditional disconnect-only-if-outgoing-conn
< sdaftuar> in #9530, there's a suggestion of rotating outbound connections periodically
< gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
< sdaftuar> and whether your outbound peer is on the same chain as you could be a criteria
< jtimon> action continue discussion on #9530 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
< luke-jr> 9530 sounds like too much refactoring IMO. I'm thinking for a bugfix only right now.
< luke-jr> but maybe there's enough overlap, dunno
< jtimon> anyway, next topic?
< luke-jr> in any case, is there a specific reason to disconnect for unconnectable headers, independently of the "same chain peers" issue?
< jtimon> or not
< luke-jr> we could move on if there's another topic, too; maybe someone can answer OOB if there's a need for the disconnect there
< wumpus> ok
< wumpus> #topic 0.14.2 (cfields)
< wumpus> I think we've merged/backported everything that was tagged?
< cfields> just wanted to keep that rolling. several backports went in this week, anything else need to go?
< wumpus> if so, we can tag it after the meeting
< jonasschnelli> not yet
< wumpus> what's missing?
< jonasschnelli> Wait.. has been merged. Nm
< cfields> wumpus: +1 then
< jonasschnelli> I check the backports and seems that now everything went in
< jonasschnelli> checked
< wumpus> right, great
< jtimon> so rc?
< wumpus> that was indeed a short topic
< wumpus> yes
< wumpus> other topics?
< sipa> i wanted to bring up whether my writeup for style guidelines was acceptable, but i see it was already merged :)
< jonasschnelli> heh. Yes.
< jtimon> what was the pr?
< luke-jr> no, it's terrible. I'm not following it. /s
< wumpus> heh yes, it was exactly what was discussed in the previous meeting
< wumpus> #topic variable name guidelines
< luke-jr> wumpus: it was sarcasm :p
< sipa> OK.
< sipa> end topic
< wumpus> wanted to merge it as soon as possible to be able to point people at it in reviews
< sipa> yes, thank you for that
< jtimon> ok, https://github.com/bitcoin/bitcoin/pull/10461 reading now, but I assume it will be acceptable to me
< wumpus> more topics? this is becoming a high frequeny meeting
< sipa> we have 1.5 months left until feature freeze for 0.15
< sipa> anything to talk about there?
< sipa> i guess not... things happen as they happen
< wumpus> I... don't think so... would really love multiwallet to get in this time
< sdaftuar> perhaps suggestions for high priority features for 0.15?
< sdaftuar> as potentially distinct from high priority prs
< wumpus> if no PRs exist for them it might be too late already, but sure
< wumpus> #topic high priority features
< jtimon> I would love https://github.com/bitcoin/bitcoin/pull/8994 , working on the blocksigning stuff again
< sdaftuar> i'd suggest matt's #10192 (script cache). huge validation win.
< gribble> https://github.com/bitcoin/bitcoin/issues/10192 | Cache full script execution results in addition to signatures by TheBlueMatt · Pull Request #10192 · bitcoin/bitcoin · GitHub
< sipa> ya
< cfields> +1
< jtimon> I have 2 PRs prefixed "Optimization", but didn't benchmark any of them...
< luke-jr> 10192 sounds problematic for future softforks
< wumpus> sdaftuar: any reason for not just adding that one to the high priority PRs though?
< jonasschnelli> +1 on 10192,.. seems also madable for 0.15
< bitcoin-git> [bitcoin] ryanofsky opened pull request #10506: Fix bumpfee test after #10449 (master...pr/bumpdis) https://github.com/bitcoin/bitcoin/pull/10506
< sdaftuar> wumpus: i was going to suggest it but thought matt might yell at me if it displaced his existing one :)
< sipa> luke-jr: i believe it shouldn't be, unless i've misunderstood the design
< wumpus> ohh okay, yes it's not really a blocker for his further work I guess, but before the feature freeze we can make an exception
< BlueMatt> yes, i still want #10179 to get in :(
< gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
< sipa> BlueMatt: will review
< BlueMatt> so much stuff to build on top of things
< sdaftuar> sipa: it interferes with script features that require chain-context. i think luke has proposed such a thing.
< luke-jr> sipa: specifically softforks where transactions are valid in some blocks, but not in others
< jtimon> merging something like #10427 before #10192 (I don't care his commit or mine, but would really love the nits solved) would make it simpler to review
< gribble> https://github.com/bitcoin/bitcoin/issues/10427 | Consensus: Introduce static GetScriptFlags (mostly MOVEONLY) by jtimon · Pull Request #10427 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/10192 | Cache full script execution results in addition to signatures by TheBlueMatt · Pull Request #10192 · bitcoin/bitcoin · GitHub
< jonasschnelli> I think we should add 10192 to the prio list (and credit sdaftuar for it)
< wumpus> jonasschnelli: I've added it
< cfields> I have a good bit of net changes still coming, working on making them reviewable and adding tests. Definitely coming in time for 0.15.
< jonasschnelli> cfields: great!
< cfields> sipa: are you aiming to have openssl nuked in time for 0.15 ?
< sipa> luke-jr: fair enough, i agree - but i do think it's solvable (store the context-dependent script validation flags along with the entry in the cache)
< wumpus> is 'nuking openssl' really a goal?
< luke-jr> sipa: yes, but is it worth it?
< jonasschnelli> For the PRNG, I though so
< wumpus> ok
< luke-jr> hmm, 1.7x
< sipa> i'd like to be independent from OpenSSL, but that's more from a code management perspective than an actual fear for security
< cfields> wumpus: I was referring to #10299
< gribble> https://github.com/bitcoin/bitcoin/issues/10299 | Remove OpenSSL by sipa · Pull Request #10299 · bitcoin/bitcoin · GitHub
< sipa> as such, i don't think removing openssl should be a priority, but i think it should eventually happen
< wumpus> I'd agree about boost but I'm... not sure trying to nuke all dependencies is a wise path
< luke-jr> dependencies are better than reinventing stuff
< luke-jr> (all else being equal)
< wumpus> that's an argument that should be considered, we can't do everything better, but yes everything else being equal
< cfields> sure, I wasn't arguing for/against, was just curious if 10299 was still desired
< jtimon> sorry for linking so many of my prs, but re boost: https://github.com/bitcoin/bitcoin/pull/10502
< luke-jr> our binaries are getting annoyingly large btw..
< jonasschnelli> sipa: IMO the rng mostly matters for the wallet keys, and long term, I'm not sure if wallet keys created on the environments we run (Linux/OSX/Windows) are in general a "good thing". Using our own PRNG (via Fortuna, etc,) seems fine to me
< jonasschnelli> luke-jr: define "large"
< wumpus> improving the PRNG is certainly a good goal
< luke-jr> jonasschnelli: 215 MB excluding the debuginfo files
< sipa> wumpus: i'd say removing OpenSSL will come naturally once our PRNG has undergone a few more improvement
< wumpus> luke-jr: you certainly shouldn't cound debug info, no one ships that
< luke-jr> wumpus: that's why I didn't.
< cfields> luke-jr: wha?? stripped bitcoind is < 10mb on all platforms iirc
< wumpus> luke-jr: where do you think it comes from? is it just bitcoin-qt being large or everything?
< cfields> luke-jr: or did you mean all binaries combined?
< wumpus> sipa: ok, makes sense
< jonasschnelli> BitcoinD linux 64 is 9.3MB, Qt: ~33,
< jonasschnelli> Perfectly fine
< luke-jr> cfields: yes
< jtimon> and if somebody can help with https://github.com/bitcoin/bitcoin/pull/10193/commits/3f404ca62c26dae8f5a4f321820a460bf7b5373e I am kind of stuck there
< wumpus> qt is huge, but that's unavoidable,it's a lot of code...
< luke-jr> wumpus: it might be
< cfields> future builds should be much slimmer
< jonasschnelli> Qt5.9 can shrink ~20% from what I have read
< cfields> yes
< wumpus> I recently had to compile qt on a single-core ARM system (don't ask), took about 2 week
< cfields> and I'd be curious to see what lto does to bitcoin-qt ?
< jonasschnelli> hehe
< luke-jr> 2.7M bitcoin-cli; 33M bitcoin-qt; 3.0M bitcoin-tx; 8.9M bitcoind; 12M test_bitcoin
< jonasschnelli> compared to the 100GB blockchain... what should I say
< wumpus> luke-jr: it compresses very well though
< jtimon> is it a worry that test_bitcoin is big?
< jonasschnelli> no
< wumpus> nope
< wumpus> I think those numbers are pretty ok, compared to most desktop software
< jonasschnelli> indeed
< wumpus> (or even mobile software, nowadays)
< luke-jr> it adds up though
< luke-jr> but not too crazy I guess
< jtimon> I mean, if it can get smaller I don't think anybody will oppose
< luke-jr> I'd be curious what using shared libs would do for it.
< wumpus> yeah... hardly a priority though, it's only such a small part of the memory use
< luke-jr> at least for Windows, where it's trivial
< cfields> luke-jr: there'd be a ton of circular deps to unravel
< luke-jr> cfields: ?
< wumpus> cfields: I think he just means for the deps
< luke-jr> ah
< cfields> ah
< wumpus> yes on windows it's trivial
< luke-jr> re internals as shared libs: on Linux, circular deps are not a problem, but IIRC they are for Windows
< cfields> osx as well, fwiw
< wumpus> on linux you can't simply ship .so's in the same directory and have it work
< cfields> wumpus: you can but you have to use rpath hacks :\
< luke-jr> right, we'd need wrapper scripts (maybe okay, iff it makes a big difference)
< luke-jr> oh
< luke-jr> forgot about rpath :D
< cfields> there's a special rpath symbol that means pwd
< cfields> s/symbol/value/
< luke-jr> yes, I use it in BFGMiner
< wumpus> cfields: doesn't that use the *current* directory instead of the application directory though?
< luke-jr> $ORIGIN
< luke-jr> the name suggests app dir
< jtimon> other super fast topic?
< wumpus> ok
< wumpus> anyhow it's worth experimenting with, possibly, for a future version
< jonasschnelli> Bitcoin Core ICO?
< jonasschnelli> *duck*
< wumpus> security might be slightly improved as well as different libs can be ASLRed relative to each other
< BlueMatt> jonasschnelli: ack
< wumpus> jonasschnelli: lol
< jtimon> testnet 4 ico at most
< luke-jr> jonasschnelli: IHO instead?
< luke-jr> compromise.
< * sipa> commits the Bitcoin Core.ico file
< luke-jr> (Initial Hat Offering)
< jonasschnelli> sipa: hahahaha
< jtimon> ITO
< jonasschnelli> Win32 had plenty if .ICO's
< BlueMatt> Bitcoin Series A ICO
< gmaxwell> We could sell international reply coupons... it would have a lot more substance than most ICOs. :)
< luke-jr> reply coupons? O.o\
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Jun 1 19:59:47 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< wumpus> sure
< wumpus> * [new tag] v0.14.2rc1 -> v0.14.2rc1
< jtimon> thanks!
< cfields> woohoo
< sipa> travis is so slow these days
< sipa> is it because we have many pull requests and rebases?
< sipa> it seems to be lagging behind easily
< jtimon> yeah travis seems to fail and lag more than usual these days
< jtimon> btw, travis didn't even run for https://github.com/bitcoin/bitcoin/pull/9176
< sipa> what's the matter with test_bitcoin_qt failing on master?
< sipa> 16:56:50 < jtimon> mhmm FAIL: qt/test/test_bitcoin-qt on master 64beb13... Merge #10449: Overhaul Qt fee bumper
< gribble> https://github.com/bitcoin/bitcoin/issues/10449 | Overhaul Qt fee bumper by jonasschnelli · Pull Request #10449 · bitcoin/bitcoin · GitHub
< sipa> jtimon: thanks!
< bitcoin-git> [bitcoin] sipa pushed 30 new commits to master: https://github.com/bitcoin/bitcoin/compare/39039b12a744...1088b02f0ccd
< bitcoin-git> bitcoin/master e66dbde Pieter Wuille: Add SizeEstimate to CDBBatch...
< bitcoin-git> bitcoin/master f54580e Pieter Wuille: error() in disconnect for disk corruption, not inconsistency...
< bitcoin-git> bitcoin/master e484652 Pieter Wuille: Introduce CHashVerifier to hash read data...
< bitcoin-git> [bitcoin] sipa closed pull request #10195: Switch chainstate db and cache to per-txout model (master...pertxoutcache) https://github.com/bitcoin/bitcoin/pull/10195
< gmaxwell> Hey everybody!!! ^^^^^
< gmaxwell> This means that after you pull your database will upgrade.
< gmaxwell> And will no longer be compatible with earlier versions!
< * TD-Linux> upgrades for speeeed
< gmaxwell> HOLY COW I'M GOING SO FAST https://www.youtube.com/watch?v=nb97AbB8M_o
< gmaxwell> If you do make the grave error of downgrading, you'll need to reindex. See you next month in that case.
< TD-Linux> bonus: pruned mode :^)
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1088b02f0ccd...7cc2c670e3d7
< bitcoin-git> bitcoin/master 8906a9a Russell Yanofsky: Fix bumpfee test after #10449...
< bitcoin-git> bitcoin/master 7cc2c67 Pieter Wuille: Merge #10506: Fix bumpfee test after #10449...
< bitcoin-git> [bitcoin] sipa closed pull request #10506: Fix bumpfee test after #10449 (master...pr/bumpdis) https://github.com/bitcoin/bitcoin/pull/10506
< bitcoin-git> [bitcoin] sipa closed pull request #10396: Report LevelDB estimate for chainstate size in gettxoutsetinfo (master...diskdbsize) https://github.com/bitcoin/bitcoin/pull/10396
< jtimon> if I get some more concept acks on #10339 maybe I should just close the noisy #9717 as included in it
< gribble> https://github.com/bitcoin/bitcoin/issues/10339 | Optimization: Calculate block hash less times by jtimon · Pull Request #10339 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9717 | Pow: Remove fCheckPOW from CheckBlockHeader by jtimon · Pull Request #9717 · bitcoin/bitcoin · GitHub