1 2016-10-19 00:15:00	0|aj|question: re: https://bitcoincore.org/en/2016/01/26/segwit-benefits/#compact-fraud-proofs -- as it turns out, that didn't make it in, right? those will need an additional merkle tree with an additional coinbase commitment with segwit as implemented, just as they would without segwit, yes/no?
  2 2016-10-19 00:15:51	0|gmaxwell|aj: right, or get picked up as part of some other addition that needs an additional commitment.
  3 2016-10-19 00:17:23	0|gmaxwell|it can be done with 'external commitments' in the same manner as the proposed commited bloom filters... meaning that it's possible to implement the whole software stack, but not get a commitment from the blockchain for it (instead get it from semitrusted servers or what not).. probably a good way to go to work out the design.
  4 2016-10-19 00:19:41	0|gmaxwell|aj: why do you ask?
  5 2016-10-19 00:24:35	0|aj|gmaxwell: have been pondering a companion segwit-costs/risks page, and when reviewing the benefits page thought that one seemed mistaken now
  6 2016-10-19 00:26:55	0|gmaxwell|yea, it's out of date, when god knows who announced segwit would be done in design and implemenation complete in April it just didn't give any time to finalize a design... and better to have fewer commitments than commitments you regret. :)
  7 2016-10-19 00:27:41	0|gmaxwell|they same deployment approach could be used though, so basically a straightforward extension.
  8 2016-10-19 00:30:05	0|GitHub75|[13bitcoin] 15rebroad closed pull request #8958: Improve logic for advertising blocks (06master...06BetterBroadcastLogic) 02https://github.com/bitcoin/bitcoin/pull/8958
  9 2016-10-19 00:30:10	0|GitHub120|[13bitcoin] 15rebroad reopened pull request #8958: Improve logic for advertising blocks (06master...06BetterBroadcastLogic) 02https://github.com/bitcoin/bitcoin/pull/8958
 10 2016-10-19 00:31:47	0|aj|yeah. i thought i remembered some other feature being mentioned that was implemented but wasn't in that list too. not coming to mind immediately though
 11 2016-10-19 00:32:11	0|gmaxwell|I don't think there was anything else.
 12 2016-10-19 00:33:20	0|gmaxwell|maybe the fact that pruned nodes could skip downloading stuff they wouldn't vakidate or keep?  thats stull true though, commitment structure wise.
 13 2016-10-19 00:33:56	0|gmaxwell|maybe you were thinking of the n^2 sighash fix--- for a while that was implemented in the commitment structure but core wasn't making use of it to reduce the hashing, it does now.. however.
 14 2016-10-19 00:48:49	0|aj|gmaxwell: ah, my irc logs remind me that it was the fix for the "sighash single bug" -- but i'm not entirely sure what that bug is precisely
 15 2016-10-19 00:50:45	0|gmaxwell|oh? I don't really consider that much of a bug, it's just a surprising feature. It has some vaguely constructive uses, in theory.
 16 2016-10-19 00:52:05	0|aj|gmaxwell: i think it's that "if you use SIGHASH_SINGLE on an input with a higher index in a transaction than the number of outputs, then that signature can be used by anyone to spend any UTXO sent to that address", but post segwit it can only spend that particular coin?
 17 2016-10-19 00:56:31	0|gmaxwell|aj: thats not incorrect.
 18 2016-10-19 00:56:54	0|aj|haha, high praise
 19 2016-10-19 00:58:08	0|gmaxwell|for non SW txn an out of bound single causes to to sign the 32 byte value 1. For SW it just causes you to sign no particular outputs for that input.
 20 2016-10-19 00:58:25	0|gmaxwell|but you still sign the prevouts.
 21 2016-10-19 01:04:28	0|Victorsueca|gmaxwell: the how is it prevented that somebody changes the outputs?
 22 2016-10-19 01:04:51	0|Victorsueca|then*
 23 2016-10-19 01:14:07	0|gmaxwell|Victorsueca: it's sighash single-- you're specifically flagging the signature so people can change outputs.
 24 2016-10-19 02:10:52	0|Victorsueca|OMG
 25 2016-10-19 02:11:08	0|Victorsueca|A wild bitcoin-qt.exe appeared
 26 2016-10-19 02:11:34	0|Victorsueca|it's finally compiled
 27 2016-10-19 04:49:55	0|tulip|neat, I now have 11 peers with NODE_WITNESS (but all inbound, less than ideal).
 28 2016-10-19 04:54:30	0|gmaxwell|4 on my bog standard host, all inbound.
 29 2016-10-19 04:54:49	0|tulip|that was on my bog standard host, too.
 30 2016-10-19 04:55:37	0|luke-jr|there's probably significantly fewer peers that they'll be willing to connect to
 31 2016-10-19 04:56:15	0|tulip|restarted the patched node and it managed 7/8 outbound peers as segwit, ha.
 32 2016-10-19 04:57:34	0|luke-jr|I thought it won't tolerate non-witness outbound peers at all?
 33 2016-10-19 04:58:36	0|tulip|in r1 you can end up with no NODE_WITNESS peers.
 34 2016-10-19 04:59:04	0|tulip|with #8949 you will continuously search until at least 4 as NODE_WITNESS.
 35 2016-10-19 05:01:54	0|gmaxwell|luke-jr: no, it makes 40 requests to addrman, and if it doesn't get any node_witness results, it gives up and uses a non-nodewitness one.
 36 2016-10-19 05:02:03	0|luke-jr|hm
 37 2016-10-19 05:02:18	0|gmaxwell|it turns out on mainnet there are so many non-nodewitness peers and such.. that it's pretty easy for it to get no node witness outbound peers at all, thus my PR.
 38 2016-10-19 05:18:30	0|luke-jr|what are things coming to, when we can't even find a witness peer anymore? :<
 39 2016-10-19 05:19:11	0|luke-jr|oh wait, that comment was meant for 2026, but this is 2016
 40 2016-10-19 05:20:28	0|jl2012|why 0.13.1rc1 binary is not yet released?
 41 2016-10-19 05:21:43	0|jl2012|aj: re SIGHASH_SINGLE: yes, BIP143 sort of fixed the bug
 42 2016-10-19 05:22:19	0|jl2012|or removed the unintentional "feature" of making a replay-able signature
 43 2016-10-19 05:27:18	0|gmaxwell|jl2012: in the past when we've encountered issues that would call for an RC2 before we shipped the RC1 binary we've sometimes just skipped it. I'm not sure if wumpus is planning on doing that.
 44 2016-10-19 05:35:04	0|btcdrak|jl2012: we are skippng RC1 because of the non version bump iirc
 45 2016-10-19 05:37:06	0|jl2012|btcdrak: it should be announced earlier so people won't waste time on building.....
 46 2016-10-19 05:39:08	0|gmaxwell|good practice? (sorry)
 47 2016-10-19 07:03:43	0|wumpus|it should be announced earlier so people won't waste time on building <- still makes sense to build to make sure that your gitian infrastructure is working an capable of building deterministic 0.13.1 executables
 48 2016-10-19 07:04:09	0|wumpus|also dependencies are cached by gitian so rc2 build will be faster
 49 2016-10-19 07:06:30	0|GitHub108|[13bitcoin] 15laanwj closed pull request #8962: Correct checksum error message (and debug node id) (06master...06CorrectChecksumError) 02https://github.com/bitcoin/bitcoin/pull/8962
 50 2016-10-19 07:08:20	0|GitHub6|[13bitcoin] 15laanwj closed pull request #8957: Additional UpdateBlockAvailability (06master...06AddUpdateBlockAvailability) 02https://github.com/bitcoin/bitcoin/pull/8957
 51 2016-10-19 07:10:13	0|GitHub111|[13bitcoin] 15laanwj closed pull request #8963: NodeId missing from this debug line (06master...06SocketSendErrorNodeId) 02https://github.com/bitcoin/bitcoin/pull/8963
 52 2016-10-19 07:12:29	0|sipa|wumpus: wow, do you sleep?
 53 2016-10-19 07:12:49	0|wumpus|I've slept a bit
 54 2016-10-19 07:13:15	0|wumpus|back to whack-a-mole now...
 55 2016-10-19 07:15:03	0|wumpus|and merging #8951 and tagging rc2 I guess
 56 2016-10-19 07:19:38	0|wumpus|anything else that needs to go into rc2 but doesn't have a 'Needs backport' tag?
 57 2016-10-19 07:20:47	0|wumpus|sipa: better question, do *you* sleep? You're still here afterall :)
 58 2016-10-19 07:21:22	0|tulip|wumpus: #8949 maybe? seems sort of critical.
 59 2016-10-19 07:21:34	0|sipa|8949?
 60 2016-10-19 07:21:46	0|tulip|"Be more agressive in getting connections to peers with relevant services."
 61 2016-10-19 07:21:48	0|sipa|wumpus: currently at the airport
 62 2016-10-19 07:22:27	0|wumpus|thanks added tag
 63 2016-10-19 07:22:42	0|sipa|wumpus: my comment is more aimed "8 hours ago you were merging/closing PRs, and now again" :)
 64 2016-10-19 07:23:05	0|sipa|i'm just hanging out on irc
 65 2016-10-19 07:31:46	0|gmaxwell|I expect 8949 to apply cleanly to 0.13 or nearly so, it's a trivial patch in any case.
 66 2016-10-19 07:41:22	0|wumpus|leave it up to rebroad to come up with lousy suggestions
 67 2016-10-19 07:42:39	0|gmaxwell|what PR?
 68 2016-10-19 07:42:47	0|sipa|8949
 69 2016-10-19 07:43:24	0|gmaxwell|lol
 70 2016-10-19 07:43:53	0|Victorsueca|morning
 71 2016-10-19 07:43:54	0|wumpus|I mean you're runnig a P2P network with decentralized propagation of node addresses, and what would you want to do, query centralized servers automatically periodically? :p
 72 2016-10-19 07:44:02	0|wumpus|morning Victorsueca
 73 2016-10-19 07:44:09	0|gmaxwell|better that he asked instead of submitting a patch "Improve DNSseeding."
 74 2016-10-19 07:44:10	0|btcdrak|yeah wumpus I replied to him
 75 2016-10-19 07:44:21	0|wumpus|true gmaxwell , very true
 76 2016-10-19 07:44:37	0|gmaxwell|had I added the skip I would have written a comment in the code that explained why it was there.
 77 2016-10-19 07:44:49	0|gmaxwell|perhaps I should have done so when editing that section.
 78 2016-10-19 07:44:49	0|Victorsueca|left 0.13.1rc1 running all night
 79 2016-10-19 07:44:54	0|Victorsueca|seems to work good
 80 2016-10-19 07:45:30	0|wumpus|gmaxwell: you could do it at the same time as the c++11 nit if you want, if not I'll just merge it as-is
 81 2016-10-19 07:45:31	0|gmaxwell|Victorsueca: do you have nodewitness peers?
 82 2016-10-19 07:47:43	0|gmaxwell|wumpus: Didn't know if we wanted the range based for. Okay, doing.
 83 2016-10-19 07:47:59	0|wumpus|13 witness peers on ereshkigal, two outgoing, rest incoming
 84 2016-10-19 07:48:07	0|wumpus|gmaxwell: yes,we do :)
 85 2016-10-19 07:48:16	0|wumpus|for new code, absolutely
 86 2016-10-19 07:48:25	0|Victorsueca|gmaxwell: have 4
 87 2016-10-19 07:48:36	0|gmaxwell|Victorsueca: inbound or outbound?
 88 2016-10-19 07:49:34	0|Victorsueca|3 outbound 1 inbound
 89 2016-10-19 07:53:01	0|gmaxwell|will push an update as soon as this compiles.
 90 2016-10-19 07:53:38	0|wumpus|going to kick my non-witness outbound peers until they're witness too :)
 91 2016-10-19 07:54:13	0|Victorsueca|wumpus: lol, you'll hardfork the network if everybody does that
 92 2016-10-19 07:54:35	0|wumpus|Victorsueca: I don't think so, I have plenty of non-witness inbound peers
 93 2016-10-19 07:54:54	0|gmaxwell|Victorsueca: nah, it won't partition due to inbounds-- SW is intended to be witness only on outbound.
 94 2016-10-19 07:55:46	0|gmaxwell|We don't want the topology to suddenly change when SW activates, if something goes wrong it's better if it goes wrong for people as they upgrade.
 95 2016-10-19 07:55:56	0|gmaxwell|and once SW is active we'll need to only fetch new blocks from SW peers.
 96 2016-10-19 07:56:08	0|sipa|Victorsueca: and if that actually happened, we could set up some proxy nodes to relay across (though that is an emergency only, obviously)
 97 2016-10-19 07:57:26	0|wumpus|Victorsueca: though, arguably if everyone did the same things as me it'd be a weird place
 98 2016-10-19 07:57:35	0|gmaxwell|yes, if there are any partioning problems as a result of some oversight there, the partition can be healed by even a single fixed node.
 99 2016-10-19 08:03:16	0|wumpus|it's somewhat working: gained one more outgoing witness peer
