19:00:32 <wumpus> #startmeeting
19:00:32 <lightningbot> Meeting started Thu Jun 14 19:00:32 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:32 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:36 <jonasschnelli> hi
19:00:37 <sipa> aye
19:00:41 <wumpus> #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 jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:00:45 <meshcollider> hi
19:00:52 <cfields> hi
19:01:00 <kanzure> hi.
19:01:07 <meshcollider> Sorry I haven't been around for the last few weeks, swamped with assignments and exams
19:01:12 <achow101> hi
19:01:22 <promag> hi
19:01:45 <wumpus> meshcollider: np!
19:01:51 <wumpus> topic proposals?
19:02:27 <wumpus> #topic high priority for review
19:02:37 <promag> jnewbery: after qt4 is dropped, I'll replace qt connections with the new sintax
19:02:39 <wumpus> currently on the list: #13425 #13111 #13062 #12196 #12136
19:02:42 <achow101> topic proposal: srd fallback coin selection
19:02:42 <gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
19:02:45 <gribble> https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub
19:02:47 <gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
19:02:51 <gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
19:02:53 <bitcoin-git> [13bitcoin] 15HashUnlimited opened pull request #13472: [devtools translations] catch invalid specifiers (06master...06HashUnlimited-translate-1) 02https://github.com/bitcoin/bitcoin/pull/13472
19:02:58 <gribble> https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions serialization and RPCs by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub
19:03:04 <wumpus> unloadwallet from promag seems almost ready for merge
19:03:04 <achow101> 12136 can be removed for now
19:03:15 <wumpus> achow101: ok
19:03:20 <achow101> it depends on 13425
19:03:58 <wumpus> dropped
19:04:06 <promag> wumpus: I think so, I have to fix last jnewbery points
19:04:09 <sipa> #13425 is pretty much all of the PSBT internal changes that are needed, excluding serialization and RPCs
19:04:10 <wumpus> it was unfair for you to have two entires on the list, anyway
19:04:12 <gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
19:04:48 <jnewbery> I think since the last change, unloadwallet no longer removes the unloaded wallet from the dropdown menu
19:04:52 <wumpus> (just kidding, no idea how it came that way)
19:05:15 <promag> jnewbery: you are right
19:05:28 <promag> needs signal unload
19:05:34 <wumpus> right
19:05:43 <jnewbery> yep. Seems to work with that method declaration readded
19:07:03 <wumpus> should we add anything to the list this week?
19:07:25 <promag> #13160
19:07:27 <gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
19:07:38 <wumpus> you already have one
19:07:46 <meshcollider> Lol
19:07:54 <promag> there was a behaviour change since 0,15 iirc, that fixes it
19:08:32 <wumpus> promag: but I agree it needs more attention, FWIW
19:09:10 <promag> it's one line change
19:09:15 <sipa> the high-priority list is for things that block other work
19:09:23 <wumpus> yes
19:09:26 <sipa> not just "this needs attention"
19:09:42 <wumpus> that's what the meeting is for
19:10:33 <wumpus> #action look at #13160
19:10:35 <gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
19:10:52 <wumpus> other topics?
19:11:01 <meshcollider> I just reviewed it fwiw promag
19:11:10 <wumpus> meshcollider: thanks!
19:11:20 <achow101> <achow101> topic proposal: srd fallback coin selection
19:11:40 <wumpus> #topic srd fallback coin selection (achow101)
19:12:10 <wumpus> srd = Single Random Draw?
19:12:14 <achow101> yes
19:12:19 <wumpus> #13307
19:12:22 <gribble> https://github.com/bitcoin/bitcoin/issues/13307 | Replace coin selection fallback strategy with Single Random Draw by achow101 · Pull Request #13307 · bitcoin/bitcoin · GitHub
19:12:33 <achow101> I think we should discuss instagibbs's point here: https://github.com/bitcoin/bitcoin/pull/13307#discussion_r192899180
19:12:44 <instagibbs> oh, I said something eh
19:13:04 <achow101> the basic point is that in the current coin selection, we prefer exact matches over confirmations. However the current implementation of srd fallback is that we prefer confirmations over exact matches
19:13:35 <instagibbs> altnernating between BnB(Exact match) and then fallback, rather than Bnb of all sorts then fallback
19:14:01 <sipa> so this is a bit of a question on what our coin selection algorithm should prioritize
19:14:09 <achow101> yes
19:14:09 <sipa> confirmed coins, or (immediate) fee
19:14:19 <instagibbs> and privacy
19:14:46 <instagibbs> imo privacy puts it over the top and we should try really hard to do it
19:14:53 <instagibbs> but obviously it's not a slam dunk
19:14:59 <sipa> hmm, unclear how privacy is affect here?
19:15:10 <instagibbs> change-less outputs mess with coin analysis
19:15:16 <instagibbs> to a large degree
19:15:36 <sipa> that's a good point
19:16:45 <sipa> sdaftuar, morcos: present, opinions?
19:17:02 <sipa> gmaxwell: ?
19:17:28 <instagibbs> IIRC we converged on being ok with current behavior, because it breaks the long chains if it works
19:17:31 <achow101> I also did a simulation (so take it with a grain of salt) that showed that the number of utxos with exact match over confirmations was higher than not
19:17:35 <instagibbs> was an intentional design decision
19:19:26 <sipa> what do you mean by "current behaviour"?
19:19:31 <instagibbs> in master
19:19:34 <sipa> master or the SRD PR?
19:19:34 <sipa> ok
19:20:11 <sipa> there is another question here on what the criteria for SRD merge should be
19:20:51 <sipa> because it seems it results in somewhat higher average UTXOs per wallet in simulations
19:21:10 <instagibbs> merge as in code? or?
19:21:29 <achow101> merge as in merge the pr
19:21:58 <instagibbs> ah
19:22:05 <sipa> yes, i'm wondering what our bar for deciding to change tbe logic should be
19:22:08 <achow101> it doesn't seem to perform as well as the current coin selection in master w.r.t mean number of utxos in the wallet in my simulations
19:22:20 <meshcollider> Significantly higher?
19:22:33 <instagibbs> did you try filtering for using only coins lower than target value? using coins with negative effective value?
19:22:38 <achow101> from ~20 utxos to ~90 utxos
19:22:38 <instagibbs> allowing a single negative effective value?
19:23:07 <instagibbs> Core is an extreme UTXO cop currently. I don't think we're going to be able to match it.
19:23:20 <achow101> these are the results so far https://gist.github.com/achow101/242470486265d3f21adab08f65b9102c
19:24:02 <achow101> I have tried filtering for inputs smaller than the target value and doing srd on that. if that fails, srd on all inputs
19:24:21 <achow101> I have also done that but instead of srd on all inputs on failure, choosing the input that is immediately larger than the target value
19:25:29 <sipa> also, these numbers are just for a single simulation, right?
19:25:40 <achow101> yes, those are all for the same scenario
19:25:45 <sipa> on different workloads differents effects may be preswnt
19:26:02 <achow101> I'm running simulations for the other scenarios right now, but that will take a while to finish
19:26:29 <sipa> i guess more to discuss in the PR
19:28:35 <instagibbs> achow101, you can also test not filtering for -EV
19:28:51 <instagibbs> to see how big an effect that is
19:29:07 <achow101> so we could be spending dust?
19:29:36 <instagibbs> Like we do now yes
19:29:53 <achow101> hmm.. ok, I can try that too
19:29:54 <instagibbs> And "allow 1 negative EV output" type logic
19:30:06 <instagibbs> anyways, more to discuss on PR
19:30:25 <sipa> EV filtering is probably the biggest reason for increased UTXO
19:33:23 <MarcoFalke> Sorry for being late, but I'd like to propose #13439 for high priority for review
19:33:23 <instagibbs> "allow 1" might be nice in that you won't blow up way past what is actually sane, while containing the bloat
19:33:25 <gribble> https://github.com/bitcoin/bitcoin/issues/13439 | rpc: Avoid "duplicate" return value for invalid submitblock by TheBlueMatt · Pull Request #13439 · bitcoin/bitcoin · GitHub
19:35:21 <wumpus> MarcoFalke: sure
19:35:28 <MarcoFalke> thx
19:36:14 <wumpus> MarcoFalke: done
19:36:17 <wumpus> any other topics?
19:39:01 <sipa> i have 4 PRs open relating to optimized hardware SHA256... should I combine them into 1, or leave like this?
19:39:15 <wumpus> let me see
19:39:39 <sipa> #13471 #13386 #13442 #13438
19:39:40 <gribble> https://github.com/bitcoin/bitcoin/issues/13471 | For AVX2 code, also check for AVX, XSAVE, and OS support by sipa · Pull Request #13471 · bitcoin/bitcoin · GitHub
19:39:42 <gribble> https://github.com/bitcoin/bitcoin/issues/13386 | SHA256 implementations based on Intel SHA Extensions by sipa · Pull Request #13386 · bitcoin/bitcoin · GitHub
19:39:43 <gribble> https://github.com/bitcoin/bitcoin/issues/13442 | Convert the 1-way SSE4 SHA256 code from asm to intrinsics by sipa · Pull Request #13442 · bitcoin/bitcoin · GitHub
19:39:44 <gribble> https://github.com/bitcoin/bitcoin/issues/13438 | Improve coverage of SHA256 SelfTest code by sipa · Pull Request #13438 · bitcoin/bitcoin · GitHub
19:39:54 <wumpus> it's good for the selftest one to be seperate, I think that one can be merged
19:40:19 <wumpus> I haven't really looked at the other ones yet in detail yet
19:40:33 <cfields> sipa: I have a follow-up PR as well to build a lib-for-each-arch
19:40:38 <sipa> cfields: ah yes
19:40:46 <sipa> i'll leave things like this
19:40:48 <cfields> I figured I'd just wait until everything settled for that one, but let me know if you'd prefer something else
19:40:59 <wumpus> re: 13442, didn't you first say that made things a few % *slower* on 64 bit?
19:41:15 <sipa> wumpus: i made more changes, it's faster now
19:41:22 <wumpus> great, no problems with it anymore then
19:41:34 <sipa> but it's very heavily compiler dependent... rearranging two lines can have 5% effect on speed
19:41:51 <wumpus> seems preferable in every way then
19:41:51 <sipa> or making a constant static
19:41:59 <sipa> how so?
19:42:10 <wumpus> both more readable and faster
19:42:19 <sipa> ah yes, but probably less reliably faster
19:42:23 <sipa> perhaps on clang it's slower
19:42:25 <cfields> sipa: also worth considering (I read this just yesterday), apparently gcc switched the way that 256bit loads are done, somewhere around gcc6, I believe.
19:42:28 <sipa> or with particular gcc versions
19:42:33 <cfields> so, worth considering compiler age as well.
19:42:38 <wumpus> right
19:43:41 <wumpus> if it becomes faster with new compilers it's good
19:43:56 <wumpus> if slower, not :)
19:43:58 <cfields> (see gcc's "mavx256-split-unaligned-load" option, which had its default value changed)
19:44:16 <ryanofsky> cd
19:44:37 <sipa> wumpus: another benefit is that this lets us compile the exact same code with -mavx, and get a slightly faster version for AVX capable machines
19:44:40 <cfields> ~$
19:44:50 <wumpus> sipa: that's really nice
19:45:00 <wumpus> sipa: so we compile it twice, the same code?
19:45:05 <sipa> wumpus: yup
19:45:12 <sipa> cfields is working on build system changes for that
19:45:16 <wumpus> almost for free
19:45:36 <sipa> i wonder what percentage of our binary will be SHA256 implementations...
19:46:09 <wumpus> a very small part
19:46:13 <cfields> heh
19:46:33 <wumpus> though I understand the sentiment :)
19:47:29 <wumpus> as for the source code, a larger part, which reminds me I still need to add ARM
19:47:48 <wumpus> POWER8 one needs review #13203
19:47:50 <gribble> https://github.com/bitcoin/bitcoin/issues/13203 | Add POWER8 ASM for 4-way SHA256 by TheBlueMatt · Pull Request #13203 · bitcoin/bitcoin · GitHub
19:48:31 <sipa> cfields: we should also try with things like -mmovbe, -mbmi1, -mbmi2, ...
19:48:34 <wumpus> that's really an instruction set I have no clue about
19:48:43 <sipa> cfields: i think these may not be implied by -mavx / -mavx2
19:48:59 <sipa> but generally available on the same systems
19:49:05 <cfields> sipa: yes. IIRC bmi provides some useful things.
19:49:34 <cfields> yea, rorx
19:49:47 <cfields> sorry, that's bmi2
19:52:37 <wumpus> I'm lost
19:52:50 <sipa> don't worry :)
19:53:16 <wumpus> :)
19:53:27 <wumpus> any quick topic?
19:53:42 <achow101> when 0.16.1 detached sigs?
19:54:06 <cfields> achow101: soon, building now
19:54:21 <cfields> jonasschnelli: ^^ ping for other half
19:54:43 <jonasschnelli> already made
19:54:45 <jonasschnelli> https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/8
19:54:48 <wumpus> cfields: jonasschnelli: thanks
19:55:13 <cfields> jonasschnelli: ah, I missed the pr! You beat me to it :)
19:55:29 <jonasschnelli> :-)
19:55:30 <GitHub133> [13bitcoin-detached-sigs] 15laanwj closed pull request #8: 0.16.1: osx signatures for 0.16.1 (060.16...060.16) 02https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/8
19:57:03 <luke-jr> hi
19:57:14 <wumpus> jonasschnelli: you should probably be able to merge your own stuff there
19:57:41 <jonasschnelli> wumpus: Yes. I did create the PR because I wasn't sure if we did hit the threshold or required non code-signed signatures
19:58:02 <wumpus> right, good point
19:58:39 <luke-jr> well, as soon as the signatures exist, someone could potentially use them
19:58:46 <luke-jr> so if the threshold isn't met, even a PR could be problematic
19:58:55 <wumpus> 5 signers for every platform so that seems ok
19:59:23 <cfields> yea, it'd only be an issue if there were 2 competing "correct" gitian outputs
19:59:33 <wumpus> agree that for a -final relaese it's better to wait for a few more
19:59:34 <cfields> I think that's happened in the past due to timezones
19:59:42 <luke-jr> 5 is fine
19:59:46 <wumpus> cfields: yes, that's worrying
19:59:51 <luke-jr> IIRC threshold was 3 anyway
20:00:03 <wumpus> meeting ending in 1 minute
20:00:07 <wumpus> oh no, now
20:00:09 <wumpus> #endmeeting