1 2015-06-26 03:13:26 <Luke-Jr> cfields: is there a reason we don't automatically set --disable-reduce-exports when needed?
  2 2015-06-26 03:14:19 <cfields> Luke-Jr: it used to be default, but we ran into some wonky compiler/stdlib combos iirc
  3 2015-06-26 03:14:19 <Luke-Jr> oh, nm, misread configure.ac
  4 2015-06-26 03:35:42 <Luke-Jr> wumpus: label 0.11 https://github.com/bitcoin/bitcoin/issues/6340
  5 2015-06-26 05:11:28 <chmod755> why am i getting like 100 connections from XT nodes ?
  6 2015-06-26 05:12:16 <Luke-Jr> someone trying to fake out charts?
  7 2015-06-26 05:12:32 <chmod755> Luke-Jr, maybe? idk
  8 2015-06-26 05:13:20 <chmod755> http://i.imgur.com/Hz1CuVo.png
  9 2015-06-26 05:13:47 <Luke-Jr> CodeShark: mSIGNA has an invalid p2p UA O.o
 10 2015-06-26 05:14:01 <CodeShark> oh?
 11 2015-06-26 05:14:02 <Luke-Jr> chmod755: yeah, they're all the same IPs..
 12 2015-06-26 05:14:13 <Luke-Jr> CodeShark: just says "Wallet v0.1"
 13 2015-06-26 05:14:19 <chmod755> Luke-Jr, several XT nodes are doing that tho
 14 2015-06-26 05:14:25 <Luke-Jr> chmod755: I'm not getting any FWIW..
 15 2015-06-26 05:14:36 <jgarzik> zero XT nodes on my public node
 16 2015-06-26 05:14:40 <CodeShark> Luke-Jr: oh, right - I was trying to think about what to put there and forgot to change it
 17 2015-06-26 05:14:50 <Luke-Jr> chmod755: could your network be broken, and it's the same one reconnecting, but not timing out yet?
 18 2015-06-26 05:14:54 <Luke-Jr> CodeShark: lol :D
 19 2015-06-26 05:15:03 <chmod755> Luke-Jr, hmmm....
 20 2015-06-26 05:15:17 <Luke-Jr> CodeShark: /mSIGNA:0.9.5beta/
 21 2015-06-26 05:15:21 <chmod755> maybe
 22 2015-06-26 05:15:33 <CodeShark> Luke-Jr: thanks for pointing that out :)
 23 2015-06-26 05:15:37 <Luke-Jr> CodeShark: shall I PR it? :p
 24 2015-06-26 05:15:52 <CodeShark> Luke-Jr: if you would like to I'm not going to stop you :)
 25 2015-06-26 05:16:20 <CodeShark> it definitely needs that fix, so it's not a question of that
 26 2015-06-26 05:17:03 <Luke-Jr> CodeShark: there's 3 places it does this? O.o
 27 2015-06-26 05:17:16 <CodeShark> if you do, though, make sure to pull the data from the settings file
 28 2015-06-26 05:17:26 <Luke-Jr> what data?
 29 2015-06-26 05:17:27 <CodeShark> there's a file, I think settings.cpp
 30 2015-06-26 05:17:38 <CodeShark> and you can pass that data to the Peer constructor
 31 2015-06-26 05:17:59 <CodeShark> which is owned by NetworkSync which is owned by SynchedVault....
 32 2015-06-26 05:18:38 <CodeShark> it's where I pull that data for the splash screen and the about box
 33 2015-06-26 05:18:52 <Luke-Jr> oh
 34 2015-06-26 05:19:01 <Luke-Jr> deps/CoinQ/src/BlockchainDownload.cpp deps/CoinQ/src/CoinQ_netsync.cpp src/networksync.cpp
 35 2015-06-26 05:19:18 <Luke-Jr> all 3 of these duplicate the same code? wtf?
 36 2015-06-26 05:19:44 <CodeShark> Luke-Jr: there's a bunch of crap in the CoinQ library that never got cleaned out - but the library should only contain the important stuff
 37 2015-06-26 05:21:01 <CodeShark> many of those source files are long-since deprecated
 38 2015-06-26 05:21:10 <CodeShark> so just look at the ones included in the actual library
 39 2015-06-26 05:21:54 <Luke-Jr> as if you made that easy to do :P
 40 2015-06-26 05:22:09 <CodeShark> Luke-Jr: the Makefile
 41 2015-06-26 05:22:14 <CodeShark> CoinQ/Makefile
 42 2015-06-26 05:23:08 <CodeShark> specifically, the OBJS
 43 2015-06-26 05:23:42 <Luke-Jr> changed all 3 to be unique and ran build-all.sh, didn't make any effective change, so guessing the build system is broken
 44 2015-06-26 05:24:13 <CodeShark> Changed all what 3 to be unique?
 45 2015-06-26 05:24:22 <Luke-Jr> all 3 instances of "Wallet v0.1"
 46 2015-06-26 05:25:16 <Luke-Jr> side note: looks like it didn't save my wallet anywhere, and didn't warn me, so I just lost bitcoins :x
 47 2015-06-26 05:25:25 <CodeShark> huh?
 48 2015-06-26 05:25:45 <CodeShark> you can't create an account without making a backup
 49 2015-06-26 05:25:49 <CodeShark> it shouldn't let you
 50 2015-06-26 05:25:52 <Luke-Jr> ☺
 51 2015-06-26 05:26:17 <CodeShark> did it not prompt you to write down a wordlist?
 52 2015-06-26 05:26:23 <Luke-Jr> sure, I ignored it <.<
 53 2015-06-26 05:26:52 <CodeShark> and you cannot create an account without there being a .vault file
 54 2015-06-26 05:27:05 <Luke-Jr> yep, that seems to have not been created
 55 2015-06-26 05:27:15 <chmod755> huh?
 56 2015-06-26 05:27:23 <chmod755> Luke-Jr, did you lose BTC or something?
 57 2015-06-26 05:27:30 <CodeShark> hmm - I don't see how that could happen - unless you changed the storage engine
 58 2015-06-26 05:27:33 <Luke-Jr> chmod755: just $2 I was using for testing
 59 2015-06-26 05:27:40 <chmod755> ah, ok
 60 2015-06-26 05:28:18 <CodeShark> there must be a .vault file somewhere on your system unless you're doing something unconventional with your file system
 61 2015-06-26 05:28:38 <Luke-Jr> nope, just a standard btrfs
 62 2015-06-26 05:28:59 <Luke-Jr> hm, recent vault list worked
 63 2015-06-26 05:29:10 <CodeShark> it should :)
 64 2015-06-26 05:29:29 <CodeShark> I've never had anyone ever have this problem
 65 2015-06-26 05:29:31 <Luke-Jr> doesn't explain why I can't find a .vault file where I told it to put it <.<
 66 2015-06-26 05:30:11 <CodeShark> that's something to do with your filesystem and has nothing to do with mSIGNA :p
 67 2015-06-26 05:30:32 <Luke-Jr> aha, found it
 68 2015-06-26 05:30:38 <Luke-Jr> wonder how it ended up there
 69 2015-06-26 05:30:46 <Luke-Jr> 917k :o
 70 2015-06-26 05:31:00 <CodeShark> you think that's a lot/
 71 2015-06-26 05:31:01 <CodeShark> ?
 72 2015-06-26 05:31:23 <Luke-Jr> for a near-empty wallet, yes :p
 73 2015-06-26 05:31:58 <CodeShark> it stores all the merkle proofs for all blocks since a little before account timestamp
 74 2015-06-26 05:32:19 <CodeShark> the only locally stored data across all vaults is blocktree.dat
 75 2015-06-26 05:32:24 <CodeShark> which is like 30MB
 76 2015-06-26 05:32:52 <CodeShark> only contains headers
 77 2015-06-26 05:33:09 <CodeShark> so naturally, vault files need to store a bit of state data
 78 2015-06-26 05:34:31 <CodeShark> then on top of that it stores all the keychain information, including precomputed p2sh tables
 79 2015-06-26 05:34:49 <CodeShark> keychain and script template information, I should say
 80 2015-06-26 05:35:59 <CodeShark> regarding your change not showing up in the build, sounds like you need to rebuild libCoinQ.a
 81 2015-06-26 05:37:06 <leakypat> Are here any QT libs prebuilt with OpenSSL for windows anywhere ?
 82 2015-06-26 05:37:24 <leakypat> Apparently it's going to take several hours to build them
 83 2015-06-26 05:37:38 <CodeShark> rm sysroot/lib/libCoinQ.a
 84 2015-06-26 05:38:24 <CodeShark> the Makefile should have caught that...but perhaps I screwed something up
 85 2015-06-26 05:58:14 <CodeShark> nah, sorry - do a make clean-all in the CoinQ directory
 86 2015-06-26 05:58:25 <CodeShark> and then run ./build-all.sh again
 87 2015-06-26 06:41:48 <jonasschnelli> FSS RBF: what if Alice is new to bitcoin, received her first 1BTC, send this 1 BTC with subtract-fee-from-amount to Bob while she did only add 0.0001 of fees. I assume she has no chance to replace her fee with FSS RBF? (forgive me if this question already been ask)
 88 2015-06-26 06:43:43 <warren> jonasschnelli: she would of course need additional inputs to add more fees, right?
 89 2015-06-26 06:45:00 <jonasschnelli> I assume. More inputs or a mempool sweep (which is not controllable, predictable).
 90 2015-06-26 06:45:48 <jonasschnelli> But i think it's low prio and probably a edge case.
 91 2015-06-26 06:51:58 <LeMiner> Looks like someone created 100+ XT nodes on the same IP
 92 2015-06-26 06:52:29 <LeMiner> and for some reason my nodes is connected to 40 of them
 93 2015-06-26 06:52:35 <LeMiner> node*
 94 2015-06-26 06:52:54 <chmod755> LeMiner, 37.187.129.166 ?
 95 2015-06-26 06:53:12 <LeMiner> 96.44.189.101
 96 2015-06-26 06:53:20 <chmod755> O.o
 97 2015-06-26 06:53:25 <LeMiner> and 188.138.9.49
 98 2015-06-26 06:53:34 <jonasschnelli> LeMiner: 40 nodes on the same ip? isn't that agains the internal "diversity" policies?
 99 2015-06-26 06:53:48 <LeMiner> It should be
