12018-07-19T00:07:31  *** BashCo has quit IRC
  22018-07-19T00:07:35  *** Dizzle has quit IRC
  32018-07-19T00:08:40  *** Krellan has quit IRC
  42018-07-19T00:09:29  *** Krellan has joined #bitcoin-core-dev
  52018-07-19T00:24:00  *** AaronvanW has joined #bitcoin-core-dev
  62018-07-19T00:27:08  *** BashCo has joined #bitcoin-core-dev
  72018-07-19T00:32:28  *** pinhead has quit IRC
  82018-07-19T00:41:27  *** dqx_ has quit IRC
  92018-07-19T00:42:28  *** Tennis has quit IRC
 102018-07-19T00:46:58  *** dqx_ has joined #bitcoin-core-dev
 112018-07-19T00:49:56  <bitcoin-git> [bitcoin] masonicboom opened pull request #13707: Tests: add usage note to check-rpc-mappings.py (master...add-usage-note-to-check-rpc-mappings) https://github.com/bitcoin/bitcoin/pull/13707
 122018-07-19T00:51:10  <bitcoin-git> [bitcoin] masonicboom closed pull request #13698: doc: Document contributing a scripted diff (master...scripted-diff-docs) https://github.com/bitcoin/bitcoin/pull/13698
 132018-07-19T00:52:47  *** dqx_ has quit IRC
 142018-07-19T00:56:06  *** dqx_ has joined #bitcoin-core-dev
 152018-07-19T01:01:52  *** AaronvanW has quit IRC
 162018-07-19T01:14:11  *** |EHG| has joined #bitcoin-core-dev
 172018-07-19T01:29:20  *** Urgo has quit IRC
 182018-07-19T01:32:46  *** Urgo has joined #bitcoin-core-dev
 192018-07-19T01:50:20  <bitcoin-git> [bitcoin] masonicboom opened pull request #13708: docs: Document lint tests (master...document-lint-tests) https://github.com/bitcoin/bitcoin/pull/13708
 202018-07-19T02:16:23  *** Krellan has quit IRC
 212018-07-19T02:16:47  *** grafcaps has quit IRC
 222018-07-19T02:17:09  *** Krellan has joined #bitcoin-core-dev
 232018-07-19T02:25:22  *** grafcaps has joined #bitcoin-core-dev
 242018-07-19T02:25:57  *** johnn2 has joined #bitcoin-core-dev
 252018-07-19T02:27:09  *** Urgo has quit IRC
 262018-07-19T02:27:20  *** bitconner has quit IRC
 272018-07-19T02:27:43  *** Urgo has joined #bitcoin-core-dev
 282018-07-19T02:28:49  *** radioops has quit IRC
 292018-07-19T02:29:59  *** grafcaps has quit IRC
 302018-07-19T02:36:03  *** farmerwampum has joined #bitcoin-core-dev
 312018-07-19T02:38:13  *** farmerwampum has quit IRC
 322018-07-19T02:38:33  *** farmerwampum has joined #bitcoin-core-dev
 332018-07-19T02:52:35  *** dqx_ has quit IRC
 342018-07-19T02:58:18  *** hendrik_ has joined #bitcoin-core-dev
 352018-07-19T03:01:30  *** xC0FFEE has quit IRC
 362018-07-19T03:13:21  *** bitconner has joined #bitcoin-core-dev
 372018-07-19T03:19:30  <gmaxwell> https://blog.bitmex.com/bitcoins-consensus-forks/ has anyone already pinged these folks and pointed out that stuff like the addition of NOPs was not a hardfork? (prior to that commit all unknown ops were nops)
 382018-07-19T03:37:32  *** nico_ has joined #bitcoin-core-dev
 392018-07-19T03:40:17  *** nico_ is now known as un1c0d3r
 402018-07-19T03:42:37  <luke-jr> gmaxwell: nope, but it might be good to correct https://en.bitcoin.it/wiki/Consensus_versions in that case (I guess it'd be a softfork instead?)
 412018-07-19T03:43:57  <gmaxwell> Yes.
 422018-07-19T03:44:30  <gmaxwell> re that page, really anything that wants to say that the system has hardforked previously ought to be explaining why the very first release can validatate past their claimed hardfork.
 432018-07-19T03:44:57  <gmaxwell> because the traditional definition of a hardfork (as used on that article) doesn't really allow for that.
 442018-07-19T03:45:12  <bitcoin-git> [bitcoin] GerardoTaboada opened pull request #13709: Update nodes_main.txt (master...patch-2) https://github.com/bitcoin/bitcoin/pull/13709
 452018-07-19T03:45:53  <gmaxwell> e.g. on the script split, there is a conjectural hardfork there that AFAIK no one is completely sure of.
 462018-07-19T03:46:12  <gmaxwell> And if it does exist, it's never actually been triggered.
 472018-07-19T03:46:27  <gmaxwell> So it would, if the conjecture holds, be better to call that a latent hardfork.
 482018-07-19T03:50:27  <bitcoin-git> [bitcoin] fanquake closed pull request #13709: Update nodes_main.txt (master...patch-2) https://github.com/bitcoin/bitcoin/pull/13709
 492018-07-19T03:52:42  *** meshcollider_ has joined #bitcoin-core-dev
 502018-07-19T03:52:57  *** un1c0d3r has quit IRC
 512018-07-19T03:54:16  <luke-jr> gmaxwell: most consensus rules are never triggered. that's immaterial to the change.
 522018-07-19T03:57:05  <gmaxwell> it's pretty material to the question of it being debatable if there was a hardfork or not!
 532018-07-19T03:57:26  <luke-jr> if the rules were relaxed, it was by definition a hardfork.
 542018-07-19T03:57:31  <gmaxwell> I mean we don't actually know if the script split was a hardfork because at most its a latent hardfork, no one has constructed a demonstration case.
 552018-07-19T03:57:44  <luke-jr> no demonstration case is needed
 562018-07-19T03:57:48  <gmaxwell> Sometimes it's really hard to tell if they were relaxed or not.
 572018-07-19T03:58:09  <luke-jr> which one are you referring to?
 582018-07-19T03:58:28  <gmaxwell> " I mean we don't actually know if the script split was a hardfork"
 592018-07-19T03:58:41  <luke-jr> oh, 0.3.7? I guess that's unclear.
 602018-07-19T03:58:49  <gmaxwell> for years we thought it wasn't then someone came up with a credible argument that it might have been.
 612018-07-19T03:59:12  <gmaxwell> But it's complicated enough that it probably won't be convincing without an example transaction.
 622018-07-19T03:59:21  <luke-jr> couldn't an OP_IF span the two scripts previously?
 632018-07-19T03:59:57  <luke-jr> hmm, can't think of a way to make that do invalid->valid, nm
 642018-07-19T04:00:03  <gmaxwell> I think the example required an invalid serialization whos bytes gobbled up the code seperator.
 652018-07-19T04:00:34  <gmaxwell> But AFAIK no one has ever tested it, and that might not work in the old code for some not immediately obvious reason.
 662018-07-19T04:01:14  <gmaxwell> e.g. you end the scriptsig with a multibyte push opcode and an invalid length on the script so when concatinated with the code sep the codesep becomes part of the push.
 672018-07-19T04:01:19  <gmaxwell> or something along those lines.
 682018-07-19T04:01:36  <luke-jr> right
 692018-07-19T04:01:56  <luke-jr> not sure it's worth the effort to prove either way, maybe it can just say "unclear"
 702018-07-19T04:02:22  <gmaxwell> in any case, when people talk about hardforks, they ususally believe it disrupted the network and split consensus, but a latent hardfork hasn't done that.
 712018-07-19T04:02:48  <gmaxwell> Which is why I think it would be useful to signal when they're latent or not and when (if ever) they materalized.
 722018-07-19T04:02:53  <luke-jr> only people who don't understand hardforks, since a real one wouldn't disrupt the network nor split consensus
 732018-07-19T04:03:04  <gmaxwell> luke-jr: yea, so only to 99.99999% of people on earth. :P
 742018-07-19T04:03:35  <luke-jr> most people don't have either a correct understanding NOR a misunderstanding ;)
 752018-07-19T04:04:00  <gmaxwell> So for example for the 2013 thing I'd say that it was a latent hardfork that became sensible in sept 2014 (or whenever old versions were actually reliably forked off).
 762018-07-19T04:04:18  <luke-jr> I'd say all hardforks are "latent"
 772018-07-19T04:04:43  <luke-jr> if the network splits, it would cease to be a hardfork, and become an altcoin like BCH instead
 782018-07-19T04:05:02  <gmaxwell> Even if the network hasn't split, the more permissiveness could have been used or not.
 792018-07-19T04:06:46  <gmaxwell> Imagine this, say the network rules change so that any coin with pubkey P could also be spent with pubkey P' = hash_to_point(P).  This is a hardfork, but unless ECC is broken it can never be anything but a latent hardfork.  It would be a dumb change for sure, but it wouldn't imply basically any of the risks of a hardfork.
 802018-07-19T04:07:30  <gmaxwell> in any case, for the list the NOP thing was just a softfork (AFAIK), I think a few other early softforks are missing.
 812018-07-19T04:08:48  <luke-jr> you want to fix it, or should I? ;)
 822018-07-19T04:09:07  <gmaxwell> The script split thing I'd describe as a "possible latent hardfork [1]"  "[1] The change wasn't believed to be a hardfork for years, but later some people conjectured some contrived transaction style which might be valid under the new rules but not the old, but it's complicated enough no one has bothered to check for sure, especially since any impacted software was long since no longer in use."
 832018-07-19T04:10:15  <luke-jr> actually, I'm not sure I see how the invalid script thing could be used to make something valid that was previously invalid.. seems the end result would be invalid after a split too
 842018-07-19T04:10:32  <luke-jr> because then you have a chopped opcode to execute
 852018-07-19T04:11:11  <gmaxwell> for the 2013 thing, it's a "hardfork kinda" because the old behavior was non-determinstic.  If you use your definition of a hardfork where a latent hardfork is a hardfork, then the 'time' of that hardfork was the initial release; since any given node could permit things others would forbid.
 862018-07-19T04:11:59  <luke-jr> afaik, the new rules after 2013 May permitted things that would never have been permitted previously, at least by any naturally functioning node
 872018-07-19T04:12:04  <gmaxwell> luke-jr: I dunno I'd have to find the discussion. I recall thinking that it was plausable.
 882018-07-19T04:12:35  <luke-jr> maybe kanzure remembers XD
 892018-07-19T04:13:20  <gmaxwell> luke-jr: I'm not _totally_ sure of that. I've synced as far as sept 2014 but the place where it fails was different between different runs.  Maybe if I tried millions of times it would make it up to current.
 902018-07-19T04:13:58  <luke-jr> gmaxwell: even if it did, you could still construct a block that is valid under the new rules that it would reject
 912018-07-19T04:14:24  <gmaxwell> in any case, a change in behavior from highly non-deterministic to slightly more permissive determnistic is not your 'typical' hardfork. :P  e.g. "do nothing" wasn't an option.
 922018-07-19T04:14:55  <gmaxwell> luke-jr: thats what I'm not sure of. I don't know if you actually can construct a block that the old code will _never_ accept, only that it's very unlikely to accept.
 932018-07-19T04:14:58  <luke-jr> the fix to the problem, in March, was to make the rules deterministically stricter ;)
 942018-07-19T04:15:26  <luke-jr> ie, semver 1.0.2 on the wiki page
 952018-07-19T04:15:31  <gmaxwell> luke-jr: I'm pretty confident that the temporary softfork wasn't actually enough to protect nodes from the non-determinism, FWIW.
 962018-07-19T04:15:47  <luke-jr> why not? wasn't it strictly more restrictive?
 972018-07-19T04:16:10  <gmaxwell> No, because the BDB behavior was more complicated than we understood at the time.
 982018-07-19T04:16:16  <luke-jr> >_<
 992018-07-19T04:17:06  <gmaxwell> I think, in fact, depending on what read activity was going on, it could have run out of locks for a block that only touched two txids (e.g. a single transaction).
