< gmaxwell>
promag: right, but we shouldn't introduce a user exposed crasher over a spurrious test failure...
< gmaxwell>
in any case, I'm not married to the idea of reverting it, but that should be our _default_ response to serious bugs found in an RC esp when there isn't a really straight forward and clear fix.
< fanquake>
dongcarl Looks like it's not permissions, but related to the fact that inside depends/x86_64-pc-linux-gnu/lib, libexpat.so & libfreetype.so are symlinks
< fanquake>
libexpat.so: symbolic link to libexpat.so.1.6.8
< fanquake>
libexpat.so.1.6.8: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, not stripped
< dongcarl>
fanquake: Okay thanks, I’ll take a look on when back behind keyboard. Your setup is documented in the link you sent?
< provoostenator>
Today it finally happened: one of my nodes ran out of disk space. It's a "256" GB SD card holding the blocks dir.
< provoostenator>
accodring to df -h it's 234G with 222G used and 45M available (not sure how that math works...)
< provoostenator>
Interestingly although it shutdown gracefully with "Error: Error: Disk space is low!", it appears too late to enable pruning, because it gives up during block rewinding.
< wumpus>
provoostenator: IIRC the math is like that because some % is reserved for root only
< wumpus>
in any case, if you're running out of space on 256GB, that means others will probably too areound the same time or already have
< provoostenator>
That's why I mentioned it.
< provoostenator>
checkblocks=1 and checklevel=0 doesn't help. Is it safe to just manually delete an old block file? Or will pruning fail if it can't find the file it wants to delete?
< gmaxwell>
if you delete a blockfile you'll be resyncing.
< gmaxwell>
you could try to compress up some non-bitcoin stuff to save you some space... or try to force a leveldb compaction.
< provoostenator>
The sd card only contains blocks, the rest on a differnt volume wiht plenty of space
< provoostenator>
But I figured I can just move more recent .dat files, which presumably won't be checked, and then let it prune and move them back?
< provoostenator>
Or use a symlynk
< gmaxwell>
I have just made a massive update to my banlists, covering some large blocks of tarpit/spynodes that were missed before:
< wumpus>
removing /run/user/1000/gnupg/S.dirmngr apparently solved the issue, apparently this was supposed to be handled by some external process that was not running anymore
< wumpus>
<3 strace
< Guest41284>
following up from a comment on twitter ( https://twitter.com/tillneu/status/109877021273061376 ), we've been able to identify a significant (400+) number of peers on the p2p network that are currently engaging in a sybil attack.
< Guest41284>
peers of this type pretend to be running various versions of Bitcoin software, but are not. they respond with compact blocks handshakes, pings and pongs, but never respond to headers, get blocks, or inventory messages. the addr messages they push are stuffed with like-peers, and in general seem to be over represented in outgoing connections of normal nodes.
< Guest41284>
the current discovered peers are all on VPS hosts, carefully chosen to evade the logic which prevents connecting to multiple peers in the same /24. there's a sample of them here, representing GCE, AWS, DigitalOcean, and Hetzner. https://pastebin.com/raw/Q5wzqvg2
< gwillen>
hmmm, maybe we need stronger "IP diversity" heuristics than just limiting /24s?
< gwillen>
that's probably only workable in IPv4, but that will be live for awhile yet
< gwillen>
I guess with 15 different /8s represented in that list, it would be hard to catch in general
< bitcoin-git>
[bitcoin] pstratem opened pull request #15613: net: Simplify PONG handler, improve readability of the processing logic. (master...2019-03-17-net-processing-pong) https://github.com/bitcoin/bitcoin/pull/15613
< midnightmagic>
also <3 ltrace
< bitcoin-git>
[bitcoin] promag opened pull request #15614: 0.18: gui: Defer removeAndDeleteWallet when no modal widget is active (0.18...2019-03-wallet-modal-widget) https://github.com/bitcoin/bitcoin/pull/15614
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #15615: Add log output during initial header sync (master...2019/03/hdr_sync) https://github.com/bitcoin/bitcoin/pull/15615
< gmaxwell>
gwillen: our hurestic is /16s not /24s and there are companies that sell you ips on diverse /8s in order to attack bittorrent.