1 2018-07-19T00:07:31  *** BashCo has quit IRC
  2 2018-07-19T00:07:35  *** Dizzle has quit IRC
  3 2018-07-19T00:08:40  *** Krellan has quit IRC
  4 2018-07-19T00:09:29  *** Krellan has joined #bitcoin-core-dev
  5 2018-07-19T00:24:00  *** AaronvanW has joined #bitcoin-core-dev
  6 2018-07-19T00:27:08  *** BashCo has joined #bitcoin-core-dev
  7 2018-07-19T00:32:28  *** pinhead has quit IRC
  8 2018-07-19T00:41:27  *** dqx_ has quit IRC
  9 2018-07-19T00:42:28  *** Tennis has quit IRC
 10 2018-07-19T00:46:58  *** dqx_ has joined #bitcoin-core-dev
 11 2018-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
 12 2018-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
 13 2018-07-19T00:52:47  *** dqx_ has quit IRC
 14 2018-07-19T00:56:06  *** dqx_ has joined #bitcoin-core-dev
 15 2018-07-19T01:01:52  *** AaronvanW has quit IRC
 16 2018-07-19T01:14:11  *** |EHG| has joined #bitcoin-core-dev
 17 2018-07-19T01:29:20  *** Urgo has quit IRC
 18 2018-07-19T01:32:46  *** Urgo has joined #bitcoin-core-dev
 19 2018-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
 20 2018-07-19T02:16:23  *** Krellan has quit IRC
 21 2018-07-19T02:16:47  *** grafcaps has quit IRC
 22 2018-07-19T02:17:09  *** Krellan has joined #bitcoin-core-dev
 23 2018-07-19T02:25:22  *** grafcaps has joined #bitcoin-core-dev
 24 2018-07-19T02:25:57  *** johnn2 has joined #bitcoin-core-dev
 25 2018-07-19T02:27:09  *** Urgo has quit IRC
 26 2018-07-19T02:27:20  *** bitconner has quit IRC
 27 2018-07-19T02:27:43  *** Urgo has joined #bitcoin-core-dev
 28 2018-07-19T02:28:49  *** radioops has quit IRC
 29 2018-07-19T02:29:59  *** grafcaps has quit IRC
 30 2018-07-19T02:36:03  *** farmerwampum has joined #bitcoin-core-dev
 31 2018-07-19T02:38:13  *** farmerwampum has quit IRC
 32 2018-07-19T02:38:33  *** farmerwampum has joined #bitcoin-core-dev
 33 2018-07-19T02:52:35  *** dqx_ has quit IRC
 34 2018-07-19T02:58:18  *** hendrik_ has joined #bitcoin-core-dev
 35 2018-07-19T03:01:30  *** xC0FFEE has quit IRC
 36 2018-07-19T03:13:21  *** bitconner has joined #bitcoin-core-dev
 37 2018-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)
 38 2018-07-19T03:37:32  *** nico_ has joined #bitcoin-core-dev
 39 2018-07-19T03:40:17  *** nico_ is now known as un1c0d3r
 40 2018-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?)
 41 2018-07-19T03:43:57  <gmaxwell> Yes.
 42 2018-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.
 43 2018-07-19T03:44:57  <gmaxwell> because the traditional definition of a hardfork (as used on that article) doesn't really allow for that.
 44 2018-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
 45 2018-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.
 46 2018-07-19T03:46:12  <gmaxwell> And if it does exist, it's never actually been triggered.
 47 2018-07-19T03:46:27  <gmaxwell> So it would, if the conjecture holds, be better to call that a latent hardfork.
 48 2018-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
 49 2018-07-19T03:52:42  *** meshcollider_ has joined #bitcoin-core-dev
 50 2018-07-19T03:52:57  *** un1c0d3r has quit IRC
 51 2018-07-19T03:54:16  <luke-jr> gmaxwell: most consensus rules are never triggered. that's immaterial to the change.
 52 2018-07-19T03:57:05  <gmaxwell> it's pretty material to the question of it being debatable if there was a hardfork or not!
 53 2018-07-19T03:57:26  <luke-jr> if the rules were relaxed, it was by definition a hardfork.
 54 2018-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.
 55 2018-07-19T03:57:44  <luke-jr> no demonstration case is needed
 56 2018-07-19T03:57:48  <gmaxwell> Sometimes it's really hard to tell if they were relaxed or not.
 57 2018-07-19T03:58:09  <luke-jr> which one are you referring to?
 58 2018-07-19T03:58:28  <gmaxwell> " I mean we don't actually know if the script split was a hardfork"
 59 2018-07-19T03:58:41  <luke-jr> oh, 0.3.7? I guess that's unclear.
 60 2018-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.
 61 2018-07-19T03:59:12  <gmaxwell> But it's complicated enough that it probably won't be convincing without an example transaction.
 62 2018-07-19T03:59:21  <luke-jr> couldn't an OP_IF span the two scripts previously?
 63 2018-07-19T03:59:57  <luke-jr> hmm, can't think of a way to make that do invalid->valid, nm
 64 2018-07-19T04:00:03  <gmaxwell> I think the example required an invalid serialization whos bytes gobbled up the code seperator.
 65 2018-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.
 66 2018-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.
 67 2018-07-19T04:01:19  <gmaxwell> or something along those lines.
 68 2018-07-19T04:01:36  <luke-jr> right
 69 2018-07-19T04:01:56  <luke-jr> not sure it's worth the effort to prove either way, maybe it can just say "unclear"
 70 2018-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.
 71 2018-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.
 72 2018-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
 73 2018-07-19T04:03:04  <gmaxwell> luke-jr: yea, so only to 99.99999% of people on earth. :P
 74 2018-07-19T04:03:35  <luke-jr> most people don't have either a correct understanding NOR a misunderstanding ;)
 75 2018-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).
 76 2018-07-19T04:04:18  <luke-jr> I'd say all hardforks are "latent"
 77 2018-07-19T04:04:43  <luke-jr> if the network splits, it would cease to be a hardfork, and become an altcoin like BCH instead
 78 2018-07-19T04:05:02  <gmaxwell> Even if the network hasn't split, the more permissiveness could have been used or not.
 79 2018-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.
 80 2018-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.
 81 2018-07-19T04:08:48  <luke-jr> you want to fix it, or should I? ;)
 82 2018-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."
 83 2018-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
 84 2018-07-19T04:10:32  <luke-jr> because then you have a chopped opcode to execute
 85 2018-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.
 86 2018-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
 87 2018-07-19T04:12:04  <gmaxwell> luke-jr: I dunno I'd have to find the discussion. I recall thinking that it was plausable.
 88 2018-07-19T04:12:35  <luke-jr> maybe kanzure remembers XD
 89 2018-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.
 90 2018-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
 91 2018-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.
 92 2018-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.
 93 2018-07-19T04:14:58  <luke-jr> the fix to the problem, in March, was to make the rules deterministically stricter ;)
 94 2018-07-19T04:15:26  <luke-jr> ie, semver 1.0.2 on the wiki page
 95 2018-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.
 96 2018-07-19T04:15:47  <luke-jr> why not? wasn't it strictly more restrictive?
 97 2018-07-19T04:16:10  <gmaxwell> No, because the BDB behavior was more complicated than we understood at the time.
 98 2018-07-19T04:16:16  <luke-jr> >_<
 99 2018-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).