100 2016-10-19 08:08:45	0|gmaxwell|I updated #8949 but did not rerun tests locally (laptop slow, took all that time to just compile it. :) )
101 2016-10-19 08:15:20	0|wumpus|gmaxwell: luckily there's travis, and also if you just changes the loop type I'm not terribly afraid of that messing up :)
102 2016-10-19 08:16:39	0|gmaxwell|just letting you know.
103 2016-10-19 08:16:41	0|sipa|it's not like we're merging things and then immediately after marking it as release candidate
104 2016-10-19 08:16:44	0|sipa|oh, wait
105 2016-10-19 08:16:53	0|btcdrak|XD
106 2016-10-19 08:17:39	0|wumpus|noo, we woudl never do something ill-advised like that
107 2016-10-19 08:18:36	0|Victorsueca|lol
108 2016-10-19 08:19:49	0|gmaxwell|maybe we should think about having a non-mandatory beta as part of the process. I noticed RC picked up a lot of testing pretty much instantly.. way more than what we had going on with 0.13 before it.
109 2016-10-19 08:20:48	0|wumpus|non-mandatory beta?
110 2016-10-19 08:21:08	0|wumpus|sounds intruiging, how do you suggest forcing people to install it :)
111 2016-10-19 08:21:40	0|gmaxwell|hah I mean when we think were close to an rc, tagging something as 'beta' as inspiration to get people to switch their attention.
112 2016-10-19 08:21:50	0|wumpus|oh, never mind, NON-mandatory. Boo.
113 2016-10-19 08:21:56	0|gmaxwell|lol
114 2016-10-19 08:22:14	0|gmaxwell|We only have mandatory fun.
115 2016-10-19 08:22:16	0|wumpus|well the good news is that we can use the word 'beta' now in releases
116 2016-10-19 08:22:24	0|rebroad|is testnet broken?
117 2016-10-19 08:22:27	0|Victorsueca|if you think more testing is required then the beta release is pretty much mandatory
118 2016-10-19 08:22:39	0|wumpus|as it's no longer a static part of the release naming, as it used to be
119 2016-10-19 08:23:57	0|gmaxwell|rebroad: looks fine to me, can you be more specific?
120 2016-10-19 08:24:31	0|rebroad|My node and my peers are al stuck on block 998938
121 2016-10-19 08:24:40	0|rebroad|all
122 2016-10-19 08:24:54	0|rebroad|have raised an issue for it
123 2016-10-19 08:25:33	0|gmaxwell|rebroad: why are you saying they're stuck?
124 2016-10-19 08:25:50	0|rebroad|based on their reported startheight and my last new best
125 2016-10-19 08:26:21	0|gmaxwell|if your height is 998938 and all of their height is 998938 ... then perhaps you are all one big happy family.
126 2016-10-19 08:26:32	0|rebroad|have been for over an hour now
127 2016-10-19 08:26:38	0|tulip|receive version message: /Satoshi:0.11.0/: version 70002, blocks=1002280
128 2016-10-19 08:26:50	0|Victorsueca|rebroad: have you considered the possibility that 998938 is the best block right now?
129 2016-10-19 08:27:06	0|gmaxwell|it looks like the best block to me.
130 2016-10-19 08:27:10	0|tulip|rebroad: that's pretty normal for testnet though, and even the main network, frequently there's no blocks for hours at a time.
131 2016-10-19 08:27:17	0|gmaxwell|may just be no one is actively mining at the moment.
132 2016-10-19 08:27:42	0|rebroad|I am seeing many headers for higher heights though
133 2016-10-19 08:28:07	0|Victorsueca|maybe testnet is hard-forked
134 2016-10-19 08:28:15	0|gmaxwell|Yes, and?
135 2016-10-19 08:28:21	0|Victorsueca|that's why some nodes have a higher height
136 2016-10-19 08:28:42	0|Victorsueca|there's nothing to do with that
137 2016-10-19 08:28:45	0|gmaxwell|it has been for something like 6 months now, rogerver's "bitcoin.com" pool.
138 2016-10-19 08:28:47	0|rebroad|why isn't my node sending getdata requests for headers that are new to the block index though?
139 2016-10-19 08:29:00	0|gmaxwell|Not being sent by witness peers.
140 2016-10-19 08:29:06	0|tulip|that's not really a good view to have as your first diagnosis. testnet is very frequently completely hosed, it's par for the course.
141 2016-10-19 08:29:35	0|rebroad|unless proof of work is too low or something.. i guess more debug is needed
142 2016-10-19 08:30:09	0|rebroad|AcceptBlockHeader returns true and AddToBlockIndex was called... but it needs more debug to debug
143 2016-10-19 08:30:37	0|Victorsueca|"needs more debug to debug" -genius
144 2016-10-19 08:32:37	0|rebroad|either it's broken or my understanding is wrong. probably the latter
145 2016-10-19 08:34:02	0|sipa|rebroad: < gmaxwell> Not being sent by witness oeers.
146 2016-10-19 08:36:38	0|GitHub170|13bitcoin/06master 14a1919ad 15R E Broadley: Report NodeId in misbehaving debug
147 2016-10-19 08:36:38	0|GitHub170|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/05998da5a7e2...1230890a6d04
148 2016-10-19 08:36:39	0|GitHub170|13bitcoin/06master 141230890 15Wladimir J. van der Laan: Merge #8936: Report NodeId in misbehaving debug...
149 2016-10-19 08:36:48	0|GitHub189|[13bitcoin] 15laanwj closed pull request #8936: Report NodeId in misbehaving debug (06master...06NodeIdWhenMisbehaving) 02https://github.com/bitcoin/bitcoin/pull/8936
150 2016-10-19 08:39:24	0|gmaxwell|https://www.blocktrail.com/tBTC appears to be having fun, it's a non-SW testnet explorer and it seems to be jumping back in forth between different chains.
151 2016-10-19 08:39:59	0|wumpus|we have a blocktrail contact
152 2016-10-19 08:41:35	0|gmaxwell|pretty interesting to reload it and watch the block numbers constantly change but continue reading 1 hr 48m ago.
153 2016-10-19 08:42:24	0|gmaxwell|may be nothing wrong there, I currently don't have any non-SW testnet nodes, but that chain may be flapping around in a reorg war.
154 2016-10-19 08:42:24	0|wumpus|hehe
155 2016-10-19 08:44:24	0|GitHub181|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1230890a6d04...e44753c06794
156 2016-10-19 08:44:25	0|GitHub181|13bitcoin/06master 144630479 15Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
157 2016-10-19 08:44:25	0|GitHub181|13bitcoin/06master 149583477 15Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
158 2016-10-19 08:44:26	0|GitHub181|13bitcoin/06master 14e44753c 15Wladimir J. van der Laan: Merge #8949: Be more agressive in getting connections to peers with relevant services....
159 2016-10-19 08:44:39	0|GitHub25|[13bitcoin] 15laanwj closed pull request #8949: Be more agressive in getting connections to peers with relevant services. (06master...06more_agressive_witness_connect) 02https://github.com/bitcoin/bitcoin/pull/8949
160 2016-10-19 08:48:10	0|Victorsueca|has somebody actually tried to fill a block over 1MB on testnet too see if the whole witness thing works and doesn't hard-fork the chain due to a invalid block size?
161 2016-10-19 08:48:34	0|aj|Victorsueca: https://testnet.smartbit.com.au/blocks?sort=size
162 2016-10-19 08:49:02	0|tulip|Victorsueca: you're not being at all helpful by continuously saying that.
163 2016-10-19 08:49:32	0|Victorsueca|tulip: when did I say it previously?
164 2016-10-19 08:49:50	0|Victorsueca|aj: thanks
165 2016-10-19 08:50:12	0|wumpus|SegWit has been extensively tested, if  we weren't sure "the whole witness thing works" it certainly wouldn't have been merged
166 2016-10-19 08:50:53	0|Victorsueca|wumpus: I guess so, just couldn't find any block that went over 1MB
167 2016-10-19 08:51:00	0|wumpus|and certainly no activation parameter would have been set on mainnet
168 2016-10-19 08:51:02	0|gmaxwell|Victorsueca: yes, there are many very large blocks on testnet (and segnet before it)
169 2016-10-19 08:51:26	0|gmaxwell|Victorsueca: https://testnet.smartbit.com.au/block/0000000000000896420b918a83d05d028ad7d61aaab6d782f580f2d98984a392
170 2016-10-19 08:51:35	0|wumpus|Victorsueca: sure, then just ask a question, instead of injecting fud into it
171 2016-10-19 08:52:01	0|Victorsueca|wumpus: sorry, didn't mean to FUD stuff
172 2016-10-19 08:52:40	0|wumpus|okay :)
173 2016-10-19 08:54:04	0|GitHub172|[13bitcoin] 15MarcoFalke opened pull request #8972: [Qt] make warnings label selectable (06master...06Mf1610-qtWarnSelJS) 02https://github.com/bitcoin/bitcoin/pull/8972
174 2016-10-19 08:55:37	0|btcdrak|wumpus: rubensayshi and afk11 are Blocktrail contacts
175 2016-10-19 08:56:07	0|btcdrak|but Blocktrail isnt segwitty, so use https://testnet.smartbit.com.au/ for the time being
176 2016-10-19 08:56:35	0|wumpus|btcdrak: thanks
177 2016-10-19 08:57:52	0|rebroad|MarcoFalke, how did you find that commit by jonasschnelli to fix #8970 so quickly?!
178 2016-10-19 08:58:32	0|MarcoFalke|out of memory :P
179 2016-10-19 08:58:32	0|wumpus|search the current pulls / issues before opening a new one
180 2016-10-19 08:59:33	0|MarcoFalke|rebroad: I think it helps if "trivial" pull don't come in massive batches. If you see there is still a "trivial" pull open on your name, make sure to queue up additional ones locally.
181 2016-10-19 08:59:36	0|GitHub169|13bitcoin/06master 1459daa58 15Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help
182 2016-10-19 08:59:36	0|GitHub169|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e44753c06794...b2df292e341d
183 2016-10-19 08:59:37	0|GitHub169|13bitcoin/06master 14b2df292 15Wladimir J. van der Laan: Merge #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help...
184 2016-10-19 08:59:46	0|MarcoFalke|You can submit a new one when the old one got merged.
185 2016-10-19 08:59:49	0|MarcoFalke|or closed
186 2016-10-19 08:59:51	0|GitHub139|[13bitcoin] 15laanwj closed pull request #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help (06master...06gbt_help_update) 02https://github.com/bitcoin/bitcoin/pull/8951
187 2016-10-19 09:00:05	0|rebroad|MarcoFalke, "locally"?
188 2016-10-19 09:00:11	0|MarcoFalke|on your machine
189 2016-10-19 09:00:21	0|MarcoFalke|in your .git folder
190 2016-10-19 09:00:23	0|wumpus|MarcoFalke: interesting, why did the original change never get merged? it looks fine
191 2016-10-19 09:00:33	0|rebroad|MarcoFalke, you mean some sort of "rate limiting"?
192 2016-10-19 09:00:41	0|MarcoFalke|^
193 2016-10-19 09:00:57	0|MarcoFalke|Jup, we have over 100 open pulls and there is lack of review.
194 2016-10-19 09:00:59	0|wumpus|yes, rate limiting, to avoid DoSing other people
195 2016-10-19 09:02:01	0|rebroad|MarcoFalke, to hold back branches on my end would create more rebase work for me. I tend to work in bursts, so the PRs get raised in bursts too.
196 2016-10-19 09:02:20	0|MarcoFalke|Then wumpus has to go ahead and merge something and later on people complain that there are bugs in master.
197 2016-10-19 09:02:21	0|wumpus|which is fine if the topics of the branches are wildly different
198 2016-10-19 09:02:30	0|btcdrak|each comment, or action taken on the tracker mails 1230 people...
199 2016-10-19 09:02:41	0|MarcoFalke|rebroad: But it seems you don't even compile the changes sometimes
200 2016-10-19 09:02:47	0|wumpus|but if they are the same or simlar (e.g. change a log message) then group them or add them to an existing PR
201 2016-10-19 09:03:04	0|MarcoFalke|Please make sure to put work in a pull before you send it to a thousand people
202 2016-10-19 09:03:20	0|MarcoFalke|at least: compile, run tests, run python tests
203 2016-10-19 09:03:33	0|MarcoFalke|Also, mention the motivation in the commit body or pull body
204 2016-10-19 09:03:47	0|MarcoFalke|(I know I don't do it either, sometimes)
205 2016-10-19 09:04:05	0|MarcoFalke|but it is good practice and helps review
206 2016-10-19 09:04:09	0|wumpus|I don't think there's ever a good reason for one person to submit 8 pulls at once, I'm sure some are similar or part of similar intent
207 2016-10-19 09:04:39	0|wumpus|working on 8 completely disparate things at the same time is beyond the scope of human memory :p
208 2016-10-19 09:05:06	0|rebroad|MarcoFalke, I am sometimes guilty of not compiling after what looks like a very simple rebase...  I do need to revise my workflow admittedly
209 2016-10-19 09:05:13	0|MarcoFalke|I stole the commit from https://github.com/bitcoin/bitcoin/pull/7134/commits
210 2016-10-19 09:05:16	0|MarcoFalke|:P
211 2016-10-19 09:05:53	0|rebroad|MarcoFalke, I am only just starting to familiarise myself with the tests.... do you mean "make check" or something else?
212 2016-10-19 09:06:18	0|MarcoFalke|./qa/pull-tester/rpc-tests.py
213 2016-10-19 09:06:24	0|rebroad|wumpus, "8 pulls at once"? why ever not?
214 2016-10-19 09:06:27	0|wumpus|rebroad: so did #8972 solve your problem?
215 2016-10-19 09:06:48	0|MarcoFalke|We need more people running the pull tester suite, anyway
216 2016-10-19 09:07:34	0|wumpus|rebroad: because a) it comes over as horribly spammy, there are 120 pulls open by many different people, you're monoolizing the pull list with trivial stuff b) as I said above, if there's so many changes you must be able to combine a few as they will share a theme
217 2016-10-19 09:08:24	0|wumpus|'shoot a buckshot at the codebase and see what sticks' is not a strategy for development
218 2016-10-19 09:09:24	0|wumpus|at least not one that respects the time constraints and priorities of other people partaking in the project
219 2016-10-19 09:12:07	0|wumpus|to get started on testing, read https://github.com/bitcoin/bitcoin#automated-testing , it mentions the kinds of tests available
220 2016-10-19 09:14:01	0|rebroad|wumpus, how does it make any difference between raising 1 PR a day, and 7 only on Saturdays?
221 2016-10-19 09:14:17	0|wumpus|please, dont' keep arguing this
222 2016-10-19 09:15:01	0|rebroad|wumpus, you put forward an argument (based on false assumptions) and then complain when I correct those assumptions. I am not interested in hearing your rants.
223 2016-10-19 09:15:11	0|tulip|for anyone following, there's progress on testnet now.
224 2016-10-19 09:15:21	0|wumpus|then just go away
225 2016-10-19 09:25:17	0|GitHub106|[13bitcoin] 15laanwj pushed 3 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/2c0913d0b3e1...7c2bf4b1759b
226 2016-10-19 09:25:18	0|GitHub106|13bitcoin/060.13 1433cd553 15Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
227 2016-10-19 09:25:18	0|GitHub106|13bitcoin/060.13 1491ae0b0 15Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
228 2016-10-19 09:25:19	0|GitHub106|13bitcoin/060.13 147c2bf4b 15Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help...
229 2016-10-19 09:27:47	0|GitHub93|13bitcoin/06master 14ef0c9ee 15Jonas Schnelli: [Qt] make warnings label selectable
230 2016-10-19 09:27:47	0|GitHub93|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b2df292e341d...d736a6eb1f91
231 2016-10-19 09:27:48	0|GitHub93|13bitcoin/06master 14d736a6e 15Wladimir J. van der Laan: Merge #8972: [Qt] make warnings label selectable (jonasschnelli)...
232 2016-10-19 09:27:52	0|wumpus|MarcoFalke:  #8972 for 0.13 too?
233 2016-10-19 09:27:57	0|GitHub37|[13bitcoin] 15laanwj closed pull request #8972: [Qt] make warnings label selectable (jonasschnelli) (06master...06Mf1610-qtWarnSelJS) 02https://github.com/bitcoin/bitcoin/pull/8972
234 2016-10-19 09:28:22	0|MarcoFalke|Should not matter
235 2016-10-19 09:28:48	0|wumpus|ok, going to update the release notes lists and pulling in new translations and tagging rc2
236 2016-10-19 09:30:21	0|gmaxwell|oops.
237 2016-10-19 09:30:30	0|gmaxwell|backport is going to fail to compile.
238 2016-10-19 09:30:45	0|wumpus|we'll hear from travis soon I guess
239 2016-10-19 09:30:47	0|gmaxwell|net.cpp:1718:108: error: ‘nMaxOutbound’ was not declared in this scope if ((addr.nServices & nRelevantServices) != nRelevantServices && (nTries < 40 || nOutbound >= (nMaxOutbound >> 1)))
240 2016-10-19 09:32:44	0|Victorsueca|RIP backport
241 2016-10-19 09:33:37	0|gmaxwell|replace with MAX_OUTBOUND_CONNECTIONS
242 2016-10-19 09:35:29	0|rebroad|Apologies for earlier. I need to learn to get less emotionally involved in my pull requests.
243 2016-10-19 09:36:10	0|wumpus|we all do, np, it's kind of a stressful time and not a good time to pick fights now :)
244 2016-10-19 09:36:35	0|rebroad|oh.. I didn't realise that? stress due to SegWit...? bitcoin related?
245 2016-10-19 09:36:52	0|btcdrak|releases are always stressful. lots to get done.
246 2016-10-19 09:37:03	0|MarcoFalke|rebroad: Also the pull request backlog
247 2016-10-19 09:37:17	0|rebroad|ah ok. will bear that in mind. PRT (pre-release-tension)
248 2016-10-19 09:37:23	0|btcdrak|ha!
249 2016-10-19 09:39:02	0|rebroad|I am inclined to think of the backlog in the same way I think of my browser tabs. I have so many I struggle to keep track of them.. I do need to find a new system to organise them rather than a simple list as they currently are. Perhaps there might be a similar way to organise the issues - i.e. it's not the large number that's the issue but they way they are organised/sorted..?
250 2016-10-19 09:40:30	0|btcdrak|rebroad: well the first thing we can do is be good citizens and consider the whole process - submitting a PR is just one part of the process. Think of reviewers and the effort they have to go through to verify and review. This is why grouping things is important. Etiquette starts from there.
251 2016-10-19 09:40:44	0|rebroad|if there is anything I can do to help make the backlog seem less daunting, please do let me know
252 2016-10-19 09:41:01	0|btcdrak|rebroad: review more PRs
253 2016-10-19 09:41:25	0|btcdrak|review and _test_
254 2016-10-19 09:42:08	0|wumpus|"error: use of undeclared identifier 'nMaxOutbound'; did you mean 'nOutbound'" eh, no thangs clang
255 2016-10-19 09:42:39	0|rebroad|btcdrak, I certainly could do that, although it's hard to know which ones to review and test. is there an easy way to see which ones require greater attention or are the more useful/desired PRs?
256 2016-10-19 09:42:49	0|gmaxwell|wumpus: yea, helpful compiler suggestions: Good news, your code compiles. You really didn't want that nice compiler static analysis to actually help you find bugs, right?
257 2016-10-19 09:43:10	0|btcdrak|rebroad: right, so putting yourself in the POV of the reviewers is very good practice...
258 2016-10-19 09:43:20	0|MarcoFalke|rebroad: Those tagged for 0.14, right now.
259 2016-10-19 09:43:36	0|rebroad|MarcoFalke, ah... great starting point. thanks
260 2016-10-19 09:44:36	0|MarcoFalke|We have also different labels where you can group by. E.g. https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aopen+label%3AP2P
261 2016-10-19 09:50:54	0|GitHub144|13bitcoin/060.13 1453e6196 15Wladimir J. van der Laan: qt: pre-rc2 translations update
262 2016-10-19 09:50:54	0|GitHub144|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/7c2bf4b1759b...0dbc48a5bd83
263 2016-10-19 09:50:55	0|GitHub144|13bitcoin/060.13 140dbc48a 15Wladimir J. van der Laan: nMaxOutbound is MAX_OUTBOUND_CONNECTIONS on 0.13...
264 2016-10-19 09:52:25	0|rebroad|has anyone else notices that the arrows point the wrong way in the peer table in the debug window? I've raised #8959 to fix this
265 2016-10-19 09:52:50	0|rebroad|(the arrows to indicate sort direction)
266 2016-10-19 09:53:13	0|wumpus|I haven't noticed, but don't think I've ever paid close attention to it so it's certainly possible
267 2016-10-19 09:53:46	0|Victorsueca|you mean the ones on the table sort?
268 2016-10-19 09:53:53	0|rebroad|Victorsueca, yes
269 2016-10-19 09:54:26	0|Victorsueca|ahh yeah, I aalways felt weird when sorting that table, now I know why
270 2016-10-19 09:54:38	0|rebroad|I wasn't sure if I fixed it in the best pace. the way I did it makes columns default to descending when you first click to sort them
271 2016-10-19 09:55:09	0|rebroad|which is fine as descending is the more useful for most of the columns, IMHO
272 2016-10-19 09:56:03	0|rebroad|an extra click to make it ascending, of course
273 2016-10-19 09:56:31	0|wumpus|for things such as ping that makes sense, I guess, the only time descending is annoying is in text columns
274 2016-10-19 09:58:04	0|Victorsueca|I think the arrow should be a bit darker to make it more visible, this is pure aesthetics tho
275 2016-10-19 09:58:46	0|wumpus|that's up to your theme
276 2016-10-19 09:59:16	0|Victorsueca|ahh windows theme
277 2016-10-19 10:00:24	0|Victorsueca|but it seems to be rendered as text, why is it lighter than the rest of text?
278 2016-10-19 10:00:26	0|wumpus|I don't know where qt takes the theme from on windows
279 2016-10-19 10:01:08	0|wumpus|in any case it's not something that should be micro-managed, e.g. I have a theme that is pretty much black on black so marking the arrow *darker* would make it invisible :)
280 2016-10-19 10:02:28	0|Victorsueca|that could be solved with a white outline
281 2016-10-19 10:02:40	0|Victorsueca|but anyway, it's ok now, no reason to bother on that
282 2016-10-19 10:03:05	0|wumpus|that's up to the theme, too
283 2016-10-19 10:04:02	0|wumpus|some of the altcoins set up their own qt theme instead of using the system theme, but I think that's kind of pushy, no need to push your asthethic preferences to others
284 2016-10-19 10:04:49	0|Victorsueca|yeah, dogecoin for example uses a funny typography
285 2016-10-19 10:05:04	0|GitHub156|13bitcoin/060.13 146e89360 15Wladimir J. van der Laan: doc: Update release notes for rc2
286 2016-10-19 10:05:04	0|GitHub156|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/6e8936032fb865c0448bec0e0f168e041a586285
287 2016-10-19 10:11:48	0|Victorsueca|3 outbound 2 inbound right now
288 2016-10-19 10:13:16	0|wumpus|4 outbound 10 inbound SW connections here
289 2016-10-19 10:13:34	0|Victorsueca|found a fail on the peers screen
290 2016-10-19 10:13:58	0|Victorsueca|some peers display "via 127.0.0.1:8333" instead of the address bitcoin is bound to
291 2016-10-19 10:15:00	0|gmaxwell|Victorsueca: you have tor HS peers.
292 2016-10-19 10:15:55	0|Victorsueca|tor peers display "via mytoraddress.onion:8333"
293 2016-10-19 10:17:38	0|gmaxwell|Victorsueca: no, _outbound_ hs peers do, inbound ones are 127,0,0,1.
294 2016-10-19 10:17:54	0|Victorsueca|ahh, makes sense
295 2016-10-19 10:18:16	0|tulip|there's no meaningful identifier for them other than "hey there's a tcp connection"
296 2016-10-19 10:18:46	0|gmaxwell|I expect someday we'll listen on a special port for those... and then we'll be able to display "onion" or whatnot.
297 2016-10-19 10:19:08	0|Victorsueca|it's a bit deceptive to invert a "something via something" sentence without explanation
298 2016-10-19 10:21:05	0|Victorsueca|maybe we should rephrase that to "Local address:...." and "Remote address:..."
299 2016-10-19 10:29:14	0|wumpus|yes, listening on a special port would make a lot of sense
300 2016-10-19 10:29:33	0|wumpus|not sure why we haven't chosen to do that esp. for the auto-torcontrol stuff
301 2016-10-19 10:30:26	0|wumpus|another things some hs hosts do is to use alternative localhost interfaces, e.g. 127.0.0.2, but the alternative port is a no-brainer
302 2016-10-19 10:40:24	0|gmaxwell|yea, for autocontrol its especially a no-brainer... other than needing to find another reliably free port.
303 2016-10-19 10:40:52	0|gmaxwell|(it could be ephemeral, but better if not.. if I saw a random listning port on my host I'd be rather concerned. :) )
304 2016-10-19 10:41:15	0|tulip|6667 seems pretty unused.
305 2016-10-19 10:41:15	0|wumpus|won't TCP automatically choose a port for you if you listen() without setting one?
306 2016-10-19 10:41:50	0|tulip|if you attempt to listen on port 0, apparently that's the behaviour.
307 2016-10-19 10:41:57	0|wumpus|oh, random is not good, okay wouldn't know then. Just pick a new fixed one one and put it in chainparams then
308 2016-10-19 10:42:19	0|gmaxwell|just means that when you run multiple daemons on the same network and host, they'll collide.
309 2016-10-19 10:42:33	0|gmaxwell|same as p2p/rpc.
310 2016-10-19 10:43:02	0|wumpus|https://github.com/bitcoin/bitcoin/issues/8973  in the issue I propose ` hsport` option for that
311 2016-10-19 10:43:06	0|tulip|random would also have the weird effect of killing other daemons that try to bind to something after bitcoind
312 2016-10-19 10:43:14	0|gmaxwell|wumpus: sounds great to me.
313 2016-10-19 10:43:31	0|Victorsueca|what about random but exclude common ports?
314 2016-10-19 10:43:37	0|wumpus|why would it kill other daemons?
315 2016-10-19 10:43:50	0|gmaxwell|the special port would also allow more than labling, e.g. preferrential relay to HS peers.. which we can only do for outbound hs peers right now.
316 2016-10-19 10:43:58	0|tulip|wumpus: say bitcoind came up, randomly chose 22, and then openssh tried to come up.
317 2016-10-19 10:44:00	0|wumpus|I'm all for daemon-kiliing functionality in bitcoind, but arguably it should happen intentionally :p
318 2016-10-19 10:44:04	0|btcdrak|is that everything now for rc2?
319 2016-10-19 10:44:13	0|gmaxwell|tulip: it won't randomly choose 22. It will get some port over 32768.
320 2016-10-19 10:44:42	0|tulip|gmaxwell: talking hypothetical, but ok.
321 2016-10-19 10:45:03	0|gmaxwell|kernel reserves some range of ports for ephemeral use that is outside of the range normally used for services.
322 2016-10-19 10:45:11	0|wumpus|I wonder if tor can create some kind of private, non-TCP socket
323 2016-10-19 10:45:24	0|wumpus|anyhow that's not relevant to solving the issue, but for the far future would be nice list
324 2016-10-19 10:45:58	0|tulip|gmaxwell: so there's privileged 1-1023, and >32768 for ephemeral. are there any other ranges?
325 2016-10-19 10:46:04	0|wumpus|btcdrak: I think so!
326 2016-10-19 10:46:20	0|btcdrak|wumpus: my gitian VM is ready!
327 2016-10-19 10:46:52	0|wumpus|tulip: ranges are configurable and depend on the OS, although <1024 private is pretty ingrained (I think windows is an exception there?)
328 2016-10-19 10:46:55	0|gmaxwell|tulip: not coming to mind. keep in mind these are local policy... there are sysctls to change them.
329 2016-10-19 10:47:29	0|gmaxwell|yea, for a long time if you could get access to ports <1024 you could escilate to root access on other hosts that rhosts trusted your host.
330 2016-10-19 10:48:02	0|tulip|I hate to think what caused that to be implemented.
331 2016-10-19 10:49:06	0|wumpus|yeah rsh :-(
332 2016-10-19 10:51:21	0|wumpus|* [new tag]         v0.13.1rc2 -> v0.13.1rc2
333 2016-10-19 10:52:29	0|wumpus|I guess that was a time in which the number of people having enough knowledge to circumvent that was so small that you could just trust them not to do it, sysadmin-inside-knowledge-based-access-control or so:p
334 2016-10-19 10:52:58	0|gmaxwell|wumpus: yea, that time lasted about 10 minutes.
335 2016-10-19 10:56:36	0|wumpus|gmaxwell: yes I can't imagine it taking long. And after that the long period it was (mis)configured by default on some OSes
336 2016-10-19 11:13:18	0|Victorsueca|so... rc2 has gmaxwell's aggressive witness node search right?
337 2016-10-19 11:13:26	0|wumpus|yes
338 2016-10-19 11:18:34	0|btcdrak|that sounds so mafia
339 2016-10-19 11:19:02	0|Victorsueca|lol
340 2016-10-19 11:19:37	0|btcdrak|the node needs a witnesss protection program
341 2016-10-19 11:24:51	0|sipa|bitcoind --aggressive=passive
342 2016-10-19 11:34:52	0|Victorsueca|done building, now starting
343 2016-10-19 11:45:49	0|jonasschnelli|[22:07:48] <wumpus:#bitcoin-core-dev> jonasschnelli: could you elaborate in #8546 what you mean with " I think its acceptable if it breaks wallets used back in 0.3.x in conjunction with IP transaction". I don't think it'd be acceptable if the client suddenly crashes if someone happens to be using a wallet that still has a pay-to-IP transaction in it.
344 2016-10-19 11:45:59	0|jonasschnelli|Yes. Your probably right...
345 2016-10-19 11:46:45	0|jonasschnelli|I don't have enough informations about the field-usage of IP transactions...
346 2016-10-19 11:47:22	0|jonasschnelli|Better keep the code as it is
347 2016-10-19 11:53:17	0|arubi|is it bad to symlink the database directory which is in datadir (contains log.0000000001 like files) to a tmpfs filesystem like /dev/shm ?  It makes things like importing scripts and generating keys much quicker for me, e.g. initial keypool population takes 14418ms vs. 4236ms with the database dir in /dev/shm
348 2016-10-19 11:53:40	0|arubi|I did (superficially with iotop) notice that a lot of writing is done to this log.0000.. file when I import many scripts, so this is why I ask.
349 2016-10-19 12:02:40	0|Victorsueca|7 witness peers now, all outbound
350 2016-10-19 12:19:25	0|wumpus|arubi: I don't know about berkeleydb specifics but having the wallet database crossing filesystem boundaries is reasonably dangerous
351 2016-10-19 12:19:52	0|achow101|was rc1 DOA?
352 2016-10-19 12:20:05	0|wumpus|arubi: also tmpfs is lost on reboot, which means you may lose data
353 2016-10-19 12:22:39	0|arubi|wumpus, yea I'm aware about the second point. thought about copying it back to the hard drive periodically, but didn't take into account if bdb itself might not like it.  I'll rtfm about bdb
354 2016-10-19 12:25:48	0|jonasschnelli|BDB has some really strange way of storing data...
355 2016-10-19 12:26:44	0|jonasschnelli|Look at http://bitcoin.stackexchange.com/questions/48070/format-of-mkey-field-in-encrypted-wallet-dat-file
356 2016-10-19 12:27:20	0|jonasschnelli|I tried to track this down and found out, that the chunks of the records value are stored in different locations.
357 2016-10-19 12:31:29	0|luke-jr|https://curl.haxx.se/mail/lib-2016-10/0076.html sigh
358 2016-10-19 12:32:57	0|arubi|thanks for the lead jonasschnelli
359 2016-10-19 12:44:26	0|wumpus|jonasschnelli: yeah I wouldn't mind changing the 'transaction details' window if anyone has a good plan to do so, but this just seemed like ripping out a few things at semi-random, not sure either whether it would affect things such as watch-only or payment requests
360 2016-10-19 12:44:53	0|jonasschnelli|wumpus: Yes. Indeed.
361 2016-10-19 12:45:00	0|wumpus|with so many more urgent pulls open, it didn't seem worth the bother
362 2016-10-19 12:46:27	0|wumpus|gah instead of building rc2 I re-built rc1
363 2016-10-19 12:46:42	0|wumpus|achow101: yes
364 2016-10-19 12:47:12	0|wumpus|it didn't have the version bumped and BlueMatt discovered a crash issue within a few minutes
365 2016-10-19 12:48:59	0|wumpus|(probably in an RPC command that only he uses, but okay that's clearly a bug that shouldn't be in a release)
366 2016-10-19 12:49:12	0|jonasschnelli|wumpus: what crash? The wallet/init one? https://github.com/bitcoin/bitcoin/pull/8928
367 2016-10-19 12:49:20	0|wumpus|addnode
368 2016-10-19 12:49:45	0|wumpus|#8928 issue doesn't exist in 0.13
369 2016-10-19 12:49:59	0|wumpus|fairly sure it was introduced in the refactoring
370 2016-10-19 12:50:11	0|jonasschnelli|We should extend addnode's RPC tests
371 2016-10-19 12:50:17	0|wumpus|yes
372 2016-10-19 12:52:29	0|jonasschnelli|wumpus: The RPC command-structure refactoring (https://github.com/bitcoin/bitcoin/pull/8788) includes your JSONRPCRequestObj renaming now. Would be nice to get this in soon to escape the rebase-hamster-wheel
373 2016-10-19 12:53:42	0|luke-jr|I still prefer 8775 :x
374 2016-10-19 12:54:09	0|luke-jr|it's just ugly to have request.params everywhere
375 2016-10-19 12:57:55	0|wumpus|I like request.params
376 2016-10-19 12:58:13	0|wumpus|it's literally "request parameters", what naming could be better
377 2016-10-19 12:58:22	0|jonasschnelli|I think request.param improves readability
378 2016-10-19 12:58:26	0|luke-jr|params is clear and much shorter. but whatever
379 2016-10-19 12:58:55	0|jonasschnelli|params is to generic and could be interpreted as local scope var
380 2016-10-19 12:59:13	0|luke-jr|obviously when it comes to taste, majority rules, so if everyone else disagrees, just go ahead and do it
381 2016-10-19 12:59:28	0|wumpus|yes it's a bit of a taste issue
382 2016-10-19 12:59:49	0|jonasschnelli|Right. The important thing is, that we have a flexible container in the RPC command function structure.
383 2016-10-19 13:01:25	0|wumpus|right
384 2016-10-19 13:20:09	0|BlueMatt|who is mining testnet-segwit?
385 2016-10-19 13:20:14	0|BlueMatt|phantomcircuit: or Lightsword, maybe?
386 2016-10-19 13:24:06	0|tulip|BlueMatt: me, problem?
387 2016-10-19 13:25:07	0|GitHub21|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d736a6eb1f91...97c7f7362f9b
388 2016-10-19 13:25:08	0|GitHub21|13bitcoin/06master 1423c32a9 15Wladimir J. van der Laan: rpc: Change JSONRPCRequest to JSONRPCRequestObj...
389 2016-10-19 13:25:08	0|GitHub21|13bitcoin/06master 1469d1c25 15Jonas Schnelli: [RPC] Give RPC commands more information about the RPC request
390 2016-10-19 13:25:09	0|GitHub21|13bitcoin/06master 14e7156ad 15Jonas Schnelli: [RPC] pass HTTP basic authentication username to the JSONRequest object
391 2016-10-19 13:25:17	0|GitHub131|[13bitcoin] 15laanwj closed pull request #8788: [RPC] Give RPC commands more information about the RPC request (06master...062016/09/rpc_container) 02https://github.com/bitcoin/bitcoin/pull/8788
392 2016-10-19 13:28:16	0|BlueMatt|tulip: yes, we havent addnode'd between the new fibre test network and your mining bitcoind :p
393 2016-10-19 13:34:10	0|wumpus|jonasschnelli: darn now #7551 needs rebase again
394 2016-10-19 13:34:23	0|luke-jr|:p
395 2016-10-19 13:39:28	0|wumpus|I really think we should merge that one soon, it's been open for ages and he's been rebasing time after time and fixing load of nits after load of nits. And it has tests. I'm not convinced that it is bugless (it adds a lot of functionality) but it'd probably be better to merge it so it gets more testing.
396 2016-10-19 13:40:03	0|wumpus|but it's very useful functionality that definitely needs to be in 0.14
397 2016-10-19 14:05:29	0|btcdrak|BlueMatt: Lightsword, but he stopped mining yesterday to let cfields test out cgminer I believe.
398 2016-10-19 14:18:17	0|luke-jr|http://arstechnica.com/security/2016/10/flaw-in-intel-chips-could-make-malware-attacks-more-potent/ :/
399 2016-10-19 14:20:49	0|wumpus|the branch prediction profiling makes local attacks (e.g. against the kernel) somewhat easier, ASLR is still a good measure against remote attacks
400 2016-10-19 14:24:18	0|wumpus|also think function-level ASLR (selfrando) would make this harder to exploit, as you cannot just guess one offset and compute others from it
401 2016-10-19 14:25:27	0|wumpus|haven't heard about using that at the kernel level though :)
402 2016-10-19 14:27:12	0|BlueMatt|hey-o, fibre works on segwit
403 2016-10-19 14:27:14	0|BlueMatt|look at that
404 2016-10-19 14:27:21	0|BlueMatt|anyone need high-speed testnet blocks? :p
405 2016-10-19 14:27:37	0|wumpus|awesome!
406 2016-10-19 14:27:49	0|BlueMatt|even worked on the first try :)
407 2016-10-19 14:29:23	0|wumpus|of course we need fast testnet blocks
408 2016-10-19 14:31:59	0|adiabat|repost from wizards, but anyone know what's up with testnet3?
409 2016-10-19 14:32:07	0|adiabat|seem to be 2 chains
410 2016-10-19 14:32:09	0|BlueMatt|what about it?
411 2016-10-19 14:32:23	0|BlueMatt|all my nodes ended up on the same chain when i synced them last night?
412 2016-10-19 14:32:30	0|BlueMatt|adiabat: is classic forked off again?
413 2016-10-19 14:32:36	0|adiabat|could be
414 2016-10-19 14:32:52	0|adiabat|test.webbtc.com is where I can see another one, that's longer
415 2016-10-19 14:33:06	0|adiabat|seems to diverge at 996198, but not sure why
416 2016-10-19 14:33:15	0|BlueMatt|2016-10-19 14:25:57.059547 UpdateTip: new best=00000000000f939a09a192c06dec99490018fa8dc488cb25cc9141612eb57bf2 height=1003480 version=0x20000000 log2_work=68.579739 tx=11657519 date='2016-10-19 14:45:27' progress=1.000000 cache=0.3MiB(1882tx)
417 2016-10-19 14:38:33	0|GitHub143|[13bitcoin] 15s-matthew-english opened pull request #8974: readability improvement (06master...06patch-5) 02https://github.com/bitcoin/bitcoin/pull/8974
418 2016-10-19 14:40:13	0|adiabat|BlueMatt: yeah I'm on that one as well.  Guess it doesn't really matter, just curious why there's a longer (presumably invalid) chain
419 2016-10-19 14:41:48	0|BlueMatt|adiabat: well at least tulip and Lightsword are both mining
420 2016-10-19 14:41:51	0|BlueMatt|maybe they're not peered.....
421 2016-10-19 14:42:28	0|GitHub129|13bitcoin/06master 14fc14609 15mruddy: RPC: augment getblockchaininfo bip9_softforks data
422 2016-10-19 14:42:28	0|GitHub129|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/97c7f7362f9b...5d2c8e524e10
423 2016-10-19 14:42:29	0|GitHub129|13bitcoin/06master 145d2c8e5 15Wladimir J. van der Laan: Merge #7948: RPC: augment getblockchaininfo bip9_softforks data...
424 2016-10-19 14:42:33	0|GitHub154|[13bitcoin] 15laanwj closed pull request #7948: RPC: augment getblockchaininfo bip9_softforks data (06master...06version_bits_locked_in_block) 02https://github.com/bitcoin/bitcoin/pull/7948
425 2016-10-19 14:50:41	0|jonasschnelli|wumpus: Yes. 7551 should go in soon. I gave it my tested ACK (tested pretty well), though, some comments where added/amend-changed afterwards.
426 2016-10-19 14:50:51	0|jonasschnelli|sipa said he want to test it as well (before we merge)
427 2016-10-19 14:51:10	0|jonasschnelli|I think we should merge it and fix (possible) issues later
428 2016-10-19 14:51:16	0|jonasschnelli|but the rebase needs to be done
429 2016-10-19 14:51:48	0|jonasschnelli|I guess 8788 will lead to plenty of rebases
430 2016-10-19 14:58:07	0|btcdrak|Lightsword wanna connect to FIBRE?
431 2016-10-19 15:06:45	0|GitHub37|[13bitcoin] 15MarcoFalke closed pull request #8974: readability improvement (06master...06patch-5) 02https://github.com/bitcoin/bitcoin/pull/8974
432 2016-10-19 15:07:25	0|tulip|adiabat: BlueMatt: 00000000000f939a09a192c06dec99490018fa8dc488cb25cc9141612eb57bf2 is my chain and is valid with 0.13.1. I don't know why webbtc is showing a different one, I noticed that before.
433 2016-10-19 15:08:36	0|GitHub48|[13bitcoin] 15jonasschnelli pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5d2c8e524e10...3e942a7060fe
434 2016-10-19 15:08:37	0|GitHub48|13bitcoin/06master 14178cd88 15Luke Dashjr: Qt/splash: Specifically keep track of which wallet(s) we are connected to for later disconnecting
435 2016-10-19 15:08:37	0|GitHub48|13bitcoin/06master 141880aeb 15Luke Dashjr: Qt: Get the private key for signing messages via WalletModel
436 2016-10-19 15:08:38	0|GitHub48|13bitcoin/06master 143e942a7 15Jonas Schnelli: Merge #8774: Qt refactors to better abstract wallet access...
437 2016-10-19 15:08:50	0|GitHub155|[13bitcoin] 15jonasschnelli closed pull request #8774: Qt refactors to better abstract wallet access (06master...06multiwallet_prefactor_qt) 02https://github.com/bitcoin/bitcoin/pull/8774
438 2016-10-19 15:09:27	0|tulip|I have >30 peers connected to that node, 11 of which are NODE_WITNESS. if there's a peering problem it's unlikely to be mine.
439 2016-10-19 15:29:09	0|GitHub135|[13bitcoin] 15jonasschnelli closed pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (06master...06multiwallet_prefactor_rpc) 02https://github.com/bitcoin/bitcoin/pull/8775
440 2016-10-19 15:34:30	0|Lightsword|btcdrak, sure
441 2016-10-19 15:42:06	0|GitHub16|13bitcoin/06master 14acf853d 15Johnson Lau: Add script tests for FindAndDelete in pre-segwit and segwit scripts
442 2016-10-19 15:42:06	0|GitHub16|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3e942a7060fe...475d68252e9c
443 2016-10-19 15:42:07	0|GitHub16|13bitcoin/06master 14475d682 15Wladimir J. van der Laan: Merge #8927: Add script tests for FindAndDelete in pre-segwit and segwit scripts...
444 2016-10-19 15:42:16	0|GitHub87|[13bitcoin] 15laanwj closed pull request #8927: Add script tests for FindAndDelete in pre-segwit and segwit scripts (06master...06findanddeletetest) 02https://github.com/bitcoin/bitcoin/pull/8927
445 2016-10-19 16:11:44	0|GitHub183|13bitcoin/06master 1437aefff 15Matt Corallo: Fix init segfault where InitLoadWallet() calls ATMP before genesis
446 2016-10-19 16:11:44	0|GitHub183|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/475d68252e9c...c5875773561c
447 2016-10-19 16:11:45	0|GitHub183|13bitcoin/06master 14c587577 15Wladimir J. van der Laan: Merge #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis...
448 2016-10-19 16:11:59	0|GitHub121|[13bitcoin] 15laanwj closed pull request #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis (06master...062016-10-fix-segfault) 02https://github.com/bitcoin/bitcoin/pull/8928
449 2016-10-19 16:30:21	0|goatpig|is someone trolling the testnet?
450 2016-10-19 16:36:25	0|btcdrak|goatpig: what do you mean?
451 2016-10-19 16:41:53	0|goatpig|someone pointed me to a 4k long fork
452 2016-10-19 16:42:36	0|goatpig|got me thinking
453 2016-10-19 16:42:47	0|rabidus_|how did your software manage that? :P
454 2016-10-19 16:42:57	0|goatpig|no idea, someone showed that to me
455 2016-10-19 16:43:15	0|goatpig|so, say i create a SW anyone can spend output
456 2016-10-19 16:43:16	0|goatpig|mine it
457 2016-10-19 16:43:18	0|goatpig|spend it
458 2016-10-19 16:43:32	0|goatpig|that would fork the chain for any 0.13 testnet node
459 2016-10-19 16:43:40	0|goatpig|but 0.12 nodes would see it as valid
460 2016-10-19 16:43:52	0|goatpig|say I throw in a couple asics and mine the hell out of that fork
461 2016-10-19 16:44:00	0|goatpig|I could maintain a testnet fork for a wihle, right?
462 2016-10-19 16:46:33	0|arubi|it really doesn't matter what you do.  sure the partitioning of post fork and pre fork nodes is obvious, but that's any soft fork.  you're really fighting hashpower, which is what pow is about
463 2016-10-19 16:46:52	0|goatpig|im trying to figure out if someone could pull that out on the testnet
464 2016-10-19 16:47:08	0|goatpig|im not concerned about the mainnet because, precisely because of the hashpower competition there
465 2016-10-19 16:47:34	0|arubi|you could probably do that on testnet, sure
466 2016-10-19 16:47:41	0|goatpig|ok
467 2016-10-19 16:51:46	0|Victorsueca|testnet shows "Warning: unknown new rules activate (versionbit 28)
468 2016-10-19 16:51:58	0|Victorsueca|activated*
469 2016-10-19 16:52:27	0|jtimon|oh, rc already?
470 2016-10-19 16:52:32	0|jtimon|oh, rc2 already?
471 2016-10-19 16:53:13	0|Victorsueca|yep
472 2016-10-19 16:56:46	0|wumpus|yes, rc1 was doa
473 2016-10-19 17:00:06	0|wumpus|for rc2 we're actually going to upload executables
474 2016-10-19 17:03:12	0|cbit|I'm getting hit with spy nodes again. Running RC1, and just checked the peers connected after running it all night.
475 2016-10-19 17:05:53	0|GitHub127|[13bitcoin] 15jtimon opened pull request #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/ (06master...060.13-chainparams-init) 02https://github.com/bitcoin/bitcoin/pull/8975
476 2016-10-19 17:22:51	0|btcdrak|testnet is a total mess at the moment. Not sure this diff 1 thing is working out very well.
477 2016-10-19 17:49:28	0|Chris_Stewart_5|Yeah, I was trying to figure out what the heck is going on
478 2016-10-19 17:49:54	0|Chris_Stewart_5|btcdrak: What is the difficult 1 thing?
479 2016-10-19 17:52:54	0|rabidus_|if there is no mined blocks within x minutes, difficulty drops to 1
480 2016-10-19 17:53:21	0|rabidus_|so no one can make difficulty bomb at testnet
481 2016-10-19 17:53:24	0|Chris_Stewart_5|rabidus_: Yes, but blocks are clearly being mined within the 20 minute threshold, unless it was dropped or something
482 2016-10-19 17:55:30	0|cbit|uh. 58 connections off a fresh rc2. Everything inbound: 52.xx.... At least I have 6 outbound witness peers off the bat, one being wumpus ha
483 2016-10-19 18:01:21	0|molz|how can you tell if your node and other nodes are witness nodes or not?
484 2016-10-19 18:02:29	0|rabidus_|i know how to tell that my node is :P
485 2016-10-19 18:03:31	0|molz|mine is  0.13.1rc2 but bitnodes doesn't list it as a witness node
486 2016-10-19 18:04:24	0|goatpig|shoudn't that be advertized in the services?
487 2016-10-19 18:04:46	0|Lauda|cbit just ban it all
488 2016-10-19 18:21:36	0|achow101|wtf. gitian is failing to build the binaries.
489 2016-10-19 18:23:39	0|wumpus|what error? mac/linux/win all built fine here
490 2016-10-19 18:25:09	0|achow101|it fails for all three for me
491 2016-10-19 18:25:38	0|achow101|here's the log starting from actually building the binaries for windows http://pastebin.com/rSDHf76d
492 2016-10-19 18:25:42	0|Victorsueca|windows built correctly here using WSL
493 2016-10-19 18:26:16	0|wumpus|"
494 2016-10-19 18:26:18	0|wumpus|x86_64-w64-mingw32-g++: internal compiler error: Killed (program cc1plus)"
495 2016-10-19 18:26:43	0|wumpus|either out of memory, or memory corruption/CPU overheat
496 2016-10-19 18:27:15	0|wumpus|could also be a compiler bug, but those are extrememly rare, usually it's a hw issue :/
497 2016-10-19 18:27:24	0|rabidus_|hot stuff
498 2016-10-19 18:27:29	0|achow101|ok... The memory is whatever gitian's default is
499 2016-10-19 18:28:44	0|achow101|If it's a hardware issue, i'm not too surprised then. This computer I'm using has some hardware issues.
500 2016-10-19 18:30:35	0|wumpus|you could try with lower parallelism
501 2016-10-19 18:30:57	0|wumpus|-j8 is a lot, esp. if you didn't increase the amount of memory available
502 2016-10-19 18:31:54	0|achow101|ok. I didn't set the -m parameter this time. so I guess I should set that?
503 2016-10-19 18:33:01	0|wumpus|--memory 3000 is recommended by reease-process.md
504 2016-10-19 18:33:13	0|wumpus|that is if you don't change -j from the default
505 2016-10-19 18:34:04	0|achow101|well. I just set it to -j8 and -m 9000 because I have cores and memory to spare
506 2016-10-19 18:54:06	0|btcdrak|i just use -j4 and nothing else, works nicely for me
507 2016-10-19 19:59:03	0|sipa|wumpus: maybe you know: http://bitcoin.stackexchange.com/q/49077/208
508 2016-10-19 20:52:18	0|michagogo|rc2 detached sigs coming soon?
509 2016-10-19 20:56:07	0|michagogo|Oh, right, that's still cfields_
510 2016-10-19 20:56:24	0|michagogo|Why did I think wumpus was doing those these days
511 2016-10-19 20:57:00	0|cfields_|michagogo: will do in a bit, my cpus are tied up atm
512 2016-10-19 21:00:40	0|michagogo|cfields_: np
513 2016-10-19 21:04:03	0|michagogo|cfields_: I think my shell should now be retrying it every 10 minutes until it works
514 2016-10-19 21:04:24	0|michagogo|so whenever you push them up, my result should show up
515 2016-10-19 21:05:19	0|michagogo|(until <myscript>; do sleep 600; done)
516 2016-10-19 21:29:03	0|BlueMatt|so there was a reasonably large performance regression in block acceptance time jeremyrubin found a while back...what are folks opinions on https://github.com/TheBlueMatt/bitcoin/commits/2016-10-fix-tx-regression ?
517 2016-10-19 21:29:17	0|BlueMatt|it switches ProcessNewBlock's block pointer to a shared_ptr to a const CBlock
518 2016-10-19 21:29:46	0|BlueMatt|ehh, fuck it, I'ma just pr it
519 2016-10-19 21:30:35	0|sipa|BlueMatt: which pr caused the regression?
520 2016-10-19 21:30:46	0|BlueMatt|the one where we moved tx wallet callbacks out of main
521 2016-10-19 21:30:53	0|BlueMatt|because now we keep a vector of every tx we connected
522 2016-10-19 21:30:57	0|BlueMatt|which requires lots of copies
523 2016-10-19 21:31:10	0|BlueMatt|solution: keep a shared_ptr to the block itself either as you deserialize it or as you call into ProcessNewBlock
524 2016-10-19 21:31:33	0|BlueMatt|later we should change the CValidationState callback to just take that shared_ptr instead of calling it for each tx
525 2016-10-19 21:31:54	0|sipa|does #8515 affect it?
526 2016-10-19 21:32:40	0|BlueMatt|sipa: I'm talking about txChanged, not txConflicted
527 2016-10-19 21:32:44	0|BlueMatt|so, no
528 2016-10-19 21:32:48	0|sipa|ok
529 2016-10-19 21:32:50	0|BlueMatt|though probably conflicts like a motherfucker
530 2016-10-19 21:33:16	0|BlueMatt|sipa: if you go ahead and rebase that I'll ack it and then we dont have to have two open prs that conflict so much
531 2016-10-19 21:33:20	0|BlueMatt|(if you have time)
532 2016-10-19 21:33:43	0|sipa|BlueMatt: about to land in SF, i can rebase 8515 in a few hours
533 2016-10-19 21:34:14	0|BlueMatt|sipa: alright, I'll hold off until tomorrow
534 2016-10-19 21:34:22	0|BlueMatt|sipa: give gmaxwell a big hug from me :p
535 2016-10-19 21:37:48	0|sipa|:)
536 2016-10-19 22:06:45	0|sipa|achow101: graphics acceleration at 9.81 m/s^2?
537 2016-10-19 22:08:00	0|achow101|:)
538 2016-10-19 22:31:21	0|cfields_|gitian builders: detached sigs for 0.13.1rc2 pushed
539 2016-10-19 22:51:33	0|sipa|test
540 2016-10-19 22:52:12	0|sipa|d_t: yow
541 2016-10-19 22:56:08	0|d_t|sipa: yow
542 2016-10-19 22:56:15	0|sipa|:)