1 2017-02-19 02:15:12	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #8660: txoutsbyaddress index (take 2) (06master...06cozz8) 02https://github.com/bitcoin/bitcoin/pull/8660
  2 2017-02-19 02:33:20	0|fanquake|cfields pushed my signed sigs up. Can try help debug gitian issues during today.
  3 2017-02-19 02:33:38	0|fanquake|Also noticed that zlib doesn't currently build with osx depends builder
  4 2017-02-19 03:02:10	0|luke-jr|re "About Qt": we're using "About %1" now anyway, so the translation issue is presumably gone, and Qt might actually be worth promoting anyway; thinking perhaps what would be an improvement there is to add an "About Bitcoin" :p
  5 2017-02-19 03:10:10	0|gmaxwell|luke-jr: It might be better to put the QT link though on the about bitcoin core page though.
  6 2017-02-19 03:10:21	0|gmaxwell|the about qt thing is really uninteresting.
  7 2017-02-19 03:10:22	0|luke-jr|hmm
  8 2017-02-19 03:10:50	0|luke-jr|so the menu would have About Bitcoin Core and About Bitcoin; and the former's dialog have a link for About Qt?
  9 2017-02-19 03:13:51	0|gmaxwell|I think that would be dandy. I dunno what about Bitcoin would say.
 10 2017-02-19 03:14:14	0|gmaxwell|I think all this is kind of pointless, user use of bitcoin is dying because of sync resource requirements.
 11 2017-02-19 03:16:08	0|luke-jr|true, better things to spend time on esp since the translation issue is basically fixed
 12 2017-02-19 03:31:30	0|gmaxwell|I'd be happy to ack a patch to improve the about messages but I think it's a waste of time to work on that.
 13 2017-02-19 04:50:17	0|BlueMatt|<conman> do you understand the whitelist v addnode thing btw?
 14 2017-02-19 04:50:17	0|BlueMatt|<conman> if I whitelist an IP address and addnode it, when I see it listed in the debug window it has the addnode'd IP there as not whitelisted
 15 2017-02-19 04:51:59	0|gmaxwell|ugh, whitelist is not something conman should want for pratically anything. Addnode (in 0.14 at least) prevents banning, whitelisting adds to that near blindly and redundantly relaying transactions, which is not desirable for him, unless he's now become an armory developer. :P
 16 2017-02-19 04:52:52	0|BlueMatt|yes, i figured, but also it is a strange thing that it doesnt whitelist for outbound
 17 2017-02-19 05:00:23	0|BlueMatt|hum, yea, looks like addnode will only consider itself "connected" if IP:Port matches, not just IP, so if you, eg, addnode bidirectionally you're guaranteed to have two connections (unless the source uses 8333 for source port, which it wont)
 18 2017-02-19 05:00:25	0|BlueMatt|afaict
 19 2017-02-19 05:01:31	0|gmaxwell|yea, bidi results in two connections, I think I had believed there was no strong way to avoid it-- in any case, it's always been true.
 20 2017-02-19 05:02:05	0|BlueMatt|i mean why do we only consider an addnode connected if its the same port?
 21 2017-02-19 05:02:08	0|BlueMatt|might as well just filter by ip?
 22 2017-02-19 05:02:20	0|gmaxwell|now I'm not sure why I was thinking it was hard to avoid. maybe just that being connected to the same IP is not the same as connecting to that IP due to the existance of NATs.
 23 2017-02-19 05:02:44	0|BlueMatt|indeed, though if you addnode its probably fine
 24 2017-02-19 05:02:45	0|gmaxwell|E.g. if you addnode my office, but have some random laptop at my office connected to you, you have not achieved your goal.
 25 2017-02-19 05:03:07	0|gmaxwell|but perhaps it's close enough that the default should be to avoid the duplicate connection...
 26 2017-02-19 05:03:19	0|BlueMatt|yes, that would be my vote
 27 2017-02-19 05:03:22	0|gmaxwell|the other thing is that the addnode connection is privledged in ways that the inbound isn't.
 28 2017-02-19 05:04:06	0|BlueMatt|true, but if the connection gets killed it'll re-open
 29 2017-02-19 05:04:17	0|BlueMatt|possibly as -addnode
 30 2017-02-19 05:04:39	0|BlueMatt|and we can do the same set-host-on-lookup thing we do for other connections and set the addnode flag if we find an applicable inbound connection
 31 2017-02-19 05:06:26	0|gmaxwell|well as I said, inbound != addnode.  This would be much better with authentication keys, since you would know if it was who you thought it was.
 32 2017-02-19 05:07:04	0|BlueMatt|yup, that
 33 2017-02-19 05:09:10	0|gmaxwell|We could have some other kind of cookie based dedupe that worked more robustly.
 34 2017-02-19 05:09:37	0|BlueMatt|true, though im no fan of encouraging more places where you can tie two nodes together as the same one
 35 2017-02-19 05:09:48	0|BlueMatt|i know we have a few places with that and just added more, buttttt
 36 2017-02-19 05:11:24	0|gmaxwell|well kinda hopeless, we should set a bar that we'd like to meet there. Like you shouldn't be able to correlate tor/ipv4+ipv6 as much as we can but otherwise we don't care. And especially shouldn't be able to correlate across restarts as much as we can.
 37 2017-02-19 05:11:36	0|gmaxwell|the current informal method is not working well.
 38 2017-02-19 05:11:49	0|BlueMatt|true
 39 2017-02-19 05:12:09	0|gmaxwell|BlueMatt: and yea, we just added a _smoking hot_ identifier... so kinda moot. without a good framework we're just going to keep undermining ourselves while also missing good functionality.
 40 2017-02-19 05:12:14	0|BlueMatt|i mean where all do we have that? double spend-based net splitting, compact blocks, addr stuff, what else?
 41 2017-02-19 05:12:33	0|BlueMatt|i mean the compact block one is easy to split-by-netgroup
 42 2017-02-19 05:13:02	0|gmaxwell|well lets ask the question, would we want to 'logically' behave like we had two mempools for ipv4 vs tor,  or just give up and say that the strongest property we try to achieve is unlinkablity across restarts?
 43 2017-02-19 05:13:23	0|gmaxwell|Because thats the first choice there, if we're unwilling to do that then the best I think we can do is unlinkability across restarts.
 44 2017-02-19 05:13:27	0|BlueMatt|heh, +/- saving mempool on disk :p
 45 2017-02-19 05:13:53	0|gmaxwell|yea, well peers.dat is the big limitation on restarts right now, in fact. much more than mempool.
 46 2017-02-19 05:14:18	0|BlueMatt|yea, ok
 47 2017-02-19 05:15:30	0|BlueMatt|yea, its a shame keeping multiple peers.dat per-netgroup would kinda defeat the purpose of peers.dat :/
 48 2017-02-19 05:15:35	0|gmaxwell|One of the open questions about mempool sync is do we want to make mempools convergent ... e.g. that you would switch to doublespends under some criteria.  Without that, I think our worst case synchronization bandwidth will always be quadratic.
 49 2017-02-19 05:16:23	0|BlueMatt|yea, good question...i mean we could do some kind of lowest-hash metric, but that seems to amount to a not-by-fee-rbf
 50 2017-02-19 05:16:41	0|BlueMatt|which also sucks, though i suppose the bw usage could be mitigated
 51 2017-02-19 05:17:00	0|gmaxwell|BlueMatt: well the sorting criteria can be {fee,hash} which is basically what I menat by convergent.
 52 2017-02-19 05:17:09	0|BlueMatt|yes, i assumed that
 53 2017-02-19 05:17:24	0|gmaxwell|(or in particular, fee,H(salt,hash)  where salt is a random beacon to avoid being able to grind preferable txn.)
 54 2017-02-19 05:17:52	0|gmaxwell|and the fact that it's non-fee based replacement is actually not harmful... so long as the sync process rate limits itself.
 55 2017-02-19 05:18:04	0|BlueMatt|random how? wouldnt it have to be network-wide? which would mean grindable
 56 2017-02-19 05:18:16	0|BlueMatt|yesyes, generally agreed there
 57 2017-02-19 05:18:23	0|gmaxwell|I think I can show that the bandwidth of that is polylog.
 58 2017-02-19 05:18:53	0|gmaxwell|BlueMatt: e.g. using block hashes, so it would be network wide but your grindablity would be a finite window.
 59 2017-02-19 05:19:36	0|BlueMatt|heh, well you only need to grind a lower hash...that shouldnt take you 10 minutes
 60 2017-02-19 05:20:48	0|BlueMatt|anyway, just means an attacker can always create infinite amount of mempool divergence in a single tx, though they'd have to spend fee to actually put it in a higher-sync-rate-bucket
 61 2017-02-19 05:35:55	0|BlueMatt|lol, recaptcha wasnt working so i tried the "audio version" and it just said "we're sorry, your computer may be sending automated queries, so we cannot process your request"
 62 2017-02-19 05:35:56	0|BlueMatt|fuckers
 63 2017-02-19 05:39:12	0|gmaxwell|better than the google search captcha that just sends you really hard captchas and doesn't let you through no matter what.
 64 2017-02-19 05:39:25	0|BlueMatt|thats what it was doing for the non-audio form, though
 65 2017-02-19 05:39:31	0|BlueMatt|it just kept saying "try again"
 66 2017-02-19 05:40:13	0|gmaxwell|yea, I think google does that intentionally on search... so perhaps they also do on recaptcha.
 67 2017-02-19 05:41:07	0|BlueMatt|yea, likely, except they give it away if you try to switch to audio
 68 2017-02-19 05:42:07	0|gmaxwell|Same shadowbanning BS that reddit does, so profoundly anti-social. The hope is to make spammers waste their time/money, and it ignores the people they harm when there is a false positive.
 69 2017-02-19 05:42:46	0|BlueMatt|hum, im thinking its just straight up broken, doesnt work on a different browser/ip either
 70 2017-02-19 06:39:39	0|achow101|cfields: I fixed the osx build. I finally fixed the fucking osx build. All I had to do was make a new base vm. it only took me the better part of the last 3-4 hours to figure out that vmbuilder has a bug and that I had a zombie vm screwing things up
 71 2017-02-19 12:05:24	0|wumpus|luke-jr: well I managed to screw up my base image, wouldn't be the first time, I do some optimizations to speed up the "upgrading operating system" step, I don't think there's any reason to dig deeper
 72 2017-02-19 12:05:42	0|luke-jr|ah
 73 2017-02-19 12:05:57	0|luke-jr|I just worry that the "rebuild base" solution is prone to malware getting in
 74 2017-02-19 12:06:05	0|luke-jr|otoh, so is the updating step
 75 2017-02-19 12:06:07	0|wumpus|if you feel like digging deeper I may be able to dig up my old base image and send it to you but I relaly don't have the time
 76 2017-02-19 12:06:39	0|luke-jr|nah, probably not worth it all things considered
 77 2017-02-19 12:06:52	0|luke-jr|if we weren't autoupdating, maybe, but we are
 78 2017-02-19 12:07:19	0|wumpus|there's just no way to do this properly as long as we're not using a deterministically built OS for building
 79 2017-02-19 12:07:33	0|luke-jr|right
 80 2017-02-19 12:09:08	0|wumpus|I think it's more curious that making a new base image solved achow101 osx non-determinism - we have no reliance on the OS's build tools in that
 81 2017-02-19 12:09:15	0|wumpus|at least I had three versions of gcc installed :)
 82 2017-02-19 12:09:31	0|luke-jr|indeed
 83 2017-02-19 12:12:15	0|wumpus|please just leave the "About Qt" link where it is, that's a common fixturefor all Qt programs and it's useful to be able to see what version of Qt is used for troubleshooting problems
 84 2017-02-19 12:12:51	0|wumpus|there's no reason at all to remove it, it's not like we lack space in that menu and absolutely need to change something
 85 2017-02-19 12:14:03	0|Arvidt|) is  expired
 86 2017-02-19 12:14:04	0|luke-jr|wumpus: the original reason I brought it up, was translators confusing it for "About Bitcoin-Qt". but that has since been resolved in other ways, so
 87 2017-02-19 12:14:39	0|Arvidt|Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com> 01EA 5486 DE18 A882 D4C2  6845 90C8 019E 36C2 E964 is expired
 88 2017-02-19 12:15:00	0|wumpus|no, it's been updated and bumped forward 2 years
 89 2017-02-19 12:15:24	0|wumpus|try gpg --refresh-keys
 90 2017-02-19 12:16:35	0|wumpus|that makes little sense, you could add arbitrary steps to release announcements to make the signature check out as ok
 91 2017-02-19 12:16:50	0|wumpus|you can't trust any steps in it before you've verified the signature
 92 2017-02-19 12:16:53	0|luke-jr|yes, but this one makes sense
 93 2017-02-19 12:17:11	0|wumpus|it's not our job to explain people how to use gpg
 94 2017-02-19 12:19:41	0|wumpus|at least not in the release notes
 95 2017-02-19 12:20:11	0|fanquake|I've still got the same issues even after re-building the base image. So I'm guessing I've somehow done that incorrectly..
 96 2017-02-19 12:20:30	0|wumpus|I'm very surprised that the base image solved it for achow101
 97 2017-02-19 12:20:39	0|wumpus|osx build hardly uses anything from the base image
 98 2017-02-19 12:21:09	0|wumpus|we should check what the differences are
 99 2017-02-19 12:22:30	0|fanquake|Looking at his new PR, it looks like the previous build was using the old version of Qt?