1002018-07-19T04:17:17  <gmaxwell> at least in theory.
1012018-07-19T04:17:34  <luke-jr> you mean in the wallet bdb?
1022018-07-19T04:17:40  <luke-jr> or what else would cause reads going on?
1032018-07-19T04:17:51  <gmaxwell> indeed.
1042018-07-19T04:19:45  <luke-jr> well, the limits had to be strict enough that it could survive at least a minimal reorg, so I'd be surprised if the wallet could interfere too much in normal operation
1052018-07-19T04:20:42  <sipa> gmaxwell: addition of NOPs was at the same time as removal of VER
1062018-07-19T04:21:07  <gmaxwell> sipa: yes, and? removing ver was a softfork.
1072018-07-19T04:21:54  <gmaxwell> (I suppose luke should argue that every version _prior_ to that point was a hardfork, due to OP_VER. ...)
1082018-07-19T04:22:16  <gmaxwell> luke-jr: Another reason why latent vs non-latent hardforks matter: a latent one could still be softforked out.
1092018-07-19T04:22:36  <sipa> gmaxwell: script split was a trivial hardfork; the sighash effect of codesep changed
1102018-07-19T04:23:45  <gmaxwell> e.g. say you did come up with a transaction pattern that split off 0.3.0, but yet was never used in the network so far. That pattern could be softforked out and then the 'hardfork' is undone.
1112018-07-19T04:24:16  <luke-jr> gmaxwell: any hardfork can be softforked out.
1122018-07-19T04:24:39  <gmaxwell> luke-jr: not in a way that prevents older software from going out of consensus.
1132018-07-19T04:25:23  <luke-jr> ?
1142018-07-19T04:25:52  <sipa> gmaxwell: did you see my comment on sighash and codesep?
1152018-07-19T04:26:46  <gmaxwell> sipa: yes, so you're saying that any transaction with a codesep in the scriptpubkey that is valid now wouldn't have been valid pre-0.3.0 ?
1162018-07-19T04:27:37  *** baldur has quit IRC
1172018-07-19T04:27:43  <gmaxwell> (well codesep and a valid signature, of course)
1182018-07-19T04:27:44  <sipa> gmaxwell: yes
1192018-07-19T04:28:06  <sipa> a signature with a checksig in the scriotsig
1202018-07-19T04:28:19  <gmaxwell> now I'm wondering if the point I was unable to get 0.1.0 ultimately past was really a codesep use and not related to the locks thing at all.
1212018-07-19T04:28:25  <sipa> it may be impossible to construct a valid one like that now...
1222018-07-19T04:28:42  <sipa> maybe when using sighash_single bug
1232018-07-19T04:29:00  *** promag has joined #bitcoin-core-dev
1242018-07-19T04:29:31  <gmaxwell> it would certantly make more sense, since the block in question wasn't even especially large.
1252018-07-19T04:31:20  *** lontivero has quit IRC
1262018-07-19T04:33:19  <gmaxwell> luke-jr: in any case there is also a big difference between intentionally adding a hardfork and accidentally adding one in a crazy corner case when trying to fix a bug that let anyone spend any coin. :P
1272018-07-19T04:33:35  *** promag has quit IRC
1282018-07-19T04:34:02  <luke-jr> gmaxwell: depends on why you're classifying
1292018-07-19T04:35:36  <kallewoof> Not sure how useful to you guys but I made a small bash script that iterates through a range of commits in a git branch and makes sure they all compile: https://gist.github.com/kallewoof/10ce05193e738b42517b565a2f9b22e6
1302018-07-19T04:38:02  *** baldur has joined #bitcoin-core-dev
1312018-07-19T04:39:24  <luke-jr> git checkout $a; while [ $(git log --pretty=oneline $b^.. | wc -l) -gt 0 ]; do make || break; git checkout HEAD^; done ?
1322018-07-19T04:39:26  <luke-jr> :p
1332018-07-19T04:42:25  <luke-jr> sipa: so you're sure that *at the time*, the script split was a HF?
1342018-07-19T04:43:28  <sipa> luke-jr: i believe it was possible at the time to construct a scriptSig that was not valid before the removal, and valid after
1352018-07-19T04:43:36  <aj> "make || break" -- love it
1362018-07-19T05:12:43  *** grafcaps has joined #bitcoin-core-dev
1372018-07-19T05:15:17  <bitcoin-git> [bitcoin] ken2812221 opened pull request #13710: [depends] Add riscv qt depends support for cross compiling bitcoin-qt (master...qt-riscv) https://github.com/bitcoin/bitcoin/pull/13710
1382018-07-19T05:17:29  *** grafcaps has quit IRC
1392018-07-19T05:28:56  *** mariorz_ has joined #bitcoin-core-dev
1402018-07-19T05:29:07  *** mturquette_ has joined #bitcoin-core-dev
1412018-07-19T05:29:12  *** trotski2000 has quit IRC
1422018-07-19T05:29:12  *** pindarhk_ has quit IRC
1432018-07-19T05:29:12  *** CryptAxe has quit IRC
1442018-07-19T05:29:13  *** trotski2000 has joined #bitcoin-core-dev
1452018-07-19T05:29:22  *** pierre_rochard_ has joined #bitcoin-core-dev
1462018-07-19T05:29:23  *** meshcollider__ has joined #bitcoin-core-dev
1472018-07-19T05:29:50  *** rodarmor_ has joined #bitcoin-core-dev
1482018-07-19T05:29:51  *** epic has quit IRC
1492018-07-19T05:29:51  *** bosma has quit IRC
1502018-07-19T05:29:51  *** wbnns has quit IRC
1512018-07-19T05:29:51  *** mturquette has quit IRC
1522018-07-19T05:29:52  *** mturquette_ is now known as mturquette
1532018-07-19T05:29:55  *** mappum__ has joined #bitcoin-core-dev
1542018-07-19T05:30:26  *** bosma has joined #bitcoin-core-dev
1552018-07-19T05:30:26  *** epic has joined #bitcoin-core-dev
1562018-07-19T05:30:27  *** wbnns has joined #bitcoin-core-dev
1572018-07-19T05:30:30  *** mariorz has quit IRC
1582018-07-19T05:30:31  *** pindarhk_ has joined #bitcoin-core-dev
1592018-07-19T05:31:08  *** meshcollider_ has quit IRC
1602018-07-19T05:31:09  *** rodarmor has quit IRC
1612018-07-19T05:31:09  *** mappum_ has quit IRC
1622018-07-19T05:31:09  *** pierre_rochard has quit IRC
1632018-07-19T05:31:09  *** meshcollider__ is now known as meshcollider_
1642018-07-19T05:31:10  *** pierre_rochard_ is now known as pierre_rochard
1652018-07-19T05:31:26  *** wbnns has quit IRC
1662018-07-19T05:31:27  *** wbnns has joined #bitcoin-core-dev
1672018-07-19T05:33:03  *** pierre_rochard is now known as Guest26115
1682018-07-19T05:33:40  *** fanquake has quit IRC
1692018-07-19T05:35:19  *** CryptAxe has joined #bitcoin-core-dev
1702018-07-19T05:44:35  *** meshcollider_ has quit IRC
1712018-07-19T05:53:25  *** meshcollider_ has joined #bitcoin-core-dev
1722018-07-19T05:57:52  <kallewoof> luke-jr: lol! but mine will start a rebase based on the commit if you ask it to? :P
1732018-07-19T06:05:46  <luke-jr> kallewoof: ? why
1742018-07-19T06:06:51  <kallewoof> luke-jr: If code is breaking you may wanna fix it
1752018-07-19T06:08:09  <luke-jr> --fixup?
1762018-07-19T06:08:47  <kallewoof> Right, or you just rebase into the commit, reset "HEAD^", and recommit it during rebase.
1772018-07-19T06:25:32  *** promag has joined #bitcoin-core-dev
1782018-07-19T06:29:57  *** promag has quit IRC
1792018-07-19T06:34:44  *** Krellan has quit IRC
1802018-07-19T06:35:12  *** nmnkgl has quit IRC
1812018-07-19T06:35:24  *** Krellan has joined #bitcoin-core-dev
1822018-07-19T06:46:00  *** Dhiraj has joined #bitcoin-core-dev
1832018-07-19T06:46:05  <sipa> what's the difference between HEAD~ and HEAD^ ?
1842018-07-19T06:46:28  *** vicenteH has quit IRC
1852018-07-19T06:46:32  <Dhiraj> Could some one suggest where to submit sec-bug for https://github.com/bitcoin/bitcoin/ ?
1862018-07-19T06:46:59  *** vicenteH has joined #bitcoin-core-dev
1872018-07-19T06:47:39  <Dhiraj> any leads please ?
1882018-07-19T06:48:11  <sipa> Dhiraj: either open an issue, or email security@bitcoincore.org
1892018-07-19T06:48:31  <Dhiraj> okay cool, thank you
1902018-07-19T06:49:10  <harding> sipa: the difference is which side of a two-way merge it follows.  ^ is the left side (main code side by default), ~ is the right side (merged-in side) IIRC.
1912018-07-19T06:50:19  <Dhiraj> Thanks mail sent too security@bitcoincore.org
1922018-07-19T06:51:39  <sipa> harding: thanks
1932018-07-19T06:51:47  *** Dhiraj has quit IRC
1942018-07-19T06:51:51  <sipa> harding: just looked up it, not really
1952018-07-19T06:51:57  <sipa> they're the same
1962018-07-19T06:52:07  <sipa> ^i means the ith parent
1972018-07-19T06:52:21  <sipa> ~i means the i times 1st parent
1982018-07-19T06:52:44  <sipa> so HEAD~ and HEAD^ are the same; both refer to the first parent of HEAD
1992018-07-19T06:52:59  <sipa> but HEAD~2 is the first parent of the first parent
2002018-07-19T06:53:06  <sipa> while HeAD^2 is the second parent
2012018-07-19T07:02:24  *** nmnkgl has joined #bitcoin-core-dev
2022018-07-19T07:03:27  <harding> sipa: Hmm.  (Looks it up myself.)  Ok, yeah.  This quote seems like a good way to remember it: "way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit)."
2032018-07-19T07:06:27  *** shesek has joined #bitcoin-core-dev
2042018-07-19T07:06:27  *** shesek has joined #bitcoin-core-dev
2052018-07-19T07:23:47  *** dqx_ has joined #bitcoin-core-dev
2062018-07-19T07:26:39  *** promag has joined #bitcoin-core-dev
2072018-07-19T07:32:02  *** promag has quit IRC
2082018-07-19T07:42:38  *** vicenteH has quit IRC
2092018-07-19T07:43:09  *** vicenteH has joined #bitcoin-core-dev
2102018-07-19T07:59:20  *** Krellan has quit IRC
2112018-07-19T08:09:27  <bitcoin-git> [bitcoin] AkioNak opened pull request #13711: [bench] Add benchmark for unserialize prevector (master...add_bench_unserialize) https://github.com/bitcoin/bitcoin/pull/13711
2122018-07-19T08:13:41  *** unixb0y has joined #bitcoin-core-dev
2132018-07-19T08:18:21  *** timothy has joined #bitcoin-core-dev
2142018-07-19T08:20:27  *** farmerwampum has quit IRC
2152018-07-19T08:22:28  *** meshcollider_ has quit IRC
2162018-07-19T08:25:24  *** Guyver2 has joined #bitcoin-core-dev
2172018-07-19T08:33:30  <bitcoin-git> [bitcoin] practicalswift opened pull request #13712: wallet: Add error handling. Check return value of ParseUInt32(...) in… (master...check-ParseUInt32-return-value) https://github.com/bitcoin/bitcoin/pull/13712
2182018-07-19T08:38:34  *** promag has joined #bitcoin-core-dev
2192018-07-19T08:47:57  *** booyah has joined #bitcoin-core-dev
2202018-07-19T08:49:05  *** grafcaps has joined #bitcoin-core-dev
2212018-07-19T08:49:08  *** promag has quit IRC
2222018-07-19T08:53:18  *** promag has joined #bitcoin-core-dev
2232018-07-19T08:53:21  *** grafcaps has quit IRC
2242018-07-19T08:54:32  *** promag has quit IRC
2252018-07-19T09:02:21  *** SopaXorzTaker has joined #bitcoin-core-dev
2262018-07-19T09:06:24  <provoostenator> I just had a node (on crappy hardware) complain "ERROR: ConnectBlock: CheckQueue failed" and "InvalidChainFound: invalid block=" on a block that's valid. It then just sat there complaining that its peers were giving it invalid tips.
2272018-07-19T09:06:28  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #13713: Ignore new blocks when -stopatheight target has been reached (master...2018/07/stopatheight) https://github.com/bitcoin/bitcoin/pull/13713
2282018-07-19T09:06:38  <provoostenator> reconsiderblock did the trick and now it's happy again
2292018-07-19T09:21:03  <provoostenator> For about 30 blocks, rinse and repeat. This probably falls under "there's no generic way to deal with crappy hardware". Maybe just recommend a virtual RAID for indexes and chainstate dirs :-)
2302018-07-19T09:21:30  *** narodnik has joined #bitcoin-core-dev
2312018-07-19T09:26:12  <provoostenator> Maybe worth noting that this only started happening after the assumevalid block and the CPU's are only 50C. I think a while ago we discussed the idea of retrying signature validation a few times to handle "cosmic rays".
2322018-07-19T09:27:20  <kallewoof> Sure the hardware isn't broken?
2332018-07-19T09:27:36  <provoostenator> I'm sure the hardware _is_ broken.
2342018-07-19T09:27:47  <kallewoof> ok
2352018-07-19T09:28:39  <provoostenator> Assume valid block is 506067, this starts happening at 506364. I'm just wondering what's reasonable in trying to compensate for bad hardware.
2362018-07-19T09:31:15  *** vicenteH has quit IRC
2372018-07-19T09:31:57  *** vicenteH has joined #bitcoin-core-dev
2382018-07-19T09:36:49  *** SopaXT has joined #bitcoin-core-dev
2392018-07-19T09:37:07  *** SopaXorzTaker has quit IRC
2402018-07-19T09:37:09  *** SopaXT is now known as SopaXorzTaker
2412018-07-19T09:38:46  *** SopaXT has joined #bitcoin-core-dev
2422018-07-19T09:43:18  *** face has joined #bitcoin-core-dev
2432018-07-19T09:48:33  *** SopaXT has quit IRC
2442018-07-19T09:49:12  <bitcoin-git> [bitcoin] ken2812221 opened pull request #13714: [gitian-build] Add automatical lxc network setup for Bionic (master...gitian-build-auto-install) https://github.com/bitcoin/bitcoin/pull/13714
2452018-07-19T09:53:13  <jonasschnelli> wumpus: what do you think about #9662. IMO it's ready for merge (has >5 utACKs). Since it's my PR, I'd prefer if someone else merges it
2462018-07-19T09:53:21  <gribble> https://github.com/bitcoin/bitcoin/issues/9662 | Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets by jonasschnelli · Pull Request #9662 · bitcoin/bitcoin · GitHub
2472018-07-19T09:58:18  *** promag has joined #bitcoin-core-dev
2482018-07-19T10:08:55  *** promag has quit IRC
2492018-07-19T10:09:45  <bitcoin-git> [bitcoin] ken2812221 closed pull request #13660: [depends] Don't build Qt dependencies if it doesn't support Qt (master...qt-packages-fix) https://github.com/bitcoin/bitcoin/pull/13660
2502018-07-19T10:10:13  *** rafalcpp_ has quit IRC
2512018-07-19T10:10:58  *** rafalcpp_ has joined #bitcoin-core-dev
2522018-07-19T10:10:59  *** promag has joined #bitcoin-core-dev
2532018-07-19T10:20:12  *** ttlloo has joined #bitcoin-core-dev
2542018-07-19T10:20:20  <ttlloo> s
2552018-07-19T10:20:35  <ttlloo> getblonkNumber
2562018-07-19T10:21:03  *** ttlloo has left #bitcoin-core-dev
2572018-07-19T10:32:23  *** ExtraCrispy has joined #bitcoin-core-dev
2582018-07-19T10:34:13  *** goatpig has joined #bitcoin-core-dev
2592018-07-19T10:49:45  *** promag has quit IRC
2602018-07-19T10:50:59  *** promag has joined #bitcoin-core-dev
2612018-07-19T10:52:00  *** promag has quit IRC
2622018-07-19T11:06:20  *** SopaXorzTaker has quit IRC
2632018-07-19T11:06:52  *** SopaXorzTaker has joined #bitcoin-core-dev
2642018-07-19T11:13:05  *** Soligor has joined #bitcoin-core-dev
2652018-07-19T11:16:40  *** promag has joined #bitcoin-core-dev
2662018-07-19T11:17:56  *** rafalcpp_ is now known as rafalcpp
2672018-07-19T11:31:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2682018-07-19T11:37:26  *** promag has quit IRC
2692018-07-19T11:39:41  *** dqx_ has quit IRC
2702018-07-19T11:41:46  *** dqx_ has joined #bitcoin-core-dev
2712018-07-19T11:42:02  *** promag has joined #bitcoin-core-dev
2722018-07-19T11:48:35  *** bitconner has quit IRC
2732018-07-19T11:51:16  *** face has quit IRC
2742018-07-19T11:55:00  *** face has joined #bitcoin-core-dev
2752018-07-19T12:00:26  *** face has quit IRC
2762018-07-19T12:00:34  *** face has joined #bitcoin-core-dev
2772018-07-19T12:01:48  *** face has quit IRC
2782018-07-19T12:01:55  *** face has joined #bitcoin-core-dev
2792018-07-19T12:06:05  *** dqx_ has quit IRC
2802018-07-19T12:09:57  *** face has quit IRC
2812018-07-19T12:10:08  *** face has joined #bitcoin-core-dev
2822018-07-19T12:10:09  *** Chris_Stewart_5 has quit IRC
2832018-07-19T12:10:29  *** face has quit IRC
2842018-07-19T12:10:38  *** face has joined #bitcoin-core-dev
2852018-07-19T12:11:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2862018-07-19T12:17:05  <bitcoin-git> [bitcoin] marcoagner opened pull request #13715: tests: fixes mininode's P2PConnection sending messages on closing transport (master...fix_mininode_p2pconnection_send_message) https://github.com/bitcoin/bitcoin/pull/13715
2872018-07-19T12:17:48  *** Chris_Stewart_5 has quit IRC
2882018-07-19T12:19:41  *** promag has quit IRC
2892018-07-19T12:20:00  *** promag has joined #bitcoin-core-dev
2902018-07-19T12:20:09  *** Guyver2 has quit IRC
2912018-07-19T12:25:22  *** grafcaps has joined #bitcoin-core-dev
2922018-07-19T12:25:56  *** promag has quit IRC
2932018-07-19T12:29:46  *** grafcaps has quit IRC
2942018-07-19T12:32:55  *** dqx_ has joined #bitcoin-core-dev
2952018-07-19T12:35:53  *** bitconner has joined #bitcoin-core-dev
2962018-07-19T12:40:40  *** bitconner has quit IRC
2972018-07-19T12:42:32  *** un1c0d3r has joined #bitcoin-core-dev
2982018-07-19T12:45:46  *** promag has joined #bitcoin-core-dev
2992018-07-19T12:46:56  *** BashCo has quit IRC
3002018-07-19T12:54:51  *** un1c0d3r has quit IRC
3012018-07-19T12:59:51  *** promag has quit IRC
3022018-07-19T13:08:36  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4a3e8c5aa6a5...e1260a798d10
3032018-07-19T13:08:36  <bitcoin-git> bitcoin/master ea5340c marcoagner: tests: fixes mininode's P2PConnection sending messages on closing transport...
3042018-07-19T13:08:37  <bitcoin-git> bitcoin/master e1260a7 MarcoFalke: Merge #13715: tests: fixes mininode's P2PConnection sending messages on closing transport...
3052018-07-19T13:09:43  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13715: tests: fixes mininode's P2PConnection sending messages on closing transport (master...fix_mininode_p2pconnection_send_message) https://github.com/bitcoin/bitcoin/pull/13715
3062018-07-19T13:19:55  *** texan136 has joined #bitcoin-core-dev
3072018-07-19T13:20:06  *** texan136 has left #bitcoin-core-dev
3082018-07-19T13:21:01  *** d9b4bef9 has quit IRC
3092018-07-19T13:22:08  *** d9b4bef9 has joined #bitcoin-core-dev
3102018-07-19T13:26:03  *** BashCo has joined #bitcoin-core-dev
3112018-07-19T13:30:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3122018-07-19T13:36:11  *** bitconner has joined #bitcoin-core-dev
3132018-07-19T13:36:49  *** harrymm has quit IRC
3142018-07-19T13:39:34  *** grafcaps has joined #bitcoin-core-dev
3152018-07-19T13:40:50  *** harrymm has joined #bitcoin-core-dev
3162018-07-19T13:41:19  *** bitconner has quit IRC
3172018-07-19T13:49:00  *** grafcaps has quit IRC
3182018-07-19T13:51:14  *** farmerwampum has joined #bitcoin-core-dev
3192018-07-19T13:52:34  *** un1c0d3r has joined #bitcoin-core-dev
3202018-07-19T13:57:28  *** AaronvanW has joined #bitcoin-core-dev
3212018-07-19T14:04:01  *** grafcaps has joined #bitcoin-core-dev
3222018-07-19T14:05:25  <wumpus> rc2 executables up https://bitcoincore.org/bin/bitcoin-core-0.16.2/test.rc2/
3232018-07-19T14:10:36  *** grafcaps has quit IRC
3242018-07-19T14:11:21  *** dqx_ has quit IRC
3252018-07-19T14:16:36  *** dqx_ has joined #bitcoin-core-dev
3262018-07-19T14:24:01  *** grafcaps has joined #bitcoin-core-dev
3272018-07-19T14:25:07  *** dqx_ has quit IRC
3282018-07-19T14:25:45  *** dqx_ has joined #bitcoin-core-dev
3292018-07-19T14:28:43  *** Aaronvan_ has joined #bitcoin-core-dev
3302018-07-19T14:31:30  *** dqx_ has quit IRC
3312018-07-19T14:31:51  *** AaronvanW has quit IRC
3322018-07-19T14:42:55  *** Aaronvan_ has quit IRC
3332018-07-19T14:48:58  *** texan136 has joined #bitcoin-core-dev
3342018-07-19T14:50:58  *** texan136 has left #bitcoin-core-dev
3352018-07-19T14:52:21  <bitcoin-git> [bitcoin] kallewoof opened pull request #13716: bitcoin-cli: -stdinwalletpassphrase and non-echo stdin passwords (master...stdinwalletpassphrase) https://github.com/bitcoin/bitcoin/pull/13716
3362018-07-19T14:53:44  *** AaronvanW has joined #bitcoin-core-dev
3372018-07-19T14:53:51  *** bitconner has joined #bitcoin-core-dev
3382018-07-19T14:54:19  *** AaronvanW has quit IRC
3392018-07-19T14:54:56  *** AaronvanW has joined #bitcoin-core-dev
3402018-07-19T14:58:29  *** bitconner has quit IRC
3412018-07-19T14:59:36  *** dqx_ has joined #bitcoin-core-dev
3422018-07-19T15:00:05  *** promag has joined #bitcoin-core-dev
3432018-07-19T15:03:33  <promag> sipa: instead of old(pk), could just be pk(...) and add a "backward compability" option to scantxoutset?
3442018-07-19T15:04:34  <promag> that option could be per descriptor
3452018-07-19T15:06:32  *** Guyver2 has joined #bitcoin-core-dev
3462018-07-19T15:08:10  *** AaronvanW has quit IRC
3472018-07-19T15:08:40  *** AaronvanW has joined #bitcoin-core-dev
3482018-07-19T15:17:41  *** harrymm has quit IRC
3492018-07-19T15:19:55  *** AaronvanW has quit IRC
3502018-07-19T15:20:30  *** AaronvanW has joined #bitcoin-core-dev
3512018-07-19T15:23:35  *** dqx_ has quit IRC
3522018-07-19T15:24:50  *** AaronvanW has quit IRC
3532018-07-19T15:26:33  *** dqx_ has joined #bitcoin-core-dev
3542018-07-19T15:30:36  *** AaronvanW has joined #bitcoin-core-dev
3552018-07-19T15:35:14  *** AaronvanW has quit IRC
3562018-07-19T15:35:40  *** harrymm has joined #bitcoin-core-dev
3572018-07-19T15:36:45  <promag> sipa: I mean, instead of providing a descriptor for the old behaviour, add an option to support that behaviour
3582018-07-19T15:38:20  *** dqx_ has quit IRC
3592018-07-19T15:39:19  *** justanotheruser has quit IRC
3602018-07-19T15:40:50  *** harrymm has quit IRC
3612018-07-19T15:42:31  <provoostenator> Coolest error message ever: *** stack smashing detected ***: <unknown> terminated
3622018-07-19T15:46:14  *** wumpus_ has joined #bitcoin-core-dev
3632018-07-19T15:46:25  *** dqx_ has joined #bitcoin-core-dev
3642018-07-19T15:47:29  *** ken2812221 has joined #bitcoin-core-dev
3652018-07-19T15:48:17  *** wumpus has quit IRC
3662018-07-19T15:48:45  *** belcher has joined #bitcoin-core-dev
3672018-07-19T15:49:04  *** wumpus_ is now known as wumpus
3682018-07-19T15:49:24  *** pierre_rochard has joined #bitcoin-core-dev
3692018-07-19T15:50:52  *** bitconner has joined #bitcoin-core-dev
3702018-07-19T15:56:29  *** Guest26115 has quit IRC
3712018-07-19T15:56:41  *** ken2812221_ has joined #bitcoin-core-dev
3722018-07-19T15:57:33  *** harrymm has joined #bitcoin-core-dev
3732018-07-19T16:04:13  *** ken2812221_ has quit IRC
3742018-07-19T16:19:09  *** AaronvanW has joined #bitcoin-core-dev
3752018-07-19T16:28:52  *** str4d has joined #bitcoin-core-dev
3762018-07-19T16:33:38  *** arubi has quit IRC
3772018-07-19T16:34:06  *** arubi has joined #bitcoin-core-dev
3782018-07-19T16:36:46  *** SopaXorzTaker has quit IRC
3792018-07-19T16:38:31  *** bitconne1 has joined #bitcoin-core-dev
3802018-07-19T16:41:10  *** bitconner has quit IRC
3812018-07-19T16:49:27  *** dqx_ has quit IRC
3822018-07-19T16:50:27  *** dqx_ has joined #bitcoin-core-dev
3832018-07-19T16:55:35  *** dqx_ has quit IRC
3842018-07-19T16:57:44  *** dqx_ has joined #bitcoin-core-dev
3852018-07-19T17:07:12  *** ken2812221_ has joined #bitcoin-core-dev
3862018-07-19T17:07:27  *** ken2812221 has quit IRC
3872018-07-19T17:12:33  *** AaronvanW has quit IRC
3882018-07-19T17:13:09  *** AaronvanW has joined #bitcoin-core-dev
3892018-07-19T17:13:41  *** Guyver2 has quit IRC
3902018-07-19T17:17:50  *** AaronvanW has quit IRC
3912018-07-19T17:26:29  *** ken2812221_ is now known as ken2812221
3922018-07-19T17:33:26  *** vicenteH has quit IRC
3932018-07-19T17:34:01  *** vicenteH has joined #bitcoin-core-dev
3942018-07-19T17:37:09  *** str4d has quit IRC
3952018-07-19T17:40:59  *** timothy has quit IRC
3962018-07-19T17:41:33  *** Krellan has joined #bitcoin-core-dev
3972018-07-19T17:46:46  *** str4d has joined #bitcoin-core-dev
3982018-07-19T17:55:34  *** Krellan has quit IRC
3992018-07-19T17:56:17  *** drexl has joined #bitcoin-core-dev
4002018-07-19T17:56:44  *** yadev has joined #bitcoin-core-dev
4012018-07-19T17:59:07  <arubi> sipa, wrt earlier script{sig,pubkey} fork, do you mean that a script like " [script lhs] codesep <pubkey> checksig | [script rhs] " could be signed in a way that's invalid pre fork and valid after?  here "script lhs" and "script rhs" are just any script and '|' is the point where scriptsig and scriptpubkey are concatenated, so a second codesep pre-fork.
4022018-07-19T17:59:28  <arubi> at first I thought it was about codesep being "missing" to the right side of the sig post-fork, but afaict the signature would not sign the second codesep op pre-fork anyway because findanddelete removes it, so that's probably not it..  also sighash_single effectively just signs "1" so I don't see how anything in script might change what a sig must sign.
4032018-07-19T17:59:57  <arubi> anyway, if you could expand on what such an invalid pre-fork and valid after script would look like, I'd be very interested :)
4042018-07-19T18:00:54  <arubi> s/sighash_single/sighash_single bug/
4052018-07-19T18:05:31  <arubi> I do like the malformed serialization thing..  it feels like you could massage the bytes pushdata takes to glob the codesep pre-fork..  that's really interesting
4062018-07-19T18:05:57  <MarcoFalke> jonasschnelli: Looks like the nightly builds are down? https://bitcoin.jonasschnelli.ch/build/698
4072018-07-19T18:10:44  <jonasschnelli> MarcoFalke: looks like. thanks for reporting... I'll investigate
4082018-07-19T18:14:17  <MarcoFalke> Thx!
4092018-07-19T18:17:43  <sipa> jonasschnelli: please have a look at #13697
4102018-07-19T18:17:46  <gribble> https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHubAsset 1Asset 1
4112018-07-19T18:20:15  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1260a798d10...8c3643279165
4122018-07-19T18:20:15  <bitcoin-git> bitcoin/master a4ba238 Lawrence Nahum: depends: disable Werror for zmqlib release, causes ndk build to break
4132018-07-19T18:20:16  <bitcoin-git> bitcoin/master 8c36432 MarcoFalke: Merge #13689: depends: disable Werror when building zmq...
4142018-07-19T18:20:21  <sipa> arubi: yeah, i think you can exploit sighash_single on an input position above the number of outputs, which signs the message 0x0000...0001
4152018-07-19T18:20:58  <gmaxwell> I didn't understand your sighash single claim myself.
4162018-07-19T18:21:09  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13689: depends: disable Werror when building zmq (master...zmq_clang_depends) https://github.com/bitcoin/bitcoin/pull/13689
4172018-07-19T18:21:20  <gmaxwell> since it's signing a constant, why would the data going into the sighash matter?
4182018-07-19T18:21:53  *** dqx_ has quit IRC
4192018-07-19T18:22:44  <sipa> gmaxwell: uh, yes
4202018-07-19T18:22:46  <sipa> of course :)
4212018-07-19T18:22:55  <arubi> phew :)
4222018-07-19T18:24:44  <arubi> so that leaves something like pushdata behaving differently by either globbing the 0xAB of the codesep as data size or not..  it really seems possible
4232018-07-19T18:25:01  <gmaxwell> arubi: or not
4242018-07-19T18:25:30  <gmaxwell> I think it's silly to speculate on, without testing no one really knows
4252018-07-19T18:25:34  <jonasschnelli> sipa: Oh. Nice... will have a look soon!
4262018-07-19T18:25:35  <sipa> oh, of course
4272018-07-19T18:25:36  *** yadev has quit IRC
4282018-07-19T18:25:54  <sipa> arubi: i don't think that works
4292018-07-19T18:26:10  <gmaxwell> arubi: e.g. perhaps any case you could construct to do that fails because earlier deserialization will fail.
4302018-07-19T18:27:03  <sipa> arubi: for it to be valid post-fork, pushes/opcodes need to align with the scriptSig end
4312018-07-19T18:27:03  <arubi> hm, yea..  pushdata in scriptsig without enough bytes to glob fails..  right
4322018-07-19T18:27:30  <sipa> so we're perhaps back to it being a HF only under the assumption you can create a self-signing signature
4332018-07-19T18:27:46  <arubi> you could with op_swap
4342018-07-19T18:27:54  <arubi> or well, just op checksig right?
4352018-07-19T18:28:04  <arubi> ah again, findanddelete removes it..
4362018-07-19T18:28:22  <sipa> ah yes
4372018-07-19T18:28:57  <sipa> doesn't findanddelete save us?
4382018-07-19T18:30:24  *** dqx_ has joined #bitcoin-core-dev
4392018-07-19T18:32:14  <arubi> it almost seems like any signing shenanigans are out of the question.  definitely gonna be busy thinking about this :)
4402018-07-19T18:32:14  *** str4d has quit IRC
4412018-07-19T18:32:43  *** riemann_ has joined #bitcoin-core-dev
4422018-07-19T18:32:55  *** str4d has joined #bitcoin-core-dev
4432018-07-19T18:36:23  *** ExtraCrispy has quit IRC
4442018-07-19T18:36:30  *** dqx_ has quit IRC
4452018-07-19T18:36:50  <sipa> i think just a scriptSig of "<sig> <pubkey> OP_CHECKSIG" and a scriptPubKey of "OP_TRUE" is enough to HF
4462018-07-19T18:37:06  <sipa> is it not possible to create such a scriptSig now, due to FindAndDelete?
4472018-07-19T18:39:26  <arubi> with FaD you'd be signing everything except the signature both pre and post fork afaict, why is this hard forking?
4482018-07-19T18:40:27  <arubi> codesep is also removed, so just "<pubkey checksig 1" on both cases (codesep is to the right of checksig and removed)
4492018-07-19T18:41:19  <sipa> arubi: pre-fork you'd be signing "<pubkey> OP_CHECKSIG OP_TRUE", post-fork you're signing "<pubkey> OP_CHECKSIG"
4502018-07-19T18:41:52  <arubi> why?  1 is scriptpubkey, isn't it in sighash?
4512018-07-19T18:41:59  <arubi> err, 1 == op_true
4522018-07-19T18:42:24  *** AaronvanW has joined #bitcoin-core-dev
4532018-07-19T18:42:29  <sipa> pre-fork the executed script was "<sig> <pubkey> CHECKSIG CODESEP TRUE"
4542018-07-19T18:42:53  <arubi> yes, no codeseps to the left of checksig, the one on the right is removed
4552018-07-19T18:43:18  <sipa> i don't understand what you're disagreeing with
4562018-07-19T18:43:24  *** reallll has joined #bitcoin-core-dev
4572018-07-19T18:43:54  <arubi> I don't understand why you'd not be signing op_true post fork
4582018-07-19T18:44:00  *** reallll has quit IRC
4592018-07-19T18:44:28  <arubi> ohhh
4602018-07-19T18:44:29  <sipa> because it's in a different script?
4612018-07-19T18:44:33  <arubi> yes!
4622018-07-19T18:47:10  *** belcher has quit IRC
4632018-07-19T18:47:22  *** dqx_ has joined #bitcoin-core-dev
4642018-07-19T18:51:27  *** lclc has joined #bitcoin-core-dev
4652018-07-19T19:00:27  <sipa> DING
4662018-07-19T19:01:24  <jonasschnelli> DONG
4672018-07-19T19:01:25  * cfields hits snooze
4682018-07-19T19:02:03  <wumpus> #startmeeting
4692018-07-19T19:02:03  <lightningbot> Meeting started Thu Jul 19 19:02:03 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4702018-07-19T19:02:03  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4712018-07-19T19:02:06  <provoostenator> hi
4722018-07-19T19:02:20  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
4732018-07-19T19:02:22  <kanzure> hi.
4742018-07-19T19:02:26  <jonasschnelli> hu
4752018-07-19T19:02:29  <achow101> hi
4762018-07-19T19:02:32  <cfields> hi
4772018-07-19T19:02:35  <sipa> ho
4782018-07-19T19:02:46  *** Krellan has joined #bitcoin-core-dev
4792018-07-19T19:03:00  <wumpus> PSA: 0.16.2rc2 executables have been uploaded today and announcement sent
4802018-07-19T19:03:25  <jonasschnelli> thanks wumpus
4812018-07-19T19:03:54  <wumpus> any topics? I think main priority is to review feature PRs that need to go in before the feature freeze - which was postponed to the 23th
4822018-07-19T19:04:03  <sipa> 4 days and ticking...
4832018-07-19T19:04:05  <wumpus> although we maerged a view
4842018-07-19T19:04:15  <wumpus> few*
4852018-07-19T19:04:15  <cfields> <topic> last chance to vote on scheduling if you haven't already. Poll closes at the end of the meeting </topic>
4862018-07-19T19:04:25  <wumpus> cfields: I voted
4872018-07-19T19:04:25  <jonasschnelli> I'd like to see #9662 merged...
4882018-07-19T19:04:32  <gribble> https://github.com/bitcoin/bitcoin/issues/9662 | Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets by jonasschnelli · Pull Request #9662 · bitcoin/bitcoin · GitHub
4892018-07-19T19:04:32  <jonasschnelli> (has >5 acks)
4902018-07-19T19:04:42  <cfields> wumpus: thanks :)
4912018-07-19T19:04:49  <wumpus> jonasschnelli: let's do it then
4922018-07-19T19:04:51  *** Guest26115 has joined #bitcoin-core-dev
4932018-07-19T19:05:09  <achow101> topic suggestion: exposing coin selection (or other possibly more internal things) as rpcs
4942018-07-19T19:05:21  <jonasschnelli> #9502 has also a couple of acks and waits for a final review from cfields
4952018-07-19T19:05:24  <gribble> https://github.com/bitcoin/bitcoin/issues/9502 | [Qt] Add option to pause/resume block downloads by jonasschnelli · Pull Request #9502 · bitcoin/bitcoin · GitHub
4962018-07-19T19:05:29  <jonasschnelli> (was originally tagged for 0.17)
4972018-07-19T19:05:37  <sipa> i also want to bring up #13697 which changes the API for scantxoutset
4982018-07-19T19:05:40  <gribble> https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHub
4992018-07-19T19:05:44  <lclc> Topic Suggestion: Hi everyone, I propose moving the bitcoin-seeder from sipa's private GitHub (https://github.com/sipa/bitcoin-seeder) to the bitcoin-core GitHub organisation (https://github.com/bitcoin-core). (if this is on-topic)
5002018-07-19T19:05:53  <cfields> jonasschnelli: oh! sorry, will take a look right after the meeting
5012018-07-19T19:06:00  <jonasschnelli> thanks cfields
5022018-07-19T19:06:10  <jonasschnelli> I think sipas 13697 should be added to the high prio list
5032018-07-19T19:06:11  <provoostenator> Nice, though it would be nice if a followup PR made disable_private_keys positional, then we'll see if that part makes it into 0.17
5042018-07-19T19:06:20  <provoostenator> non-positional
5052018-07-19T19:06:22  <jonasschnelli> (since it's an API thing)
5062018-07-19T19:06:24  *** laurentmt has joined #bitcoin-core-dev
5072018-07-19T19:06:26  <sipa> if it doesn't go into 0.17, it'll either need to be an addition rather than a replacement, or we need to mark the API experimental (which may be a good idea regardless)
5082018-07-19T19:06:43  *** ken2812221_ has joined #bitcoin-core-dev
5092018-07-19T19:06:48  <wumpus> I think it's more relevant right now to tag things for 0.17 instead of adding them to the high-priority list
5102018-07-19T19:06:59  <jonasschnelli> Or that, yes.
5112018-07-19T19:07:10  <wumpus> everything that needs to go into 0.17 is high-priority by definition
5122018-07-19T19:07:10  *** ken2812221 has quit IRC
5132018-07-19T19:07:20  <jnewbery> in general I think it's a sensible default policy to mark new APIs as experimental
5142018-07-19T19:07:25  <wumpus> (although some things are taggd 0.17 that shouldn't be,I tihnk)
5152018-07-19T19:07:34  <sipa> what about #13666 ?
5162018-07-19T19:07:37  <gribble> https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHub
5172018-07-19T19:07:52  <provoostenator> What's in a number?
5182018-07-19T19:08:01  <sipa> 13 and 666, can't beat those odds
5192018-07-19T19:08:17  <wumpus> niice
5202018-07-19T19:08:35  <achow101> it was completely planned, obviously
5212018-07-19T19:08:40  <ken2812221_> Could #13426 be tagged for 0.17?
5222018-07-19T19:08:42  <gribble> https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Add u8path and u8string to fix encoding issue for Windows by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub
5232018-07-19T19:08:45  <sipa> in some timezones it was also opened on friday the 13th
5242018-07-19T19:09:03  <sipa> oh, no
5252018-07-19T19:09:20  <jonasschnelli> I hope no black cat was sitting on the keyboard during coding
5262018-07-19T19:09:20  <wumpus> ken2812221_: done
5272018-07-19T19:09:32  <ken2812221_> thanks
5282018-07-19T19:09:50  <sipa> if it is a bugfix it can also go in after the feature freeze
5292018-07-19T19:10:01  <wumpus> tagged 13666 13426 and 13697 with 0.17
5302018-07-19T19:10:06  <wumpus> absolutely
5312018-07-19T19:10:26  *** laurentmt has quit IRC
5322018-07-19T19:10:34  <sipa> 12 PRs tagged 0.17 :o
5332018-07-19T19:10:44  * sipa fires up the review engine
5342018-07-19T19:10:44  <achow101> #13712 is a bug fix for 0.17 too
5352018-07-19T19:10:46  <gribble> https://github.com/bitcoin/bitcoin/issues/13712 | wallet: Fix non-determinism in ParseHDKeypath(...). Avoid using an uninitialized variable in path calculation. by practicalswift · Pull Request #13712 · bitcoin/bitcoin · GitHub
5362018-07-19T19:10:53  <jonasschnelli> Looks like #8469 won't make it for 0.17. I guess untag would make sense
5372018-07-19T19:10:56  <gribble> https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
5382018-07-19T19:11:08  <wumpus> jonasschnelli: yes will remove that one
5392018-07-19T19:11:41  <jonasschnelli> Also #13617 (I like, but to wip-ish for the timing of 0.17)
5402018-07-19T19:11:43  <gribble> https://github.com/bitcoin/bitcoin/issues/13617 | [WIP] release: require macOS 10.10+ by fanquake · Pull Request #13617 · bitcoin/bitcoin · GitHub
5412018-07-19T19:11:53  <wumpus> and added 13712
5422018-07-19T19:12:22  <wumpus> jonasschnelli: ok
5432018-07-19T19:13:01  <cfields> jonasschnelli: if 13617 isn't ready in time (I don't see why it wouldn't, though), we can always bump the requirement and leave the stale code for later removal
5442018-07-19T19:13:15  <sipa> #13617
5452018-07-19T19:13:18  <gribble> https://github.com/bitcoin/bitcoin/issues/13617 | [WIP] release: require macOS 10.10+ by fanquake · Pull Request #13617 · bitcoin/bitcoin · GitHub
5462018-07-19T19:13:56  <jonasschnelli> Oh. Right... it's not a feature... agree with cfields
5472018-07-19T19:14:02  *** booyah has quit IRC
5482018-07-19T19:14:08  <wumpus> re-add it then?
5492018-07-19T19:14:20  <jonasschnelli> Yes. I'll do it. Sry for the confusion
5502018-07-19T19:14:48  *** AaronvanW has quit IRC
5512018-07-19T19:15:00  <wumpus> no problem
5522018-07-19T19:15:11  <wumpus> #topic exposing coin selection on RPC (achow101)
5532018-07-19T19:15:22  <gmaxwell> What does that mean precisely?
5542018-07-19T19:15:51  <achow101> this came up in a discussion with some companies about coin selection. basically, some are interested in using core's coin selection (or someone elses) instead of having to implement/roll their own
5552018-07-19T19:15:54  <wumpus> I'd say listunspent+raw transactions API
5562018-07-19T19:16:14  <achow101> currently if they wanted to use core's coin selection, the utxos need to be in the wallet, i.e. the addresses and possibly keys need to be in the wallet
5572018-07-19T19:16:17  <wumpus> fundrawtransaction?
5582018-07-19T19:16:17  <achow101> that is not ideal for them
5592018-07-19T19:16:17  <jonasschnelli> achow101: hmm,... is RPC the right interface for that?`
5602018-07-19T19:16:22  *** dqx_ has quit IRC
5612018-07-19T19:16:28  <sipa> i suggested to achow101 that a library might be a better way of doing so
5622018-07-19T19:16:31  <gmaxwell> but again what does that mean.  like isn't fun-draw-transaction that?
5632018-07-19T19:16:31  <jonasschnelli> Right.. what wumpus said
5642018-07-19T19:16:39  <achow101> the idea was then to have an rpc call where the utxos are provided and coin selection is operated on those utxos
5652018-07-19T19:16:46  <sipa> gmaxwell: they don't want to use the wallet; they just want to be able to run coin selection
5662018-07-19T19:16:51  <wumpus> you can import utxos into the wallet with importprunedfunds
5672018-07-19T19:16:53  <achow101> wumpus: fundrawtransaction requires the wallet
5682018-07-19T19:17:03  <jonasschnelli> achow101: using private key disabled dynamic wallet in conjunction with fundraw seems very efficient
5692018-07-19T19:17:08  <gmaxwell> I am doubtful that it is worth our effort in maintaining a stable interface for such a thing.
5702018-07-19T19:17:11  <achow101> wumpus: that's probably slow with hundreds of thousands of utxos
5712018-07-19T19:17:11  <wumpus> meh, RPC is not a good place for pure utility functions
5722018-07-19T19:17:26  <wumpus> if it doesn't need the wallet nor core state, why have it on *remote* procedure call?
5732018-07-19T19:17:26  <gmaxwell> E.g. kallewoof's recent grouping PR would have obliterated the interface for coin selection.
5742018-07-19T19:17:46  *** clarkmoody has joined #bitcoin-core-dev
5752018-07-19T19:17:53  <wumpus> it just creates a central point of faliure for no good reason
5762018-07-19T19:18:03  <wumpus> a library indeed sounds like a better idea
5772018-07-19T19:18:04  <jonasschnelli> Agree with wumpus.
5782018-07-19T19:18:12  *** dqx_ has joined #bitcoin-core-dev
5792018-07-19T19:18:27  <jonasschnelli> I know a library would be cumbersome to implement (compared to RPC),... but that is a weak argument IMO
5802018-07-19T19:18:27  <wumpus> RPC is not a good way to do code sharing
5812018-07-19T19:18:39  <sipa> it sounded like people really like RPC interfaces over libraries though, for reason i have difficulty comprehending
5822018-07-19T19:18:52  <achow101> a library is probably better, but the issue with libraries is that they all use different languages. so a different library for each language would need to be created
5832018-07-19T19:18:54  <sipa> but one possibility would be to have a separate binary with utility functions, that exposes an RPC
5842018-07-19T19:19:00  <gmaxwell> its just the webby world.
5852018-07-19T19:19:03  <wumpus> I don't get it
5862018-07-19T19:19:06  <achow101> and they seemed to like rpcs where things are easily dropped in
5872018-07-19T19:19:08  <wumpus> I don't want to debate this madness
5882018-07-19T19:19:12  <gmaxwell> achow101: C(++) is callable from every language.... :P
5892018-07-19T19:19:21  <jonasschnelli> Wild though: provide a cli tool?
5902018-07-19T19:19:22  <bitcoin-git> [bitcoin] masonicboom opened pull request #13717: docs: Link to python style guidelines from developer notes (master...link-to-python-style-guidelines-from-dev-notes) https://github.com/bitcoin/bitcoin/pull/13717
5912018-07-19T19:19:25  <gmaxwell> (well C is, C++ via making a C interface. :) )
5922018-07-19T19:19:27  <jonasschnelli> *thought
5932018-07-19T19:19:28  <sipa> jonasschnelli: slow
5942018-07-19T19:19:41  <gmaxwell> but in any case, if you have a library you can also wrap that to present an RPC.
5952018-07-19T19:19:44  <jonasschnelli> (a library & a CLI tool for the lazy people)
5962018-07-19T19:19:51  <wumpus> cli also a 'remote' call, though it invokes a new process for every call!
5972018-07-19T19:19:57  <wumpus> but it has the same issues with (de)serialization
5982018-07-19T19:20:06  <gmaxwell> But the argument I was making above is also an argument against a library: pressure to maintain a stable interface to this would be harmful to the project.
5992018-07-19T19:20:20  <wumpus> right
6002018-07-19T19:20:24  <jonasschnelli> indeed... if performance is the goal, a library is probably the right choice.
6012018-07-19T19:20:26  <sipa> i think coin selection is relatively well encapsulated
6022018-07-19T19:20:46  <sipa> i also don't see how kallewoof's groupings would break the API
6032018-07-19T19:20:47  <gmaxwell> sipa: I just gave an example where recent changes changed the API substantailly.
6042018-07-19T19:21:05  <gmaxwell> Both BNB and kallewoof changed arguments to every entry point.
6052018-07-19T19:21:18  <wumpus> to be honest I think this is not a concern for our project
6062018-07-19T19:21:21  <achow101> gmaxwell: but the interface exposed to the callers did not
6072018-07-19T19:21:26  <sipa> so? overall it takes a list of UTXOs and gives a subset back
6082018-07-19T19:21:41  <wumpus> some other people want a coin selection algorithm for their own purposes
6092018-07-19T19:21:58  <achow101> gmaxwell: only things within selectcoins changed, and an rpc would effectively only expose selectcoins
6102018-07-19T19:22:00  <wumpus> it's fine, they can make a library out of it themselves
6112018-07-19T19:22:05  <gmaxwell> it's more tightly coupled than "list of UTXOs" ... e.g. it needs fees, signature sizes.
6122018-07-19T19:22:09  <wumpus> the code is open source
6132018-07-19T19:22:52  <gmaxwell> I mean if someone can jigger things around to make it seperable and they find that useful, fantastic.
6142018-07-19T19:22:57  <achow101> wumpus: sure the code is open source, but it is not something that can easily be taken out and dropped into something else.
6152018-07-19T19:23:05  <gmaxwell> But I don't want to hear "we can't implement privacy feature X because it'll break an interface"
6162018-07-19T19:23:05  <wumpus> for the consensus code I see a strong reason to provide it as a library: it is *important* that everyone uses the same consensus code
6172018-07-19T19:23:08  <jonasschnelli> wumpus: I think what they want is something maintained by the same people
6182018-07-19T19:23:22  <wumpus> jonasschnelli: the same people might not agree with that, who asks them?!
6192018-07-19T19:23:37  <gmaxwell> perhaps they should contribute to making the wallet code better so they don't have to write their own. :P
6202018-07-19T19:23:39  <wumpus> they might want the whole world to be maintained by the same people
6212018-07-19T19:23:52  <jonasschnelli> heh...
6222018-07-19T19:24:14  *** booyah has joined #bitcoin-core-dev
6232018-07-19T19:24:38  <wumpus> gmaxwell: right, exactly
6242018-07-19T19:24:57  *** laurentmt has joined #bitcoin-core-dev
6252018-07-19T19:25:24  <achow101> the general feeling was that they wanted core to be more modular so that they can pick and choose specific internal components to use in their software
6262018-07-19T19:25:27  *** riemann_ has quit IRC
6272018-07-19T19:25:44  <achow101> also more generally that there was some sort of "canonical" libraries for things instead of everyone implementing their own thing
6282018-07-19T19:26:00  <wumpus> but making internal interfaces stable does restrict future flexibilty, as gmaxwell says
6292018-07-19T19:26:11  <wumpus> it's already hard enough to change the RPC interface
6302018-07-19T19:26:54  <wumpus> I understand the desire for that, bt puttingn that all on our plate is unreasonable
6312018-07-19T19:27:00  <wumpus> as well as centralization
6322018-07-19T19:27:30  *** laurentmt has quit IRC
6332018-07-19T19:27:58  <wumpus> it's not how things can work in a project like this, the same group providing canonical implementations for everything
6342018-07-19T19:28:10  <achow101> right
6352018-07-19T19:28:21  <moneyball> suggested topic: next Core dev tech meetup
6362018-07-19T19:28:45  <jnewbery> wumpus: there is some benefit to making the Core coin selection algorithm more generally usable though
6372018-07-19T19:29:15  <wumpus> jnewbery: people that want that, can work on that, the code is open source, they can make a library out of it
6382018-07-19T19:29:16  <jnewbery> eg if we think it's good and reduces UTXO bloat, having more people using it is a benefit
6392018-07-19T19:29:35  <wumpus> if it turns out to be feasible enough then core can start using that library too
6402018-07-19T19:29:43  <wumpus> that's a two-step process, though
6412018-07-19T19:29:52  <sipa> i think the first step for this is something we're doing anyway; making the code itself more encapsulated
6422018-07-19T19:29:53  <jonasschnelli> Agree with wumpus: I guess its a one-day job to extract the coin selection code and create a library out of it...
6432018-07-19T19:30:01  <sipa> no it's not
6442018-07-19T19:30:05  <jonasschnelli> The burden is the maintenance...
6452018-07-19T19:30:08  <sipa> it's currently split between wallet code and coinselection
6462018-07-19T19:30:12  <wumpus> jonasschnelli: I doubt it's that easy
6472018-07-19T19:30:13  <sipa> and that's improving
6482018-07-19T19:30:13  <bitcoin-git> [bitcoin] masonicboom opened pull request #13718: docs: Specify preferred Python string formatting technique (master...python-string-format-guideline) https://github.com/bitcoin/bitcoin/pull/13718
6492018-07-19T19:30:19  <jnewbery> yes, agree that anyone can work on it. I think it's a legitimate thing to bring up in a core meeting though
6502018-07-19T19:31:00  <sipa> i think it's great to hear there is interest in code we're writing
6512018-07-19T19:31:10  <jnewbery> sipa: +1
6522018-07-19T19:31:16  <wumpus> sipa: so in as far as that helps our own maintainability of the walletcode, that's a good thing
6532018-07-19T19:31:58  <sipa> wumpus: perhaps once the code is sufficiently encapsulated, someone else can librarify that and maintain it
6542018-07-19T19:32:06  *** LukeJr has joined #bitcoin-core-dev
6552018-07-19T19:32:07  <wumpus> right
6562018-07-19T19:33:12  <wumpus> #topic #13697 which changes the API for scantxoutset
6572018-07-19T19:33:15  <gribble> https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHub
6582018-07-19T19:33:16  <wumpus> (sipa)
6592018-07-19T19:33:41  <sipa> first of all, this is part of a bigger effort to combine keys and scripts and chains into one concept
6602018-07-19T19:34:14  <sipa> there's a mini language to specify (sets of) scriptPubKeys, so i'd very much first want to hear comments on that language
6612018-07-19T19:34:27  <wumpus> yes that is very neat
6622018-07-19T19:34:58  <sipa> https://github.com/sipa/bitcoin/blob/895a46d83550838a8170ccba075367232eabbd8c/src/script/descriptor.h#L9L68
6632018-07-19T19:35:22  <jonasschnelli> I really like it. Will review and test it asap!
6642018-07-19T19:36:00  <sipa> the other question is scantxoutset experimental or not, and with descriptor support in 0.17 or not
6652018-07-19T19:36:03  <jonasschnelli> What is the difference between the FlatSigningProvider and the dummysigner?
6662018-07-19T19:36:24  <sipa> dummysignatureprovider doesn't provide anything
6672018-07-19T19:36:39  <sipa> flatisigningprovider takes its information from flat maps
6682018-07-19T19:36:53  <jonasschnelli> I see
6692018-07-19T19:37:00  <wumpus> I think scantxout should be marked experimental
6702018-07-19T19:37:05  <jonasschnelli> Agree
6712018-07-19T19:37:14  <jonasschnelli> Also with 13697...
6722018-07-19T19:37:18  <sipa> agree
6732018-07-19T19:37:22  <jonasschnelli> Helps us to do unplaned API changed
6742018-07-19T19:37:34  <jonasschnelli> *changes
6752018-07-19T19:37:35  <wumpus> right
6762018-07-19T19:37:49  <sipa> i plan to write a longer explanation in doc/descriptors.md or so
6772018-07-19T19:38:11  <wumpus> cool
6782018-07-19T19:38:21  <jonasschnelli> thanks for working on this sipa
6792018-07-19T19:38:23  <sipa> one of the future ideas is a PSBT standalone binary that can sign/update using descriptors
6802018-07-19T19:38:34  <luke-jr> should these be a BIP? seems potentially useful outside Core
6812018-07-19T19:38:45  <sipa> luke-jr: potentially yes, but not in first instance
6822018-07-19T19:38:53  <sipa> i expect that this will evolve rather quickly
6832018-07-19T19:39:11  <luke-jr> BIP drafts can evolve :p
6842018-07-19T19:39:22  <wumpus> maybe at some point, but as this doesn't touch consensus or P2P it'd be an advisory BIP at most, and it's not required to do it first
6852018-07-19T19:39:34  <wumpus> luke-jr: let's just leave it up to sipa
6862018-07-19T19:39:35  <sipa> also, the part that actually needs interoperability is PSBT; descripors are just how we (or at least i hope) represent our knowledge
6872018-07-19T19:40:00  <sipa> compability would certainly be useful too, but i'd rather take some time to see how things evolve
6882018-07-19T19:40:23  <sipa> otherwise i fear we'll have something with a dozen optional parts all implemented by different subsets of software
6892018-07-19T19:40:34  <wumpus> yes
6902018-07-19T19:41:28  <wumpus> #topic bitcoin-seeder under bitcoin-core GitHub organisation (lclc)
6912018-07-19T19:41:49  <sipa> lclc: no problem as far as I'm concerned, but i'm not sure it's the right message
6922018-07-19T19:41:52  <luke-jr> Seems unnecessary.
6932018-07-19T19:42:03  <lclc> I though because there are a few open issues and simple PRs for bitcoin-seeder and it might would make sense that several Bitcoin maintainers have merge rights.
6942018-07-19T19:42:04  <sipa> there are other pieces of seeder software out there too, and having variety is a good thing here
6952018-07-19T19:42:16  <luke-jr> should we put bfgminer, knots, kallewoof's script debugger stuff, etc under bitcoin-core too? :p
6962018-07-19T19:42:21  <lclc> I know there are several seeder implementations but it appears to be the most used one. And since getting new node IPs by DNS is the default way to bootstrap a node in Core I think it makes sense to have one implementation in the bitcoin-core org.
6972018-07-19T19:42:29  <wumpus> luke-jr: if they want
6982018-07-19T19:42:43  <luke-jr> wumpus: what sipa said - it sends the wrong msg IMO
6992018-07-19T19:43:09  <wumpus> yes, to be clear I don't think it's necessary
7002018-07-19T19:43:20  <provoostenator> Another approach could be for sipa to give more people access to that repo?
7012018-07-19T19:43:22  <jonasschnelli> No strong opinion... but slighly prefere to have it under the bitcoin-core repository
7022018-07-19T19:43:23  <luke-jr> although maybe it would make sense for knots, but that would probably just be a mess on github
7032018-07-19T19:43:32  <luke-jr> provoostenator: +1
7042018-07-19T19:43:40  <luke-jr> to sipa giving access as desired
7052018-07-19T19:43:41  <sipa> provoostenator: i'm fine with that!
7062018-07-19T19:43:51  <wumpus> as I said before with the library stuff, I think it's more robust to spread projects around instead of create the illusion that they're all maintained by the same 'team'
7072018-07-19T19:43:53  <provoostenator> Or create an ad hoc organization "Sipa's DNS Seed maintainer club"
7082018-07-19T19:43:55  *** bitconne1 has quit IRC
7092018-07-19T19:43:59  <wumpus> so agree with you on that luke-jr
7102018-07-19T19:44:09  <luke-jr> there's no reason to turn access to tht eCore github repo ainto an actual position
7112018-07-19T19:44:13  <luke-jr> forgive the typos
7122018-07-19T19:45:09  *** bitconner has joined #bitcoin-core-dev
7132018-07-19T19:45:11  <lclc> That's also fine with me
7142018-07-19T19:45:14  <achow101> topic suggestion: moving away from bitcoin.org more
7152018-07-19T19:46:02  <lclc> I (and others) just have a few simple PRs open (and open PRs feels like potential outstanding work in the future :D), so a few more maintainers (maybe jonasschnelli ?) would be good
7162018-07-19T19:46:06  <wumpus> #topic moving away from bitcoin.org more (achow101)
7172018-07-19T19:46:12  <luke-jr> not sure there's anything further we can do in terms of oving away..?
7182018-07-19T19:46:18  <achow101> we still link to bitcoin.org for things like downloads
7192018-07-19T19:46:20  <wumpus> achow101: moving what, excatly? executables have been moved
7202018-07-19T19:46:22  <achow101> should probably change those
7212018-07-19T19:46:24  <jonasschnelli> I'm pretty familiar with the seeder code and happy to co-maintain it
7222018-07-19T19:46:26  <wumpus> achow101: where?
7232018-07-19T19:46:27  <luke-jr> achow101: where?
7242018-07-19T19:46:31  <achow101> in the readme
7252018-07-19T19:46:36  <jnewbery> I don't think we link to bitcoin.org for downloads any more
7262018-07-19T19:46:46  <wumpus> at least in the release mail I link to bitcoincore.org nowadays
7272018-07-19T19:47:13  <moneyball> suggested topic: next Core dev tech meetup :)
7282018-07-19T19:47:15  <sipa> For more information, as well as an immediately useable, binary version of
7292018-07-19T19:47:15  <provoostenator> And there's guiconstants.h: QAPP_ORG_DOMAIN "bitcoin.org"
7302018-07-19T19:47:18  <sipa> the Bitcoin Core software, see https://bitcoin.org/en/download
7312018-07-19T19:47:19  <jnewbery> Open a PR to remove that link from the readme. I will happily ACK
7322018-07-19T19:47:21  <luke-jr> bitcoin.org could increase distance further, but someone needs to do that work, and people whined when they tried, so I think it's stuck
7332018-07-19T19:47:29  <wumpus> I think the link to bitcoin.org is only for the *general* descriptoin of bitcoin
7342018-07-19T19:47:35  <wumpus> that certainly would be confusing to make bitcoincore.or
7352018-07-19T19:47:39  <wumpus> moneyball: yep
7362018-07-19T19:47:43  <sipa> wumpus: see quote above
7372018-07-19T19:47:46  <luke-jr> provoostenator: oh yeah, that was an issue for distro stuff somewhere IIRC
7382018-07-19T19:47:54  <wumpus> sipa: oh yes that should go
7392018-07-19T19:48:03  <sipa> ack on that in any case
7402018-07-19T19:48:06  <wumpus> provoostenator: don't change that! it determines the settings path
7412018-07-19T19:48:08  <luke-jr> provoostenator: might want to make it something generic though, not Core-specific
7422018-07-19T19:48:23  <achow101> I was thinking that it may not be appropriate to make release posts on bitcoin.org, at least not before they go up on bitcoincore.or
7432018-07-19T19:48:52  <luke-jr> wumpus: I think it's used outside settings too, but maybe best to just leave it alone
7442018-07-19T19:48:58  <achow101> as in we should simply take the bitcoin.org steps out of our release process and if someone wants to do them later, then that's fine
7452018-07-19T19:49:04  <luke-jr> perhaps a comment explaining it's for compatibility, nothing more
7462018-07-19T19:49:14  <wumpus> luke-jr: possibly, but at the least it loses the qsettings, that's also why it's not "Bitcoin core" named there yet
7472018-07-19T19:49:31  <wumpus> achow101: would that really make anything better?
7482018-07-19T19:49:43  <wumpus> achow101: are you seriously suggesting I should no longer update bitcoin.org and upload binaries there?
7492018-07-19T19:49:55  <achow101> yes
7502018-07-19T19:50:17  <achow101> wumpus: are you aware of the recent events on bitcoin.org?
7512018-07-19T19:50:36  <provoostenator> Well, I think technically he's suggesting not having that be part of the documented process, but you can do whatever you want.
7522018-07-19T19:50:42  <wumpus> acvaguely
7532018-07-19T19:50:42  *** bitconner has quit IRC
7542018-07-19T19:51:05  <luke-jr> Cobra wanted to make Knots the "default" on bitcoin.org a while back; we could encourage that, or (probably better) encourage not having a "default"
7552018-07-19T19:51:06  <wumpus> so I think this will effectively reduce the number of downloads
7562018-07-19T19:51:28  <wumpus> I don't care though, I don't want to be involved in political stuff at all, I' kind of burned out on that
7572018-07-19T19:51:34  <luke-jr> wumpus: Core doesn't have a problem wth getting users atm
7582018-07-19T19:51:36  <jonasschnelli> I think we should only publish binaries via bitcoincore.org and should not actively push it to other websites...
7592018-07-19T19:51:47  <luke-jr> >99% of the network runs Core
7602018-07-19T19:51:47  <jonasschnelli> It's gives a wrong sense of project coupling
7612018-07-19T19:51:48  <achow101> there's ongoing work to move all of the bitcoin core stuff from bitcoin.org to bitcoincore.org
7622018-07-19T19:52:21  <wumpus> maybe the developer documentation too
7632018-07-19T19:52:33  <luke-jr> if people are running/updating Core simply because it's on bitcoin.org, that is kind of a systemic risk we should address if possible
7642018-07-19T19:52:48  <luke-jr> (and making it harder to "just run bitcoin.org" seems a step in that direction)
7652018-07-19T19:53:04  *** Chris_Stewart_5 has quit IRC
7662018-07-19T19:53:33  <wumpus> #topic next coredev tech meeting (moneyball)
7672018-07-19T19:54:03  <moneyball> Hi, I wanted to let people know I've volunteered to organize the next Core Dev Tech meetup
7682018-07-19T19:54:18  <moneyball> The current thinking is to have it in Tokyo in October after Scaling Bitcoin
7692018-07-19T19:54:22  <luke-jr> thanks
7702018-07-19T19:54:24  <moneyball> Oct 8-10
7712018-07-19T19:54:27  <jonasschnelli> thanks moneyball
7722018-07-19T19:54:30  <wumpus> yes, awesome!
7732018-07-19T19:54:35  <jonasschnelli> moneyball: please update https://github.com/coredev-tech
7742018-07-19T19:54:37  <provoostenator> Awesome indeed
7752018-07-19T19:54:39  <cfields> thanks moneyball :)
7762018-07-19T19:54:58  <moneyball> And to organize it in a similar fashion as the last one in NYC
7772018-07-19T19:55:20  <moneyball> Cory put me in touch with the Digital Garage guys and they will be able to help quite a bit, similar to last year's Tokyo meetup
7782018-07-19T19:55:21  <sipa> nice
7792018-07-19T19:55:50  <moneyball> I plan to send out a survey to collect some feedback
7802018-07-19T19:56:07  <moneyball> If anyone has specific ideas or suggestions please feel free to contact me
7812018-07-19T19:56:59  <moneyball> Nothing more from me about the topic now
7822018-07-19T19:57:04  <luke-jr> side note: anime meetup after on Oct 11 if anyone's interested https://docs.google.com/document/d/1CWLhg8u9pfNWSVjgiPYt0V5ZIOQFSCIYYdSvzHaqOpQ/edit?usp=sharing
7832018-07-19T19:57:41  <jonasschnelli> thanks moneyball for organising!
7842018-07-19T19:57:55  <moneyball> You're welcome happy to help!
7852018-07-19T19:58:18  <jnewbery> yes, thanks moneyball! Looking forward to it :)
7862018-07-19T19:59:27  <wumpus> #endmeeting
7872018-07-19T19:59:28  <lightningbot> Meeting ended Thu Jul 19 19:59:27 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7882018-07-19T19:59:28  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-19-19.02.html
7892018-07-19T19:59:28  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-19-19.02.txt
7902018-07-19T19:59:28  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-19-19.02.log.html
7912018-07-19T19:59:36  <wumpus> thanks everyone
7922018-07-19T19:59:38  <achow101> topic suggetion: lunch
7932018-07-19T19:59:45  <sipa> #lunch
7942018-07-19T19:59:56  <luke-jr> not breakfast?
7952018-07-19T20:00:23  <sipa> it will in fact be my first meal of the day
7962018-07-19T20:00:36  <ken2812221_> for me, it's almost breakfast.4 AM here
7972018-07-19T20:01:15  <cfields> ken2812221_: you got a link to vote on the meeting time, right?
7982018-07-19T20:01:37  <ken2812221_> No, I didn't receive the email.
7992018-07-19T20:02:03  <provoostenator> Any tips for debugging the auto hidden service feature when it doesn't seem reachable? Its log looks happy, but trying to addnode it results in "general failure" (as opposed to "host unreachable")
8002018-07-19T20:02:31  <cfields> ken2812221_: hmm. I'll resend. Can you stick around for another minute to vote?
8012018-07-19T20:02:39  *** lclc has quit IRC
8022018-07-19T20:03:06  <ken2812221_> ok, thanks
8032018-07-19T20:04:03  <wumpus> provoostenator: fwiw this is what I use to manually check hidden service connections: https://twitter.com/orionwl/status/1000995421739802624
8042018-07-19T20:04:09  <cfields> ken2812221_: got that one?
8052018-07-19T20:04:29  <ken2812221_> cfields: yes. thank you
8062018-07-19T20:04:37  <wumpus> provoostenator: also run with debug=torcontrol on the server
8072018-07-19T20:04:38  <provoostenator> Using the wrong port will get me a "connection refused", so something is out there :-)
8082018-07-19T20:05:02  <wumpus> ok
8092018-07-19T20:05:37  <wumpus> 'general failure' is a generic enough error message to be completely useless :)
8102018-07-19T20:06:02  *** LukeJr has quit IRC
8112018-07-19T20:06:38  <cfields> ken2812221_: please let me know when you're finished so that I can end the poll.
8122018-07-19T20:06:55  <wumpus> provoostenator: so it might be something with the forwarding then, is the bind port open?
8132018-07-19T20:07:24  <jonasschnelli> Is there a quick cure for my gitian builder? Trying to create a bionic base vm....but getting E: No such script: /usr/share/debootstrap/scripts/bionic
8142018-07-19T20:07:51  <cfields> jonasschnelli: try using lxc
8152018-07-19T20:07:51  <luke-jr> jonasschnelli: AFAIK we don't have a way to make gitian base VMs for bionic yet (at least KVM?)
8162018-07-19T20:08:08  <jonasschnelli> cfields: I though I'm using lxc
8172018-07-19T20:08:17  <wumpus> tor, from the server side, reports a different thing if the port is not open on the hidden service at all - versus when the connection to the local target port fails
8182018-07-19T20:08:19  <jonasschnelli> Getting the error after executing bin/make-base-vm --suite bionic --arch amd64 --lxc
8192018-07-19T20:09:37  <cfields> jonasschnelli: ah, I think it might still look at the bionic debootstrap script. You might need to update a package. sec.
8202018-07-19T20:09:45  <ken2812221_> cfields: finished
8212018-07-19T20:09:50  <cfields> ken2812221_: thanks!
8222018-07-19T20:09:57  <provoostenator> -debug=tor says "ADD_ONION successful ...  advertising service [....].onion ... AddLocal([....].onion:8333,4)"
8232018-07-19T20:10:21  <cfields> jonasschnelli: oh, just apt-get update and apt-get install debootstrap
8242018-07-19T20:10:41  <cfields> jonasschnelli: in my case, anyway, mine was old and missing the script for Bionic. Upgrading that package fixed it.
8252018-07-19T20:11:47  <wumpus> so in any case: does everyone think I should stop uploading bitcoin core to bitcoin.org? this would be a complete break with them, maybe that's better than waiting for cobra to decide to no longer support core as he's already threatened at least once, but I'm ambivalent abouti t
8262018-07-19T20:12:03  <wumpus> provoostenator: looks 100% good
8272018-07-19T20:12:38  <wumpus> provoostenator: so can you connect locally to the 127.0.0.1:port that tor connects on to reach bitcoin?
8282018-07-19T20:12:39  <provoostenator> Indeed. Might be nice for it to try and ping itself via Tor.
8292018-07-19T20:12:54  *** un1c0d3r has quit IRC
8302018-07-19T20:13:11  <luke-jr> wumpus: I think we should leave that up to bitcoin.org, and encourage them to be multi-fullnode
8312018-07-19T20:13:42  <wumpus> luke-jr: leave it up to them = keep doing what I do now?
8322018-07-19T20:14:08  <luke-jr> wumpus: basically
8332018-07-19T20:14:12  <cfields> wumpus: I think that makes sense. They're Bitcoin Core downloads, not Bitcoin downloads. If bitcoin.org wants to mirror them, that's their prerogative.
8342018-07-19T20:14:13  <wumpus> ok
8352018-07-19T20:14:22  <jonasschnelli> cfields: debootstrap is already the newest version (1.0.89).
8362018-07-19T20:14:37  <provoostenator> bind=127.0.0.1:8333 did the trick, bid surprised that was needed.
8372018-07-19T20:14:46  <luke-jr> wumpus: if they say "we'll point people to bitcoincore.org for that", then stop (and encourage this outcome)
8382018-07-19T20:16:11  <provoostenator> Coming soon: I'm thinking of making my Armbian build script use the Tor hidden service stuff by default, as well as connect via Tor proxy outbound.
8392018-07-19T20:16:24  <ken2812221_> The minimum debootstrap version to support bionic is 1.0.92
8402018-07-19T20:16:34  <cfields> jonasschnelli: ah, you're on Debian
8412018-07-19T20:16:44  <wumpus> provoostenator: yes, that's surprising, the ideal solution for that would be #8973 - make the tor forwarding code create its own private P2P listening port
8422018-07-19T20:16:45  <gribble> https://github.com/bitcoin/bitcoin/issues/8973 | Incoming tor connections should use alternative port · Issue #8973 · bitcoin/bitcoin · GitHub
8432018-07-19T20:16:46  *** hex17or has joined #bitcoin-core-dev
8442018-07-19T20:17:01  <jonasschnelli> cfields: Right...I'm looing for a Bionic script now
8452018-07-19T20:17:19  <wumpus> (or even a UNIX socket, if we ever get that code into mergable shape)
8462018-07-19T20:17:26  <luke-jr> jonasschnelli: check backports?
8472018-07-19T20:17:43  <luke-jr> bbiab
8482018-07-19T20:17:46  <cfields> jonasschnelli: if it helps, it's just a symlink to gutsy. Do you have that?
8492018-07-19T20:18:09  <jonasschnelli> cfields:okay.Let me try that
8502018-07-19T20:18:31  *** ghost43 has quit IRC
8512018-07-19T20:19:06  <jonasschnelli> cfields: that should still create bionic-deterministic builds?
8522018-07-19T20:19:13  <jonasschnelli> (seems to work)
8532018-07-19T20:19:33  *** ghost43 has joined #bitcoin-core-dev
8542018-07-19T20:20:18  <cfields> jonasschnelli: I guess we'll see :)
8552018-07-19T20:20:46  <jonasschnelli> heh..okay. :)
8562018-07-19T20:20:46  *** yadev has joined #bitcoin-core-dev
8572018-07-19T20:20:53  *** bitconner has joined #bitcoin-core-dev
8582018-07-19T20:21:17  <yadev> Hello !
8592018-07-19T20:22:12  <yadev> Please I need to run a full node for a cryptocurrency trading site what are requirements, what do you suggest me to do ? thanks.
8602018-07-19T20:22:25  <jonasschnelli> yadev: #bitcoin
8612018-07-19T20:22:58  <yadev> Thanks
8622018-07-19T20:24:42  <cfields> poll results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_a80f9a69d20aab2a
8632018-07-19T20:26:39  <wumpus> yadev: see https://bitcoin.org/en/full-node  (but yes, discussion of user issues belongs in #bitcoin)
8642018-07-19T20:27:42  *** yadev has quit IRC
8652018-07-19T20:27:48  <wumpus> cfields: so should we pick the most popular and least popular times? ;)
8662018-07-19T20:28:35  *** dqx_ has quit IRC
8672018-07-19T20:28:37  <cfields> heh
8682018-07-19T20:30:23  <wumpus> in any case this confirms that a lot of people do in fact like the current time
8692018-07-19T20:32:35  <cfields> I had some hope that there's a 25th hour that is amenable to everyone. Guess not :(
8702018-07-19T20:32:50  <jonasschnelli> cfields: using bionic, I get "lxc-init: missing container name, use --name option"? Any idea how to get rid of this?
8712018-07-19T20:33:13  <jonasschnelli> (don't complain when I use trusty)
8722018-07-19T20:33:26  <ken2812221_> update lxc to 2.1.1 or upper
8732018-07-19T20:33:31  <cfields> jonasschnelli: ok, that's the lxc2 vs lcx3 incompatibility
8742018-07-19T20:33:36  <cfields> right
8752018-07-19T20:34:05  <jonasschnelli> I'm on debian stretch
8762018-07-19T20:34:06  <jonasschnelli> :(
8772018-07-19T20:34:17  <cfields> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/13171#issuecomment-405711147
8782018-07-19T20:37:56  <gmaxwell> wumpus: re unix sockets, did the upstream things we need for that happen?
8792018-07-19T20:39:11  *** hex17or has quit IRC
8802018-07-19T20:39:23  <wumpus> gmaxwell: not sure; though there was only one small part that needed upstream support, the client-side RPC support
8812018-07-19T20:39:55  <wumpus> P2P unix sockets support didn't need anything special, neither did server-side RPC
8822018-07-19T20:40:46  <gmaxwell> only reason I ask I guess is because our side can be done whenever, upstream has leadtimes. :)
8832018-07-19T20:41:39  <wumpus> I kind of lost track, I think upstream wanted another solution which was much more work and I didn't really understand how it would help us
8842018-07-19T20:43:34  *** nickler has quit IRC
8852018-07-19T20:43:45  <wumpus> (I think something that would allow automatic reconnection)
8862018-07-19T20:44:37  <wumpus> it's still open: https://github.com/libevent/libevent/pull/479
8872018-07-19T20:44:42  *** hex17or has joined #bitcoin-core-dev
8882018-07-19T20:45:01  <wumpus> "I added EVHTTP_CON_OUTGOING. Making the retry work with a callback (at either http or bufferevent level) as suggested by @azat sounds like a good idea to me, but that exceeds my expertise with the libevent code."
8892018-07-19T20:45:22  <wumpus> if anyone knows more about libevent than me, please help
8902018-07-19T20:46:34  <jonasschnelli> cfields: so Bionic requires LXC 2.1.1 which is not available on the newest Debian version (stretch)... that seems to be unfortunate
8912018-07-19T20:46:57  <jonasschnelli> Looks like I don't have an upgrade path for my build host
8922018-07-19T20:47:08  <wumpus> otherwise I'm not sure this is ever going to happen, though I still think it's useful even without bitcoin-cli support
8932018-07-19T20:47:15  <cfields> jonasschnelli: yea. I don't see any way around it :(
8942018-07-19T20:48:47  <gmaxwell> wumpus: Do we have a way to test it without bitcoin-cli support?
8952018-07-19T20:48:58  *** hex17or has quit IRC
8962018-07-19T20:49:08  <wumpus> gmaxwell: my original PR already updated the test framework to use it (from python)
8972018-07-19T20:49:12  <gmaxwell> Oh.
8982018-07-19T20:49:21  <gmaxwell> Well then, I agree its useful without -cli.
8992018-07-19T20:49:32  <wumpus> gmaxwell: whihch was one of the primary motivations because it allows doing the tests without claiming port ranges
9002018-07-19T20:49:32  *** frenchy has joined #bitcoin-core-dev
9012018-07-19T20:50:31  <frenchy> Hello everyone
9022018-07-19T20:50:33  <wumpus> using UNIX sockets guarantees that there are no port collisions
9032018-07-19T20:53:26  <gmaxwell> wumpus: yep makes perfect sense there.
9042018-07-19T20:53:28  <wumpus> and reduces other risk that external things interfere ODODODwith the tests, though making the P2P port in the tests listen on localhost only was a good move in that direction
9052018-07-19T20:53:46  <wumpus> frenchy: hello.
9062018-07-19T20:58:19  *** AaronvanW has joined #bitcoin-core-dev
9072018-07-19T20:58:54  <gmaxwell> wumpus: right, I think the reason I found the socket most interesting was better security, e.g. making it easy to give a group access to the bitcoin daemon rather than all of localhost.
9082018-07-19T21:01:28  <bitcoin-git> [bitcoin] sipa opened pull request #13719: Avoid creating a temporary vector for size-prefixed elements (master...201807_psbt_no_vec_serialize) https://github.com/bitcoin/bitcoin/pull/13719
9092018-07-19T21:01:38  *** dqx_ has joined #bitcoin-core-dev
9102018-07-19T21:02:35  <bitcoin-git> [bitcoin] practicalswift opened pull request #13720: build: Make lint-locale-dependence.sh work with BSD grep (avoid empty subexpressions) (master...bsd-grep-compatibility) https://github.com/bitcoin/bitcoin/pull/13720
9112018-07-19T21:03:35  *** booyah has quit IRC
9122018-07-19T21:08:19  *** nickler has joined #bitcoin-core-dev
9132018-07-19T21:12:05  *** dqx_ has quit IRC
9142018-07-19T21:13:05  *** str4d has quit IRC
9152018-07-19T21:14:35  *** dqx_ has joined #bitcoin-core-dev
9162018-07-19T21:16:59  <jonasschnelli> cfields: self compiled lxc 2.1.1 seems to work.
9172018-07-19T21:17:00  *** un1c0d3r has joined #bitcoin-core-dev
9182018-07-19T21:17:17  <jonasschnelli> https://bitcoin.jonasschnelli.ch/build/707
9192018-07-19T21:18:06  *** un1c0d3r has quit IRC
9202018-07-19T21:18:54  *** frenchy has quit IRC
9212018-07-19T21:23:20  <cfields> jonasschnelli: nice!
9222018-07-19T21:29:35  *** dqx_ has quit IRC
9232018-07-19T21:34:15  *** goatpig has quit IRC
9242018-07-19T21:35:09  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c3643279165...f281f8f75522
9252018-07-19T21:35:10  <bitcoin-git> bitcoin/master 2c71edc John Newbery: [wallet] [rpc] Fix importaddress help text
9262018-07-19T21:35:10  <bitcoin-git> bitcoin/master f281f8f MarcoFalke: Merge #13074: [trivial] Correct help text for `importaddress` RPC...
9272018-07-19T21:35:41  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13074: [trivial] Correct help text for `importaddress` RPC (master...importaddress_help_text) https://github.com/bitcoin/bitcoin/pull/13074
9282018-07-19T21:36:24  *** dqx_ has joined #bitcoin-core-dev
9292018-07-19T21:37:01  <jonasschnelli> sipa: is it possible to define a range rather then all keys in a chain? https://github.com/bitcoin/bitcoin/pull/13697/commits/83cc8dcaa5dfe22d4ba657edf35727d09da09dd1#diff-8c0b1c3cb0e19eaad495b468bc5813aaR56
9302018-07-19T21:37:32  <jonasschnelli> Haven't looked at the code,... but maybe  pkh(xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw/1'/2/[0-1000]) should be possible
9312018-07-19T21:37:45  <sipa> jonasschnelli: i would rather not do that
9322018-07-19T21:37:51  <jonasschnelli> why?
9332018-07-19T21:38:15  <sipa> jonasschnelli: the reason is that in some contexts where descriptors are useful, the chain size is determined by the environment (in particular, in a wallet it follows from gap limit and blockchain)
9342018-07-19T21:38:34  <sipa> so unless you're going to add more "variants" of the descriptor language, it doesn't feel like a core feature
9352018-07-19T21:39:59  <jonasschnelli> Thinking practical: assume I haven a xpub and I'd like to find funds via scantxoutset (gap limit not possible)... would it make sense to scan for all non hardened keys (assume BIP44 has been used)?
9362018-07-19T21:40:12  <sipa> jonasschnelli: no, you specify a range
9372018-07-19T21:40:13  <jonasschnelli> I'm not sure about the performance implications... maybe it's okay
9382018-07-19T21:40:22  <sipa> jonasschnelli: the scantxoutset RPC in my PR lets you do that
9392018-07-19T21:40:31  <sipa> it's just not part of the descriptor itself
9402018-07-19T21:40:36  <jonasschnelli> aha.. okay. I'm still at the third commit. :)
9412018-07-19T21:40:54  *** clarkmoody has quit IRC
9422018-07-19T21:40:57  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f281f8f75522...aba2e666d7fd
9432018-07-19T21:40:58  <bitcoin-git> bitcoin/master 7223263 practicalswift: wallet: Add tests for ParseHDKeypath(...)
9442018-07-19T21:40:58  <bitcoin-git> bitcoin/master 27ee53c practicalswift: wallet: Add error handling. Check return value of ParseUInt32(...) in ParseHDKeypath(...).
9452018-07-19T21:40:59  <bitcoin-git> bitcoin/master aba2e66 MarcoFalke: Merge #13712: wallet: Fix non-determinism in ParseHDKeypath(...). Avoid using an uninitialized variable in path calculation....
9462018-07-19T21:41:15  <jonasschnelli> (sipa: IMO the third commit "Support output descriptors in scantxoutset" sould be renamed to somthing without "scantxoutset")
9472018-07-19T21:41:25  <sipa> why?
9482018-07-19T21:41:39  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13712: wallet: Fix non-determinism in ParseHDKeypath(...). Avoid using an uninitialized variable in path calculation. (master...check-ParseUInt32-return-value) https://github.com/bitcoin/bitcoin/pull/13712
9492018-07-19T21:41:50  <jonasschnelli> sipa: it's unrelated to scantxoutset
9502018-07-19T21:42:00  <sipa> the third commit is called "Output descriptors module"
9512018-07-19T21:42:17  <sipa> you're looking at the PR title
9522018-07-19T21:42:17  <jonasschnelli> Damit! Got fooled by github. NM
9532018-07-19T21:42:26  <sipa> haha
9542018-07-19T21:47:01  *** brianhoffman has joined #bitcoin-core-dev
9552018-07-19T21:47:08  <jonasschnelli> sipa: right now, each child key requires to derive the complete chain, right?
9562018-07-19T21:47:37  <sipa> jonasschnelli: there's a TODO to cache the bottom non-hardened key
9572018-07-19T21:48:01  <sipa> i can add that in the same PR if you want
9582018-07-19T21:48:13  <jonasschnelli> I guess that can be added later
9592018-07-19T21:48:45  <jonasschnelli> Performance should not mater in the context of scanning the whole utxo set
9602018-07-19T21:48:59  <jonasschnelli> (for other descriptor usages it may matter)
9612018-07-19T21:49:06  <jonasschnelli> so later should be fine
9622018-07-19T21:49:11  <sipa> right, agree
9632018-07-19T21:51:59  <achow101> it would be nice if we could also get #12493 in for 0.17
9642018-07-19T21:52:02  <gribble> https://github.com/bitcoin/bitcoin/issues/12493 | [wallet] Reopen CDBEnv after encryption instead of shutting down by achow101 · Pull Request #12493 · bitcoin/bitcoin · GitHub
9652018-07-19T21:53:17  *** dqx_ has quit IRC
9662018-07-19T21:54:55  *** dqx_ has joined #bitcoin-core-dev
9672018-07-19T22:04:22  *** meshcollider_ has joined #bitcoin-core-dev
9682018-07-19T22:05:15  *** meshcollider_ has quit IRC
9692018-07-19T22:05:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
9702018-07-19T22:07:12  *** AaronvanW has quit IRC
9712018-07-19T22:14:38  <meshcollider> So is the meeting time likely to stay as-is
9722018-07-19T22:15:21  <meshcollider> Sorry I missed this morning's
9732018-07-19T22:28:09  *** justanotheruser has joined #bitcoin-core-dev
9742018-07-19T22:29:42  *** dqx_ has quit IRC
9752018-07-19T22:30:16  *** lari has quit IRC
9762018-07-19T22:31:24  *** lari has joined #bitcoin-core-dev
9772018-07-19T22:37:07  *** jamesob_ has joined #bitcoin-core-dev
9782018-07-19T22:37:07  *** jamesob__ has joined #bitcoin-core-dev
9792018-07-19T22:39:08  *** Chris_Stewart_5 has quit IRC
9802018-07-19T22:40:57  *** jtimon has joined #bitcoin-core-dev
9812018-07-19T22:42:25  <jtimon> review beg https://github.com/bitcoin/bitcoin/pull/13311 , I'm waiting on that to rebase https://github.com/bitcoin/bitcoin/pull/8994
9822018-07-19T22:51:09  *** dqx_ has joined #bitcoin-core-dev
9832018-07-19T22:51:09  <aj> #13311 #8994
9842018-07-19T22:51:13  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
9852018-07-19T22:51:15  <gribble> https://github.com/bitcoin/bitcoin/issues/13311 | Dont edit Chainparams after initialization by jtimon · Pull Request #13311 · bitcoin/bitcoin · GitHub
9862018-07-19T22:54:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
9872018-07-19T22:56:01  *** vicenteH has quit IRC
9882018-07-19T23:01:23  *** Squidicuz has quit IRC
9892018-07-19T23:02:50  *** dqx_ has quit IRC
9902018-07-19T23:06:21  *** polydin has quit IRC
9912018-07-19T23:19:41  *** drexl has quit IRC
9922018-07-19T23:34:25  <aj> jtimon: you could tick the todo box for 12128 in 8994's description fwiw
9932018-07-19T23:37:25  *** dqx_ has joined #bitcoin-core-dev
9942018-07-19T23:39:02  *** Randolf has joined #bitcoin-core-dev
9952018-07-19T23:43:29  *** dqx_ has quit IRC
9962018-07-19T23:45:33  <jtimon> aj: done, thanks