1 2016-10-28 00:00:02	0|midnightmagic|my odroid xu4 has been sync'ing for ..  mm..  four days now I guess. still going, "92%" complete.
  2 2016-10-28 00:00:22	0|midnightmagic|Dunno what the hell anyone saying an rpi is a good node is talking about.
  3 2016-10-28 00:03:50	0|gmaxwell|midnightmagic: they probably never actually brought one up on it.
  4 2016-10-28 00:03:57	0|gmaxwell|Surely no one here has been saying that.
  5 2016-10-28 00:04:06	0|gmaxwell|(besides, pretty inadvisable to run on anything with less than 2GB ram)
  6 2016-10-28 00:04:37	0|sipa|luke-jr: uh
  7 2016-10-28 00:04:48	0|sipa|btcdrak: ^
  8 2016-10-28 00:05:38	0|midnightmagic|gmaxwell: 72h ETA assuming current average verification rate.  yikes.
  9 2016-10-28 00:07:57	0|gmaxwell|luke-jr: whats the server?
 10 2016-10-28 00:10:21	0|luke-jr|https://sendy.bitcoincore.org
 11 2016-10-28 00:15:18	0|owowo|midnightmagic: Get a Banana Pi with 9 core ;)
 12 2016-10-28 00:15:34	0|owowo|*8
 13 2016-10-28 00:17:39	0|tulip|owowo: 4+4 core big.LITTLE processors aren't really ideal.
 14 2016-10-28 00:17:53	0|midnightmagic|owowo: I have an XU4 with 8 cores! It's pretty quick for a little credit-card-area sbc.
 15 2016-10-28 00:18:38	0|owowo|tulip, why not?
 16 2016-10-28 00:20:14	0|sipa|sbc?
 17 2016-10-28 00:20:40	0|gmaxwell|owowo: because they 'little' cores are power efficient but not fast, you normally don't use all 8 at one time.
 18 2016-10-28 00:21:06	0|tulip|it's unclear if the a83t in that Single Board Computer is actually big.LITTLE.
 19 2016-10-28 00:21:41	0|luke-jr|regardless, POWER8 would still be better :p
 20 2016-10-28 00:22:37	0|tulip|ok, I stand corrected, it does actually have 8*a7 cores. in *general* 8 core ARM SoC have been big.LITTLE, which have 4 high power and 4 low power cores with different instruction sets.
 21 2016-10-28 00:22:43	0|owowo|but it works :D
 22 2016-10-28 00:24:49	0|owowo|and the HDD works too, though it crashed with the computer from about 1.6 meters.
 23 2016-10-28 00:25:05	0|owowo|about 5 years ago ;)
 24 2016-10-28 00:38:28	0|BlueMatt|gmaxwell: ok, done
 25 2016-10-28 00:44:39	0|phantomcircuit|gmaxwell: i restarted a node at ~tip of master
 26 2016-10-28 00:44:52	0|phantomcircuit|a huge number of inbound connections claim to be 0.13.1
 27 2016-10-28 00:44:57	0|phantomcircuit|which seems a bit fast
 28 2016-10-28 00:45:15	0|gmaxwell|phantomcircuit: preferential peering.
 29 2016-10-28 00:48:51	0|sipa|i see a large number of /BTCC:0.13.1/ with 00000001 service bits
 30 2016-10-28 00:50:35	0|gmaxwell|oh fake nodes, fake nodes.
 31 2016-10-28 00:51:08	0|gmaxwell|I think all of those ended up on my banlist previously for being fake and connecting to everyone.
 32 2016-10-28 00:52:56	0|aj|"fake nodes, fake nodes, what you gonna do, what you gonna do when they connect to you?" o/ o/
 33 2016-10-28 00:53:13	0|achow101|all those nodes are aws nodes too
 34 2016-10-28 00:53:39	0|sipa|yeah i think they're on my banlist
 35 2016-10-28 01:02:17	0|BlueMatt|gmaxwell: lol
 36 2016-10-28 01:02:26	0|BlueMatt|didnt realize the btcc things were that fake
 37 2016-10-28 01:05:12	0|achow101|the one with the chinese ip is probably the real one. The rest are all aws nodes which seems a little suspicious
 38 2016-10-28 01:23:35	0|shangzhou|I have upgraded my node to 0.13.1
 39 2016-10-28 01:23:51	0|shangzhou|From China Suzhou
 40 2016-10-28 04:31:39	0|achow101|gmaxwell: for the alert key retirement, what about testnet's key?
 41 2016-10-28 04:47:53	0|phantomcircuit|achow101: is there even a separate key
 42 2016-10-28 04:50:02	0|achow101|phantomcircuit: there is. mainnet: https://github.com/bitcoin/bitcoin/blob/0.11/src/chainparams.cpp#L51 testnet: https://github.com/bitcoin/bitcoin/blob/0.11/src/chainparams.cpp#L148
 43 2016-10-28 05:07:58	0|phantomcircuit|interesting
 44 2016-10-28 05:12:14	0|midnightmagic|to.. uh. Whomever? Do you want me to open a new PR re: functional 0.13.1rc3 gitian sig update, or just update the pre-existing one.. or? I've rebuult (in total) the rc3 gitians and actually done a gverify on them against the others available now.
 45 2016-10-28 05:17:00	0|midnightmagic|Well. I'll open a new one. Seems github makes that easier.
 46 2016-10-28 05:44:29	0|tulip|rebroad: the peer in your issue about "already received" is one with a /ViaBTC/ subversion. in a misguided attempt to improve their stale block rate (which they do have, though their pool reports a false "0") they wrote a piece of software which hammers out blocks to peers that don't request it, burning bandwidth in the process.
 47 2016-10-28 05:54:17	0|phantomcircuit|uh
 48 2016-10-28 05:54:27	0|phantomcircuit|so im not exactly 100% on c++ inheritance stuff
 49 2016-10-28 05:54:30	0|phantomcircuit|but i feel like this should work
 50 2016-10-28 05:54:31	0|phantomcircuit|https://0bin.net/paste/f9fapca8fsr46oed#Xkqs57RGuJRtBRJBoX25sqxzW7KAiKjIBZAotGks4gR
 51 2016-10-28 05:58:31	0|gmaxwell|tulip: I've encountered a number of other nodes doing that, wastes a lot of bandwidth. now that we have BIP152 deployed, we should look to banning peers that send unsolicited full blocks.
 52 2016-10-28 05:59:26	0|gmaxwell|perhaps unsolicited CB too (e.g. when they weren't selected to be high bandwidth peers)... though thats less awful.
 53 2016-10-28 06:20:55	0|phantomcircuit|gmaxwell: any ideas
 54 2016-10-28 06:21:14	0|aj|phantomcircuit: you're trying to access a protected member in an instance of the /base/ class
 55 2016-10-28 06:21:25	0|aj|phantomcircuit: if it were an instance of the child class you could do it
 56 2016-10-28 06:22:33	0|phantomcircuit|aj: right so i have to actually replace the CWallet object with a CWalletAccountingTests object
 57 2016-10-28 06:24:44	0|aj|phantomcircuit: or you could declare CWalletAccounttests a friend class? i don't see any other ways...
 58 2016-10-28 06:25:44	0|phantomcircuit|hmm
 59 2016-10-28 06:26:07	0|phantomcircuit|now i need to find where pwalletMain is intialized during testing
 60 2016-10-28 06:26:44	0|aj|wallet/test/wallet_test_fixture.cpp?
 61 2016-10-28 06:27:05	0|aj|but you might be able to use reinterpret_cast in a way that's not too horrific
 62 2016-10-28 06:28:06	0|phantomcircuit|yeah
 63 2016-10-28 06:31:02	0|aj|phantomcircuit: http://0bin.net/paste/xjooaSxyMVgrJfAe#-BDbENY7Ld4HMIkB7O3nIAuSdSQpIuDo03jLJh1MnU8 maybe
 64 2016-10-28 06:36:47	0|phantomcircuit|yeah i can do that but....
 65 2016-10-28 06:37:16	0|aj|...you don't like the taste of vomit? :)
 66 2016-10-28 06:51:45	0|phantomcircuit|aj: indeed
 67 2016-10-28 08:42:00	0|phantomcircuit|the problem is more so that pwalletMain is a thing i guess
 68 2016-10-28 10:45:52	0|Bi_|Hi. Can someone please help me to understand one of the unit tests / script_tests
 69 2016-10-28 10:45:59	0|Bi_|Its then one
 70 2016-10-28 10:46:21	0|Bi_|that is called "Basic P2WSH"
 71 2016-10-28 10:46:49	0|Bi_|My main question is: is the script expected to fail or pass?
 72 2016-10-28 10:50:12	0|Bi_|Because in script_tests.json file I see "OK" for this test vector. But looking how the script gets executed (from script_tests.cpp) I see it actually failing. But the test itself is passing, like it was expecting the script to fail
 73 2016-10-28 10:54:55	0|phantomcircuit|Bi_: there are tests which pass when the test fails intentionally
 74 2016-10-28 10:55:20	0|Bi_|phantomcircuit, yes I know it
 75 2016-10-28 10:55:49	0|Bi_|Bus is this such a one?
 76 2016-10-28 10:56:21	0|phantomcircuit|no idea
 77 2016-10-28 10:56:24	0|phantomcircuit|it should say
 78 2016-10-28 10:58:08	0|Bi_|Well, in the jason file it says "OK" - so I'd assume it's expecting OK from the script function
 79 2016-10-28 10:58:26	0|Bi_|But that's not what I see it getting from the script function
 80 2016-10-28 11:50:20	0|GitHub119|13bitcoin/06master 14169bdab 15instagibbs: Return useful error message on ATMP failure
 81 2016-10-28 11:50:20	0|GitHub119|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fea5e05a6380...0dcb888266ea
 82 2016-10-28 11:50:21	0|GitHub119|13bitcoin/06master 140dcb888 15Wladimir J. van der Laan: Merge #9016: Return useful error message on ATMP failure...
 83 2016-10-28 11:50:37	0|GitHub28|[13bitcoin] 15laanwj closed pull request #9016: Return useful error message on ATMP failure (06master...06atmperror) 02https://github.com/bitcoin/bitcoin/pull/9016
 84 2016-10-28 12:15:40	0|GitHub65|[13bitcoin] 15laanwj closed pull request #8989: [Qt] overhaul smart-fee slider, adjust default confirmation target (06master...062016/10/qt_slider) 02https://github.com/bitcoin/bitcoin/pull/8989
 85 2016-10-28 12:16:01	0|GitHub166|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0dcb888266ea...d2143dc937e3
 86 2016-10-28 12:16:02	0|GitHub166|13bitcoin/06master 14004168d 15Jonas Schnelli: CoinControl: add option for custom confirmation target
 87 2016-10-28 12:16:02	0|GitHub166|13bitcoin/06master 146f02899 15Jonas Schnelli: [Qt] Hide nTxConfirmTarget behind WalletModel
 88 2016-10-28 12:16:03	0|GitHub166|13bitcoin/06master 14cfe77ef 15Jonas Schnelli: [Qt] overhaul smart-fee slider, adjust default confirmation target
 89 2016-10-28 12:20:02	0|GitHub64|[13bitcoin] 15laanwj opened pull request #9036: wallet: Change default confirm target from 2 to 6 (06master...062016_10_txconfirmtarget) 02https://github.com/bitcoin/bitcoin/pull/9036
 90 2016-10-28 12:58:49	0|tinkerbell11_|lots of places shouting about november 15th startdate for checking flags.. but dates are meaningless.. anyone know the first blockheight where checking will begin??
 91 2016-10-28 12:58:56	0|tinkerbell11_|eg 440,000?
 92 2016-10-28 13:08:56	0|aj|probably block 441504 would be the first block where the 95% test could theoretically pass; so around dec 3rd for earliest conceivable lockedin?
 93 2016-10-28 13:11:07	0|btcdrak|New blog post by aj on Segwit Costs: https://bitcoincore.org/en/2016/10/28/segwit-costs/
 94 2016-10-28 13:12:18	0|wumpus|jonasschnelli: do you know why do we still change payTxFee globally in the GUI when there's a perfectly usable fOverrideFeeRate in coincontrol?
 95 2016-10-28 13:14:14	0|wumpus|seems like an unnecessary source of potential conflicts
 96 2016-10-28 13:14:52	0|wumpus|btcdrak: great!
 97 2016-10-28 13:21:19	0|aj|wumpus: fwiw bitcoin 0.13.1 is in debian unstable now too.
 98 2016-10-28 13:21:36	0|wumpus|aj: okay
 99 2016-10-28 13:21:57	0|timothy|archlinux too
100 2016-10-28 13:22:33	0|btcdrak|Viva la revolución!
101 2016-10-28 14:52:06	0|BlueMatt|wtf is pnodeLocalHost?
102 2016-10-28 14:52:50	0|BlueMatt|looks like we maintain a persistent connection to ourselves?
103 2016-10-28 14:53:05	0|BlueMatt|cfields_: ^?
104 2016-10-28 15:03:07	0|BlueMatt|lol, fibre test network reliable much? https://imgur.com/a/W3dhx
105 2016-10-28 15:03:14	0|BlueMatt|flat top to the graph is amazing
106 2016-10-28 15:06:59	0|kanzure|axis labels plz
107 2016-10-28 15:09:44	0|BlueMatt|oops, heh, cut off the explination text
108 2016-10-28 15:11:08	0|BlueMatt|anyway, left axis is ms from first-recv to which the 1st, 2nd, 3rd, etc node received the block...so T1-T4 (the bottom 4 lines) are pretty noisy because it depends on where things entered the network....T5 is super flat, meaning the network is highly reliable in terms of time take to transmit around the globe
109 2016-10-28 15:11:47	0|sipa|it's an exponential scale
110 2016-10-28 15:11:48	0|BlueMatt|note log scale, but its still super flat ignoring that...just under 180ms almost always, with peaks reaching 190/195
111 2016-10-28 15:11:57	0|sipa|ok
112 2016-10-28 15:16:32	0|aj|BlueMatt: which lines correspond to the right hand axis?
113 2016-10-28 15:17:00	0|BlueMatt|honestly i have nfc wtf the right axis is, none of the lines correspond to it
114 2016-10-28 15:17:04	0|BlueMatt|would have to go read the source
115 2016-10-28 15:17:10	0|aj|haha, awesome
116 2016-10-28 15:19:14	0|cfields_|BlueMatt: yea, we do. I've never gotten around to asking why, kept assuming i'd bump into the reason. Still haven't though.
117 2016-10-28 15:19:51	0|BlueMatt|wtf....
118 2016-10-28 15:20:37	0|cfields_|BlueMatt: i've always assumed the intent was to be able to query our own node state in the same place as the others
119 2016-10-28 15:21:05	0|BlueMatt|that sounds like some satoshi-era bullshit right there :p
120 2016-10-28 15:21:19	0|cfields_|BlueMatt: well it's completely made up, just my best guess :)
121 2016-10-28 15:21:24	0|cfields_|but yes, let's kill it
122 2016-10-28 15:22:08	0|cfields_|BlueMatt: i'll nuke it after the PR that changes message sending around? Otherwise killing it would stomp on that i believe
123 2016-10-28 15:22:23	0|BlueMatt|yes, agreed, no rush there
124 2016-10-28 15:22:26	0|BlueMatt|reviewing that one now :)
125 2016-10-28 15:22:31	0|BlueMatt|(thats why i saw it)
126 2016-10-28 15:22:37	0|cfields_|figured
127 2016-10-28 15:22:44	0|cfields_|BlueMatt: need to double-check all accounting to make sure it doesn't +1 something important
128 2016-10-28 15:22:59	0|BlueMatt|yea
129 2016-10-28 15:34:40	0|phantomcircuit|kanzure: he's lying it's kittens/time
130 2016-10-28 15:35:20	0|kanzure|thank you.
131 2016-10-28 15:35:36	0|BlueMatt|that is a strange unit
132 2016-10-28 15:37:29	0|phantomcircuit|kittens over time?
133 2016-10-28 15:37:58	0|BlueMatt|kittens strangled? kittens hugged? kittens adopted?
134 2016-10-28 15:38:32	0|phantomcircuit|so in all seriousness
135 2016-10-28 15:38:36	0|phantomcircuit|pwalletMain
136 2016-10-28 15:38:42	0|BlueMatt|needs to die?
137 2016-10-28 15:38:55	0|phantomcircuit|that isn't used internally in CWallet or CWalletDB is it?
138 2016-10-28 15:38:58	0|phantomcircuit|(also yes)
139 2016-10-28 15:39:38	0|phantomcircuit|i went to wrap CWallet in a class for the tests so i can make a bunch of methods protected and ran into pwalletMain being global for tests and normal use
140 2016-10-28 15:43:00	0|BlueMatt|it shouldnt be? is it really?
141 2016-10-28 15:51:20	0|phantomcircuit|BlueMatt: yeah...
142 2016-10-28 15:51:23	0|phantomcircuit|wallet.h
143 2016-10-28 15:51:40	0|BlueMatt|thats not "used", just defined
144 2016-10-28 15:51:44	0|BlueMatt|move the definition?
145 2016-10-28 15:52:01	0|phantomcircuit|it's used in accounting_tests.cpp
146 2016-10-28 15:52:38	0|phantomcircuit|and is initialized in wallet_test_fixture.cpp
147 2016-10-28 15:54:22	0|phantomcircuit|afaict those are the only things which even use the CDB::MakeMock stuff
148 2016-10-28 15:54:27	0|phantomcircuit|and they aren't really
149 2016-10-28 16:01:48	0|BlueMatt|https://www.reddit.com/r/Bitcoin/comments/59rlgq/ubuntu_bitcoin_core_ppa_updated_to_0131/d9bjp5z/
150 2016-10-28 16:01:59	0|BlueMatt|anyone got an idea why the fuck that assert would trigger???
151 2016-10-28 16:13:47	0|wumpus|no clue,my guess would be database corruption
152 2016-10-28 16:14:10	0|gmaxwell|It's a common place where DB corruption manifests. Perhaps we should change that from an assert to be something telling you to reindex.
153 2016-10-28 16:14:14	0|gmaxwell|https://github.com/bitcoin/bitcoin/issues/5670
154 2016-10-28 16:14:34	0|gmaxwell|https://github.com/bitcoin/bitcoin/issues/7258
155 2016-10-28 16:14:46	0|gmaxwell|https://github.com/bitcoin/bitcoin/issues/6196
156 2016-10-28 16:14:48	0|wumpus|probably
157 2016-10-28 16:15:55	0|wumpus|I think it ends up there if things are missing in the block index
158 2016-10-28 16:16:28	0|BlueMatt|cfields_: ok, reviewed 8708
159 2016-10-28 16:16:32	0|BlueMatt|gmaxwell: heh, ok
160 2016-10-28 16:19:31	0|gmaxwell|BlueMatt: did you see my comment from last night that perhaps we should be banning peers that send us an unsolicited block message now that we have compact blocks? (perhaps also unsolicited CB when that peer is not requested for HB mode, but I think thats less important)...  there are a number of peers on the network which 'helpfully' send blocks without asking, causing some n-fold bandwidth inc
161 2016-10-28 16:19:37	0|gmaxwell|rease (esp for blocks only nodes).
162 2016-10-28 16:20:07	0|BlueMatt|gmaxwell: i did not, but I'm not against it particularly
163 2016-10-28 16:21:53	0|BlueMatt|I'd like to nominate https://github.com/bitcoin/bitcoin/pull/9026 (well, a variant of it, because that is gonna end up adapting to some reorgs that are in-progress) for 0.13.2
164 2016-10-28 16:23:47	0|gmaxwell|With 9026 will peers still get banned if the block fails the stateless checks (e.g. bad pow)?
165 2016-10-28 16:24:00	0|BlueMatt|i think that is the intention?
166 2016-10-28 16:24:25	0|gmaxwell|k
167 2016-10-28 16:24:30	0|BlueMatt|not with the current implementation, i think, but could be done
168 2016-10-28 16:24:38	0|BlueMatt|and i think maybe should
169 2016-10-28 16:25:15	0|BlueMatt|anyway, i think sdaftuar might be waiting for #8969 and the commits i posted based on it yesterday to tweak it, since it simplifies it
170 2016-10-28 16:26:20	0|cfields_|BlueMatt: https://github.com/theuni/bitcoin/commits/connman-const
171 2016-10-28 16:26:25	0|BlueMatt|though if we backport it....
172 2016-10-28 16:27:29	0|cfields_|BlueMatt: i agree with your nits about locking, so I whipped up the changes in the branch above. I didn't want that PR to creep on forever though, so I was going to add them as a next step. Would you be more comfortable if i tacked them on?
173 2016-10-28 16:27:43	0|BlueMatt|cfields_: that looks sane to me? though i havent audited where we have those strange threading bugs
174 2016-10-28 16:28:19	0|cfields_|BlueMatt: well if they're const, they can't be racy. No need to make things atomic if they can't change.
175 2016-10-28 16:28:28	0|BlueMatt|indeed
176 2016-10-28 16:28:52	0|cfields_|ok, I'll add them to the PR. Thanks for the review.
177 2016-10-28 16:28:55	0|BlueMatt|cfields_: I'd be ok if they're next-step, i think, though i didnt bother to audit if they were possibly correct, it just looked very wrong and i gave up and pointed it out
178 2016-10-28 16:29:03	0|BlueMatt|i dont think you need to
179 2016-10-28 16:29:08	0|BlueMatt|i agree I'd prefer to move the pr forward
180 2016-10-28 16:29:24	0|BlueMatt|i can go audit more fully to figure out if there are any actual bugs introduced
181 2016-10-28 16:29:45	0|cfields_|ok. Well, you can take the branch above as proof that they don't change :)
182 2016-10-28 16:30:23	0|cfields_|BlueMatt: ok, yes, that'd be easier. I was wanting to get gmaxwell/sipa's opinion on deterministic siphash for node nonce first anyway.
183 2016-10-28 16:31:36	0|Victorsueca|gmaxwell: wouldn't that potentially lead to a split network with the nodes that ban peers that send unsolicited blocks on one side and the peers that don't know they're not supposed to send unsolicited blocks on the other?
184 2016-10-28 16:33:14	0|BlueMatt|cfields_: heh, thanks for pointing out that nVersion is already const - your SetVersion violates C++ spec :p
185 2016-10-28 16:33:58	0|BlueMatt|cfields_: https://github.com/bitcoin/bitcoin/pull/8708/files#r85565594
186 2016-10-28 16:34:09	0|cfields_|BlueMatt: same hack we use for serializing tx/block, so i figured i could get away with it :)
187 2016-10-28 16:34:27	0|BlueMatt|cfields_: sipa has open prs to fix it for tx/block :p
188 2016-10-28 16:34:49	0|BlueMatt|soo....no
189 2016-10-28 16:34:50	0|BlueMatt|:p
190 2016-10-28 16:35:41	0|cfields_|BlueMatt: must exist non-const? I'm going to have to call you on that. Going to either learn something or look like an idiot :)
191 2016-10-28 16:36:20	0|BlueMatt|cfields_: i dont recall the exact wording, it either must exist somewhere as non-const reference (so possibly the constructor is enough), or it must exist afterwards as non-const
192 2016-10-28 16:36:36	0|BlueMatt|I'm sure there is something like this in the spec, just not sure if the setting in the constructor qualifies
193 2016-10-28 16:39:16	0|BlueMatt|sipa: might recall better than I
194 2016-10-28 16:43:11	0|cfields_|BlueMatt: thanks, on phone, will take a look in a sec
195 2016-10-28 16:53:33	0|BlueMatt|cfields_: stack overflow, as well as how i read the notes section on cppreference, indicate this is undefined...so folks are stating it clearly as anything defined with const cannot be const_cast'ed, cppreference says "Modifying a const object through a non-const access path...results in undefined behavior"
196 2016-10-28 16:59:20	0|jtimon|am I doing something obviously wrong to get memory access violations in the market lines here https://0bin.net/paste/3ytYmDeGLDb+tlZy#sQXtt4ZyeODcf2u-wuibKPFEr9LsL8hr/bRHSIEVoVr ?
197 2016-10-28 17:01:40	0|BlueMatt|jtimon: secp context not set up?
198 2016-10-28 17:01:55	0|BlueMatt|(ie no ECC_Start call)
199 2016-10-28 17:03:16	0|jtimon|I thought that was done globally for the tests in test_bitcoin.cpp, but let me try
200 2016-10-28 17:03:26	0|BlueMatt|oh, in tests? dunno
201 2016-10-28 17:07:06	0|jtimon|oh, I need to do the BOOST_FIXTURE_TEST_SUITE thing if I want to reuse that ECC_Start, if I do my own it seems to cause conflicts with the other call
202 2016-10-28 17:07:18	0|jtimon|thanks a lot!
203 2016-10-28 17:07:56	0|sipa|BlueMatt: correct... though i'm sure we already violate that elsewhere
204 2016-10-28 17:08:16	0|sipa|BlueMatt: in particular in CTransaction, which i have a PR for to fix
205 2016-10-28 17:08:28	0|BlueMatt|sipa: still, best not to introduce more :p
206 2016-10-28 17:09:11	0|sipa|agree.
207 2016-10-28 17:10:39	0|BlueMatt|still trying to get 8969 in
208 2016-10-28 17:11:12	0|BlueMatt|:p
209 2016-10-28 17:21:06	0|sipa|BlueMatt: can you have a look at 8580?
210 2016-10-28 17:21:11	0|cfields_|BlueMatt: i'll look through again and ack in a min
211 2016-10-28 17:21:27	0|BlueMatt|sipa: lol, needs rebase again :p
212 2016-10-28 17:21:33	0|BlueMatt|but I can look, is that your preferred version?
213 2016-10-28 17:22:24	0|sipa|BlueMatt: i expect the rebase to be trivial
214 2016-10-28 17:22:52	0|cfields_|BlueMatt: mm, how can you move a class with a const member, then? I assumed a const_cast there was correct. Looks like I need to read up.
215 2016-10-28 17:22:55	0|BlueMatt|sipa: k, will look
216 2016-10-28 17:23:34	0|BlueMatt|cfields_: move doesnt specify that the originating object must be invalidated, only that it may be and any future access is undefined?
217 2016-10-28 17:24:31	0|cfields_|BlueMatt: yes, but the target object's const member must be re-assigned
218 2016-10-28 17:25:12	0|BlueMatt|cfields_: hmm? I may be missing what you're referring to with move here
219 2016-10-28 17:25:31	0|cfields_|BlueMatt: nm, not relevant.
220 2016-10-28 17:26:27	0|cfields_|BlueMatt: i'll just give nVersion a const accessor and leave the assert in Set(). I just hope there aren't a million users of pnode->nSendVersion
221 2016-10-28 17:26:41	0|BlueMatt|make it private?
222 2016-10-28 17:26:41	0|cfields_|*i'll just give nSendVersion.
223 2016-10-28 17:26:43	0|cfields_|yea
224 2016-10-28 17:27:36	0|cfields_|oh wait, it already is. that was easy :)
225 2016-10-28 17:27:42	0|BlueMatt|heh
226 2016-10-28 17:30:56	0|sipa|BlueMatt: move must bring the moved-from object in a valid, but not further soecified state
227 2016-10-28 17:31:34	0|sipa|BlueMatt: it *is* allowed to reuse a moved from object if you first use a call that fixes all its observable behaviour again
228 2016-10-28 17:31:37	0|BlueMatt|sipa: yea, thats what i said?
229 2016-10-28 17:32:00	0|sipa|ah, i didn't read the whole conversation
230 2016-10-28 17:32:11	0|BlueMatt|hum, yea, i cant claim to be a C++11 person yet
231 2016-10-28 17:32:12	0|sipa|cfields_: you cannot move an object with a const member
232 2016-10-28 17:32:19	0|BlueMatt|you cant?
233 2016-10-28 17:32:35	0|sipa|well, you can if you fon't modify the source
234 2016-10-28 17:32:45	0|BlueMatt|well, yes, that was my comment
235 2016-10-28 17:32:51	0|sipa|but that would make it a copy
236 2016-10-28 17:33:01	0|BlueMatt|only for that member
237 2016-10-28 17:33:05	0|sipa|right
238 2016-10-28 17:33:10	0|sipa|seems i'm not fully awake yet
239 2016-10-28 17:33:26	0|cfields_|sipa: yes, I see that now. I've always just setup a move operator that does a const_cast and changes. In some places that makes perfect sense. Seems it's not actually to spec, though.
240 2016-10-28 17:33:54	0|cfields_|(again, like our current tx serializers)
241 2016-10-28 17:34:25	0|sipa|cfields_: see 8580 :)
242 2016-10-28 17:34:31	0|cfields_|heh, right
243 2016-10-28 17:34:35	0|BlueMatt|bbl, lunch
244 2016-10-28 17:34:51	0|sipa|there is an annoying confusion between observably constant and representation constness in c++
245 2016-10-28 17:35:03	0|cfields_|i suppose i should review/ack that too, then. adding it to the list.
246 2016-10-28 17:35:59	0|cfields_|sipa: mind explaining the distinction?
247 2016-10-28 20:08:13	0|BlueMatt|sipa: can a constructor call a function which then const_casts?
248 2016-10-28 20:28:50	0|luke-jr|0.13.1 fails tests on sparc64? https://buildd.debian.org/status/package.php?p=bitcoin&suite=sid#problem-6
249 2016-10-28 20:29:54	0|BlueMatt|what the shit
250 2016-10-28 20:30:24	0|BlueMatt|and alpha
251 2016-10-28 20:30:27	0|luke-jr|yeah
252 2016-10-28 20:30:41	0|BlueMatt|similar errors on both
253 2016-10-28 20:32:16	0|sipa|BlueMatt: a bit more detail?
254 2016-10-28 20:32:20	0|luke-jr|looks like they have a few patches, not clear if relevant
255 2016-10-28 20:32:33	0|BlueMatt|sipa: nvm
256 2016-10-28 20:32:37	0|luke-jr|seems like just portability-related
257 2016-10-28 20:38:42	0|ArtGravity|Does anyone know how to fix the bitcoin-qt tray icon and integrated menus in the most recent Trusty client from the Ubuntu PPA?
258 2016-10-28 20:38:53	0|BlueMatt|ArtGravity: ruh roh, they not work?
259 2016-10-28 20:39:08	0|ArtGravity|The tray icon is in the upper left
260 2016-10-28 20:39:17	0|ArtGravity|the integrated menus are MIA
261 2016-10-28 20:39:20	0|BlueMatt|were they working in 0.13.0?
262 2016-10-28 20:39:37	0|ArtGravity|They worked before I upgraded today
263 2016-10-28 20:39:53	0|ArtGravity|I cannot guarantee that I was on 0.13.0, but is likely I was
264 2016-10-28 20:40:01	0|luke-jr|check your debug.log
265 2016-10-28 20:40:47	0|ArtGravity|What am I looking for in ~/.bitcoin/debug.log ?
266 2016-10-28 20:41:02	0|ArtGravity|just version number prior to today?
267 2016-10-28 20:41:08	0|luke-jr|yeah
268 2016-10-28 20:41:34	0|ArtGravity|Confirmed
269 2016-10-28 20:41:38	0|ArtGravity|I was on 0.13.0
270 2016-10-28 20:42:05	0|ArtGravity|The qt-tray icon was in the ubuntu notification area on that version
271 2016-10-28 20:42:33	0|ArtGravity|It's been some time since I have used the menus, so I cannot confirm or deny their presence on that version
272 2016-10-28 20:42:47	0|BlueMatt|ArtGravity: see https://github.com/bitcoin/bitcoin/issues/8043 and https://github.com/bitcoin/bitcoin/issues/7497#issuecomment-182341185 - does removing appmenu-qt5 fix it?
273 2016-10-28 20:43:03	0|BlueMatt|oh, wait, thats non-unity des
274 2016-10-28 20:43:18	0|BlueMatt|anyway, does it look like 8043 for you?
275 2016-10-28 20:43:57	0|ArtGravity|I am on Unity
276 2016-10-28 20:44:15	0|ArtGravity|my icon appears where the B in Bitcoin Core is in the image on 8043
277 2016-10-28 20:44:33	0|ArtGravity|In the top left of the screen
278 2016-10-28 20:44:58	0|BlueMatt|I'm not farmiliar with unity...is that the equivalent of the screenshot in 8043?
279 2016-10-28 20:45:04	0|ArtGravity|I'm not having the missing menu problem
280 2016-10-28 20:45:24	0|ArtGravity|Same desktop environment as in the 8043 screenshot
281 2016-10-28 20:45:32	0|ArtGravity|different symptoms
282 2016-10-28 20:45:49	0|BlueMatt|wait, so whats the bug? that you dont get the file, settings, etc menus?
283 2016-10-28 20:46:10	0|ArtGravity|Tray icon appears in upper left of screen instead of in notification area
284 2016-10-28 20:46:11	0|BlueMatt|cfields_: welp, looks like the ppa is gonna switch back to qt4
285 2016-10-28 20:46:22	0|cfields_|BlueMatt: ?
286 2016-10-28 20:46:38	0|ArtGravity|menus that should appear in the top menu bar of unity are missing
287 2016-10-28 20:46:40	0|BlueMatt|ArtGravity: I really dont know what that means...screenshot? I have no idea where its /supposed/ to show up :p
288 2016-10-28 20:46:53	0|BlueMatt|cfields_: 0.13.1 was the first release with qt5, and if there are bugs gotta go back
289 2016-10-28 20:47:23	0|ArtGravity|in the 8043 screenshot, where it says Bitcoin Core - Wallet at the top left of the screen is where it should have the usual menus
290 2016-10-28 20:47:32	0|ArtGravity|like File, Edit, View, Help, etc
291 2016-10-28 20:47:55	0|BlueMatt|and what does it have there?
292 2016-10-28 20:48:00	0|BlueMatt|the logo
293 2016-10-28 20:48:13	0|BlueMatt|but the menus are in the window, i assume?
294 2016-10-28 20:48:15	0|BlueMatt|ie not missing
295 2016-10-28 20:48:38	0|ArtGravity|Just the logo covering the "Bit" in Bitcoin Core
296 2016-10-28 20:48:40	0|ArtGravity|No menus
297 2016-10-28 20:48:42	0|cfields_|BlueMatt: Ah yea, 0.13 -> 0.13.1 definitely shouldn't switch qt4 -> qt5. I didn't realize 0.13 used qt4.
298 2016-10-28 20:48:51	0|BlueMatt|ArtGravity: anyway, can you file an issue on github?
299 2016-10-28 20:48:56	0|ArtGravity|Yes
300 2016-10-28 20:48:59	0|BlueMatt|ArtGravity: thanks
301 2016-10-28 20:49:02	0|ArtGravity|NP
302 2016-10-28 20:49:02	0|BlueMatt|probably with screenshot
303 2016-10-28 20:49:19	0|BlueMatt|cfields_: well the only way to switch was dropping precise, which i did in 0.13, but only after uploading for others
304 2016-10-28 20:49:23	0|BlueMatt|so this was the first opportunity
305 2016-10-28 20:49:24	0|luke-jr|cfields_: PPA, not gitian binaries
306 2016-10-28 20:49:27	0|ArtGravity|I do have appmenu-qt5 installed
307 2016-10-28 20:49:40	0|BlueMatt|ArtGravity: hmm, try without?
308 2016-10-28 20:49:45	0|BlueMatt|if it works without thats an easier fix
309 2016-10-28 20:49:52	0|ArtGravity|I can try removing that first and see what happens
310 2016-10-28 20:50:01	0|BlueMatt|thanks
311 2016-10-28 20:50:38	0|cfields_|BlueMatt: mm, even if it does work, that's definitely an unexpected change imo
312 2016-10-28 20:50:59	0|BlueMatt|cfields_: it /should/ just be a library change, not anything a user would see
313 2016-10-28 20:51:16	0|ArtGravity|I remember this happening before and doing something to fix it
314 2016-10-28 20:51:27	0|cfields_|BlueMatt: eh? guis and integration are vastly different between qt4 and qt5
315 2016-10-28 20:51:33	0|ArtGravity|My Dogecoin had the problem too
316 2016-10-28 20:53:19	0|cfields_|bbl
317 2016-10-28 20:57:22	0|ArtGravity|w/o appmenu-qt5 I get the menu in the app instead of integrated into Unity
318 2016-10-28 20:57:32	0|ArtGravity|The tray icon still appears in the wrong location
319 2016-10-28 21:02:12	0|BlueMatt|arg, ok, thanks
320 2016-10-28 21:02:15	0|BlueMatt|can you file an issue?
321 2016-10-28 21:02:21	0|ArtGravity|Sure
322 2016-10-28 21:15:03	0|BlueMatt|sipa: ok, you owe me review :p
323 2016-10-28 21:18:18	0|sipa|BlueMatt: this is true.
324 2016-10-28 21:24:52	0|sipa|BlueMatt: the whole reason for needing the stream::Construct<T>() rather than T(Steam&) is nVersion and nType
325 2016-10-28 21:25:09	0|sipa|BlueMatt: the stream determines the value of those
326 2016-10-28 21:25:34	0|sipa|i've argued before that we need to get rid of the nVersion and nType being passed around everywhere, and instead just make them accessors on the stream
327 2016-10-28 21:26:55	0|BlueMatt|sipa: then please do :p
328 2016-10-28 21:27:30	0|sipa|please review 8468 then :)
329 2016-10-28 21:27:57	0|BlueMatt|sipa: I meant just for CTransaction initially
330 2016-10-28 21:28:12	0|sipa|BlueMatt: bleh
331 2016-10-28 21:28:36	0|BlueMatt|sipa: its incredibly shitty to have the Construct<T> stuff there, especially given the random hacks and tons of assert(false) functions
332 2016-10-28 21:28:44	0|sipa|BlueMatt: i agree
333 2016-10-28 21:28:55	0|BlueMatt|so break the shitty api :p
334 2016-10-28 21:41:27	0|BlueMatt|it deserved it
335 2016-10-28 21:42:28	0|Victorsueca|lol
336 2016-10-28 21:54:15	0|GitHub166|[13bitcoin] 15EthanHeilman opened pull request #9037: net: Add test-before-evict discipline to addrman (06master...06test-before-evict) 02https://github.com/bitcoin/bitcoin/pull/9037
337 2016-10-28 22:09:28	0|ArtGravity|BlueMatt: Issue #9038 submitted