100 2017-02-19 12:22:50	0|fanquake|Actually, no.
101 2017-02-19 12:23:33	0|wumpus|I don't think so
102 2017-02-19 12:25:27	0|wumpus|normally would suggest "remove the gitian cache directories" but due to that switch, 0.14 uses new ones anyway
103 2017-02-19 12:25:52	0|wumpus|so it can't be using anything stale
104 2017-02-19 12:26:12	0|wumpus|your gitian-builder is up to date?
105 2017-02-19 12:26:17	0|fanquake|I might be missunderstanding, but why do the hashes for the same file change in his new PR?
106 2017-02-19 12:26:25	0|fanquake|Yes gitian-builder up to date.
107 2017-02-19 12:26:50	0|fanquake|Talking about something like native_mac_alias-1.1.0-f064d7cfd4c.tar.gz
108 2017-02-19 12:28:00	0|wumpus|curious. yes.
109 2017-02-19 12:28:03	0|fanquake|Same for cctools andbiplist.
110 2017-02-19 12:28:14	0|wumpus|not sure where those files come from. cfields?
111 2017-02-19 12:28:32	0|fanquake|That hasn't changed in depends recently as far as I remember. And those hashes don't even match the ones we have in depends anyways.
112 2017-02-19 12:28:51	0|bitcoin-git|13bitcoin/06master 145c8fd50 15Pieter Wuille: Avoid VLA in hash.h
113 2017-02-19 12:28:51	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7ff4a538a868...1f9e904f4556
114 2017-02-19 12:28:52	0|bitcoin-git|13bitcoin/06master 141f9e904 15Wladimir J. van der Laan: Merge #9791: Avoid VLA in hash.h...
115 2017-02-19 12:29:09	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9791: Avoid VLA in hash.h (06master...06novla) 02https://github.com/bitcoin/bitcoin/pull/9791
116 2017-02-19 12:29:15	0|wumpus|maybe the gitian "tarballs are not deterministic" issue
117 2017-02-19 12:29:33	0|wumpus|eh GITHUB not gitian
118 2017-02-19 12:29:55	0|fanquake|except biplist comes from bitcucket
119 2017-02-19 12:30:16	0|fanquake|actually, from pypi.python.org
120 2017-02-19 12:30:19	0|wumpus|oh right, maybe bitbucket has that issue too, or has it now that github no longer has it, I don't know \
121 2017-02-19 12:30:45	0|wumpus|good catch though, that could very well be the reason
122 2017-02-19 12:31:11	0|wumpus|we'd need to find the old and new versions of those files and compare
123 2017-02-19 12:31:26	0|fanquake|They should still be in the /inputs folder
124 2017-02-19 12:32:07	0|wumpus|df26cbb976befd59ba20b73ee33676f22b6ed7aa1329e373307e0a21055f5a5a  ./cache/bitcoin-osx-0.13/x86_64-apple-darwin11/native_biplist/native_biplist-0.9-d766a97a608.tar.gz
125 2017-02-19 12:32:07	0|wumpus|ed6c2d2b2839164e592859f5eff62df7fedde9657c9e7a853720d0a768b8b756  ./cache/bitcoin-osx-0.14/x86_64-apple-darwin11/native_biplist/native_biplist-0.9-d766a97a608.tar.gz
126 2017-02-19 12:32:27	0|wumpus|those are mine. Both have different hash from achow101's new and old one
127 2017-02-19 12:33:26	0|wumpus|maybe they regenerate that file on every download?!
128 2017-02-19 12:33:43	0|fanquake|Surely we would have noticed if that we happening before now ?
129 2017-02-19 12:34:00	0|wumpus|for all the other downloaded dependencies we check the hash
130 2017-02-19 12:34:09	0|wumpus|apparently not for this one
131 2017-02-19 12:34:44	0|fanquake|https://github.com/bitcoin/bitcoin/blob/master/depends/packages/native_biplist.mk#L5
132 2017-02-19 12:36:03	0|fanquake|My cached biplist files don't even match yours or his..
133 2017-02-19 12:37:08	0|fanquake|Well, I even have a different file cached for 0.13 compared to you.
134 2017-02-19 12:37:12	0|fanquake|490e9049e68ec8c7010be3cd19a6237e463d5115839c4cbccbb1dff1196129b4  native_biplist-0.9-1c39c8871c7.tar.gz
135 2017-02-19 12:40:42	0|wumpus|so my hypothesis of it changing every time isn't far off the mark, probably
136 2017-02-19 12:40:55	0|fanquake|Looking at my two asserts, my biplist files haven't changed between the two.
137 2017-02-19 12:41:47	0|fanquake|My other theory is something zlib related. Given it's new to our build.
138 2017-02-19 12:42:05	0|fanquake|It also doesn't compile using the depends system on OS X.
139 2017-02-19 12:43:05	0|wumpus|we should probably start by comparing the resulting files, it maybe some silly metadata thing too
140 2017-02-19 12:43:54	0|fanquake|Yes hopefully.
141 2017-02-19 12:44:52	0|fanquake|Something like #8373
142 2017-02-19 12:44:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/8373 | Fix OSX non-deterministic dmg by theuni · Pull Request #8373 · bitcoin/bitcoin · GitHub
143 2017-02-19 12:48:22	0|wumpus|yes, like that one
144 2017-02-19 13:05:41	0|wumpus|fanquake: could you upload your  bitcoin-0.14.0-osx64.tar.gz somewhere?
145 2017-02-19 13:06:24	0|wumpus|I can't guarantee anything, I don't have the tooling to compare or analyze osx executables, but maybe I can find something obvious
146 2017-02-19 13:14:25	0|fanquake|wumpus probably. Sketchy internet at the moment. Will find a site.
147 2017-02-19 13:16:59	0|bitcoin-git|[13bitcoin] 15kirit93 opened pull request #9798: Fix Issue #9775   (06master...06issue) 02https://github.com/bitcoin/bitcoin/pull/9798
148 2017-02-19 13:19:52	0|gmaxwell|uh. hey, so the release notes don't mention bumpfee.
149 2017-02-19 13:20:09	0|gmaxwell|thats like, a major feature, no? :P
150 2017-02-19 13:21:16	0|wumpus|yes
151 2017-02-19 13:37:54	0|gmaxwell|Relase notes make it sound like getinfo is hard-cut disabled in this version.
152 2017-02-19 13:40:01	0|gmaxwell|(I'm answering questions about the RC on reddit)
153 2017-02-19 14:11:26	0|wumpus|well, it mentions that getinfo was deprecated, not that it was removed. But yeah I guess it could be clearer
154 2017-02-19 14:13:25	0|wumpus|I implemented getinfo client-side at some point (https://github.com/bitcoin/bitcoin/pull/8843) so that anyone using bitcoin-cli would hardly notice the command being removed from the server
155 2017-02-19 14:14:09	0|wumpus|but that only resulted in a big argument, so I gave up on it
156 2017-02-19 14:16:13	0|luke-jr|not the first time someone confused deprecated to mean removed
157 2017-02-19 14:17:30	0|wumpus|on the dev side getinfo was already deprecated for years, iti's just that this was never communicated on the RPC interface
158 2017-02-19 14:23:05	0|achow101|wumpus: fanquake: I did delete gitian-builder and redownload it before making the base vm, so maybe that could be part of why the build was fixed, although I don't see why it should
159 2017-02-19 14:24:18	0|wumpus|achow101: yes, it's no longer possible to isolate what the cause of the problem was
160 2017-02-19 14:24:41	0|wumpus|although the same is not working for fan
161 2017-02-19 14:24:47	0|wumpus|fanquake
162 2017-02-19 14:31:34	0|gmaxwell|I wonder if the next step there shouldn't be to disable getinfo but allow a config option to reenable it.  Another half measure would be to make the error field there always preface with a warning.
163 2017-02-19 14:51:04	0|wumpus|I think the next major release we should just get rid of it
164 2017-02-19 14:51:10	0|wumpus|we've delayed that enough
165 2017-02-19 14:52:10	0|wumpus|announcing it in the release notes in strong language was a good start
166 2017-02-19 14:52:28	0|wumpus|and we provide *exactly* a table of how to get the information
167 2017-02-19 14:54:42	0|wumpus|no need to draw this out like the account deprectation, where it's not 100% clear what the replacement for some use cases
168 2017-02-19 15:01:20	0|da2ce7|if you decide now to remove it in the next version, state. "in version 0.15,  getinfo will be removed from bitcoin-core". :)
169 2017-02-19 15:02:21	0|wumpus|yes, would make sense to add that
170 2017-02-19 15:02:29	0|wumpus|also clears up that it is not removed yet
171 2017-02-19 15:04:01	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1f9e904f4556...390a39bb5cf4
172 2017-02-19 15:04:02	0|bitcoin-git|13bitcoin/06master 14390a39b 15Wladimir J. van der Laan: Merge #9795: doc: Update manpages for master (laanwj)...
173 2017-02-19 15:04:02	0|bitcoin-git|13bitcoin/06master 14eb49101 15Wladimir J. van der Laan: doc: Update manpages for master...
174 2017-02-19 15:04:20	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9795: doc: Update manpages for master (laanwj) (06master...06Mf1602-docManMaster) 02https://github.com/bitcoin/bitcoin/pull/9795
175 2017-02-19 15:22:37	0|gmaxwell|wumpus: the problem with hard cuts like that is predictable people will just not upgrade their nodes when their software is incompatible, and in doing so harm the network.
176 2017-02-19 15:22:51	0|gmaxwell|especially since its super easy to just have never noticed a release note.
177 2017-02-19 15:23:27	0|gmaxwell|(not really trying to argue it out with you now, just defending why I'd even suggest such a thing)
178 2017-02-19 16:11:03	0|achow101|wumpus: it's still non-deterministic :( I just ran gitian again and got my original results
179 2017-02-19 17:21:40	0|gmaxwell|instagibbs: you're double counted in the contributor list
180 2017-02-19 17:31:54	0|bitcoin-git|[13bitcoin] 15gubatron opened pull request #9801: Removed redundant parameter from mempool.PrioritiseTransaction (06master...06refactor-mempool-prioritisetx) 02https://github.com/bitcoin/bitcoin/pull/9801
181 2017-02-19 18:04:06	0|bitcoin-git|[13bitcoin] 15dooglus opened pull request #9803: Fix typo in release notes. (060.14...06patch-5) 02https://github.com/bitcoin/bitcoin/pull/9803
182 2017-02-19 19:46:08	0|bitcoin-git|[13bitcoin] 15JeremyRubin opened pull request #9804: Fixes subscript 0 (&var[0]) where should use (var.data()) instead. (06master...06fix-subscript-0) 02https://github.com/bitcoin/bitcoin/pull/9804
183 2017-02-19 19:55:33	0|achow101|cfields: I now have what appears to be a consistently inconsistent gitian build for osx. Each time I build it, it alternates between the hashes that everyone else has, and the hashes that fanquake and I have
184 2017-02-19 19:56:05	0|sipa|"consistently inconsistent"
185 2017-02-19 20:11:05	0|achow101|cfields: I put the two different assert files in different branches: https://github.com/achow101/gitian.sigs/tree/0.14.0rc1-match and https://github.com/achow101/gitian.sigs/tree/0.14.0rc1-mismatch the only difference between the two are the output files. everything else matches according to diff
186 2017-02-19 21:13:09	0|bitcoin-git|[13bitcoin] 15petertodd opened pull request #9805: Add seed.btc.petertodd.org to mainnet DNS seeds (06master...062017-02-add-pt-mainnet-seed) 02https://github.com/bitcoin/bitcoin/pull/9805
187 2017-02-19 21:33:30	0|boab|Looking for readme on upgrade of core from 0.8.x to 0.10.x Help?
188 2017-02-19 21:34:55	0|gmaxwell|uh? why run such an old version as 0.10? I assume everyone has long forgotten about it, it's old and insecure.
189 2017-02-19 21:35:32	0|boab|Yep, good ppoint. My main mission is to get off of 0.8.x ... and how-to's please?
190 2017-02-19 21:37:19	0|gmaxwell|the blockchain files and wallets are all compatible. shut down, backup your wallet (for good measure), install 0.13.2.  start it.
191 2017-02-19 21:37:48	0|boab|Fantastic...that's all the assurance I needed. Just did not want to trash something in the process.
192 2017-02-19 21:39:43	0|sipa|make a backup of your wallet after shutting down 0.8 if you want to be sure
193 2017-02-19 21:39:55	0|sipa|(which you should have anyway)
194 2017-02-19 21:42:33	0|boab|Thanks mate. I used the [backup wallet] option from within 0.8 and have stored off site.
195 2017-02-19 21:43:14	0|luke-jr|need to backup the wallet before shutting down..
196 2017-02-19 21:43:57	0|boab|?? I think that's right: I was running 0.8, used the GUI option to create a backup, and then have shut 0.8 down.
197 2017-02-19 21:44:02	0|luke-jr|sounds good
198 2017-02-19 21:44:05	0|sipa|sounds good
199 2017-02-19 21:44:21	0|boab|fingers crossed...about to fire up new core now...
200 2017-02-19 21:46:43	0|boab|Rock n roll! v013.2 seems to have read the wallet and blockchain and is happily syncing right now. Thanks for your hand-holding...much appreciated.
201 2017-02-19 21:47:10	0|gmaxwell|Great! congrats on joining the modern era!
202 2017-02-19 21:47:49	0|boab|heheh...respkt ur elders?
203 2017-02-19 21:50:56	0|sipa|boab: also, 0.14.0 will be released in a few weeks likely