< 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/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
< 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.
< 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
< 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
< 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
< 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
< 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
< 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
< 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)
< 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
< 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
< 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
< 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,