< GitHub16>
[bitcoin] sdaftuar opened pull request #8854: [qa] Fix race condition in p2p-compactblocks test (master...fix-p2p-sync) https://github.com/bitcoin/bitcoin/pull/8854
< GitHub93>
[bitcoin] jtimon opened pull request #8855: Use a proper factory for creating chainparams (master...0.13-chainparams-factory) https://github.com/bitcoin/bitcoin/pull/8855
< * jtimon>
^^ hopes btcdrack notes that I didn't reopened #6382
< GitHub196>
[bitcoin] jtimon opened pull request #8856: Globals: Decouple GetConfigFile and ReadConfigFile from global mapArgs (master...0.13-globals-utils-configfile) https://github.com/bitcoin/bitcoin/pull/8856
< GitHub39>
[bitcoin] MarcoFalke closed pull request #8854: [qa] Fix race condition in p2p-compactblocks test (master...fix-p2p-sync) https://github.com/bitcoin/bitcoin/pull/8854
< GitHub47>
[bitcoin] MarcoFalke opened pull request #8857: [qa] mininode: Fix order of positional args in wait_until (master...Mf1610-qaMininodeWaitUntil) https://github.com/bitcoin/bitcoin/pull/8857
< luke-jr>
wtf, 15 minutes after starting my node back up, I have 63 connections, most bitcoinj
< luke-jr>
is this an attack or random luck?
< luke-jr>
most are 52.* IPs… :|
< luke-jr>
AWS
< luke-jr>
yet claims to be various GUI and Android clients
< gmaxwell>
yea, that those asshole again.
< gmaxwell>
they're spy nodes.
< gmaxwell>
report it to the amazon abuse contact form. (it's pretty amazing, they ask for logs and such)
< wumpus>
same here, ~50 connections from 52.* IPs
< wumpus>
all random /bitcoinj or /BitcoinJ variants
< gmaxwell>
I banned them on my nodes a while ago.
< wumpus>
and have sent no commands but pong, verack and version
< wumpus>
good idea
< gmaxwell>
doesn't really solve the problem...
< gmaxwell>
I'd at least recommend lodging a complaint with amazon before doing so.
< wumpus>
stopping listening on IPv4 would stop them for a while, EC2 still has no IPv6 support :)
< luke-jr>
lol
< luke-jr>
hmm. I started banning them, and after a few, the rest disconnected on their own :o
< wumpus>
they're still connected to me, so it's not stopped
< wumpus>
but yes I've also managed to get banned by a spy node once, after continuously probing them and sending them junk back over their connectinos
< luke-jr>
lol
< luke-jr>
hm, I cannot compile BFGMiner with my usual dev config now. too hardened for the CPU mining assembly. XD
< sipa>
luke-jr: for extra security, also disable networking support on your system
< sipa>
it great decreases attack surface
< sipa>
around 10-15% of my bandwidth (for uploaded blocks) goes to height <=288
< sipa>
twice that for up to 2016
< gmaxwell>
sipa: do you still have the -1000 quirk?
< sipa>
nope
< sipa>
but it's only 1.5 days worth of data
< luke-jr>
sipa: given unlimited time, I would probably isolate my networking to a VM, but just using Hardened Gentoo with my 64-bit switch is enough for now (I hope) ☺
< btcdrak>
luke-jr: did you go 64bit?
< luke-jr>
btcdrak: yes, although I'm being tempted to go back to revert to KDE 4
< luke-jr>
but for better or worse, I didn't really take enough notes to make it possible to revert back
< luke-jr>
uh, wow… rm a large directory on my SSD pretty much shuts down I/O for everything else :|
< luke-jr>
even dmesg and top hung
< wumpus>
so it goes when your system is swappy
< luke-jr>
I'm not even swapping right now - killed most of the Chromium tabs
< wumpus>
but yes it's curious how easy it is to monopolize I/O even on modern OSes, it's even worse on windows
< wumpus>
any user space process can just hog the entire disk
< paveljanik>
luke-jr, what IO scheduler do you use with your SSD device?
< wumpus>
though I guess among the many proc and sys settings, there are ways to tweak this
< MarcoFalke>
we need a bot to invite people to review :)
< luke-jr>
although I have a udev rule that's supposed to set SSDs to deadline, but it apparently doesn't work
< wumpus>
s/to invite/to drag people by their hair into PRs and force them to review/
< luke-jr>
hehe
< midnightmagic>
If people have a list of those 52.* IP addresses I would appreciate that.
< wumpus>
have to go now, but sure will make one later
< MarcoFalke>
luke-jr: It seems odd to place our whole bip process into the hands of a single github user. No one verified who owned this account right now. They could just do anything if they are required to ACK every change to BIP1.
< MarcoFalke>
I know BIP2 solves this, but we should use common sense to see that BIP1 mostly applies to other bips
< MarcoFalke>
and not itself
< luke-jr>
MarcoFalke: well, that'd be a concern with trusting ACKs on github in general
< btcdrak>
MarcoFalke: +1
< MarcoFalke>
Sure, but for BIP1 it seems particularly weird. (Given that the (Github)user is not active in any other bitcoin related project)
< MarcoFalke>
I am looking forward to see the BIP2 changes merged, but there may be some people not approve all changes.
< MarcoFalke>
Esp. the links in the header for further discussion
< luke-jr>
MarcoFalke: I think all the disagreement is resolved now. Since the last posting, there have been no objections.
< MarcoFalke>
You never know. :/
< MarcoFalke>
We should not forcefully keep us in this awkward situation of BIP1
< btcdrak>
luke-jr: I havent had time to review it yet.
< luke-jr>
MarcoFalke: worst case, we can drop BIP Comments and move them to BIP 3 or something
< luke-jr>
although that's one of the main improvements IMO
< luke-jr>
so we can discourage people from adopting crappy BIPs
< btcdrak>
from first glance I think there is a problem with specifically the GPL license part and the comments are fine if it's self contained, without linking to external resources.
< MarcoFalke>
And then ping people: "Please read BIP2, BIP3, ... but don't read BIP1"...
< MarcoFalke>
Why not amend?
< luke-jr>
MarcoFalke: BIPs are amended by replacing them. That's how the process works right now. <.<
< btcdrak>
replace LGPL with GPL is fine.
< luke-jr>
btcdrak: so you'd insist libbitcoin code cannot be used in any BIPs?
< MarcoFalke>
As I said, the BIP process does not make sense to be applied to BIP1 itself.
< btcdrak>
in any case, I didnt get a chance to read the full BIP and digest it's contents. I think there was something about the workflows too which could be improved.
< btcdrak>
MarcoFalke: +1
< luke-jr>
btcdrak: the only licenses BIP 2 *recommends* are BSD, CC0, and GNU-All-Permissive
< gmaxwell>
that huge list is bleh.
< gmaxwell>
MarcoFalke: I made the same argument but luke pointed out that we can put a notice at the top of BIP 1 that says read BIP N instead, and that seemed acceptable enough to me.
< luke-jr>
fine, or delay BIP 2 yet longer by making up new problems that aren't really problems and could have been brought up months ago if it was really a concern.
< gmaxwell>
luke-jr: I had no idea about BIP2 until I wigged out about you assigning a BIP number to a restrictively licensed specification. :)
< luke-jr>
are you subscribed to bitcoin-dev? :|
< gmaxwell>
Yes. But threads get missed.
< * luke-jr>
doesn't know how to solve this.
< gmaxwell>
just don't expect anything to go quickly.
< gmaxwell>
FWIW, IETF requires any source code as part of RFCs be under a fixed three clause BSD license.
< luke-jr>
interesting
< gmaxwell>
(you can also offer under additional licenses, at your choice.. of course)
< luke-jr>
does IETF aim to document standards set by others, or prescribe them?
< gmaxwell>
It does both.
< gmaxwell>
Informational RFCs are usually things standarized outside of the IETF that just get documented in IETF form.
< luke-jr>
BIPs can't do both. maybe not relevant, dunno
< GitHub161>
[bitcoin] laanwj opened pull request #8858: rpc: Generate auth cookie in hex instead of base64 (master...2016_10_01_moar_cookies) https://github.com/bitcoin/bitcoin/pull/8858
< Lauda>
They do connect-reconnect on their own every now and then here
< wumpus>
another idea that has been brought up a few times is to create a service where nodes can publish their peer lists, and the intersection between those is published
< wumpus>
oh that makes them even easier to detect, no kicking needed :)
< Lauda>
Same behavior as last time, yes!
< wumpus>
could add logic that remembers IPs for a while after disconnection, and if the same peer reconnects again, it's labeled/blacklisted. At least if they're unexpected - someone may also have legitimately addnode'd you.
< wumpus>
in any case the banning doesn't have to be automatic, the software could just warn the user which nodes are 'persistently' connecting to you, it's up to them what to do with that
< GitHub19>
[bitcoin] theuni opened pull request #8862: Fix a few cases where messages were sent after requested disconnect (master...fix-disconnect-send) https://github.com/bitcoin/bitcoin/pull/8862