12015-11-24T00:09:25  <gmaxwell> sipa: do you have any thoughts about where in the block acceptance plumbing it it would be best to extract a "most recent time Peer X gave us an accepted block"?  As I'm doing for transactions in #7082 ?
  22015-11-24T00:10:25  *** Guest23423 has joined #bitcoin-core-dev
  32015-11-24T00:13:38  *** guest234234 has quit IRC
  42015-11-24T00:23:12  *** Guest23423 has quit IRC
  52015-11-24T00:32:21  *** skyraider has quit IRC
  62015-11-24T01:14:29  *** Ylbam has quit IRC
  72015-11-24T01:17:17  *** guest234234 has joined #bitcoin-core-dev
  82015-11-24T01:29:16  *** JackH has quit IRC
  92015-11-24T01:42:02  *** parazyd has left #bitcoin-core-dev
 102015-11-24T02:48:14  *** d_t has quit IRC
 112015-11-24T02:48:37  *** d_t has joined #bitcoin-core-dev
 122015-11-24T03:07:22  *** jl2012 has quit IRC
 132015-11-24T03:07:26  *** jl2012_ has joined #bitcoin-core-dev
 142015-11-24T03:08:24  *** belcher has quit IRC
 152015-11-24T03:16:20  *** randy-waterhouse has quit IRC
 162015-11-24T03:16:43  *** randy-waterhouse has joined #bitcoin-core-dev
 172015-11-24T03:24:32  *** go1111111 has quit IRC
 182015-11-24T03:38:28  *** go1111111 has joined #bitcoin-core-dev
 192015-11-24T04:34:00  <gmaxwell> Anyone else seeing connections from 54.210.68.46 multiple times to your nodes, sitting running the mempool command as fast as its little feet will go?
 202015-11-24T04:35:03  <jgarzik> I've been inclined to disable mempool by default for months
 212015-11-24T04:35:23  <gmaxwell> I've banned this particular nussance several times, on several nodes in the past. And now it seems to be changing IPs and behaviors to avoid being banned.
 222015-11-24T04:36:01  <gmaxwell> If it's also spamming you, feel free to report to https://aws.amazon.com/forms/report-abuse
 232015-11-24T04:36:23  <gmaxwell> jgarzik: I think we should probably only let one request per peer per block, and only return the top couple blocks worth of mempool.
 242015-11-24T04:38:01  <tulip> gmaxwell: yes, multiple connections announced as /btcwire:0.2.0/.
 252015-11-24T04:38:42  <gmaxwell> tulip: yea, I have one node with four, one with two, one with one.
 262015-11-24T04:38:51  <gmaxwell> I haven't checked the others yet.
 272015-11-24T04:38:54  <jgarzik> gmaxwell, That's reasonable - though I really don't see much use of it.  It occasionally gets used for diagnostics or by miners - though the fingerprint/analysis people will probably use it soon if not already.
 282015-11-24T04:40:12  <tulip> as much as I'd like to see it gone, people will probably turn to inventory hammering to learn memory pool contents :(
 292015-11-24T04:41:20  <gmaxwell> most of the stuff related to the anti-fungibility/anti-privacy attacks would be more completely addressed by fixing announcement so that sybil/etc. attacking the network doesn't teach you anything interesting.
 302015-11-24T04:42:24  *** wangchun has quit IRC
 312015-11-24T04:42:25  <gmaxwell> tulip: good point.  Yea, so long as there is a strong incentive to abusively data mine the network; people will do so.
 322015-11-24T04:43:00  <tulip> on second thought, it's probably just an incentive to stay connected to every peer permanently.
 332015-11-24T04:43:46  <gmaxwell> tulip: they'd use a lot less bandwidth that way.
 342015-11-24T04:44:23  <gmaxwell> I mean this current mempool sucker is using 10x the bandwidth of any of my other peers.
 352015-11-24T04:45:13  <jgarzik> We already account traffic up & down.  You'd think this could be dealt with through generic resource accounting.
 362015-11-24T04:45:58  <tulip> modified clarks law: any sufficiently buggy software is indistinguishable from denial of service.
 372015-11-24T04:47:36  *** randy-waterhouse has quit IRC
 382015-11-24T04:47:37  <gmaxwell> tulip: yea, my amazon report said that since it doesn't have a webpage or any other contact information I can't determine if its buggy or malicious.
 392015-11-24T04:48:52  <phantomcircuit> jgarzik, i assume that the mempool infinite loop is some kind of poorly thought out sybil attack
 402015-11-24T04:48:52  *** randy-waterhouse has joined #bitcoin-core-dev
 412015-11-24T04:49:15  <jgarzik> phantomcircuit, plain ole asymmetric DoS
 422015-11-24T04:49:42  <phantomcircuit> jgarzik, responding to the mempool command is actually very cheap though
 432015-11-24T04:49:58  <gmaxwell> well they have to recieve the response but bandwidth is differentially valuable to them and me. :)
 442015-11-24T04:50:00  <phantomcircuit> both ends have equal bandwidth cost
 452015-11-24T04:50:08  <phantomcircuit> hmm true
 462015-11-24T04:50:14  <phantomcircuit> asymetric bandwidth value
 472015-11-24T04:50:17  <gmaxwell> phantomcircuit: I (and my partner) beg to differ!
 482015-11-24T04:50:47  <phantomcircuit> fyi btcwire is btcd
 492015-11-24T04:50:52  <gmaxwell> but I dunno that it's intentional, could just be some really ill advised anti-privacy attack, trying to bypass trickling by yanking the mempool super fast.
 502015-11-24T04:51:11  <jgarzik> might just be "real time network scope"
 512015-11-24T04:51:15  <gmaxwell> phantomcircuit: this isn't btcd; all the behavior is goofy, it's just someone using their p2p implementation.
 522015-11-24T04:51:17  <jgarzik> a new product
 532015-11-24T04:51:21  <phantomcircuit> ah
 542015-11-24T04:51:22  <tulip> nodes running on ADSL connections have a heavy impact from uploads, you could probably slow down most of those nodes downloading blocks by just requesting them to send you a few and ruining their ACK speed.
 552015-11-24T04:51:42  *** randy-waterhouse has quit IRC
 562015-11-24T04:51:44  <phantomcircuit> jgarzik, ?
 572015-11-24T04:51:45  <tulip> requesting they send you a few blocks.
 582015-11-24T04:51:51  <jgarzik> phantomcircuit, speculating
 592015-11-24T04:52:12  <jgarzik> phantomcircuit, conceivably it's someone testing a new product that monitors mempools across the network in real time
 602015-11-24T04:52:26  <gmaxwell> tulip: one evidence that it could be an attack is that I _believe_ the same party (amazon, btcwire) used to be requesting a single big over and over again in a loop.
 612015-11-24T04:52:28  <phantomcircuit> jgarzik, if so they're doing a shit job of it
 622015-11-24T04:52:41  <phantomcircuit> the mempool command adds enough latency that it would actually damage their measurements
 632015-11-24T04:52:42  <tulip> jgarzik: if they wanted to do that, why are they using multiple connections, and why request with mempool when you can see inv messages in real time?
 642015-11-24T04:53:18  <gmaxwell> I don't know if the block looper stopped generally, becuase jonas' bandwidth limiter kills them. :)
 652015-11-24T04:53:31  <gmaxwell> (as the block they were requesting was months old)
 662015-11-24T04:53:32  <jgarzik> tulip, 'mempool' shows you when transactions leave the mempool too...
 672015-11-24T04:54:02  <phantomcircuit> jgarzik, that doesn't tell you much of anything though
 682015-11-24T04:54:03  <jgarzik> we're all guessing, who knows
 692015-11-24T04:54:15  <tulip> sure.
 702015-11-24T04:54:17  <phantomcircuit> im thinking gmaxwell is right and it's just an attack
 712015-11-24T04:54:21  <gmaxwell> maybe my abuse report will result in hearing something.
 722015-11-24T04:54:30  <jgarzik> I think it's a DoS attack
 732015-11-24T04:54:55  <gmaxwell> I could certantly see this as a misguided monitoring attempt. But regardless, the motivations aren't that important.
 742015-11-24T04:54:58  <jgarzik> but it's a useful exercise to try and figure out weird, unlikely attacks ;p
 752015-11-24T04:55:19  <gmaxwell> I think before this discussion I hadn't connected that mempool bypasses trickling... good thing to figure that out.
 762015-11-24T04:55:47  <davec> fwiw, 0.2.0 is months old too, so it's likely whoever is up to it has been at it for a while
 772015-11-24T04:55:59  <gmaxwell> yet another gaping privacy hole we added to the protocol. :(
 782015-11-24T04:56:28  <gmaxwell> davec: yea, I've seen it before; it's bubbled up to the level of complaining about it here because it has persisted and changed addresses.
 792015-11-24T04:59:38  <tulip> jgarzik: you're the BIP author by the looks of things, would you have any qualms about removing it completely? do you know of any software which makes use of it?
 802015-11-24T05:00:42  <gmaxwell> tulip: or made whitelisted peers only, perhaps?
 812015-11-24T05:00:59  <tulip> that sounds like a better option.
 822015-11-24T05:01:23  <gmaxwell> bluematt: does the relay node client use the mempool message?
 832015-11-24T05:01:26  * gmaxwell greps logs
 842015-11-24T05:01:27  <jgarzik> tulip, scroll up ;p
 852015-11-24T05:02:04  <tulip> jgarzik: whoops, missed the first assertion for removal, sorry.
 862015-11-24T05:02:22  <phantomcircuit> gmaxwell, it does but i cant remember how
 872015-11-24T05:03:23  <tulip> wouldn't the relay node be on a whitelisted port anyway?
 882015-11-24T05:03:44  <davec> doesn't the testing framework use it?
 892015-11-24T05:04:07  *** raskolnnikov has joined #bitcoin-core-dev
 902015-11-24T05:04:17  <davec> (mempool that is).  It's been a while, but I seem to recall it being used by the block tester tool to compare mempool contents
 912015-11-24T05:04:28  <gmaxwell> it really shouldn't, we've complained about that before.
 922015-11-24T05:04:34  <gmaxwell> maybe it got fixed. :P
 932015-11-24T05:04:51  <gmaxwell> otherwise I dunno why all the recent mempool changes didn't make it fail all over itself.
 942015-11-24T05:04:55  <jgarzik> rpc-tests uses getrawmempool
 952015-11-24T05:06:48  <gmaxwell> my log data suggests that it's being used once per connection by some wallet or something.
 962015-11-24T05:06:58  <gmaxwell> hm. maybe.
 972015-11-24T05:07:40  <gmaxwell> http://0bin.net/paste/WPN3p8EyTg5QiXwe#oc16NOdpqju3WllP7+4FO4tbcphIwDQN5ZqHBv8bOux
 982015-11-24T05:08:21  <tulip> total count in the left column?
 992015-11-24T05:09:04  <gmaxwell> actually no, most of those are "/bitcoin-seeder:0.01/" "/Snoopy:0.2.1/"
1002015-11-24T05:09:27  <gmaxwell> ah so spv clients are doing a
1012015-11-24T05:09:27  <gmaxwell> 2015-11-24 02:17:45 received: filterload (1923 bytes) peer=4177
1022015-11-24T05:09:28  <gmaxwell> 2015-11-24 02:17:45 received: mempool (0 bytes) peer=4177
1032015-11-24T05:09:38  <gmaxwell> "/bitcoinj:0.13.2/MultiBitHD:0.1.4/"
1042015-11-24T05:09:54  <gmaxwell> but most of this stuff is ... things which are, uh, not in my interest to serve these responses to.
1052015-11-24T05:10:11  <tulip> bitcoin seeder does a mempool request? surely not
1062015-11-24T05:10:23  <gmaxwell> something claiming to be it does.
1072015-11-24T05:10:35  <tulip> yep.
1082015-11-24T05:11:53  <gmaxwell> anyways, if we don't kill it completely we should cap its size and find a way to fix the privacy leak. :(
1092015-11-24T05:11:57  <raskolnnikov> hello guys, I'm beginning work on a small research about SPV's transaction validation. Anyone has some 10 mins available to discuss a bit, I'm fairly lost inside the core src...
1102015-11-24T05:12:39  <gmaxwell> raskolnnikov: norm on IRC is to ask your question and pray for a response. :)
1112015-11-24T05:12:41  <davec> there is a definitely at least one bogus client out there claiming to be bitcoin-seeder
1122015-11-24T05:12:59  <tulip> there's lots claiming to be satoshi as well.
1132015-11-24T05:13:03  <gmaxwell> raskolnnikov: (and wait around long enough so people who aren't actively paying attention can answer)
1142015-11-24T05:13:05  <davec> I have noticed it not following the protocol
1152015-11-24T05:14:18  <gmaxwell> tulip: dunno who these things think they're fooling.  "/Satoshi:0.10.2/" ... "why are you sending me filterloads?"
1162015-11-24T05:14:28  <gmaxwell> I like the ones that are copy and paste errors.
1172015-11-24T05:14:38  <raskolnnikov> ha, I'm fairly new to IRC!
1182015-11-24T05:14:40  <raskolnnikov> thanks!
1192015-11-24T05:14:42  <davec> Yeah that's are funny
1202015-11-24T05:14:43  <gmaxwell> "Satoshi:0.11.1/"
1212015-11-24T05:15:03  <davec> those*
1222015-11-24T05:15:19  <davec> I saw a few misspelled ones too
1232015-11-24T05:15:24  <gmaxwell> davec: I'm amagining a person with a nose-and-glasses setup.
1242015-11-24T05:16:06  <tulip> they're easy enough to detect, but even easier to evade again.
1252015-11-24T05:16:51  <raskolnnikov> SPV's wallets provide a txn hash to full nodes whenever they want to verify if the transaction exists on a previous block and is unspent. where in the SRC code does bitcoin-core process and replies to these kind of requests?
1262015-11-24T05:17:36  <raskolnnikov> I'd like to log these requests from a test network to a log file
1272015-11-24T05:18:13  <gmaxwell> raskolnnikov: ah, you can't find that because that isn't how SPV wallets work.
1282015-11-24T05:19:29  <gmaxwell> raskolnnikov: if someone were to give you a transaction, they could also give you the proof that it was in a block.  So there is currently no facility in the protocol to just extract a proof for an arbritary transaction. (among other things this would require an index of all transactions, which bitcoin full nodes do not usually have)
1292015-11-24T05:21:01  <gmaxwell> raskolnnikov: instead you can download a block and filter the download to particular transactions or addresses, see MSG_FILTERED_BLOCK in the bitcoin core source code
1302015-11-24T05:21:21  <raskolnnikov> so there only is a request for the particular block (which I assume is extracted from some sort of block header, in the proof provided to the wallet) from the SPV to the full node
1312015-11-24T05:21:45  <raskolnnikov> and then the full node only provides the requested block back to the SPV?
1322015-11-24T05:22:18  <davec> a merkleblock (which is a filtered version) yes
1332015-11-24T05:22:42  <gmaxwell> raskolnnikov: it does not necessarily provide the whole block, the block can be filtered in way that proves the filtered subset is in there. See BIP37.
1342015-11-24T05:23:27  <gmaxwell> The gettxoutproof RPC in bitcoin core also provides an eqivilent message over the RPC.
1352015-11-24T05:24:02  *** randy-waterhouse has joined #bitcoin-core-dev
1362015-11-24T05:26:03  <raskolnnikov> and is there a way to single out the requests that come from SPV wallets? cause I assume that other full nodes will be requesting blocks or filtered blocks as well...
1372015-11-24T05:26:24  <raskolnnikov> cause those are the one I'd like to put on a log
1382015-11-24T05:26:31  <tulip> why?
1392015-11-24T05:26:54  <raskolnnikov> I'd like to measure the impact of having modified full nodes
1402015-11-24T05:27:07  <raskolnnikov> which "lie" back to the SPV wallet
1412015-11-24T05:28:34  <tulip> do you realise that BIP37 only allows lying by omission in most circumstances?
1422015-11-24T05:29:20  <gmaxwell> raskolnnikov: full nodes can freely omit transactions, thats one of the limitations in the design of BIP37.  There are other schemes which lack that limitation which are possible but have not been implemented yet.
1432015-11-24T05:30:00  <gmaxwell> raskolnnikov: as to your question, only SPV clients currently fetch filtered blocks.
1442015-11-24T05:33:09  *** tulip has quit IRC
1452015-11-24T05:33:44  *** tulip has joined #bitcoin-core-dev
1462015-11-24T05:41:49  <BlueMatt> gmaxwell: nope
1472015-11-24T05:42:31  <BlueMatt> gmaxwell: https://github.com/TheBlueMatt/RelayNode/issues/11
1482015-11-24T05:42:46  <BlueMatt> gmaxwell: there is even a whole rpcclient class thinggy that could be used
1492015-11-24T05:48:00  <gmaxwell> ::sigh:: seems like my laptop has a spurrious warning on mainnet:   "errors": "WARNING: check your network connection, 3 blocks received in the last 4 hours (24 expected)"
1502015-11-24T05:50:37  <gmaxwell> Anyone have a recent-ish count of how many distinct scriptpubkeys there are in the txout set?
1512015-11-24T05:51:22  <CodeShark> I used to keep a database of that but haven't been tracking that in a while
1522015-11-24T06:05:23  <GitHub82> [bitcoin] pstratem opened pull request #7087: [Net][WIP]Add -enforcenodebloom option (master...2015-11-23-bloom-disable) https://github.com/bitcoin/bitcoin/pull/7087
1532015-11-24T06:06:56  *** pigeons has quit IRC
1542015-11-24T06:07:51  *** randy-waterhouse has quit IRC
1552015-11-24T06:07:52  *** pigeons has joined #bitcoin-core-dev
1562015-11-24T06:08:14  *** pigeons is now known as Guest1328
1572015-11-24T06:53:28  *** arowser has quit IRC
1582015-11-24T06:53:55  *** arowser has joined #bitcoin-core-dev
1592015-11-24T06:56:00  *** moli has joined #bitcoin-core-dev
1602015-11-24T06:59:53  *** molly has quit IRC
1612015-11-24T07:01:14  *** molly has joined #bitcoin-core-dev
1622015-11-24T07:04:26  *** moli has quit IRC
1632015-11-24T07:14:48  *** guest234234 has quit IRC
1642015-11-24T07:15:21  *** dcousens has joined #bitcoin-core-dev
1652015-11-24T07:42:54  <GitHub191> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b0fc179ab87...f91e29fd4d0e
1662015-11-24T07:42:54  <GitHub191> bitcoin/master 3522f49 Wladimir J. van der Laan: http: add Boost 1.49 compatibility...
1672015-11-24T07:42:55  <GitHub191> bitcoin/master f91e29f Wladimir J. van der Laan: Merge pull request #7065...
1682015-11-24T07:43:00  <GitHub27> [bitcoin] laanwj closed pull request #7065: http: add Boost 1.49 compatibility (master...2015_11_httpserver_boost1_49) https://github.com/bitcoin/bitcoin/pull/7065
1692015-11-24T07:43:19  *** pkthebud has joined #bitcoin-core-dev
1702015-11-24T07:44:37  <pkthebud> Hello 😃
1712015-11-24T07:51:16  *** MarcoFalke has joined #bitcoin-core-dev
1722015-11-24T07:53:18  *** Ylbam has joined #bitcoin-core-dev
1732015-11-24T07:55:43  *** randy-waterhouse has joined #bitcoin-core-dev
1742015-11-24T08:12:35  *** Guyver2 has joined #bitcoin-core-dev
1752015-11-24T08:13:11  *** Thireus has quit IRC
1762015-11-24T08:24:57  <GitHub187> [bitcoin] MarcoFalke opened pull request #7088: [trivial] pull secp256k1subtree (master...MarcoFalke-2015-syncSecp256k1) https://github.com/bitcoin/bitcoin/pull/7088
1772015-11-24T08:30:08  <GitHub13> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f91e29fd4d0e...ed34e0577e8d
1782015-11-24T08:30:09  <GitHub13> bitcoin/master a0953cd MarcoFalke: [qa] python-bitcoinrpc is no longer a subtree...
1792015-11-24T08:30:09  <GitHub13> bitcoin/master ed34e05 Wladimir J. van der Laan: Merge pull request #7052...
1802015-11-24T08:30:19  <GitHub133> [bitcoin] laanwj closed pull request #7052: [qa] python-bitcoinrpc is no longer a subtree (master...MarcoFalke-2015-qaSubtree) https://github.com/bitcoin/bitcoin/pull/7052
1812015-11-24T08:31:27  <gmaxwell> Anyone know why zapwallettxes might use a lot more memory than a rescan?
1822015-11-24T08:32:23  <gmaxwell> my huge wallet test host (500k txn wallet) OOM killed on a zap, with about 24GB used--- where normally it uses about 15GB.
1832015-11-24T08:33:04  <GitHub69> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed34e0577e8d...b1fcdec68790
1842015-11-24T08:33:05  <GitHub69> bitcoin/master 2fcb849 fanquake: [doc][trivial] Remove source forge from Debian watch.
1852015-11-24T08:33:05  <GitHub69> bitcoin/master 70899d7 fanquake: [doc][trivial] Update Debian control description...
1862015-11-24T08:33:06  <GitHub69> bitcoin/master b1fcdec Wladimir J. van der Laan: Merge pull request #7042...
1872015-11-24T08:33:14  <GitHub56> [bitcoin] laanwj closed pull request #7042: [doc] Update Debian watch & control (master...update-debian) https://github.com/bitcoin/bitcoin/pull/7042
1882015-11-24T08:38:30  *** JackH has joined #bitcoin-core-dev
1892015-11-24T08:50:07  *** paveljanik has quit IRC
1902015-11-24T08:51:33  <GitHub105> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b1fcdec68790...72dccfc29dfc
1912015-11-24T08:51:34  <GitHub105> bitcoin/master 2aa49ce Luke Dashjr: Bugfix: Use unique autostart filenames on Linux for testnet/regtest
1922015-11-24T08:51:34  <GitHub105> bitcoin/master 72dccfc Wladimir J. van der Laan: Merge pull request #7045...
1932015-11-24T08:51:38  <GitHub148> [bitcoin] laanwj closed pull request #7045: Bugfix: Use unique autostart filenames on Linux for testnet/regtest (master...linux_autostart_unique) https://github.com/bitcoin/bitcoin/pull/7045
1942015-11-24T08:53:16  *** tulip has quit IRC
1952015-11-24T09:02:42  *** lightningbot has joined #bitcoin-core-dev
1962015-11-24T09:03:39  *** lightningbot has joined #bitcoin-core-dev
1972015-11-24T09:04:40  *** MarcoFalke has quit IRC
1982015-11-24T09:34:10  <GitHub146> [bitcoin] laanwj closed pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066
1992015-11-24T09:47:39  *** randy-waterhouse has quit IRC
2002015-11-24T09:53:26  <GitHub1> [bitcoin] laanwj closed pull request #6306: Prevent peer flooding inv request queue (redux) (master...no_duplicate_askfor) https://github.com/bitcoin/bitcoin/pull/6306
2012015-11-24T09:54:32  <GitHub98> [bitcoin] laanwj reopened pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066
2022015-11-24T09:55:57  <GitHub67> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/72dccfc29dfc...02a0f348c210
2032015-11-24T09:55:58  <GitHub67> bitcoin/master 5c2fd38 Pavel Janík: Add missing "blocktime" description to listtransactions help, fix formatting.
2042015-11-24T09:55:58  <GitHub67> bitcoin/master 02a0f34 Wladimir J. van der Laan: Merge pull request #7066...
2052015-11-24T09:56:07  <GitHub135> [bitcoin] laanwj closed pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066
2062015-11-24T10:09:20  <phantomcircuit> it's kind of comical how much more productive i am without video games
2072015-11-24T10:10:03  <phantomcircuit> gmaxwell, iirc zapwallettxs keeps two walletdb objects open, so will presumably use a minimum of double the memory
2082015-11-24T10:11:13  *** Thireus has joined #bitcoin-core-dev
2092015-11-24T10:24:33  *** randy-waterhouse has joined #bitcoin-core-dev
2102015-11-24T10:28:57  <sipa> phantomcircuit: you should sold *all* your gpus after the gpu mining era was over
2112015-11-24T10:29:41  <phantomcircuit> sipa, heh
2122015-11-24T10:45:52  <wumpus> heh I stopped playing video games at the same time I stopped striving to be a game developer. Just lost interest with modern games and the PC upgrade treadmill
2132015-11-24T10:49:49  *** MarcoFalke has joined #bitcoin-core-dev
2142015-11-24T10:51:15  *** d_t has quit IRC
2152015-11-24T10:52:23  <phantomcircuit> wumpus, it helps when you're using old 7970s from a mining farm
2162015-11-24T10:53:42  <phantomcircuit> wumpus, need anything else on 7087 ?
2172015-11-24T10:55:23  <wumpus> no, looks good to me now
2182015-11-24T11:03:43  <midnightmagic> wumpus: independent game devs can make it these days. A friend of mine is in the middle of doing it, he lives in norway right now.
2192015-11-24T11:05:09  <wumpus> midnightmagic: yes that still sounds kind of fun
2202015-11-24T11:07:10  <midnightmagic> definitely an appetite for cleverness that's within the grasp of small teams, it seems. and ios can be done by one or two people. retro gaming scene is hot.
2212015-11-24T11:07:44  <MarcoFalke> wumups, not sure we should silently "ignore" negative values from GetArg()?
2222015-11-24T11:08:03  *** jl2012 has joined #bitcoin-core-dev
2232015-11-24T11:08:03  *** jl2012_ has quit IRC
2242015-11-24T11:08:13  <MarcoFalke> is done very rarely, though.
2252015-11-24T11:08:53  <MarcoFalke> *Sanitization is done very rarely, though.
2262015-11-24T11:09:05  <MarcoFalke> * wumpus,
2272015-11-24T11:12:06  <MarcoFalke> We need to collect all accepted config args and their valid range. Also warn about unknown config args.
2282015-11-24T11:22:24  <wumpus> MarcoFalke: definitely not ignore
2292015-11-24T11:23:30  <wumpus> yea, we're ignoring a lot of command-line issues, I have a very old issue about this https://github.com/bitcoin/bitcoin/issues/1044
2302015-11-24T11:27:38  <phantomcircuit> gmaxwell, did you see my PR for 7082 ?
2312015-11-24T11:29:33  *** randy-waterhouse has quit IRC
2322015-11-24T11:30:08  <MarcoFalke> Changed it to uint_ and dropped the < 0 check like you suggested.
2332015-11-24T11:30:36  <MarcoFalke> Now, we get funny errors like Error: -maxmempool must be at least 1.84467e+16 MB, at least.
2342015-11-24T11:30:43  <wumpus> so a negative value is an explicit error now?
2352015-11-24T11:30:57  <wumpus> eh, that's definitely not an improvemnt
2362015-11-24T11:31:15  <wumpus> just leave it as is then
2372015-11-24T11:31:27  <MarcoFalke> I like it uint ;)
2382015-11-24T11:31:52  <wumpus> sure, uint makes sense, but that's only acceptable if you avoid the user from passing negative values and causing overflows
2392015-11-24T11:32:47  <wumpus> (which the old code did, so probably my suggestion was just wrong)
2402015-11-24T11:33:11  <MarcoFalke> Usually -1 means "just make it large enogh that I don't have to care about it"
2412015-11-24T11:33:54  <wumpus> it just looked weird to compare to both 0 and that limit value, a typical developer trap 'hey, this could be simpler...'
2422015-11-24T11:34:11  <wumpus> which is fine if you handle it explicitly, don't rely on integer overflow
2432015-11-24T11:35:50  <gmaxwell> phantomcircuit: thanks, I wouldn't have.
2442015-11-24T11:39:33  <gmaxwell> phantomcircuit: you dropped the node network compare, otherwise your PR is just a reordering, and a fine one, go fix that.
2452015-11-24T11:42:31  *** randy-waterhouse has joined #bitcoin-core-dev
2462015-11-24T11:45:38  <phantomcircuit> gmaxwell, ha derp so i did
2472015-11-24T11:49:02  <phantomcircuit> gmaxwell, ok there you go
2482015-11-24T11:52:52  *** MarcoFalke has quit IRC
2492015-11-24T11:57:52  *** randy-waterhouse has quit IRC
2502015-11-24T12:33:44  *** MarcoFalke has joined #bitcoin-core-dev
2512015-11-24T12:52:37  <MarcoFalke> Restored original behavior: "Error: -maxmempool must be at least -120 MB
2522015-11-24T12:52:38  <MarcoFalke> "
2532015-11-24T12:55:52  <wumpus> ok..
2542015-11-24T12:57:30  *** Guest1328 is now known as pigeons
2552015-11-24T12:58:01  <wumpus> we probably want to check -limitdescendantsize against 0 as well, or can it be usefully negative?
2562015-11-24T12:59:50  <sdaftuar> wumpus: limitdescendantsize cannot be usefully negative
2572015-11-24T13:00:01  <wumpus> in other places we assign the result to a size_t
2582015-11-24T13:01:14  <wumpus> type-safe argument parsing would be great to have at some point in the future, bit of a  mish-mash now, but checking that it is >=0 at least prevents this from being an issue
2592015-11-24T13:04:11  <MarcoFalke> Is this framework sipa mentions ready for copy & paste? https://github.com/bitcoin/bitcoin/pull/4194#issuecomment-44521490
2602015-11-24T13:04:53  <wumpus> I doubt it
2612015-11-24T13:05:31  <sipa> i started writing that a long time ago, but never finished it
2622015-11-24T13:05:36  <wumpus> although the approach is a lot saner than what we have now
2632015-11-24T13:07:10  <wumpus> I think it's complicated by various options that, in turn, determine each other's ranges. But even basic type and sane-range checking with a consistent system would be  a way forward.
2642015-11-24T13:08:40  <wumpus> and at least having base argument parsing in one place so that it can flag unknown arguments
2652015-11-24T13:10:02  *** MarcoFalke has quit IRC
2662015-11-24T13:10:39  *** MarcoFalke has joined #bitcoin-core-dev
2672015-11-24T13:24:41  *** MarcoFalke has quit IRC
2682015-11-24T13:25:25  *** MarcoFalke has joined #bitcoin-core-dev
2692015-11-24T13:37:43  *** ParadoxSpiral has joined #bitcoin-core-dev
2702015-11-24T13:43:46  *** dcousens has quit IRC
2712015-11-24T13:44:22  *** dcousens has joined #bitcoin-core-dev
2722015-11-24T13:51:18  *** MarcoFalke has quit IRC
2732015-11-24T14:36:51  <GitHub197> [bitcoin] petertodd opened pull request #7090: Connect to Tor hidden services by default (master...2015-11-onion-by-default) https://github.com/bitcoin/bitcoin/pull/7090
2742015-11-24T15:02:29  <GitHub18> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/02a0f348c210...b19fe277dd62
2752015-11-24T15:02:30  <GitHub18> bitcoin/master 4846543 tulip: Move time data log print to 'net' category to reduce log noise
2762015-11-24T15:02:30  *** davec has quit IRC
2772015-11-24T15:02:30  <GitHub18> bitcoin/master b19fe27 Wladimir J. van der Laan: Merge pull request #7075...
2782015-11-24T15:02:37  <GitHub64> [bitcoin] laanwj closed pull request #7075: [Trivial] Move time data log print to 'net' category to reduce noise (master...no-time-offset-logging) https://github.com/bitcoin/bitcoin/pull/7075
2792015-11-24T15:02:51  *** davec has joined #bitcoin-core-dev
2802015-11-24T15:07:19  <GitHub149> [bitcoin] jtimon opened pull request #7091: Consensus build package (master...consensus-build) https://github.com/bitcoin/bitcoin/pull/7091
2812015-11-24T15:40:03  *** Thireus has quit IRC
2822015-11-24T15:56:59  *** Thireus has joined #bitcoin-core-dev
2832015-11-24T16:08:08  *** MarcoFalke has joined #bitcoin-core-dev
2842015-11-24T16:29:44  *** dcousens has quit IRC
2852015-11-24T16:46:42  <MarcoFalke> travis is only running 3 jobs in parallel instead of 5, what it used to be...
2862015-11-24T17:06:04  *** Thireus has quit IRC
2872015-11-24T17:13:34  *** d_t has joined #bitcoin-core-dev
2882015-11-24T17:32:56  *** paveljanik has joined #bitcoin-core-dev
2892015-11-24T17:45:38  *** ParadoxSpiral_ has joined #bitcoin-core-dev
2902015-11-24T17:48:40  *** ParadoxSpiral has quit IRC
2912015-11-24T19:44:43  *** MarcoFalke has quit IRC
2922015-11-24T19:46:10  <phantomcircuit> sipa, huh ActivateBestChain seems to be super slow when it's able to connect a large number of blocks all at once
2932015-11-24T19:51:30  <sipa> phantomcircuit: it is, it should cache things
2942015-11-24T20:08:25  <cfields_> jonasschnelli: ping. regarding osx perms, looks to me like perms are correct in gitian, but they're wrong in the created image
2952015-11-24T20:08:35  <cfields_> jtimon: will have a look
2962015-11-24T20:16:39  *** randy-waterhouse has joined #bitcoin-core-dev
2972015-11-24T20:32:10  *** Thireus has joined #bitcoin-core-dev
2982015-11-24T20:33:39  <jtimon> cfields_: awesome, for some reason I haven't found out yet travis doesn't like it, even if it built locally yesterday
2992015-11-24T20:59:10  <jonasschnelli> cfields_: so it could be a issue created by the dmg tool?
3002015-11-24T21:01:16  *** cocoBTC has joined #bitcoin-core-dev
3012015-11-24T21:03:46  <cfields_> jtimon: you need $()
3022015-11-24T21:04:19  <cfields_> jonasschnelli: yea, looks that way to me. testing a fix now
3032015-11-24T21:05:00  <jonasschnelli> cfields_ : nice! Thanks for looking at it. It's an ugly OSX bug that we should solve in 0.12 and backport.
3042015-11-24T21:05:22  <cfields_> jonasschnelli: np. I'm still trying to figure out why it's not an issue for me
3052015-11-24T21:13:36  <cfields_> jonasschnelli: yea, that fixes
3062015-11-24T21:13:50  *** raedah has joined #bitcoin-core-dev
3072015-11-24T21:14:30  <cfields_> fixes the perms, anyway. I can't reproduce, but i assume setting the dir to 0755 is enough
3082015-11-24T21:18:45  <GitHub91> [bitcoin] theuni opened 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
3092015-11-24T21:27:24  <jonasschnelli> cfields_: super. Thanks. Testing tomorrow (in about 10h).
3102015-11-24T21:27:47  <cfields_> jonasschnelli: great, thanks
3112015-11-24T21:38:28  *** Guyver2_ has joined #bitcoin-core-dev
3122015-11-24T21:44:14  <phantomcircuit> would anybody be opposed to adding a last ditch peer discovery mechanism (even after trying the hard coded nodes) of "scan the internetz"
3132015-11-24T21:45:29  <sipa> phantomcircuit: as in: try random IPs? :o
3142015-11-24T21:46:51  <jtimon> cfields_: this should fix it? https://github.com/bitcoin/bitcoin/commit/164870c3f43f09330611fa939b7ae7fe468c1cf1
3152015-11-24T21:47:24  <jtimon> cfields_: in any case, I'm more interested in your opinion than making travis happy at this point
3162015-11-24T21:48:00  <cfields_> jtimon: from the looks, i believe that now involves building each object 3 times
3172015-11-24T21:48:12  <jtimon> how so?
3182015-11-24T21:48:40  <jtimon> one for libconsensus and one for the rest, no?
3192015-11-24T21:48:51  <jtimon> like before, no?
3202015-11-24T21:49:22  <cfields_> ah sorry, misread. yes.
3212015-11-24T21:49:44  * jtimon naively let himself think he was saving one build
3222015-11-24T21:50:07  <cfields_> jtimon: to save the build, you'd have to add the objects rather than the sources
3232015-11-24T21:50:22  <cfields_> don't think libtool will let you do that, though
3242015-11-24T21:51:04  <jtimon> never mind, I was expecting you to maybe complain about https://github.com/jtimon/bitcoin/commit/083e1344f7162d516ffcf2bb30622b28767e415e
3252015-11-24T21:51:39  <jtimon> or https://github.com/jtimon/bitcoin/commit/f37ff9b61375f8f667f17d529b6422e9c2c353c4 (it makes bitcoin-tx a little bit bigger)
3262015-11-24T21:52:02  <jtimon> not much bigger though
3272015-11-24T21:52:41  <cfields_> jtimon: yes, i'm not a fan of that. I see your reasoning, though.
3282015-11-24T21:52:43  <jtimon> but it signals the intend to put verifyBlock in the consensus package, which bitcoin-tx will still have to depend on
3292015-11-24T21:53:04  <jtimon> not a fan of which part?
3302015-11-24T21:53:28  <cfields_> breaking crypto out of its contained unit
3312015-11-24T21:54:43  <jtimon> I don't care much about the crypto part, it is currently well encapsulated and protected in the same way it would be in the consensus package, I guess we can leave that for the time when libconsensus gets its own repo (after exposing verifyblock)
3322015-11-24T21:56:27  <jtimon> any concerns about libconsensus depending on hmac_sha256 (without using it) by depending on the whole crypto package instead of all files but one?
3332015-11-24T21:57:31  <jtimon> that way we can say libconsensus contains the libsecp256k1, crypto and consensus packages
3342015-11-24T21:58:48  <jtimon> forget about that for now, I will update the branch without unifying crypto but in a way that I still like it and ask again
3352015-11-24T21:58:57  <jtimon> what about https://github.com/jtimon/bitcoin/commit/f37ff9b61375f8f667f17d529b6422e9c2c353c4 ?
3362015-11-24T21:58:58  <phantomcircuit> sipa, yeah and why not?
3372015-11-24T22:00:00  <sipa> phantomcircuit: nobody implemented it :)
3382015-11-24T22:00:05  <GitHub147> [bitcoin] gmaxwell opened pull request #7093: Address mempool information leak and resource wasting attacks. (master...mempool_infoleak) https://github.com/bitcoin/bitcoin/pull/7093
3392015-11-24T22:00:06  <sipa> phantomcircuit: it's very rarely an issue
3402015-11-24T22:05:49  *** ParadoxSpiral_ has quit IRC
3412015-11-24T22:05:51  <gmaxwell> I think I fixed the mempool dos attack/information leak problem.
3422015-11-24T22:06:49  *** randy-waterhouse has quit IRC
3432015-11-24T22:06:49  <gmaxwell> phantomcircuit: doing that pisses off network operators and gets your software firewalled off. Also we have such a low nodecount that it's not a very effective mechenism.
3442015-11-24T22:07:24  <phantomcircuit> gmaxwell, yes i was thinking of it as something that wouldn't run for at least 30 minutes
3452015-11-24T22:07:29  <phantomcircuit> and would be pretty slow even then
3462015-11-24T22:08:04  <gmaxwell> phantomcircuit: slow = never find peers. :P
3472015-11-24T22:08:19  <phantomcircuit> gmaxwell, "slowish"
3482015-11-24T22:08:23  <gmaxwell> phantomcircuit: go look at my candidate mempool attack fix
3492015-11-24T22:08:46  <phantomcircuit> gmaxwell, in about an hour i have to go move my car now...
3502015-11-24T22:08:58  <phantomcircuit> who does street sweeping at 3pm?
3512015-11-24T22:16:53  * jgarzik reads
3522015-11-24T22:17:02  * sipa sleeps
3532015-11-24T22:19:52  <cfields_> jtimon: how about something more like this: http://pastebin.com/raw.php?i=JBqjPYAr ?
3542015-11-24T22:20:13  <cfields_> (it's a quick hack, the other targets need to be updated, i only changed bitcoind)
3552015-11-24T22:22:12  <gmaxwell> cfields_: if you get a chance, https://github.com/bitcoin/secp256k1/pull/356#issuecomment-156839307
3562015-11-24T22:22:26  <cfields_> that creates an internal helper lib that the other libs include. means everything's only built ones. and provides a clear distinction between what's consensus and what isn't
3572015-11-24T22:23:03  <jtimon> we still remove the files from util and common, I think I get your point, putting it all closer to the libconsensus stuff
3582015-11-24T22:23:45  <jtimon> should I put the .h directly in libbitcoinconsensusint_la_SOURCES?
3592015-11-24T22:24:08  <jtimon> btw, what does the int stand for?
3602015-11-24T22:24:10  <cfields_> jtimon: just an idea, i haven't really thought it through
3612015-11-24T22:24:19  <cfields_> internal. again, just a quick hack
3622015-11-24T22:24:58  <cfields_> gmaxwell: i'm having trouble parsing that too. You just want openssl optional, and only add the comparison tests if it's found/enabled ?
3632015-11-24T22:25:54  <jtimon> cfields_: I mean, the way I see it, this is mostly levearaing work that is already done, just make it harder or more obvious for contributors to break the existing encapsulation
3642015-11-24T22:27:16  <cfields_> jtimon: yea. that way, each lib-friendly module is built with its own flags. We can control include paths that way, making it not possible to accidentally add unsafe headers/objects
3652015-11-24T22:28:25  <jtimon> cfields_: one secondary goal is putting together whatever we plan to take out with libconsensus' subtree once it is complete
3662015-11-24T22:28:34  <jtimon> but that can wait
3672015-11-24T22:28:44  <gmaxwell> cfields_: Yes, it should be optional, and be switchable off.  OpenSSL is actually a constant irritation for me when testing on random systems, because it throws a zillion and one valgrind errors (openssl is not valgrind clean unless compiled to be so)
3682015-11-24T22:28:49  <cfields_> gmaxwell: ok, that's already how it works. Looks like you just want the option to explicitly disable openssl rather than using it if it's found?
3692015-11-24T22:29:00  <gmaxwell> cfields_: yes.
3702015-11-24T22:29:03  <cfields_> roger
3712015-11-24T22:30:03  <jtimon> cfields_: got it, so no BITCOIN_CONSENSUS_H, put the .h and the .cpp together directly
3722015-11-24T22:30:23  <jtimon> cfields_: like in the crypto package
3732015-11-24T22:30:42  <cfields_> jtimon: i have no real preference there
3742015-11-24T22:31:02  <jtimon> cfields_: well, me neither, so...
3752015-11-24T22:31:19  <gmaxwell> cfields_: interested in running coverity again? we haven't run it in a while. I added directory masks for our new directories under src.  (If you're no longer setup to run it, I'll run it... I just don't want to stomp on you if you are. Path changes can make the reports somewhat less useful if you bounce between systems that its run on)
3762015-11-24T22:32:04  <jtimon> I think I'll just copy the ways of crypto then
3772015-11-24T22:32:42  <cfields_> gmaxwell: go for it, i haven't messed with it in a while. I poke at it with clang tools now and then, i'd be curious to see how the results differ
3782015-11-24T22:33:36  <gmaxwell> cfields_: mostly I wanted to get a run against current libsecp256k1. :)
3792015-11-24T22:33:51  <cfields_> heh
3802015-11-24T22:34:08  <cfields_> gmaxwell: while you're at it, make sure to throw clang-tidy at it. It's turned up some useful stuff
3812015-11-24T22:34:24  <jtimon> but the main question...is it ok to add primitives/block, arith_uint256, version.h, serialize.h and company to the consensus package (and therefore to bitcoin-tx)?
3822015-11-24T22:37:03  <jtimon> s/"version.h, serialize.h"/"consensus/params.h, consensus/validation.h"/
3832015-11-24T22:40:53  <cfields_> jtimon: the headers are only listed to keep track of what files go into the tarball. they're not actually used in depenency resolution
3842015-11-24T22:41:00  <cfields_> so just do whatever makes it the most clear
3852015-11-24T22:42:18  <jtimon> cfields_: so nothing can fail in the build by .h files having circular package dependencies and stuff? what a pity
3862015-11-24T22:42:35  <cfields_> jtimon: i don't believe so. Need to control it with paths.
3872015-11-24T22:42:47  <jtimon> I think it still makes it clearer
3882015-11-24T22:44:20  <jtimon> currently https://github.com/libbitcoin/libbitcoin-consensus/tree/master/src/clone is more clear than libbitcoinconsensus_la_SOURCES
3892015-11-24T22:45:49  <jtimon> thanks for the feedback, I will force push an updated version
3902015-11-24T22:46:00  <cfields_> np
3912015-11-24T22:48:30  <jtimon> cfields_: could you push your raw patch somewhere on github for convenience?
3922015-11-24T22:49:00  <cfields_> jtimon: will do in a few min, that's mixed in with my current branch
3932015-11-24T22:49:22  <jtimon> oh, I see, no hurry
3942015-11-24T22:50:07  <jtimon> hehe, I wasn't sure if it was on top of master or one of my commits
3952015-11-24T22:51:27  <cfields_> nah, master
3962015-11-24T22:52:21  <jtimon> oh, never mind then
3972015-11-24T23:03:18  <cfields_> ok
3982015-11-24T23:03:37  *** Guyver2 has quit IRC
3992015-11-24T23:03:39  *** Guyver2_ is now known as Guyver2
4002015-11-24T23:22:54  <phantomcircuit> gmaxwell, we're keeping travis very busy
4012015-11-24T23:24:44  *** belcher has joined #bitcoin-core-dev