< achow101> is the zmq_test failing for anyone else?
< achow101> (in rpc tests)
< jonasschnelli> jnewbery: jeremyrubin: I can hold back the PR. There is no hurry. Lets firs aim on the one you have listed above
< gmaxwell> jonasschnelli: I happened to see the list recently, and I think you shouldn't waste your time arguing with people who are philosophically opposed to supporting encryption. These people are acting in a way which is harmful to human rights and wellfare. I do not know if they are confused or if they are working for state actors which are opposed to personal freedom, or what. But it's a waste of ti
< gmaxwell> me. Support for encryption and authication is completely optional and if other people want to use it it simply isn't any of their busienss.
< jonasschnelli> gmaxwell: Yes. That had cost me a lot of time and nerves... :)
< jonasschnelli> Thanks!
< jonasschnelli> gmaxwell: What I really dislikes is that those guys tried to enflame others and it partially worked... that's why I was commenting on some of the concerns
< luke-jr> gmaxwell: or possibly scared of what State actors opposing encryption might do to them/Bitcoin
< gmaxwell> luke-jr: if so, then they're arguing dishonestly... and I can't see a reason to do that.
< luke-jr> hm
< gmaxwell> If someone argued that adding encryption to Bitcoin would make some state actors hate bitcoin, I think that could be pretty easily refuted.
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/afae75fd3dad...8dee82217708
< bitcoin-git> bitcoin/master 55c403b John Newbery: Ensure `-maxsigcachesize` is in valid range...
< bitcoin-git> bitcoin/master 8dee822 Wladimir J. van der Laan: Merge #9777: Handle unusual maxsigcachesize gracefully...
< bitcoin-git> [bitcoin] laanwj closed pull request #9777: Handle unusual maxsigcachesize gracefully (master...sigcache2) https://github.com/bitcoin/bitcoin/pull/9777
< * wumpus> running gitian builds to check pre-rc1
< Victorsueca> wumpus: you're going to tag 0.14 rc1 today?
< wumpus> Victorsueca: unless there is a critical issue, that's the plan
< Victorsueca> wumpus: anything that needs some extra testing on windows?
< wumpus> argh my dev/build machine died, that's not a good start of the day...
< Victorsueca> RIP
< wumpus> building bitcoin core apparently breaks power supplies now :-) things should be back to normal, restarting testing gitian builds in a bit
< gmaxwell> libsecp256k1 easily overheats cpus.
< luke-jr> building it⁇
< gmaxwell> for libsecp256k1? running the tests... which you hopefully do at build time!
< Victorsueca> I'm making the depends and it's downloading samba ccache, is that new or it just got updated?
< Victorsueca> ffs, it's downloading everything again, not sure why
< Victorsueca> I hate building boost
< wumpus> building boost should be very quick, at least from depends, we have restricted that to only build the modules and variants that we actually use
< wumpus> building qt on the other hand...
< wumpus> we have done the same there - select only what we need, but GUI toolkits are beasts
< Victorsueca> problem with boost is not nly the time it takes, it's quiet, there's nothing more stressing than that, you don't know if it's still building or it got stuck
< wumpus> I'm pretty sure there's a flag to make it verbose, if you want that
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8dee82217708...3c02b957402e
< bitcoin-git> bitcoin/master 3f78e46 Gregory Maxwell: Update nMinimumChainWork and defaultAssumeValid.
< bitcoin-git> bitcoin/master 3c02b95 Wladimir J. van der Laan: Merge #9779: Update nMinimumChainWork and defaultAssumeValid....
< bitcoin-git> [bitcoin] laanwj closed pull request #9779: Update nMinimumChainWork and defaultAssumeValid. (master...update_chainparams) https://github.com/bitcoin/bitcoin/pull/9779
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3c02b957402e...ad168ef4e308
< bitcoin-git> bitcoin/master 91fb506 Alex Morcos: Add two hour buffer to manual pruning
< bitcoin-git> bitcoin/master ad168ef Wladimir J. van der Laan: Merge #9778: Add two hour buffer to manual pruning...
< bitcoin-git> [bitcoin] laanwj closed pull request #9778: Add two hour buffer to manual pruning (master...2hrprune) https://github.com/bitcoin/bitcoin/pull/9778
< bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/ad168ef4e308...9828f9a9962c
< bitcoin-git> bitcoin/master 8be0866 Russell Yanofsky: [qa] Simplify import-rescan.py...
< bitcoin-git> bitcoin/master c28583d Russell Yanofsky: [qa] Extend import-rescan.py to test specific key timestamps
< bitcoin-git> bitcoin/master 38d3e9e Russell Yanofsky: [qa] Extend import-rescan.py to test imports on pruned nodes.
< bitcoin-git> [bitcoin] laanwj closed pull request #9761: Use 2 hour grace period for key timestamps in importmulti rescans (master...pr/multigrace) https://github.com/bitcoin/bitcoin/pull/9761
< achow101> don't forget to increment the version number this time :p
< wumpus> I don't think I ever forgot that for a major release, just minor releases
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/bc69f34b3537a7d34fb7f89b4acd619749bc6cc2
< bitcoin-git> bitcoin/0.14 bc69f34 Wladimir J. van der Laan: build: bump version to 0.14.0
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/f87e8f53920adfa80a3f4af9435370dc272c3783
< bitcoin-git> bitcoin/master f87e8f5 Wladimir J. van der Laan: build: bump version to 0.14.99...
< achow101> ooh branching
< MarcoFalke_> branch off ''\o/''
< wumpus> yep, it's that time of the year
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/f68e4414d77aeb60d8dee1b2e53a195ff15b2c48
< bitcoin-git> bitcoin/0.14 f68e441 Wladimir J. van der Laan: qt: pre-rc1 translations update
< MarcoFalke_> I think `gen-manpages.sh` needs to be run on 0.14
< wumpus> ok
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/1a02ecc73af4b4ac36da1bd04f9e7eddf640e48f
< bitcoin-git> bitcoin/0.14 1a02ecc Wladimir J. van der Laan: doc: Update release notes from wiki
< wumpus> will do that in a bit
< cfields> did a full gitian build of linux/win/osx as of a few commits ago (afae75fd3da). So far, linux/osx test_bitcoin pass, osx gets reliable rpc test failure: http://pastebin.com/raw/7mgt7jsQ
< wumpus> argh
< cfields> will re-test from 0.14 after the latest importmulti changes
< wumpus> and it doesn't happen with normal build of the same, just gitian?
< wumpus> I don't remember that issue on travis so probably
< cfields> wumpus: i haven't tried an osx build from the same spot, i'll do that at the same time as the 0.14 rebuild
< Arvidt> Is it better for Bitcoin to run a full node, or is it also ok ok to run a pruned node with 100 GiB (-prune=100000) ?
< wumpus> when running a pruned node it doesn't matter what the size is, no pruned node will serve blocks
< wumpus> so if you want to provide blocks to other nodes that are bootstrapping, you need to run a non-pruned node, at least currently
< Arvidt> ok, thanks for the info. There is very few information about pruned mode in the internet, only bitcoiin core release notes and some bitcointalk thread that are two years old.
< wumpus> the full node guide mentions pruning as well https://bitcoin.org/en/full-node#configuration-tuning , though it doesn't mention that currently pruned nodes will not serve blocks
< wumpus> feel free to add it, most if not all the documents are open source
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/268c390d02d99a4a93a0a01221e273d2b9695ff7
< bitcoin-git> bitcoin/0.14 268c390 Wladimir J. van der Laan: doc: Update manpages for 0.14.0
< cfields> wumpus: local build passes :\. Waiting for gitian built to finish so i can compare.
< wumpus> ok, hopefully it was a false positive
< cfields> wumpus: yes, that tests passes on 0.14. Still waiting for the whole suite to finish, but looks like a false alarm
< achow101> I had an rpc test failing yesterday, I'm checking again now on master to see if it still fails
< achow101> yeah, zmq_test.py still fails for me
< cfields> ok, all osx pass
< cfields> wumpus: need to bump the gitian descriptors if we want separate package caches for 0.13/0.14. Will PR now.
< bitcoin-git> [bitcoin] theuni opened pull request #9783: release: bump gitian descriptors for a new 0.14 package cache (0.14...gitian-descriptor-bump) https://github.com/bitcoin/bitcoin/pull/9783
< Chris_Stewart_5> Will this 'normalize' function in secp256k1 strip uneccessary padding on signatures? https://github.com/bitcoin/bitcoin/blob/master/src/pubkey.cpp#L183
< Chris_Stewart_5> We have a specific test in script_tests.json that pads R values and doesn't require DERSIG flag
< wumpus> cfields: I had no idea that we were still using the 0.13 dependencies for master
< bitcoin-git> [bitcoin] laanwj closed pull request #9783: release: bump gitian descriptors for a new 0.14 package cache (0.14...gitian-descriptor-bump) https://github.com/bitcoin/bitcoin/pull/9783
< cfields> wumpus: it doesn't matter a ton. The chain is hashed and it always grabs the right deps based on the recipe. Splitting just lets you keep them separate, so you can stash 0.13 away if you want, to save time for 0.13.3 build
< wumpus> cfields: right
< gmaxwell> release notes still say nothing about the massive performance improvements. Shall I write something?
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/871e19ac84ae71b3d22928d5cb3bbf4f0f013b07
< bitcoin-git> bitcoin/0.14 871e19a Wladimir J. van der Laan: doc: Add list of authors to release notes...
< wumpus> sure, that'd be very welcome, release notes can be updated until the final release
< wumpus> still need to add the big list of changes too
< cfields> gmaxwell: i started to a few days ago but got distracted. I'm unsure if we want to just add a "performance increases" section and add a bunch of stuff, or add individual features and mention what they speed up
< gmaxwell> Perfmrnace increases with a line per improvement might be nice.
< cfields> gmaxwell: works for me. Have you already started, or shall I?
< gmaxwell> Go ahead. Hm. I thought I wrote release notes for assume valid.
< gmaxwell> that certantly should be release noted, esp as someone might feel its a security model change (at least without the explination)
< gmaxwell> oh Idid and it was just all removed. :(
< cfields> gmaxwell: sure, and imo it goes under performance improvements. Not sure if that's what you were implying. But to an end-user, that's surely the benefit
< gmaxwell> It is a performance improvement but unless explained it could be understood as a significant security model change.
< gmaxwell> Can someone please explain to me why the release note for that was removed?
< wumpus> what was removed? you should edit the release notes in 0.14, not on master
< wumpus> master was completely cleaned out
< gmaxwell> wumpus: doing that means that changes that write their release notes get their notes nuked.
< sipa> gmaxwell: ?
< wumpus> gmaxwell: this has been the case for every major release
< sipa> things that are merged in 0.14 have their notes in 0.14
< wumpus> 0.14 is branched off, master is 0.15 now
< gmaxwell> The releas enote was removed for 0.14
< sipa> ah, update from the wiki
< gmaxwell> so was -0.14.0 Fundrawtransaction change address reuse
< wumpus> gmaxwell: wasn't that just moved somewhere else?
< achow101> the problem was that some things got into the release notes in the repo, and others were in the wiki
< wumpus> it's in the wrong place after all, in the section reserved for PRs
< wumpus> so my assumption was that it was moved upwards, but if it got removed it should be added back (in the right place)
< gmaxwell> wumpus: it was in the notable changes section, and no it's nowhere mentioned in the release notes now.
< wumpus> ok, re-add it then
< gmaxwell> At least I know what happened now!
< gmaxwell> I think we do want changes writing their own release notes, no? we'll just need to figure out how to merge that with the wiki.
< gmaxwell> (in the future)
< wumpus> gmaxwell: I apparently missed that when merging changes from the wiki; I saw some stuff was removed, but Ithought it were just the items in the wrong place that were merged back
< wumpus> in the future we should pay attention to changes, just like you did now, good job
< wumpus> :)
< cfields> sipa / gmaxwell: any notable perf improvements from libsecp256k1 for 0.14? I'm hazy on the timeline
< sipa> cfields: no, i don't think so
< cfields> ok, thanks
< cfields> ah, docs need ctaes reference
< sipa> oh, was ctaes new for 0.14?
< gmaxwell> No.
< cfields> huh, seemed recent
< bitcoin-git> [bitcoin] gmaxwell opened pull request #9784: Restore removed release notes. (0.14...release_notes) https://github.com/bitcoin/bitcoin/pull/9784
< cfields> yep, present in 0.13.0. nm.
< gmaxwell> I don't know if we ever release noted. :)
< cfields> jus this: - #7689 `b89ef13` Replace OpenSSL AES with ctaes-based version (sipa)
< gribble> https://github.com/bitcoin/bitcoin/issues/7689 | Replace OpenSSL AES with ctaes-based version by sipa · Pull Request #7689 · bitcoin/bitcoin · GitHub
< wumpus> is it something that affects end users much?
< gmaxwell> yea, kinda sad because that was a relly impressive work.
< gmaxwell> a secondary purpose of release notes, its also a communication channel about what we're doing.
< gmaxwell> (and interesting to)
< gmaxwell> the only effect on users was that it avoided some build problems with openssl api changes that some people expirenced later.
< wumpus> the release notes for 0.13 were already huge, if there are too many notable changes no one is going to read everything
< wumpus> I think it's fine to not add a specific paragraph for everything
< wumpus> i'm certainly in favor of publishing awesome developer changes in bitcoin core, but I'm not sure the release notes is the right place for that
< wumpus> a tech blog on bitcoincore.org would be nice
< gmaxwell> That is fair too.
< gmaxwell> But who has the time?
< wumpus> well if you'd have the time to add it to the release notes, you'd also have time to write a blog post, those are equivalent time-wise
< gmaxwell> release note would have been one/two paragraphs, would make for a kind of lame blogpost. :P
< wumpus> brg444 did a nice writeup on bitcoin core performance improvements
< gmaxwell> but there could be summary posts, I suppose with things that weren't important enough to usage to go into the release notes.
< wumpus> why? not everything needs to be a long story
< wumpus> short, frequent updates are good too
< Chris_Stewart_5> The Chronicles of Bitcoin Core (TM)
< gmaxwell> I hope he hasn't published that yet, it didn't have measurement last I saw and was weaker without it... unfortunately it takes so long to sync with older versions it takes a while to get numbers! :)
< wumpus> I don't think he has, but I like that it puts everything into context
< gmaxwell> wumpus: Thanks, good points.
< gmaxwell> Yea, I saw a draft too... I should check again, it was missing a bunch of stuff but I bet he's added it now.
< gmaxwell> We have two stack protector not protecting compiler warnings on 0.14 branch, might want to consider fixing in the next RC if they're trivial fixes.
< cfields> gmaxwell: ah, nice. I've been trying to figure out how to state the net performance improvements in a meaningful way. Full IBD from before/after seems pretty reasonable.
< wumpus> what causes those?
< wumpus> and I don't think I've ever seen those warnings, what gcc/clang gives them?
< gmaxwell> "running newer compilers" :P
< gmaxwell> httprpc.cpp: In function ‘bool HTTPReq_JSONRPC(HTTPRequest*, const string&)’:
< gmaxwell> httprpc.cpp:150:13: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector] static bool HTTPReq_JSONRPC(HTTPRequest* req, const std::string &)
< gmaxwell> qt/test/paymentservertests.cpp: In member function ‘void PaymentServerTests::paymentServerTests()’:
< gmaxwell> qt/test/paymentservertests.cpp:65:6: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector]
< gmaxwell> void PaymentServerTests::paymentServerTests()
< gmaxwell> ^~~~~~~~~~~~~~~~~~
< wumpus> oh in the tests in not important
< gmaxwell> first one isn't in tests. httprpc.
< gmaxwell> anyways anyone running more recent gcc will get them. (I don't know how recent is required, but 6.3.0 has them)
< wumpus> variable-length buffer on the stack in httprpc/!
< gmaxwell> thats what it appears to be reporting!
< wumpus> where?
< sipa> i don't see it!
< wumpus> didn't even know that was possible in c++
< sipa> it is
< gmaxwell> well C++11 IIRC added optional VLA.
< gmaxwell> this is what it reports:
< gmaxwell> static bool HTTPReq_JSONRPC(HTTPRequest* req, const std::string &)
< gmaxwell> ^~~~~~~~~~~~~~~
< gmaxwell> which made no sense to me but I figured there was some kind of over-my-head c++ magic happening.
< luke-jr> I get them with 4.9.4
< wumpus> I'm fairly sure I didn't *intend* that when writing that code at least
< wumpus> so I'm curious
< gmaxwell> I agree the test isn't so important, but the users compiling seeing warnings isn't ideal. Certantly lower priority.
< wumpus> I also think it's strange it comes up now
< sipa> i've seen that warning for months, at least
< wumpus> shouldn't that warning have been there for ages?
< gmaxwell> it's been there for a while but I ignore warnings in master because they're usually eliminated before release, didn't realize that most other people weren't seeing it.
< wumpus> oh and you just mention it now just before a release, ok :/
< gmaxwell> Actually I have mentioned it once before.
< gmaxwell> but I thought everyone else was seeing it too.
< gmaxwell> Sorry.
< sipa> building from scratch with 6.2.0 now, i'll report the warnings i get
< sipa> /usr/bin/ar: `u' modifier ignored since `D' is the default (see `U')
< wumpus> I don't think it's a big deal but I want to know what is causing a variable sized buffer there
< sipa> httprpc.cpp: In function ‘bool HTTPReq_JSONRPC(HTTPRequest*, const string&)’:
< sipa> httprpc.cpp:150:13: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector]
< sipa> static bool HTTPReq_JSONRPC(HTTPRequest* req, const std::string &)
< sipa> ^~~~~~~~~~~~~~~
< wumpus> variable-sized buffers on the stack are usually a code stink
< wumpus> honestly I thought the practice died in the 90's
< sipa> (several more 'u' modifier warnings)
< jonasschnelli> I think we should mention the AES change there...
< jonasschnelli> (in the release notes)
< wumpus> yes the modfifier warnings are well-known, there's an issue open for those IIRC
< gmaxwell> jonasschnelli: what aes change?
< jonasschnelli> Sorry,.. I hadn't scrolled down...
< gmaxwell> :P
< sipa> jonasschnelli, wumpus, gmaxwell: how about we first move all the AES mode of operation code into ctaes (it's currently in crypto/aes.cpp), and then write a blog post about ctaes in general
< jonasschnelli> I just saw a discussion about ctaes
< sipa> /usr/include/boost/type_traits/detail/bool_trait_def.hpp:18:78: note: #pragma message: NOTE: Use of this header (bool_trait_def.hpp) is deprecated
< sipa> # pragma message("NOTE: Use of this header (bool_trait_def.hpp) is deprecated")
< sipa> leveldb/db/memtable.cc: In member function ‘void leveldb::MemTable::Add(leveldb::SequenceNumber, leveldb::ValueType, const leveldb::Slice&, const leveldb::Slice&)’:
< sipa> leveldb/db/memtable.cc:104:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
< sipa> assert((p + val_size) - buf == encoded_len);
< wumpus> yes, there are a few warnings in boost, those depend on the boost version
< wumpus> there's also warnings in leveldb those need to be fixed upstream
< cfields> heh, i have a fix for the deprecated boost thing. Will PR in a few min.
< cfields> sipa: i did a cbc ctaes over the weekend, just need to get it cleaned up
< wumpus> sipa: sounds good to me
< cfields> sipa: out of curiosity, does the rpc warning go away if you make the function non-static ?
< gmaxwell> cfields: no.
< sipa> cfields: no
< cfields> ok, thanks
< gmaxwell> I am bisecting its code.
< jonasschnelli> Hmm.. I once extended ctaes to do cbc (if that is of interest)
< sipa> hah
< sipa> there are at least 3 people who have already done that it seems
< sipa> and nobody upstreamed it!
< cfields> heh
< cfields> sipa: i didn't like the api i came up with, planned to revisit before upstreaming
< jonasschnelli> I wanted to upstream.
< wumpus> haha!
< sipa> i found the httprpc thing
< sipa> it's the out[KEY_SIZE] in multiuserauthorized
< gmaxwell> damn I type too slow.
< wumpus> KEY_SIZE is not a constant?
< sipa> marking it const fixes it
< wumpus> damn, good catch
< gmaxwell> unsigned int KEY_SIZE = 32;
< gmaxwell> unsigned char out[KEY_SIZE];
< wumpus> next time you see that warning please raise an alarm immediately
< gmaxwell> I wish the compiler had flags to disable language features.
< gmaxwell> I'll open an issue, I did mention it on IRC.
< gmaxwell> (if it happens again!)
< cfields> gmaxwell: -Wvla
< gmaxwell> oh, lol.
< cfields> i think that should catch it?
< cfields> specifically, -Werror=vla
< bitcoin-git> [bitcoin] sipa opened pull request #9785: Make KEY_SIZE a compile-time constant (master...constkeysize) https://github.com/bitcoin/bitcoin/pull/9785
< wumpus> cfields: let's do that
< wumpus> I'm not usually for disabling language features, but I can see no good coming out of this one
< cfields> wumpus: sounds good. There was another case like that a while back wrt hashing, I guess that was fixed at one point
< gmaxwell> that one seems safe but we should be very cautious about werror... compilers change warning detection all the time and then crap won't compile for users.
< cfields> sipa / gmaxwell: can you comment on whether -Werror=vla blows up on the old code?
< sipa> cfields: let's check
< wumpus> especially if it silently makes functions vulnerable by disabling the stack cookie
< wumpus> gmaxwell: agreed, Werror certainly shouldn't be enabled generally
< cfields> gmaxwell: Werror= allows you to only error on specific warnings
< gmaxwell> VLAs aren't so bad... they have good uses, but I agree we shouldn't have them in our codebase.
< gmaxwell> cfields: yes but many warnings change their behavior. As I said, vla sounds safe.
< gmaxwell> but many other warnings change their specific triggers from version to version.
< wumpus> this one is specific enough
< sipa> $ ./configure --with-incompatible-bdb --without-gui CXXFLAGS="-Wall -Wpedantic -Werror=vla -g3 -O2"
< sipa> ok, i do not want -Wpedantic
< gmaxwell> httprpc.cpp: In function ‘bool multiUserAuthorized(std::__cxx11::string)’:
< gmaxwell> httprpc.cpp:116:39: error: variable length array ‘out’ is used [-Werror=vla]
< gmaxwell> unsigned char out[KEY_SIZE];
< gmaxwell> ^
< cfields> I remember this one getting snagged as a vla at one point: https://github.com/bitcoin/bitcoin/blob/master/src/hash.h#L30
< cfields> i think that may be up to the compiler.
< gmaxwell> qt/test/paymentservertests.cpp: In member function ‘void PaymentServerTests::paymentServerTests()’:
< gmaxwell> qt/test/paymentservertests.cpp:181:61: error: variable length array ‘randData’ is used [-Werror=vla]
< cfields> er sorry, 2 lines up
< gmaxwell> unsigned char randData[BIP70_MAX_PAYMENTREQUEST_SIZE + 1];
< gmaxwell> ^
< gmaxwell> with those two things fixed it compiles cleanly with that Werror=vla.
< wumpus> would be good to include the paymentrequest change in https://github.com/bitcoin/bitcoin/pull/9785 too
< cfields> yes, clang still dislikes the one in hash.h
< wumpus> hm, a static field that is addressed as a non-static field
< wumpus> if you make that CSHA256::OUTPUT_SIZE I'm fairly sure the warning goes away?
< cfields> wumpus: yep
< sipa> what if you make it just OUTPUT_SIZE ?
< cfields> sipa: works for one, breaks for ripemd
< cfields> pr coming up
< sipa> already on it
< cfields> race!
< wumpus> if you make it just OUTPUT_SIZE the meaning changes
< sipa> indeed
< wumpus> though if the numbers are the same anyway it doesn't matter
< sipa> it needs to be CSHA256::OUTPUT_SIZE
< cfields> no?
< sipa> my battery just died
< btcdrak> RIP
< sipa> the PR also has the paymentprotocol change, but I didn't tedt
< sipa> *test
< cfields> 0.14: destroyer of PSUs and batteries
< sipa> s/died/ran out/
< achow101> When did 0.14 destroy a PSU?
< bitcoin-git> [bitcoin] theuni opened pull request #9786: boost: remove iostreams includes (master...no-iostreams) https://github.com/bitcoin/bitcoin/pull/9786
< wumpus> achow101: mine, earlier today
< wumpus> while building w/ gitian, not while running it, mind you
< cfields> ^^ should get rid of the "NOTE: Use of this header (bool_trait_def.hpp) is deprecated")"
< achow101> wumpus: lol
< achow101> is the tag still happening today?
< cfields> wumpus: would you like release notes additions PR'd directly to 0.14, i assume?
< wumpus> achow101: yes, in a minute
< luke-jr> "Out-of-sync Modal Info Layer" looks like something that can be removed from release notes to trim it down
< wumpus> cfields: yes, editing the wiki has little sense now, we should probaly add a warning there
< cfields> ok
< luke-jr> " - After resetting the options by clicking the `Reset Options` button in the options dialog or with the `-resetguioptions` startup option, the user will be prompted to choose the data directory again. This is to ensure that custom data directories will be kept after the option reset which clears the custom data directory set via the choose datadir dialog."
< luke-jr> ^ where did this change happen? I don't see any code for this behaviour
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/618709141147f74771da0795cf0dccb47c606d24
< bitcoin-git> bitcoin/0.14 6187091 Wladimir J. van der Laan: doc: Add changelog for 0.14.0 to release notes
< wumpus> going to pull in the warning changes and then tag
< bitcoin-git> [bitcoin] theuni opened pull request #9787: [WIP] release: add a few performance-related notes (0.14...update-release-notes) https://github.com/bitcoin/bitcoin/pull/9787
< cfields> ^^ just intended to be a starting point
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/618709141147...04396bcc058e
< bitcoin-git> bitcoin/0.14 1577f07 Gregory Maxwell: Restore removed release notes.
< bitcoin-git> bitcoin/0.14 04396bc Wladimir J. van der Laan: Merge #9784: Restore removed release notes....
< cfields> sipa: are you PRing the hash changes? Or did those die with your battery?
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f87e8f53920a...df42bcdbfebe
< bitcoin-git> bitcoin/master 914fad1 Pieter Wuille: Make KEY_SIZE a compile-time constant
< bitcoin-git> bitcoin/master c801c82 Pieter Wuille: Move BIP70_MAX_PAYMENTREQUEST_SIZE to header
< bitcoin-git> bitcoin/master df42bcd Wladimir J. van der Laan: Merge #9785: Avoid variable length arrays...
< bitcoin-git> [bitcoin] laanwj closed pull request #9785: Avoid variable length arrays (master...constkeysize) https://github.com/bitcoin/bitcoin/pull/9785
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/df42bcdbfebe...12f46fa7d87d
< bitcoin-git> bitcoin/master 3301587 Cory Fields: boost: remove iostreams includes...
< bitcoin-git> bitcoin/master 12f46fa Wladimir J. van der Laan: Merge #9786: boost: remove iostreams includes...
< bitcoin-git> [bitcoin] laanwj closed pull request #9786: boost: remove iostreams includes (master...no-iostreams) https://github.com/bitcoin/bitcoin/pull/9786
< sipa> cfields: oops, right, will do
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/04396bcc058e...2afefeade6e6
< bitcoin-git> bitcoin/0.14 f873564 Pieter Wuille: Make KEY_SIZE a compile-time constant...
< bitcoin-git> bitcoin/0.14 973e345 Pieter Wuille: Move BIP70_MAX_PAYMENTREQUEST_SIZE to header...
< bitcoin-git> bitcoin/0.14 2afefea Cory Fields: boost: remove iostreams includes...
< wumpus> luke-jr: was that message added at the same time as the change, or later?
< wumpus> luke-jr: seems to be #8487
< gribble> https://github.com/bitcoin/bitcoin/issues/8487 | Persist the datadir after option reset by achow101 · Pull Request #8487 · bitcoin/bitcoin · GitHub
< luke-jr> but that's the opposite?
< wumpus> I'm not aware of any other changes there (and log -p confirms this)
< luke-jr> oh, does it preserve *and* reprompt? :o
< wumpus> anyhow, time to tag
< sipa> ack tag
< jonasschnelli> \O/
< wumpus> * [new tag] v0.14.0rc1 -> v0.14.0rc1
< sipa> \o/ \\o o//
< wumpus> \\o//
< cfields> woohoo!
< sipa> you have 4 arms? that explains!
< wumpus> if only :)
< gmaxwell> that symbol is a tutrle on its back.
< wumpus> gitian will probably have to rebuild all dependencies as the gitian-depends version was bumped
< gmaxwell> flip him over!
< jonasschnelli> heh
< achow101> \o/
< wumpus> cfields: we should not forget to bump the depends version to 0.15 on master as soon as possible so that we don't have this problem next time
< cfields> wumpus: indeed. I'm cheating and symlinking for now.
< cfields> will PR that in just a min.
< wumpus> yeah I thought about that too, but I'm not doing that, want to be sure to get the right output
< wumpus> I'd be the person to symlink the wrong directory then get a wrong executable, spend hours debugging that, and lose a lot of time compared to... simply rebuilding everything :p
< achow101> luke-jr: it preserves and reprompts the datadir
< jonasschnelli> Can you just gpg sign the gitian assets file on a different machine? No need for the descriptor, right?
< wumpus> jonasschnelli: yes, see "signing externally" in gitian-building.md
< jonasschnelli> wumpus: Thanks... great.. wasn't aware of that doc part
< instagibbs> nice work :)
< wumpus> you can also pass -p true to gsign to make it skip the call to gpg complately
< wumpus> but it doesn't matter whether you do that or let the gpg call fail, it's the last statement in gsign, in both cases you can copy the unsigned assert file and detach-sign it yourself
< bitcoin-git> [bitcoin] theuni opened pull request #9788: gitian: bump descriptors for master (master...gitian-bump-0.15) https://github.com/bitcoin/bitcoin/pull/9788
< * gmaxwell> sets the timer for the premature reddit release announcement. :P
< wumpus> reddit, what's that :)
< instagibbs> having issues with configure on rc1:
< instagibbs> x86_64-pc-linux-gnu
< instagibbs> checking build system type... x86_64-pc-linux-gnu
< instagibbs> checking host system type... x86_64-pc-linux-gnu
< instagibbs> ./configure: line 2455: syntax error near unexpected token `no-define'
< instagibbs> ./configure: line 2455: `AM_INIT_AUTOMAKE(no-define subdir-objects foreign)'
< wumpus> instagibbs: see #bitcoin
< achow101> works fine for me
< instagibbs> wumpus, not unless it recently was removed, it's on a dev machine :P
< wumpus> no need to cross-post
< instagibbs> eh, I tried asking, got nothing, then came here
< instagibbs> sorry
< bitcoin-git> [bitcoin] theuni opened pull request #9789: build: disallow variable length arrays (master...no-vla) https://github.com/bitcoin/bitcoin/pull/9789
< cfields> gmaxwell: i wonder if that vla was throwing off your sanitizer. didn't you have something reported from rpc code?
< sipa> i'm running master as of a few hours ago, plus my sanitize fixes, on bitcoin.sipa.be, with tsan and ubsan enabled
< cfields> sipa: ah, nice
< gmaxwell> cfields: I don't know why it would.
< bitcoin-git> [bitcoin] luke-jr opened pull request #9790: doc/release-notes: Various cleanups (0.14...0.14-relnotes) https://github.com/bitcoin/bitcoin/pull/9790
< achow101> first!
< bitcoin-git> [bitcoin] sipa opened pull request #9791: Avoid VLA in hash.h (master...novla) https://github.com/bitcoin/bitcoin/pull/9791
< gmaxwell> the CLANG vs GCC VLA warning on hash.h is an example of why we should -Wvla but not error on it.
< sipa> gmaxwell: from investigating briefly, it seems that VLAs are standard in C99 but optional in C11. They're not specified in C++ or C++11.
< gmaxwell> Apparently their analog is in C++14, std::dynarray and "runtime sized arrays" (exactly the same syntax as VLA but: sizeof works, and they can't be multidimensional)
< luke-jr> eh? sizeof works with C99 VLAs..
< luke-jr> or is that a GNU extension?
< gmaxwell> luke-jr: sorry, I wasn't clear, I was saying that it does not work in the C++14 spec.
< luke-jr> oh
< * luke-jr> wonders if we should remove "About Qt" from the menu. It seems (without knowing the languages) translators are interpreting "Qt" as "Bitcoin-Qt"
< sipa> luke-jr: i've noticed that too
< sipa> in past times, it seems "Qt" was even understood to refer to the bitcoin core program name
< gmaxwell> it's kind of confusing in any case. like... "information no one ever wants"
< luke-jr> other Qt apps used to have it, but I don't think many (if any) do anymore
< luke-jr> in KDE apps, it's just "About <app>" and "About KDE"
< achow101> I thought it was required as part of the license that Qt uses
< achow101> (that might be wrong info)
< gmaxwell> nope.