< tryphe> sipa, i'm pretty sure windows marks applications as "hung" after a certain number of seconds if the window handle stops responding to an optimistic message, and closes any applications that are "hung"
< tryphe> (first paragraph)
< tryphe> there's a registry value called HungAppTimeout that you can change to modify the timeout, though. not sure if that's useful though.
< tryphe> seems like the right thing to do would be to figure out why it doesn't respond to that message, but it might be a bit hairy trying to debug that
< sipa> tryphe: yes, but that doesn't sound like what's going on here
< tryphe> could be, but i have some machines where that behavior happens to other applications, not just bitcoin (i don't run bitcoin on windows though so can't say)
< promag> MarcoFalke: please see #20017
< gribble> https://github.com/bitcoin/bitcoin/issues/20017 | rpc: Add RPCContext by promag · Pull Request #20017 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] kallewoof closed pull request #20045: upstream: add and use defaulted getters to UniValue (master...202009-defaulted-get) https://github.com/bitcoin/bitcoin/pull/20045
< bitcoin-git> [bitcoin] fanquake closed pull request #19785: build: lrelease requires xml if not cross-building (master...200823-xml) https://github.com/bitcoin/bitcoin/pull/19785
< bitcoin-git> [bitcoin] MarcoFalke pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/3487e421a7fe...40aab35e9828
< bitcoin-git> bitcoin/master e455713 John Newbery: [tests] Move bech32 unit tests to test framework
< bitcoin-git> bitcoin/master 011e784 John Newbery: [tests] Rename segwit encode and decode functions
< bitcoin-git> bitcoin/master 7f639df John Newbery: [tests] Remove unused optional verify_checksum parameter
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19253: Tests: tidy up address.py and segwit_addr.py (master...2020-06-addr-unit-tests) https://github.com/bitcoin/bitcoin/pull/19253
< vasild> jonatack: https://github.com/bitcoin/bitcoin/pull/19954#pullrequestreview-499530501 "Should we test for both msg_addr and msg_addrv2?"
< vasild> Right! Good question :)
< vasild> I was thinking that it is possible to change the py testing framework to always announce support for addrv2 which would flip all tests to use addrv2 but then addr will be untested... hmm
< wumpus> tryphe: oh no, if so it's just a new symptom of the old 'we hang the UI event loop on everything' problem
< wumpus> in any case I don't remember the windows shutdown detection code changing recently
< wumpus> but it would be good if anyone that runs windows could check this
< jonatack> vasild: indeed, i wondered how much extra effort it would be to test both and started doing it, then stopped before the rabbit hole "nah...i'll ask the question" ;)
< vasild> git grep msg_addr ./test/functional/
< wumpus> not seeing anything that could break the shutdown monitor in the git log for winshutdownmonitor.cpp, the last change of any significance was removing OpenSSL seeding in 2019, which jus removes an if() statement, before that it effectively wasn't teouched since the file was first introduced
< fanquake> wumpus: I did try this morning and from what I remember I didn't see a shutdown window
< fanquake> Will test again
< vasild> jonatack: p2p_addr_relay.py is the only test that uses msg_addr!?
< wumpus> fanquake: okay, worrying then :/
< jonatack> vasild: seems so
< vasild> jonatack: I assumed there were many others that would keep testing msg_addr when p2p_addr_relay.py is converted to use msg_addrv2, but if that test is the only one testing msg_addr, then we better not stop it
< jonatack> yes, initially it didn't seem to be too much extra effort to test both
< wumpus> the only thing I can think of, besides Windows deprecating this way of detecting shutdown, is that it might be one of the Qt updates breaking how native event filters work?
< wumpus> I honestly don't know though I'd expect much more complaints if this really doesn't work anymore
< jnewbery> #proposedmeetingtopic merging PR 19953 (taproot)
< vasild> MarcoFalke: why those builds on 18750? https://github.com/bitcoin/bitcoin/pull/18750#event-3822788532
< vasild> to test that compilation works on more platforms than CI?
< vasild> btw, guix_build.log for master is 35M while for master+PR 3.4MB
< fanquake> wumpus: I tried again, and didn't see a shutdown dialog, but that's also might be because Windows threw up another shutting down overlay, which might have hid it.
< wumpus> fanquake: maybe a test like would be useful: add a sleep during shutdown to make sure it's slow, then shut down windows, afterwards check the log if it got to the end or was interrupted
< wumpus> also maybe check for the message (if we log any) that the shutdown request came in
< wumpus> after all, the issue here would be not so much not seeing the shutdown window but that it shuts down unclean
< fanquake> wumpus: I'll take a look at it tonight
< wumpus> thanks!
< wumpus> (looking at the code: no we don't log any specific message if WM_QUERYENDSESSION comes in, nor on registering the shutdown handler itself, though it does log if it fails for some erason)
< wumpus> it might make sense to add those things to make troubleshooting easier
< kallewoof> i get a bunch of errors about inline asm when i try -fsanitize=address on a mac. is that normal?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/40aab35e9828...9fc2f011ba17
< bitcoin-git> bitcoin/master 6fccad7 Jon Atack: signet: do not log signet startup messages for other chains
< bitcoin-git> bitcoin/master 9fc2f01 MarcoFalke: Merge #20048: chainparams: do not log signet startup messages for other ch...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20048: chainparams: do not log signet startup messages for other chains (master...signet-startup-logging-bugfix) https://github.com/bitcoin/bitcoin/pull/20048
< MarcoFalke> vasild: The builds are just to confirm our guix/gitian build doesn't break. I ask DrahtBot to do those on "risky" build system changes
< vasild> MarcoFalke: ok, did it break? (it is not obvious to me from the logs, but I think not)
< MarcoFalke> no, it didn't break ;)
< vasild> do you think that it makes sense to do one test run with the new option enabled? because by default it is disabled which means no change in behavior
< aj> sipa: hmm. every single binary in src/test/fuzz is ~185MB for me (following the instructions in doc/fuzzzing.md). 117MB stripped, by the looks. total of 18G for src/test/fuzz, 22G for src
< wumpus> aj: that's large even for a static build
< aj> wumpus: hmm, bitcoind is 83M unstripped, 16M stripped for me
< aj> ./configure CC=clang CXX=clang++ --with-incompatible-bdb --enable-zmq --enable-debug --enable-werror --enable-fuzz --with-sanitizers=address,fuzzer,undefined
< wumpus> aj: for comparision, stripped x86_64 bitcoind 0.20.1 from the release is 10M
< wumpus> bitcoin-qt is 31MB, for reference, that includes a large part of whopping qt statically
< wumpus> I'm not sure what's happening in your case but it's fairly weird
< aj> wumpus: bitcoind with same options but not zmq or fuzz or sanitizers is 8MB stripped for me
< aj> (134M unstripped)
< wumpus> ohh, yes it's not unreasonable that the sanitizers that add extra code size
< aj> wumpus: debian testing, clang 9 apparently
< wumpus> zmq or not should hardly make a difference
< aj> yeah, just happened to have the non-zmq binary and config options handy
< aj> maybe fuzzing.md shouldn't recommend with-sanitizers in its quickstart section then?
< wumpus> I suppose it does make the fuzzing more effective, which might be considered worth the extra harddisk usage
< aj> oh well, i guess now i've got more disk space free it doesn't matter to me?
< vasild> \o/
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20054: Remove confusing and useless "unexpected version" warning (master...2010-valRemVerWarn) https://github.com/bitcoin/bitcoin/pull/20054
< nthumann> Hey there! I´m looking for some feedback/tests of my PR #18309, so feel free to leave a comment, if you have some spare time :)
< gribble> https://github.com/bitcoin/bitcoin/issues/18309 | zmq: Add support to listen on multiple interfaces by n-thumann · Pull Request #18309 · bitcoin/bitcoin · GitHub
< luke-jr> nthumann: looks simple and good to me
< nthumann> luke-jr thanks :)
< bitcoin-git> [bitcoin] laanwj opened pull request #20055: rpc: Set HTTP Content-Type in bitcoin-cli (master...2020_10_cli_contenttype) https://github.com/bitcoin/bitcoin/pull/20055
< wumpus> nthumann: looks good to me and has a test
< wumpus> I also see no reason why this would *not* be allowed
< instagibbs> nthumann, bugging on IRC works! ;P
< instagibbs> RFM imo
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/9fc2f011ba17...a0185d90a7f2
< bitcoin-git> bitcoin/master 347c94f Nicolas Thumann: zmq: Add support to listen on multiple interfaces
< bitcoin-git> bitcoin/master b1c3f18 nthumann: doc: Adjust ZMQ usage to support multiple interfaces
< bitcoin-git> bitcoin/master a0b2e5c nthumann: doc: Add release notes to support multiple interfaces
< luke-jr> lol
< instagibbs> I forgot how simple it was, would have re-acked earlier
< bitcoin-git> [bitcoin] laanwj merged pull request #18309: zmq: Add support to listen on multiple interfaces (master...zmq-listen-multiple-interfaces) https://github.com/bitcoin/bitcoin/pull/18309
< instagibbs> I was harassing nthumann on email to re-review my zmq PR :P
< wumpus> yes, bugging on IRC works
< luke-jr> for simple stuff anyway
< nthumann> instagibbs don´t worry about it :D
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20056: net: Use Span in ReceiveMsgBytes (master...2010-netSpan) https://github.com/bitcoin/bitcoin/pull/20056
< wumpus> luke-jr: or in any case, almost-ready PRs
< achow101> is the arm travis failure a thing now or am I doing somethign wrong?
< wumpus> oh no... what now?
< wumpus> the same one that jnewbery reported yesterday?
< achow101> yes
< achow101> showing up on most (all?) of my PRs
< wumpus> okay
< wumpus> it seems to have passed on the PR I just opened
< achow101> it passed on one of the prs I updated yesterday, but not the others
< achow101> it seems to just be timing out. the log isn't terribly helpful, just a bunch of dots
< wumpus> yes the error is terribly unhelpful, it seems like simply a timeout
< wumpus> same as for previous reported ones, "Ran for 1 hr 4 min 38 sec" looks like there's a cutoff point there
< wumpus> restarted it
< achow101> usually travis says something about timing out when it times out
< achow101> if there's a cutoff, it's not consistent. https://travis-ci.org/github/bitcoin/bitcoin/jobs/731742236 ran for 1 hr 17 min and passed
< sipa> there is a cutoff at 10 minutes of non-activity, but that's what the dots prevent
< achow101> and usually there's a message saying it timed out
< wumpus> right, there's no message at all of any exit status, it just stops
< wumpus> I have not seen any problems on ARM locally so I'm fairly sure this is a travis problem
< achow101> travis and random unexplainable issues, name a more iconic duo
< wumpus> heh
< sipa> haha
< aj> luke-jr: ping re bips PRs 978 and 1000
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Oct 1 19:00:21 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< promag> meeting?
< jnewbery> hi
< promag> oh, hi
< hebasto> hi
< amiti> hi
< aj> hi
< achow101> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
< wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
< ariard> hi
< provoostenator> hi
< meshcollider> hi
< dongcarl> hi
< sipa> hi
< luke-jr> hi
< jonatack> kon'nichiwa
< wumpus> one proposed topic for today: merging PR 19953 (taproot) (jnewbery)
< wumpus> any last minute suggestions?
< kanzure> hi
< wumpus> jonatack: こんにちは
< wumpus> #topic High priority for review
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 12 blockers, 1 bugfix, 2 chasing concept ACK
< promag> please remove mine from hp, it doesn't help getting more reviews
< wumpus> ok
< wumpus> yes, anything concerning libevent initialization/shutdown is notoriously hard to review
< promag> basically it will wait for you ^^
< wumpus> well the PR seemed really tricky to me... I think what we need is a clear test, and then to test with different versions of libevent
< wumpus> I can't judge just from the code change wether it's better or not
< promag> ok, then I guess I need to make it clear and improve testing!
< wumpus> it's kind of awkward we've had a history of PRs like that, and it never really fixed the problem, we'll really want to make sure we get it right this time or it doesn't make sense to make another change there
< wumpus> thanks!
< wumpus> anything else for high prio?
< sipa> #19953 ? :)
< gribble> https://github.com/bitcoin/bitcoin/issues/19953 | Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #19953 · bitcoin/bitcoin · GitHub
< sipa> oh, it is
< wumpus> hehe
< wumpus> that's also the other topic
< wumpus> #topic Merging PR 19953 (taproot) (jnewbery)
< jnewbery> Hi!
< jnewbery> Apologies if eveyone else is already on the same page on this and I'm just not keeping up.
< jnewbery> What are people's hopes for when the Taproot PR gets merged?
< jnewbery> Feature freeze is in a couple of weeks, and it seems optimistic to get it merged before then.
< jnewbery> But if we want it included in v0.21.1, I think it makes sense to be merged very soon after the v0.21 branch, to make back-porting easier.
< jnewbery> So in my mind, it's the priority as soon as v0.21 gets branched, and before any big refactors (eg switching things to C++17) go in.
< jnewbery> Is that what other people are thinking too?
< jnewbery> (I'm personally prioritizing #19988 ahead of it for my reviews, because I think it'd be good to get that in 0.21)
< gribble> https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub
< luke-jr> jnewbery: before the branch?
< luke-jr> after the branch is too late, isn't it?
< sipa> i was hoping before the branch, but it's obviously not up to me
< sipa> i do think the PR is essentially done
< wumpus> yep, FWIW today was the translations freeze, feature freeze is in 14 days: https://github.com/bitcoin/bitcoin/issues/18947
< aj> i thought before the branch was still plausible; also prioritising 19988, but i think it's just about there
< promag> no backport after branch off right?
< luke-jr> promag: softforks should always be backported to anything supported
< luke-jr> not necessarily until activation is set tho
< wumpus> yes, softforks are always backported
< wumpus> but it would be good to get that in before the branch-off if it's ready anyway
< jnewbery> it currently has two ACKs (instagibbs and benthecarmen). Feels like now would be the time to review if anyone was waiting for the right moment!
< ariard> sounds good to prioritize 19988, I had the same PR order
< jonatack> agree. i was thinking the same as aj and sipa WRT these two PRs, 19953 and 19988
< jonatack> (along with the tor v3 support)
< sipa> it seems silly to say "merge right after branch", if it's ready to merge at that point, it's also ready to merge before
< achow101> i'll move it to the top of my review queue
< wumpus> sipa: right, 'merge after branch' is for features that shouldn't be backported
< sipa> or for very invasive refactors perhaps
< wumpus> yes
< sipa> of course, if it isn't ready before, it isn't, and that should be that
< jnewbery> sipa: I meant "if it's not ready to merge at branch, then it should be a priority to get it reviewed/merged as soon as possible", not "don't merge it before the branch even if it's ready"
< sipa> jnewbery: right, that makes sense
< sipa> in any case, the outstanding things i have for 19953 at this point are a few review comments (which will just result in added code comments for clarification), and documenting the process of creating the JSON unit test data
< wumpus> so just documentation work
< ariard> I still want to review in-depth the test coverage, but that said 14 days is largely enough
< wumpus> which is important but doesn't hold up the code merge
< sipa> and obviously addressing any review comments that may still arise
< jnewbery> I guess maybe the message should be: feature freeze is in two weeks, think about what your priorities are. Mine are 19988 and 19953.
< sipa> i'm committed to quickly addressing comments in both of those
< sipa> my other priority is torv3
< luke-jr> IMO #11082 is important to get into 0.21, but clearly I can't do it alone :/
< gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< aj> wumpus: oh, i guess #19937 for high-pri might be nice
< gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
< wumpus> mine are, beside taproot, #19991 and #19954
< gribble> https://github.com/bitcoin/bitcoin/issues/19991 | net: Use alternative port for incoming Tor connections by hebasto · Pull Request #19991 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19954 | tor: complete the TORv3 implementation by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
< sipa> luke-jr: i haven't seen any argument as for what it adds over settings.json, so barring a wide agreement to revert that (and there doesn't seem to be), it seems hard to get people to find it important
< luke-jr> sipa: it potentially reduces us to 1 config format, whereas settings.json bumped us to 3 or 4
< wumpus> aj: added
< wumpus> sipa: I agree, that's why I haven't really looked at it either
< wumpus> I don'twant yet another config file, initialization and setting priority is complex enough as it is
< sipa> luke-jr: but settings.json is merged; you'll need a much stronger case if your goal is reverting that and merging bitcoin_rw instead
< luke-jr> wumpus: that's the point behind rwconf - it reduces
< sipa> as having both seems the worst of both worlds
< luke-jr> sipa: that's why it's important to do before 0.21
< luke-jr> once 0.21 is released, we're stuck with settings.json
< sipa> luke-jr: but your goal isn't just merging bitcoin_rw; it's replacing a feature that was already merged
< sipa> i have no opinion either way, but one is merged, and the other isn't
< wumpus> it's an internal settings file, people are not supposed to edit it manually, might be better if it's in json format instead
< wumpus> could have been some obscure binary format as well but as least this is readible if you want to...
< jnewbery> luke-jr: you failed to convince people that bitcoin_rw was the right approach in the PRs. I don't see what simply repeating your position here will achieve
< wumpus> any other topics?
< achow101> at what point do we switch to the milestone for hi prio?
< wumpus> achow101: well not yet as I've not really looked at what is at the milestone yet
< wumpus> but yes good point
< wumpus> we could do that starting from next week, after sorting things out, I think we need to postpone things like "sqlite wallet storage" to 0.22 https://github.com/bitcoin/bitcoin/milestone/45
< achow101> :(
< wumpus> as well as the guix build
< wumpus> yes, :(
< sipa> i'm sorry i haven't had the time to dive into that... i'd really like to see sqlite happen
< luke-jr> "the guix build"?
< wumpus> but that sounds scary to do last minute at least to me, seems like something that needs to brew in the master branch for a while
< * dongcarl> awakens
< wumpus> luke-jr: yes, 0.21 will be another release built with gitian it seems?
< luke-jr> wumpus: hopefully gitian won't be abandoned any time soon
< luke-jr> guix is an improvement over Ubuntu, but not over gitian
< achow101> the main thing was that I had wanted to couple sqlite with descriptor wallets just to avoid multiple upgrade scenarios
< sipa> achow101: i get that, but does that add that much? you'll still need to support legacy+bdb, legacy+sqlite, desc+sqlite anyway
< wumpus> achow101: yes, I understand … but it seems too recent to have as default yet
< luke-jr> Guix requires running third-party blobs to use (or at least, I couldn't get it running - and if I can't, how could we expect others to?)
< achow101> sipa: the idea was there wasn't a legacy+sqlite
< wumpus> luke-jr: my point was, that's a concern for 0.22 not 0.21
< luke-jr> k
< sipa> achow101: in the short term perhaps, but longer term i'd hope you can convert a legacy bdb wallet to sqlite so we could (in due time) have a reasonable build without bdb dependency
< wumpus> ^^
< sipa> while converting legacy to descriptor seems much harder/impossible
< achow101> converting legacy to descriptor seems possible
< wumpus> there needs to be a way to upgrade old wallets
< wumpus> if not, we'll be stuck with them forever
< achow101> #19602 does it
< gribble> https://github.com/bitcoin/bitcoin/issues/19602 | wallet: Migrate legacy wallets to descriptor wallets by achow101 · Pull Request #19602 · bitcoin/bitcoin · GitHub
< achow101> my plan was for the legacy -> desc upgrade is the bdb -> sqlite upgrade too
< luke-jr> we *could* disable descriptor wallets in 0.21, but I don't think anyone wants to go there..
< sipa> luke-jr: yeah, no
< wumpus> you can't really require people to transfer their funds to a new wallet to upgrade, ever
< sipa> achow101: i see, right, if you require a new backup at the same time, it does seem reasonaBLE
< wumpus> requiring a new backup is fine
< wumpus> just be clear about it
< achow101> wumpus: no funds transfer is required for the upgrade
< wumpus> achow101: good, that's the only hope we can get rid of berkeleydb at some point :)
< dongcarl> luke-jr: We can talk more about guix on #bitcoin-builds, would very much like to know the problems you ran into
< luke-jr> dongcarl: k, after the meeting
< wumpus> (which I fully support, FWIW, though we'll want to be careful to somehow have some tools somewhere that people can use to convert old bdb wallets they find)
< wumpus> it highlights how important backwards compatibility is for our wallet formats anway
< wumpus> any other topics?
< sipa> 42 is a good minute to end at
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Oct 1 19:42:43 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jonatack> :)
< jnewbery> thanks wumpus. Great meeting!
< aj> i guess 42:42 must be a doubleplus-good second to have neded at
< sipa> next time.
< aj> oh, it was right on 42:42 for me
< aj> maybe lightningbot's clock is wrong. i could edit the logs?
< sipa> did you know that the decimal sequence "424242" appears for the first time in byte position 242424 in the digits of Pi?
< achow101> I got it at 42:43. maybe your internet is just fater
< sipa> aj: irc doesn't guarantee bounded time delivery (iirc it doesn't even guarantee that messages won't be reordered, in multi-server setups)
< cfields> sipa: Huh, neat. I suppose you could probably find any fun pattern like that you want if you look long enough :)
< sipa> cfields: the actual string at that position is even 242424242 or something like that
< wumpus> jnewbery: thank you!
< promag> (sipa pretending he doesn't know all pi digits)
< aj> nope, it's my local clock that's 1s slow it seems. further updates in the news at 9
< sipa> promag: i can promise you that i cannot recite them backwards
< achow101> promag: new fact for pieterwuillefacts.com
< gloriazhao> i can recite all the unique digits of pi does that count
< wumpus> hehe
< sipa> gloriazhao: woah
< promag> btw regarding windows hang
< promag> what version is it?
< aj> gloriazhao: if you do it in the obvious order, it _is_ counting?
< sipa> promag: i don't know, and the user complaining on SE isn't volunteering much information
< promag> right, maybe he is using datadir on usb
< wumpus> we've already ruled out it happening on current versions of windows in the standard case?
< hebasto> promag: testing right now on Win10 build 19041.450, and cannot reproduce for now
< wumpus> hebasto: thanks for testing, I think it's good to have a baseline at least
< gwillen> cfields: fun fact -- it's actually an open problem whether you can find any fun pattern you like in pi if you look long enough! https://www.askamathematician.com/2009/11/since-pi-is-infinite-can-i-draw-any-random-number-sequence-and-be-certain-that-it-exists-somewhere-in-the-digits-of-pi/
< promag> he says "However, recently, whether it was a new version of Bitcoin Core or an update to Windows 10"
< promag> so looks like he updated bitcoind too
< hebasto> I'm testing v0.20.1
< sipa> gwillen: yeah, proving normality of a number is very hard
< cfields> gwillen: neat!
< promag> hebasto: vm?
< hebasto> yes
< sipa> gwillen, cfields: apparently some theorem about them was proven a certain C. P. Schnorr: https://en.wikipedia.org/wiki/Normal_number
< cfields> sipa: scared to click.. don't want to click, don't want him to sue me for using pi :p
< sipa> cfields: it's from 1972
< sipa> hebasto: based on earlier comments by (presumably) the same user under a different identity (long story), i suspect he is using 0.20.1 and not master
< cfields> whoops, some c/p there someow.
< cfields> sipa: that was a joke.
< sipa> cfields: obviously
< sipa> sorry, should have used an interrobang
< hebasto> sipa: thanks
< cfields> heh
< sipa> a c/p schnorr?
< cfields> nm
< cfields> I'm going to resist going down another number theory rabbit hole. This stuff is so freaking fun to learn about.
< gwillen> sipa: apparently my freshman college roommate was responsible for the final version of that meme: https://www.quora.com/How-do-you-find-the-positive-integer-solutions-to-frac-x-y%2Bz-%2B-frac-y-z%2Bx-%2B-frac-z-x%2By-4/answer/Alon-Amit/comment/36734352
< sipa> ha
< sipa> small world
< sipa> alon amit's explanation there is a really nice read, btw, if you like number theory rabbit holes
< sipa> hint: it's got elliptic curves
< bitcoin-git> [bitcoin] laanwj opened pull request #20058: Update transifex slug for 0.21 (master...2020_10_transifex_slug) https://github.com/bitcoin/bitcoin/pull/20058
< amiti> jnewbery, achow101, sipa, wumpus: I've also been seeing a decent amount of travis ARM64 builds just stopping w/out any exit status or explicit failure. another eg. https://travis-ci.org/github/bitcoin/bitcoin/jobs/732023438
< achow101> amiti: yeah, it seems to be travis just dying again
< amiti> 😬
< sipa> sigh
< phantomcircuit> how difficult would it be to run those unit tests on a dedicated server?
< sipa> phantomcircuit: i'm sure we would have no problems finding funds to buy/run such a server, but something has to set it up and maintain it
< phantomcircuit> sipa, yeah that's my question, what would the maintenance look like?
< achow101> we have bitcoinbuilds.org doing almost everything
< phantomcircuit> presumably there isn't anything to prevent a pull request from being some altcoin miner
< aj> newb question, but now i've got a fuzzer crash, how do i get at the data that triggered it?
< sipa> aj: it should have created a file crash-HHHHHHHH
< aj> sipa: yep
< sipa> that contains the raw data fed to the fuzzer
< phantomcircuit> did someone fix the fuzzer stuff to be different binaries?
< sipa> phantomcircuit: yes, every fuzzer is one binary
< aj> sipa: right, but that got run through ConsumeIntegral and ConsumeDeserializable and stuff?
< sipa> aj: you can add debug statements to the fuzzer code, and then rerun it with ./fuzzer crash-HHHH
< sipa> if you need to see the "unpacked" values from it
< bitcoin-git> [bitcoin] laanwj closed pull request #20055: rpc: Set HTTP Content-Type in bitcoin-cli (master...2020_10_cli_contenttype) https://github.com/bitcoin/bitcoin/pull/20055