100 2018-07-19T04:17:17  <gmaxwell> at least in theory.
101 2018-07-19T04:17:34  <luke-jr> you mean in the wallet bdb?
102 2018-07-19T04:17:40  <luke-jr> or what else would cause reads going on?
103 2018-07-19T04:17:51  <gmaxwell> indeed.
104 2018-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
105 2018-07-19T04:20:42  <sipa> gmaxwell: addition of NOPs was at the same time as removal of VER
106 2018-07-19T04:21:07  <gmaxwell> sipa: yes, and? removing ver was a softfork.
107 2018-07-19T04:21:54  <gmaxwell> (I suppose luke should argue that every version _prior_ to that point was a hardfork, due to OP_VER. ...)
108 2018-07-19T04:22:16  <gmaxwell> luke-jr: Another reason why latent vs non-latent hardforks matter: a latent one could still be softforked out.
109 2018-07-19T04:22:36  <sipa> gmaxwell: script split was a trivial hardfork; the sighash effect of codesep changed
110 2018-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.
111 2018-07-19T04:24:16  <luke-jr> gmaxwell: any hardfork can be softforked out.
112 2018-07-19T04:24:39  <gmaxwell> luke-jr: not in a way that prevents older software from going out of consensus.
113 2018-07-19T04:25:23  <luke-jr> ?
114 2018-07-19T04:25:52  <sipa> gmaxwell: did you see my comment on sighash and codesep?
115 2018-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 ?
116 2018-07-19T04:27:37  *** baldur has quit IRC
117 2018-07-19T04:27:43  <gmaxwell> (well codesep and a valid signature, of course)
118 2018-07-19T04:27:44  <sipa> gmaxwell: yes
119 2018-07-19T04:28:06  <sipa> a signature with a checksig in the scriotsig
120 2018-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.
121 2018-07-19T04:28:25  <sipa> it may be impossible to construct a valid one like that now...
122 2018-07-19T04:28:42  <sipa> maybe when using sighash_single bug
123 2018-07-19T04:29:00  *** promag has joined #bitcoin-core-dev
124 2018-07-19T04:29:31  <gmaxwell> it would certantly make more sense, since the block in question wasn't even especially large.
125 2018-07-19T04:31:20  *** lontivero has quit IRC
126 2018-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
127 2018-07-19T04:33:35  *** promag has quit IRC
128 2018-07-19T04:34:02  <luke-jr> gmaxwell: depends on why you're classifying
129 2018-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
130 2018-07-19T04:38:02  *** baldur has joined #bitcoin-core-dev
131 2018-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 ?
132 2018-07-19T04:39:26  <luke-jr> :p
133 2018-07-19T04:42:25  <luke-jr> sipa: so you're sure that *at the time*, the script split was a HF?
134 2018-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
135 2018-07-19T04:43:36  <aj> "make || break" -- love it
136 2018-07-19T05:12:43  *** grafcaps has joined #bitcoin-core-dev
137 2018-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
138 2018-07-19T05:17:29  *** grafcaps has quit IRC
139 2018-07-19T05:28:56  *** mariorz_ has joined #bitcoin-core-dev
140 2018-07-19T05:29:07  *** mturquette_ has joined #bitcoin-core-dev
141 2018-07-19T05:29:12  *** trotski2000 has quit IRC
142 2018-07-19T05:29:12  *** pindarhk_ has quit IRC
143 2018-07-19T05:29:12  *** CryptAxe has quit IRC
144 2018-07-19T05:29:13  *** trotski2000 has joined #bitcoin-core-dev
145 2018-07-19T05:29:22  *** pierre_rochard_ has joined #bitcoin-core-dev
146 2018-07-19T05:29:23  *** meshcollider__ has joined #bitcoin-core-dev
147 2018-07-19T05:29:50  *** rodarmor_ has joined #bitcoin-core-dev
148 2018-07-19T05:29:51  *** epic has quit IRC
149 2018-07-19T05:29:51  *** bosma has quit IRC
150 2018-07-19T05:29:51  *** wbnns has quit IRC
151 2018-07-19T05:29:51  *** mturquette has quit IRC
152 2018-07-19T05:29:52  *** mturquette_ is now known as mturquette
153 2018-07-19T05:29:55  *** mappum__ has joined #bitcoin-core-dev
154 2018-07-19T05:30:26  *** bosma has joined #bitcoin-core-dev
155 2018-07-19T05:30:26  *** epic has joined #bitcoin-core-dev
156 2018-07-19T05:30:27  *** wbnns has joined #bitcoin-core-dev
157 2018-07-19T05:30:30  *** mariorz has quit IRC
158 2018-07-19T05:30:31  *** pindarhk_ has joined #bitcoin-core-dev
159 2018-07-19T05:31:08  *** meshcollider_ has quit IRC
160 2018-07-19T05:31:09  *** rodarmor has quit IRC
161 2018-07-19T05:31:09  *** mappum_ has quit IRC
162 2018-07-19T05:31:09  *** pierre_rochard has quit IRC
163 2018-07-19T05:31:09  *** meshcollider__ is now known as meshcollider_
164 2018-07-19T05:31:10  *** pierre_rochard_ is now known as pierre_rochard
165 2018-07-19T05:31:26  *** wbnns has quit IRC
166 2018-07-19T05:31:27  *** wbnns has joined #bitcoin-core-dev
167 2018-07-19T05:33:03  *** pierre_rochard is now known as Guest26115
168 2018-07-19T05:33:40  *** fanquake has quit IRC
169 2018-07-19T05:35:19  *** CryptAxe has joined #bitcoin-core-dev
170 2018-07-19T05:44:35  *** meshcollider_ has quit IRC
171 2018-07-19T05:53:25  *** meshcollider_ has joined #bitcoin-core-dev
172 2018-07-19T05:57:52  <kallewoof> luke-jr: lol! but mine will start a rebase based on the commit if you ask it to? :P
173 2018-07-19T06:05:46  <luke-jr> kallewoof: ? why
174 2018-07-19T06:06:51  <kallewoof> luke-jr: If code is breaking you may wanna fix it
175 2018-07-19T06:08:09  <luke-jr> --fixup?
176 2018-07-19T06:08:47  <kallewoof> Right, or you just rebase into the commit, reset "HEAD^", and recommit it during rebase.
177 2018-07-19T06:25:32  *** promag has joined #bitcoin-core-dev
178 2018-07-19T06:29:57  *** promag has quit IRC
179 2018-07-19T06:34:44  *** Krellan has quit IRC
180 2018-07-19T06:35:12  *** nmnkgl has quit IRC
181 2018-07-19T06:35:24  *** Krellan has joined #bitcoin-core-dev
182 2018-07-19T06:46:00  *** Dhiraj has joined #bitcoin-core-dev
183 2018-07-19T06:46:05  <sipa> what's the difference between HEAD~ and HEAD^ ?
184 2018-07-19T06:46:28  *** vicenteH has quit IRC
185 2018-07-19T06:46:32  <Dhiraj> Could some one suggest where to submit sec-bug for https://github.com/bitcoin/bitcoin/ ?
186 2018-07-19T06:46:59  *** vicenteH has joined #bitcoin-core-dev
187 2018-07-19T06:47:39  <Dhiraj> any leads please ?
188 2018-07-19T06:48:11  <sipa> Dhiraj: either open an issue, or email security@bitcoincore.org
189 2018-07-19T06:48:31  <Dhiraj> okay cool, thank you
190 2018-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.
191 2018-07-19T06:50:19  <Dhiraj> Thanks mail sent too security@bitcoincore.org
192 2018-07-19T06:51:39  <sipa> harding: thanks
193 2018-07-19T06:51:47  *** Dhiraj has quit IRC
194 2018-07-19T06:51:51  <sipa> harding: just looked up it, not really
195 2018-07-19T06:51:57  <sipa> they're the same
196 2018-07-19T06:52:07  <sipa> ^i means the ith parent
197 2018-07-19T06:52:21  <sipa> ~i means the i times 1st parent
198 2018-07-19T06:52:44  <sipa> so HEAD~ and HEAD^ are the same; both refer to the first parent of HEAD
199 2018-07-19T06:52:59  <sipa> but HEAD~2 is the first parent of the first parent
200 2018-07-19T06:53:06  <sipa> while HeAD^2 is the second parent
201 2018-07-19T07:02:24  *** nmnkgl has joined #bitcoin-core-dev
202 2018-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)."
203 2018-07-19T07:06:27  *** shesek has joined #bitcoin-core-dev
204 2018-07-19T07:06:27  *** shesek has joined #bitcoin-core-dev
205 2018-07-19T07:23:47  *** dqx_ has joined #bitcoin-core-dev
206 2018-07-19T07:26:39  *** promag has joined #bitcoin-core-dev
207 2018-07-19T07:32:02  *** promag has quit IRC
208 2018-07-19T07:42:38  *** vicenteH has quit IRC
209 2018-07-19T07:43:09  *** vicenteH has joined #bitcoin-core-dev
210 2018-07-19T07:59:20  *** Krellan has quit IRC
211 2018-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
212 2018-07-19T08:13:41  *** unixb0y has joined #bitcoin-core-dev
213 2018-07-19T08:18:21  *** timothy has joined #bitcoin-core-dev
214 2018-07-19T08:20:27  *** farmerwampum has quit IRC
215 2018-07-19T08:22:28  *** meshcollider_ has quit IRC
216 2018-07-19T08:25:24  *** Guyver2 has joined #bitcoin-core-dev
217 2018-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
218 2018-07-19T08:38:34  *** promag has joined #bitcoin-core-dev
219 2018-07-19T08:47:57  *** booyah has joined #bitcoin-core-dev
220 2018-07-19T08:49:05  *** grafcaps has joined #bitcoin-core-dev
221 2018-07-19T08:49:08  *** promag has quit IRC
222 2018-07-19T08:53:18  *** promag has joined #bitcoin-core-dev
223 2018-07-19T08:53:21  *** grafcaps has quit IRC
224 2018-07-19T08:54:32  *** promag has quit IRC
225 2018-07-19T09:02:21  *** SopaXorzTaker has joined #bitcoin-core-dev
226 2018-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.
227 2018-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
228 2018-07-19T09:06:38  <provoostenator> reconsiderblock did the trick and now it's happy again
229 2018-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 :-)
230 2018-07-19T09:21:30  *** narodnik has joined #bitcoin-core-dev
231 2018-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".
232 2018-07-19T09:27:20  <kallewoof> Sure the hardware isn't broken?
233 2018-07-19T09:27:36  <provoostenator> I'm sure the hardware _is_ broken.
234 2018-07-19T09:27:47  <kallewoof> ok
235 2018-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.
236 2018-07-19T09:31:15  *** vicenteH has quit IRC
237 2018-07-19T09:31:57  *** vicenteH has joined #bitcoin-core-dev
238 2018-07-19T09:36:49  *** SopaXT has joined #bitcoin-core-dev
239 2018-07-19T09:37:07  *** SopaXorzTaker has quit IRC
240 2018-07-19T09:37:09  *** SopaXT is now known as SopaXorzTaker
241 2018-07-19T09:38:46  *** SopaXT has joined #bitcoin-core-dev
242 2018-07-19T09:43:18  *** face has joined #bitcoin-core-dev
243 2018-07-19T09:48:33  *** SopaXT has quit IRC
244 2018-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
245 2018-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
246 2018-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
247 2018-07-19T09:58:18  *** promag has joined #bitcoin-core-dev
248 2018-07-19T10:08:55  *** promag has quit IRC
249 2018-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
250 2018-07-19T10:10:13  *** rafalcpp_ has quit IRC
251 2018-07-19T10:10:58  *** rafalcpp_ has joined #bitcoin-core-dev
252 2018-07-19T10:10:59  *** promag has joined #bitcoin-core-dev
253 2018-07-19T10:20:12  *** ttlloo has joined #bitcoin-core-dev
254 2018-07-19T10:20:20  <ttlloo> s
255 2018-07-19T10:20:35  <ttlloo> getblonkNumber
256 2018-07-19T10:21:03  *** ttlloo has left #bitcoin-core-dev
257 2018-07-19T10:32:23  *** ExtraCrispy has joined #bitcoin-core-dev
258 2018-07-19T10:34:13  *** goatpig has joined #bitcoin-core-dev
259 2018-07-19T10:49:45  *** promag has quit IRC
260 2018-07-19T10:50:59  *** promag has joined #bitcoin-core-dev
261 2018-07-19T10:52:00  *** promag has quit IRC
262 2018-07-19T11:06:20  *** SopaXorzTaker has quit IRC
263 2018-07-19T11:06:52  *** SopaXorzTaker has joined #bitcoin-core-dev
264 2018-07-19T11:13:05  *** Soligor has joined #bitcoin-core-dev
265 2018-07-19T11:16:40  *** promag has joined #bitcoin-core-dev
266 2018-07-19T11:17:56  *** rafalcpp_ is now known as rafalcpp
267 2018-07-19T11:31:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
268 2018-07-19T11:37:26  *** promag has quit IRC
269 2018-07-19T11:39:41  *** dqx_ has quit IRC
270 2018-07-19T11:41:46  *** dqx_ has joined #bitcoin-core-dev
271 2018-07-19T11:42:02  *** promag has joined #bitcoin-core-dev
272 2018-07-19T11:48:35  *** bitconner has quit IRC
273 2018-07-19T11:51:16  *** face has quit IRC
274 2018-07-19T11:55:00  *** face has joined #bitcoin-core-dev
275 2018-07-19T12:00:26  *** face has quit IRC
276 2018-07-19T12:00:34  *** face has joined #bitcoin-core-dev
277 2018-07-19T12:01:48  *** face has quit IRC
278 2018-07-19T12:01:55  *** face has joined #bitcoin-core-dev
279 2018-07-19T12:06:05  *** dqx_ has quit IRC
280 2018-07-19T12:09:57  *** face has quit IRC
281 2018-07-19T12:10:08  *** face has joined #bitcoin-core-dev
282 2018-07-19T12:10:09  *** Chris_Stewart_5 has quit IRC
283 2018-07-19T12:10:29  *** face has quit IRC
284 2018-07-19T12:10:38  *** face has joined #bitcoin-core-dev
285 2018-07-19T12:11:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
286 2018-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
287 2018-07-19T12:17:48  *** Chris_Stewart_5 has quit IRC
288 2018-07-19T12:19:41  *** promag has quit IRC
289 2018-07-19T12:20:00  *** promag has joined #bitcoin-core-dev
290 2018-07-19T12:20:09  *** Guyver2 has quit IRC
291 2018-07-19T12:25:22  *** grafcaps has joined #bitcoin-core-dev
292 2018-07-19T12:25:56  *** promag has quit IRC
293 2018-07-19T12:29:46  *** grafcaps has quit IRC
294 2018-07-19T12:32:55  *** dqx_ has joined #bitcoin-core-dev
295 2018-07-19T12:35:53  *** bitconner has joined #bitcoin-core-dev
296 2018-07-19T12:40:40  *** bitconner has quit IRC
297 2018-07-19T12:42:32  *** un1c0d3r has joined #bitcoin-core-dev
298 2018-07-19T12:45:46  *** promag has joined #bitcoin-core-dev
299 2018-07-19T12:46:56  *** BashCo has quit IRC
300 2018-07-19T12:54:51  *** un1c0d3r has quit IRC
301 2018-07-19T12:59:51  *** promag has quit IRC
302 2018-07-19T13:08:36  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4a3e8c5aa6a5...e1260a798d10
303 2018-07-19T13:08:36  <bitcoin-git> bitcoin/master ea5340c marcoagner: tests: fixes mininode's P2PConnection sending messages on closing transport...
304 2018-07-19T13:08:37  <bitcoin-git> bitcoin/master e1260a7 MarcoFalke: Merge #13715: tests: fixes mininode's P2PConnection sending messages on closing transport...
305 2018-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
306 2018-07-19T13:19:55  *** texan136 has joined #bitcoin-core-dev
307 2018-07-19T13:20:06  *** texan136 has left #bitcoin-core-dev
308 2018-07-19T13:21:01  *** d9b4bef9 has quit IRC
309 2018-07-19T13:22:08  *** d9b4bef9 has joined #bitcoin-core-dev
310 2018-07-19T13:26:03  *** BashCo has joined #bitcoin-core-dev
311 2018-07-19T13:30:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
312 2018-07-19T13:36:11  *** bitconner has joined #bitcoin-core-dev
313 2018-07-19T13:36:49  *** harrymm has quit IRC
314 2018-07-19T13:39:34  *** grafcaps has joined #bitcoin-core-dev
315 2018-07-19T13:40:50  *** harrymm has joined #bitcoin-core-dev
316 2018-07-19T13:41:19  *** bitconner has quit IRC
317 2018-07-19T13:49:00  *** grafcaps has quit IRC
318 2018-07-19T13:51:14  *** farmerwampum has joined #bitcoin-core-dev
319 2018-07-19T13:52:34  *** un1c0d3r has joined #bitcoin-core-dev
320 2018-07-19T13:57:28  *** AaronvanW has joined #bitcoin-core-dev
321 2018-07-19T14:04:01  *** grafcaps has joined #bitcoin-core-dev
322 2018-07-19T14:05:25  <wumpus> rc2 executables up https://bitcoincore.org/bin/bitcoin-core-0.16.2/test.rc2/
323 2018-07-19T14:10:36  *** grafcaps has quit IRC
324 2018-07-19T14:11:21  *** dqx_ has quit IRC
325 2018-07-19T14:16:36  *** dqx_ has joined #bitcoin-core-dev
326 2018-07-19T14:24:01  *** grafcaps has joined #bitcoin-core-dev
327 2018-07-19T14:25:07  *** dqx_ has quit IRC
328 2018-07-19T14:25:45  *** dqx_ has joined #bitcoin-core-dev
329 2018-07-19T14:28:43  *** Aaronvan_ has joined #bitcoin-core-dev
330 2018-07-19T14:31:30  *** dqx_ has quit IRC
331 2018-07-19T14:31:51  *** AaronvanW has quit IRC
332 2018-07-19T14:42:55  *** Aaronvan_ has quit IRC
333 2018-07-19T14:48:58  *** texan136 has joined #bitcoin-core-dev
334 2018-07-19T14:50:58  *** texan136 has left #bitcoin-core-dev
335 2018-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
336 2018-07-19T14:53:44  *** AaronvanW has joined #bitcoin-core-dev
337 2018-07-19T14:53:51  *** bitconner has joined #bitcoin-core-dev
338 2018-07-19T14:54:19  *** AaronvanW has quit IRC
339 2018-07-19T14:54:56  *** AaronvanW has joined #bitcoin-core-dev
340 2018-07-19T14:58:29  *** bitconner has quit IRC
341 2018-07-19T14:59:36  *** dqx_ has joined #bitcoin-core-dev
342 2018-07-19T15:00:05  *** promag has joined #bitcoin-core-dev
343 2018-07-19T15:03:33  <promag> sipa: instead of old(pk), could just be pk(...) and add a "backward compability" option to scantxoutset?
344 2018-07-19T15:04:34  <promag> that option could be per descriptor
345 2018-07-19T15:06:32  *** Guyver2 has joined #bitcoin-core-dev
346 2018-07-19T15:08:10  *** AaronvanW has quit IRC
347 2018-07-19T15:08:40  *** AaronvanW has joined #bitcoin-core-dev
348 2018-07-19T15:17:41  *** harrymm has quit IRC
349 2018-07-19T15:19:55  *** AaronvanW has quit IRC
350 2018-07-19T15:20:30  *** AaronvanW has joined #bitcoin-core-dev
351 2018-07-19T15:23:35  *** dqx_ has quit IRC
352 2018-07-19T15:24:50  *** AaronvanW has quit IRC
353 2018-07-19T15:26:33  *** dqx_ has joined #bitcoin-core-dev
354 2018-07-19T15:30:36  *** AaronvanW has joined #bitcoin-core-dev
355 2018-07-19T15:35:14  *** AaronvanW has quit IRC
356 2018-07-19T15:35:40  *** harrymm has joined #bitcoin-core-dev
357 2018-07-19T15:36:45  <promag> sipa: I mean, instead of providing a descriptor for the old behaviour, add an option to support that behaviour
358 2018-07-19T15:38:20  *** dqx_ has quit IRC
359 2018-07-19T15:39:19  *** justanotheruser has quit IRC
360 2018-07-19T15:40:50  *** harrymm has quit IRC
361 2018-07-19T15:42:31  <provoostenator> Coolest error message ever: *** stack smashing detected ***: <unknown> terminated
362 2018-07-19T15:46:14  *** wumpus_ has joined #bitcoin-core-dev
363 2018-07-19T15:46:25  *** dqx_ has joined #bitcoin-core-dev
364 2018-07-19T15:47:29  *** ken2812221 has joined #bitcoin-core-dev
365 2018-07-19T15:48:17  *** wumpus has quit IRC
366 2018-07-19T15:48:45  *** belcher has joined #bitcoin-core-dev
367 2018-07-19T15:49:04  *** wumpus_ is now known as wumpus
368 2018-07-19T15:49:24  *** pierre_rochard has joined #bitcoin-core-dev
369 2018-07-19T15:50:52  *** bitconner has joined #bitcoin-core-dev
370 2018-07-19T15:56:29  *** Guest26115 has quit IRC
371 2018-07-19T15:56:41  *** ken2812221_ has joined #bitcoin-core-dev
372 2018-07-19T15:57:33  *** harrymm has joined #bitcoin-core-dev
373 2018-07-19T16:04:13  *** ken2812221_ has quit IRC
374 2018-07-19T16:19:09  *** AaronvanW has joined #bitcoin-core-dev
375 2018-07-19T16:28:52  *** str4d has joined #bitcoin-core-dev
376 2018-07-19T16:33:38  *** arubi has quit IRC
377 2018-07-19T16:34:06  *** arubi has joined #bitcoin-core-dev
378 2018-07-19T16:36:46  *** SopaXorzTaker has quit IRC
379 2018-07-19T16:38:31  *** bitconne1 has joined #bitcoin-core-dev
380 2018-07-19T16:41:10  *** bitconner has quit IRC
381 2018-07-19T16:49:27  *** dqx_ has quit IRC
382 2018-07-19T16:50:27  *** dqx_ has joined #bitcoin-core-dev
383 2018-07-19T16:55:35  *** dqx_ has quit IRC
384 2018-07-19T16:57:44  *** dqx_ has joined #bitcoin-core-dev
385 2018-07-19T17:07:12  *** ken2812221_ has joined #bitcoin-core-dev
386 2018-07-19T17:07:27  *** ken2812221 has quit IRC
387 2018-07-19T17:12:33  *** AaronvanW has quit IRC
388 2018-07-19T17:13:09  *** AaronvanW has joined #bitcoin-core-dev
389 2018-07-19T17:13:41  *** Guyver2 has quit IRC
390 2018-07-19T17:17:50  *** AaronvanW has quit IRC
391 2018-07-19T17:26:29  *** ken2812221_ is now known as ken2812221
392 2018-07-19T17:33:26  *** vicenteH has quit IRC
393 2018-07-19T17:34:01  *** vicenteH has joined #bitcoin-core-dev
394 2018-07-19T17:37:09  *** str4d has quit IRC
395 2018-07-19T17:40:59  *** timothy has quit IRC
396 2018-07-19T17:41:33  *** Krellan has joined #bitcoin-core-dev
397 2018-07-19T17:46:46  *** str4d has joined #bitcoin-core-dev
398 2018-07-19T17:55:34  *** Krellan has quit IRC
399 2018-07-19T17:56:17  *** drexl has joined #bitcoin-core-dev
400 2018-07-19T17:56:44  *** yadev has joined #bitcoin-core-dev
401 2018-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.
402 2018-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.
403 2018-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 :)
404 2018-07-19T18:00:54  <arubi> s/sighash_single/sighash_single bug/
405 2018-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
406 2018-07-19T18:05:57  <MarcoFalke> jonasschnelli: Looks like the nightly builds are down? https://bitcoin.jonasschnelli.ch/build/698
407 2018-07-19T18:10:44  <jonasschnelli> MarcoFalke: looks like. thanks for reporting... I'll investigate
408 2018-07-19T18:14:17  <MarcoFalke> Thx!
409 2018-07-19T18:17:43  <sipa> jonasschnelli: please have a look at #13697
410 2018-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
411 2018-07-19T18:20:15  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1260a798d10...8c3643279165
412 2018-07-19T18:20:15  <bitcoin-git> bitcoin/master a4ba238 Lawrence Nahum: depends: disable Werror for zmqlib release, causes ndk build to break
413 2018-07-19T18:20:16  <bitcoin-git> bitcoin/master 8c36432 MarcoFalke: Merge #13689: depends: disable Werror when building zmq...
414 2018-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
415 2018-07-19T18:20:58  <gmaxwell> I didn't understand your sighash single claim myself.
416 2018-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
417 2018-07-19T18:21:20  <gmaxwell> since it's signing a constant, why would the data going into the sighash matter?
418 2018-07-19T18:21:53  *** dqx_ has quit IRC
419 2018-07-19T18:22:44  <sipa> gmaxwell: uh, yes
420 2018-07-19T18:22:46  <sipa> of course :)
421 2018-07-19T18:22:55  <arubi> phew :)
422 2018-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
423 2018-07-19T18:25:01  <gmaxwell> arubi: or not
424 2018-07-19T18:25:30  <gmaxwell> I think it's silly to speculate on, without testing no one really knows
425 2018-07-19T18:25:34  <jonasschnelli> sipa: Oh. Nice... will have a look soon!
426 2018-07-19T18:25:35  <sipa> oh, of course
427 2018-07-19T18:25:36  *** yadev has quit IRC
428 2018-07-19T18:25:54  <sipa> arubi: i don't think that works
429 2018-07-19T18:26:10  <gmaxwell> arubi: e.g. perhaps any case you could construct to do that fails because earlier deserialization will fail.
430 2018-07-19T18:27:03  <sipa> arubi: for it to be valid post-fork, pushes/opcodes need to align with the scriptSig end
431 2018-07-19T18:27:03  <arubi> hm, yea..  pushdata in scriptsig without enough bytes to glob fails..  right
432 2018-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
433 2018-07-19T18:27:46  <arubi> you could with op_swap
434 2018-07-19T18:27:54  <arubi> or well, just op checksig right?
435 2018-07-19T18:28:04  <arubi> ah again, findanddelete removes it..
436 2018-07-19T18:28:22  <sipa> ah yes
437 2018-07-19T18:28:57  <sipa> doesn't findanddelete save us?
438 2018-07-19T18:30:24  *** dqx_ has joined #bitcoin-core-dev
439 2018-07-19T18:32:14  <arubi> it almost seems like any signing shenanigans are out of the question.  definitely gonna be busy thinking about this :)
440 2018-07-19T18:32:14  *** str4d has quit IRC
441 2018-07-19T18:32:43  *** riemann_ has joined #bitcoin-core-dev
442 2018-07-19T18:32:55  *** str4d has joined #bitcoin-core-dev
443 2018-07-19T18:36:23  *** ExtraCrispy has quit IRC
444 2018-07-19T18:36:30  *** dqx_ has quit IRC
445 2018-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
446 2018-07-19T18:37:06  <sipa> is it not possible to create such a scriptSig now, due to FindAndDelete?
447 2018-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?
448 2018-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)
449 2018-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"
450 2018-07-19T18:41:52  <arubi> why?  1 is scriptpubkey, isn't it in sighash?
451 2018-07-19T18:41:59  <arubi> err, 1 == op_true
452 2018-07-19T18:42:24  *** AaronvanW has joined #bitcoin-core-dev
453 2018-07-19T18:42:29  <sipa> pre-fork the executed script was "<sig> <pubkey> CHECKSIG CODESEP TRUE"
454 2018-07-19T18:42:53  <arubi> yes, no codeseps to the left of checksig, the one on the right is removed
455 2018-07-19T18:43:18  <sipa> i don't understand what you're disagreeing with
456 2018-07-19T18:43:24  *** reallll has joined #bitcoin-core-dev
457 2018-07-19T18:43:54  <arubi> I don't understand why you'd not be signing op_true post fork
458 2018-07-19T18:44:00  *** reallll has quit IRC
459 2018-07-19T18:44:28  <arubi> ohhh
460 2018-07-19T18:44:29  <sipa> because it's in a different script?
461 2018-07-19T18:44:33  <arubi> yes!
462 2018-07-19T18:47:10  *** belcher has quit IRC
463 2018-07-19T18:47:22  *** dqx_ has joined #bitcoin-core-dev
464 2018-07-19T18:51:27  *** lclc has joined #bitcoin-core-dev
465 2018-07-19T19:00:27  <sipa> DING
466 2018-07-19T19:01:24  <jonasschnelli> DONG
467 2018-07-19T19:01:25  * cfields hits snooze
468 2018-07-19T19:02:03  <wumpus> #startmeeting
469 2018-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.
470 2018-07-19T19:02:03  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
471 2018-07-19T19:02:06  <provoostenator> hi
472 2018-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
473 2018-07-19T19:02:22  <kanzure> hi.
474 2018-07-19T19:02:26  <jonasschnelli> hu
475 2018-07-19T19:02:29  <achow101> hi
476 2018-07-19T19:02:32  <cfields> hi
477 2018-07-19T19:02:35  <sipa> ho
478 2018-07-19T19:02:46  *** Krellan has joined #bitcoin-core-dev
479 2018-07-19T19:03:00  <wumpus> PSA: 0.16.2rc2 executables have been uploaded today and announcement sent
480 2018-07-19T19:03:25  <jonasschnelli> thanks wumpus
481 2018-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
482 2018-07-19T19:04:03  <sipa> 4 days and ticking...
483 2018-07-19T19:04:05  <wumpus> although we maerged a view
484 2018-07-19T19:04:15  <wumpus> few*
485 2018-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>
486 2018-07-19T19:04:25  <wumpus> cfields: I voted
487 2018-07-19T19:04:25  <jonasschnelli> I'd like to see #9662 merged...
488 2018-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
489 2018-07-19T19:04:32  <jonasschnelli> (has >5 acks)
490 2018-07-19T19:04:42  <cfields> wumpus: thanks :)
491 2018-07-19T19:04:49  <wumpus> jonasschnelli: let's do it then
492 2018-07-19T19:04:51  *** Guest26115 has joined #bitcoin-core-dev
493 2018-07-19T19:05:09  <achow101> topic suggestion: exposing coin selection (or other possibly more internal things) as rpcs
494 2018-07-19T19:05:21  <jonasschnelli> #9502 has also a couple of acks and waits for a final review from cfields
495 2018-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
496 2018-07-19T19:05:29  <jonasschnelli> (was originally tagged for 0.17)
497 2018-07-19T19:05:37  <sipa> i also want to bring up #13697 which changes the API for scantxoutset
498 2018-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
499 2018-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)
500 2018-07-19T19:05:53  <cfields> jonasschnelli: oh! sorry, will take a look right after the meeting
501 2018-07-19T19:06:00  <jonasschnelli> thanks cfields
502 2018-07-19T19:06:10  <jonasschnelli> I think sipas 13697 should be added to the high prio list
503 2018-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
504 2018-07-19T19:06:20  <provoostenator> non-positional
505 2018-07-19T19:06:22  <jonasschnelli> (since it's an API thing)
506 2018-07-19T19:06:24  *** laurentmt has joined #bitcoin-core-dev
507 2018-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)
508 2018-07-19T19:06:43  *** ken2812221_ has joined #bitcoin-core-dev
509 2018-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
510 2018-07-19T19:06:59  <jonasschnelli> Or that, yes.
511 2018-07-19T19:07:10  <wumpus> everything that needs to go into 0.17 is high-priority by definition
512 2018-07-19T19:07:10  *** ken2812221 has quit IRC
513 2018-07-19T19:07:20  <jnewbery> in general I think it's a sensible default policy to mark new APIs as experimental
514 2018-07-19T19:07:25  <wumpus> (although some things are taggd 0.17 that shouldn't be,I tihnk)
515 2018-07-19T19:07:34  <sipa> what about #13666 ?
516 2018-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
517 2018-07-19T19:07:52  <provoostenator> What's in a number?
518 2018-07-19T19:08:01  <sipa> 13 and 666, can't beat those odds
519 2018-07-19T19:08:17  <wumpus> niice
520 2018-07-19T19:08:35  <achow101> it was completely planned, obviously
521 2018-07-19T19:08:40  <ken2812221_> Could #13426 be tagged for 0.17?
522 2018-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
523 2018-07-19T19:08:45  <sipa> in some timezones it was also opened on friday the 13th
524 2018-07-19T19:09:03  <sipa> oh, no
525 2018-07-19T19:09:20  <jonasschnelli> I hope no black cat was sitting on the keyboard during coding
526 2018-07-19T19:09:20  <wumpus> ken2812221_: done
527 2018-07-19T19:09:32  <ken2812221_> thanks
528 2018-07-19T19:09:50  <sipa> if it is a bugfix it can also go in after the feature freeze
529 2018-07-19T19:10:01  <wumpus> tagged 13666 13426 and 13697 with 0.17
530 2018-07-19T19:10:06  <wumpus> absolutely
531 2018-07-19T19:10:26  *** laurentmt has quit IRC
532 2018-07-19T19:10:34  <sipa> 12 PRs tagged 0.17 :o
533 2018-07-19T19:10:44  * sipa fires up the review engine
534 2018-07-19T19:10:44  <achow101> #13712 is a bug fix for 0.17 too
535 2018-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
536 2018-07-19T19:10:53  <jonasschnelli> Looks like #8469 won't make it for 0.17. I guess untag would make sense
537 2018-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
538 2018-07-19T19:11:08  <wumpus> jonasschnelli: yes will remove that one
539 2018-07-19T19:11:41  <jonasschnelli> Also #13617 (I like, but to wip-ish for the timing of 0.17)
540 2018-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
541 2018-07-19T19:11:53  <wumpus> and added 13712
542 2018-07-19T19:12:22  <wumpus> jonasschnelli: ok
543 2018-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
544 2018-07-19T19:13:15  <sipa> #13617
545 2018-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
546 2018-07-19T19:13:56  <jonasschnelli> Oh. Right... it's not a feature... agree with cfields
547 2018-07-19T19:14:02  *** booyah has quit IRC
548 2018-07-19T19:14:08  <wumpus> re-add it then?
549 2018-07-19T19:14:20  <jonasschnelli> Yes. I'll do it. Sry for the confusion
550 2018-07-19T19:14:48  *** AaronvanW has quit IRC
551 2018-07-19T19:15:00  <wumpus> no problem
552 2018-07-19T19:15:11  <wumpus> #topic exposing coin selection on RPC (achow101)
553 2018-07-19T19:15:22  <gmaxwell> What does that mean precisely?
554 2018-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
555 2018-07-19T19:15:54  <wumpus> I'd say listunspent+raw transactions API
556 2018-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
557 2018-07-19T19:16:17  <wumpus> fundrawtransaction?
558 2018-07-19T19:16:17  <achow101> that is not ideal for them
559 2018-07-19T19:16:17  <jonasschnelli> achow101: hmm,... is RPC the right interface for that?`
560 2018-07-19T19:16:22  *** dqx_ has quit IRC
561 2018-07-19T19:16:28  <sipa> i suggested to achow101 that a library might be a better way of doing so
562 2018-07-19T19:16:31  <gmaxwell> but again what does that mean.  like isn't fun-draw-transaction that?
563 2018-07-19T19:16:31  <jonasschnelli> Right.. what wumpus said
564 2018-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
565 2018-07-19T19:16:46  <sipa> gmaxwell: they don't want to use the wallet; they just want to be able to run coin selection
566 2018-07-19T19:16:51  <wumpus> you can import utxos into the wallet with importprunedfunds
567 2018-07-19T19:16:53  <achow101> wumpus: fundrawtransaction requires the wallet
568 2018-07-19T19:17:03  <jonasschnelli> achow101: using private key disabled dynamic wallet in conjunction with fundraw seems very efficient
569 2018-07-19T19:17:08  <gmaxwell> I am doubtful that it is worth our effort in maintaining a stable interface for such a thing.
570 2018-07-19T19:17:11  <achow101> wumpus: that's probably slow with hundreds of thousands of utxos
571 2018-07-19T19:17:11  <wumpus> meh, RPC is not a good place for pure utility functions
572 2018-07-19T19:17:26  <wumpus> if it doesn't need the wallet nor core state, why have it on *remote* procedure call?
573 2018-07-19T19:17:26  <gmaxwell> E.g. kallewoof's recent grouping PR would have obliterated the interface for coin selection.
574 2018-07-19T19:17:46  *** clarkmoody has joined #bitcoin-core-dev
575 2018-07-19T19:17:53  <wumpus> it just creates a central point of faliure for no good reason
576 2018-07-19T19:18:03  <wumpus> a library indeed sounds like a better idea
577 2018-07-19T19:18:04  <jonasschnelli> Agree with wumpus.
578 2018-07-19T19:18:12  *** dqx_ has joined #bitcoin-core-dev
579 2018-07-19T19:18:27  <jonasschnelli> I know a library would be cumbersome to implement (compared to RPC),... but that is a weak argument IMO
580 2018-07-19T19:18:27  <wumpus> RPC is not a good way to do code sharing
581 2018-07-19T19:18:39  <sipa> it sounded like people really like RPC interfaces over libraries though, for reason i have difficulty comprehending
582 2018-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
583 2018-07-19T19:18:54  <sipa> but one possibility would be to have a separate binary with utility functions, that exposes an RPC
584 2018-07-19T19:19:00  <gmaxwell> its just the webby world.
585 2018-07-19T19:19:03  <wumpus> I don't get it
586 2018-07-19T19:19:06  <achow101> and they seemed to like rpcs where things are easily dropped in
587 2018-07-19T19:19:08  <wumpus> I don't want to debate this madness
588 2018-07-19T19:19:12  <gmaxwell> achow101: C(++) is callable from every language.... :P
589 2018-07-19T19:19:21  <jonasschnelli> Wild though: provide a cli tool?
590 2018-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
591 2018-07-19T19:19:25  <gmaxwell> (well C is, C++ via making a C interface. :) )
592 2018-07-19T19:19:27  <jonasschnelli> *thought
593 2018-07-19T19:19:28  <sipa> jonasschnelli: slow
594 2018-07-19T19:19:41  <gmaxwell> but in any case, if you have a library you can also wrap that to present an RPC.
595 2018-07-19T19:19:44  <jonasschnelli> (a library & a CLI tool for the lazy people)
596 2018-07-19T19:19:51  <wumpus> cli also a 'remote' call, though it invokes a new process for every call!
597 2018-07-19T19:19:57  <wumpus> but it has the same issues with (de)serialization
598 2018-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.
599 2018-07-19T19:20:20  <wumpus> right
600 2018-07-19T19:20:24  <jonasschnelli> indeed... if performance is the goal, a library is probably the right choice.
601 2018-07-19T19:20:26  <sipa> i think coin selection is relatively well encapsulated
602 2018-07-19T19:20:46  <sipa> i also don't see how kallewoof's groupings would break the API
603 2018-07-19T19:20:47  <gmaxwell> sipa: I just gave an example where recent changes changed the API substantailly.
604 2018-07-19T19:21:05  <gmaxwell> Both BNB and kallewoof changed arguments to every entry point.
605 2018-07-19T19:21:18  <wumpus> to be honest I think this is not a concern for our project
606 2018-07-19T19:21:21  <achow101> gmaxwell: but the interface exposed to the callers did not
607 2018-07-19T19:21:26  <sipa> so? overall it takes a list of UTXOs and gives a subset back
608 2018-07-19T19:21:41  <wumpus> some other people want a coin selection algorithm for their own purposes
609 2018-07-19T19:21:58  <achow101> gmaxwell: only things within selectcoins changed, and an rpc would effectively only expose selectcoins
610 2018-07-19T19:22:00  <wumpus> it's fine, they can make a library out of it themselves
611 2018-07-19T19:22:05  <gmaxwell> it's more tightly coupled than "list of UTXOs" ... e.g. it needs fees, signature sizes.
612 2018-07-19T19:22:09  <wumpus> the code is open source
613 2018-07-19T19:22:52  <gmaxwell> I mean if someone can jigger things around to make it seperable and they find that useful, fantastic.
614 2018-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.
615 2018-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"
616 2018-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
617 2018-07-19T19:23:08  <jonasschnelli> wumpus: I think what they want is something maintained by the same people
618 2018-07-19T19:23:22  <wumpus> jonasschnelli: the same people might not agree with that, who asks them?!
619 2018-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
620 2018-07-19T19:23:39  <wumpus> they might want the whole world to be maintained by the same people
621 2018-07-19T19:23:52  <jonasschnelli> heh...
622 2018-07-19T19:24:14  *** booyah has joined #bitcoin-core-dev
623 2018-07-19T19:24:38  <wumpus> gmaxwell: right, exactly
624 2018-07-19T19:24:57  *** laurentmt has joined #bitcoin-core-dev
625 2018-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
626 2018-07-19T19:25:27  *** riemann_ has quit IRC
627 2018-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
628 2018-07-19T19:26:00  <wumpus> but making internal interfaces stable does restrict future flexibilty, as gmaxwell says
629 2018-07-19T19:26:11  <wumpus> it's already hard enough to change the RPC interface
630 2018-07-19T19:26:54  <wumpus> I understand the desire for that, bt puttingn that all on our plate is unreasonable
631 2018-07-19T19:27:00  <wumpus> as well as centralization
632 2018-07-19T19:27:30  *** laurentmt has quit IRC
633 2018-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
634 2018-07-19T19:28:10  <achow101> right
635 2018-07-19T19:28:21  <moneyball> suggested topic: next Core dev tech meetup
636 2018-07-19T19:28:45  <jnewbery> wumpus: there is some benefit to making the Core coin selection algorithm more generally usable though
637 2018-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
638 2018-07-19T19:29:16  <jnewbery> eg if we think it's good and reduces UTXO bloat, having more people using it is a benefit
639 2018-07-19T19:29:35  <wumpus> if it turns out to be feasible enough then core can start using that library too
640 2018-07-19T19:29:43  <wumpus> that's a two-step process, though
641 2018-07-19T19:29:52  <sipa> i think the first step for this is something we're doing anyway; making the code itself more encapsulated
642 2018-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...
643 2018-07-19T19:30:01  <sipa> no it's not
644 2018-07-19T19:30:05  <jonasschnelli> The burden is the maintenance...
645 2018-07-19T19:30:08  <sipa> it's currently split between wallet code and coinselection
646 2018-07-19T19:30:12  <wumpus> jonasschnelli: I doubt it's that easy
647 2018-07-19T19:30:13  <sipa> and that's improving
648 2018-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
649 2018-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
650 2018-07-19T19:31:00  <sipa> i think it's great to hear there is interest in code we're writing
651 2018-07-19T19:31:10  <jnewbery> sipa: +1
652 2018-07-19T19:31:16  <wumpus> sipa: so in as far as that helps our own maintainability of the walletcode, that's a good thing
653 2018-07-19T19:31:58  <sipa> wumpus: perhaps once the code is sufficiently encapsulated, someone else can librarify that and maintain it
654 2018-07-19T19:32:06  *** LukeJr has joined #bitcoin-core-dev
655 2018-07-19T19:32:07  <wumpus> right
656 2018-07-19T19:33:12  <wumpus> #topic #13697 which changes the API for scantxoutset
657 2018-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
658 2018-07-19T19:33:16  <wumpus> (sipa)
659 2018-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
660 2018-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
661 2018-07-19T19:34:27  <wumpus> yes that is very neat
662 2018-07-19T19:34:58  <sipa> https://github.com/sipa/bitcoin/blob/895a46d83550838a8170ccba075367232eabbd8c/src/script/descriptor.h#L9L68
663 2018-07-19T19:35:22  <jonasschnelli> I really like it. Will review and test it asap!
664 2018-07-19T19:36:00  <sipa> the other question is scantxoutset experimental or not, and with descriptor support in 0.17 or not
665 2018-07-19T19:36:03  <jonasschnelli> What is the difference between the FlatSigningProvider and the dummysigner?
666 2018-07-19T19:36:24  <sipa> dummysignatureprovider doesn't provide anything
667 2018-07-19T19:36:39  <sipa> flatisigningprovider takes its information from flat maps
668 2018-07-19T19:36:53  <jonasschnelli> I see
669 2018-07-19T19:37:00  <wumpus> I think scantxout should be marked experimental
670 2018-07-19T19:37:05  <jonasschnelli> Agree
671 2018-07-19T19:37:14  <jonasschnelli> Also with 13697...
672 2018-07-19T19:37:18  <sipa> agree
673 2018-07-19T19:37:22  <jonasschnelli> Helps us to do unplaned API changed
674 2018-07-19T19:37:34  <jonasschnelli> *changes
675 2018-07-19T19:37:35  <wumpus> right
676 2018-07-19T19:37:49  <sipa> i plan to write a longer explanation in doc/descriptors.md or so
677 2018-07-19T19:38:11  <wumpus> cool
678 2018-07-19T19:38:21  <jonasschnelli> thanks for working on this sipa
679 2018-07-19T19:38:23  <sipa> one of the future ideas is a PSBT standalone binary that can sign/update using descriptors
680 2018-07-19T19:38:34  <luke-jr> should these be a BIP? seems potentially useful outside Core
681 2018-07-19T19:38:45  <sipa> luke-jr: potentially yes, but not in first instance
682 2018-07-19T19:38:53  <sipa> i expect that this will evolve rather quickly
683 2018-07-19T19:39:11  <luke-jr> BIP drafts can evolve :p
684 2018-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
685 2018-07-19T19:39:34  <wumpus> luke-jr: let's just leave it up to sipa
686 2018-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
687 2018-07-19T19:40:00  <sipa> compability would certainly be useful too, but i'd rather take some time to see how things evolve
688 2018-07-19T19:40:23  <sipa> otherwise i fear we'll have something with a dozen optional parts all implemented by different subsets of software
689 2018-07-19T19:40:34  <wumpus> yes
690 2018-07-19T19:41:28  <wumpus> #topic bitcoin-seeder under bitcoin-core GitHub organisation (lclc)
691 2018-07-19T19:41:49  <sipa> lclc: no problem as far as I'm concerned, but i'm not sure it's the right message
692 2018-07-19T19:41:52  <luke-jr> Seems unnecessary.
693 2018-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.
694 2018-07-19T19:42:04  <sipa> there are other pieces of seeder software out there too, and having variety is a good thing here
695 2018-07-19T19:42:16  <luke-jr> should we put bfgminer, knots, kallewoof's script debugger stuff, etc under bitcoin-core too? :p
696 2018-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.
697 2018-07-19T19:42:29  <wumpus> luke-jr: if they want
698 2018-07-19T19:42:43  <luke-jr> wumpus: what sipa said - it sends the wrong msg IMO
699 2018-07-19T19:43:09  <wumpus> yes, to be clear I don't think it's necessary
700 2018-07-19T19:43:20  <provoostenator> Another approach could be for sipa to give more people access to that repo?
701 2018-07-19T19:43:22  <jonasschnelli> No strong opinion... but slighly prefere to have it under the bitcoin-core repository
702 2018-07-19T19:43:23  <luke-jr> although maybe it would make sense for knots, but that would probably just be a mess on github
703 2018-07-19T19:43:32  <luke-jr> provoostenator: +1
704 2018-07-19T19:43:40  <luke-jr> to sipa giving access as desired
705 2018-07-19T19:43:41  <sipa> provoostenator: i'm fine with that!
706 2018-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'
707 2018-07-19T19:43:53  <provoostenator> Or create an ad hoc organization "Sipa's DNS Seed maintainer club"
708 2018-07-19T19:43:55  *** bitconne1 has quit IRC
709 2018-07-19T19:43:59  <wumpus> so agree with you on that luke-jr
710 2018-07-19T19:44:09  <luke-jr> there's no reason to turn access to tht eCore github repo ainto an actual position
711 2018-07-19T19:44:13  <luke-jr> forgive the typos
712 2018-07-19T19:45:09  *** bitconner has joined #bitcoin-core-dev
713 2018-07-19T19:45:11  <lclc> That's also fine with me
714 2018-07-19T19:45:14  <achow101> topic suggestion: moving away from bitcoin.org more
715 2018-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
716 2018-07-19T19:46:06  <wumpus> #topic moving away from bitcoin.org more (achow101)
717 2018-07-19T19:46:12  <luke-jr> not sure there's anything further we can do in terms of oving away..?
718 2018-07-19T19:46:18  <achow101> we still link to bitcoin.org for things like downloads
719 2018-07-19T19:46:20  <wumpus> achow101: moving what, excatly? executables have been moved
720 2018-07-19T19:46:22  <achow101> should probably change those
721 2018-07-19T19:46:24  <jonasschnelli> I'm pretty familiar with the seeder code and happy to co-maintain it
722 2018-07-19T19:46:26  <wumpus> achow101: where?
723 2018-07-19T19:46:27  <luke-jr> achow101: where?
724 2018-07-19T19:46:31  <achow101> in the readme
725 2018-07-19T19:46:36  <jnewbery> I don't think we link to bitcoin.org for downloads any more
726 2018-07-19T19:46:46  <wumpus> at least in the release mail I link to bitcoincore.org nowadays
727 2018-07-19T19:47:13  <moneyball> suggested topic: next Core dev tech meetup :)
728 2018-07-19T19:47:15  <sipa> For more information, as well as an immediately useable, binary version of
729 2018-07-19T19:47:15  <provoostenator> And there's guiconstants.h: QAPP_ORG_DOMAIN "bitcoin.org"
730 2018-07-19T19:47:18  <sipa> the Bitcoin Core software, see https://bitcoin.org/en/download
731 2018-07-19T19:47:19  <jnewbery> Open a PR to remove that link from the readme. I will happily ACK
732 2018-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
733 2018-07-19T19:47:29  <wumpus> I think the link to bitcoin.org is only for the *general* descriptoin of bitcoin
734 2018-07-19T19:47:35  <wumpus> that certainly would be confusing to make bitcoincore.or
735 2018-07-19T19:47:39  <wumpus> moneyball: yep
736 2018-07-19T19:47:43  <sipa> wumpus: see quote above
737 2018-07-19T19:47:46  <luke-jr> provoostenator: oh yeah, that was an issue for distro stuff somewhere IIRC
738 2018-07-19T19:47:54  <wumpus> sipa: oh yes that should go
739 2018-07-19T19:48:03  <sipa> ack on that in any case
740 2018-07-19T19:48:06  <wumpus> provoostenator: don't change that! it determines the settings path
741 2018-07-19T19:48:08  <luke-jr> provoostenator: might want to make it something generic though, not Core-specific
742 2018-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
743 2018-07-19T19:48:52  <luke-jr> wumpus: I think it's used outside settings too, but maybe best to just leave it alone
744 2018-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
745 2018-07-19T19:49:04  <luke-jr> perhaps a comment explaining it's for compatibility, nothing more
746 2018-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
747 2018-07-19T19:49:31  <wumpus> achow101: would that really make anything better?
748 2018-07-19T19:49:43  <wumpus> achow101: are you seriously suggesting I should no longer update bitcoin.org and upload binaries there?
749 2018-07-19T19:49:55  <achow101> yes
750 2018-07-19T19:50:17  <achow101> wumpus: are you aware of the recent events on bitcoin.org?
751 2018-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.
752 2018-07-19T19:50:42  <wumpus> acvaguely
753 2018-07-19T19:50:42  *** bitconner has quit IRC
754 2018-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"
755 2018-07-19T19:51:06  <wumpus> so I think this will effectively reduce the number of downloads
756 2018-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
757 2018-07-19T19:51:34  <luke-jr> wumpus: Core doesn't have a problem wth getting users atm
758 2018-07-19T19:51:36  <jonasschnelli> I think we should only publish binaries via bitcoincore.org and should not actively push it to other websites...
759 2018-07-19T19:51:47  <luke-jr> >99% of the network runs Core
760 2018-07-19T19:51:47  <jonasschnelli> It's gives a wrong sense of project coupling
761 2018-07-19T19:51:48  <achow101> there's ongoing work to move all of the bitcoin core stuff from bitcoin.org to bitcoincore.org
762 2018-07-19T19:52:21  <wumpus> maybe the developer documentation too
763 2018-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
764 2018-07-19T19:52:48  <luke-jr> (and making it harder to "just run bitcoin.org" seems a step in that direction)
765 2018-07-19T19:53:04  *** Chris_Stewart_5 has quit IRC
766 2018-07-19T19:53:33  <wumpus> #topic next coredev tech meeting (moneyball)
767 2018-07-19T19:54:03  <moneyball> Hi, I wanted to let people know I've volunteered to organize the next Core Dev Tech meetup
768 2018-07-19T19:54:18  <moneyball> The current thinking is to have it in Tokyo in October after Scaling Bitcoin
769 2018-07-19T19:54:22  <luke-jr> thanks
770 2018-07-19T19:54:24  <moneyball> Oct 8-10
771 2018-07-19T19:54:27  <jonasschnelli> thanks moneyball
772 2018-07-19T19:54:30  <wumpus> yes, awesome!
773 2018-07-19T19:54:35  <jonasschnelli> moneyball: please update https://github.com/coredev-tech
774 2018-07-19T19:54:37  <provoostenator> Awesome indeed
775 2018-07-19T19:54:39  <cfields> thanks moneyball :)
776 2018-07-19T19:54:58  <moneyball> And to organize it in a similar fashion as the last one in NYC
777 2018-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
778 2018-07-19T19:55:21  <sipa> nice
779 2018-07-19T19:55:50  <moneyball> I plan to send out a survey to collect some feedback
780 2018-07-19T19:56:07  <moneyball> If anyone has specific ideas or suggestions please feel free to contact me
781 2018-07-19T19:56:59  <moneyball> Nothing more from me about the topic now
782 2018-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
783 2018-07-19T19:57:41  <jonasschnelli> thanks moneyball for organising!
784 2018-07-19T19:57:55  <moneyball> You're welcome happy to help!
785 2018-07-19T19:58:18  <jnewbery> yes, thanks moneyball! Looking forward to it :)
786 2018-07-19T19:59:27  <wumpus> #endmeeting
787 2018-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)
788 2018-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
789 2018-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
790 2018-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
791 2018-07-19T19:59:36  <wumpus> thanks everyone
792 2018-07-19T19:59:38  <achow101> topic suggetion: lunch
793 2018-07-19T19:59:45  <sipa> #lunch
794 2018-07-19T19:59:56  <luke-jr> not breakfast?
795 2018-07-19T20:00:23  <sipa> it will in fact be my first meal of the day
796 2018-07-19T20:00:36  <ken2812221_> for me, it's almost breakfast.4 AM here
797 2018-07-19T20:01:15  <cfields> ken2812221_: you got a link to vote on the meeting time, right?
798 2018-07-19T20:01:37  <ken2812221_> No, I didn't receive the email.
799 2018-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")
800 2018-07-19T20:02:31  <cfields> ken2812221_: hmm. I'll resend. Can you stick around for another minute to vote?
801 2018-07-19T20:02:39  *** lclc has quit IRC
802 2018-07-19T20:03:06  <ken2812221_> ok, thanks
803 2018-07-19T20:04:03  <wumpus> provoostenator: fwiw this is what I use to manually check hidden service connections: https://twitter.com/orionwl/status/1000995421739802624
804 2018-07-19T20:04:09  <cfields> ken2812221_: got that one?
805 2018-07-19T20:04:29  <ken2812221_> cfields: yes. thank you
806 2018-07-19T20:04:37  <wumpus> provoostenator: also run with debug=torcontrol on the server
807 2018-07-19T20:04:38  <provoostenator> Using the wrong port will get me a "connection refused", so something is out there :-)
808 2018-07-19T20:05:02  <wumpus> ok
809 2018-07-19T20:05:37  <wumpus> 'general failure' is a generic enough error message to be completely useless :)
810 2018-07-19T20:06:02  *** LukeJr has quit IRC
811 2018-07-19T20:06:38  <cfields> ken2812221_: please let me know when you're finished so that I can end the poll.
812 2018-07-19T20:06:55  <wumpus> provoostenator: so it might be something with the forwarding then, is the bind port open?
813 2018-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
814 2018-07-19T20:07:51  <cfields> jonasschnelli: try using lxc
815 2018-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?)
816 2018-07-19T20:08:08  <jonasschnelli> cfields: I though I'm using lxc
817 2018-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
818 2018-07-19T20:08:19  <jonasschnelli> Getting the error after executing bin/make-base-vm --suite bionic --arch amd64 --lxc
819 2018-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.
820 2018-07-19T20:09:45  <ken2812221_> cfields: finished
821 2018-07-19T20:09:50  <cfields> ken2812221_: thanks!
822 2018-07-19T20:09:57  <provoostenator> -debug=tor says "ADD_ONION successful ...  advertising service [....].onion ... AddLocal([....].onion:8333,4)"
823 2018-07-19T20:10:21  <cfields> jonasschnelli: oh, just apt-get update and apt-get install debootstrap
824 2018-07-19T20:10:41  <cfields> jonasschnelli: in my case, anyway, mine was old and missing the script for Bionic. Upgrading that package fixed it.
825 2018-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
826 2018-07-19T20:12:03  <wumpus> provoostenator: looks 100% good
827 2018-07-19T20:12:38  <wumpus> provoostenator: so can you connect locally to the that tor connects on to reach bitcoin?
828 2018-07-19T20:12:39  <provoostenator> Indeed. Might be nice for it to try and ping itself via Tor.
829 2018-07-19T20:12:54  *** un1c0d3r has quit IRC
830 2018-07-19T20:13:11  <luke-jr> wumpus: I think we should leave that up to bitcoin.org, and encourage them to be multi-fullnode
831 2018-07-19T20:13:42  <wumpus> luke-jr: leave it up to them = keep doing what I do now?
832 2018-07-19T20:14:08  <luke-jr> wumpus: basically
833 2018-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.
834 2018-07-19T20:14:13  <wumpus> ok
835 2018-07-19T20:14:22  <jonasschnelli> cfields: debootstrap is already the newest version (1.0.89).
836 2018-07-19T20:14:37  <provoostenator> bind= did the trick, bid surprised that was needed.
837 2018-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)
838 2018-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.
839 2018-07-19T20:16:24  <ken2812221_> The minimum debootstrap version to support bionic is 1.0.92
840 2018-07-19T20:16:34  <cfields> jonasschnelli: ah, you're on Debian
841 2018-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
842 2018-07-19T20:16:45  <gribble> https://github.com/bitcoin/bitcoin/issues/8973 | Incoming tor connections should use alternative port · Issue #8973 · bitcoin/bitcoin · GitHub
843 2018-07-19T20:16:46  *** hex17or has joined #bitcoin-core-dev
844 2018-07-19T20:17:01  <jonasschnelli> cfields: Right...I'm looing for a Bionic script now
845 2018-07-19T20:17:19  <wumpus> (or even a UNIX socket, if we ever get that code into mergable shape)
846 2018-07-19T20:17:26  <luke-jr> jonasschnelli: check backports?
847 2018-07-19T20:17:43  <luke-jr> bbiab
848 2018-07-19T20:17:46  <cfields> jonasschnelli: if it helps, it's just a symlink to gutsy. Do you have that?
849 2018-07-19T20:18:09  <jonasschnelli> cfields:okay.Let me try that
850 2018-07-19T20:18:31  *** ghost43 has quit IRC
851 2018-07-19T20:19:06  <jonasschnelli> cfields: that should still create bionic-deterministic builds?
852 2018-07-19T20:19:13  <jonasschnelli> (seems to work)
853 2018-07-19T20:19:33  *** ghost43 has joined #bitcoin-core-dev
854 2018-07-19T20:20:18  <cfields> jonasschnelli: I guess we'll see :)
855 2018-07-19T20:20:46  <jonasschnelli> heh..okay. :)
856 2018-07-19T20:20:46  *** yadev has joined #bitcoin-core-dev
857 2018-07-19T20:20:53  *** bitconner has joined #bitcoin-core-dev
858 2018-07-19T20:21:17  <yadev> Hello !
859 2018-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.
860 2018-07-19T20:22:25  <jonasschnelli> yadev: #bitcoin
861 2018-07-19T20:22:58  <yadev> Thanks
862 2018-07-19T20:24:42  <cfields> poll results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_a80f9a69d20aab2a
863 2018-07-19T20:26:39  <wumpus> yadev: see https://bitcoin.org/en/full-node  (but yes, discussion of user issues belongs in #bitcoin)
864 2018-07-19T20:27:42  *** yadev has quit IRC
865 2018-07-19T20:27:48  <wumpus> cfields: so should we pick the most popular and least popular times? ;)
866 2018-07-19T20:28:35  *** dqx_ has quit IRC
867 2018-07-19T20:28:37  <cfields> heh
868 2018-07-19T20:30:23  <wumpus> in any case this confirms that a lot of people do in fact like the current time
869 2018-07-19T20:32:35  <cfields> I had some hope that there's a 25th hour that is amenable to everyone. Guess not :(
870 2018-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?
871 2018-07-19T20:33:13  <jonasschnelli> (don't complain when I use trusty)
872 2018-07-19T20:33:26  <ken2812221_> update lxc to 2.1.1 or upper
873 2018-07-19T20:33:31  <cfields> jonasschnelli: ok, that's the lxc2 vs lcx3 incompatibility
874 2018-07-19T20:33:36  <cfields> right
875 2018-07-19T20:34:05  <jonasschnelli> I'm on debian stretch
876 2018-07-19T20:34:06  <jonasschnelli> :(
877 2018-07-19T20:34:17  <cfields> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/13171#issuecomment-405711147
878 2018-07-19T20:37:56  <gmaxwell> wumpus: re unix sockets, did the upstream things we need for that happen?
879 2018-07-19T20:39:11  *** hex17or has quit IRC
880 2018-07-19T20:39:23  <wumpus> gmaxwell: not sure; though there was only one small part that needed upstream support, the client-side RPC support
881 2018-07-19T20:39:55  <wumpus> P2P unix sockets support didn't need anything special, neither did server-side RPC
882 2018-07-19T20:40:46  <gmaxwell> only reason I ask I guess is because our side can be done whenever, upstream has leadtimes. :)
883 2018-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
884 2018-07-19T20:43:34  *** nickler has quit IRC
885 2018-07-19T20:43:45  <wumpus> (I think something that would allow automatic reconnection)
886 2018-07-19T20:44:37  <wumpus> it's still open: https://github.com/libevent/libevent/pull/479
887 2018-07-19T20:44:42  *** hex17or has joined #bitcoin-core-dev
888 2018-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."
889 2018-07-19T20:45:22  <wumpus> if anyone knows more about libevent than me, please help
890 2018-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
891 2018-07-19T20:46:57  <jonasschnelli> Looks like I don't have an upgrade path for my build host
892 2018-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
893 2018-07-19T20:47:15  <cfields> jonasschnelli: yea. I don't see any way around it :(
894 2018-07-19T20:48:47  <gmaxwell> wumpus: Do we have a way to test it without bitcoin-cli support?
895 2018-07-19T20:48:58  *** hex17or has quit IRC
896 2018-07-19T20:49:08  <wumpus> gmaxwell: my original PR already updated the test framework to use it (from python)
897 2018-07-19T20:49:12  <gmaxwell> Oh.
898 2018-07-19T20:49:21  <gmaxwell> Well then, I agree its useful without -cli.
899 2018-07-19T20:49:32  <wumpus> gmaxwell: whihch was one of the primary motivations because it allows doing the tests without claiming port ranges
900 2018-07-19T20:49:32  *** frenchy has joined #bitcoin-core-dev
901 2018-07-19T20:50:31  <frenchy> Hello everyone
902 2018-07-19T20:50:33  <wumpus> using UNIX sockets guarantees that there are no port collisions
903 2018-07-19T20:53:26  <gmaxwell> wumpus: yep makes perfect sense there.
904 2018-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
905 2018-07-19T20:53:46  <wumpus> frenchy: hello.
906 2018-07-19T20:58:19  *** AaronvanW has joined #bitcoin-core-dev
907 2018-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.
908 2018-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
909 2018-07-19T21:01:38  *** dqx_ has joined #bitcoin-core-dev
910 2018-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
911 2018-07-19T21:03:35  *** booyah has quit IRC
912 2018-07-19T21:08:19  *** nickler has joined #bitcoin-core-dev
913 2018-07-19T21:12:05  *** dqx_ has quit IRC
914 2018-07-19T21:13:05  *** str4d has quit IRC
915 2018-07-19T21:14:35  *** dqx_ has joined #bitcoin-core-dev
916 2018-07-19T21:16:59  <jonasschnelli> cfields: self compiled lxc 2.1.1 seems to work.
917 2018-07-19T21:17:00  *** un1c0d3r has joined #bitcoin-core-dev
918 2018-07-19T21:17:17  <jonasschnelli> https://bitcoin.jonasschnelli.ch/build/707
919 2018-07-19T21:18:06  *** un1c0d3r has quit IRC
920 2018-07-19T21:18:54  *** frenchy has quit IRC
921 2018-07-19T21:23:20  <cfields> jonasschnelli: nice!
922 2018-07-19T21:29:35  *** dqx_ has quit IRC
923 2018-07-19T21:34:15  *** goatpig has quit IRC
924 2018-07-19T21:35:09  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c3643279165...f281f8f75522
925 2018-07-19T21:35:10  <bitcoin-git> bitcoin/master 2c71edc John Newbery: [wallet] [rpc] Fix importaddress help text
926 2018-07-19T21:35:10  <bitcoin-git> bitcoin/master f281f8f MarcoFalke: Merge #13074: [trivial] Correct help text for `importaddress` RPC...
927 2018-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
928 2018-07-19T21:36:24  *** dqx_ has joined #bitcoin-core-dev
929 2018-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
930 2018-07-19T21:37:32  <jonasschnelli> Haven't looked at the code,... but maybe  pkh(xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw/1'/2/[0-1000]) should be possible
931 2018-07-19T21:37:45  <sipa> jonasschnelli: i would rather not do that
932 2018-07-19T21:37:51  <jonasschnelli> why?
933 2018-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)
934 2018-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
935 2018-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)?
936 2018-07-19T21:40:12  <sipa> jonasschnelli: no, you specify a range
937 2018-07-19T21:40:13  <jonasschnelli> I'm not sure about the performance implications... maybe it's okay
938 2018-07-19T21:40:22  <sipa> jonasschnelli: the scantxoutset RPC in my PR lets you do that
939 2018-07-19T21:40:31  <sipa> it's just not part of the descriptor itself
940 2018-07-19T21:40:36  <jonasschnelli> aha.. okay. I'm still at the third commit. :)
941 2018-07-19T21:40:54  *** clarkmoody has quit IRC
942 2018-07-19T21:40:57  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f281f8f75522...aba2e666d7fd
943 2018-07-19T21:40:58  <bitcoin-git> bitcoin/master 7223263 practicalswift: wallet: Add tests for ParseHDKeypath(...)
944 2018-07-19T21:40:58  <bitcoin-git> bitcoin/master 27ee53c practicalswift: wallet: Add error handling. Check return value of ParseUInt32(...) in ParseHDKeypath(...).
945 2018-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....
946 2018-07-19T21:41:15  <jonasschnelli> (sipa: IMO the third commit "Support output descriptors in scantxoutset" sould be renamed to somthing without "scantxoutset")
947 2018-07-19T21:41:25  <sipa> why?
948 2018-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
949 2018-07-19T21:41:50  <jonasschnelli> sipa: it's unrelated to scantxoutset
950 2018-07-19T21:42:00  <sipa> the third commit is called "Output descriptors module"
951 2018-07-19T21:42:17  <sipa> you're looking at the PR title
952 2018-07-19T21:42:17  <jonasschnelli> Damit! Got fooled by github. NM
953 2018-07-19T21:42:26  <sipa> haha
954 2018-07-19T21:47:01  *** brianhoffman has joined #bitcoin-core-dev
955 2018-07-19T21:47:08  <jonasschnelli> sipa: right now, each child key requires to derive the complete chain, right?
956 2018-07-19T21:47:37  <sipa> jonasschnelli: there's a TODO to cache the bottom non-hardened key
957 2018-07-19T21:48:01  <sipa> i can add that in the same PR if you want
958 2018-07-19T21:48:13  <jonasschnelli> I guess that can be added later
959 2018-07-19T21:48:45  <jonasschnelli> Performance should not mater in the context of scanning the whole utxo set
960 2018-07-19T21:48:59  <jonasschnelli> (for other descriptor usages it may matter)
961 2018-07-19T21:49:06  <jonasschnelli> so later should be fine
962 2018-07-19T21:49:11  <sipa> right, agree
963 2018-07-19T21:51:59  <achow101> it would be nice if we could also get #12493 in for 0.17
964 2018-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
965 2018-07-19T21:53:17  *** dqx_ has quit IRC
966 2018-07-19T21:54:55  *** dqx_ has joined #bitcoin-core-dev
967 2018-07-19T22:04:22  *** meshcollider_ has joined #bitcoin-core-dev
968 2018-07-19T22:05:15  *** meshcollider_ has quit IRC
969 2018-07-19T22:05:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
970 2018-07-19T22:07:12  *** AaronvanW has quit IRC
971 2018-07-19T22:14:38  <meshcollider> So is the meeting time likely to stay as-is
972 2018-07-19T22:15:21  <meshcollider> Sorry I missed this morning's
973 2018-07-19T22:28:09  *** justanotheruser has joined #bitcoin-core-dev
974 2018-07-19T22:29:42  *** dqx_ has quit IRC
975 2018-07-19T22:30:16  *** lari has quit IRC
976 2018-07-19T22:31:24  *** lari has joined #bitcoin-core-dev
977 2018-07-19T22:37:07  *** jamesob_ has joined #bitcoin-core-dev
978 2018-07-19T22:37:07  *** jamesob__ has joined #bitcoin-core-dev
979 2018-07-19T22:39:08  *** Chris_Stewart_5 has quit IRC
980 2018-07-19T22:40:57  *** jtimon has joined #bitcoin-core-dev
981 2018-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
982 2018-07-19T22:51:09  *** dqx_ has joined #bitcoin-core-dev
983 2018-07-19T22:51:09  <aj> #13311 #8994
984 2018-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
985 2018-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
986 2018-07-19T22:54:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
987 2018-07-19T22:56:01  *** vicenteH has quit IRC
988 2018-07-19T23:01:23  *** Squidicuz has quit IRC
989 2018-07-19T23:02:50  *** dqx_ has quit IRC
990 2018-07-19T23:06:21  *** polydin has quit IRC
991 2018-07-19T23:19:41  *** drexl has quit IRC
992 2018-07-19T23:34:25  <aj> jtimon: you could tick the todo box for 12128 in 8994's description fwiw
993 2018-07-19T23:37:25  *** dqx_ has joined #bitcoin-core-dev
994 2018-07-19T23:39:02  *** Randolf has joined #bitcoin-core-dev
995 2018-07-19T23:43:29  *** dqx_ has quit IRC
996 2018-07-19T23:45:33  <jtimon> aj: done, thanks