< 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.
< 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.
< 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>
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.
< 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.
< 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)