--- Day changed Wed Nov 25 2015
00:05 < GitHub144> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b19fe277dd62...26af1ac7cbce
00:05 < GitHub144> bitcoin/master ae98388 Jonas Schnelli: [Qt] add startup option to reset Qt settings
00:05 < GitHub144> bitcoin/master f71bfef Jonas Schnelli: add UI help for -resetguisettings
00:05 < GitHub144> bitcoin/master 26af1ac Jonas Schnelli: Merge pull request #7006...
00:05 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
00:05 < GitHub116> [bitcoin] jonasschnelli closed pull request #7006: [Qt] add startup option to reset Qt settings (master...2015/11/qt_resetsettings) https://github.com/bitcoin/bitcoin/pull/7006
00:08 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
00:10 < jonasschnelli> hmm.... testing coinjoin and QT. Question:
00:11 < jonasschnelli> I have two 50BTC inputs, one from node0, one from node1. I create a transaction with those inputs with two outputs (49.9 to node0, 49.9 to node1). What would be expected as output for listtransactions and over the GUI?
00:11 < jonasschnelli> I expect only the relevant in/outs should be listed/calculated for the net?
00:13 < gmaxwell> It displays the coins that weren't yours as negative fee.
00:13 < gmaxwell> Which is ... internally consistent though a little confusing when you're not expecting it.
00:15 < wumpus> ah yes the negative fees when you don't own all inputs, that's not just a qt issue
00:16 < jonasschnelli> Yes. Listtransactions tell me now:  "fee": 49.98000000
00:17 < gmaxwell> It's logical in a sense, but hah. can be a real heart stopper.
00:17 < jonasschnelli> haha... right.
00:17 < wumpus> hehe indeed
00:17 < gmaxwell> FWIW, if I had champaign or really drank, I would have poped a cork at that issue being opened.
00:18 < gmaxwell> This is the first real proof of coinjoin being in widespread use by actual users: the reported a known 'bug'!
00:18 < jonasschnelli> Indeed. At it was reported by two users (independent) within 1.5 month... 
00:18 < wumpus> it is good to see people actually using coinjoin, absolutely!
00:19 < gmaxwell> (bug just in quotes because I'm not actually sure what our behavior should be. Without access to the inputs in the wallet, it's hard to handle sanely!)
00:19 < gmaxwell> (reporting it all as fee might actually be the best we can do with the data available)
00:20 < wumpus> can we 'see' that something fishy is happening and flag the transaction as 'probably coinjoin',?
00:20 < wumpus> that'd at least help with the UI aspect a bit
00:20 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
00:21 < gmaxwell> yes, well if there are inputs from outside the wallet we can just flag it as "used outside funds"
00:21 < gmaxwell> Or "used outside funds (coinjoin? lighthouse?)"
00:21 < wumpus> e.g. "you may be seeing exorbitant fees on this transaction because it involves foreign inputs"
00:21 < wumpus> right
00:22 < gmaxwell> well they're the opposite of exorbitant. :P
00:22 < wumpus> negative exorbitant :p
00:22 < gmaxwell> "exuberant fees"
00:22 < wumpus> people may not see the sign correctly, but agreed
00:23 < wumpus> LOL!
00:23 < gmaxwell> yea, it freaked me out the first time.
00:23 < gmaxwell> well actually not the first but the first time I did a CJ with an ordinary amount of coin.
00:25 < gmaxwell> I wasn't likely to mistake this for a too high fee error: 
00:25 < gmaxwell>     "fee": 50000.31337000,
00:25 < gmaxwell> (this is not output from a testnet wallet)
00:25 < wumpus> whoa
00:27 < gmaxwell> but later a 10BTC one startled me I think.
00:27 < wumpus> was that the 'link yourself rich' or something transaction from bitcoin talk?
00:27 < wumpus> e.g. the first coinjoin experiment
00:28 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 244 seconds]
00:29 < gmaxwell> https://bitcointalk.org/index.php?topic=139581.0
00:30 < gmaxwell> It works, FWIW, lots of wallet tracker things think that address is all kinds of stuff.
00:30 < gmaxwell> well half-works, they were supposted to notice all the linked up stuff and realize that what they were doing was dumb.
00:30 < wumpus> it's promising for the future at least when it is more used, they probably won't adjust dumb behavior for one transaction :)
00:32 < gmaxwell> well I made lots of coinjoins with that address, with lots of other people who went on to do coinjoins, and also joined with keys and got them imported varrious places.
00:32 -!- raedah [~raedah@172.56.39.224] has joined #bitcoin-core-dev
00:33 < gmaxwell> otoh I now have to avoid anyone donating to it, because I probably can't spend any coins sent there in a lot of places. :(
00:35 < wumpus> is it 'contaminated'?
00:36 < gmaxwell> https://www.walletexplorer.com/wallet/0093bdcd5f898d99?from_address=1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB  and from what I've heard the commercial anti-fungibility tools are even dumber (more agressive about what they include)
00:37 < gmaxwell> in any case, it seems to think that 'wallet' has 266 addresses, and I believe only two of them are mine. 
00:38 < gmaxwell> actually checking, three of them, how'd that one get linked. :-/
00:42 < CodeShark> expecting dumb people to notice that what they're doing is dumb is a risky success strategy - and avoiding donations is a good kind of problem to have :)
00:42 < tulip> has anybody tested -blocksonly with dynamic fees? 
00:42 < tulip> I sort of expected the dynamic fee RPC calls to return -1, but they don't. they're returning values. 
00:42 < gmaxwell> tulip: I  have, results in the -1 all the time (unless you have prexisting save predictioned), in which case they just fade out.
00:43 < gmaxwell> the results surprised me too, but they go away if you delete the saved stats file.
00:43 < tulip> ah good call.
00:44 < tulip> maybe they should just be hard wired to -1 with blocksonly?
00:47 < gmaxwell> tulip: so blocksonly isn't necessarily all blocks only; as you can have whitelisted peers you accept txn from. I was also contemplating a rpc command to one shot perform a top mempool fetch from a single peer; but I dunno if we'd take that upstream.
00:47 < gmaxwell> but perhaps it should be hardwired -1 when the mempool is totally empty? 
00:48 < tulip> right, ok. 
00:49 < gmaxwell> the goal with the saved state is to give useful resutlts as soon as you start. 
00:49 < tulip> I'd completely forgot it exists, that's all. 
01:00 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
01:00 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Remote host closed the connection]
01:02 < GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26af1ac7cbce...348b281f8a67
01:02 < GitHub102> bitcoin/master 392d3c5 Cory Fields: build: Set osx permissions in the dmg to make Gatekeeper happy
01:02 < GitHub102> bitcoin/master 348b281 Wladimir J. van der Laan: Merge pull request #7092...
01:02 < GitHub54> [bitcoin] laanwj closed pull request #7092: build: Set osx permissions in the dmg to make Gatekeeper happy (master...osx-perm-fix) https://github.com/bitcoin/bitcoin/pull/7092
01:07 < wumpus> jonasschnelli: good call on closing #7089 - indeed, bitcoin's core github is not the place to request changes to consensus behavior
01:07 < jonasschnelli> wumpus: Yes. It was a bit harsh but I think we need to keep discussions out of the github context.
01:08 < gmaxwell> hm. I didn't even see #7089 but yes.
01:08 < gmaxwell> Kind of irritating that they keep going back to probably the worst proposal for that ever done. (e.g. needlessly a hardfork)
01:09 < jonasschnelli> But i agree with him. It causes big pain for HWW devs to trustworthy validate fees (=input amounts).
01:09 < gmaxwell> Oh absolutely.
01:10 < gmaxwell> CHECKSIG in elements alpha tries one fix, though a different one would be better. I expect there will be a decent soft fork new checksig operator proposed within sig months.
01:10 < jonasschnelli> Not sure what is best practice there. But I think retrieving over SPV/BF the inputs and validate these together with the transaction is the only feasible way.
01:12 < gmaxwell> jonasschnelli: Currently, sure. But if we add a new checksig operator it can avoid having to check the inputs at all.
01:12 < wumpus> providing the dependent transactions together with the transaction seems like the only feasible way, certainly if the HW wants to verify that the inputs are really the ones given
01:12 < gmaxwell> Checksig already signs the txin scriptpubkey but what it really should sign is the whole utxo. If it did, then when signing you need only provide the utxos and not the whole parent transactions. If you lie the signature will be invalid.
01:13 < gmaxwell> But this can't be done as a sighash flag to checksig. Well it can but it would be insane and irresponsbile to hardfork the network for that.
01:13 < wumpus> indeed it signs the scriptpubkey, and that doesn't help verifying the amount
01:14 < wumpus> sure, a hardfork for that is stupid
01:19 < tulip> it looks like there's mining software on the main network which is rolling the sequence number. not disastrous or particularly interesting at the moment, but it might be notable if anybody is altering the behaviour of sequence numbers with a consensus rule like in BIP112. 
01:19 < gmaxwell> lol oh boy. fortunately BIP constrains the transaction version number.
01:19 < gmaxwell> er that BIP.
01:20 < gmaxwell> tulip: thanks for noticing that. :(
01:27 < tulip> might be problematic if miners using this software just flip forward the version number though. 
01:28 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
01:28 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
01:31 < wumpus> flipping forward the version number like people click 'OK' on software's terms and conditions
01:39 < jonasschnelli> hmm... testing wallet.py over the GUI makes the test fail.
01:39 < jonasschnelli> It looks like that self.nodes[2].settxfee(Decimal('0.001')) has no effect
01:39 < jonasschnelli> Assertion failed: 89.99977400 != 89.99900000
01:40 < jonasschnelli> how can the GUI "disturb" self.nodes[2].settxfee(Decimal('0.001')) and make the RPC servers sendtoaddress make pay different fees
01:42 < sipa> that seems weird...
01:43 < jonasschnelli> maybe this is related to the fPayAtLeastCustomFee
01:44 < wumpus> the GUI at least used to hook into fee decisions
01:44  * wumpus checks ui_interface
01:44 < gmaxwell> jonasschnelli: I suppose this is why it's important to test for impossible outcomes!
01:45 < wumpus> ok, seems no longer the case
01:46 < wumpus> neither ui_interface or the signals on CWallet itself have anything to do with determining fees
01:47 < wumpus> maybe a race condition as the UI gives some background load
01:47 < jonasschnelli> hmm... CreateTransaction repots a payTxFee=22600 after calling settxfee(Decimal('0.001')).
01:52 < wumpus> maybe coin control interfering? or some settings from QSettings?
01:52 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
01:53 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 272 seconds]
01:53 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
01:53 -!- neha [~narula@mint-square.mit.edu] has quit [Ping timeout: 272 seconds]
01:53 < wumpus> ideally the GUI should have an 'ignore QSettings' option for tests
01:54 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has joined #bitcoin-core-dev
01:54 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has quit [Changing host]
01:54 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
01:54 -!- neha [~narula@mint-square.mit.edu] has joined #bitcoin-core-dev
01:54 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 272 seconds]
01:56 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
02:29 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
02:31 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has quit [Ping timeout: 255 seconds]
02:32 < GitHub53> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/348b281f8a67...2b2ddc558e1c
02:32 < GitHub53> bitcoin/master 5ad5463 MarcoFalke: Squashed 'src/secp256k1/' changes from 2bfb82b..6c527ec...
02:32 < GitHub53> bitcoin/master fa63e49 MarcoFalke: Merge commit '5ad54630935d1f340666de7bc9ffef9b8a1df296' into HEAD
02:32 < GitHub53> bitcoin/master 2b2ddc5 Wladimir J. van der Laan: Merge pull request #7088...
02:32 < jonasschnelli> found the problematic UI interaction that interferes the RPC server.
02:32 < GitHub130> [bitcoin] laanwj closed pull request #7088: [trivial] pull secp256k1 subtree (master...MarcoFalke-2015-syncSecp256k1) https://github.com/bitcoin/bitcoin/pull/7088
02:32 < jonasschnelli> void SendCoinsDialog::updateGlobalFeeVariables()  ---> fSendFreeTransactions = ui->checkBoxFreeTx->isChecked()
02:32 < jonasschnelli> Gets called when the GUI starts
02:33 < jonasschnelli> sorry... not fSendFreeTransactions , i meant instead: fPayAtLeastCustomFee = ui->radioCustomAtLeast->isChecked();
02:33 < wumpus> good catch
02:33 < wumpus> phew, at least not a race condition!
02:41 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-core-dev
03:16 < wumpus> though ideally the UI wouldn't be updating global variables like that, just pass everything it needs into the transaction creation/commit
03:22 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
03:31 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 246 seconds]
03:36 < jonasschnelli> wumpus: I though the same. The UI should not connect globals vars with radio-buttons, etc.
03:36 < wumpus> managed to avoid that with coin control, but apparently some did sneak in
03:37 < wumpus> (e.g. coincontrol config is global, but only to the GUI, it is explicitly passed to the core, so doesn't/shouldn't interfere with RPC usage)
03:38 < jonasschnelli> but i don't get this. "settxfee" is supposed to by by fee per KB?! Also it help says so. But it's actually absolute?!
03:39 < wumpus> it's per kB afaik
03:39 < jonasschnelli> If it would be, that assert would not be true: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/wallet.py#L111
03:40 < jonasschnelli> I just created a transaction on regtest after calling "settxfee 0.001" ... gettransaction tells me: "fee": -0.00100000
03:41 < jonasschnelli> hexlen 384 = 192 bytes = a expected fee of 0.000192
03:41 < wumpus> it assumes rounding?
03:42 < sipa>     if (fPayAtLeastCustomFee && nFeeNeeded > 0 && nFeeNeeded < payTxFee.GetFeePerK())
03:42 < sipa>         nFeeNeeded = payTxFee.GetFeePerK();
03:42 < jonasschnelli> no. settxfee to 0.01 resuls in a transaction with fee "fee": -0.01000000
03:42 < sipa> ^ that looks complete broken
03:42 < sipa> payTxFee is treated as a minimum, absolute, fee for a transaction
03:42 < jonasschnelli> right... this needs fixing.
03:43 < sipa> what is this "payatleastcustomfee" ?
03:43 < sipa> the comment says "user selected total at least"
03:43 < sipa> so this is clearly intentional
03:44 < jonasschnelli> Right. But fPayAtLeastCustomFee = true by default.
03:44 < jonasschnelli> Which makes by default every fee absolute?
03:44 < jonasschnelli> and the only way to change fPayAtLeastCustomFee is over the GUI?
03:44 < sipa> ... yup
03:44 < jonasschnelli> hah
03:45 -!- MarcoFalke [8af60238@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.56] has joined #bitcoin-core-dev
03:45 < jonasschnelli> i think we should review https://github.com/bitcoin/bitcoin/pull/6708
03:45 < sipa> from within the coin control dialog
03:45 < sipa> so it makes sense that from without coincontrol you're able to set the absolute fee
03:46 < sipa> but it should 1) use a separate variable (not paytxfee, but for example overridetotalfee) 2) it should be passed down through the coin control preferences, not through a global
03:46 < jonasschnelli> Right. It should not be a global variable and should not touch outside GUI behavior. It's actually also available without CoinControl.
03:47 < sipa> well it being set to true by default is broken
03:47 < sipa> and it can only be unset through the coincontrol gui
03:47 < jonasschnelli> okay. will work on a fix.
03:47 < jonasschnelli> nFeeNeeded = payTxFee.GetFeePerK(); // <--- is a dirty hack!
03:48 < jonasschnelli> but i see, that an absolute fee can help (during RPC tests and maybe some other usecases).
03:49 < jonasschnelli> What about adding an option to set absolute fees over "settxfee"?
03:49 < sipa> makes no sense
03:49 < sipa> without coin control
03:49 < jonasschnelli> It only makes sense for regression tests.
03:50 < sipa> and if you're doing selection manually (via createrawtransaction), there is no need for it
03:50 < jonasschnelli> to deterministic calculate fees
03:50 < sipa> well if it's exposed by RPC it is necessarily global
03:50 < sipa> (for RPC)
03:50 < sipa> let's first fix the use case, then the rest?
03:51 < jonasschnelli> If we drop absolute fees (which would be the right step), rpc tests need this update: https://github.com/bitcoin/bitcoin/pull/6708/files#diff-51c9989cea15f3cac744183b78cb0688
03:53 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-core-dev
03:54 < sipa> jonasschnelli: i'm writing a fix
03:54 < jonasschnelli> sipa: okay.. nice.
03:54 < jonasschnelli> I'll fix the UI stuff.
03:55 < jonasschnelli> Need to drop the absolut fee option for "non-coincontrol" transactions
03:56  * jonasschnelli needs to go back to the thing he was actually working on, "CoinJoin transactions display"
03:59 < sipa> oh, there is a nCustomFeeRadio set from the send dialog
03:59 < MarcoFalke> jonasschnelli, are you working on the https://github.com/bitcoin/bitcoin/issues/6749#issuecomment-157746758 thing?
03:59 < sipa> sorry, this will need gui hackery
03:59 < MarcoFalke> Didn't catch that, so we are not duplicating effort
04:00 < jonasschnelli> MarcoFalke: I think sipa has just started to work on some things there. I'll wait until he has something.
04:00 < jonasschnelli> Then i'd like to address the UI stuff
04:00 < sipa> jonasschnelli: so my suggestion would be to remove the "pay at least total" function from the regular send dialog, and move it to the coin control one
04:01 < MarcoFalke> sipa, to fix https://github.com/bitcoin/bitcoin/issues/6749#issuecomment-157746758 ?
04:01 < sipa> then the setting can just be passed via the coincontrol settings object, which is trivial
04:01 < sipa> MarcoFalke: no, to fix the fact that the "set at least total" function works via a global and changes all fees
04:02 < sipa> why was this introduced?
04:02 < jonasschnelli> sipa: right. It should be in the CC dialog. 
04:02 < jonasschnelli> <sipa>	why was this introduced? / you mean the "pay at least total"? Probably together with Cozzes CC stuff?
04:03 < MarcoFalke> Yes it's by cozz
04:03 < sipa> so nobody ever noticed that this makes bitcoin core's transaction pay around 4x too much fee by default?
04:04 < jonasschnelli> sipa: hah. I assume "no"!.. scary!
04:04 < sipa> oh, i assume paytxfee was 0 by default, so it didn't have any effect
04:04  * jonasschnelli thinks Cozz was payed by the miners... :)
04:04 < jonasschnelli> sipa: right. This is a point.
04:05 < sipa> jonasschnelli: see my betterabsolute branch
04:05 < sipa> jonasschnelli: sorry, i thought i could do more, but there rest is gui code
04:05 < MarcoFalke> I haven't checked previous code but it may be to mimick how earlier version have done that.
04:05 < MarcoFalke> Was this "let's use round numbers for fees" a thing back then?
04:05 < sipa> right, i think until some time in the past, we always paid per kilobyte started
04:05 < jonasschnelli> sipa: np. I'm happy to take over.
04:05 < sipa> not per byte
04:05 < sipa> jonasschnelli: thanks!
04:18 < MarcoFalke> sipa, should I rebase onto betterabsolute?
04:19 < MarcoFalke> or wait until the gui is fixed
04:20 < sipa> MarcoFalke: up to jonasschnelli 
04:20 < jonasschnelli> MarcoFalke: let me finish it, i'll also cherry-pick your wallet.py changes,... maybe afterwards there are still things that could be optimized.
04:22 < GitHub91> [bitcoin] laanwj opened pull request #7095: Replace scriptnum_test's normative ScriptNum implementation (master...2015_11_remove_openssl_consensus_checks) https://github.com/bitcoin/bitcoin/pull/7095
04:26 -!- guest234234 [~guest2342@223.207.237.249] has joined #bitcoin-core-dev
04:29 < MarcoFalke> wumpus, is https://github.com/bitcoin/bitcoin/pull/527/files#diff-e2b7ef544fda33841c06f443b2cab6b3 still relevant for gitian?
04:29 < wumpus> MarcoFalke: no
04:30 < wumpus> it never was; gitian-downloader was meant to be a downloader for bitcoin that checks the gitian signatures, but AFAIK it was never completed or used
04:31 < MarcoFalke> But the folder is used to store the pgp keys?
04:31 < wumpus> yes, just a convention
04:32 < wumpus> the download-configs are pointless
04:34 < wumpus> I think they've been kept around in case anyone was ever going to resurrect the tool, but that never happened, I guess they're out of date enough to be removed now
04:34 < MarcoFalke> Just doing this with my next trvial pull
05:05 < MarcoFalke> Oh, that's why travis is only running with 3/5 speed.
05:05 < MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92025728
05:05 < MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/builds/92213684
05:22 < GitHub180> [bitcoin] jonasschnelli opened pull request #7096: [Wallet] fix settxfee and improve minimum absolute fee GUI options (master...2015/11/feefix) https://github.com/bitcoin/bitcoin/pull/7096
05:25 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
05:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
05:26 -!- tulip [~tulip@unaffiliated/tulip] has quit []
05:31 < GitHub147> [bitcoin] jonasschnelli closed pull request #6708: [wallet] Default fPayAtLeastCustomFee to false (master...MarcoFalke-2015-walletFixPayTxFee) https://github.com/bitcoin/bitcoin/pull/6708
05:32 -!- MarcoFalke [8af60238@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.56] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
05:36 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
05:53 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
05:53 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
05:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
05:55 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
05:57 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
05:57 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:02 -!- guest234234 [~guest2342@223.207.237.249] has quit [Ping timeout: 244 seconds]
06:03 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
06:03 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host]
06:03 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
06:07 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
06:07 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:09 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
06:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:14 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:24 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:25 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
06:25 -!- MarcoFalke [8af60238@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.56] has joined #bitcoin-core-dev
06:32 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
06:32 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:34 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
06:34 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
06:38 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:38 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
07:16 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
07:23 -!- ParadoxSpiral [~ParadoxSp@p508B8071.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:39 -!- MarcoFalke [8af60238@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.56] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
08:11 -!- zookolaptop [~user@2601:281:8001:26aa:ac94:e5d8:45fe:a98e] has quit [Ping timeout: 246 seconds]
08:44 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 260 seconds]
08:44 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
09:38 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
09:39 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev
09:39 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Client Quit]
09:45 -!- ParadoxSpiral_ [~ParadoxSp@p508B8799.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:49 -!- ParadoxSpiral [~ParadoxSp@p508B8071.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
09:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
10:11 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev
10:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:26 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kssotdfzbjvavpmi] has quit [Ping timeout: 240 seconds]
10:26 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qgkdjfpkbqmigkig] has joined #bitcoin-core-dev
11:37 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds]
11:48 < cfields_> sipa: thoughts on https://github.com/theuni/bitcoin/commit/792b0f5da618ea51ecd7b21db633faa6743c1e68 ?
11:50 < cfields_> not sure what the reasoning was for the double lookup, does it serve a purpose that a static dummy source wouldn't?
12:52 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
13:03 < cfields_> ok, i must be going crazy... using a vanilla node with no externally bound address, ipv4/ipv6 aren't set as reachable by default. So when addr's come in, they're not added to addrman since they fail IsReachable(). Result is that addrman only ever contains dns seeds
13:04 < cfields_> ...that can't be right.
13:08 < gmaxwell> oh that bug. damn
13:09 < gmaxwell> I think phantomcircuit (?) found that a couple months ago, someone did, and I forgot about it. So it may well be true.
13:09 < cfields_> gmaxwell: so that's actually the case? whoa.
13:09 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
13:09 < cfields_> just verified with an addrman dump
13:11 < cfields_> gmaxwell: surely it's reasonable to set a net to reachable once a connection has been established on it?
13:12 < gmaxwell> I think we should be setting IPv4 reachable if we have any IPv4 bindings at least.
13:12 < gmaxwell> and tor reachable if we have a onion proxy configured.
13:13 < cfields_> i believe the latter is already done
13:25 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has quit [Ping timeout: 240 seconds]
13:33 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
13:46 -!- raskolnnikov [~raskolnni@181.194.130.224] has quit [Quit: Leaving]
13:57 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
14:06 < gmaxwell> wumpus: I switched to a somewhat different approach in that mempool limit patch. I now have it set setInventoryKnown (I think it should have always done this), and not return anything in setInventoryKnown.  It also only considers the top 8192 entries in the mempool.
14:19 -!- ParadoxSpiral_ [~ParadoxSp@p508B8799.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
14:28 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 252 seconds]
14:28 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
14:34 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
14:40 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
14:40 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:43 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
14:52 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving]
14:57 -!- Guest66004 [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
15:10 < GitHub82> [bitcoin] gmaxwell opened pull request #7099: Add whitelistforcerelay setting and default to off. (master...control_relay_force) https://github.com/bitcoin/bitcoin/pull/7099
15:18 -!- Guest66004 [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host]
15:18 -!- Guest66004 [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
15:18 -!- Guest66004 is now known as jgarzik_
15:24 -!- asoltys [~adam@li92-10.members.linode.com] has joined #bitcoin-core-dev
15:26 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 250 seconds]
15:39 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
15:59 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
16:17 -!- tulip [~tulip@unaffiliated/tulip] has quit [Ping timeout: 272 seconds]
16:18 -!- guest234234 [~guest2342@223.207.237.249] has joined #bitcoin-core-dev
16:19 -!- guest234234 [~guest2342@223.207.237.249] has quit [Read error: Connection reset by peer]
16:40 < gmaxwell> sipa: gonna address my comment on https://github.com/bitcoin/bitcoin/pull/6996 ?
16:40 < gmaxwell> sipa: do you have an opinions about jtimons's comment: https://github.com/bitcoin/bitcoin/pull/6508
16:44 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 246 seconds]
16:44 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
16:46 < sipa> gmaxwell: yeah, will od
16:48 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
16:51 < cfields_> Luke-Jr: ping. Seems your dns seed doesn't support the 0x20 hack (that was fun to track down). What is it running?
16:51 < gmaxwell> Whats the 0x20 hack?
16:52 < cfields_> gmaxwell: reply with the same cAsE as the query
16:52 < sipa> cfields_: i think it's running github.com/sipa/bitcoin-seeder
16:53 < cfields_> sipa: assuming yours runs the same, i can't test against that now 'cause it's down :p
16:53 < sipa> mine is not down
16:54 < cfields_> mm, is for me
16:54 < sipa> at least, it's serving actual requests :)
16:54 < tulip> I can reach all of the DNS seeds at the moment. 
16:54 < cfields_> gmaxwell: https://isc.sans.edu/diary/Use+of+Mixed+Case+DNS+Queries/12418
16:56 < Luke-Jr> what sipa said, but I don't see a use case to support this?
16:57 < cfields_> tulip: thanks. confirmed working on a vps as well. Looks like my default dns is borked atm
16:57 < tulip> ;; ANSWER SECTION:
16:57 < tulip> dnsseed.bitcoin.DASHjr.org
16:57 < gribble> Error: "ANSWER" is not a valid command.
16:57 < tulip> is that not correct?
16:59 < sipa> https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
16:59 < cfields_> tulip: hmm, looks correct.
17:00 < tulip> maybe there's something between you and his DNS server which is mutating it? 
17:00 < cfields_> (assuming that's how you queried it, ofc)
17:00 < tulip> yes. 
17:01 < cfields_> hmm. libevent turns on a check by default, so resolves in my test app are failing. when i turn the option off they succeed. "dig" succeeds as well.
17:01 < cfields_> i'll keep poking around.
17:02 < cfields_> (matt/jonas seeds work fine)
17:08 < BlueMatt> wumpus: fyi, if you want me to see something on github, tag @BugTheBlueMatt not @TheBlueMatt (which just gets delivered just like any other notification email)
17:09 < BlueMatt> (and there doesnt seem to be a way to have github route to a different email address if you're tagged :/ )
17:09 < sipa> BlueMatt: disable all notification mails except tagging :)
17:09 < BlueMatt> sipa: but I dont want to do that :(
17:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qgkdjfpkbqmigkig] has quit [Quit: Connection closed for inactivity]
17:35 < BlueMatt> wumpus: also, wait, why does the gitian build env need network access?
17:36 < BlueMatt> it really shouldnt be allowed to have network access (we really want to support doing builds via gitian on airgapped machines)
17:36 < BlueMatt> oh, the pr is still open, i'll go comment there
17:40 -!- Squidicc [~squid@pool-173-48-117-206.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
17:41 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
17:41 < dcousens> what happens if SIGHASH_SINGLE is used, but no corresponding output exists?
17:42 < tulip> the SIGHASH_SINGLE bug :P
17:42 < dcousens> haha, nvm, thats right
17:42 < sipa> dcousens: hash == 1 is signed
17:43 -!- Squidicuz [~squid@pool-173-48-117-206.bstnma.fios.verizon.net] has quit [Ping timeout: 260 seconds]
17:43 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
17:52 -!- guest234234 [~guest2342@223.207.237.249] has joined #bitcoin-core-dev
18:12 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
18:12 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
18:35 < midnightmagic> BlueMatt: it is possible to do it entirely offline unless something fundamental changed.
18:35 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:43 < gmaxwell> Fishing for concept acks dgenr8 pointed out that the sendbuffer size reduction a long time ago ended up turning the setInventoryKnown mruset down to 1000 entries!   I'd like to change that mruset to do per-peer salted key hashing and truncate to 64-bits, then increase its size to 100,000 entries.  With 64 bits the probablity that there has ever been a collission in the history of all transaction
18:43 < gmaxwell> s is only about 0.02% and even if there were one, it would just mean that you'd fail to INV a transaction to a single peer.
18:51 < tulip> height 385363 has 521 txns, 1142 sigs, 169 cache misses. not bad for a node with 10 minutes of uptime. 
18:53 < gmaxwell> tulip: may be due to a peer spamming you with their mempool at connect.
18:55 < tulip> maybe.
18:55 < sipa> gmaxwell: or a rolling bloom filter?
18:57 < gmaxwell> I was trying to keep MRU behavior, but maybe we don't really need it.
18:57 < gmaxwell> would certantly be easier.
18:59 < gmaxwell> BlueMatt: on that subject, I still have this behavior where RNC seems broken; -- it's my only source of transactions on a testnode and I've never seen it get more than 1671 tx.
18:59 < gmaxwell> okay jinx, it's actually at 1783, but thats still small.
19:02 < sipa> gmaxwell: rolling bloom filter is effectively mru
19:04 < gmaxwell> RB is not per-use salted? weird. why.
19:07 < gmaxwell> what. I am boggle this code. 
19:07 < gmaxwell> oh I see. 
19:08 < gmaxwell> still, don't see why it's not salted.
19:10 < sipa> it is salted?
19:10 < sipa> no?
19:10 < gmaxwell> constructor has no salt argument and calls the underlying blooms with a tweak of 0.
19:13 < gmaxwell> looks like you have to call reset to randomize it.
19:13 < sipa> oh, right, we didn't want to call getrandbytes in a global constructor
19:13 < gmaxwell> ah duh.
19:14 < sipa> but it could actually automatically reset upon first use
19:14 < gmaxwell> just making ninsertions oversize would do that.  Is there a reason to just not reset it every time a table is changed?
19:15 < gmaxwell> e.g. with b1/b2 are cleared?
19:15 < sipa> yes, that's what i'm suggesting
19:15 < gmaxwell> No reason I can see why the two should have the same tweak.
19:15 < sipa> but only when an actual entry is written to it
19:15 < sipa> not on construction
19:16 < gmaxwell> yea, sure, I mean make the clear functions in insert do it when they clear.
19:16 < sipa> right
19:19 < gmaxwell> whats with the 2* in the rolling bloom filter?
19:19 < sipa> it's needed
19:19 < sipa> :)
19:20 < gmaxwell> whats an acceptable FP rate for the known filtering?
19:25 -!- guest234234 [~guest2342@223.207.237.249] has quit [Ping timeout: 255 seconds]
19:26 < sipa> you need around 4.8 bits per element per 1/10 FP rate
19:26 < sipa> so 6*4.8 bits per element for one in a million
19:27 < dcousens> "what. I am boggle this code." lol
19:30 < gmaxwell> sipa: as far as 'mru', well-- so it doesn't reinsert in the other filter when it hits. And doing it yourself isn't quite ideal since you'll increment the count.
19:30 < sipa> ?
19:30 < gmaxwell> so I think the contains code should check one filter, but insert in the other, not yet mature filter, in order to have the behavior you expected.
19:31 < gmaxwell> if I send you the same item non-stop, and you drop it when contains, it will fall out. 
19:33 < sipa> right
19:33 < sipa> it is most recently added, not most recently used
19:50 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Ping timeout: 260 seconds]
19:50 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
20:19 -!- Irssi: #bitcoin-core-dev: Total of 86 nicks [0 ops, 0 halfops, 0 voices, 86 normal]
20:32 -!- guest234234 [~guest2342@223.207.237.249] has joined #bitcoin-core-dev
20:40 < cfields_> Luke-Jr / sipa: nevermind the dns red herring earlier. It looks to be a combination of a libevent implementation detail and a dns resolver implementation detail. annoying.
20:41 < cfields_> we bump up against the 512 byte udp limit. Due to compression, messing with CaSe can grow the payload. Different resolvers/cachers react in different ways when hitting the 512 byte mark.
20:44 < cfields_> In this case, my local cache appends additional records. Apparently smart resolvers strip those off and just ignore the truncation. however, libevent marks a truncation as a failure.
21:41 -!- tulip [~tulip@unaffiliated/tulip] has quit []
21:48 < GitHub92> [bitcoin] gmaxwell opened pull request #7100: Replace setInventoryKnown with a rolling bloom filter. (master...known_bloom) https://github.com/bitcoin/bitcoin/pull/7100
22:21 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
22:23 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
22:29 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
22:31 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
22:36 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 252 seconds]
22:41 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
23:10 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vvndlqovnchvmuww] has joined #bitcoin-core-dev
23:25 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
23:27 -!- jgarzik__ [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
23:28 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Ping timeout: 265 seconds]
23:28 -!- Eliel_ [~jojkaart@jkaartinen.iki.fi] has quit [Ping timeout: 265 seconds]
23:28 -!- arowser_ [~quassel@106.120.101.38] has joined #bitcoin-core-dev
23:29 -!- bsm1175322 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
23:29 -!- jl2012_ [~jl2012@119246245241.ctinets.com] has joined #bitcoin-core-dev
23:29 -!- Eliel [~jojkaart@jkaartinen.iki.fi] has joined #bitcoin-core-dev
23:30 -!- BlueMatt_ [~BlueMatt@mail.bluematt.me] has joined #bitcoin-core-dev
23:30 -!- aj_ [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
23:30 -!- jcorgan_ [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has joined #bitcoin-core-dev
23:30 -!- jcorgan_ [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has quit [Changing host]
23:30 -!- jcorgan_ [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
23:31 -!- luke-jr_ [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
23:31 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
23:31 -!- Arnavion3 [~Arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
23:31 -!- Arnavion3 is now known as Arnavion
23:31 -!- wump [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
23:31 -!- sipa_ [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev
23:32 -!- da2ce7_ [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
23:32 -!- phantomcircuit_ [phantomcir@2600:3c01::f03c:91ff:fe73:6892] has joined #bitcoin-core-dev
23:34 -!- crescend1 [~mozart@173.203.100.20] has joined #bitcoin-core-dev
23:35 -!- Netsplit *.net <-> *.split quits: arowser, BlueMatt
23:35 -!- warren_2 [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev
23:36 -!- Netsplit *.net <-> *.split quits: btcdrak, jl2012, morcos_
23:36 -!- berndj-blackout [~berndj@azna.co.za] has joined #bitcoin-core-dev
23:36 -!- Netsplit *.net <-> *.split quits: mm_1, jcorgan, warren, Madars, Apocalyptic, berndj
23:36 -!- warren_2 is now known as warren
23:36 -!- guruvan- [~guruvan@unaffiliated/guruvan] has joined #bitcoin-core-dev
23:36 -!- Netsplit *.net <-> *.split quits: Squidicc, d_t, lightningbot, pmienk, jgarzik_, jonasschnelli, Luke-Jr
23:38 -!- Netsplit over, joins: Apocalyptic
23:39 -!- Netsplit over, joins: mm_1
23:40 -!- Netsplit *.net <-> *.split quits: crescendo, Guest1234, nanotube, petertodd, isis, Anduck, bsm117532
23:40 -!- Netsplit over, joins: petertodd
23:40 -!- Netsplit *.net <-> *.split quits: molly, aj, go1111111, phantomcircuit, raedah, wumpus, pkthebud
23:41 -!- Netsplit *.net <-> *.split quits: da2ce7, michagogo, guruvan, fkhan, helo, baldur, sipa
23:41 -!- guruvan- is now known as guruvan
23:41 -!- Netsplit over, joins: pmienk
23:41 -!- pkthebud [uid128839@gateway/web/irccloud.com/session] has joined #bitcoin-core-dev
23:41 -!- Netsplit over, joins: helo
23:42 -!- Netsplit *.net <-> *.split quits: PaulCapestany, davec
23:42 -!- fkhan [weechat@unaffiliated/loteriety] has joined #bitcoin-core-dev
23:42 -!- Netsplit over, joins: PaulCapestany
23:43 < GitHub96> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/2b2ddc558e1c...be281d8a83ca
23:43 < GitHub96> bitcoin/master b3caa9b Patick Strateman: Move bloom filter filtering logic outside of command "switch" (giant if/else)....
23:43 < GitHub96> bitcoin/master 0f4dc53 Patick Strateman: Add enforcenodebloom option....
23:43 < GitHub96> bitcoin/master 9cf6688 Patick Strateman: Document both the peerbloomfilters and enforcenodebloom options.
23:44 < GitHub110> [bitcoin] laanwj closed pull request #7087: [Net]Add -enforcenodebloom option (master...2015-11-23-bloom-disable) https://github.com/bitcoin/bitcoin/pull/7087
23:44 -!- Netsplit over, joins: d_t
23:45 -!- Arnavion [~Arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
23:46 -!- Netsplit over, joins: Anduck
23:49 -!- Netsplit over, joins: davec
23:49 -!- Netsplit over, joins: go1111111
23:49 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:49 -!- Netsplit over, joins: arowser
23:49 -!- Netsplit over, joins: jl2012
23:51 -!- warren_2 [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev
23:51 -!- Netsplit over, joins: nanotube
23:52 -!- ParadoxSpiral [~ParadoxSp@p508B8799.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
23:52 -!- Netsplit over, joins: raedah
23:55 -!- btcdrak_ [uid115429@gateway/web/irccloud.com/session] has joined #bitcoin-core-dev
23:55 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev
23:56 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
23:56 -!- Netsplit *.net <-> *.split quits: warren, pmienk, AtashiCon, evoskuil, neha, helo, d_t, jl2012_, berndj-blackout, tripleslash,  (+2 more, use /NETSPLIT to show all of them)
23:56 -!- warren_2 is now known as warren
23:56 -!- ParadoxSpiral [~ParadoxSp@p508B8799.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
23:56 -!- Netsplit over, joins: evoskuil
23:58 -!- Netsplit over, joins: d4de
23:58 -!- Netsplit over, joins: neha
23:59 -!- luke-jr_ is now known as Luke-Jr