< bitcoin-git> [bitcoin] MarcoFalke pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/f359afcc4104...6970b30c6f1d
< bitcoin-git> bitcoin/master ca6523d Anthony Towns: [tests] Rename feature_* functional tests.
< bitcoin-git> bitcoin/master 90600bc Anthony Towns: [tests] Rename wallet_* functional tests.
< bitcoin-git> bitcoin/master 61b8f7f Anthony Towns: [tests] Rename p2p_* functional tests.
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11774: [tests] Rename functional tests (master...rename_tests) https://github.com/bitcoin/bitcoin/pull/11774
< bitcoin-git> [bitcoin] kallewoof opened pull request #12265: [test] fundrawtransaction: lock watch-only shared address (master...test-fundrawtransaction-lockunspent) https://github.com/bitcoin/bitcoin/pull/12265
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #12266: Move scheduler/threadGroup into common-init instead of per-app (master...2018-01-common-init) https://github.com/bitcoin/bitcoin/pull/12266
< BlueMatt> cfields: #12266
< gribble> https://github.com/bitcoin/bitcoin/issues/12266 | Move scheduler/threadGroup into common-init instead of per-app by TheBlueMatt · Pull Request #12266 · bitcoin/bitcoin · GitHub
< sipa> added 0.16 tag
< bitcoin-git> [bitcoin] statebits opened pull request #12267: Update blockchain size in Ravencoin/doc/Readme (master...master) https://github.com/bitcoin/bitcoin/pull/12267
< bitcoin-git> [bitcoin] statebits closed pull request #12267: Update blockchain size in Ravencoin/doc/Readme (master...master) https://github.com/bitcoin/bitcoin/pull/12267
< ProfMac> Does it make sense to do the git clone into /opt, /var/opt, or ~{$USER}/opt
< jonasschnelli> ProfMac: i guess that depends...
< jonasschnelli> clone it to wherever you have enough space to compile... :)
< jonasschnelli> I would recommend within you userspace
< jonasschnelli> If you want to make the binaries accessable to everyone, use "make install" (probably sudo)
< ProfMac> jonasschelli, thanks. Userspace then make install makes good sense.
< promag> iiuc #12265 fixes a bug in the test, should be 0.16?
< gribble> https://github.com/bitcoin/bitcoin/issues/12265 | [test] fundrawtransaction: lock watch-only shared address by kallewoof · Pull Request #12265 · bitcoin/bitcoin · GitHub
< promag> jnewbery: flake8 --ignore=B,C,E,F,I,N,W --select=F401 test/functional/p2p-versionbits-warning.py in master I get not warnings
< promag> s/not/no
< jnewbery> promag: that's because --ignore is suppressing all the warnings
< jnewbery> our Travis linter only checks for F401 (module imported but unused), but in general it's preferable to follow PEP8, all other things being equal: https://github.com/bitcoin/bitcoin/blob/6970b30c6f1d2be7947295fe18f2390649b17a4b/test/functional/README.md#style-guidelines
< promag> ok got it
< promag> so how do you usually run?
< promag> flake8 file?
< jnewbery> I use Syntastic in vim so it runs flake8 every time I save a python file. My ~/.config/flake8 file has:
< jnewbery> ignore = E302,E305,E501,E731
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/6970b30c6f1d...598a9c4e4dcd
< bitcoin-git> bitcoin/master ef2beb2 John Newbery: Fix flake8 warnings in p2p-versionbits-warning.py
< bitcoin-git> bitcoin/master 3bbd843 John Newbery: Improve comments/logging in p2p-versionbits-warning.py
< bitcoin-git> bitcoin/master 1e2e09e John Newbery: Fix intermittent failure in p2p-versionbits-warning.py...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12264: Fix versionbits warning test (master...fix_versionbits_warning_test) https://github.com/bitcoin/bitcoin/pull/12264
< promag> thanks jnewbery
< * wumpus> should probably start doing that too
< * jnewbery> gets annoyed by it sometimes and has to run :SyntasticToggleMode to stop his screen being filled with red
< mrannanay> @jnewbery I can relate so much xD
< bitcoin-git> [bitcoin] gmaxwell opened pull request #12269: Update defaultAssumeValid to block 506067 (master...201801-update-assumevalid) https://github.com/bitcoin/bitcoin/pull/12269
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/598a9c4e4dcd...16bac24f60fa
< bitcoin-git> bitcoin/master 55f52bd Wladimir J. van der Laan: contrib: Update ATTERN_AGENT to include 0.15.x
< bitcoin-git> bitcoin/master 1e90544 Wladimir J. van der Laan: net: Update hardcoded seeds...
< bitcoin-git> bitcoin/master 16bac24 Wladimir J. van der Laan: Merge #12262: net: Hardcoded seed update...
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/16bac24f60fa...2ae7cf8ef5be
< bitcoin-git> bitcoin/master bde8bcd Gregory Maxwell: Update defaultAssumeValid according to release-process.md....
< bitcoin-git> bitcoin/master 2ae7cf8 Wladimir J. van der Laan: Merge #12269: Update defaultAssumeValid to block 506067...
< bitcoin-git> [bitcoin] laanwj closed pull request #12269: Update defaultAssumeValid to block 506067 (master...201801-update-assumevalid) https://github.com/bitcoin/bitcoin/pull/12269
< bitcoin-git> [bitcoin] laanwj opened pull request #12270: Update chainTxData for 0.16 (master...2018_01_chainstats) https://github.com/bitcoin/bitcoin/pull/12270
< bitcoin-git> [bitcoin] Ov3rlo4d closed pull request #12029: Build: Add a makefile target for Doxygen documentation (master...make-doxygen) https://github.com/bitcoin/bitcoin/pull/12029
< bitcoin-git> [bitcoin] Ov3rlo4d reopened pull request #12029: Build: Add a makefile target for Doxygen documentation (master...make-doxygen) https://github.com/bitcoin/bitcoin/pull/12029
< achow101> meeting?
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Jan 25 19:00:23 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< provoostenator> Hi
< 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
< jonasschnelli> hi
< achow101> can we release 0.16 yet?
< meshcollider> Hi
< wumpus> today or tomorrow, hopefully
< instagibbs> perhaps an RC first
< wumpus> there's still two PRs open
< wumpus> instagibbs: always
< cfields> hi
< kanzure> hi.
< instagibbs> wumpus, thatsthejoke.gif
< instagibbs> not sure how to evaluated the chain stats one
< jtimon> before releasing we would need to fork from master, no?
< instagibbs> jtimon, can happen immediately after, afaik
< wumpus> so the chaintxdata needs to be checked and BlueMatt's pr reviewed
< instagibbs> well, version bump ofc
< wumpus> jtimon: yes, no way I'm going to forget that
< jtimon> instagibbs: without rc?
< Chris_Stewart_5> hello
< achow101> jtimon: branching happens right before rc is tagged
< jtimon> achow101: right
< wumpus> branch -> [on 0.16 branch] change version information -> tag rc
< cfields> oh shit, I never PR'd the rpc fd exhaustion fix. wumpus: ok to do that right after meeting and add to 0.16 milestone?
< wumpus> -> [on master] change version information -> clear out release notes
< wumpus> 0.16 branch will be 0.16.0 (with release=true) master will be 0.16.99
< wumpus> cfields: sure
< cfields> thanks
< wumpus> though maybe it can wait for 0.16.1 too, I don't know, it's only a local issue
< MarcoFalke> It's a major release. There is no way we will have only one rc
< MarcoFalke> Backport works as well
< jtimon> although not a huge bug, https://github.com/bitcoin/bitcoin/pull/12172 is a bugfix (and a simple one)...
< wumpus> right
< wumpus> please, we want to do the release, we're not going too add more stuff to 0.16.0 now unless absolutely critical
< jonasschnelli> yes... we did already last week... this week is release week. :)
< wumpus> it's the same story every week
< jonasschnelli> heh...
< wumpus> and as MarcoFalke says there's no way there's only going to be one rc
< wumpus> there are going to be problems that come up in rc1 and have to be fixed
< jtimon> it's not like that +9-4 change is going to break anything, but ok
< MarcoFalke> and release notes to be written ...
< MarcoFalke> jtimon: It still needs review. I told you last week
< jtimon> MarcoFalke: sure, it needs more review
< jtimon> anyway, never mind
< MarcoFalke> jtimon: I like it, but others need to like it as well
< meshcollider> Release notes for major releases are so much longer than point releases but I'll try and find time if noone else does
< MarcoFalke> meshcollider: Even doing half of it would help
< wumpus> maybe we could put it in the wiki again?
< MarcoFalke> oh right
< meshcollider> wumpus: yeah +1
< wumpus> #action put release 0.16 notes in wiki
< achow101> yes, let's do the wiki thing again
< BlueMatt> yes, #12266 needs review :/
< wumpus> and re: #12270 does anyone know the exact process there?
< gribble> https://github.com/bitcoin/bitcoin/issues/12266 | Move scheduler/threadGroup into common-init instead of per-app by TheBlueMatt · Pull Request #12266 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/12270 | Update chainTxData for 0.16 by laanwj · Pull Request #12270 · bitcoin/bitcoin · GitHub
< wumpus> the release notes are quite unclear on chainTxData
< BlueMatt> wumpus: maybe sipa can confirm, he's currently mid-giving-talk
< cfields> BlueMatt: is there q/a after?
< BlueMatt> lol
< kanzure> oh bpase scheduling
< cfields> BlueMatt: thanks for the fix, btw. taking a look.
< meshcollider> Are bpase talks recorded btw
< kanzure> site says videos will be posted later
< wumpus> any other topics?
< achow101> coin selection?
< achow101> (again)
< wumpus> #topic coin selection
< Murch> Currently listening to sipa @ BPASE :p
< achow101> I did some more simulations, this time with varying fee rates
< wumpus> I saw a new PR was openened about that #12257, haven't had time to look at it yet
< gribble> https://github.com/bitcoin/bitcoin/issues/12257 | [wallet] Use destination groups instead of coins in coin select by kallewoof · Pull Request #12257 · bitcoin/bitcoin · GitHub
< achow101> the results don't seem to be very impressive though
< meshcollider> wumpus: that's pretty orthogonal I think, it's a privacy thing rather than an efficient selection thing
< wumpus> ok...
< achow101> I'm not sure of BnB is going to be much of an improvement over what we currently have
< achow101> s/of/that/
< achow101> at the very least, it doesn't do worse
< wumpus> that's already good if it is a win in runtime
< achow101> it actually runs a lot slower
< meshcollider> Oh
< wumpus> ouch
< achow101> I noticed during the simulations that running BnB takes longer since it has to exhaust the search before it continues with the current algo
< morcos> Should we save this conversation for when Murch can join?
< achow101> It seems to only be faster when it can find a solution, which is not all that frequent
< Murch> achow101: I just had a look at the results. How come that there were several hundred instances of BnB use but only one fewer change output created than without BnB?
< Murch> I think there is an unexpected behavior there.
< achow101> oh, that's strange
< achow101> I will look into that
< wumpus> thanks
< wumpus> any other topics?
< Chris_Stewart_5> achow101: It seems like the algo would obviously be slower if it reverts to the old algo?
< jtimon> perhaps a short meeting today?
< achow101> Chris_Stewart_5: yes
< meshcollider> jtimon: yes seems sipa's talk has stolen the show today :)
< achow101> Chris_Stewart_5: logically, reverting means that it's running more code, so it kinda has to be slower
< Chris_Stewart_5> so the high failure rate is the main concern?
< jtimon> meshcollider: oh, what talk?
< meshcollider> jtimon: at bpase
< wumpus> jtimon: yep
< wumpus> let's review stuff for 0.16 after the talk :)
< jtimon> oh, I'll wait for the video
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Jan 25 19:30:28 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jonasschnelli> Where is sipas talk?
< Chris_Stewart_5> is bpase live on youtube?
< instagibbs> murchandamus, achow101 yes those results look really strange
< meshcollider> Chris_Stewart_5: I couldn't find it, kanzure said they'll be posted later
< instagibbs> now that i think about it, highly improbably? unless classical selection ends up doing no-change solution a lot more somehow
< instagibbs> or BnB only finds the dumb solutions that classic selection would have found
< achow101> instagibbs: murchandamus perhaps review what I'm using to simulate?
< meshcollider> Also the coredev channel is invite only now? I need an invite to it :)
< sipa> meshcollider: are you at bpase?
< achow101> I may have screwed up how I count things
< achow101> meshcollider: yes, it's invite only now
< meshcollider> sipa: no unfortunately not
< instagibbs> achow101, print out how often core selection gets no change solution, as a start
< sipa> i believe videos will be online later
< instagibbs> in both scenarios, with and without bnb
< jonasschnelli> thanks
< kanzure> it's surprisingly difficult to transcribe without being there and also without audio/video
< kanzure> i can only guess what was said, but i think i could have >20% accuracy
< meshcollider> kanzure: are you op in the coredev channel
< sipa> kanzure: lol!
< kanzure> nah, i'll ping someone for you
< achow101> meshcollider: ask jnewbery or morcos
<@sipa> i haz op
<@sipa> oh, coredev channel, not core-dev
<@sipa> nvm
< kanzure> meshcollider: moderator says you are good under meshcollider name... pm me the channel you think you're joining.
< achow101> sipa: aren't you supposed to be giving a talk?
< sipa> achow101: just finished
< kanzure> irc on stage is fine
< kanzure> standard procedure
< Chris_Stewart_5> lol
< Chris_Stewart_5> priorties! There is a core-dev meeting!
< kanzure> i assume it was a musig talk
< sipa> kanzure: nooe!
< sipa> nope!
< kanzure> accuracy going down.. :-)
< sipa> it was on bellare-neven multi-signatures
< achow101> so almost musig
< sipa> (and generally the advantages of schnorr-like signature schemes, including the ability to use musig to aggregate keys)
< sipa> yup
< cfields> kanzure: thanks a ton for that, btw. There's no wikipedia entry for BN sigs, so I always end up hitting that link when I google for the paper
< kanzure> yep no problem
< kanzure> really weird how a lot of this stuff just gets lost
< jonasschnelli> BlueMatt: GuessVerificationProgress needs cs_main, right? (accessing pindex->nChainTx )
< jojeyh> sipa, is it possible to see these talks live ?
< jojeyh> or even a recording i guess
< sipa> kanzure: at RWC we ran into Neven, who sounded very excited that someone may actually use his scheme :)
< sipa> jojeyh: there will be a recording later
< jojeyh> danke
< kanzure> sipa: has he reviewed the paper yet?
< BlueMatt> jonasschnelli: yup
< instagibbs> gmaxwell, morcos some not completely thought out discussion on fee bumping/transaction replacement #12271 . I haven't really seen a good central location for discussion, so I continue re-inventing the wheel
< gribble> https://github.com/bitcoin/bitcoin/issues/12271 | Improving fee bumping in Core · Issue #12271 · bitcoin/bitcoin · GitHub
< luke-jr> :o "Two new instructions (addex and vmsumudm) introduced to accelerate arbitrary-precision integer arithmetic, and specifically to accelerate Blockchain’s implementation of elliptical curve encryption signature algorithm. The OV bit is employed to provide an additional, independent carry status bit, allowing software to parallelize carry propagation."
< wumpus> luke-jr: whoa, interesting
< achow101> luke-jr: what is that for?
< wumpus> powerpc 9 ISA apparently
< luke-jr> achow101: POWER9
< luke-jr> "Add Extended using alternate carry bit Z23-form" and "Vector Multiply-Sum Unsigned Doubleword Modulo VA-form"
< luke-jr> "The unsigned integer value in doubleword element 0 of VR[VRA] is multiplied by the unsigned integer value in doubleword element 0 of VR[VRB] to produce a 128-bit product. The unsigned integer value in doubleword element 1 of VR[VRA] is multiplied by the unsigned integer value in doubleword element 1 of VR[VRB] to produce a 128-bit product. The two 128-bit unsigned integer products and the 128-bit unsigned integer in VR[VRC] are summed.
< wumpus> vmsumudm seems SIMD 2x 64*64 -> 128 bit multiplication, where the two results are added to a third 128 bit value
< luke-jr> The low-order 128 bits of the sum are placed into VR[VRT]. Any carry out or overflow status is discarded."
< luke-jr> hopefully this is compatible with libsecp256k1's existing optimisations
< wumpus> that seems quite useful for the kind off mult-sum operations in secp256k1 secp256k1_fe_mul_inner and such
< * luke-jr> wonders if it is still useful for the new aggregation-capable signature scheme
< wumpus> I'd be surprised if the low level operations are not still the same