< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15616: rpc: Remove hex from decodescript RPCResult doc (master...1903-rpcDocDecodeS) https://github.com/bitcoin/bitcoin/pull/15616
< warren> fanquake: btw why the alpine container to use guix? the entire point of using guix is to eliminate other non-deterministic tools, the container should be directly guix (and separately the contents of that container are verifiably determinstic)
< fanquake> warren It seemed like the easiest way to get started. As far as I'm aware I can't run/use guix natively on macOS, so I need the container to actually install/run guix inside. The simplest/smallest choice seemed to be Alpine. Very open to other suggestions if you have any.
< fanquake> Related guix on macOS discussion here: https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00111.html
< warren> fanquake_: I suppose it's good to have any working way for macos to additionally replicate the same build for bit-for-bit verification, but given that you rely on osx -> alpine -> guix that's a lot of non-deterministic stuff. I think verifying determinism of the build environment can be done separately and less often (don't bother to bootstrap guix on a system that can't)
< bitcoin-git> [bitcoin] sipa opened pull request #15617: Do not relay banned IP addresses (master...201903_nobannedrelay) https://github.com/bitcoin/bitcoin/pull/15617
< bitcoin-git> [bitcoin] MeshCollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/acbbb7bf0d45...7ec7aea44281
< bitcoin-git> bitcoin/master faf3698 Glenn Willen: wallet: Improve log output for errors during load
< bitcoin-git> bitcoin/master 7ec7aea MeshCollider: Merge #15491: wallet: Improve log output for errors during load
< bitcoin-git> [bitcoin] MeshCollider merged pull request #15491: wallet: Improve log output for errors during load (master...feature-improve-wallet-load-debug-output) https://github.com/bitcoin/bitcoin/pull/15491
< fanquake> \o/
< fanquake> provoostenator hope you don't mind, I've updated 15555 with the new link.
< muoitran> Hi, I'm looking at the AcceptConnection() of the net.cpp and I notice that whenever there is a new incoming connection and nInbound >= nMaxInbound, likely one existing incoming connection will be evicted.
< muoitran> Is this a bug or a design choice? Because doesn't this allow an adversary to evict some current legitimate incoming connections?
< dongcarl> fanquake: Absolutely marvelous work with the Docker image! Will most likely get to test it out today.
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7ec7aea44281...27781b6530c0
< bitcoin-git> bitcoin/master 2e5d482 Steven Roose: tests: Print remaining jobs in test_runner.py
< bitcoin-git> bitcoin/master 27781b6 MarcoFalke: Merge #15466: tests: Print remaining jobs in test_runner.py
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15466: tests: Print remaining jobs in test_runner.py (master...remaining-jobs) https://github.com/bitcoin/bitcoin/pull/15466
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/27781b6530c0...2c336a9ccdf4
< bitcoin-git> bitcoin/master 340ef50 Carl Dong: depends: Defer to Python detected by autoconf
< bitcoin-git> bitcoin/master 89bee1b Carl Dong: depends: tar: Always extract as yourself
< bitcoin-git> bitcoin/master f7696e6 Carl Dong: depends: qt: Don't hardcode pwd path
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15581: depends: Make less assumptions about build env (master...2019-03-true-neutral-depends) https://github.com/bitcoin/bitcoin/pull/15581
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/2c336a9ccdf4...c033c4b5cef8
< bitcoin-git> bitcoin/master e5efacb Karl-Johan Alm: test: Refactor vout fetches in rpc_rawtransaction
< bitcoin-git> bitcoin/master 6c0a6f7 Karl-Johan Alm: wallet/rpc: add maxfeerate parameter to sendrawtransaction
< bitcoin-git> bitcoin/master 7abd2e6 Karl-Johan Alm: wallet/rpc: add maxfeerate parameter to testmempoolaccept
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #13541: wallet/rpc: sendrawtransaction maxfeerate (master...sendrawtransaction-maxfeerate) https://github.com/bitcoin/bitcoin/pull/13541
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15618: refactor: Remove unused function (master...1903-refRem) https://github.com/bitcoin/bitcoin/pull/15618
< MarcoFalke> Sorry, I missed this during merge ^
< MarcoFalke> sneaky attempt of kallewoof to get signet merged? hmm :)
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15620: rpc: Uncouple rpcs from maxTxFee global (master...1903-rpcNoMaxTxFee) https://github.com/bitcoin/bitcoin/pull/15620
< wumpus> MarcoFalke: ouch
< wumpus> wallet/rpc should definitely not touch validation.cpp
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c033c4b5cef8...e45b7f20e651
< bitcoin-git> bitcoin/master fa5c511 MarcoFalke: refactor: Remove unused function
< bitcoin-git> bitcoin/master e45b7f2 Wladimir J. van der Laan: Merge #15618: refactor: Remove unused function
< bitcoin-git> [bitcoin] laanwj merged pull request #15618: refactor: Remove unused function (master...1903-refRem) https://github.com/bitcoin/bitcoin/pull/15618
< MarcoFalke> Indeed
< MarcoFalke> I will get my DrahtBot script to tag pull requests up and running
< MarcoFalke> That script could be useful on its own
< moneyball> hi, i tried setting gmaxwell ban list in the Core GUI debug console, and in response i got "Error: IP/Subnet already banned (code -23)" even though i've never done this before. is there a reason they were already banned for my node?
< warren> moneyball: grep your debug.log, maybe they already triggered ban scores. in any case I think you'd be best to feed it into RPC with a script and ignore the output.
< moneyball> warren: maybe that error message is just referring to a subset of the list as having already been banned. i'll check the debug log...but i doubt all of them have already been banned? in any case, it seems like a more useful response could be provided to the user to avoid confusion? (i can create a github issue if appropriate)
< sipa> moneyball: they may be banned due to automatic behavior
< moneyball> ok. grep'ing for 'ban' reveals one, although i don't see that IP in greg's ban list: 2018-07-28 03:11:56 Misbehaving: peer=302 (80 -> 100) BAN THRESHOLD EXCEEDED
< moneyball> i used bitcoin-cli listbanned to determine i have 474 banned, all of which are manually added. greg's list has 670. so i am wondering why my ban list is less (likely due to error aborting prematurely?). i am also still wondering about the "already banned" error message since i have none in the ban list that are shown as automatic.
< moneyball> (i can take this to another channel, or, to a github issue, if you'd prefer. just say the word.)
< gwillen> moneyball: is it possible that you loaded a version of greg's list or similar in the past?
< echeveria> moneyball: some ranges could overlap.
< moneyball> gwillen: doubtful as i've never done anything around ban lists
< warren> I haven't looked at his ban list, you sure it doesn't have duplicates? Did you run it through sort then uniq and compare the before/after line count?
< warren> If he's using the GUI then I'm guessing it isn't a long lived node that would have a large ban list. Also GUI is a lot less likely to have incoming connections unless you configured your NAT/firewall to allow it. The ban list is mainly relevant to incoming connections.
< moneyball> for context, i'm just testing this out as it is referenced in this week's optech newsletter, so i wanted to make sure our readers have a good experience
< gmaxwell> There is a small range overlap in my banlist, but it shouldn't reject bans for that reason.
< gmaxwell> IIRC There are only two ranges in my banlist at all, one has no overlap in the list because I removed all the overlapped addresses, and the other one I left them in.
< gmaxwell> (removed because it was 245 out of the 256 ips in the range, left the other one in because it was only 20 or so ips out of the range, and thought maybe the range was a bit questionable and might remove it later)
< gmaxwell> moneyball: if you only got one "already banned" that just means there was only one overlap.
< gmaxwell> moneyball: how are you counting in listbanned?
< gmaxwell> $ ./bitcoin-cli listbanned | grep address | wc -l
< gmaxwell> 723
< moneyball> that is how i counted
< moneyball> $bitcoin-cli listbanned | grep address | wc -l
< moneyball> 474
< moneyball> $bitcoin-cli listbanned | grep manually | wc -l
< moneyball> 474
< moneyball> $cat ~/Downloads/banlist.gui.txt | wc -l
< moneyball> 670
< gmaxwell> Is it possible that you used a cached copy (in your browser) of the list? 474 is more like the length of the list last week.
< gmaxwell> I guess I do have one dupe in the list, fixing.
< gmaxwell> hm I don't see the dupe.
< gmaxwell> found it
< gmaxwell> There was just one in there without its /32.
< gmaxwell> maybe that messed up the paste in the gui?
< moneyball> gmaxwell: let me try again
< gmaxwell> moneyball: right, they're the same (as in anytime I update cli I regenerate gui by running cat banlist.cli.txt | cut -d' ' -f2- | sort > banlist.gui.txt )
< moneyball> so maybe the GUI doesn't handle pasting that many items
< gmaxwell> lol :(
< moneyball> i'll try to break it into chunks
< gmaxwell> ::sigh:: maybe I should reorder it so the most important ones are first.
< moneyball> hmmm. even if i paste just ONE into the GUI, i now get this "Method not found" error
< harding> moneyball: are you using the version with ./bitcoin-cli embedded? You need the one where the lines start with "setban"
< moneyball> harding: whoops!
< moneyball> i switched lists...
< harding> Testing on a regtest node, I can paste the current full list into the GUI, have it evaluate without error, and confirm via listbanned that the expected number of bans have been set.
< harding> (Linux here.)
< moneyball> gmaxwell: fyi the line "setban add 31557600" is still missing the /32. i tried loading in a different browser to confirm. did you push the change?
< gmaxwell> moneyball: that one didn't have it, it wasn't a dupe though. the /32 isn't required.
< gmaxwell> (I include it just so the output from list banned is consistent with my list)
< gmaxwell> (I added that one now)
< gmaxwell> harding: maybe it's OS specific? moneyball's latest paste looks pretty clearly like a truncation-- its cutoff in the middle of a line.
< luke-jr> aside: is actually all attackers?
< luke-jr> (just seems strange most of the peers I know there claim to be btcd)
< moneyball> fwiw i'm MacOS, Chrome, Core v0.18rc2
< gmaxwell> luke-jr: yes. 245 out of the 256 IPs in that subnet connected to me falsely claiming to be android wallet, which they clearly are not, and then sit connected listening to all invs.
< midnightmagic> luke-jr: yes. The /24 is one I personally triangulated with someone else. ban one, another takes its place, randomly, in the /24. We got to 64 and then just killed the whole lot. None of them are even real nodes, and someone else has fingerprinted them.
< moneyball> i pasted just the last few dozen in the list into the GUI, and no error message, although the response i get is "null" ... which isn't very user friendly. is it expected?
< gmaxwell> moneyball: I think it has no response on a successful ban, yes.
< moneyball> also it increased by banned list to 509, which now strongly suggests the paste is being truncated
< moneyball> my*
< moneyball> i've managed to get my ban list up to 669, one short of gmaxwell's list of 670. to be clear, is there one dup/overlap in the list that would cause this?
< luke-jr> midnightmagic: yeah. looking like some kind of botnet
< harding> moneyball: the list is now 669 long.
< harding> I mean, it was 10 minutes ago.
< moneyball> ok i re-downloaded...confirmed
< gmaxwell> I dropped one that was actually duplicated, based on moneyball's report earlier.
< moneyball> so harding, for the newsletter, we might want to point out the pasting challenge.
< gmaxwell> so it sounds like maybe on OSX there is a paste limit that is getting in the way.
< moneyball> gmaxwell yeah
< gmaxwell> :(
< midnightmagic> gmaxwell: there's also a paste limitation when working through.. mosh I think and some kinds of shell connections. Easier to just wget it first and pipe.
< luke-jr> gmaxwell: are ALL of your banned IPs implicated in the attack?
< gmaxwell> luke-jr: 245 out of 256.
< luke-jr> gmaxwell: how about the specific one I PM'd you?
< gmaxwell> oh you weren't asking about that /24.
< gmaxwell> Just answering the general question in public: no the IPs in my ban list are either addresses that are mass connecting to (nearly) every reachable node in the network and leaving connections up, OR were directly connecting to a node I control and behaving in a clearly abusive way, OR are part of an apparently eclipse attack in a clearly identifyable way. I'll follow up in PM about the specific
< gmaxwell> ones you're talking about.
< fanquake> dongcarl cheers. I'll take a look at your changes today.
< warren> fanquake: try downloading all of the depends prior to running the build inside guix, ideally the builder should work without any networking at all. That also bypasses the permission issue.