1 2017-12-13 04:24:17	0|xmsx|hey, could anyone help me with generating segwit addresses?
  2 2017-12-13 04:25:03	0|meshcollider|Anyone seen this Travis failure before https://travis-ci.org/bitcoin/bitcoin/jobs/315614592
  3 2017-12-13 04:25:16	0|meshcollider|xmsx: what do you need help with?
  4 2017-12-13 04:27:13	0|meshcollider|https://pastebin.com/Ek9htTQL
  5 2017-12-13 04:29:06	0|xmsx|I'm trying to generate segwit address in PHP but not sure if I got it right, and my bitcoin got corrupted database for some reason so I can't test it properly
  6 2017-12-13 04:29:26	0|xmsx|Here's the code I'm using: https://pastebin.com/us0qEqe1
  7 2017-12-13 04:30:28	0|xmsx|My only question is -- Am I using correct  $compressed_public_key at step 1?
  8 2017-12-13 04:32:54	0|xmsx|e.g. docs say: "To create a P2SH-P2WPKH address: 1) Calculate the RIPEMD160 of the SHA256 of a public key (keyhash)."
  9 2017-12-13 04:33:29	0|xmsx|Do I need to use compressed version of keyhash?
 10 2017-12-13 04:35:17	0|xmsx|it generates valid segwit addresses (eg. https://blockchain.info/address/37fZYysB6c2iMt2cywZyUUydqQkR6vkCri) but not sure if I base it on proper public key on step 1 :)
 11 2017-12-13 04:36:01	0|xmsx|Also, don't try to run that code above, it won't work for you, it's just a pseudocode :)
 12 2017-12-13 04:41:32	0|sipa|xmsx: sorry, this the dev channel for bitcoin core, a c++ bitcoin client
 13 2017-12-13 04:42:38	0|xmsx|Can you just import this private key: 5KAwW31HxQW5Jrp4HM3o59BPRXarMP87imDR1nrjQpGvnTzwafK and tell me if segwit for it is 37fZYysB6c2iMt2cywZyUUydqQkR6vkCri?
 14 2017-12-13 04:42:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ef8ba7d73a48...ba2f19504c6b
 15 2017-12-13 04:43:00	0|bitcoin-git|13bitcoin/06master 141729c29 15Cory Fields: net: split socket creation out of connection...
 16 2017-12-13 04:43:00	0|bitcoin-git|13bitcoin/06master 149e3b2f5 15Cory Fields: net: Move IsSelectableSocket check into socket creation...
 17 2017-12-13 04:43:01	0|bitcoin-git|13bitcoin/06master 14df3bcf8 15Cory Fields: net: pass socket closing responsibility up to caller for outgoing connections...
 18 2017-12-13 04:43:15	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11363: net: Split socket create/connect (06master...06split-socket-create-connect) 02https://github.com/bitcoin/bitcoin/pull/11363
 19 2017-12-13 05:48:37	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #11884: [trivial] Remove unused include in hash.cpp (06master...0620171213-unneeded-include-hash-cpp) 02https://github.com/bitcoin/bitcoin/pull/11884
 20 2017-12-13 06:18:05	0|bitcoinNOOOB|Hello?
 21 2017-12-13 06:18:57	0|bitcoinNOOOB|Anyone here?
 22 2017-12-13 06:49:16	0|jonasschnelli|[OT] what is the fastest way to amend commit the current changes into a non HEAD commit? (instead of git stash & git rebase -i HEAD~3 (edit) & git stash apply & git commit --amend & git rebase --continue)?
 23 2017-12-13 06:50:18	0|sipa|i usually just write a new commit at the end, and then move/apply/squash it with rebase -i
 24 2017-12-13 06:50:26	0|wumpus|same here
 25 2017-12-13 06:50:52	0|sipa|so <make changes>; git commit -am "fix"; git rebase -i HEAD~~~~~~~~, and move the last commit up in the list turning the 'pick' into 'fix'
 26 2017-12-13 06:50:57	0|wumpus|I make lots of temporary commits, then at some point I merge them into the commit they belong
 27 2017-12-13 06:51:35	0|sipa|if the changes are to a commit in the middle which you can't just do at the end (because they're already overwritten in a later commit), git rebase -i HEAD~~~~~~ and 'edit' the commit itself
 28 2017-12-13 06:52:33	0|sipa|(i squash very liberally, but try to avoid actually rebasing0
 29 2017-12-13 06:53:24	0|wumpus|if you already have changes in your working tree that need to be spread into multiple commits, git add -p is great
 30 2017-12-13 06:56:20	0|jonasschnelli|thanks!
 31 2017-12-13 06:56:54	0|jonasschnelli|There is no direct way for git rebase -i HEAD~3 (then select edit)? Something that directly rebased back in edit mode to ~3 (or other depth)?
 32 2017-12-13 06:57:40	0|jonasschnelli|I whish my IDE would have a way to directly amend commit a line-change (or block) into a selected historical commit
 33 2017-12-13 06:57:51	0|wumpus|I think everything you can do with -i (interactive) should be possible without -i, it's just a longer sequence of commands
 34 2017-12-13 06:58:25	0|wumpus|in a way an interactive mode makes you lazy :)
 35 2017-12-13 06:59:29	0|wumpus|yes that'd be quite useful as a command, what I usually miss is a way to refer to commits by say, a name, instead of their (ever changing) commit id
 36 2017-12-13 06:59:53	0|wumpus|that would be so much easier for referring to them in rebase commands
 37 2017-12-13 07:01:46	0|jonasschnelli|wumpus: indeed
 38 2017-12-13 08:49:47	0|Provoostenator|There's a Github issue or PR about consolidating translation files, but I can't find it. Not even with Google...
 39 2017-12-13 08:53:06	0|fanquake|There are various issues for translations open at the moment. Do you want to add discussion somewhere?
 40 2017-12-13 08:54:40	0|fanquake|cfields did you end up sending the zeromq mingw64 patch upstream?
 41 2017-12-13 08:55:53	0|Provoostenator|I want to link to it from #11875 because reducing the number of locales would probably be helpful for review.
 42 2017-12-13 08:55:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/11875 | Snoei: a.k.a. how to translate technical jargon · Issue #11875 · bitcoin/bitcoin · GitHub
 43 2017-12-13 08:56:16	0|Provoostenator|I remember the issue was quite specific about whch language files could be combined.
 44 2017-12-13 09:16:27	0|wumpus|I don't think there's a hard rule for that; in some cases the same language for multiple countries is spurious, in some cases there's actually a language difference
 45 2017-12-13 09:17:34	0|wumpus|'reducing the number of locales' is not a goal in itself, it means leaving people without translations for their language, though removing low-quality ones would be good (but this has to be judged on transifex somehow)
 46 2017-12-13 09:19:02	0|Provoostenator|I think the PR (which I can't find) was just combining (mostly) identical languages like Dutch and Flemish.
 47 2017-12-13 09:21:11	0|sipa|jonasschnelli: my odroid iseems be having some trouble... i just had a block that took 12 hours to validate
 48 2017-12-13 09:21:45	0|sipa|it looks like it's just insanely slow I/O (7.5s per txin), but it's much faster after a reboot
 49 2017-12-13 09:22:06	0|Provoostenator|In transifex there's nl, nl_BE, and nl_NL, although in src/qt/locale there's only nl. So maybe this has already been done.
 50 2017-12-13 09:22:33	0|wumpus|yes, I have already been selective which languages I include in the repository
 51 2017-12-13 09:23:19	0|wumpus|also translations with too few messages don't get included
 52 2017-12-13 09:23:55	0|wumpus|(although that threshold is at 10, should probably be higher with the huge volume of translatable strings we have these days)
 53 2017-12-13 09:24:43	0|Provoostenator|As long as the fallback is sane and the translations are reviewed, wouldn't 1 be a low enough threshold?
 54 2017-12-13 09:26:26	0|Provoostenator|E.g. if Flemish falls back to Dutch and Dutch falls back to English. Similarly Latin american versions of Spanish should fall back to European Spanish, before falling back to English.
 55 2017-12-13 09:27:42	0|Provoostenator|But if instead languages immedidately fall back to English then it's probably better to leave them out if they're seriously incomplete.
 56 2017-12-13 09:29:51	0|sipa|Provoostenator: we've had issues in the past once where there was an austrian german translation which was apparently full of dialect that offended peoe
 57 2017-12-13 09:30:30	0|Provoostenator|Without review even worse things could happen.
 58 2017-12-13 09:31:05	0|sipa|oh yes.
 59 2017-12-13 09:31:39	0|Provoostenator|So I think the amount / quality / trustworthyness of review is more important than the number of translated phrases (depdneing on fallback behavior).
 60 2017-12-13 09:32:24	0|Provoostenator|Obviously it's not worth monitoring reviewers for a language with 5 words, so I guess it's the same outcome.
 61 2017-12-13 09:40:04	0|wumpus|what use would a translation with one translated phrase be? I don't see it
 62 2017-12-13 09:40:35	0|wumpus|for translation to be useful the entire application needs to be translated, more or less, certainly the most visited parts
 63 2017-12-13 09:41:01	0|sipa|i don't know how i'd translate anything dirrectly in dutch vs flemish
 64 2017-12-13 09:41:50	0|wumpus|I do agree the threshold could be lower for XX_yy languages that just override some messages than for XX "top level" ones
 65 2017-12-13 09:42:51	0|wumpus|but otherwise the number of message is a measure of compleness
 66 2017-12-13 09:43:07	0|Provoostenator|There's probably no use for a translation with 10 words, but if someone believes it's useful (for whatever reason I can't think of) and it's reviewed, and the fallback behavior is correct, I don't see a downside.
 67 2017-12-13 09:43:36	0|Provoostenator|But as a general rule I would agree the majority of the frequently used parts of the app should be translated and maintained.
 68 2017-12-13 09:45:12	0|Provoostenator|There are some cases where XX_yy languages have subtle differences that are genenally not a problem, but can be very confusing in just one or two places. That's the only scenario I can think of and I doubt it's relevant with so much technical jargon.
 69 2017-12-13 09:45:19	0|wumpus|another reason why a language with many translations is preferable is because, very likely, there is more translation activity for it
 70 2017-12-13 09:45:32	0|wumpus|a language with 10 messages will likely have had 1 person type in some messages
 71 2017-12-13 09:46:11	0|wumpus|but sure, in the end it's just a time-saving heuristic - I don't have time nor language skills to judge every translation separately
 72 2017-12-13 09:47:07	0|wumpus|I like the idea of having a glossary of 'words to not translate' btw, though I'm not sure it works for every language
 73 2017-12-13 09:47:29	0|wumpus|e.g. what about chinese or arabic? it just doesn't make sense t ohave english words interspersed there
 74 2017-12-13 09:49:12	0|Provoostenator|The glossary for each language would contain the suggested translation, which in most cases would not be a translation.
 75 2017-12-13 09:50:17	0|wumpus|you want to make one for every language?
 76 2017-12-13 09:50:39	0|Provoostenator|Well, every language where it's useful.
 77 2017-12-13 09:50:49	0|Provoostenator|Isn't that how it already works?
 78 2017-12-13 09:50:50	0|wumpus|that's awesome
 79 2017-12-13 09:52:20	0|wumpus|I mean we've never had anyone spend a lot of time on translations or helping translators, i've tried to do it on or off (usually by removing overly-technical messages from translation or rewording them)
 80 2017-12-13 09:54:52	0|Provoostenator|It's seems problematic to have a process that nobody can focus enough on to prevent things from breaking.
 81 2017-12-13 09:55:37	0|wumpus|it's not clear to me what kind of process works for translating open source software
 82 2017-12-13 09:56:11	0|wumpus|though the current one works, more or less, it's certainly better than not translating at all
 83 2017-12-13 09:56:14	0|Provoostenator|I think it's better to not translate when in doubt
 84 2017-12-13 09:56:22	0|wumpus|whose doubt?
 85 2017-12-13 09:56:50	0|wumpus|that's the problem really here, you'd have to mobilize lots of volunteers
 86 2017-12-13 09:56:56	0|wumpus|unless you know all languages yourself :)
 87 2017-12-13 09:57:19	0|wumpus|maybe it's realistic now that bitcoin is so well-known
 88 2017-12-13 09:57:26	0|Provoostenator|There's a lot of websites and applications out there where the translation is worse than the original.
 89 2017-12-13 09:57:35	0|wumpus|and still it helps some people
 90 2017-12-13 09:57:47	0|Provoostenator|I think requiring review of translated strings would be a good improvement.
 91 2017-12-13 09:58:02	0|wumpus|a large portion of the world doesn't know english at all, so even somewhat broken form of their own language is more understandable
 92 2017-12-13 09:58:14	0|wumpus|by whom?
 93 2017-12-13 09:58:30	0|Provoostenator|Not always, because if you google a word like "snoei" you won't find help in any language.
 94 2017-12-13 09:59:24	0|wumpus|well it literally translates to prune
 95 2017-12-13 09:59:34	0|Provoostenator|Same as with pull requests; anyone can review translations, don't merge unless it has enough review.
 96 2017-12-13 09:59:56	0|wumpus|so does transifex have a process for that?
 97 2017-12-13 10:00:06	0|wumpus|I know you can make teams etc
 98 2017-12-13 10:00:20	0|wumpus|and that messages can be flagged as 'reviewed'
 99 2017-12-13 10:00:25	0|Provoostenator|Yes, when you download the strings, you can select that you only want reviewed strings.
100 2017-12-13 10:00:30	0|Provoostenator|At least in the UI.
101 2017-12-13 10:00:32	0|wumpus|yes, but what does that mean?
102 2017-12-13 10:00:38	0|wumpus|who clicked 'reviewed' in that case?
103 2017-12-13 10:00:45	0|Provoostenator|That part I'm still figuring out
104 2017-12-13 10:00:55	0|Provoostenator|Transifex is broken for me, I can't see some of the pages.
105 2017-12-13 10:00:56	0|wumpus|I guess that a language reviewr needs to be assigned for every language?
106 2017-12-13 10:01:06	0|wumpus|or review team
107 2017-12-13 10:01:19	0|Provoostenator|Every language has a team, feel free to add me to Dutch.
108 2017-12-13 10:01:27	0|wumpus|I think German has a review team, from back when diapolo was a contributor
109 2017-12-13 10:01:45	0|wumpus|oh they can choose their own team?
110 2017-12-13 10:01:51	0|wumpus|I really have no clue :)
111 2017-12-13 10:02:06	0|Provoostenator|I think you (or whoever has admin rights over transifex) can invite people to language teams.
112 2017-12-13 10:03:01	0|wumpus|I'll see if I can add you for dutch
113 2017-12-13 10:03:25	0|Provoostenator|So a process could be: 1) all translations need review by someone in the team 2) before or after merging the final version, remind people on Github to quickly skim through whichever language they know 3) if (2) leads to problems, fire the reviewers
114 2017-12-13 10:03:36	0|Provoostenator|(3) could be less drastic :-)
115 2017-12-13 10:03:36	0|wumpus|but I can't coordinate this for every language
116 2017-12-13 10:04:19	0|Provoostenator|So maybe we need a github issue for a translation coordinator?
117 2017-12-13 10:05:06	0|Provoostenator|Sounds like a good role for a non-technical person who wants to help out.
118 2017-12-13 10:06:40	0|wumpus|I can't even find where to add you, I can go to https://www.transifex.com/bitcoin/teams/159/nl_NL/  and see your name under "translators" but I don't see how to move you to coorindator or reviewer
119 2017-12-13 10:08:03	0|Provoostenator|I'll try to make an org for myself and see if I can figure out the UX.
120 2017-12-13 10:09:34	0|wumpus|https://docs.transifex.com/teams/managing-and-removing-collaborators  I don't see any "Teams" tab
121 2017-12-13 10:10:01	0|Provoostenator|I've used half a dozen translation services in the past and they all have serious issues.
122 2017-12-13 10:10:07	0|wumpus|might be that I don't have the required permissions
123 2017-12-13 10:10:28	0|Provoostenator|Yeah, I was assuming you were the admin.
124 2017-12-13 10:10:37	0|Provoostenator|Maybe Satoshi is? :-)
125 2017-12-13 10:10:39	0|wumpus|I'm "project maintainer"
126 2017-12-13 10:10:55	0|wumpus|seone, apparently
127 2017-12-13 10:11:08	0|wumpus|haven't seen them in a long time...
128 2017-12-13 10:12:26	0|wumpus|on the other hand I have access to all the settings, even the "delete project" button, so I would find it slightly strange if I don't have access to teams
129 2017-12-13 10:13:50	0|Provoostenator|Projects are not the top lovel.
130 2017-12-13 10:14:07	0|Provoostenator|Organization is
131 2017-12-13 10:14:11	0|wumpus|ok
132 2017-12-13 10:15:19	0|Provoostenator|If you click on the dropdown next to Bitcoin at the top, you shoudl see Organization Settings.
133 2017-12-13 10:15:38	0|Provoostenator|(I don't see that for Bitcoin because I don't own that org, but I do see it for the org I just created)
134 2017-12-13 10:15:54	0|wumpus|https://www.transifex.com/bitcoin/public/   I can only access the public page, ok that's explained then
135 2017-12-13 10:16:08	0|Provoostenator|Yes, and I can add administrators, which is probably what you are.
136 2017-12-13 10:18:00	0|Provoostenator|There's also "Maintainers". So maybe you can be promoted to admin.
137 2017-12-13 10:18:32	0|Provoostenator|SAAS Kafka
138 2017-12-13 10:18:40	0|gmaxwell|https://www.bloomberg.com/news/articles/2017-12-12/bitcoin-developer-behind-failed-fork-begins-another-offshoot < someone should contact them and advise them that jeff garzik has not been a bitcoin core developer for many years.
139 2017-12-13 10:19:00	0|wumpus|Provoostenator: trying to find contact info for them. At least the irc account mentioned hasn't logged on for 7 weeks. Yes indeed :(
140 2017-12-13 10:19:42	0|Provoostenator|gmaxwell: doesn't he have an ICO to work on?
141 2017-12-13 10:22:57	0|wumpus|gmaxwell: I don't think there's a way to get rid of that denomination even if you'd want to
142 2017-12-13 10:23:25	0|wumpus|once someone is a bitcoin core developer you'll never leave, so beware :)
143 2017-12-13 10:23:35	0|meshcollider|gmaxwell: here you go ;) https://twitter.com/MeshCollider/status/940889701640060928
144 2017-12-13 10:24:09	0|wumpus|the only solution is to call everyone bitcoin core developer that contributed one patch, or heck even a translation message
145 2017-12-13 10:24:33	0|meshcollider|yes all users on transifex are core developers too :)
146 2017-12-13 10:24:43	0|wumpus|yup!
147 2017-12-13 10:25:05	0|Provoostenator|Yes, which would include the bitcoin diamonds(?) person whose gitian signature was recently added to a PR.
148 2017-12-13 10:25:05	0|wumpus|in that regard I've been trying to get credit info from the API (for the release notes) but haven't been succesful
149 2017-12-13 10:25:16	0|gmaxwell|Nah, they media does this when people use it to promote themselves or at least don't say don't do that.
150 2017-12-13 10:26:54	0|gmaxwell|that new spinoff is especially scammy, in they they confiscate most of the coins; -- any coin that wasn't moved in the last 30 days.
151 2017-12-13 10:29:07	0|Provoostenator|Ah, that's where they get their "sizable reserve to stabilize its price relative to fiat currencies"
152 2017-12-13 10:30:08	0|wumpus|the confiscation part is extrememly scammy, I mean deleting coins after 30 days that's one way to *bludgeon* the utxo set down, a very ugly way, but moving that money into their pocket is simply criminal
153 2017-12-13 10:30:20	0|gmaxwell|(moved in the last 30 days before their fork, and their domain was only registered <12 days before the fork...)
154 2017-12-13 10:30:32	0|Provoostenator|I'm sure it will stabilize at 0. I personally don't find it very productive to try and get media to report bitcoin related thing correctly.
155 2017-12-13 10:31:16	0|gmaxwell|well they design the rules, so ... well the really misleading part is to claim it is really related to bitcoin at all, it's just a massively premined dumb altcoin, where they happened to give a small portion to people who generated excess tx volume in the last week.
156 2017-12-13 10:31:40	0|wumpus|right, just yet another fork, at some point people will start ignoring them like they do for new altcoins and icos
157 2017-12-13 10:32:05	0|Provoostenator|There will probalby be plenty of malware too, maybe even in the reference client.
158 2017-12-13 10:32:36	0|wumpus|yep, also waiting for the first fork with malware in their reference client, it has been done with altcoins
159 2017-12-13 10:33:33	0|Provoostenator|Let's see if they get it right "at block height: #498,777"
160 2017-12-13 10:33:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/498 | Edited README.md via GitHub by paraipan · Pull Request #498 · bitcoin/bitcoin · GitHub
161 2017-12-13 10:35:26	0|wumpus|garzik is pretty just wasting everyones time
162 2017-12-13 10:35:35	0|wumpus|+much
163 2017-12-13 10:35:36	0|Provoostenator|On the bright side, some of these airdrop developers might end up contributing to Core in the long term.
164 2017-12-13 10:36:09	0|wumpus|at some point his reputation will go down enough he can't keep pulling these stunts off anymore
165 2017-12-13 10:36:24	0|Provoostenator|Whaha, you'd be surprised.
166 2017-12-13 10:36:50	0|Provoostenator|I can point you to some biographies...
167 2017-12-13 10:37:17	0|wumpus|I'm not sure we even want that, the forks don't really seem to attract much talent, just people full of themselves that think they can do everything better
168 2017-12-13 10:37:36	0|Provoostenator|Not always, not if they're hired developers.
169 2017-12-13 10:37:58	0|Provoostenator|Then it's just their boss telling them to work on X, which they might feel reluctant about.
170 2017-12-13 10:41:25	0|gmaxwell|Provoostenator: someone once said that about altcoins in 2011... so far it seems almost none have done so.
171 2017-12-13 10:42:43	0|Provoostenator|Were any of these altcoins run by companies though? I would not expect single founder coin devs to do this. But yeah, I'm probably too optimistic.
172 2017-12-13 10:43:26	0|fanquake|The altcoins were run in bitcointalk threads. And eventually "generators" just churned them out.
173 2017-12-13 10:44:19	0|Provoostenator|They have 12 devs: http://www.ub.com/about/team
174 2017-12-13 10:47:27	0|meshcollider|at least their website looks nice ;)
175 2017-12-13 10:48:04	0|wumpus|usually in the cryptocurrency space, the nicer the website looks the scammier something is
176 2017-12-13 10:48:27	0|meshcollider|yep they spend more time on the website appearance than on the actual coin
177 2017-12-13 10:51:21	0|Provoostenator|No checksums on the download page. Source code is offered as a zip file, so good luck reviewing that...
178 2017-12-13 10:51:49	0|Provoostenator|(oh no, they do have a Github repo as well)
179 2017-12-13 10:52:30	0|meshcollider|only as of a week ago according to their roadmap lol
180 2017-12-13 10:54:15	0|Provoostenator|The commit messages and user names are entertaining.
181 2017-12-13 10:54:58	0|meshcollider|BUG FIXED
182 2017-12-13 10:55:27	0|Provoostenator|They branched away from Core master on November 30
183 2017-12-13 10:56:24	0|Provoostenator|This should be the full div: https://github.com/UnitedBitcoin/UnitedBitcoin/compare/60d739e...v1.0.3
184 2017-12-13 11:09:07	0|Provoostenator|My favorite comment so far: "UnionBitcoin god mode block generator" (anyway, off topic I guess, unless there's a zero-day?)
185 2017-12-13 11:11:08	0|gmaxwell|Provoostenator: in 2011 no, but ripple...
186 2017-12-13 11:13:56	0|Provoostenator|Does Ripple have any code overlap with Core that would make it easy for their devs to help out here?
187 2017-12-13 11:14:48	0|wumpus|I don't think they have any code overlap
188 2017-12-13 11:16:39	0|meshcollider|certainly doesn't look like they do, from a quick browse at their repo
189 2017-12-13 11:19:53	0|gmaxwell|generally companies won't have code overlap, paying people to rewrite the codebase (not necessarily well or with any originality :) ) is cheap to do and lots of people are eager to do it.
190 2017-12-13 11:21:22	0|Provoostenator|I created #bitcoin-airdrop-code-shenanigans if anyone is interested. Not sure how to log it.
191 2017-12-13 12:09:59	0|cluelessperson|question, which flag indicates an RBF transaction?
192 2017-12-13 12:10:08	0|mryandao|nsequence
193 2017-12-13 12:10:51	0|cluelessperson|< some maximum?
194 2017-12-13 12:11:11	0|meshcollider|cluelessperson: yep RBF if any sequence value is less than 0xffffffff - 1
195 2017-12-13 12:11:38	0|cluelessperson|oh that's easy
196 2017-12-13 12:11:44	0|cluelessperson|I overlooked it in my code
197 2017-12-13 12:13:32	0|cluelessperson|wait
198 2017-12-13 12:13:46	0|cluelessperson|my previous code looks at nsequence in all of the inputs
199 2017-12-13 12:13:49	0|cluelessperson|is that right?
200 2017-12-13 12:14:10	0|cluelessperson|should be nSequence of the current transaction, not inputs, right?
201 2017-12-13 12:20:17	0|aj|cluelessperson: depends on if the inputs have confirmed already
202 2017-12-13 12:20:34	0|cluelessperson|aj: What depends?
203 2017-12-13 12:21:10	0|aj|cluelessperson: RBF inherits; if the ancestors have nSeq signalling RBF, current tx is RBF too
204 2017-12-13 12:22:15	0|aj|cluelessperson: (provided the ancestors haven't confirmed yet)
205 2017-12-13 12:22:23	0|meshcollider|cluelessperson: Depends what you are referring to by an input. If you mean the vin of the transaction, then yes, thats correct, sequence numbers are per-input
206 2017-12-13 12:22:46	0|meshcollider|that is different from looking back at the parent being spend
207 2017-12-13 12:22:48	0|meshcollider|spent*
208 2017-12-13 12:23:03	0|meshcollider|but yes aj is right, RBF also inherits
209 2017-12-13 12:26:07	0|cluelessperson|I see
210 2017-12-13 12:26:47	0|cluelessperson|for txin in tx.vin: if txin.nSequence < 0xfffffffe: return True
211 2017-12-13 12:29:03	0|meshcollider|yes that sounds right
212 2017-12-13 12:29:17	0|meshcollider|its detailed in BIP 125 btw
213 2017-12-13 13:06:11	0|bitcoin-git|13bitcoin/06master 14fbf327b 15Aaron Clauson: Minimal code changes to allow msvc compilation.
214 2017-12-13 13:06:11	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ba2f19504c6b...68e021e3a35d
215 2017-12-13 13:06:12	0|bitcoin-git|13bitcoin/06master 1468e021e 15Wladimir J. van der Laan: Merge #11558: Minimal code changes to allow msvc compilation...
216 2017-12-13 13:21:19	0|DeadCode|hello world
217 2017-12-13 13:22:44	0|DeadCode|I would like to ask some questions to jonasschnelli but he seems offline, anyone would like to help regarding libbtc implementation, please?
218 2017-12-13 14:52:10	0|promag|MarcoFalke: ping
219 2017-12-13 14:53:54	0|promag|wumpus: int64_t GetArg returns 0 if conversion fails
220 2017-12-13 14:54:54	0|promag|should it return default value? should it throw or signal some *bool?
221 2017-12-13 14:54:58	0|wumpus|I guess that has always been the case?
222 2017-12-13 14:55:33	0|promag|we have ParseInt64 that indicates success or not
223 2017-12-13 14:55:38	0|wumpus|no, if that's changed, I'd say make it use ParseInt64 instead of atoi and raise an actual error
224 2017-12-13 14:55:40	0|wumpus|yes
225 2017-12-13 14:56:37	0|promag|for instance, -prune=foo
226 2017-12-13 14:56:49	0|promag|atm it's the same as -prune=0
227 2017-12-13 14:57:01	0|wumpus|it should throw an error and exit imo
228 2017-12-13 14:57:13	0|promag|my opinion also
229 2017-12-13 14:57:21	0|wumpus|using the default value when parsing fails isn't better
230 2017-12-13 14:57:27	0|promag|right
231 2017-12-13 14:57:41	0|promag|it's bad configuration
232 2017-12-13 14:57:51	0|promag|should be fixed
233 2017-12-13 15:00:16	0|promag|the problem is that dealing with failed conversion will make the code ugly throughout, GetArg is used everywhere
234 2017-12-13 15:03:28	0|wumpus|yeah...
235 2017-12-13 15:03:52	0|wumpus|that's kind of the annoying thing about the current argument parsing code
236 2017-12-13 15:03:57	0|wumpus|that it's called from everywhere, not just init
237 2017-12-13 15:04:33	0|wumpus|also why I didn't fix this before, I did know of that use of atoi when I introduced ParseInt64
238 2017-12-13 15:05:02	0|wumpus|seems it's something better left for when there's more structured argument parsing
239 2017-12-13 15:11:30	0|promag|ok
240 2017-12-13 15:18:49	0|promag|Is this comment still valid https://github.com/bitcoin/bitcoin/blob/68e021e3a35d1e88d6075ea8b05a8e3a40a64e29/src/wallet/wallet.cpp#L4125-L4129 ?
241 2017-12-13 15:20:18	0|promag|Reading #10286..
242 2017-12-13 15:20:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
243 2017-12-13 15:34:36	0|promag|is validation.h the best place for LookupBlockIndex definition?
244 2017-12-13 15:35:18	0|promag|I guess so because extern BlockMap& mapBlockIndex; is in validation.h
245 2017-12-13 15:38:05	0|BlueMatt|yes, though tbh I'd like to quickly move to LookupBlockIndex being in validation.h and mapBlockIndex being validation.cpp-static, but thats more work so can be a separate pr
246 2017-12-13 15:40:31	0|promag|yes I thought of that too
247 2017-12-13 15:40:50	0|promag|https://github.com/bitcoin/bitcoin/pull/11041#issuecomment-349811860
248 2017-12-13 15:41:11	0|promag|but out of scope of 11041
249 2017-12-13 15:42:38	0|BlueMatt|yes, agreed
250 2017-12-13 15:43:01	0|BlueMatt|I just really want to get #10692 in, and #11041 should simplify it a bunch
251 2017-12-13 15:43:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/10692 | Make mapBlockIndex and chainActive and all CBlockIndex*es const outside of validation/CChainState by TheBlueMatt · Pull Request #10692 · bitcoin/bitcoin · GitHub
252 2017-12-13 15:43:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
253 2017-12-13 15:43:44	0|BlueMatt|and I can probably skip making mapBlockIndex const and just move it to validation.cpp, cause making it const is a stupid hack (that possible invokes ub? I'm not actually 100% sure)
254 2017-12-13 15:44:20	0|promag|haven't compiled locally to verify the annotation LookupBlockIndex(const uint256& hash) EXCLUSIVE_LOCKS_REQUIRED(cs_main), waiting for travis
255 2017-12-13 15:44:45	0|BlueMatt|you just have to compile with CXX=clang++ ./configure --enable-werror
256 2017-12-13 16:08:24	0|promag|IMO #11877 is ready
257 2017-12-13 16:08:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/11877 | Improve createrawtransaction functional tests by promag · Pull Request #11877 · bitcoin/bitcoin · GitHub
258 2017-12-13 16:09:35	0|promag|jnewbery: +1 for comment
259 2017-12-13 16:21:34	0|bitcoin-git|[13bitcoin] 15fridzema opened pull request #11885: Direct link to the freenode channel (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11885
260 2017-12-13 16:34:35	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/68e021e3a35d...d4991c0cbb8a
261 2017-12-13 16:34:36	0|bitcoin-git|13bitcoin/06master 1427c6199 15João Barbosa: test: Add multidict to support dictionary with duplicate key (laanwj)
262 2017-12-13 16:34:36	0|bitcoin-git|13bitcoin/06master 14320669a 15João Barbosa: rpc: Validate replaceable type in createrawtransaction
263 2017-12-13 16:34:37	0|bitcoin-git|13bitcoin/06master 1488af502 15João Barbosa: test: Add createrawtransaction functional tests
264 2017-12-13 16:35:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11877: Improve createrawtransaction functional tests (06master...062017-12-createrawtransaction) 02https://github.com/bitcoin/bitcoin/pull/11877
265 2017-12-13 16:41:39	0|bitcoin-git|[13bitcoin] 15jimhashhq reopened pull request #10922: New file-partition.md doc describing how to partition files to ensure fast initial blockchain synchronization.. (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10922
266 2017-12-13 16:51:57	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #11734: rpc: Work around Clang thread safety analysis quirks (06master...06clang-thread-safety-quirks) 02https://github.com/bitcoin/bitcoin/pull/11734
267 2017-12-13 16:54:33	0|ThemoonMoth|Thoughts about the upcoming FCC vote?
268 2017-12-13 16:54:56	0|ThemoonMoth|And it's effect on bitcoin development in the US
269 2017-12-13 16:55:29	0|kanzure|wrong channel
270 2017-12-13 16:56:00	0|ThemoonMoth|the appropriate one would be...?
271 2017-12-13 17:01:03	0|BlueMatt|#bitcoin
272 2017-12-13 17:06:00	0|BlueMatt|can remove 11363 from https://github.com/bitcoin/bitcoin/projects/8 =D
273 2017-12-13 17:07:20	0|rever5e|I'm trying to figure out if there is a way i can help core as a full-stack web developer.  Anyone have any ideas?
274 2017-12-13 17:08:01	0|rever5e|Unfortunately not savvy enough to contribute to main repo i'd just end up Garzik'ing it
275 2017-12-13 17:09:10	0|wumpus|rever5e: you could help with documentation, or translations
276 2017-12-13 17:10:03	0|rever5e|wumpus: How?
277 2017-12-13 17:10:58	0|wumpus|documentation is mainly in https://github.com/bitcoin/bitcoin/tree/master/doc, translations on transifex https://www.transifex.com/bitcoin/bitcoin/
278 2017-12-13 17:23:50	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11886: Clarify getbalance meaning a tiny bit in response to questions. (06master...062017-12-getbalance-docs) 02https://github.com/bitcoin/bitcoin/pull/11886
279 2017-12-13 17:25:15	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11885: Direct link to the freenode channel (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11885
280 2017-12-13 18:17:02	0|cluelessperson|Bitcoin Core's  "estimatefee" and "estimatesmartfee", what is the unit they're using?
281 2017-12-13 18:17:11	0|cluelessperson|0.00356757
282 2017-12-13 18:17:21	0|cluelessperson|I think it's mbtc/kb?
283 2017-12-13 18:17:45	0|arubi|it's always been btc/kb
284 2017-12-13 18:17:59	0|arubi|maybe changed recently?  that would be breaking for .confs
285 2017-12-13 18:18:11	0|arubi|*so I don't think it's changed :)
286 2017-12-13 18:19:03	0|arubi|yep, says btc/kb
287 2017-12-13 18:19:26	0|wumpus|the help should show it, if not, it's a bug
288 2017-12-13 18:19:38	0|wumpus|(e.g. bitcoin-cli help estimatefee)
289 2017-12-13 18:19:46	0|arubi|it does, actually I didn't see we're on #-core-dev
290 2017-12-13 18:20:24	0|arubi|on smartfee it does say btc/kb.  estimatefee just says "fee-per-kb"
291 2017-12-13 18:21:34	0|wumpus|that could be clearer, though in general all amounts on the RPC interface are in BTC, never mbtc or mubtc
292 2017-12-13 18:30:23	0|achow101|estimatefee is deprecated anyways
293 2017-12-13 18:31:41	0|cluelessperson|help doesn't show it.
294 2017-12-13 18:31:47	0|cluelessperson|achow101: estimatesmartfee is good?
295 2017-12-13 18:32:40	0|sipa|yes
296 2017-12-13 18:32:55	0|achow101|yes
297 2017-12-13 18:32:56	0|sipa|estimatesmartfee orestimaterawfee
298 2017-12-13 18:33:03	0|achow101|estimatesmartfee replaces estimatefee
299 2017-12-13 18:58:01	0|jonasschnelli|sipa: re. "it looks like it's just insanely slow I/O (7.5s per txin), but it's much faster after a reboot"
300 2017-12-13 18:58:14	0|jonasschnelli|Is that the same problem we have reported on the github issue tracker?
301 2017-12-13 18:58:23	0|jonasschnelli|Do you know why it was caused? swap?
302 2017-12-13 19:05:55	0|sipa|jonasschnelli: trying to figure that out now
303 2017-12-13 19:09:29	0|jonasschnelli|I really like to try Core on the Jetson TX1 board: https://www.nvidia.com/en-us/autonomous-machines/embedded-systems-dev-kits-modules/
304 2017-12-13 19:10:20	0|GAit|when you say odroid do you mean hardkernel stuff?
305 2017-12-13 19:10:28	0|jonasschnelli|sipa: did anyone ever conceptually figured out if parts of the validation could be "outsourced" to GPU?
306 2017-12-13 19:10:31	0|jonasschnelli|(http://on-demand.gputechconf.com/gtc/2013/presentations/S3018-High-Performance-Cryptology-on-GPUs.pdf)
307 2017-12-13 19:10:56	0|jonasschnelli|GAit: yes. Hardkernel
308 2017-12-13 19:11:22	0|jonasschnelli|But for a "fullnode-in-a-box", I think you need more horsepower... that's why I think the Jetson TX1 would be a good choice.
309 2017-12-13 19:11:35	0|jonasschnelli|Also,... you don't pay for stuff you don't need (HDMI, 4USB, etc.)
310 2017-12-13 19:15:42	0|gmaxwell|the gpu is useless, and otherwise it's just an arm a57 and wouldn't be faster than other a57s
311 2017-12-13 19:18:24	0|wumpus|with modern GPUs you can certainly do cryptography, would'nt be surprised if you could port secp256k1 to opencl, but gpus are unreliable, even the high-end cloud computing ones, but especially customer ones. It'd be a mess.
312 2017-12-13 19:19:05	0|gmaxwell|well there have been gpu key generators, for example, that were a couple times faster than openssl, but significantly slower than libsecp256k1.
313 2017-12-13 19:19:10	0|wumpus|and as we already get a enough reports of errors due to overheating *CPUs*...
314 2017-12-13 19:19:28	0|gmaxwell|lack of 64,64->128 multiply is a big performance hit.
315 2017-12-13 19:19:55	0|wumpus|still, you could distribute over both the CPU and PGU
316 2017-12-13 19:22:10	0|gmaxwell|the pdf jonas linked to showed only a 6x speedup over naieve code on the cpu given arbritarily high parallelism, with a gpu using ~3x the power, and having a 21x hit in latency. Not especially attractive even if you ignore the historical stability issues.
317 2017-12-13 19:22:48	0|gmaxwell|(and the man power required to write and maintain the software, and the requirement for propritary drivers, etc.)
318 2017-12-13 19:24:04	0|wumpus|yes
319 2017-12-13 19:25:46	0|Provoostenator|wumpus: I can't find "snoei" in the nl_NL Transifex translations, maybe it's in the nl one? Can you add me there?
320 2017-12-13 19:26:55	0|wumpus|it's possible that it was removed since last update from transifex
321 2017-12-13 19:27:46	0|wumpus|but no, I can't add you to anything, I somehow don't have access to teams there
322 2017-12-13 19:28:12	0|Provoostenator|But you were able to add me to nl_NL, or did I just social engineer Transifex staff?
323 2017-12-13 19:28:52	0|wumpus|no, I didn't add you to anything
324 2017-12-13 19:30:26	0|wumpus|I can only delete stuff apparentlly, transifex access controls make no sense
325 2017-12-13 19:31:06	0|wumpus|oh that's not true I can also create new translations, and sub-projects, just not teams
326 2017-12-13 19:31:47	0|Provoostenator|Does the translation script only use nl_NL? Because then there's no need for me to have access to nl (or nl_be)
327 2017-12-13 19:32:18	0|wumpus|for the next major version I should probably create the transations in a new organization
328 2017-12-13 19:33:25	0|wumpus|$ find -name bitcoin_nl\* -> ./src/qt/locale/bitcoin_nl_NL.ts ./src/qt/locale/bitcoin_nl.ts
329 2017-12-13 19:34:09	0|Provoostenator|So that combines nl, nl_BE and nl_NL somehow?
330 2017-12-13 19:34:40	0|wumpus|no
331 2017-12-13 19:34:49	0|wumpus|that's literally nl_NL and nl, no nl_BE
332 2017-12-13 19:35:03	0|wumpus|it doesn't combine anything, it just copies the translation files
333 2017-12-13 19:37:24	0|wumpus|nl_BE either falls below the threshold of 10 messages, or has been added since the last translations pull
334 2017-12-13 19:39:10	0|Provoostenator|I'm reading the script now. Is it actually doing the downloading or do you do that manually?
335 2017-12-13 19:39:23	0|wumpus|yes, it does the downloading
336 2017-12-13 19:39:35	0|Provoostenator|update-translations.py? Where?
337 2017-12-13 19:39:43	0|wumpus|we talked about this before today?
338 2017-12-13 19:40:01	0|Provoostenator|I was referring to this: https://github.com/bitcoin/bitcoin/issues/11875#issuecomment-351331497
339 2017-12-13 19:41:14	0|Provoostenator|Ah wait, I see it now. TX is another command. I'll figure it out.
340 2017-12-13 19:41:19	0|wumpus|fetch_all_translations(), fetches the translations
341 2017-12-13 20:01:00	0|jonasschnelli|Is there a way to detect if IsInitialBlockDownload() via RPC?
342 2017-12-13 20:01:16	0|jonasschnelli|nm: getblockchaininfo
343 2017-12-13 20:13:34	0|BlueMatt|#11888 should get an 0.16 tag
344 2017-12-13 20:13:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/11888 | Prevent Opening Wallets Simultaneously in Two Instances · Issue #11888 · bitcoin/bitcoin · GitHub
345 2017-12-13 20:17:47	0|jonasschnelli|Tagged
346 2017-12-13 20:20:09	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #11889: Drop extra script variable in ProduceSignature (06master...06pr/dupvar) 02https://github.com/bitcoin/bitcoin/pull/11889
347 2017-12-13 20:27:49	0|jonasschnelli|BlueMatt: re: https://github.com/bitcoin/bitcoin/pull/11281#pullrequestreview-82968766
348 2017-12-13 20:27:59	0|jonasschnelli|can you explain that a bit more for me?
349 2017-12-13 20:28:42	0|jonasschnelli|I think locking cs_main during the AddToWalletIfInvolvingMe() part would be removing most of the lock optimization done in this PR
350 2017-12-13 20:28:53	0|BlueMatt|jonasschnelli: the !chainActive.Contains(pindex) check *must* be in the same cs_main lock as AddToWalletIfInvolvingMe
351 2017-12-13 20:29:25	0|jonasschnelli|BlueMatt: But AddToWalletIfInvolvingMe is currently (in the PR) done without cs_main
352 2017-12-13 20:30:27	0|jonasschnelli|If we remove the general locks and add those back in ever block, it seems like a wast of effort. I don't see why AddToWalletIfInvolvingMe would need cs_main...
353 2017-12-13 20:30:49	0|jonasschnelli|*every
354 2017-12-13 20:32:26	0|jonasschnelli|I way expecting that we can do the two most significant time consumers (ReadBlockFromDisk, AddToWalletIfInvolvingMe) without cs_main
355 2017-12-13 20:32:28	0|BlueMatt|jonasschnelli: uhhhh well thats a second bug then
356 2017-12-13 20:32:35	0|BlueMatt|AddToWalletIfInvolvingMe requires cs_main
357 2017-12-13 20:32:42	0|BlueMatt|cause it can call AbandonTransaction
358 2017-12-13 20:32:50	0|BlueMatt|errrr, I meant MarkConflicted
359 2017-12-13 20:33:13	0|jonasschnelli|BlueMatt: ahh.. redudant deadlock
360 2017-12-13 20:33:32	0|jonasschnelli|seems my #11281 approach is a dead end
361 2017-12-13 20:33:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
362 2017-12-13 20:33:40	0|BlueMatt|no?
363 2017-12-13 20:33:55	0|BlueMatt|its still helpful to *unlock* cs_main after every block
364 2017-12-13 20:34:03	0|jonasschnelli|if we add AddToWalletIfInvolvingMe under cs_main two, alomst every code part will aquire the lock
365 2017-12-13 20:34:07	0|BlueMatt|so?
366 2017-12-13 20:34:34	0|BlueMatt|another thing you could do (which I thought you were going to) is push down the cs_main in the ReadBlockFromDisk
367 2017-12-13 20:34:44	0|jonasschnelli|BlueMatt: yes. I wanted to do this after the PR
368 2017-12-13 20:34:45	0|BlueMatt|then you take cs_main to get the diskpos out of CBlockIndex and then lose cs_main during the actual reading
369 2017-12-13 20:34:58	0|jonasschnelli|BlueMatt: yes
370 2017-12-13 20:46:09	0|jonasschnelli|Would adding a function ReadBlockFromDiskLock() be a bad design (where the function would lock cs_main for pindex->GetBlockPos() but not for the actual reading ReadBlockFromDisk()
371 2017-12-13 20:51:20	0|gmaxwell|normally you'd want to push up the lock by passing in the offset so the lock acqusition can be merged into the caller grabbing cs_main for other reasons.
372 2017-12-13 20:51:42	0|gmaxwell|like to decide if it knows about the block at all.
373 2017-12-13 21:00:14	0|BlueMatt|gmaxwell: I disagree 100%...
374 2017-12-13 21:00:34	0|BlueMatt|jonasschnelli: we already do, just push down the lock instead of taking it outside
375 2017-12-13 21:01:26	0|BlueMatt|gmaxwell: there are already two ReadBlockFromDisk's - one that does not require cs_main (and is often called without it), and one which does, but only for the non-disk-read part of the function
376 2017-12-13 21:01:35	0|BlueMatt|no reason to require the caller take cs_main for the whole time if they dont want to
377 2017-12-13 21:01:41	0|BlueMatt|cs_main is recursive for a reason....
378 2017-12-13 21:01:41	0|gmaxwell|BlueMatt: you think you should take a lock to fetch a single integer, when the caller already needed the lock in the first place to get the pindex member?
379 2017-12-13 21:02:21	0|BlueMatt|I mean that version of ReadBlockFromDisk already is barely called anywhere, iirc jonasschnelli's use-case here would be one of two places its used, and in his case you clearly *dont* want to be holding cs_main
380 2017-12-13 21:02:30	0|BlueMatt|his whole goal is to reduce its usage in this case
381 2017-12-13 21:02:46	0|gmaxwell|sure, so look up the offset when you check if the block is in the index to begin with.
382 2017-12-13 21:03:01	0|BlueMatt|well in jonasschnelli's use-case above you cant do that...
383 2017-12-13 21:03:10	0|BlueMatt|you *must* do the check after reading, when processing
384 2017-12-13 21:03:19	0|gmaxwell|okay I didn't see the usecase then
385 2017-12-13 21:03:37	0|BlueMatt|the race in AddToWalletIfInvolvingMe in the rescan stuff is subtle af
386 2017-12-13 21:04:42	0|jonasschnelli|BlueMatt: so acquiring cs_main in ReadBlockFromDisk() just for reading CDiskBlockPos blockPos;,... right?
387 2017-12-13 21:04:58	0|jonasschnelli|Doesn't it hurt to acquire it twice for the existing use cases of ReadBlockFromDisk()?
388 2017-12-13 21:05:00	0|BlueMatt|i think thats fine
389 2017-12-13 21:05:03	0|BlueMatt|indeed
390 2017-12-13 21:05:08	0|BlueMatt|its recursive
391 2017-12-13 21:10:26	0|jamesob|somewhat related question... was browsing getrawtransaction and noticed we acquire cs_main in a slightly more broad scope than necessary (though not by much) -- is it worth making a change to scope cs_main use as tightly as possible, or does it not matter so much (i.e. within the context of a single rpc call)?
392 2017-12-13 21:11:32	0|jonasschnelli|jamesob: I think it would be worth... though ask BlueMatt, he is actually working on optimising concurrency
393 2017-12-13 21:13:24	0|jamesob|also, is there somewhere we're having an ongoing discussion about splitting cs_main into separate read & write locks?
394 2017-12-13 21:14:38	0|BlueMatt|jamesob: I mean looks like getrawtransaction only acquires it too broadly for like the parsing of two parameters, dunno if thats worth it...for something where you hit disk or are parsing a huge map and have a ton of logic it'd probably be worth it, but no need to create review burden to avoid holding cs_main for a ParseHashV...
395 2017-12-13 21:14:57	0|jamesob|BlueMatt: yup, makes sense
396 2017-12-13 21:15:05	0|BlueMatt|jamesob: heh, I dont think cs_main has made much progress of late....I think most of the curren progress is on making things use cs_main less
397 2017-12-13 21:16:06	0|BlueMatt|I think the generally-accepted goal is for things to have their own "view" of the chain - eg wallet probably can/should start doing checks on a cached/validationinterface-updated chainActive.Tip() instead of ever locking cs_main to query for the current validation state
398 2017-12-13 21:16:11	0|BlueMatt|same goes for other subsystems
399 2017-12-13 21:16:45	0|BlueMatt|but its a long road ahead...I think we may be not too far off on wallet in my brief glancing a few weeks ago when sipa was saying we should do it sooner rather than later, but I dunno if anyone's tried to implement it
400 2017-12-13 21:16:55	0|BlueMatt|gonna be lots of corner cases either way, I'm sure
401 2017-12-13 21:17:28	0|BlueMatt|also working on (very slowly) migrating CNodeState out of cs_main, but I havent picked that work up in a while due to number of outstanding prs :/
402 2017-12-13 21:17:53	0|jamesob|yeah, that sounds like the right way to go. definitely easier to make gradual changes that way instead of having to (delicately) modify cs_main itself.
403 2017-12-13 21:18:01	0|BlueMatt|exactly
404 2017-12-13 21:18:56	0|BlueMatt|I mean the other (obvious) thing is to make, as you suggested, cs_main a read/write/upgrade lock so that simple things like reading CBlockIndex->nStatus dont require a full cs_main global lock
405 2017-12-13 21:19:35	0|BlueMatt|just doing that for CBlockIndex fields feels like it'd be helpful (see, eg, the above discussion about needing cs_main for ReadBlockFromDisk....), but also not something I've tried to do in like 5 years, dunno if anyone else has
406 2017-12-13 21:31:06	0|ossifrage|Did changing the wallet passphrase stop dumping the keypool in 0.15.x? I just changed the passphrase but keypoololdest is still old?
407 2017-12-13 21:34:52	0|BlueMatt|did it ever dump the keypool?
408 2017-12-13 21:38:58	0|ossifrage|BlueMatt, okay, I guess I had bad information, someone told me that it discarded the keypool when you changed the passphrase as a security feature.
409 2017-12-13 21:39:46	0|BlueMatt|it does when you *first encrypt* (I'm 90% sure)
410 2017-12-13 21:39:50	0|BlueMatt|changing, I do not believe so
411 2017-12-13 21:40:18	0|ossifrage|Ah yeah, my wallet was unencrypted before that
412 2017-12-13 21:41:28	0|ossifrage|So I'm stuck calling getnewaddress 980 times :-(
413 2017-12-13 21:41:45	0|instagibbs|It should only throw away your master privkey on first encryption, yes
414 2017-12-13 21:42:01	0|instagibbs|I have not tested that sequence myself however
415 2017-12-13 21:42:34	0|BlueMatt|ossifrage: heh, 980? thats not too bad...I had to do like 99k recently...that took a while
416 2017-12-13 21:43:23	0|ossifrage|I basically want to get an address that is not in my backups
417 2017-12-13 21:47:02	0|ossifrage|My poor 'receiving addresses list' is already painfully long as it is (mostly with discarded/unused addresses)
418 2017-12-13 21:47:59	0|BlueMatt|getrawchangeaddress intead, I think
419 2017-12-13 21:48:40	0|luke-jr|I thought it discarded keypool on change passphrase also
420 2017-12-13 21:49:08	0|ossifrage|luke-jr, I changed the passphrase and keypoololdest is 109 days old
421 2017-12-13 21:49:33	0|ossifrage|which is about when I initially set the passphrase
422 2017-12-13 21:49:51	0|sipa|changing your passphrase doesn't change your masterkey, though
423 2017-12-13 21:50:46	0|luke-jr|sipa: no?
424 2017-12-13 21:52:01	0|luke-jr|hmm
425 2017-12-13 21:53:09	0|luke-jr|is there a reason not to?
426 2017-12-13 21:54:32	0|BlueMatt|yea..not having to re-encrypt everything
427 2017-12-13 21:56:05	0|Randolf|In comparison, TrueCrypt works this way -- re-encrypting the whole hard drive every time the user wanted to change their boot-password would be very time-consuming.
428 2017-12-13 21:56:06	0|luke-jr|why would you need to reencrypt everything, just to add a new master key?
429 2017-12-13 21:57:20	0|BlueMatt|luke-jr: how in the hell would you do it otherwise?
430 2017-12-13 21:57:43	0|ossifrage|My goal was to invalidate my backup for new transactions without loosing the history/metadata
431 2017-12-13 21:57:47	0|luke-jr|BlueMatt: SetHDMasterKey(GenerateNewHDMasterKey())?
432 2017-12-13 21:58:08	0|sipa|luke-jr: the encryption master key, not the hd master key
433 2017-12-13 21:58:11	0|luke-jr|oh
434 2017-12-13 21:58:13	0|BlueMatt|luke-jr: we're not talking about HD master key
435 2017-12-13 21:58:32	0|ossifrage|In my case it is *not* a HD wallet (I think it predates the HD stuff)
436 2017-12-13 21:58:34	0|luke-jr|I was XD
437 2017-12-13 21:58:55	0|sipa|rotating out the hd master key is something we should support, but it can be orthogonal to the encryption question
438 2017-12-13 21:59:07	0|BlueMatt|ossifrage: yes, I think over time we need to support that use-case by upgrading to hd then letting people rotate the hd seed and optioanlly flush keypool at that time
439 2017-12-13 21:59:11	0|BlueMatt|#11085
440 2017-12-13 21:59:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/11085 | Add sethdseed RPC to initialize or replace HD seed. by dooglus · Pull Request #11085 · bitcoin/bitcoin · GitHub
441 2017-12-13 21:59:34	0|sipa|yah
442 2017-12-13 22:00:00	0|ossifrage|Is there a way to 'decrypt' the wallet so I can reencrypt it and dump the keypool?
443 2017-12-13 22:00:41	0|luke-jr|I don't think so
444 2017-12-13 22:00:42	0|BlueMatt|not atm
445 2017-12-13 22:00:53	0|BlueMatt|i mean you can also hack in your own rpc that empties keypool
446 2017-12-13 22:00:56	0|BlueMatt|in one db batch
447 2017-12-13 22:01:00	0|BlueMatt|which would make it faster
448 2017-12-13 22:02:43	0|ossifrage|The 'receiving address list' UI is already insanely long, adding another 960 entries will suck
449 2017-12-13 22:05:00	0|luke-jr|[21:48:00] <BlueMatt> getrawchangeaddress intead, I think
450 2017-12-13 22:06:27	0|ossifrage|luke-jr, yeah, that might work until I forget to do it
451 2017-12-13 22:09:35	0|ossifrage|getrawchangeaddress caused keypoolsize to go down by 1
452 2017-12-13 22:13:31	0|ossifrage|and 'bitcoin-cli listreceivedbyaddress 0 true | jq .[].address | grep <getrawchangeaddress>' does not return the address
453 2017-12-13 22:15:29	0|sipa|by definition transaction outputs to a change address are not treated as incoming payments
454 2017-12-13 22:16:27	0|ossifrage|sipa, ok yeah... but the getrawchangeaddress comes from the keypool
455 2017-12-13 22:17:27	0|sipa|yes?
456 2017-12-13 22:17:42	0|sipa|i don't understand what you're expecting
457 2017-12-13 22:18:32	0|ossifrage|Ah, I understand now, use getrawchangeaddress 980 times to discard the old keys... duh
458 2017-12-13 22:18:59	0|sipa|it will only discard change keys
459 2017-12-13 22:58:05	0|ossifrage|Okay calling getrawchangeaddress 980 times did what I wanted, it consumed all the keys in the (non HD) keypool without bloating the 'receiving address' list.
460 2017-12-13 22:58:50	0|ossifrage|Now both getrawchangeaddress and getnewaddress fail with "Error: Keypool ran out, please call keypoolrefill first" as expected
461 2017-12-13 22:59:04	0|luke-jr|that's convenient
462 2017-12-13 23:00:16	0|ossifrage|I wanted to invalidate my backups without loosing the history that goes back to 2011
463 2017-12-13 23:01:15	0|ossifrage|BlueMatt, thanks!
464 2017-12-13 23:15:47	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #11892:  [Qt] Warn if fallback fee has been used (06master...062017/12/qt_warn_fallbackfee) 02https://github.com/bitcoin/bitcoin/pull/11892
465 2017-12-13 23:19:09	0|gmaxwell|We might actually be running low on sockets on the network, not critically so, but low none the less.
466 2017-12-13 23:19:40	0|gmaxwell|I am seeing multiple nodes with all or nearly all inbound sockets in use, and it doesn't appear at first analysis to be a connect flood attack.
467 2017-12-13 23:46:50	0|jonasschnelli|gmaxwell: due to a lot of peers in IBD? Or plenty of SPV?