12017-12-13T00:03:24  *** Dyaheon has joined #bitcoin-core-dev
  22017-12-13T00:05:47  *** eck has quit IRC
  32017-12-13T00:06:11  *** eck has joined #bitcoin-core-dev
  42017-12-13T00:11:08  *** jamesob has quit IRC
  52017-12-13T00:12:10  *** jamesob has joined #bitcoin-core-dev
  62017-12-13T00:17:45  *** eck has quit IRC
  72017-12-13T00:24:39  *** Deacyde has joined #bitcoin-core-dev
  82017-12-13T00:27:10  *** mrfrasha has quit IRC
  92017-12-13T00:28:15  *** dermoth has quit IRC
 102017-12-13T00:28:42  *** dermoth has joined #bitcoin-core-dev
 112017-12-13T00:28:51  *** dgenr8 has quit IRC
 122017-12-13T00:34:45  *** Deacyde has quit IRC
 132017-12-13T00:36:16  *** Deacyde has joined #bitcoin-core-dev
 142017-12-13T00:42:27  *** lnostdal has quit IRC
 152017-12-13T00:43:25  *** Deacyde has quit IRC
 162017-12-13T00:43:55  *** jb55 has joined #bitcoin-core-dev
 172017-12-13T00:46:13  *** dermoth has quit IRC
 182017-12-13T00:46:35  *** dermoth has joined #bitcoin-core-dev
 192017-12-13T00:48:27  *** jb55 has quit IRC
 202017-12-13T00:48:57  *** jamesob has quit IRC
 212017-12-13T00:49:52  *** eck has joined #bitcoin-core-dev
 222017-12-13T00:51:08  *** eck has quit IRC
 232017-12-13T00:51:43  *** lnostdal has joined #bitcoin-core-dev
 242017-12-13T00:52:55  *** eck has joined #bitcoin-core-dev
 252017-12-13T00:56:41  *** mrfrasha has joined #bitcoin-core-dev
 262017-12-13T00:57:24  *** Dizzle has quit IRC
 272017-12-13T00:58:40  *** Deacyde has joined #bitcoin-core-dev
 282017-12-13T00:58:41  *** Giszmo has quit IRC
 292017-12-13T01:02:40  *** Szadek has quit IRC
 302017-12-13T01:07:01  *** AaronvanW has quit IRC
 312017-12-13T01:15:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 322017-12-13T01:17:02  *** Randolf has joined #bitcoin-core-dev
 332017-12-13T01:18:57  *** DrFeelGood has quit IRC
 342017-12-13T01:23:49  *** dabura667 has joined #bitcoin-core-dev
 352017-12-13T01:28:27  *** DvdKhl has quit IRC
 362017-12-13T01:29:24  *** Murch has quit IRC
 372017-12-13T01:36:29  *** DvdKhl has joined #bitcoin-core-dev
 382017-12-13T01:37:19  *** Chris_Stewart_5 has quit IRC
 392017-12-13T01:38:59  *** Giszmo has joined #bitcoin-core-dev
 402017-12-13T01:50:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 412017-12-13T01:58:36  *** Ylbam has quit IRC
 422017-12-13T02:12:56  *** go1111111 has quit IRC
 432017-12-13T02:14:28  *** DvdKhl has quit IRC
 442017-12-13T02:16:22  *** pkx2 has joined #bitcoin-core-dev
 452017-12-13T02:20:44  *** Chris_Stewart_5 has quit IRC
 462017-12-13T02:21:32  *** jamesob has joined #bitcoin-core-dev
 472017-12-13T02:23:47  *** shtirlic has quit IRC
 482017-12-13T02:26:16  *** shtirlic has joined #bitcoin-core-dev
 492017-12-13T02:35:50  *** jb55 has joined #bitcoin-core-dev
 502017-12-13T02:46:38  *** quantbot has joined #bitcoin-core-dev
 512017-12-13T02:50:40  *** _ has joined #bitcoin-core-dev
 522017-12-13T02:51:03  *** _ is now known as Guest22330
 532017-12-13T02:51:08  *** quantbot has quit IRC
 542017-12-13T02:51:45  *** Guest22330 has quit IRC
 552017-12-13T03:09:57  *** mrfrasha has quit IRC
 562017-12-13T03:12:35  *** mrfrasha has joined #bitcoin-core-dev
 572017-12-13T03:14:32  *** spinza has quit IRC
 582017-12-13T03:42:01  *** go1111111 has joined #bitcoin-core-dev
 592017-12-13T03:59:56  *** edman80 has joined #bitcoin-core-dev
 602017-12-13T04:01:55  *** bityogi has quit IRC
 612017-12-13T04:03:37  *** spinza has joined #bitcoin-core-dev
 622017-12-13T04:06:14  *** bityogi has joined #bitcoin-core-dev
 632017-12-13T04:09:05  *** meshcollider has quit IRC
 642017-12-13T04:16:53  *** bityogi has quit IRC
 652017-12-13T04:21:07  *** Roberto_2000 has joined #bitcoin-core-dev
 662017-12-13T04:23:40  *** meshcollider has joined #bitcoin-core-dev
 672017-12-13T04:23:59  *** xmsx has joined #bitcoin-core-dev
 682017-12-13T04:24:17  <xmsx> hey, could anyone help me with generating segwit addresses?
 692017-12-13T04:25:02  <meshcollider> Anyone seen this Travis failure before https://travis-ci.org/bitcoin/bitcoin/jobs/315614592
 702017-12-13T04:25:15  <meshcollider> xmsx: what do you need help with?
 712017-12-13T04:25:33  *** goatpig has quit IRC
 722017-12-13T04:27:13  <meshcollider> https://pastebin.com/Ek9htTQL
 732017-12-13T04:29:06  <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
 742017-12-13T04:29:26  <xmsx> Here's the code I'm using: https://pastebin.com/us0qEqe1
 752017-12-13T04:30:28  <xmsx> My only question is -- Am I using correct  $compressed_public_key at step 1?
 762017-12-13T04:32:54  <xmsx> e.g. docs say: "To create a P2SH-P2WPKH address: 1) Calculate the RIPEMD160 of the SHA256 of a public key (keyhash)."
 772017-12-13T04:33:29  <xmsx> Do I need to use compressed version of keyhash?
 782017-12-13T04:35:17  <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 :)
 792017-12-13T04:36:01  <xmsx> Also, don't try to run that code above, it won't work for you, it's just a pseudocode :)
 802017-12-13T04:40:11  *** xmsx has quit IRC
 812017-12-13T04:40:27  *** xmsx has joined #bitcoin-core-dev
 822017-12-13T04:41:31  <sipa> xmsx: sorry, this the dev channel for bitcoin core, a c++ bitcoin client
 832017-12-13T04:42:38  <xmsx> Can you just import this private key: 5KAwW31HxQW5Jrp4HM3o59BPRXarMP87imDR1nrjQpGvnTzwafK and tell me if segwit for it is 37fZYysB6c2iMt2cywZyUUydqQkR6vkCri?
 842017-12-13T04:42:59  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef8ba7d73a48...ba2f19504c6b
 852017-12-13T04:43:00  <bitcoin-git> bitcoin/master 1729c29 Cory Fields: net: split socket creation out of connection...
 862017-12-13T04:43:00  <bitcoin-git> bitcoin/master 9e3b2f5 Cory Fields: net: Move IsSelectableSocket check into socket creation...
 872017-12-13T04:43:01  <bitcoin-git> bitcoin/master df3bcf8 Cory Fields: net: pass socket closing responsibility up to caller for outgoing connections...
 882017-12-13T04:43:15  <bitcoin-git> [bitcoin] laanwj closed pull request #11363: net: Split socket create/connect (master...split-socket-create-connect) https://github.com/bitcoin/bitcoin/pull/11363
 892017-12-13T04:59:05  *** quantbot has joined #bitcoin-core-dev
 902017-12-13T05:00:52  *** pkx2 has quit IRC
 912017-12-13T05:00:52  *** quantbot has quit IRC
 922017-12-13T05:01:05  *** quantbot has joined #bitcoin-core-dev
 932017-12-13T05:01:33  *** jamesob has quit IRC
 942017-12-13T05:03:45  *** Roberto_2000 is now known as AegisAttack_9000
 952017-12-13T05:08:45  *** blasfem has joined #bitcoin-core-dev
 962017-12-13T05:12:39  *** Giszmo has quit IRC
 972017-12-13T05:13:08  *** Giszmo has joined #bitcoin-core-dev
 982017-12-13T05:18:01  *** blasfem has quit IRC
 992017-12-13T05:21:32  *** AegisAttack_9000 is now known as PIMP