100 2015-06-26 06:53:53 <LeMiner> its still happening tough
101 2015-06-26 06:54:40 <chmod755> so it's not just happening in my client....
102 2015-06-26 06:55:09 <LeMiner> I got a message that my node stalled, so found out that it's still working, just that all these weird clients connected...
103 2015-06-26 06:55:39 <LeMiner> I'm maxed out on connections now
104 2015-06-26 06:56:04 <jonasschnelli> LeMiner: pull in the ban PR and ban the node(s)
105 2015-06-26 06:56:35 <leakypat> jonasschnelli: correct if you have no inputs with FSS you can't do it
106 2015-06-26 06:56:48 <chmod755> jonasschnelli, ban PR?
107 2015-06-26 06:57:04 <LeMiner> I'll just ban them through the firewall
108 2015-06-26 06:57:18 <jonasschnelli> chmod755: it's even merged. If you compile the master branch of bitcoin-core you have a rpc command called "setban <ip> add"
109 2015-06-26 06:57:33 <chmod755> ohhh lol
110 2015-06-26 06:57:34 <jonasschnelli> the QT part is not merged yet: https://github.com/bitcoin/bitcoin/pull/6315
111 2015-06-26 06:57:42 <LeMiner> Can't compile on this at the moment
112 2015-06-26 06:58:20 <leakypat> jonasschnelli: it struck me the other day that the recipient could RBF FSS the transaction (need to think this through more)
113 2015-06-26 06:58:26 <LeMiner> You did awesome work on the add ban tough, really happy with your work
114 2015-06-26 06:59:37 <leakypat> People are running multiple XT on same IP?
115 2015-06-26 06:59:58 <jonasschnelli> maybe the "setban" rpc command should be ready to support banning after a user agent ("subver") string regex filter. *duck*
116 2015-06-26 07:00:45 <paveljanik> those IPs are tor exit nodes...
117 2015-06-26 07:00:58 <gmaxwell> jonasschnelli: your ducking is well honed.
118 2015-06-26 07:01:58 <gmaxwell> it's really important to not do anything at all with that string, or it'll become another http useragent "Mozilla" -- a preprogramed lie that has no meaning at all.  It's already very frequently wrong, even though I'm not aware of any good reason for implementations to lie.
119 2015-06-26 07:02:38 <gmaxwell> LeMiner: they're connected inbound to you, there is no diversity policy there,
120 2015-06-26 07:02:53 <jonasschnelli> @gmaxwell: Right. I Agree with that.
121 2015-06-26 07:02:56 <gmaxwell> presumably it's just one node and someone has hacked it up to be super agressive and broken its behavior.
122 2015-06-26 07:03:37 <chmod755> m
123 2015-06-26 07:04:33 <chmod755> gmaxwell, it's more than 1 node
124 2015-06-26 07:06:29 <gmaxwell> chmod755: what reason do you have to believe that?
125 2015-06-26 07:11:50 <chmod755> gmaxwell, might be 1 node.... i didn't realize those are tor ips
126 2015-06-26 07:13:57 <warren> LeMiner: http://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
127 2015-06-26 07:14:08 <warren> LeMiner: iptables rule something like this would prevent that kind of abuse
128 2015-06-26 08:00:44 <michagogo> cfields: sorry, was already asleep
129 2015-06-26 08:00:47 <michagogo> I'll go do that now
130 2015-06-26 08:01:39 <michagogo> Should I make a version for 0.11, or will whoever pulls it just port it there?
131 2015-06-26 08:08:25 <michagogo> cfields: Hm, looking at the expected output thing
132 2015-06-26 08:09:53 <michagogo> There you do also get the unsigned dmg, in addition to the tgz
133 2015-06-26 09:13:26 <LeMiner> I've kicked off the ones that had multiple connections from the same IP, don't care much about the others
134 2015-06-26 09:25:13 <LeMiner> Here's the list of IP's; 84.53.203.38 - 188.138.9.49 - 96.44.189.101 - 197.231.221.211 - 80.68.95.180 - 46.101.162.85 - 89.105.194.74 - 96.47.226.22 - 77.109.141.138
135 2015-06-26 09:26:05 <LeMiner> Funny, looks like they just pulled the rest of them away as well
136 2015-06-26 09:31:58 <phantomcircuit> LeMiner, tor?
137 2015-06-26 09:32:09 <phantomcircuit> tor
138 2015-06-26 09:33:04 <phantomcircuit> LeMiner, probably someone tried to hack their xt node to look like it was 1000 nodes or something stupid
139 2015-06-26 09:33:15 <LeMiner> aye
140 2015-06-26 09:33:29 <LeMiner> it did take up all my available connections
141 2015-06-26 09:34:06 <LeMiner> It just started again, am I the only one having this problem?
142 2015-06-26 09:34:31 <LeMiner> 22 connections from 37.130.227.133
143 2015-06-26 09:36:23 <phantomcircuit> LeMiner,   "connections": 41,
144 2015-06-26 09:36:31 <phantomcircuit> long uptime public node
145 2015-06-26 09:36:49 <LeMiner> I hover around 70 most of the tme
146 2015-06-26 09:37:02 <chmod755> i just banned all tor relays and exits
147 2015-06-26 09:37:30 <LeMiner> but these bad nodes are taking up all the rest of the available connections
148 2015-06-26 09:38:40 <phantomcircuit> chmod755, :(
149 2015-06-26 09:38:45 <phantomcircuit> but tor
150 2015-06-26 09:39:02 <LeMiner> I don't mind connections from tor but this is obviously some sort of attack, heh
151 2015-06-26 09:39:09 <michagogo> chmod755: Uh, wtf?
152 2015-06-26 09:39:13 <michagogo> Why would you ban tor relays?
153 2015-06-26 09:39:32 <chmod755> michagogo, i'm getting 125 connections on my node if i don't
154 2015-06-26 09:39:34 <michagogo> As someone who runs a tor relay at home, I hate people who do that
155 2015-06-26 09:39:46 <michagogo> chmod755: that has nothing to do with being a tor relay
156 2015-06-26 09:40:05 <michagogo> You could block tor exit nodes, which would prevent people from connecting to you through tor
157 2015-06-26 09:40:18 <michagogo> But there's no reason to block tor *relays*
158 2015-06-26 09:40:27 <Luke-Jr> phantomcircuit: eh, if it's tor exit nodes, then it *could* be many XT nodes using the same exit
159 2015-06-26 09:41:32 <LeMiner> Luke, I'm under constant attack from nearly all exit relays at this point.... I only ban the ones that attempt to get more than 1 connection
160 2015-06-26 09:41:37 <phantomcircuit> Luke-Jr, that's pretty unlikely
161 2015-06-26 09:42:31 <michagogo> cfields: Also, another consistency thing
162 2015-06-26 09:42:56 <michagogo> With OS X, the input tarball to the signer contains everything that you need to apply the signature
163 2015-06-26 09:43:57 <michagogo> Seems weird to me that that's the case, while with Windows we give it the raw setup binaries and the tool
164 2015-06-26 09:44:10 <Luke-Jr> LeMiner: why? I see none of this on my node
165 2015-06-26 09:44:32 <LeMiner> I'm not sure if i'm being singled out or if anyone else is experiencing this, it started a few hours ago @luke
166 2015-06-26 09:44:56 <Luke-Jr> sounds similar to what chmod755 was reporting
167 2015-06-26 09:45:08 <Luke-Jr> MEH, I need to drive an hour in 2 hours.
168 2015-06-26 09:45:26 <michagogo> Would make more sense to have the osslsigncode thing set up in gitian-win.yml, and have it output a bitcoin-win-unsigned.tar.gz that goes into inputs/
169 2015-06-26 09:47:43 <chmod755> Luke-Jr, yep
170 2015-06-26 09:47:49 <chmod755> LeMiner, you're not alone
171 2015-06-26 09:48:12 <LeMiner> When did it start for you?
172 2015-06-26 09:48:48 <chmod755> LeMiner, i have no idea - i'm only running bitcoin on my desktop
173 2015-06-26 09:50:58 <gribble> cfields was last seen in #bitcoin-dev 6 hours, 36 minutes, and 38 seconds ago: <cfields> Luke-Jr: it used to be default, but we ran into some wonky compiler/stdlib combos iirc
174 2015-06-26 09:50:58 <michagogo> ;;seen cfields
175 2015-06-26 09:52:07 <phantomcircuit> chmod755, anything weird about your setup?
176 2015-06-26 09:52:22 <phantomcircuit> maybe you're being returned from dnsseeds excessively or something
177 2015-06-26 09:52:27 <phantomcircuit> (that's happened before)
178 2015-06-26 09:52:47 <LeMiner> The node i'm experiencing it on is just a regulair Win 8.1 machine
179 2015-06-26 09:54:21 <chmod755> phantomcircuit, nothing special
180 2015-06-26 09:54:31 <phantomcircuit> weird
181 2015-06-26 09:58:00 <jtimon> cfields does this make sense to you? https://github.com/bitcoin/bitcoin/pull/5987/files#r33342634
182 2015-06-26 10:25:54 <chmod755> phantomcircuit, I just compiled bitcoin-qt, no firewall rules, same result as before
183 2015-06-26 10:35:19 <chmod755> http://i.imgur.com/KVLBRg9.png
184 2015-06-26 10:58:11 <warren> LeMiner: saw my link?
185 2015-06-26 10:58:39 <warren> LeMiner: you can use iptables to automate blocking of IP's or entire subnets who connect too many times simultaneously
186 2015-06-26 12:25:10 <jtimon> 1) #6124 is merged tomorrow
187 2015-06-26 12:25:10 <jtimon> 2) the code gets ready, reviewed, tested and merged in 1 week
188 2015-06-26 12:25:10 <jtimon> 3) we don't reach the 95% to start enforcing bip66
189 2015-06-26 12:25:10 <jtimon> sipa I have a question about the bits-version proposal: let's imagine that...
190 2015-06-26 12:25:10 <jtimon> we can still start voting on bip65 without bip66 having being resolved, right?
191 2015-06-26 12:25:40 <jtimon> (obviously the example dates came out of a hat)
192 2015-06-26 12:35:37 <jonasschnelli> Does anyone see a reason why CWallet::SyncTransaction() needs a cs_main lock? https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L765
193 2015-06-26 12:46:39 <wumpus> jonasschnelli: I don't know - maybe in that function, or one of the deeper functions it cells, some operations on the transaction/block that require the lock (that eg check the active chain)?
194 2015-06-26 12:46:47 <wumpus> s/cells/calls
195 2015-06-26 12:47:06 <jonasschnelli> okay... will try to follow...
196 2015-06-26 12:50:05 <jtimon> never mind about assumption #1, 6124 just got merged (thanks wumpus!)
197 2015-06-26 12:52:21 <jtimon> I'm almost sure the answer is yes because only tthe bits that have not been used already can be used, just wanted to confirm
198 2015-06-26 12:53:08 <wumpus> jtimon: with the bits proposal it would be possible to have multiple unconflicting softforks in flight, yes
199 2015-06-26 12:53:39 <jtimon> wumpus I meant, specifically bip66 in flight with the newer changes
200 2015-06-26 12:54:16 <jtimon> but thanks, yes, I think the answer is yes as well
201 2015-06-26 12:54:27 <wumpus> not sure about that, no
202 2015-06-26 12:57:05 <phantomcircuit> http://bitcoin.sipa.be/ver-2k.png
203 2015-06-26 12:57:09 <phantomcircuit> that looks pretty likely
204 2015-06-26 12:59:14 <jtimon> "Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible." https://gist.github.com/sipa/bf69659f43e763540550
205 2015-06-26 12:59:14 <jtimon> #mechanism
206 2015-06-26 12:59:14 <jtimon> yeah, I'm almost sure now, but sipa gmaxwell petertodd can confirm
207 2015-06-26 13:01:40 <phantomcircuit> jtimon, using nVersion = 4 i think blows 1 bit
208 2015-06-26 13:02:47 <jtimon> yes, if we use the old mechanism for bip65 we lose one parallel bit forever, that's the main argument in favor waiting for the code for the new mechanism
209 2015-06-26 13:04:24 <phantomcircuit> jtimon, the question then becomes how long would it take to get that code written
210 2015-06-26 13:06:02 <jtimon> I believe it will be a small patch and the question will really be how long to get that code reviewed and tested but until I see the code I can only guess
211 2015-06-26 13:20:04 <wumpus> jonasschnelli: agree with your lastest comment
212 2015-06-26 13:20:41 <jonasschnelli> I see his points.... but this could go endless. :)
213 2015-06-26 13:21:30 <wumpus> yes - the point of a pull request is to submit your code changes, and the point of reviews is to find defects in the code, not request even more features :p
214 2015-06-26 13:22:55 <phantomcircuit> jonasschnelli, there's already support for banning via rpc right?
215 2015-06-26 13:23:05 <jonasschnelli> phantomcircuit: in master: yes.
216 2015-06-26 13:23:09 <jtimon> well, some of the nits are clearly useful, like the __func__ thing and history really gets simpler if not left for later, but 1000 nits can will a PR just like 1000 bees can kill a person
217 2015-06-26 13:23:27 <jtimon> s/will/kill
218 2015-06-26 13:23:57 <wumpus> sure, nits can be useful too. But diapolo does go over the top quite often.
219 2015-06-26 13:27:30 <jtimon> yeah, I wonder how much is he using pushing to the trivial branch
220 2015-06-26 13:29:31 <jtimon> btw, half of these things would stop being a concern if we started to do a pre-major-version clang-format and it started to make sense for devs to configure it as automatic in their IDEs
221 2015-06-26 13:30:41 <phantomcircuit> jtimon, haha ide
222 2015-06-26 13:30:42 <phantomcircuit> lol
223 2015-06-26 13:30:55 <phantomcircuit> that's funny
224 2015-06-26 13:31:19 <jtimon> well I was trying to be inclusive I use emacs and I assume you use vim
225 2015-06-26 13:31:42 <jtimon> those are IDEs too
226 2015-06-26 13:32:41 <jtimon> or independelty of whether they are or not, they can configure an on-save format just like eclipse or any other "IDE"
227 2015-06-26 13:34:01 <jtimon> and btw, I would make "right before the major release branch fork" the "perfect time for big code movements" and in that period (2 weeks per major release) I would mostly focus and code movements
228 2015-06-26 13:34:19 <jtimon> 2 weeks per major releas?
229 2015-06-26 13:35:27 <jtimon> right now that period it's supposed "right after the major release branch fork" or maybe "right after a major release", I'm not sure yet
230 2015-06-26 13:36:59 <jonasschnelli> "clang-format" can also be used from cmd line. I think a clever guy could also manage to run it before a "git commit".
231 2015-06-26 13:37:13 <jtimon> but I think it's more better if it's right before, then you can backport those movements to the previous version to simplify any rebase from that previous version
232 2015-06-26 13:37:50 <michagogo> I think there was trouble with different versions of clang-format or different platforms or something giving different results, wasn't there?
233 2015-06-26 13:38:37 <jtimon> jonasschelli exactly is not rocket science, but until it is done periodically or at least once project-wide, if you do so you will "fix" too many things, certainly more thhings than the lines you've just touched
234 2015-06-26 13:40:46 <wumpus> I've used clang-format in the past with some slicing and dicing to just format functions that I was adding
235 2015-06-26 13:43:39 <jonasschnelli> michagogo: right. different clang-format version gave out slightly different formatting.
236 2015-06-26 13:55:00 <jtimon> jonasschnelli: "slightly different formatting" we have a common file specifying the format
237 2015-06-26 13:55:00 <jtimon> wumpus can I reuse your command to do that? clang-format staged changes?
238 2015-06-26 13:56:31 <jonasschnelli> jtimon: but last time we tried to format everything (whole source tree) we found out that the formatting was different between minor version changes of clang-format but with the same .clang-format config file (the one we keep in git)
239 2015-06-26 13:57:07 <jonasschnelli> jtimon: see https://github.com/bitcoin/bitcoin/pull/5387
240 2015-06-26 13:57:37 <wumpus> yes, multiple versions would 'fight' against each other
241 2015-06-26 13:57:44 <wumpus> even with the same config file
242 2015-06-26 14:02:24 <wumpus> would need to 'bless' a certain specific version to make formatting the entire source base work, which already makes it less practical
243 2015-06-26 14:03:11 <btcdrak> jtimon: are we really going to have 29 simultaneous softforks though? once deployed the bits become free again
244 2015-06-26 14:04:38 <michagogo> wumpus: tag 6342/3 for 0.11?
245 2015-06-26 14:04:40 <michagogo> label*
246 2015-06-26 14:04:55 <michagogo> Or milestone? Whatever it's called
247 2015-06-26 14:04:58 <wumpus> well you can never know about the future, some softforks may run for a very long time, but with the current number of proposals 29 is certainly enough
248 2015-06-26 14:06:46 <jtimon> well, yeah, 29 simultaneus softforks seems unlikely so maybe we want to use less for that and have some free for something else (though not using the nex mechanism would still be a bit lost forever)
249 2015-06-26 14:06:59 <jtimon> btcdrak
250 2015-06-26 14:08:43 <btcdrak> jtimon: clearly we need to increase the number of bits before the sky falls :-P I'll start lobbying on r/bitcoin
251 2015-06-26 14:09:42 <wumpus> heh.
252 2015-06-26 14:10:51 <wumpus> michagogo: I'll let that up to cfields
253 2015-06-26 14:11:15 <michagogo> wumpus: Oh, can he also tag? No problem.
254 2015-06-26 14:11:26 <jtimon> btcdrak they could be increased from 29 bits to 8 bytes and then double every few years until we get to the needed 8 KB in 20 years
255 2015-06-26 14:11:33 <michagogo> (just hold off on rc3 until then?)
256 2015-06-26 14:11:44 <wumpus> I don't think so, but he should comment on it, I don't really mind
257 2015-06-26 14:13:31 <michagogo> wumpus: I feel like at least the first set of changes (release-process only) should go in, and it's better to do that before the first tag that's built with the detached signature process (when the process is changing anyway) than to have another change later
258 2015-06-26 14:14:40 <michagogo> I mean, unless there's a good explanation for the discrepancy, the second set should also, but as mentioned, I can't really make the required changes myself atm
259 2015-06-26 14:38:36 <cfields> jonasschnelli: around?
260 2015-06-26 14:39:09 <cfields> jonasschnelli: if we change the gitian output around a bit, will that mess up your current automated build stuff?
261 2015-06-26 14:39:41 <cfields> if not, i guess michagogo's right and it makes sense to unify the process once, then maybe we won't have to touch it again for a while
262 2015-06-26 14:40:22 <michagogo> cfields: we're changing it anyway, aren't we?
263 2015-06-26 14:40:48 <cfields> michagogo: as-is, it's just an extra step
264 2015-06-26 14:41:14 <michagogo> Oh, right
265 2015-06-26 14:41:25 <michagogo> Since we're outputting the same files
266 2015-06-26 14:42:03 <michagogo> (and since the OS X introduction of detached signing coincided with a bigger overhaul of that build IIRC)
267 2015-06-26 14:42:23 <cfields> yea
268 2015-06-26 14:42:26 <michagogo> cfields: It just seems to me like it would be really confusing to have signed/unsigned with the same name
269 2015-06-26 14:46:30 <cfields> michagogo: yea, it's not straightforward. It was just kept as-is because I didn't want to change the process around yet again. I'm sure it's annoying for builders to have to use a new process each time. But with the changes you proposed, it's possible that we wouldn't need to change it again for quite a while i should think.
270 2015-06-26 14:54:04 <michagogo> cfields: And anyone who's building for release *will* need to change
271 2015-06-26 14:54:14 <michagogo> (well, if they want to be maximally useful)
272 2015-06-26 14:54:39 <michagogo> We could in theory take it a step further and put the win detached sig thing into the repo
273 2015-06-26 14:54:43 <michagogo> or maybe the deps system
274 2015-06-26 14:54:49 <michagogo> to eliminate that pair of wgets
275 2015-06-26 14:55:07 <michagogo> I mean, that's what we do for OS X, right?
276 2015-06-26 15:00:54 <cfields> michagogo: yea, but that's because osx requires our toolchain and sdk to build the attacher
277 2015-06-26 15:01:37 <cfields> it wouldn't make sense for gitian to upload all of the depends for the win signer just for that
278 2015-06-26 15:01:58 <cfields> (or output a binary for it)
279 2015-06-26 15:12:09 <teward> wumpus: or coffee
280 2015-06-26 15:12:15 <teward> or a nice cup of tea
281 2015-06-26 15:12:35 <michagogo> cfields: upload?
282 2015-06-26 15:12:39 <wumpus> yes, that's a good idea
283 2015-06-26 15:12:48 <michagogo> just make sure it's true tea
284 2015-06-26 15:19:30 <mjerr> the CLTV merge, is there any timeframe for when it is available to use in transactions?
285 2015-06-26 15:20:51 <mjerr> with the merge the discussion around it is over, so it comes within the next version?
286 2015-06-26 15:27:42 <wumpus> possibly: the code to verify BIP65 is merged, but there is no softfork in progress to enable it yet. Right now, it can be used for mempool-only testing if you run master.
287 2015-06-26 15:36:22 <mjerr> will it be P2SH only?
288 2015-06-26 15:43:28 <wumpus> no, although no scriptPubkey scripts with the opcode are standard so you'd likely want to use it with P2SH
289 2015-06-26 16:22:07 <cfields> wumpus: are you planning to tag rc3 today? If so, I'll throw together the gitian changes
290 2015-06-26 16:25:34 <wumpus> cfields: yes, but no hurry, I can also do the tagging monday morning instead
291 2015-06-26 16:26:00 <wumpus> it's more important that it works than to tag it asap :)
292 2015-06-26 16:27:40 <wumpus> yes, let's postpone to monday, I'm kind of sleepy at the moment and prone to make some stupid mistake
293 2015-06-26 16:29:18 <cfields> ok, that's fine. I'd like to make the changes that michagogo proposed, but i'll want to run a bunch of builds to be sure a stupid typo doesn't slip in. With any luck, after this the gitian process will be pretty much set in stone.
294 2015-06-26 16:30:12 <michagogo> cfields: famous last words
295 2015-06-26 16:31:10 <wumpus> I somewhat doubt we'll have even that much luck :) But I agree consistency between osx and windows makes sense. There may be one final thing re:signing we may want at some point: signing the executables themselves too, not just the setup.exe
296 2015-06-26 16:31:11 <michagogo> Also, especially if we're making such a bold statement, we probably want some more eyes on the process, to make sure nothing's wrong/could be improved
297 2015-06-26 16:32:27 <wumpus> but to be clear: I'm happy with what we have now for rc3/final
298 2015-06-26 16:32:28 <michagogo> wumpus: yeah, I was thinking of suggesting that, but that may be more trouble than it's worth. Does anyone know if it's standard on Windows to sign executables placed by installers?
299 2015-06-26 16:39:08 <cfields> michagogo: probably prudent to see how app store signing works, since the trend will likely follow that procedure
300 2015-06-26 16:39:20 <cfields> (that's how it goes for osx, anyway)
301 2015-06-26 16:40:31 <cfields> not sure if it's as relevant on windows though, i have no idea how releases are bundled for their app store thingy
302 2015-06-26 17:02:26 <wumpus> I could see it become mandatory at some point that all executables are signed, but right not it's not very relevant, no
303 2015-06-26 17:58:08 <dgenr8> any reason long-running extended tests like pruning.py could not be run last by rpc-tests.sh, so failure in the quicker ones can be found quicker?
304 2015-06-26 18:15:06 <jonasschnelli> dgenr8: i think it would run into a travis timeout.
305 2015-06-26 18:15:17 <jonasschnelli> pruning.py might take up to 30mins (of even more IIRC)
306 2015-06-26 18:19:51 <jonasschnelli> [16:38:37]  <*highlight>
307 2015-06-26 18:20:14 <jonasschnelli> if it messes up my autobuilds, i will fix.. :)
308 2015-06-26 18:21:07 <jonasschnelli> maybe i should also manage to run serval rpc-tests.sh extended version somehow after a nightly build.
309 2015-06-26 18:21:26 <jonasschnelli> s/serval rpc-tests.sh/the rpc-tests.sh
310 2015-06-26 18:21:45 <jonasschnelli> travis should not be the only CI building and testing bitcoin-core.
311 2015-06-26 18:29:36 <sdaftuar> jonasschnelli: what do you think of adding a feature to rpc-tests.sh to allow excluding a test?  i run rpc-tests.sh -extended on master regularly, and smartfees.py seems to fail about half the time these days (due to the issue mentioned in #6297)
312 2015-06-26 18:29:55 <sdaftuar> (i was going to do it myself, but i'm not much of a bash programmer)
313 2015-06-26 18:30:16 <jonasschnelli> sdaftuar: you can add a `#` in front of the smartfees.py line. :)
314 2015-06-26 18:30:28 <jonasschnelli> But yeah. Why not. A -exclude= flag.
315 2015-06-26 18:30:30 <sdaftuar> heh, i know, but i am running what is in master... :)
316 2015-06-26 18:31:25 <sdaftuar> it seems like things break periodically in master, so being able to update a CI system manually to just turn off a test here and there while fixes are in progress would be useful to me at least. (not sure if this is useful to anyone else though)
317 2015-06-26 18:31:34 <jonasschnelli> do you use rpc-test.sh to run serval tests? I guess you no that you can pass a test as argument to only run this test.
318 2015-06-26 18:32:07 <sdaftuar> right now i'm just doing rpc-tests.sh -extended
319 2015-06-26 18:32:25 <sdaftuar> (actually as of this morning i turned off "-extended" because of the smartfees errors)
320 2015-06-26 18:32:30 <jonasschnelli> sdaftuar: -extended is really something which needs to be kicked of before lunch or so.
321 2015-06-26 18:32:57 <jonasschnelli> sdaftuar: so you are running these tests on a extra CI machine?
322 2015-06-26 18:33:52 <sdaftuar> yeah i have a local jenkins instance; i poll for updates to bitcoin/master and run make check && rpc-tests.sh every two hours
323 2015-06-26 18:34:01 <morcos> dgenr8: I agree makes sense to move pruning.py to last in rpc-tests.sh, if not remove it all together.   It's a somehwhat fragile test, but it turned out to be very useful in working on the pruning code.   I don't want to attempt to rework it though until we see where some of these other changes are going to go.  For instance #5943 would break it completely.
324 2015-06-26 18:36:39 <sdaftuar> dgenr8, morcos: are you guys talking about moving pruning.py to be the last "extended" test?  (travis doesn't run any of the extended tests right now)
325 2015-06-26 18:37:21 <morcos> thats what i meant, just so when people run it themselves its faster to cover move tests
326 2015-06-26 18:37:36 <sdaftuar> ok yeah that makes sense to me
327 2015-06-26 18:38:06 <jonasschnelli> the issue with travis as CI is: time matters (we have timeouts and people like to see if travis succeed of fail). It would be nice if your jenkins instance could post the test reports to somewhere.
328 2015-06-26 18:42:10 <sdaftuar> well there's a non-automated process now, where whenever i notice things breaking, i open an issue :) hm, i never thought about making my jenkins instance upload its output, not a bad idea, any suggestions for where to stick that?  would be nice if travis supported a special nightly test build or something that we could use to run all the tests.
329 2015-06-26 18:44:25 <petertodd> jtimon: the nVersion bits proposal sets a high order bit to 1 to soft-fork it into place, so how many old-style soft-the nVersion bits proposal sets a high order bit to 1 to soft-fork it into place, so how many old-style soft-forks we do prior to it has no effect on the number of bits it can use
330 2015-06-26 18:45:48 <jonasschnelli> sdaftuar: i once used (different project) the github wiki as place to auto-post similar automated outputs (in this case it was automatic generated screenshots of a nightly build).
331 2015-06-26 18:54:28 <dgenr8> jonasschnelli morcos sdaftuar: sorry, yes, I only meant last in the extended list
332 2015-06-26 19:23:46 <morcos> sipa: I agree with you re:6331, I was just getting confused and thinking it was a regression, but out of curiousity, why is it hard?  I just naively copied what CCoinsKeyHasher does, and it seemed to work?
333 2015-06-26 20:19:34 <jonasschnelli> <funmode>YESS. Got travis build nr #5000</funmode>
334 2015-06-26 20:22:34 <bad_duck> ls
335 2015-06-26 20:22:48 <bad_duck> hmm, wrong window.. sorry
336 2015-06-26 20:57:16 <LeMiner> http://i.imgur.com/DKqEhUE.jpg
337 2015-06-26 20:57:31 <LeMiner> How are all of those allowed to connect 1 second apart of each other?
338 2015-06-26 20:57:46 <LeMiner> sounds/looks like a bug, or at least something that shouldn't be possible
339 2015-06-26 21:01:49 <C-Otto> is it causing problems?
340 2015-06-26 21:02:12 <LeMiner> A malicious user can fill up all of a nodes connection within 2 minutes, so yes
341 2015-06-26 21:02:22 <C-Otto> ok.
342 2015-06-26 21:02:23 <LeMiner> available connections*
343 2015-06-26 21:45:40 <phantomcircuit> LeMiner, jgarzik did some work to use udp for signaling which wouldn't have this issue
344 2015-06-26 21:45:50 <phantomcircuit> but even then it didn't cover everything
345 2015-06-26 21:46:18 <jgarzik> yah, for bigger messages, you basically have to reinvent TCP over UDP
346 2015-06-26 21:46:31 <jgarzik> which is easily doable, but still a PITA and re-introduces other problems
347 2015-06-26 21:46:47 <LeMiner> it does look like a pretty good attack vector currently...
348 2015-06-26 21:47:29 <phantomcircuit> jgarzik, well probably 99% of real messages are < 64kB
349 2015-06-26 21:47:48 <jgarzik> anything above 1kB rapidly degrades
350 2015-06-26 21:48:02 <jgarzik> because it gets fragmented -> which fails and requires retries under load & attack
351 2015-06-26 21:48:36 <jgarzik> gotta think about the underlying UDP to IP fragment and reassembly
352 2015-06-26 21:48:56 <LeMiner> A connection limit per IP sounds pretty reasonable to start...
353 2015-06-26 21:49:11 <jgarzik> s/IP/class c/ etc.
354 2015-06-26 23:06:39 <gmaxwell> Is there any straight-forward way from the RPC to tell if BIP66 is enforcing status?
355 2015-06-26 23:06:50 <gmaxwell> (short of doing a getblock on the last 1001 blocks?
356 2015-06-26 23:11:59 <phantomcircuit> gmaxwell, dont think so