1 2015-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 ?
  2 2015-11-24T00:10:25  *** Guest23423 has joined #bitcoin-core-dev
  3 2015-11-24T00:13:38  *** guest234234 has quit IRC
  4 2015-11-24T00:23:12  *** Guest23423 has quit IRC
  5 2015-11-24T00:32:21  *** skyraider has quit IRC
  6 2015-11-24T01:14:29  *** Ylbam has quit IRC
  7 2015-11-24T01:17:17  *** guest234234 has joined #bitcoin-core-dev
  8 2015-11-24T01:29:16  *** JackH has quit IRC
  9 2015-11-24T01:42:02  *** parazyd has left #bitcoin-core-dev
 10 2015-11-24T02:48:14  *** d_t has quit IRC
 11 2015-11-24T02:48:37  *** d_t has joined #bitcoin-core-dev
 12 2015-11-24T03:07:22  *** jl2012 has quit IRC
 13 2015-11-24T03:07:26  *** jl2012_ has joined #bitcoin-core-dev
 14 2015-11-24T03:08:24  *** belcher has quit IRC
 15 2015-11-24T03:16:20  *** randy-waterhouse has quit IRC
 16 2015-11-24T03:16:43  *** randy-waterhouse has joined #bitcoin-core-dev
 17 2015-11-24T03:24:32  *** go1111111 has quit IRC
 18 2015-11-24T03:38:28  *** go1111111 has joined #bitcoin-core-dev
 19 2015-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?
 20 2015-11-24T04:35:03  <jgarzik> I've been inclined to disable mempool by default for months
 21 2015-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.
 22 2015-11-24T04:36:01  <gmaxwell> If it's also spamming you, feel free to report to https://aws.amazon.com/forms/report-abuse
 23 2015-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.
 24 2015-11-24T04:38:01  <tulip> gmaxwell: yes, multiple connections announced as /btcwire:0.2.0/.
 25 2015-11-24T04:38:42  <gmaxwell> tulip: yea, I have one node with four, one with two, one with one.
 26 2015-11-24T04:38:51  <gmaxwell> I haven't checked the others yet.
 27 2015-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.
 28 2015-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 :(
 29 2015-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.
 30 2015-11-24T04:42:24  *** wangchun has quit IRC
 31 2015-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.
 32 2015-11-24T04:43:00  <tulip> on second thought, it's probably just an incentive to stay connected to every peer permanently.
 33 2015-11-24T04:43:46  <gmaxwell> tulip: they'd use a lot less bandwidth that way.
 34 2015-11-24T04:44:23  <gmaxwell> I mean this current mempool sucker is using 10x the bandwidth of any of my other peers.
 35 2015-11-24T04:45:13  <jgarzik> We already account traffic up & down.  You'd think this could be dealt with through generic resource accounting.
 36 2015-11-24T04:45:58  <tulip> modified clarks law: any sufficiently buggy software is indistinguishable from denial of service.
 37 2015-11-24T04:47:36  *** randy-waterhouse has quit IRC
 38 2015-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.
 39 2015-11-24T04:48:52  <phantomcircuit> jgarzik, i assume that the mempool infinite loop is some kind of poorly thought out sybil attack
 40 2015-11-24T04:48:52  *** randy-waterhouse has joined #bitcoin-core-dev
 41 2015-11-24T04:49:15  <jgarzik> phantomcircuit, plain ole asymmetric DoS
 42 2015-11-24T04:49:42  <phantomcircuit> jgarzik, responding to the mempool command is actually very cheap though
 43 2015-11-24T04:49:58  <gmaxwell> well they have to recieve the response but bandwidth is differentially valuable to them and me. :)
 44 2015-11-24T04:50:00  <phantomcircuit> both ends have equal bandwidth cost
 45 2015-11-24T04:50:08  <phantomcircuit> hmm true
 46 2015-11-24T04:50:14  <phantomcircuit> asymetric bandwidth value
 47 2015-11-24T04:50:17  <gmaxwell> phantomcircuit: I (and my partner) beg to differ!
 48 2015-11-24T04:50:47  <phantomcircuit> fyi btcwire is btcd
 49 2015-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.
 50 2015-11-24T04:51:11  <jgarzik> might just be "real time network scope"
 51 2015-11-24T04:51:15  <gmaxwell> phantomcircuit: this isn't btcd; all the behavior is goofy, it's just someone using their p2p implementation.
 52 2015-11-24T04:51:17  <jgarzik> a new product
 53 2015-11-24T04:51:21  <phantomcircuit> ah
 54 2015-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.
 55 2015-11-24T04:51:42  *** randy-waterhouse has quit IRC
 56 2015-11-24T04:51:44  <phantomcircuit> jgarzik, ?
 57 2015-11-24T04:51:45  <tulip> requesting they send you a few blocks.
 58 2015-11-24T04:51:51  <jgarzik> phantomcircuit, speculating
 59 2015-11-24T04:52:12  <jgarzik> phantomcircuit, conceivably it's someone testing a new product that monitors mempools across the network in real time
 60 2015-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.
 61 2015-11-24T04:52:28  <phantomcircuit> jgarzik, if so they're doing a shit job of it
 62 2015-11-24T04:52:41  <phantomcircuit> the mempool command adds enough latency that it would actually damage their measurements
 63 2015-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?
 64 2015-11-24T04:53:18  <gmaxwell> I don't know if the block looper stopped generally, becuase jonas' bandwidth limiter kills them. :)
 65 2015-11-24T04:53:31  <gmaxwell> (as the block they were requesting was months old)
 66 2015-11-24T04:53:32  <jgarzik> tulip, 'mempool' shows you when transactions leave the mempool too...
 67 2015-11-24T04:54:02  <phantomcircuit> jgarzik, that doesn't tell you much of anything though
 68 2015-11-24T04:54:03  <jgarzik> we're all guessing, who knows
 69 2015-11-24T04:54:15  <tulip> sure.
 70 2015-11-24T04:54:17  <phantomcircuit> im thinking gmaxwell is right and it's just an attack
 71 2015-11-24T04:54:21  <gmaxwell> maybe my abuse report will result in hearing something.
 72 2015-11-24T04:54:30  <jgarzik> I think it's a DoS attack
 73 2015-11-24T04:54:55  <gmaxwell> I could certantly see this as a misguided monitoring attempt. But regardless, the motivations aren't that important.
 74 2015-11-24T04:54:58  <jgarzik> but it's a useful exercise to try and figure out weird, unlikely attacks ;p
 75 2015-11-24T04:55:19  <gmaxwell> I think before this discussion I hadn't connected that mempool bypasses trickling... good thing to figure that out.
 76 2015-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
 77 2015-11-24T04:55:59  <gmaxwell> yet another gaping privacy hole we added to the protocol. :(
 78 2015-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.
 79 2015-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?
 80 2015-11-24T05:00:42  <gmaxwell> tulip: or made whitelisted peers only, perhaps?
 81 2015-11-24T05:00:59  <tulip> that sounds like a better option.
 82 2015-11-24T05:01:23  <gmaxwell> bluematt: does the relay node client use the mempool message?
 83 2015-11-24T05:01:26  * gmaxwell greps logs
 84 2015-11-24T05:01:27  <jgarzik> tulip, scroll up ;p
 85 2015-11-24T05:02:04  <tulip> jgarzik: whoops, missed the first assertion for removal, sorry.
 86 2015-11-24T05:02:22  <phantomcircuit> gmaxwell, it does but i cant remember how
 87 2015-11-24T05:03:23  <tulip> wouldn't the relay node be on a whitelisted port anyway?
 88 2015-11-24T05:03:44  <davec> doesn't the testing framework use it?
 89 2015-11-24T05:04:07  *** raskolnnikov has joined #bitcoin-core-dev
 90 2015-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
 91 2015-11-24T05:04:28  <gmaxwell> it really shouldn't, we've complained about that before.
 92 2015-11-24T05:04:34  <gmaxwell> maybe it got fixed. :P
 93 2015-11-24T05:04:51  <gmaxwell> otherwise I dunno why all the recent mempool changes didn't make it fail all over itself.
 94 2015-11-24T05:04:55  <jgarzik> rpc-tests uses getrawmempool
 95 2015-11-24T05:06:48  <gmaxwell> my log data suggests that it's being used once per connection by some wallet or something.
 96 2015-11-24T05:06:58  <gmaxwell> hm. maybe.
 97 2015-11-24T05:07:40  <gmaxwell> http://0bin.net/paste/WPN3p8EyTg5QiXwe#oc16NOdpqju3WllP7+4FO4tbcphIwDQN5ZqHBv8bOux
 98 2015-11-24T05:08:21  <tulip> total count in the left column?
 99 2015-11-24T05:09:04  <gmaxwell> actually no, most of those are "/bitcoin-seeder:0.01/" "/Snoopy:0.2.1/"
100 2015-11-24T05:09:27  <gmaxwell> ah so spv clients are doing a
101 2015-11-24T05:09:27  <gmaxwell> 2015-11-24 02:17:45 received: filterload (1923 bytes) peer=4177
102 2015-11-24T05:09:28  <gmaxwell> 2015-11-24 02:17:45 received: mempool (0 bytes) peer=4177
103 2015-11-24T05:09:38  <gmaxwell> "/bitcoinj:0.13.2/MultiBitHD:0.1.4/"
104 2015-11-24T05:09:54  <gmaxwell> but most of this stuff is ... things which are, uh, not in my interest to serve these responses to.
105 2015-11-24T05:10:11  <tulip> bitcoin seeder does a mempool request? surely not
106 2015-11-24T05:10:23  <gmaxwell> something claiming to be it does.
107 2015-11-24T05:10:35  <tulip> yep.
108 2015-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. :(
109 2015-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...
110 2015-11-24T05:12:39  <gmaxwell> raskolnnikov: norm on IRC is to ask your question and pray for a response. :)
111 2015-11-24T05:12:41  <davec> there is a definitely at least one bogus client out there claiming to be bitcoin-seeder
112 2015-11-24T05:12:59  <tulip> there's lots claiming to be satoshi as well.
113 2015-11-24T05:13:03  <gmaxwell> raskolnnikov: (and wait around long enough so people who aren't actively paying attention can answer)
114 2015-11-24T05:13:05  <davec> I have noticed it not following the protocol
115 2015-11-24T05:14:18  <gmaxwell> tulip: dunno who these things think they're fooling.  "/Satoshi:0.10.2/" ... "why are you sending me filterloads?"
116 2015-11-24T05:14:28  <gmaxwell> I like the ones that are copy and paste errors.
117 2015-11-24T05:14:38  <raskolnnikov> ha, I'm fairly new to IRC!
118 2015-11-24T05:14:40  <raskolnnikov> thanks!
119 2015-11-24T05:14:42  <davec> Yeah that's are funny
120 2015-11-24T05:14:43  <gmaxwell> "Satoshi:0.11.1/"
121 2015-11-24T05:15:03  <davec> those*
122 2015-11-24T05:15:19  <davec> I saw a few misspelled ones too
123 2015-11-24T05:15:24  <gmaxwell> davec: I'm amagining a person with a nose-and-glasses setup.
124 2015-11-24T05:16:06  <tulip> they're easy enough to detect, but even easier to evade again.
125 2015-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?
126 2015-11-24T05:17:36  <raskolnnikov> I'd like to log these requests from a test network to a log file
127 2015-11-24T05:18:13  <gmaxwell> raskolnnikov: ah, you can't find that because that isn't how SPV wallets work.
128 2015-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)
129 2015-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
130 2015-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
131 2015-11-24T05:21:45  <raskolnnikov> and then the full node only provides the requested block back to the SPV?
132 2015-11-24T05:22:18  <davec> a merkleblock (which is a filtered version) yes
133 2015-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.
134 2015-11-24T05:23:27  <gmaxwell> The gettxoutproof RPC in bitcoin core also provides an eqivilent message over the RPC.
135 2015-11-24T05:24:02  *** randy-waterhouse has joined #bitcoin-core-dev
136 2015-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...
137 2015-11-24T05:26:24  <raskolnnikov> cause those are the one I'd like to put on a log
138 2015-11-24T05:26:31  <tulip> why?
139 2015-11-24T05:26:54  <raskolnnikov> I'd like to measure the impact of having modified full nodes
140 2015-11-24T05:27:07  <raskolnnikov> which "lie" back to the SPV wallet
141 2015-11-24T05:28:34  <tulip> do you realise that BIP37 only allows lying by omission in most circumstances?
142 2015-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.
143 2015-11-24T05:30:00  <gmaxwell> raskolnnikov: as to your question, only SPV clients currently fetch filtered blocks.
144 2015-11-24T05:33:09  *** tulip has quit IRC
145 2015-11-24T05:33:44  *** tulip has joined #bitcoin-core-dev
146 2015-11-24T05:41:49  <BlueMatt> gmaxwell: nope
147 2015-11-24T05:42:31  <BlueMatt> gmaxwell: https://github.com/TheBlueMatt/RelayNode/issues/11
148 2015-11-24T05:42:46  <BlueMatt> gmaxwell: there is even a whole rpcclient class thinggy that could be used
149 2015-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)"
150 2015-11-24T05:50:37  <gmaxwell> Anyone have a recent-ish count of how many distinct scriptpubkeys there are in the txout set?
151 2015-11-24T05:51:22  <CodeShark> I used to keep a database of that but haven't been tracking that in a while
152 2015-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
153 2015-11-24T06:06:56  *** pigeons has quit IRC
154 2015-11-24T06:07:51  *** randy-waterhouse has quit IRC
155 2015-11-24T06:07:52  *** pigeons has joined #bitcoin-core-dev
156 2015-11-24T06:08:14  *** pigeons is now known as Guest1328
157 2015-11-24T06:53:28  *** arowser has quit IRC
158 2015-11-24T06:53:55  *** arowser has joined #bitcoin-core-dev
159 2015-11-24T06:56:00  *** moli has joined #bitcoin-core-dev
160 2015-11-24T06:59:53  *** molly has quit IRC
161 2015-11-24T07:01:14  *** molly has joined #bitcoin-core-dev
162 2015-11-24T07:04:26  *** moli has quit IRC
163 2015-11-24T07:14:48  *** guest234234 has quit IRC
164 2015-11-24T07:15:21  *** dcousens has joined #bitcoin-core-dev
165 2015-11-24T07:42:54  <GitHub191> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b0fc179ab87...f91e29fd4d0e
166 2015-11-24T07:42:54  <GitHub191> bitcoin/master 3522f49 Wladimir J. van der Laan: http: add Boost 1.49 compatibility...
167 2015-11-24T07:42:55  <GitHub191> bitcoin/master f91e29f Wladimir J. van der Laan: Merge pull request #7065...
168 2015-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
169 2015-11-24T07:43:19  *** pkthebud has joined #bitcoin-core-dev
170 2015-11-24T07:44:37  <pkthebud> Hello 😃
171 2015-11-24T07:51:16  *** MarcoFalke has joined #bitcoin-core-dev
172 2015-11-24T07:53:18  *** Ylbam has joined #bitcoin-core-dev
173 2015-11-24T07:55:43  *** randy-waterhouse has joined #bitcoin-core-dev
174 2015-11-24T08:12:35  *** Guyver2 has joined #bitcoin-core-dev
175 2015-11-24T08:13:11  *** Thireus has quit IRC
176 2015-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
177 2015-11-24T08:30:08  <GitHub13> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f91e29fd4d0e...ed34e0577e8d
178 2015-11-24T08:30:09  <GitHub13> bitcoin/master a0953cd MarcoFalke: [qa] python-bitcoinrpc is no longer a subtree...
179 2015-11-24T08:30:09  <GitHub13> bitcoin/master ed34e05 Wladimir J. van der Laan: Merge pull request #7052...
180 2015-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
181 2015-11-24T08:31:27  <gmaxwell> Anyone know why zapwallettxes might use a lot more memory than a rescan?
182 2015-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.
183 2015-11-24T08:33:04  <GitHub69> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed34e0577e8d...b1fcdec68790
184 2015-11-24T08:33:05  <GitHub69> bitcoin/master 2fcb849 fanquake: [doc][trivial] Remove source forge from Debian watch.
185 2015-11-24T08:33:05  <GitHub69> bitcoin/master 70899d7 fanquake: [doc][trivial] Update Debian control description...
186 2015-11-24T08:33:06  <GitHub69> bitcoin/master b1fcdec Wladimir J. van der Laan: Merge pull request #7042...
187 2015-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
188 2015-11-24T08:38:30  *** JackH has joined #bitcoin-core-dev
189 2015-11-24T08:50:07  *** paveljanik has quit IRC
190 2015-11-24T08:51:33  <GitHub105> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b1fcdec68790...72dccfc29dfc
191 2015-11-24T08:51:34  <GitHub105> bitcoin/master 2aa49ce Luke Dashjr: Bugfix: Use unique autostart filenames on Linux for testnet/regtest
192 2015-11-24T08:51:34  <GitHub105> bitcoin/master 72dccfc Wladimir J. van der Laan: Merge pull request #7045...
193 2015-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
194 2015-11-24T08:53:16  *** tulip has quit IRC
195 2015-11-24T09:02:42  *** lightningbot has joined #bitcoin-core-dev
196 2015-11-24T09:03:39  *** lightningbot has joined #bitcoin-core-dev
197 2015-11-24T09:04:40  *** MarcoFalke has quit IRC
198 2015-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
199 2015-11-24T09:47:39  *** randy-waterhouse has quit IRC
200 2015-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
201 2015-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
202 2015-11-24T09:55:57  <GitHub67> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/72dccfc29dfc...02a0f348c210
203 2015-11-24T09:55:58  <GitHub67> bitcoin/master 5c2fd38 Pavel Janík: Add missing "blocktime" description to listtransactions help, fix formatting.
204 2015-11-24T09:55:58  <GitHub67> bitcoin/master 02a0f34 Wladimir J. van der Laan: Merge pull request #7066...
205 2015-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
206 2015-11-24T10:09:20  <phantomcircuit> it's kind of comical how much more productive i am without video games
207 2015-11-24T10:10:03  <phantomcircuit> gmaxwell, iirc zapwallettxs keeps two walletdb objects open, so will presumably use a minimum of double the memory
208 2015-11-24T10:11:13  *** Thireus has joined #bitcoin-core-dev
209 2015-11-24T10:24:33  *** randy-waterhouse has joined #bitcoin-core-dev
210 2015-11-24T10:28:57  <sipa> phantomcircuit: you should sold *all* your gpus after the gpu mining era was over
211 2015-11-24T10:29:41  <phantomcircuit> sipa, heh
212 2015-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
213 2015-11-24T10:49:49  *** MarcoFalke has joined #bitcoin-core-dev
214 2015-11-24T10:51:15  *** d_t has quit IRC
215 2015-11-24T10:52:23  <phantomcircuit> wumpus, it helps when you're using old 7970s from a mining farm
216 2015-11-24T10:53:42  <phantomcircuit> wumpus, need anything else on 7087 ?
217 2015-11-24T10:55:23  <wumpus> no, looks good to me now
218 2015-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.
219 2015-11-24T11:05:09  <wumpus> midnightmagic: yes that still sounds kind of fun
220 2015-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.
221 2015-11-24T11:07:44  <MarcoFalke> wumups, not sure we should silently "ignore" negative values from GetArg()?
222 2015-11-24T11:08:03  *** jl2012 has joined #bitcoin-core-dev
223 2015-11-24T11:08:03  *** jl2012_ has quit IRC
224 2015-11-24T11:08:13  <MarcoFalke> is done very rarely, though.
225 2015-11-24T11:08:53  <MarcoFalke> *Sanitization is done very rarely, though.
226 2015-11-24T11:09:05  <MarcoFalke> * wumpus,
227 2015-11-24T11:12:06  <MarcoFalke> We need to collect all accepted config args and their valid range. Also warn about unknown config args.
228 2015-11-24T11:22:24  <wumpus> MarcoFalke: definitely not ignore
229 2015-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
230 2015-11-24T11:27:38  <phantomcircuit> gmaxwell, did you see my PR for 7082 ?
231 2015-11-24T11:29:33  *** randy-waterhouse has quit IRC
232 2015-11-24T11:30:08  <MarcoFalke> Changed it to uint_ and dropped the < 0 check like you suggested.
233 2015-11-24T11:30:36  <MarcoFalke> Now, we get funny errors like Error: -maxmempool must be at least 1.84467e+16 MB, at least.
234 2015-11-24T11:30:43  <wumpus> so a negative value is an explicit error now?
235 2015-11-24T11:30:57  <wumpus> eh, that's definitely not an improvemnt
236 2015-11-24T11:31:15  <wumpus> just leave it as is then
237 2015-11-24T11:31:27  <MarcoFalke> I like it uint ;)
238 2015-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
239 2015-11-24T11:32:47  <wumpus> (which the old code did, so probably my suggestion was just wrong)
240 2015-11-24T11:33:11  <MarcoFalke> Usually -1 means "just make it large enogh that I don't have to care about it"
241 2015-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...'
242 2015-11-24T11:34:11  <wumpus> which is fine if you handle it explicitly, don't rely on integer overflow
243 2015-11-24T11:35:50  <gmaxwell> phantomcircuit: thanks, I wouldn't have.
244 2015-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.
245 2015-11-24T11:42:31  *** randy-waterhouse has joined #bitcoin-core-dev
246 2015-11-24T11:45:38  <phantomcircuit> gmaxwell, ha derp so i did
247 2015-11-24T11:49:02  <phantomcircuit> gmaxwell, ok there you go
248 2015-11-24T11:52:52  *** MarcoFalke has quit IRC
249 2015-11-24T11:57:52  *** randy-waterhouse has quit IRC
250 2015-11-24T12:33:44  *** MarcoFalke has joined #bitcoin-core-dev
251 2015-11-24T12:52:37  <MarcoFalke> Restored original behavior: "Error: -maxmempool must be at least -120 MB
252 2015-11-24T12:52:38  <MarcoFalke> "
253 2015-11-24T12:55:52  <wumpus> ok..
254 2015-11-24T12:57:30  *** Guest1328 is now known as pigeons
255 2015-11-24T12:58:01  <wumpus> we probably want to check -limitdescendantsize against 0 as well, or can it be usefully negative?
256 2015-11-24T12:59:50  <sdaftuar> wumpus: limitdescendantsize cannot be usefully negative
257 2015-11-24T13:00:01  <wumpus> in other places we assign the result to a size_t
258 2015-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
259 2015-11-24T13:04:11  <MarcoFalke> Is this framework sipa mentions ready for copy & paste? https://github.com/bitcoin/bitcoin/pull/4194#issuecomment-44521490
260 2015-11-24T13:04:53  <wumpus> I doubt it
261 2015-11-24T13:05:31  <sipa> i started writing that a long time ago, but never finished it
262 2015-11-24T13:05:36  <wumpus> although the approach is a lot saner than what we have now
263 2015-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.
264 2015-11-24T13:08:40  <wumpus> and at least having base argument parsing in one place so that it can flag unknown arguments
265 2015-11-24T13:10:02  *** MarcoFalke has quit IRC
266 2015-11-24T13:10:39  *** MarcoFalke has joined #bitcoin-core-dev
267 2015-11-24T13:24:41  *** MarcoFalke has quit IRC
268 2015-11-24T13:25:25  *** MarcoFalke has joined #bitcoin-core-dev
269 2015-11-24T13:37:43  *** ParadoxSpiral has joined #bitcoin-core-dev
270 2015-11-24T13:43:46  *** dcousens has quit IRC
271 2015-11-24T13:44:22  *** dcousens has joined #bitcoin-core-dev
272 2015-11-24T13:51:18  *** MarcoFalke has quit IRC
273 2015-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
274 2015-11-24T15:02:29  <GitHub18> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/02a0f348c210...b19fe277dd62
275 2015-11-24T15:02:30  <GitHub18> bitcoin/master 4846543 tulip: Move time data log print to 'net' category to reduce log noise
276 2015-11-24T15:02:30  *** davec has quit IRC
277 2015-11-24T15:02:30  <GitHub18> bitcoin/master b19fe27 Wladimir J. van der Laan: Merge pull request #7075...
278 2015-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
279 2015-11-24T15:02:51  *** davec has joined #bitcoin-core-dev
280 2015-11-24T15:07:19  <GitHub149> [bitcoin] jtimon opened pull request #7091: Consensus build package (master...consensus-build) https://github.com/bitcoin/bitcoin/pull/7091
281 2015-11-24T15:40:03  *** Thireus has quit IRC
282 2015-11-24T15:56:59  *** Thireus has joined #bitcoin-core-dev
283 2015-11-24T16:08:08  *** MarcoFalke has joined #bitcoin-core-dev
284 2015-11-24T16:29:44  *** dcousens has quit IRC
285 2015-11-24T16:46:42  <MarcoFalke> travis is only running 3 jobs in parallel instead of 5, what it used to be...
286 2015-11-24T17:06:04  *** Thireus has quit IRC
287 2015-11-24T17:13:34  *** d_t has joined #bitcoin-core-dev
288 2015-11-24T17:32:56  *** paveljanik has joined #bitcoin-core-dev
289 2015-11-24T17:45:38  *** ParadoxSpiral_ has joined #bitcoin-core-dev
290 2015-11-24T17:48:40  *** ParadoxSpiral has quit IRC
291 2015-11-24T19:44:43  *** MarcoFalke has quit IRC
292 2015-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
293 2015-11-24T19:51:30  <sipa> phantomcircuit: it is, it should cache things
294 2015-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
295 2015-11-24T20:08:35  <cfields_> jtimon: will have a look
296 2015-11-24T20:16:39  *** randy-waterhouse has joined #bitcoin-core-dev
297 2015-11-24T20:32:10  *** Thireus has joined #bitcoin-core-dev
298 2015-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
299 2015-11-24T20:59:10  <jonasschnelli> cfields_: so it could be a issue created by the dmg tool?
300 2015-11-24T21:01:16  *** cocoBTC has joined #bitcoin-core-dev
301 2015-11-24T21:03:46  <cfields_> jtimon: you need $()
302 2015-11-24T21:04:19  <cfields_> jonasschnelli: yea, looks that way to me. testing a fix now
303 2015-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.
304 2015-11-24T21:05:22  <cfields_> jonasschnelli: np. I'm still trying to figure out why it's not an issue for me
305 2015-11-24T21:13:36  <cfields_> jonasschnelli: yea, that fixes
306 2015-11-24T21:13:50  *** raedah has joined #bitcoin-core-dev
307 2015-11-24T21:14:30  <cfields_> fixes the perms, anyway. I can't reproduce, but i assume setting the dir to 0755 is enough
308 2015-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
309 2015-11-24T21:27:24  <jonasschnelli> cfields_: super. Thanks. Testing tomorrow (in about 10h).
310 2015-11-24T21:27:47  <cfields_> jonasschnelli: great, thanks
311 2015-11-24T21:38:28  *** Guyver2_ has joined #bitcoin-core-dev
312 2015-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"
313 2015-11-24T21:45:29  <sipa> phantomcircuit: as in: try random IPs? :o
314 2015-11-24T21:46:51  <jtimon> cfields_: this should fix it? https://github.com/bitcoin/bitcoin/commit/164870c3f43f09330611fa939b7ae7fe468c1cf1
315 2015-11-24T21:47:24  <jtimon> cfields_: in any case, I'm more interested in your opinion than making travis happy at this point
316 2015-11-24T21:48:00  <cfields_> jtimon: from the looks, i believe that now involves building each object 3 times
317 2015-11-24T21:48:12  <jtimon> how so?
318 2015-11-24T21:48:40  <jtimon> one for libconsensus and one for the rest, no?
319 2015-11-24T21:48:51  <jtimon> like before, no?
320 2015-11-24T21:49:22  <cfields_> ah sorry, misread. yes.
321 2015-11-24T21:49:44  * jtimon naively let himself think he was saving one build
322 2015-11-24T21:50:07  <cfields_> jtimon: to save the build, you'd have to add the objects rather than the sources
323 2015-11-24T21:50:22  <cfields_> don't think libtool will let you do that, though
324 2015-11-24T21:51:04  <jtimon> never mind, I was expecting you to maybe complain about https://github.com/jtimon/bitcoin/commit/083e1344f7162d516ffcf2bb30622b28767e415e
325 2015-11-24T21:51:39  <jtimon> or https://github.com/jtimon/bitcoin/commit/f37ff9b61375f8f667f17d529b6422e9c2c353c4 (it makes bitcoin-tx a little bit bigger)
326 2015-11-24T21:52:02  <jtimon> not much bigger though
327 2015-11-24T21:52:41  <cfields_> jtimon: yes, i'm not a fan of that. I see your reasoning, though.
328 2015-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
329 2015-11-24T21:53:04  <jtimon> not a fan of which part?
330 2015-11-24T21:53:28  <cfields_> breaking crypto out of its contained unit
331 2015-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)
332 2015-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?
333 2015-11-24T21:57:31  <jtimon> that way we can say libconsensus contains the libsecp256k1, crypto and consensus packages
334 2015-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
335 2015-11-24T21:58:57  <jtimon> what about https://github.com/jtimon/bitcoin/commit/f37ff9b61375f8f667f17d529b6422e9c2c353c4 ?
336 2015-11-24T21:58:58  <phantomcircuit> sipa, yeah and why not?
337 2015-11-24T22:00:00  <sipa> phantomcircuit: nobody implemented it :)
338 2015-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
339 2015-11-24T22:00:06  <sipa> phantomcircuit: it's very rarely an issue
340 2015-11-24T22:05:49  *** ParadoxSpiral_ has quit IRC
341 2015-11-24T22:05:51  <gmaxwell> I think I fixed the mempool dos attack/information leak problem.
342 2015-11-24T22:06:49  *** randy-waterhouse has quit IRC
343 2015-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.
344 2015-11-24T22:07:24  <phantomcircuit> gmaxwell, yes i was thinking of it as something that wouldn't run for at least 30 minutes
345 2015-11-24T22:07:29  <phantomcircuit> and would be pretty slow even then
346 2015-11-24T22:08:04  <gmaxwell> phantomcircuit: slow = never find peers. :P
347 2015-11-24T22:08:19  <phantomcircuit> gmaxwell, "slowish"
348 2015-11-24T22:08:23  <gmaxwell> phantomcircuit: go look at my candidate mempool attack fix
349 2015-11-24T22:08:46  <phantomcircuit> gmaxwell, in about an hour i have to go move my car now...
350 2015-11-24T22:08:58  <phantomcircuit> who does street sweeping at 3pm?
351 2015-11-24T22:16:53  * jgarzik reads
352 2015-11-24T22:17:02  * sipa sleeps
353 2015-11-24T22:19:52  <cfields_> jtimon: how about something more like this: http://pastebin.com/raw.php?i=JBqjPYAr ?
354 2015-11-24T22:20:13  <cfields_> (it's a quick hack, the other targets need to be updated, i only changed bitcoind)
355 2015-11-24T22:22:12  <gmaxwell> cfields_: if you get a chance, https://github.com/bitcoin/secp256k1/pull/356#issuecomment-156839307
356 2015-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
357 2015-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
358 2015-11-24T22:23:45  <jtimon> should I put the .h directly in libbitcoinconsensusint_la_SOURCES?
359 2015-11-24T22:24:08  <jtimon> btw, what does the int stand for?
360 2015-11-24T22:24:10  <cfields_> jtimon: just an idea, i haven't really thought it through
361 2015-11-24T22:24:19  <cfields_> internal. again, just a quick hack
362 2015-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 ?
363 2015-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
364 2015-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
365 2015-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
366 2015-11-24T22:28:34  <jtimon> but that can wait
367 2015-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)
368 2015-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?
369 2015-11-24T22:29:00  <gmaxwell> cfields_: yes.
370 2015-11-24T22:29:03  <cfields_> roger
371 2015-11-24T22:30:03  <jtimon> cfields_: got it, so no BITCOIN_CONSENSUS_H, put the .h and the .cpp together directly
372 2015-11-24T22:30:23  <jtimon> cfields_: like in the crypto package
373 2015-11-24T22:30:42  <cfields_> jtimon: i have no real preference there
374 2015-11-24T22:31:02  <jtimon> cfields_: well, me neither, so...
375 2015-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)
376 2015-11-24T22:32:04  <jtimon> I think I'll just copy the ways of crypto then
377 2015-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
378 2015-11-24T22:33:36  <gmaxwell> cfields_: mostly I wanted to get a run against current libsecp256k1. :)
379 2015-11-24T22:33:51  <cfields_> heh
380 2015-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
381 2015-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)?
382 2015-11-24T22:37:03  <jtimon> s/"version.h, serialize.h"/"consensus/params.h, consensus/validation.h"/
383 2015-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
384 2015-11-24T22:41:00  <cfields_> so just do whatever makes it the most clear
385 2015-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
386 2015-11-24T22:42:35  <cfields_> jtimon: i don't believe so. Need to control it with paths.
387 2015-11-24T22:42:47  <jtimon> I think it still makes it clearer
388 2015-11-24T22:44:20  <jtimon> currently https://github.com/libbitcoin/libbitcoin-consensus/tree/master/src/clone is more clear than libbitcoinconsensus_la_SOURCES
389 2015-11-24T22:45:49  <jtimon> thanks for the feedback, I will force push an updated version
390 2015-11-24T22:46:00  <cfields_> np
391 2015-11-24T22:48:30  <jtimon> cfields_: could you push your raw patch somewhere on github for convenience?
392 2015-11-24T22:49:00  <cfields_> jtimon: will do in a few min, that's mixed in with my current branch
393 2015-11-24T22:49:22  <jtimon> oh, I see, no hurry
394 2015-11-24T22:50:07  <jtimon> hehe, I wasn't sure if it was on top of master or one of my commits
395 2015-11-24T22:51:27  <cfields_> nah, master
396 2015-11-24T22:52:21  <jtimon> oh, never mind then
397 2015-11-24T23:03:18  <cfields_> ok
398 2015-11-24T23:03:37  *** Guyver2 has quit IRC
399 2015-11-24T23:03:39  *** Guyver2_ is now known as Guyver2
400 2015-11-24T23:22:54  <phantomcircuit> gmaxwell, we're keeping travis very busy
401 2015-11-24T23:24:44  *** belcher has joined #bitcoin-core-dev