1 2016-10-22 02:25:43	0|GitHub101|[13bitcoin] 15jtimon opened pull request #8994: Testchains: Introduce custom chain whose constructor...  (06master...060.13-new-testchain) 02https://github.com/bitcoin/bitcoin/pull/8994
  2 2016-10-22 02:33:31	0|gmaxwell|jtimon: regarding your comment in lightning-dev, it's kind of rude to the community here to go around to our end users to advocate a pull request that has been open for 7 minutes.
  3 2016-10-22 02:35:02	0|jtimon|gmaxwell: thanks, noted. I'm poor in netiquette I think
  4 2016-10-22 02:36:01	0|jtimon|I was thinking about them while wrting the btanch though, in my defense
  5 2016-10-22 02:39:43	0|gmaxwell|Sure, and in this case I don't think it answers what they were asking about. Their concern was that they want a globally shared public testnet, but without having a 2000 block reorg every couple months that breaks their stuff. :)
  6 2016-10-22 02:39:54	0|gmaxwell|and having chainparames in a file doesn't really change that.
  7 2016-10-22 03:02:33	0|GitHub9|[13bitcoin] 15TheBlueMatt opened pull request #8995: Add missing cs_main lock to ::GETBLOCKTXN processing (06master...062016-10-fix-getblocktxn-locks) 02https://github.com/bitcoin/bitcoin/pull/8995
  8 2016-10-22 06:58:32	0|wumpus|< gmaxwell> and having chainparames in a file doesn't really change that <- well it could. There's no rule that people can't share chainparams file
  9 2016-10-22 06:59:14	0|wumpus|with chainparams files they could have arbitrarily defined shared testsnets, sharable by just copying a file
 10 2016-10-22 06:59:35	0|wumpus|that's 100% better than having to go through our review process every time whether some network is really worth defining
 11 2016-10-22 07:00:54	0|wumpus|or whether it should burden the codebase forever
 12 2016-10-22 07:01:29	0|wumpus|I really don't understand the opposition to this idea, are you afraid people will make actual altcoins this way?
 13 2016-10-22 07:02:25	0|wumpus|I personally doubt that, as it doesn't let you override things that are not in the codebase in the first place like hash algorithm
 14 2016-10-22 07:03:20	0|wumpus|but imagine: people want some testnet and they can just define it and share it, instead of having to bother us
 15 2016-10-22 07:06:00	0|wumpus|*without* having to compile their own software
 16 2016-10-22 07:08:40	0|btcdrak|I like the idea. Testnet is a mess at the best of times.
 17 2016-10-22 07:10:46	0|btcdrak|It's also testnet, I think giving users a bit of freedom to start/join their own test chain means we dont have to worry as much about it.
 18 2016-10-22 07:11:29	0|wumpus|and the possibilities for the QA tests are also many, e.g. there was some pull to improve testing by changing the halving interval (8623). This was rejected because it burdens the software with special-case options
 19 2016-10-22 07:11:58	0|wumpus|if the parameters are just read from some .json file, no such problem anymore, the test can just define its own parameters
 20 2016-10-22 07:12:16	0|wumpus|btcdrak: exactly
 21 2016-10-22 07:13:27	0|btcdrak|Also, since there is no incentive to mine a testnet, they are always going to be unstable and unusable. I have spent _month_ chasing testnet miners when their stuff breaks, goes offline. It's been utterly impossible. Then you get people like Ver running consensus incompatible stuff on the main testnet making it unusable for everyone else. At least this way
 22 2016-10-22 07:13:27	0|btcdrak|he could test what he wants on a private chain without causing major disruption.
 23 2016-10-22 07:16:04	0|wumpus|yes the mining problem would not be solved by this - I guess for that one we do need limited mining algo choice in the chain file, e.g. a 'fake mining' where the blocks are signed regularly by a central party (that's fine for a testnet)
 24 2016-10-22 07:18:17	0|btcdrak|Well my own opinion is the diff 1 thing is utterly useless, we'd be much better having a per block retarget on testnet if using PoW.
 25 2016-10-22 07:18:38	0|wumpus|the signing key would be in the json, no keys would be hardcoded into the client code, "wumpus signs a block every 10 minutes" fine
 26 2016-10-22 07:18:59	0|btcdrak|oh interesting.
 27 2016-10-22 07:19:48	0|wumpus|yes, you could also choose PoW with some other parameters
 28 2016-10-22 07:20:03	0|wumpus|as long as it is double-SHA256 :-)
 29 2016-10-22 07:21:07	0|btcdrak|I have a very well battle tested fast diff adjustment. Certainly the most accurate one in live deployment.
 30 2016-10-22 07:39:26	0|gmaxwell|wumpus: congrats, you get the jtimon award for not listening.
 31 2016-10-22 07:39:35	0|gmaxwell|wumpus: no one was asking to define more testnets.
 32 2016-10-22 07:40:11	0|gmaxwell|wumpus: they were asking to have a public testnet shared among everyone with predictable blocks and no uncontrolled reorgs.
 33 2016-10-22 07:40:59	0|gmaxwell|If a config file is a good thing or not is not here nor there. I suppose it's fine (except in so far that it cruds up the code with additional indirection to read things that would otherwise be constants).
 34 2016-10-22 07:45:11	0|gmaxwell|Going and telling people, that you're getting this instead when it doesn't do at all what they asked for is insulting.
 35 2016-10-22 07:45:12	0|wumpus|that indirection already exits
 36 2016-10-22 07:45:31	0|wumpus|from the time this CChainParams structure was defined
 37 2016-10-22 07:45:35	0|wumpus|we're just not using it to the fullest
 38 2016-10-22 07:45:49	0|gmaxwell|wumpus: get it out of your head that I'm at all commenting on having the files.
 39 2016-10-22 07:46:31	0|gmaxwell|I don't care, I think it's a pointless feature that we've already lowered the quality of the codebase to enable, but that wasn't the point.
 40 2016-10-22 07:46:34	0|wumpus|sure, but being able to define additional testnets also makes it possible to define more reliable ones, as well as having the wildwest one for testing other things
 41 2016-10-22 07:46:44	0|wumpus|god damnit
 42 2016-10-22 07:47:04	0|btcdrak|well federated signing will go a long way to help that aim. configurable testnets would be an easy way to achieve that
 43 2016-10-22 07:47:09	0|wumpus|YOU don't listen either
 44 2016-10-22 07:47:22	0|wumpus|btcdrak: exactly
 45 2016-10-22 07:47:38	0|gmaxwell|wumpus: glad we have something in common then. :)
 46 2016-10-22 07:47:47	0|wumpus|"lowering the quality of the codebase" why
 47 2016-10-22 07:47:53	0|wumpus|how do you suggest doing that in a better way?
 48 2016-10-22 07:48:08	0|wumpus|can you stop complaining for once? not only what matters to you matters
 49 2016-10-22 07:48:58	0|wumpus|I'm tired of this madness, whatever you do people are going to complain, going to disengage from bitcoin-related things for a while
 50 2016-10-22 07:50:54	0|gmaxwell|There are places where we're making multiple function calls in an inner loop to access a constant integer.
 51 2016-10-22 07:51:41	0|wumpus|most of that gets optimized out as they're inline functions
 52 2016-10-22 07:51:57	0|wumpus|and where not, it usually doesn't matter as it's not used in performance critical loops anyway
 53 2016-10-22 07:54:39	0|wumpus|if it is an actual bottleneck somewhere, I'd like to know of course
 54 2016-10-22 07:56:24	0|gmaxwell|How would we ever no, no one ever checks? we just end up with GetChainparams().GetConsensus().getdarnaninterger() all of the place.. :P but I don't care and I don't know why you think I care.
 55 2016-10-22 07:56:37	0|gmaxwell|please review my commentary earlier. I said _nothing_ negative about having a configuration file.
 56 2016-10-22 07:56:47	0|gmaxwell|It is the case that I'm not impressed by it, but whatever.
 57 2016-10-22 07:57:01	0|gmaxwell|That isn't what I was commenting on.
 58 2016-10-22 07:57:37	0|gmaxwell|I was commenting on jtimon going to people who asked for something specific and telling them that this other thing was what they were getting. Thats all. it creates awkwardness.
 59 2016-10-22 07:59:23	0|wumpus|GetChainparams().GetConsensus().getdarnaninterger() is temporary, the idea is to have the consensus parameters either available (e.g. pass them in) or store them locally
 60 2016-10-22 07:59:49	0|wumpus|this disentangles from using global structures everywhere, which is useful for testing
 61 2016-10-22 08:00:10	0|wumpus|things can be tested in isolation instead of having to take care of all kind of global state that leaks in
 62 2016-10-22 08:00:12	0|gmaxwell|K. Thats reasonable.
 63 2016-10-22 08:01:26	0|gmaxwell|When I commented to jtimon earlier, I didn't have any recent opinions about the indirection, though I did just spend an hour ripping out checkpoints completely before your comments, so I had something to offer when you brought it up.
 64 2016-10-22 08:04:01	0|gmaxwell|I came up with a way to completely eliminate checkpoints-- missing part was how to prevent header flooding attacks-- that I think is deployable. (assuming we're either okay with removing the signature skipping which I still need to benchmark, or we replace it with some not checkpoint thing)...
 65 2016-10-22 08:05:40	0|btcdrak|I do wish we could accelerate the libconsensus work, it's so long and drawn out.
 66 2016-10-22 08:10:23	0|wumpus|that applies to all projects going on, not just libconsensus
 67 2016-10-22 08:10:58	0|wumpus|our development methodology is too slow for handling even all submitted PRs
 68 2016-10-22 08:11:08	0|wumpus|and no, I have no clue how to improve it
 69 2016-10-22 08:12:39	0|wumpus|too much going on for me to handle anymore at least
 70 2016-10-22 08:12:42	0|gmaxwell|tell you what though, -- having lots of things we know we want to do, more than there are hours in a day-- is a lot better problem than the opposite.
 71 2016-10-22 08:13:51	0|wumpus|sure, you have a good point there
 72 2016-10-22 08:16:35	0|wumpus|it's good that things are going faster than ever, but it does expose the bottlenecks in the process
 73 2016-10-22 08:18:06	0|gmaxwell|And we're getting a _ton_ of interesting things done, ... which is a better metric than the ratio of our appetite to our plate. :)
 74 2016-10-22 08:18:09	0|gmaxwell|yea.
 75 2016-10-22 08:18:26	0|gmaxwell|(sorry for the delayed response, turns out wifi doesn't work so well when you rmmod the driver) :P
 76 2016-10-22 08:19:40	0|wumpus|so at least let's try to be understanding of changes other people are trying to do, have some trust in them even if you can't follow them in detail
 77 2016-10-22 08:20:20	0|wumpus|this project became too big for any one person to follow everyone
 78 2016-10-22 08:21:56	0|wumpus|I'm still trying and it only gives me a headache and lack of sleep
 79 2016-10-22 08:27:28	0|wumpus|in any case I'm going to work on GPU drivers a bit more now, still have some outstanding work to do there, maybe I can return to bitcoin with a clearer perspective
 80 2016-10-22 08:32:42	0|Victorsueca|morning
 81 2016-10-22 08:33:41	0|shangzhou|wumpus: I want to thank you and other devs for the ongoing great contributions.
 82 2016-10-22 08:50:59	0|wumpus|shangzhou: thank you
 83 2016-10-22 09:24:51	0|GitHub153|[13bitcoin] 15rebroad closed pull request #8959: Fix sort arrow in peer table (06master...06FixPeerTableSort) 02https://github.com/bitcoin/bitcoin/pull/8959
 84 2016-10-22 11:24:36	0|btcdrak|are there any particular things we need to cover in the segwit migration guide?
 85 2016-10-22 11:27:17	0|gmaxwell|so far the things I'm aware of are peremiter node deployment, and what to do if you're on older debian without a C++11 compiler.
 86 2016-10-22 11:28:59	0|gmaxwell|for the latter, I'm not sure what the answer is.. one option is "use bitcoin.org binaries" but if you have to compile perhaps there is a newer compiler you can install out of the next distro version without breaking things?
 87 2016-10-22 11:32:55	0|btcdrak|i wonder if aj has any insights, ping
 88 2016-10-22 11:33:59	0|btcdrak|which min version of debian has c++11 support?
 89 2016-10-22 11:34:28	0|aj|seems like jessie; the bitcoin.org binaries seemed to work fine for me in a chroot
 90 2016-10-22 11:37:20	0|gmaxwell|wheezy doesn't and I had a couple of companies mention this to me, they don't seem too concerned about it but we should have some guidance. I'm pretty sure the binaries will work fine, and I can test... but if there is also an option for people who need/want to compile that would be good too.
 91 2016-10-22 11:37:43	0|btcdrak|they could always use the gitian build process to make binaries if they are more paranoid.
 92 2016-10-22 11:38:33	0|gmaxwell|may be a product of customization instead of paranoia, but hm indeed, use the same process to build static binaries on another system would also work.
 93 2016-10-22 11:39:09	0|aj|i don't see any updated gcc versions in backports
 94 2016-10-22 11:39:15	0|btcdrak|gmaxwell:  have you looked at the draft blog post and migration stuff harding has been working on?
 95 2016-10-22 12:02:22	0|wumpus|yes a depends build on another system with the same architecture should be sufficient
 96 2016-10-22 12:02:35	0|wumpus|(or alternatively a  depends cross-compile)
 97 2016-10-22 12:04:55	0|wumpus|also configure with LDFLAGS=-static-libstdc++
 98 2016-10-22 12:05:50	0|btcdrak|Is this a random travis fail? https://travis-ci.org/bitcoin/bitcoin/jobs/169675967
 99 2016-10-22 12:05:53	0|wumpus|but that should be all, using the full gitian process should not be necessary if you're just building binaries for yourself
100 2016-10-22 12:06:48	0|wumpus|yes there seem to be random travis failires at the moment with p2p-compactblocks.py, does it pass locally?
101 2016-10-22 12:06:57	0|btcdrak|strangely enough, Travis offers me a "restart job" button, which I can press and it says "successfully restarted job" but nothing happens.
102 2016-10-22 12:07:24	0|wumpus|I pushed it too...
103 2016-10-22 12:17:47	0|btcdrak|wumpus: p2p-compactblocks.py passes locally for me on that PR.
104 2016-10-22 12:54:09	0|wumpus|ok
105 2016-10-22 14:42:57	0|Victorsueca|so the next release is the final one? or we will have another rc?
106 2016-10-22 14:55:00	0|btcdrak|If there are no blockers, next release will be final
107 2016-10-22 14:56:49	0|wumpus|the final release before the end of the world
108 2016-10-22 14:59:48	0|Victorsueca|lol
109 2016-10-22 15:01:04	0|Victorsueca|the end of the world.... as we know it and the beginning of the decentralised currency era! buy bitcoin know while your fiduciary money is still worth something!
110 2016-10-22 15:01:27	0|Victorsueca|wumpus: just converted your sentence into a commercial :D
111 2016-10-22 16:08:56	0|PRab|FYI, I'm running RC2 on Windows 10 64bit and it appears to be working correctly.
112 2016-10-22 16:21:10	0|PRab|Hm... Did something in RC2 change about minimizing/closing?
113 2016-10-22 16:22:09	0|PRab|I think something must have. Before when I clicked the X, it would go into the notification tray. Now it just goes into the taskbar.
114 2016-10-22 16:22:44	0|PRab|I just tried a bunch of the combinations in options->Windows and can't figure out how to make it do the old behavior any more.
115 2016-10-22 16:25:36	0|MarcoFalke|PRab: Please see the release notes
116 2016-10-22 16:25:58	0|MarcoFalke|(GUI section)
117 2016-10-22 16:27:59	0|PRab|https://github.com/bitcoin/bitcoin/blob/0.13/doc/release-notes/release-notes-0.13.0.md ?
118 2016-10-22 16:28:11	0|PRab|I can't find any specifically for 0.13.1
119 2016-10-22 16:29:14	0|achow101|PRab: 0.13 branch doc/release-notes.md
120 2016-10-22 16:29:59	0|luke-jr|it's not really done yet
121 2016-10-22 16:30:19	0|luke-jr|has some very misleading/confusing language about segwit
122 2016-10-22 16:30:24	0|MarcoFalke|But the minimize/close fix is menitioned
123 2016-10-22 16:30:36	0|MarcoFalke|I think that is what PRab was looking for
124 2016-10-22 16:31:04	0|PRab|Checking it out.
125 2016-10-22 16:31:50	0|achow101|PRab: did you check the "Minimize to tray instead of taskbar" option?
126 2016-10-22 16:31:51	0|PRab|Your talking about - #8481 `d9f0d4e` Fix minimize and close bugs (adlawren), right?
127 2016-10-22 16:32:03	0|PRab|achow101: Yes.
128 2016-10-22 16:32:32	0|PRab|I like the old behavior where Minimize sends it to the taskbar and Close sends it to its notification icon.
129 2016-10-22 16:33:24	0|luke-jr|I don't think that was ever intentional XD
130 2016-10-22 16:33:41	0|PRab|Oh... It was nice that way.
131 2016-10-22 16:34:07	0|luke-jr|could open a PR adding it as a well-defined behaviour option
132 2016-10-22 16:35:01	0|luke-jr|eg Close behaviour: [Exit, Minimize, minimize-to-tray]
133 2016-10-22 16:35:03	0|achow101|for me it has always gone into the tray regardless of which button I clicked
134 2016-10-22 16:35:05	0|PRab|is it a bug or intended that if I have both "Minimize to tray..." and "Minimize on close" checked that when you restore it from the tray, it restores minimized?
135 2016-10-22 16:35:17	0|luke-jr|achow101: indeed, must be platform-specific?
136 2016-10-22 16:35:34	0|achow101|luke-jr: seen it on both ubuntu and windows
137 2016-10-22 16:35:51	0|luke-jr|PRab: it should never appear minimized if you have minimize-to-tray
138 2016-10-22 16:36:17	0|PRab|Then that sounds like a bug to me.
139 2016-10-22 16:37:22	0|PRab|I have both checked. I click close and it goes to the tray. I double click the tray and it shows up in the taskbar minimized. Finally I click the taskbar and it restores the actual window.
140 2016-10-22 16:37:43	0|PRab|I realize this is all fairly petty.
141 2016-10-22 16:37:53	0|achow101|that's probably a bug. I just go used to it. that has been around for a while
142 2016-10-22 16:37:58	0|achow101|*got
143 2016-10-22 16:38:07	0|luke-jr|PRab: works fine here; what OS?
144 2016-10-22 16:38:12	0|PRab|Windows 10
145 2016-10-22 23:45:24	0|michagogo|22:19:47 <midnightmagic> :-/  What the hell. Why would my GnuPG key require a matching email in order to show as verified in github.
146 2016-10-22 23:45:43	0|michagogo|Yeah, annoying to me too
147 2016-10-22 23:47:14	0|michagogo|At least they let you just put yourusername@users.noreply.github.com on the key and it works
148 2016-10-22 23:48:14	0|luke-jr|lol