< gmaxwell> Anyone see a issue with adding all the IPs that have been performing the electrum coin theft attakcks to my node blacklist?
< midnightmagic> gmaxwell: I think that's a splendid idea.
< midnightmagic> gmaxwell: May I request some explanatory text in a comment section maybe so the groups are identifiable if you choose to head there
< fanquake> 3 signed sigs up for rc2 so far.
< warren> I apologize for not participating in gitian for a while. debootstrap has not worked on Fedora for a few years now. I'm hoping people can help https://github.com/bitcoin/bitcoin/pull/15277 so we have a deterministic buildsystem to replace gitian.
< fanquake> warren I'm writing up notes for that/using guix on macOS. Have also been working on an alpine/guix docker setup for those builds.
< sipa> nice
< warren> fanquake: awesome!
< warren> fanquake: you mean you got the osx cross-compile from linux working?
< fanquake> warren no, just getting setup to build. I started building (in an alpine container) using carls scripts, but didn't get finished, so will probably retry today.
< fanquake> I haven't read the latest out of the PR yet, so probably need to catch up on anything newish.
< fanquake> If someone could sanity check https://github.com/fanquake/core-review/blob/master/update-assumevalid.md that'd be handy.
< bitcoin-git> [bitcoin] hebasto opened pull request #15609: scripts and tools: Set 'distro' explicitly (master...20190314-set-distro) https://github.com/bitcoin/bitcoin/pull/15609
< hebasto> @wumpus: Hi! Regarding #15541. When you faced LXC disk size issues the cache was enabled or disabled?
< gribble> https://github.com/bitcoin/bitcoin/issues/15541 | Reproducibility issue with 0.18.0rc1 · Issue #15541 · bitcoin/bitcoin · GitHub
< provoostenator> The MVSC (debug) build bitcoind.exe has a weird habit of occasionally pausing. E.g. in the middle of IBD I have to hit space and then it continues.
< provoostenator> Maybe it's a PowerShell issue? I don't really feel like going down that rabbit hole though...
< wumpus> hebasto: I didn't change anything with regard to cache settings from the default
< wumpus> provoostenator: I vaguely remember this, no idea why though
< wumpus> I guess as MSVC has a pretty good debugger it should be possible to find out where it's hanging by breaking when it happens
< fanquake> evening wumpus
< wumpus> hello fanquake
< fanquake> If you're doing any merging, #15609 and #15604 could go in. Probably don't really have to get the gitian build on the first pr.
< gribble> https://github.com/bitcoin/bitcoin/issues/15609 | scripts and tools: Set distro explicitly by hebasto · Pull Request #15609 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15604 | [docs] release note for disabling reject messages by default by jnewbery · Pull Request #15604 · bitcoin/bitcoin · GitHub
< fanquake> given that we should have always been getting set to "ubuntu" anyways.
< wumpus> yes
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/118a5c8d94de...cede01b41668
< bitcoin-git> bitcoin/master b8705a0 Hennadii Stepanov: Set 'distro' explicitly
< bitcoin-git> bitcoin/master cede01b Wladimir J. van der Laan: Merge #15609: scripts and tools: Set 'distro' explicitly
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cede01b41668...165ea14efeda
< bitcoin-git> bitcoin/master 92f3e80 John Newbery: [docs] release note for disabling reject messages by default
< bitcoin-git> bitcoin/master 165ea14 Wladimir J. van der Laan: Merge #15604: [docs] release note for disabling reject messages by default...
< fanquake> There is such a long lag between the bot reporting a PR merged and GH's UI actually updating to the merged state..
< bitcoin-git> [bitcoin] laanwj merged pull request #15604: [docs] release note for disabling reject messages by default (master...release_notes_bip61) https://github.com/bitcoin/bitcoin/pull/15604
< bitcoin-git> [bitcoin] laanwj merged pull request #15609: scripts and tools: Set 'distro' explicitly (master...20190314-set-distro) https://github.com/bitcoin/bitcoin/pull/15609
< Sentineo> gitian build PR created, hope it is ok. I found several stuff that I was not sure what to do, so I had to guess :P
< fanquake> Sentineo the sigs look ok. What issues did you run into?
< Sentineo> I used docker as someone suggested, but had no idea how to use it. so first had to consult help of the gitian build script. Then I had trouble cloning the gitian.sigs repo (as I have no ssh key uploaded to github, that might have been the issue, but cloned it from the github page). Then the signing part of the docs was confusing. As some parts were not defined at all (e.g. $VERSION) and some
< Sentineo> were static and had to remove them. But not big issue, but I guess the goal is to make it perhaps very user friendly to run, so I can create a PR for a more detailed steps, e.g. for docker.
< Sentineo> the question is who is the target. If a developer, then the docs are fine, if a more novice user it makes a lot of assumptions about prior knowledge.
< fanquake> Sentineo if you have suggestions on how to make the documentation more user friendly, PRs are definitely welcome
< fanquake> There is a base level of knowledge assumed, i.e cloning repositories.
< fanquake> If there inconsistencies with usage of $VERSION that should be fixed up.
< fanquake> carldong warren Some initial Alpine / Guix Docker instructions up here https://github.com/fanquake/core-review/blob/master/guix/guix.md
< fanquake> Seems to setup ok. depends currently fails building fontconfig. Looks like maybe a permissions issue not solved by --no-same-owner ? Need to investigate some more.
< fanquake> I put more info into 15277 anyways.
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/165ea14efeda...2f501fb5c68d
< bitcoin-git> bitcoin/master c7ea8d3 practicalswift: Add sizeof(size_t) assumptions
< bitcoin-git> bitcoin/master c7a7250 practicalswift: Document assumptions about C++ compiler
< bitcoin-git> bitcoin/master 2f501fb Wladimir J. van der Laan: Merge #15522: Document sizeof(size_t) assumptions and compiler assumptions...
< bitcoin-git> [bitcoin] laanwj merged pull request #15522: Document sizeof(size_t) assumptions and compiler assumptions in assumptions.h (master...size_t-assumptions) https://github.com/bitcoin/bitcoin/pull/15522
< provoostenator> Fwiw I succesfully used fanquake's Gitian Docker instructions on my Mac. Ideally those instructions would be added to the gitian-builder script.
< provoostenator> If that script also handles the signing and pushing signatures to Github, then it might be able to catch configuration mistakes like not having an SSH setup or missing dependencies. Generally those checks are added as people run into problems themselves :-)
< dongcarl> fanquake: I think tar is trying to set the mtime of the extracted file, but doesn’t have permission? I’m afk but there’s probably a flag to disable that
< gmaxwell> brought up a node on a new IP, within 5 minutes I has 12 inbound connections... all of them were mass connectors on my published banlists...
< gmaxwell> so are mass connectors chewing up >10% of inbound port capacity?
< provoostenator> Feedback on the (de)serialization code in #15487 would be quite useful, if anyone has time in the next couple of days.
< gribble> https://github.com/bitcoin/bitcoin/issues/15487 | [WIP] descriptor based wallet serialization and import by Sjors · Pull Request #15487 · bitcoin/bitcoin · GitHub
< * provoostenator> goes off to unfry brain...
< sipa> lol
< gmaxwell> Googling shows one or two other pages also saying "bitcoin bark" but it doesn't appear to be an altcoin.
< gmaxwell> okay an estonian word for "bark" is "koor" (and presumably other languages have a similar mapping)
< gmaxwell> thats kinda confusing since bark and core have sort of opposite meanings (like tree bark vs tree core)
< gmaxwell> (I guess finish would be a likely candidate)
< gmaxwell> (and indeed google translate says that "tree bark" is "puun kuori" in finnish)
< luke-jr> I know of Karna, but not bark :P
< promag> any reason to not tag #15313 0.18?
< gribble> https://github.com/bitcoin/bitcoin/issues/15313 | Qt: avoid AskPassphraseDialog synchronous QDialog.exec() calls by jonasschnelli · Pull Request #15313 · bitcoin/bitcoin · GitHub
< gmaxwell> it's incomplete. :(
< gmaxwell> 0.18 tagging will force another RC and add weeks to the release, but won't fix the other cases where the same bug exists.
< promag> fixes the reported bug
< promag> but yeah, no need to delay 0.18
< gmaxwell> read the rest of the bug, it points out that a bunch of other versions of the same thing exists
< gmaxwell> I think for 0.18 it might be better to revert #14941 which I believe introduced the crash.
< gribble> https://github.com/bitcoin/bitcoin/issues/14941 | rpc: Make unloadwallet wait for complete wallet unload by promag · Pull Request #14941 · bitcoin/bitcoin · GitHub
< gmaxwell> Shipping with a known easily triggerable crash isn't ideal (in partiular because the crash can corrupt your blockchain state e.g. if you do it during IBD)
< gmaxwell> or alternatively disable wallet unloading with the gui up in 0.18.0.
< promag> QDialog blocking calls are not recommended
< promag> you can always console->unloadwallet
< gmaxwell> Sure. I'm not saying that that sort of thing is a good long term fix.
< promag> for RPC clients 14941 is more important IMO
< gmaxwell> But in general when we find new functionality causes crashes shortly before a release we should probably favor reverting-- or applying blunt workaround like disabling a non-criticial feature-- rather than making more changes which could introduce their own bugs.
< promag> true, jonas fix "looks harmless" but indeed it's too late for that
< promag> I'm afraid reverting that one can open other problems
< promag> btw, I meant to ask this before, but is a "-experimental=foo" option reasonable?
< gmaxwell> the idea behind a reverting preference is that /generally/ whatever problems existed with the old behavior aren't that fatal-- since we have thousands and thousands of users running with them already. this is obviously not always the case, e.g. for changes that have been in the codebase for 7 months which interact with other features...
< gmaxwell> promag: maybe? depends on the thing. We've pretty commonly added new functionality and defaulted it to disabled, then enabled it in a later release, and even in some cases later removed the configuration setting.. which is functionally equivilent. 'Nesting options' is probably not ideal.
< promag> or just -experimental, where a bunch of "experimental" stuff is enabled
< luke-jr> promag: IMO it sounds like you're thinking of "just merge it into Knots for now" ;)
< gmaxwell> I'd rather see -experimental-foo=1 than -experimental=foo. also, I don't think we should be shipping a "bunch" of expiremental stuff generally.
< promag> luke-jr: is that officially supported here?
< gmaxwell> usage by users of optional features is very low from what I've seen, and they carry risk. I think the reason we end up with stuff default off in an initial release is often when functionality was intended to get turned on but didn't quite reach enough maturity (or even when it turned out to have shortcomings at the last minute)
< gmaxwell> or when it has interop impact and we want people to test with it before defaulting it on...
< luke-jr> promag: each person can decide what they will support as usual; complicating Core with a -experimental mode wouldn't reasonably increase support though
< luke-jr> (as for "here": this isn't a support channel in the first place)
< bitcoin-git> [bitcoin] droark opened pull request #15611: Add Gitian key for droark (master...master-keys-update) https://github.com/bitcoin/bitcoin/pull/15611
< promag> gmaxwell: reverting 14941 requires rc3?
< promag> gmaxwell: btw, 14941 fixes #14917
< gribble> https://github.com/bitcoin/bitcoin/issues/14917 | wallet_multiwallet --usecli fails with "Duplicate -wallet filename specified" · Issue #14917 · bitcoin/bitcoin · GitHub