1002017-12-13T05:21:50  *** PIMP is now known as Allah
1012017-12-13T05:22:17  *** xmsx has quit IRC
1022017-12-13T05:22:27  *** Allah is now known as AegisAttack
1032017-12-13T05:25:57  *** AegisAttack is now known as HODLGod
1042017-12-13T05:26:54  *** HODLGod is now known as AegisAttack
1052017-12-13T05:28:00  *** quantbot has quit IRC
1062017-12-13T05:48:37  <bitcoin-git> [bitcoin] kallewoof opened pull request #11884: [trivial] Remove unused include in hash.cpp (master...20171213-unneeded-include-hash-cpp) https://github.com/bitcoin/bitcoin/pull/11884
1072017-12-13T06:17:55  *** bitcoinNOOOB has joined #bitcoin-core-dev
1082017-12-13T06:18:05  <bitcoinNOOOB> Hello?
1092017-12-13T06:18:56  <bitcoinNOOOB> Anyone here?
1102017-12-13T06:19:38  *** bitcoinNOOOB has quit IRC
1112017-12-13T06:21:41  *** AegisAttack has quit IRC
1122017-12-13T06:25:11  *** jb55 has quit IRC
1132017-12-13T06:31:11  *** quantbot has joined #bitcoin-core-dev
1142017-12-13T06:35:58  *** quantbot has quit IRC
1152017-12-13T06:37:27  *** jtimon has quit IRC
1162017-12-13T06:42:02  *** d9b4bef9 has quit IRC
1172017-12-13T06:43:09  *** d9b4bef9 has joined #bitcoin-core-dev
1182017-12-13T06:45:58  *** go1111111 has quit IRC
1192017-12-13T06:49:16  <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)?
1202017-12-13T06:50:17  <sipa> i usually just write a new commit at the end, and then move/apply/squash it with rebase -i
1212017-12-13T06:50:25  <wumpus> same here
1222017-12-13T06:50:52  <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'
1232017-12-13T06:50:56  <wumpus> I make lots of temporary commits, then at some point I merge them into the commit they belong
1242017-12-13T06:51:34  <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
1252017-12-13T06:52:32  <sipa> (i squash very liberally, but try to avoid actually rebasing0
1262017-12-13T06:53:23  <wumpus> if you already have changes in your working tree that need to be spread into multiple commits, git add -p is great
1272017-12-13T06:56:20  <jonasschnelli> thanks!
1282017-12-13T06:56:54  <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)?
1292017-12-13T06:57:40  <jonasschnelli> I whish my IDE would have a way to directly amend commit a line-change (or block) into a selected historical commit
1302017-12-13T06:57:51  <wumpus> I think everything you can do with -i (interactive) should be possible without -i, it's just a longer sequence of commands
1312017-12-13T06:58:25  <wumpus> in a way an interactive mode makes you lazy :)
1322017-12-13T06:59:29  <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
1332017-12-13T06:59:53  <wumpus> that would be so much easier for referring to them in rebase commands
1342017-12-13T07:01:38  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
1352017-12-13T07:01:38  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
1362017-12-13T07:01:46  <jonasschnelli> wumpus: indeed
1372017-12-13T07:15:12  *** mrfrasha has quit IRC
1382017-12-13T07:35:52  *** Victorsueca has quit IRC
1392017-12-13T07:37:12  *** Victorsueca has joined #bitcoin-core-dev
1402017-12-13T07:59:05  *** meshcollider has quit IRC
1412017-12-13T08:02:35  *** tattoovicious has joined #bitcoin-core-dev
1422017-12-13T08:08:44  *** Kozuch has joined #bitcoin-core-dev
1432017-12-13T08:11:44  *** go1111111 has joined #bitcoin-core-dev
1442017-12-13T08:12:53  *** Williiiiiii has joined #bitcoin-core-dev
1452017-12-13T08:15:32  *** Williiiiiii has quit IRC
1462017-12-13T08:19:12  *** promag has quit IRC
1472017-12-13T08:32:29  *** tattoovicious has quit IRC
1482017-12-13T08:34:15  *** fanquake has joined #bitcoin-core-dev
1492017-12-13T08:43:05  *** laurentmt has joined #bitcoin-core-dev
1502017-12-13T08:49:47  <Provoostenator> There's a Github issue or PR about consolidating translation files, but I can't find it. Not even with Google...
1512017-12-13T08:49:53  *** tattoovicious has joined #bitcoin-core-dev
1522017-12-13T08:53:06  <fanquake> There are various issues for translations open at the moment. Do you want to add discussion somewhere?
1532017-12-13T08:54:40  <fanquake> cfields did you end up sending the zeromq mingw64 patch upstream?
1542017-12-13T08:55:53  <Provoostenator> I want to link to it from #11875 because reducing the number of locales would probably be helpful for review.
1552017-12-13T08:55:54  <gribble> https://github.com/bitcoin/bitcoin/issues/11875 | Snoei: a.k.a. how to translate technical jargon · Issue #11875 · bitcoin/bitcoin · GitHub
1562017-12-13T08:56:16  <Provoostenator> I remember the issue was quite specific about whch language files could be combined.
1572017-12-13T09:12:55  *** meshcollider has joined #bitcoin-core-dev
1582017-12-13T09:15:21  *** tiagotrs has joined #bitcoin-core-dev
1592017-12-13T09:15:21  *** tiagotrs has joined #bitcoin-core-dev
1602017-12-13T09:16:26  <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
1612017-12-13T09:17:23  *** Ab_ has joined #bitcoin-core-dev
1622017-12-13T09:17:34  <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)
1632017-12-13T09:18:59  *** Ab_ has quit IRC
1642017-12-13T09:19:02  <Provoostenator> I think the PR (which I can't find) was just combining (mostly) identical languages like Dutch and Flemish.
1652017-12-13T09:20:44  *** aqeel has joined #bitcoin-core-dev
1662017-12-13T09:21:11  <sipa> jonasschnelli: my odroid iseems be having some trouble... i just had a block that took 12 hours to validate
1672017-12-13T09:21:44  <sipa> it looks like it's just insanely slow I/O (7.5s per txin), but it's much faster after a reboot
1682017-12-13T09:22:06  <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.
1692017-12-13T09:22:33  <wumpus> yes, I have already been selective which languages I include in the repository
1702017-12-13T09:23:19  <wumpus> also translations with too few messages don't get included
1712017-12-13T09:23:55  <wumpus> (although that threshold is at 10, should probably be higher with the huge volume of translatable strings we have these days)
1722017-12-13T09:24:03  *** alreadylate has joined #bitcoin-core-dev
1732017-12-13T09:24:42  <Provoostenator> As long as the fallback is sane and the translations are reviewed, wouldn't 1 be a low enough threshold?
1742017-12-13T09:26:26  <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.
1752017-12-13T09:27:41  <Provoostenator> But if instead languages immedidately fall back to English then it's probably better to leave them out if they're seriously incomplete.
1762017-12-13T09:28:12  *** SopaXorzTaker has joined #bitcoin-core-dev
1772017-12-13T09:29:51  <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
1782017-12-13T09:30:30  <Provoostenator> Without review even worse things could happen.
1792017-12-13T09:31:04  <sipa> oh yes.
1802017-12-13T09:31:34  *** AaronvanW has joined #bitcoin-core-dev
1812017-12-13T09:31:39  <Provoostenator> So I think the amount / quality / trustworthyness of review is more important than the number of translated phrases (depdneing on fallback behavior).
1822017-12-13T09:32:23  <Provoostenator> Obviously it's not worth monitoring reviewers for a language with 5 words, so I guess it's the same outcome.
1832017-12-13T09:32:30  *** Aaronvan_ has joined #bitcoin-core-dev
1842017-12-13T09:36:09  *** AaronvanW has quit IRC
1852017-12-13T09:36:24  *** vicenteH has joined #bitcoin-core-dev
1862017-12-13T09:38:21  *** aqeel has quit IRC
1872017-12-13T09:40:04  <wumpus> what use would a translation with one translated phrase be? I don't see it
1882017-12-13T09:40:35  <wumpus> for translation to be useful the entire application needs to be translated, more or less, certainly the most visited parts
1892017-12-13T09:41:00  <sipa> i don't know how i'd translate anything dirrectly in dutch vs flemish
1902017-12-13T09:41:12  *** promag has joined #bitcoin-core-dev
1912017-12-13T09:41:50  <wumpus> I do agree the threshold could be lower for XX_yy languages that just override some messages than for XX "top level" ones
1922017-12-13T09:42:51  <wumpus> but otherwise the number of message is a measure of compleness
1932017-12-13T09:43:07  <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.
1942017-12-13T09:43:36  <Provoostenator> But as a general rule I would agree the majority of the frequently used parts of the app should be translated and maintained.
1952017-12-13T09:44:01  *** Emcy_ has quit IRC
1962017-12-13T09:45:11  <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.
1972017-12-13T09:45:18  <wumpus> another reason why a language with many translations is preferable is because, very likely, there is more translation activity for it
1982017-12-13T09:45:32  <wumpus> a language with 10 messages will likely have had 1 person type in some messages
1992017-12-13T09:46:11  <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
2002017-12-13T09:47:06  <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
2012017-12-13T09:47:28  <wumpus> e.g. what about chinese or arabic? it just doesn't make sense t ohave english words interspersed there
2022017-12-13T09:48:19  *** timothy has joined #bitcoin-core-dev
2032017-12-13T09:49:07  *** Emcy has joined #bitcoin-core-dev
2042017-12-13T09:49:12  <Provoostenator> The glossary for each language would contain the suggested translation, which in most cases would not be a translation.
2052017-12-13T09:50:17  <wumpus> you want to make one for every language?
2062017-12-13T09:50:39  <Provoostenator> Well, every language where it's useful.
2072017-12-13T09:50:49  <Provoostenator> Isn't that how it already works?
2082017-12-13T09:50:50  <wumpus> that's awesome
2092017-12-13T09:52:20  <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)
2102017-12-13T09:54:51  <Provoostenator> It's seems problematic to have a process that nobody can focus enough on to prevent things from breaking.
2112017-12-13T09:55:36  <wumpus> it's not clear to me what kind of process works for translating open source software
2122017-12-13T09:56:05  *** quantbot has joined #bitcoin-core-dev
2132017-12-13T09:56:10  <wumpus> though the current one works, more or less, it's certainly better than not translating at all
2142017-12-13T09:56:14  <Provoostenator> I think it's better to not translate when in doubt
2152017-12-13T09:56:22  <wumpus> whose doubt?
2162017-12-13T09:56:49  <wumpus> that's the problem really here, you'd have to mobilize lots of volunteers
2172017-12-13T09:56:55  <wumpus> unless you know all languages yourself :)
2182017-12-13T09:57:18  <wumpus> maybe it's realistic now that bitcoin is so well-known
2192017-12-13T09:57:26  <Provoostenator> There's a lot of websites and applications out there where the translation is worse than the original.
2202017-12-13T09:57:35  <wumpus> and still it helps some people
2212017-12-13T09:57:47  <Provoostenator> I think requiring review of translated strings would be a good improvement.
2222017-12-13T09:57:57  *** DrFeelGood has joined #bitcoin-core-dev
2232017-12-13T09:58:02  <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
2242017-12-13T09:58:14  <wumpus> by whom?
2252017-12-13T09:58:30  <Provoostenator> Not always, because if you google a word like "snoei" you won't find help in any language.
2262017-12-13T09:59:24  <wumpus> well it literally translates to prune
2272017-12-13T09:59:34  <Provoostenator> Same as with pull requests; anyone can review translations, don't merge unless it has enough review.
2282017-12-13T09:59:56  <wumpus> so does transifex have a process for that?
2292017-12-13T10:00:05  *** owowo has quit IRC
2302017-12-13T10:00:05  <wumpus> I know you can make teams etc
2312017-12-13T10:00:19  <wumpus> and that messages can be flagged as 'reviewed'
2322017-12-13T10:00:25  <Provoostenator> Yes, when you download the strings, you can select that you only want reviewed strings.
2332017-12-13T10:00:30  <Provoostenator> At least in the UI.
2342017-12-13T10:00:32  <wumpus> yes, but what does that mean?
2352017-12-13T10:00:38  <wumpus> who clicked 'reviewed' in that case?
2362017-12-13T10:00:45  <Provoostenator> That part I'm still figuring out
2372017-12-13T10:00:54  <Provoostenator> Transifex is broken for me, I can't see some of the pages.
2382017-12-13T10:00:56  <wumpus> I guess that a language reviewr needs to be assigned for every language?
2392017-12-13T10:01:06  <wumpus> or review team
2402017-12-13T10:01:17  *** quantbot has quit IRC
2412017-12-13T10:01:19  <Provoostenator> Every language has a team, feel free to add me to Dutch.
2422017-12-13T10:01:27  <wumpus> I think German has a review team, from back when diapolo was a contributor
2432017-12-13T10:01:44  <wumpus> oh they can choose their own team?
2442017-12-13T10:01:51  <wumpus> I really have no clue :)
2452017-12-13T10:02:06  <Provoostenator> I think you (or whoever has admin rights over transifex) can invite people to language teams.
2462017-12-13T10:03:00  <wumpus> I'll see if I can add you for dutch
2472017-12-13T10:03:25  <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
2482017-12-13T10:03:35  <wumpus> but I can't coordinate this for every language
2492017-12-13T10:03:36  <Provoostenator> (3) could be less drastic :-)
2502017-12-13T10:04:19  <Provoostenator> So maybe we need a github issue for a translation coordinator?
2512017-12-13T10:05:06  <Provoostenator> Sounds like a good role for a non-technical person who wants to help out.
2522017-12-13T10:06:39  <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
2532017-12-13T10:08:03  <Provoostenator> I'll try to make an org for myself and see if I can figure out the UX.
2542017-12-13T10:09:16  *** Victorsueca has quit IRC
2552017-12-13T10:09:33  <wumpus> https://docs.transifex.com/teams/managing-and-removing-collaborators  I don't see any "Teams" tab
2562017-12-13T10:10:01  <Provoostenator> I've used half a dozen translation services in the past and they all have serious issues.
2572017-12-13T10:10:07  <wumpus> might be that I don't have the required permissions
2582017-12-13T10:10:28  <Provoostenator> Yeah, I was assuming you were the admin.
2592017-12-13T10:10:35  *** Victorsueca has joined #bitcoin-core-dev
2602017-12-13T10:10:36  <Provoostenator> Maybe Satoshi is? :-)
2612017-12-13T10:10:39  <wumpus> I'm "project maintainer"
2622017-12-13T10:10:55  <wumpus> seone, apparently
2632017-12-13T10:11:08  <wumpus> haven't seen them in a long time...
2642017-12-13T10:12:26  <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
2652017-12-13T10:13:50  <Provoostenator> Projects are not the top lovel.
2662017-12-13T10:14:07  <Provoostenator> Organization is
2672017-12-13T10:14:11  <wumpus> ok
2682017-12-13T10:15:07  *** Emcy_ has joined #bitcoin-core-dev
2692017-12-13T10:15:19  <Provoostenator> If you click on the dropdown next to Bitcoin at the top, you shoudl see Organization Settings.
2702017-12-13T10:15:38  <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)
2712017-12-13T10:15:53  <wumpus> https://www.transifex.com/bitcoin/public/   I can only access the public page, ok that's explained then
2722017-12-13T10:16:08  <Provoostenator> Yes, and I can add administrators, which is probably what you are.
2732017-12-13T10:17:59  <Provoostenator> There's also "Maintainers". So maybe you can be promoted to admin.
2742017-12-13T10:18:05  *** Emcy has quit IRC
2752017-12-13T10:18:31  <Provoostenator> SAAS Kafka
2762017-12-13T10:18:39  <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.
2772017-12-13T10:18:59  <wumpus> Provoostenator: trying to find contact info for them. At least the irc account mentioned hasn't logged on for 7 weeks. Yes indeed :(
2782017-12-13T10:19:42  <Provoostenator> gmaxwell: doesn't he have an ICO to work on?
2792017-12-13T10:22:56  <wumpus> gmaxwell: I don't think there's a way to get rid of that denomination even if you'd want to
2802017-12-13T10:23:24  <wumpus> once someone is a bitcoin core developer you'll never leave, so beware :)
2812017-12-13T10:23:35  <meshcollider> gmaxwell: here you go ;) https://twitter.com/MeshCollider/status/940889701640060928
2822017-12-13T10:24:09  <wumpus> the only solution is to call everyone bitcoin core developer that contributed one patch, or heck even a translation message
2832017-12-13T10:24:33  <meshcollider> yes all users on transifex are core developers too :)
2842017-12-13T10:24:43  <wumpus> yup!
2852017-12-13T10:25:05  <wumpus> in that regard I've been trying to get credit info from the API (for the release notes) but haven't been succesful
2862017-12-13T10:25:05  <Provoostenator> Yes, which would include the bitcoin diamonds(?) person whose gitian signature was recently added to a PR.
2872017-12-13T10:25:15  <gmaxwell> Nah, they media does this when people use it to promote themselves or at least don't say don't do that.
2882017-12-13T10:26:53  <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.
2892017-12-13T10:29:06  <Provoostenator> Ah, that's where they get their "sizable reserve to stabilize its price relative to fiat currencies"
2902017-12-13T10:30:07  <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
2912017-12-13T10:30:20  <gmaxwell> (moved in the last 30 days before their fork, and their domain was only registered <12 days before the fork...)
2922017-12-13T10:30:32  <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.
2932017-12-13T10:31:15  <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.
2942017-12-13T10:31:40  <wumpus> right, just yet another fork, at some point people will start ignoring them like they do for new altcoins and icos
2952017-12-13T10:32:04  <Provoostenator> There will probalby be plenty of malware too, maybe even in the reference client.
2962017-12-13T10:32:35  <wumpus> yep, also waiting for the first fork with malware in their reference client, it has been done with altcoins
2972017-12-13T10:33:33  <Provoostenator> Let's see if they get it right "at block height: #498,777"
2982017-12-13T10:33:35  <gribble> https://github.com/bitcoin/bitcoin/issues/498 | Edited README.md via GitHub by paraipan · Pull Request #498 · bitcoin/bitcoin · GitHub
2992017-12-13T10:35:26  <wumpus> garzik is pretty just wasting everyones time
3002017-12-13T10:35:34  <wumpus> +much
3012017-12-13T10:35:35  <Provoostenator> On the bright side, some of these airdrop developers might end up contributing to Core in the long term.
3022017-12-13T10:36:08  <wumpus> at some point his reputation will go down enough he can't keep pulling these stunts off anymore
3032017-12-13T10:36:24  <Provoostenator> Whaha, you'd be surprised.
3042017-12-13T10:36:50  <Provoostenator> I can point you to some biographies...
3052017-12-13T10:37:17  <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
3062017-12-13T10:37:36  <Provoostenator> Not always, not if they're hired developers.
3072017-12-13T10:37:58  <Provoostenator> Then it's just their boss telling them to work on X, which they might feel reluctant about.
3082017-12-13T10:41:25  <gmaxwell> Provoostenator: someone once said that about altcoins in 2011... so far it seems almost none have done so.
3092017-12-13T10:42:02  *** Lauda has quit IRC
3102017-12-13T10:42:32  *** Lauda has joined #bitcoin-core-dev
3112017-12-13T10:42:42  <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.
3122017-12-13T10:43:26  <fanquake> The altcoins were run in bitcointalk threads. And eventually "generators" just churned them out.
3132017-12-13T10:44:19  <Provoostenator> They have 12 devs: http://www.ub.com/about/team
3142017-12-13T10:47:27  <meshcollider> at least their website looks nice ;)
3152017-12-13T10:48:03  <wumpus> usually in the cryptocurrency space, the nicer the website looks the scammier something is
3162017-12-13T10:48:26  <meshcollider> yep they spend more time on the website appearance than on the actual coin
3172017-12-13T10:50:24  *** Lauda has quit IRC
3182017-12-13T10:50:25  *** Ylbam has joined #bitcoin-core-dev
3192017-12-13T10:51:05  *** Lauda has joined #bitcoin-core-dev
3202017-12-13T10:51:21  <Provoostenator> No checksums on the download page. Source code is offered as a zip file, so good luck reviewing that...
3212017-12-13T10:51:49  <Provoostenator> (oh no, they do have a Github repo as well)
3222017-12-13T10:52:29  <meshcollider> only as of a week ago according to their roadmap lol
3232017-12-13T10:54:15  <Provoostenator> The commit messages and user names are entertaining.
3242017-12-13T10:54:58  <meshcollider> BUG FIXED
3252017-12-13T10:55:26  <Provoostenator> They branched away from Core master on November 30
3262017-12-13T10:56:24  <Provoostenator> This should be the full div: https://github.com/UnitedBitcoin/UnitedBitcoin/compare/60d739e...v1.0.3
3272017-12-13T10:56:51  *** quantbot has joined #bitcoin-core-dev
3282017-12-13T11:09:06  <Provoostenator> My favorite comment so far: "UnionBitcoin god mode block generator" (anyway, off topic I guess, unless there's a zero-day?)
3292017-12-13T11:11:07  <gmaxwell> Provoostenator: in 2011 no, but ripple...
3302017-12-13T11:12:28  *** quantbot has quit IRC
3312017-12-13T11:13:56  <Provoostenator> Does Ripple have any code overlap with Core that would make it easy for their devs to help out here?
3322017-12-13T11:14:47  <wumpus> I don't think they have any code overlap
3332017-12-13T11:16:39  <meshcollider> certainly doesn't look like they do, from a quick browse at their repo
3342017-12-13T11:18:16  *** tattoovicious has quit IRC
3352017-12-13T11:18:39  *** promag has quit IRC
3362017-12-13T11:19:53  <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.
3372017-12-13T11:21:22  <Provoostenator> I created #bitcoin-airdrop-code-shenanigans if anyone is interested. Not sure how to log it.
3382017-12-13T11:27:47  *** quantbot has joined #bitcoin-core-dev
3392017-12-13T11:32:15  *** quantbot has quit IRC
3402017-12-13T11:36:32  *** tattoovicious has joined #bitcoin-core-dev
3412017-12-13T11:39:26  *** fronti has quit IRC
3422017-12-13T11:49:25  *** go1111111 has quit IRC
3432017-12-13T11:51:55  *** promag has joined #bitcoin-core-dev
3442017-12-13T11:52:58  *** fronti has joined #bitcoin-core-dev
3452017-12-13T11:55:17  *** dabura667 has quit IRC
3462017-12-13T12:02:08  *** StopAndDecrypt_ has quit IRC
3472017-12-13T12:03:08  *** StopAndDecrypt has joined #bitcoin-core-dev
3482017-12-13T12:03:08  *** StopAndDecrypt has quit IRC
3492017-12-13T12:03:08  *** StopAndDecrypt has joined #bitcoin-core-dev
3502017-12-13T12:08:57  *** blackbaba has joined #bitcoin-core-dev
3512017-12-13T12:09:59  <cluelessperson> question, which flag indicates an RBF transaction?
3522017-12-13T12:10:08  <mryandao> nsequence
3532017-12-13T12:10:51  <cluelessperson> < some maximum?
3542017-12-13T12:11:11  <meshcollider> cluelessperson: yep RBF if any sequence value is less than 0xffffffff - 1
3552017-12-13T12:11:38  <cluelessperson> oh that's easy
3562017-12-13T12:11:43  <cluelessperson> I overlooked it in my code
3572017-12-13T12:11:46  * cluelessperson makes a comment
3582017-12-13T12:13:32  <cluelessperson> wait
3592017-12-13T12:13:45  <cluelessperson> my previous code looks at nsequence in all of the inputs
3602017-12-13T12:13:49  <cluelessperson> is that right?
3612017-12-13T12:14:09  <cluelessperson> should be nSequence of the current transaction, not inputs, right?
3622017-12-13T12:20:04  *** StopAndDecrypt_ has joined #bitcoin-core-dev
3632017-12-13T12:20:05  *** StopAndDecrypt has quit IRC
3642017-12-13T12:20:16  <aj> cluelessperson: depends on if the inputs have confirmed already
3652017-12-13T12:20:34  <cluelessperson> aj: What depends?
3662017-12-13T12:21:10  <aj> cluelessperson: RBF inherits; if the ancestors have nSeq signalling RBF, current tx is RBF too
3672017-12-13T12:22:15  <aj> cluelessperson: (provided the ancestors haven't confirmed yet)
3682017-12-13T12:22:23  <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
3692017-12-13T12:22:45  <meshcollider> that is different from looking back at the parent being spend
3702017-12-13T12:22:48  <meshcollider> spent*
3712017-12-13T12:23:03  <meshcollider> but yes aj is right, RBF also inherits
3722017-12-13T12:24:10  *** blackbaba has quit IRC
3732017-12-13T12:26:06  <cluelessperson> I see
3742017-12-13T12:26:46  <cluelessperson> for txin in tx.vin: if txin.nSequence < 0xfffffffe: return True
3752017-12-13T12:27:58  *** promag has quit IRC
3762017-12-13T12:29:03  <meshcollider> yes that sounds right
3772017-12-13T12:29:17  <meshcollider> its detailed in BIP 125 btw
3782017-12-13T12:34:07  *** m8tion has joined #bitcoin-core-dev
3792017-12-13T12:35:31  *** tattoovicious has quit IRC
3802017-12-13T12:37:20  *** Aaronvan_ has quit IRC
3812017-12-13T12:37:54  *** AaronvanW has joined #bitcoin-core-dev
3822017-12-13T12:43:44  *** StopAndDecrypt_ has quit IRC
3832017-12-13T12:44:18  *** StopAndDecrypt has joined #bitcoin-core-dev
3842017-12-13T12:44:18  *** StopAndDecrypt has quit IRC
3852017-12-13T12:44:18  *** StopAndDecrypt has joined #bitcoin-core-dev
3862017-12-13T12:48:03  *** kabaum_ has joined #bitcoin-core-dev
3872017-12-13T12:54:33  *** bityogi has joined #bitcoin-core-dev
3882017-12-13T12:55:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3892017-12-13T12:58:18  *** fanquake has quit IRC
3902017-12-13T12:59:23  *** cyber55 has quit IRC
3912017-12-13T13:01:50  *** alfa has joined #bitcoin-core-dev
3922017-12-13T13:02:18  *** Victorsueca has quit IRC
3932017-12-13T13:03:35  *** Victorsueca has joined #bitcoin-core-dev
3942017-12-13T13:06:11  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ba2f19504c6b...68e021e3a35d
3952017-12-13T13:06:11  <bitcoin-git> bitcoin/master fbf327b Aaron Clauson: Minimal code changes to allow msvc compilation.
3962017-12-13T13:06:12  <bitcoin-git> bitcoin/master 68e021e Wladimir J. van der Laan: Merge #11558: Minimal code changes to allow msvc compilation...
3972017-12-13T13:12:41  *** Chris_Stewart_5 has quit IRC
3982017-12-13T13:17:14  *** goatpig has joined #bitcoin-core-dev
3992017-12-13T13:21:05  *** DeadCode has joined #bitcoin-core-dev
4002017-12-13T13:21:19  <DeadCode> hello world
4012017-12-13T13:22:44  <DeadCode> I would like to ask some questions to jonasschnelli but he seems offline, anyone would like to help regarding libbtc implementation, please?
4022017-12-13T13:27:05  *** archaeal has quit IRC
4032017-12-13T13:35:52  *** lnostdal has quit IRC
4042017-12-13T13:36:25  *** StopAndDecrypt has quit IRC
4052017-12-13T13:36:31  *** StopAndDecrypt_ has joined #bitcoin-core-dev
4062017-12-13T13:38:14  *** Deacydal has joined #bitcoin-core-dev
4072017-12-13T13:38:38  *** nullptr| has quit IRC
4082017-12-13T13:41:50  *** Deacyde has quit IRC
4092017-12-13T13:46:15  *** lnostdal has joined #bitcoin-core-dev
4102017-12-13T13:50:58  *** archaeal has joined #bitcoin-core-dev
4112017-12-13T14:04:13  *** DeadCode has quit IRC
4122017-12-13T14:07:59  *** quantbot has joined #bitcoin-core-dev
4132017-12-13T14:12:09  *** Victorsueca has quit IRC
4142017-12-13T14:13:26  *** mrfrasha has joined #bitcoin-core-dev
4152017-12-13T14:14:03  *** Victorsueca has joined #bitcoin-core-dev
4162017-12-13T14:14:58  *** nullptr| has joined #bitcoin-core-dev
4172017-12-13T14:19:31  *** quantbot has quit IRC
4182017-12-13T14:19:32  *** SopaXorzTaker has quit IRC
4192017-12-13T14:19:58  *** quantbot has joined #bitcoin-core-dev
4202017-12-13T14:20:13  *** SopaXorzTaker has joined #bitcoin-core-dev
4212017-12-13T14:20:44  *** arubi_ has joined #bitcoin-core-dev
4222017-12-13T14:21:21  *** promag has joined #bitcoin-core-dev
4232017-12-13T14:23:08  *** arubi has quit IRC
4242017-12-13T14:23:57  *** quantbot has quit IRC
4252017-12-13T14:24:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4262017-12-13T14:32:47  *** Guyver2 has joined #bitcoin-core-dev
4272017-12-13T14:33:23  *** SopaXorzTaker has quit IRC
4282017-12-13T14:33:34  *** Ylbam has quit IRC
4292017-12-13T14:34:52  *** SopaXorzTaker has joined #bitcoin-core-dev
4302017-12-13T14:38:09  *** harrymm has joined #bitcoin-core-dev
4312017-12-13T14:39:21  *** tiagotrs has quit IRC
4322017-12-13T14:45:21  *** quantbot has joined #bitcoin-core-dev
4332017-12-13T14:46:28  *** SopaXT has joined #bitcoin-core-dev
4342017-12-13T14:46:35  *** SopaXorzTaker has quit IRC
4352017-12-13T14:49:36  *** quantbot has quit IRC
4362017-12-13T14:50:14  *** quantbot has joined #bitcoin-core-dev
4372017-12-13T14:52:10  <promag> MarcoFalke: ping
4382017-12-13T14:52:24  *** mrfrasha_ has joined #bitcoin-core-dev
4392017-12-13T14:52:26  *** mrfrasha has quit IRC
4402017-12-13T14:53:01  *** quantbot has quit IRC
4412017-12-13T14:53:28  *** quantbot has joined #bitcoin-core-dev
4422017-12-13T14:53:53  <promag> wumpus: int64_t GetArg returns 0 if conversion fails
4432017-12-13T14:54:54  <promag> should it return default value? should it throw or signal some *bool?
4442017-12-13T14:54:58  <wumpus> I guess that has always been the case?
4452017-12-13T14:55:33  <promag> we have ParseInt64 that indicates success or not
4462017-12-13T14:55:37  <wumpus> no, if that's changed, I'd say make it use ParseInt64 instead of atoi and raise an actual error
4472017-12-13T14:55:39  <wumpus> yes
4482017-12-13T14:56:36  <promag> for instance, -prune=foo
4492017-12-13T14:56:48  <promag> atm it's the same as -prune=0
4502017-12-13T14:57:01  <wumpus> it should throw an error and exit imo
4512017-12-13T14:57:12  <promag> my opinion also
4522017-12-13T14:57:21  <wumpus> using the default value when parsing fails isn't better
4532017-12-13T14:57:27  <promag> right
4542017-12-13T14:57:40  <promag> it's bad configuration
4552017-12-13T14:57:51  <promag> should be fixed
4562017-12-13T14:57:57  *** quantbot has quit IRC
4572017-12-13T15:00:15  <promag> the problem is that dealing with failed conversion will make the code ugly throughout, GetArg is used everywhere
4582017-12-13T15:03:28  <wumpus> yeah...
4592017-12-13T15:03:52  <wumpus> that's kind of the annoying thing about the current argument parsing code
4602017-12-13T15:03:57  <wumpus> that it's called from everywhere, not just init
4612017-12-13T15:04:33  <wumpus> also why I didn't fix this before, I did know of that use of atoi when I introduced ParseInt64
4622017-12-13T15:05:02  <wumpus> seems it's something better left for when there's more structured argument parsing
4632017-12-13T15:11:30  <promag> ok
4642017-12-13T15:16:57  *** quantbot has joined #bitcoin-core-dev
4652017-12-13T15:18:49  <promag> Is this comment still valid https://github.com/bitcoin/bitcoin/blob/68e021e3a35d1e88d6075ea8b05a8e3a40a64e29/src/wallet/wallet.cpp#L4125-L4129 ?
4662017-12-13T15:20:18  <promag> Reading #10286..
4672017-12-13T15:20:22  <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
4682017-12-13T15:28:09  *** Victorsueca has quit IRC
4692017-12-13T15:28:51  *** Amuza has joined #bitcoin-core-dev
4702017-12-13T15:29:37  *** Victorsueca has joined #bitcoin-core-dev
4712017-12-13T15:34:36  <promag> is validation.h the best place for LookupBlockIndex definition?
4722017-12-13T15:35:17  <promag> I guess so because extern BlockMap& mapBlockIndex; is in validation.h
4732017-12-13T15:38:04  <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
4742017-12-13T15:40:31  <promag> yes I thought of that too
4752017-12-13T15:40:50  <promag> https://github.com/bitcoin/bitcoin/pull/11041#issuecomment-349811860
4762017-12-13T15:41:11  <promag> but out of scope of 11041
4772017-12-13T15:42:37  <BlueMatt> yes, agreed
4782017-12-13T15:43:01  <BlueMatt> I just really want to get #10692 in, and #11041 should simplify it a bunch
4792017-12-13T15:43:03  <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
4802017-12-13T15:43:04  <gribble> https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
4812017-12-13T15:43:43  <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)
4822017-12-13T15:44:19  <promag> haven't compiled locally to verify the annotation LookupBlockIndex(const uint256& hash) EXCLUSIVE_LOCKS_REQUIRED(cs_main), waiting for travis
4832017-12-13T15:44:44  <BlueMatt> you just have to compile with CXX=clang++ ./configure --enable-werror
4842017-12-13T15:47:43  *** owowo has joined #bitcoin-core-dev
4852017-12-13T15:49:39  *** dabura667 has joined #bitcoin-core-dev
4862017-12-13T15:56:49  *** tattoovicious has joined #bitcoin-core-dev
4872017-12-13T16:07:15  *** pkx2 has joined #bitcoin-core-dev
4882017-12-13T16:08:24  <promag> IMO #11877 is ready
4892017-12-13T16:08:26  <gribble> https://github.com/bitcoin/bitcoin/issues/11877 | Improve createrawtransaction functional tests by promag · Pull Request #11877 · bitcoin/bitcoin · GitHub
4902017-12-13T16:09:35  <promag> jnewbery: +1 for comment
4912017-12-13T16:18:00  *** owowo has quit IRC
4922017-12-13T16:19:05  *** meshcollider has quit IRC
4932017-12-13T16:21:34  <bitcoin-git> [bitcoin] fridzema opened pull request #11885: Direct link to the freenode channel (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11885
4942017-12-13T16:22:16  *** owowo has joined #bitcoin-core-dev
4952017-12-13T16:24:51  *** mitfree[m] has joined #bitcoin-core-dev
4962017-12-13T16:25:20  *** Victorsueca has quit IRC
4972017-12-13T16:26:36  *** Victorsueca has joined #bitcoin-core-dev
4982017-12-13T16:33:19  *** SopaXT has quit IRC
4992017-12-13T16:33:51  *** LeMiner has quit IRC
5002017-12-13T16:33:58  *** SopaXorzTaker has joined #bitcoin-core-dev
5012017-12-13T16:34:35  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/68e021e3a35d...d4991c0cbb8a
5022017-12-13T16:34:36  <bitcoin-git> bitcoin/master 320669a João Barbosa: rpc: Validate replaceable type in createrawtransaction
5032017-12-13T16:34:36  <bitcoin-git> bitcoin/master 27c6199 João Barbosa: test: Add multidict to support dictionary with duplicate key (laanwj)
5042017-12-13T16:34:37  <bitcoin-git> bitcoin/master 88af502 João Barbosa: test: Add createrawtransaction functional tests
5052017-12-13T16:35:05  <bitcoin-git> [bitcoin] laanwj closed pull request #11877: Improve createrawtransaction functional tests (master...2017-12-createrawtransaction) https://github.com/bitcoin/bitcoin/pull/11877
5062017-12-13T16:35:50  *** dabura667 has quit IRC
5072017-12-13T16:41:28  *** tattoovicious has quit IRC
5082017-12-13T16:41:38  <bitcoin-git> [bitcoin] jimhashhq reopened pull request #10922: New file-partition.md doc describing how to partition files to ensure fast initial blockchain synchronization.. (master...master) https://github.com/bitcoin/bitcoin/pull/10922
5092017-12-13T16:47:10  *** goatpig has quit IRC
5102017-12-13T16:50:09  *** Randolf has quit IRC
5112017-12-13T16:51:39  *** Murch has joined #bitcoin-core-dev
5122017-12-13T16:51:57  <bitcoin-git> [bitcoin] practicalswift closed pull request #11734: rpc: Work around Clang thread safety analysis quirks (master...clang-thread-safety-quirks) https://github.com/bitcoin/bitcoin/pull/11734
5132017-12-13T16:53:01  *** mitfree[m] has left #bitcoin-core-dev
5142017-12-13T16:54:03  *** ThemoonMoth has joined #bitcoin-core-dev
5152017-12-13T16:54:33  <ThemoonMoth> Thoughts about the upcoming FCC vote?
5162017-12-13T16:54:56  <ThemoonMoth> And it's effect on bitcoin development in the US
5172017-12-13T16:55:29  <kanzure> wrong channel
5182017-12-13T16:55:59  <ThemoonMoth> the appropriate one would be...?
5192017-12-13T17:00:37  *** jb55 has joined #bitcoin-core-dev
5202017-12-13T17:01:03  <BlueMatt> #bitcoin
5212017-12-13T17:01:37  *** Emcy has joined #bitcoin-core-dev
5222017-12-13T17:01:53  *** Emcy_ has quit IRC
5232017-12-13T17:02:52  *** jtimon has joined #bitcoin-core-dev
5242017-12-13T17:05:36  *** Kozuch has quit IRC
5252017-12-13T17:06:00  <BlueMatt> can remove 11363 from https://github.com/bitcoin/bitcoin/projects/8 =D
5262017-12-13T17:06:32  *** rever5e has joined #bitcoin-core-dev
5272017-12-13T17:07:19  <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?
5282017-12-13T17:07:39  *** rafalcpp has joined #bitcoin-core-dev
5292017-12-13T17:07:53  *** Randolf has joined #bitcoin-core-dev
5302017-12-13T17:08:01  <rever5e> Unfortunately not savvy enough to contribute to main repo i'd just end up Garzik'ing it
5312017-12-13T17:09:09  <wumpus> rever5e: you could help with documentation, or translations
5322017-12-13T17:10:02  <rever5e> wumpus: How?
5332017-12-13T17:10:57  <wumpus> documentation is mainly in https://github.com/bitcoin/bitcoin/tree/master/doc, translations on transifex https://www.transifex.com/bitcoin/bitcoin/
5342017-12-13T17:10:58  *** ThemoonMoth has quit IRC
5352017-12-13T17:14:25  *** rever5e has quit IRC
5362017-12-13T17:16:23  *** Amuza has quit IRC
5372017-12-13T17:23:49  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11886: Clarify getbalance meaning a tiny bit in response to questions. (master...2017-12-getbalance-docs) https://github.com/bitcoin/bitcoin/pull/11886
5382017-12-13T17:25:01  *** SopaXorzTaker has quit IRC
5392017-12-13T17:25:15  <bitcoin-git> [bitcoin] laanwj closed pull request #11885: Direct link to the freenode channel (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11885
5402017-12-13T17:27:14  *** Kozuch has joined #bitcoin-core-dev
5412017-12-13T17:29:37  *** SopaXorzTaker has joined #bitcoin-core-dev
5422017-12-13T17:34:00  *** Murch has quit IRC
5432017-12-13T17:41:30  *** alfa has quit IRC
5442017-12-13T17:43:33  *** Kozuch has quit IRC
5452017-12-13T17:44:40  *** Murch has joined #bitcoin-core-dev
5462017-12-13T17:47:36  *** Dizzle has joined #bitcoin-core-dev
5472017-12-13T17:59:15  *** alreadylate has quit IRC
5482017-12-13T17:59:27  *** timothy has quit IRC
5492017-12-13T18:06:31  *** arubi_ is now known as arubi
5502017-12-13T18:11:24  *** laurentmt has quit IRC
5512017-12-13T18:13:16  *** Victorsueca has quit IRC
5522017-12-13T18:15:03  *** Victorsueca has joined #bitcoin-core-dev
5532017-12-13T18:17:02  <cluelessperson> Bitcoin Core's  "estimatefee" and "estimatesmartfee", what is the unit they're using?
5542017-12-13T18:17:10  <cluelessperson> 0.00356757
5552017-12-13T18:17:21  <cluelessperson> I think it's mbtc/kb?
5562017-12-13T18:17:45  <arubi> it's always been btc/kb
5572017-12-13T18:17:59  <arubi> maybe changed recently?  that would be breaking for .confs
5582017-12-13T18:18:11  <arubi> *so I don't think it's changed :)
5592017-12-13T18:19:03  <arubi> yep, says btc/kb
5602017-12-13T18:19:17  *** [b__b] has quit IRC
5612017-12-13T18:19:25  <wumpus> the help should show it, if not, it's a bug
5622017-12-13T18:19:35  *** [b__b] has joined #bitcoin-core-dev
5632017-12-13T18:19:38  <wumpus> (e.g. bitcoin-cli help estimatefee)
5642017-12-13T18:19:45  <arubi> it does, actually I didn't see we're on #-core-dev
5652017-12-13T18:20:24  <arubi> on smartfee it does say btc/kb.  estimatefee just says "fee-per-kb"
5662017-12-13T18:21:33  <wumpus> that could be clearer, though in general all amounts on the RPC interface are in BTC, never mbtc or mubtc
5672017-12-13T18:27:32  *** Ylbam has joined #bitcoin-core-dev
5682017-12-13T18:30:23  <achow101> estimatefee is deprecated anyways
5692017-12-13T18:31:41  <cluelessperson> help doesn't show it.
5702017-12-13T18:31:46  <cluelessperson> achow101: estimatesmartfee is good?
5712017-12-13T18:32:39  <sipa> yes
5722017-12-13T18:32:55  <achow101> yes
5732017-12-13T18:32:56  <sipa> estimatesmartfee orestimaterawfee
5742017-12-13T18:33:03  <achow101> estimatesmartfee replaces estimatefee
5752017-12-13T18:35:26  *** vicenteH has quit IRC
5762017-12-13T18:43:08  *** bityogi has quit IRC
5772017-12-13T18:46:37  *** eck has quit IRC
5782017-12-13T18:50:55  *** Chris_Stewart_5 has quit IRC
5792017-12-13T18:58:01  <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"
5802017-12-13T18:58:14  <jonasschnelli> Is that the same problem we have reported on the github issue tracker?
5812017-12-13T18:58:23  <jonasschnelli> Do you know why it was caused? swap?
5822017-12-13T19:05:54  <sipa> jonasschnelli: trying to figure that out now
5832017-12-13T19:08:01  *** sanada` has quit IRC
5842017-12-13T19:09:28  <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/
5852017-12-13T19:10:19  <GAit> when you say odroid do you mean hardkernel stuff?
5862017-12-13T19:10:27  <jonasschnelli> sipa: did anyone ever conceptually figured out if parts of the validation could be "outsourced" to GPU?
5872017-12-13T19:10:31  <jonasschnelli> (http://on-demand.gputechconf.com/gtc/2013/presentations/S3018-High-Performance-Cryptology-on-GPUs.pdf)
5882017-12-13T19:10:56  <jonasschnelli> GAit: yes. Hardkernel
5892017-12-13T19:11:22  <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.
5902017-12-13T19:11:35  <jonasschnelli> Also,... you don't pay for stuff you don't need (HDMI, 4USB, etc.)
5912017-12-13T19:12:15  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5922017-12-13T19:15:42  <gmaxwell> the gpu is useless, and otherwise it's just an arm a57 and wouldn't be faster than other a57s
5932017-12-13T19:18:24  <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.
5942017-12-13T19:19:05  <gmaxwell> well there have been gpu key generators, for example, that were a couple times faster than openssl, but significantly slower than libsecp256k1.
5952017-12-13T19:19:10  <wumpus> and as we already get a enough reports of errors due to overheating *CPUs*...
5962017-12-13T19:19:28  <gmaxwell> lack of 64,64->128 multiply is a big performance hit.
5972017-12-13T19:19:55  <wumpus> still, you could distribute over both the CPU and PGU
5982017-12-13T19:22:10  <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.
5992017-12-13T19:22:48  <gmaxwell> (and the man power required to write and maintain the software, and the requirement for propritary drivers, etc.)
6002017-12-13T19:23:14  *** Dizzle has quit IRC
6012017-12-13T19:24:04  <wumpus> yes
6022017-12-13T19:25:46  <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?
6032017-12-13T19:26:55  <wumpus> it's possible that it was removed since last update from transifex
6042017-12-13T19:27:45  <wumpus> but no, I can't add you to anything, I somehow don't have access to teams there
6052017-12-13T19:27:59  *** jb55 has quit IRC
6062017-12-13T19:28:11  <Provoostenator> But you were able to add me to nl_NL, or did I just social engineer Transifex staff?
6072017-12-13T19:28:48  *** ghost43 has quit IRC
6082017-12-13T19:28:52  <wumpus> no, I didn't add you to anything
6092017-12-13T19:30:26  <wumpus> I can only delete stuff apparentlly, transifex access controls make no sense
6102017-12-13T19:31:06  <wumpus> oh that's not true I can also create new translations, and sub-projects, just not teams
6112017-12-13T19:31:31  *** ghost43 has joined #bitcoin-core-dev
6122017-12-13T19:31:47  <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)
6132017-12-13T19:32:01  *** alreadylate has joined #bitcoin-core-dev
6142017-12-13T19:32:18  <wumpus> for the next major version I should probably create the transations in a new organization
6152017-12-13T19:33:25  <wumpus> $ find -name bitcoin_nl\* -> ./src/qt/locale/bitcoin_nl_NL.ts ./src/qt/locale/bitcoin_nl.ts
6162017-12-13T19:34:09  <Provoostenator> So that combines nl, nl_BE and nl_NL somehow?
6172017-12-13T19:34:40  <wumpus> no
6182017-12-13T19:34:49  <wumpus> that's literally nl_NL and nl, no nl_BE
6192017-12-13T19:35:03  <wumpus> it doesn't combine anything, it just copies the translation files
6202017-12-13T19:36:45  *** dcousens has quit IRC
6212017-12-13T19:36:49  *** jonas_ has joined #bitcoin-core-dev
6222017-12-13T19:37:01  *** dcousens has joined #bitcoin-core-dev
6232017-12-13T19:37:12  *** jonas_ is now known as Guest99398
6242017-12-13T19:37:24  <wumpus> nl_BE either falls below the threshold of 10 messages, or has been added since the last translations pull
6252017-12-13T19:37:48  *** Guest99398 has quit IRC
6262017-12-13T19:39:09  <Provoostenator> I'm reading the script now. Is it actually doing the downloading or do you do that manually?
6272017-12-13T19:39:23  <wumpus> yes, it does the downloading
6282017-12-13T19:39:34  <Provoostenator> update-translations.py? Where?
6292017-12-13T19:39:43  <wumpus> we talked about this before today?
6302017-12-13T19:40:00  <Provoostenator> I was referring to this: https://github.com/bitcoin/bitcoin/issues/11875#issuecomment-351331497
6312017-12-13T19:41:13  <Provoostenator> Ah wait, I see it now. TX is another command. I'll figure it out.
6322017-12-13T19:41:18  <wumpus> fetch_all_translations(), fetches the translations
6332017-12-13T19:41:55  *** dcousens has quit IRC
6342017-12-13T19:42:20  *** dcousens has joined #bitcoin-core-dev
6352017-12-13T19:43:39  *** m8tion01 has joined #bitcoin-core-dev
6362017-12-13T19:46:41  *** m8tion has quit IRC
6372017-12-13T19:50:48  *** jtimon has quit IRC
6382017-12-13T19:53:40  *** grio has joined #bitcoin-core-dev
6392017-12-13T19:54:21  *** dcousens has quit IRC
6402017-12-13T19:54:21  *** grio has quit IRC
6412017-12-13T19:54:26  *** bityogi has joined #bitcoin-core-dev
6422017-12-13T19:54:48  *** dcousens has joined #bitcoin-core-dev
6432017-12-13T19:54:49  *** grio has joined #bitcoin-core-dev
6442017-12-13T19:55:31  *** grio has quit IRC
6452017-12-13T19:56:00  *** grio has joined #bitcoin-core-dev
6462017-12-13T19:57:31  *** grio has joined #bitcoin-core-dev
6472017-12-13T19:58:45  *** grio has joined #bitcoin-core-dev
6482017-12-13T19:59:58  *** tiagotrs has joined #bitcoin-core-dev
6492017-12-13T19:59:59  *** tiagotrs has joined #bitcoin-core-dev
6502017-12-13T20:00:23  *** grio has quit IRC
6512017-12-13T20:00:55  *** grio has joined #bitcoin-core-dev
6522017-12-13T20:00:59  <jonasschnelli> Is there a way to detect if IsInitialBlockDownload() via RPC?
6532017-12-13T20:01:16  <jonasschnelli> nm: getblockchaininfo
6542017-12-13T20:01:34  *** grio has quit IRC
6552017-12-13T20:02:38  *** eck has joined #bitcoin-core-dev
6562017-12-13T20:04:13  *** jamesob has joined #bitcoin-core-dev
6572017-12-13T20:06:20  *** bsm117532 has joined #bitcoin-core-dev
6582017-12-13T20:07:33  *** Murch has quit IRC
6592017-12-13T20:13:34  <BlueMatt> #11888 should get an 0.16 tag
6602017-12-13T20:13:35  <gribble> https://github.com/bitcoin/bitcoin/issues/11888 | Prevent Opening Wallets Simultaneously in Two Instances · Issue #11888 · bitcoin/bitcoin · GitHub
6612017-12-13T20:17:47  <jonasschnelli> Tagged
6622017-12-13T20:19:04  *** jtimon has joined #bitcoin-core-dev
6632017-12-13T20:19:43  *** Murch has joined #bitcoin-core-dev
6642017-12-13T20:20:09  <bitcoin-git> [bitcoin] ryanofsky opened pull request #11889: Drop extra script variable in ProduceSignature (master...pr/dupvar) https://github.com/bitcoin/bitcoin/pull/11889
6652017-12-13T20:22:59  *** CubicEarth has joined #bitcoin-core-dev
6662017-12-13T20:24:40  *** alreadylate has quit IRC
6672017-12-13T20:27:49  <jonasschnelli> BlueMatt: re: https://github.com/bitcoin/bitcoin/pull/11281#pullrequestreview-82968766
6682017-12-13T20:27:58  <jonasschnelli> can you explain that a bit more for me?
6692017-12-13T20:28:25  *** PaulCapestany has quit IRC
6702017-12-13T20:28:42  <jonasschnelli> I think locking cs_main during the AddToWalletIfInvolvingMe() part would be removing most of the lock optimization done in this PR
6712017-12-13T20:28:52  *** bule has joined #bitcoin-core-dev
6722017-12-13T20:28:53  <BlueMatt> jonasschnelli: the !chainActive.Contains(pindex) check *must* be in the same cs_main lock as AddToWalletIfInvolvingMe
6732017-12-13T20:29:25  <jonasschnelli> BlueMatt: But AddToWalletIfInvolvingMe is currently (in the PR) done without cs_main
6742017-12-13T20:30:26  <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...
6752017-12-13T20:30:49  <jonasschnelli> *every
6762017-12-13T20:31:23  *** CubicEarth has quit IRC
6772017-12-13T20:31:30  *** alreadylate has joined #bitcoin-core-dev
6782017-12-13T20:32:01  *** CubicEarth has joined #bitcoin-core-dev
6792017-12-13T20:32:25  <jonasschnelli> I way expecting that we can do the two most significant time consumers (ReadBlockFromDisk, AddToWalletIfInvolvingMe) without cs_main
6802017-12-13T20:32:28  <BlueMatt> jonasschnelli: uhhhh well thats a second bug then
6812017-12-13T20:32:35  <BlueMatt> AddToWalletIfInvolvingMe requires cs_main
6822017-12-13T20:32:42  <BlueMatt> cause it can call AbandonTransaction
6832017-12-13T20:32:50  <BlueMatt> errrr, I meant MarkConflicted
6842017-12-13T20:33:12  <jonasschnelli> BlueMatt: ahh.. redudant deadlock
6852017-12-13T20:33:16  *** alreadylate has quit IRC
6862017-12-13T20:33:32  <jonasschnelli> seems my #11281 approach is a dead end
6872017-12-13T20:33:35  <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
6882017-12-13T20:33:40  <BlueMatt> no?
6892017-12-13T20:33:54  <BlueMatt> its still helpful to *unlock* cs_main after every block
6902017-12-13T20:34:02  <jonasschnelli> if we add AddToWalletIfInvolvingMe under cs_main two, alomst every code part will aquire the lock
6912017-12-13T20:34:07  <BlueMatt> so?
6922017-12-13T20:34:33  <BlueMatt> another thing you could do (which I thought you were going to) is push down the cs_main in the ReadBlockFromDisk
6932017-12-13T20:34:44  <jonasschnelli> BlueMatt: yes. I wanted to do this after the PR
6942017-12-13T20:34:45  <BlueMatt> then you take cs_main to get the diskpos out of CBlockIndex and then lose cs_main during the actual reading
6952017-12-13T20:34:58  <jonasschnelli> BlueMatt: yes
6962017-12-13T20:36:57  *** CubicEarth has quit IRC
6972017-12-13T20:37:31  *** alreadylate has joined #bitcoin-core-dev
6982017-12-13T20:38:16  *** SopaXorzTaker has quit IRC
6992017-12-13T20:41:16  *** alreadylate has quit IRC
7002017-12-13T20:43:36  *** lifeofguenter_ has quit IRC
7012017-12-13T20:43:36  *** BlueMatt has quit IRC
7022017-12-13T20:43:36  *** gijensen has quit IRC
7032017-12-13T20:43:36  *** zxzzt has quit IRC
7042017-12-13T20:43:36  *** sdaftuar has quit IRC
7052017-12-13T20:43:36  *** asoltys has quit IRC
7062017-12-13T20:43:36  *** AndyS2 has quit IRC
7072017-12-13T20:43:36  *** dlb76 has quit IRC
7082017-12-13T20:43:36  *** comboy has quit IRC
7092017-12-13T20:43:44  *** AndyS2 has joined #bitcoin-core-dev
7102017-12-13T20:43:45  *** comboy has joined #bitcoin-core-dev
7112017-12-13T20:43:45  *** gijensen has joined #bitcoin-core-dev
7122017-12-13T20:43:49  *** zxzzt has joined #bitcoin-core-dev
7132017-12-13T20:43:54  *** BlueMatt has joined #bitcoin-core-dev
7142017-12-13T20:43:54  *** BlueMatt has quit IRC
7152017-12-13T20:43:54  *** BlueMatt has joined #bitcoin-core-dev
7162017-12-13T20:43:57  *** tiagotrs has quit IRC
7172017-12-13T20:44:00  *** lifeofguenter has joined #bitcoin-core-dev
7182017-12-13T20:44:12  *** asoltys has joined #bitcoin-core-dev
7192017-12-13T20:44:12  *** sdaftuar has joined #bitcoin-core-dev
7202017-12-13T20:44:12  *** sdaftuar has joined #bitcoin-core-dev
7212017-12-13T20:45:57  *** paracyst_ has quit IRC
7222017-12-13T20:46:09  <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()
7232017-12-13T20:46:14  *** paracyst has joined #bitcoin-core-dev
7242017-12-13T20:46:38  *** dlb76 has joined #bitcoin-core-dev
7252017-12-13T20:48:07  *** bule has quit IRC
7262017-12-13T20:48:36  *** bule has joined #bitcoin-core-dev
7272017-12-13T20:51:19  <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.
7282017-12-13T20:51:41  <gmaxwell> like to decide if it knows about the block at all.
7292017-12-13T20:52:02  *** quantbot_ has joined #bitcoin-core-dev
7302017-12-13T20:53:20  *** quantbot has quit IRC
7312017-12-13T21:00:13  <BlueMatt> gmaxwell: I disagree 100%...
7322017-12-13T21:00:34  <BlueMatt> jonasschnelli: we already do, just push down the lock instead of taking it outside
7332017-12-13T21:01:06  *** m8tion01 has quit IRC
7342017-12-13T21:01:25  <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
7352017-12-13T21:01:35  <BlueMatt> no reason to require the caller take cs_main for the whole time if they dont want to
7362017-12-13T21:01:40  <BlueMatt> cs_main is recursive for a reason....
7372017-12-13T21:01:41  <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?
7382017-12-13T21:01:47  *** quantbot has joined #bitcoin-core-dev
7392017-12-13T21:02:21  <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
7402017-12-13T21:02:30  <BlueMatt> his whole goal is to reduce its usage in this case
7412017-12-13T21:02:45  <gmaxwell> sure, so look up the offset when you check if the block is in the index to begin with.
7422017-12-13T21:03:01  <BlueMatt> well in jonasschnelli's use-case above you cant do that...
7432017-12-13T21:03:09  <BlueMatt> you *must* do the check after reading, when processing
7442017-12-13T21:03:19  <gmaxwell> okay I didn't see the usecase then
7452017-12-13T21:03:22  *** gmaxwell has left #bitcoin-core-dev
7462017-12-13T21:03:23  *** quantbot_ has quit IRC
7472017-12-13T21:03:37  <BlueMatt> the race in AddToWalletIfInvolvingMe in the rescan stuff is subtle af
7482017-12-13T21:04:41  <jonasschnelli> BlueMatt: so acquiring cs_main in ReadBlockFromDisk() just for reading CDiskBlockPos blockPos;,... right?
7492017-12-13T21:04:57  <jonasschnelli> Doesn't it hurt to acquire it twice for the existing use cases of ReadBlockFromDisk()?
7502017-12-13T21:04:59  <BlueMatt> i think thats fine
7512017-12-13T21:05:02  <BlueMatt> indeed
7522017-12-13T21:05:07  <BlueMatt> its recursive
7532017-12-13T21:05:22  *** CubicEarth has joined #bitcoin-core-dev
7542017-12-13T21:07:32  *** alreadylate has joined #bitcoin-core-dev
7552017-12-13T21:09:01  *** jb55 has joined #bitcoin-core-dev
7562017-12-13T21:10:25  <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)?
7572017-12-13T21:10:32  *** agileDeveloper has joined #bitcoin-core-dev
7582017-12-13T21:10:33  *** CubicEarth has quit IRC
7592017-12-13T21:10:34  *** agileDeveloper has quit IRC
7602017-12-13T21:11:31  <jonasschnelli> jamesob: I think it would be worth... though ask BlueMatt, he is actually working on optimising concurrency
7612017-12-13T21:13:24  <jamesob> also, is there somewhere we're having an ongoing discussion about splitting cs_main into separate read & write locks?
7622017-12-13T21:13:52  *** CubicEarth has joined #bitcoin-core-dev
7632017-12-13T21:14:34  *** Kozuch has joined #bitcoin-core-dev
7642017-12-13T21:14:37  <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...
7652017-12-13T21:14:39  *** alreadylate has quit IRC
7662017-12-13T21:14:56  <jamesob> BlueMatt: yup, makes sense
7672017-12-13T21:15:04  <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
7682017-12-13T21:16:06  <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
7692017-12-13T21:16:08  *** vicenteH has joined #bitcoin-core-dev
7702017-12-13T21:16:11  <BlueMatt> same goes for other subsystems
7712017-12-13T21:16:44  <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
7722017-12-13T21:16:54  <BlueMatt> gonna be lots of corner cases either way, I'm sure
7732017-12-13T21:17:28  <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 :/
7742017-12-13T21:17:53  <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.
7752017-12-13T21:18:01  <BlueMatt> exactly
7762017-12-13T21:18:56  <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
7772017-12-13T21:18:57  *** CubicEarth has quit IRC
7782017-12-13T21:19:30  *** CubicEarth has joined #bitcoin-core-dev
7792017-12-13T21:19:35  <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
7802017-12-13T21:25:52  *** DrFeelGood has quit IRC
7812017-12-13T21:28:48  *** PaulCapestany has joined #bitcoin-core-dev
7822017-12-13T21:29:44  *** CubicEarth has quit IRC
7832017-12-13T21:31:05  <ossifrage> Did changing the wallet passphrase stop dumping the keypool in 0.15.x? I just changed the passphrase but keypoololdest is still old?
7842017-12-13T21:34:51  <BlueMatt> did it ever dump the keypool?
7852017-12-13T21:35:15  *** CubicEarth has joined #bitcoin-core-dev
7862017-12-13T21:35:40  *** saint_ has joined #bitcoin-core-dev
7872017-12-13T21:36:36  * BlueMatt sees no evidence that it did in 0.13.2
7882017-12-13T21:38:57  <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.
7892017-12-13T21:39:45  <BlueMatt> it does when you *first encrypt* (I'm 90% sure)
7902017-12-13T21:39:49  <BlueMatt> changing, I do not believe so
7912017-12-13T21:40:17  <ossifrage> Ah yeah, my wallet was unencrypted before that
7922017-12-13T21:41:21  *** Chris_Stewart_5 has quit IRC
7932017-12-13T21:41:28  <ossifrage> So I'm stuck calling getnewaddress 980 times :-(
7942017-12-13T21:41:45  <instagibbs> It should only throw away your master privkey on first encryption, yes
7952017-12-13T21:42:01  <instagibbs> I have not tested that sequence myself however
7962017-12-13T21:42:16  *** mrfrasha_ has quit IRC
7972017-12-13T21:42:34  <BlueMatt> ossifrage: heh, 980? thats not too bad...I had to do like 99k recently...that took a while
7982017-12-13T21:43:23  <ossifrage> I basically want to get an address that is not in my backups
7992017-12-13T21:43:33  *** PaulCapestany has quit IRC
8002017-12-13T21:47:02  <ossifrage> My poor 'receiving addresses list' is already painfully long as it is (mostly with discarded/unused addresses)
8012017-12-13T21:47:59  <BlueMatt> getrawchangeaddress intead, I think
8022017-12-13T21:48:40  <luke-jr> I thought it discarded keypool on change passphrase also
8032017-12-13T21:48:55  *** eck has quit IRC
8042017-12-13T21:49:08  <ossifrage> luke-jr, I changed the passphrase and keypoololdest is 109 days old
8052017-12-13T21:49:32  <ossifrage> which is about when I initially set the passphrase
8062017-12-13T21:49:51  <sipa> changing your passphrase doesn't change your masterkey, though
8072017-12-13T21:50:23  *** alreadylate has joined #bitcoin-core-dev
8082017-12-13T21:50:31  *** quantbot_ has joined #bitcoin-core-dev
8092017-12-13T21:50:45  <luke-jr> sipa: no?
8102017-12-13T21:52:01  <luke-jr> hmm
8112017-12-13T21:53:08  <luke-jr> is there a reason not to?
8122017-12-13T21:54:31  *** quantbot has quit IRC
8132017-12-13T21:54:32  <BlueMatt> yea..not having to re-encrypt everything
8142017-12-13T21:55:34  *** quantbot_ has quit IRC
8152017-12-13T21:56:05  <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.
8162017-12-13T21:56:06  <luke-jr> why would you need to reencrypt everything, just to add a new master key?
8172017-12-13T21:56:24  *** Murch has quit IRC
8182017-12-13T21:57:19  <BlueMatt> luke-jr: how in the hell would you do it otherwise?
8192017-12-13T21:57:29  *** Murch has joined #bitcoin-core-dev
8202017-12-13T21:57:42  <ossifrage> My goal was to invalidate my backup for new transactions without loosing the history/metadata
8212017-12-13T21:57:46  <luke-jr> BlueMatt: SetHDMasterKey(GenerateNewHDMasterKey())?
8222017-12-13T21:58:08  <sipa> luke-jr: the encryption master key, not the hd master key
8232017-12-13T21:58:11  <luke-jr> oh
8242017-12-13T21:58:13  <BlueMatt> luke-jr: we're not talking about HD master key
8252017-12-13T21:58:25  *** PaulCapestany has joined #bitcoin-core-dev
8262017-12-13T21:58:32  <ossifrage> In my case it is *not* a HD wallet (I think it predates the HD stuff)
8272017-12-13T21:58:33  <luke-jr> I was XD
8282017-12-13T21:58:54  <sipa> rotating out the hd master key is something we should support, but it can be orthogonal to the encryption question
8292017-12-13T21:59:06  <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
8302017-12-13T21:59:11  <BlueMatt> #11085
8312017-12-13T21:59:13  <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
8322017-12-13T21:59:34  <sipa> yah
8332017-12-13T22:00:00  <ossifrage> Is there a way to 'decrypt' the wallet so I can reencrypt it and dump the keypool?
8342017-12-13T22:00:41  <luke-jr> I don't think so
8352017-12-13T22:00:42  <BlueMatt> not atm
8362017-12-13T22:00:53  <BlueMatt> i mean you can also hack in your own rpc that empties keypool
8372017-12-13T22:00:56  <BlueMatt> in one db batch
8382017-12-13T22:00:59  <BlueMatt> which would make it faster
8392017-12-13T22:02:43  <ossifrage> The 'receiving address list' UI is already insanely long, adding another 960 entries will suck
8402017-12-13T22:05:00  <luke-jr> [21:48:00] <BlueMatt> getrawchangeaddress intead, I think
8412017-12-13T22:06:21  *** JackH has joined #bitcoin-core-dev
8422017-12-13T22:06:27  <ossifrage> luke-jr, yeah, that might work until I forget to do it
8432017-12-13T22:06:44  *** alreadylate has quit IRC
8442017-12-13T22:07:26  *** cryptapus has quit IRC
8452017-12-13T22:09:35  <ossifrage> getrawchangeaddress caused keypoolsize to go down by 1
8462017-12-13T22:09:38  *** cryptapus has joined #bitcoin-core-dev
8472017-12-13T22:09:39  *** cryptapus has joined #bitcoin-core-dev
8482017-12-13T22:09:39  *** Solrac has joined #bitcoin-core-dev
8492017-12-13T22:10:16  *** PaulCapestany has quit IRC
8502017-12-13T22:12:01  *** bule has quit IRC
8512017-12-13T22:12:30  *** bule has joined #bitcoin-core-dev
8522017-12-13T22:13:26  *** luke-jr has quit IRC
8532017-12-13T22:13:30  <ossifrage> and 'bitcoin-cli listreceivedbyaddress 0 true | jq .[].address | grep <getrawchangeaddress>' does not return the address
8542017-12-13T22:15:28  <sipa> by definition transaction outputs to a change address are not treated as incoming payments
8552017-12-13T22:16:01  *** PaulCapestany has joined #bitcoin-core-dev
8562017-12-13T22:16:27  <ossifrage> sipa, ok yeah... but the getrawchangeaddress comes from the keypool
8572017-12-13T22:16:34  *** luke-jr has joined #bitcoin-core-dev
8582017-12-13T22:17:27  <sipa> yes?
8592017-12-13T22:17:42  <sipa> i don't understand what you're expecting
8602017-12-13T22:17:52  *** LeMiner has joined #bitcoin-core-dev
8612017-12-13T22:18:32  <ossifrage> Ah, I understand now, use getrawchangeaddress 980 times to discard the old keys... duh
8622017-12-13T22:18:59  <sipa> it will only discard change keys
8632017-12-13T22:19:05  *** Solrac has quit IRC
8642017-12-13T22:19:12  *** Randolf has quit IRC
8652017-12-13T22:20:40  *** luke-jr has quit IRC
8662017-12-13T22:20:50  *** luke-jr has joined #bitcoin-core-dev
8672017-12-13T22:20:54  *** Kozuch has quit IRC
8682017-12-13T22:22:33  *** saint_ has quit IRC
8692017-12-13T22:24:09  *** tiagotrs has joined #bitcoin-core-dev
8702017-12-13T22:24:10  *** tiagotrs has joined #bitcoin-core-dev
8712017-12-13T22:33:28  *** ghost43 has quit IRC
8722017-12-13T22:33:36  *** eck has joined #bitcoin-core-dev
8732017-12-13T22:33:43  *** ghost43 has joined #bitcoin-core-dev
8742017-12-13T22:42:56  *** eck has quit IRC
8752017-12-13T22:44:00  *** shesek has quit IRC
8762017-12-13T22:44:25  *** eck has joined #bitcoin-core-dev
8772017-12-13T22:45:56  *** shesek has joined #bitcoin-core-dev
8782017-12-13T22:45:57  *** shesek has joined #bitcoin-core-dev
8792017-12-13T22:47:28  *** alreadylate has joined #bitcoin-core-dev
8802017-12-13T22:50:12  *** ghost43 has quit IRC
8812017-12-13T22:50:32  *** ghost43 has joined #bitcoin-core-dev
8822017-12-13T22:56:29  *** herzmeister[m] has quit IRC
8832017-12-13T22:57:37  *** herzmeister[m] has joined #bitcoin-core-dev
8842017-12-13T22:58:04  <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.
8852017-12-13T22:58:50  <ossifrage> Now both getrawchangeaddress and getnewaddress fail with "Error: Keypool ran out, please call keypoolrefill first" as expected
8862017-12-13T22:59:04  <luke-jr> that's convenient
8872017-12-13T23:00:15  <ossifrage> I wanted to invalidate my backups without loosing the history that goes back to 2011
8882017-12-13T23:01:14  <ossifrage> BlueMatt, thanks!
8892017-12-13T23:14:15  *** meshcollider has joined #bitcoin-core-dev
8902017-12-13T23:15:35  *** pkx2 has quit IRC
8912017-12-13T23:15:47  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #11892:  [Qt] Warn if fallback fee has been used (master...2017/12/qt_warn_fallbackfee) https://github.com/bitcoin/bitcoin/pull/11892
8922017-12-13T23:18:50  *** gmaxwell has joined #bitcoin-core-dev
8932017-12-13T23:19:09  <gmaxwell> We might actually be running low on sockets on the network, not critically so, but low none the less.
8942017-12-13T23:19:39  <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.
8952017-12-13T23:20:10  *** unholymachine has quit IRC
8962017-12-13T23:20:32  *** unholymachine has joined #bitcoin-core-dev
8972017-12-13T23:23:49  *** Guyver2 has quit IRC
8982017-12-13T23:25:11  *** ghost43 has quit IRC
8992017-12-13T23:25:59  *** ghost43 has joined #bitcoin-core-dev
9002017-12-13T23:28:38  *** laurentmt has joined #bitcoin-core-dev
9012017-12-13T23:30:03  *** Murch has quit IRC
9022017-12-13T23:31:10  *** laurentmt has quit IRC
9032017-12-13T23:35:30  *** Murch has joined #bitcoin-core-dev
9042017-12-13T23:38:02  *** bityogi has quit IRC
9052017-12-13T23:44:32  *** alreadylate has quit IRC
9062017-12-13T23:46:50  <jonasschnelli> gmaxwell: due to a lot of peers in IBD? Or plenty of SPV?
9072017-12-13T23:57:39  *** StopAndDecrypt_ has quit IRC
9082017-12-13T23:57:56  *** StopAndDecrypt has joined #bitcoin-core-dev
9092017-12-13T23:57:56  *** StopAndDecrypt has quit IRC
9102017-12-13T23:57:56  *** StopAndDecrypt has joined #bitcoin-core-dev
9112017-12-13T23:57:57  *** PaulCapestany has quit IRC