1 2020-06-18T00:00:02  *** slewis has quit IRC
  2 2020-06-18T00:08:59  *** jarthur has joined #bitcoin-core-dev
  3 2020-06-18T00:11:37  *** andrewtoth has quit IRC
  4 2020-06-18T00:12:21  *** andrewtoth has joined #bitcoin-core-dev
  5 2020-06-18T00:16:54  *** Highway61 has quit IRC
  6 2020-06-18T00:21:40  *** Laat has joined #bitcoin-core-dev
  7 2020-06-18T00:21:47  *** lightlike has quit IRC
  8 2020-06-18T00:38:08  *** jarthur has quit IRC
  9 2020-06-18T00:49:00  *** S3RK has joined #bitcoin-core-dev
 10 2020-06-18T00:53:35  *** S3RK has quit IRC
 11 2020-06-18T00:56:26  *** S3RK has joined #bitcoin-core-dev
 12 2020-06-18T01:00:20  *** jarthur has joined #bitcoin-core-dev
 13 2020-06-18T01:14:46  *** davterra has joined #bitcoin-core-dev
 14 2020-06-18T01:18:17  *** S3RK has quit IRC
 15 2020-06-18T01:19:32  <jeremyrubin> hebasto: is their a motivation for replacing recursivemutex with mutex?
 16 2020-06-18T01:19:51  <sipa> recursive mutexes are evil
 17 2020-06-18T01:20:01  <sipa> mutices?
 18 2020-06-18T01:20:26  *** Beta_ has joined #bitcoin-core-dev
 19 2020-06-18T01:21:15  <jeremyrubin> (context #19306)
 20 2020-06-18T01:21:16  <gribble> https://github.com/bitcoin/bitcoin/issues/19306 | refactor: Replace RecursiveMutex with Mutex in CTxMemPool by hebasto · Pull Request #19306 · bitcoin/bitcoin · GitHub
 21 2020-06-18T01:21:22  <sipa> there is probably a place for them, like goto
 22 2020-06-18T01:21:34  <sipa> but almost always, they just lead to badly designed abstractions
 23 2020-06-18T01:22:01  <sipa> a clear design should have code that operates outside the critical section, and code that operates inside
 24 2020-06-18T01:22:16  <sipa> but not code that works in both
 25 2020-06-18T01:22:51  <gwillen> my impression is that the usual better approach is to have Foo() which calls Foo_locked(), and callers who already hold the mutex can call the latter directly
 26 2020-06-18T01:22:57  <sipa> indeed
 27 2020-06-18T01:23:00  <jeremyrubin> I agree with this in general, but am trying to understand the specific issues we're solving in the mempool  rather than general API design
 28 2020-06-18T01:23:03  *** davterra has quit IRC
 29 2020-06-18T01:23:23  <jeremyrubin> It seems to get rid of recursive mutex in favor of our own implementation of it
 30 2020-06-18T01:23:29  <jeremyrubin> which seems worse
 31 2020-06-18T01:23:32  <sipa> oh
 32 2020-06-18T01:23:58  <jeremyrubin> So I'm trying to understand hebasto's motive in the PR to be able to provide constructive feedback :)
 33 2020-06-18T01:23:59  <sipa> i have not looked at the code
 34 2020-06-18T01:24:48  <sipa> eh, i agree - that change isn't a step in the right direction
 35 2020-06-18T01:29:25  *** bitcoin-git has joined #bitcoin-core-dev
 36 2020-06-18T01:29:25  <bitcoin-git> [bitcoin] andrewtoth closed pull request #18941: validation: Persist coins cache to disk and load on startup (master...persist-coinscache) https://github.com/bitcoin/bitcoin/pull/18941
 37 2020-06-18T01:29:28  *** bitcoin-git has left #bitcoin-core-dev
 38 2020-06-18T01:30:53  *** ossifrage has joined #bitcoin-core-dev
 39 2020-06-18T01:33:47  <luke-jr> sipa: recursive mutexes just guarantees that <this> code always operates inside, no matter the scope of the lock
 40 2020-06-18T01:34:11  *** Beta_ has quit IRC
 41 2020-06-18T01:34:19  *** davterra has joined #bitcoin-core-dev
 42 2020-06-18T01:34:31  <luke-jr> gwillen: what good is adding a wrapper for every method that just takes a lock before calling the real one?
 43 2020-06-18T01:35:00  <sipa> luke-jr: making the separation between inside/outside critical section clear
 44 2020-06-18T01:35:11  <jeremyrubin> I think recursive mutexs and lock annotations have a slight redundancy
 45 2020-06-18T01:35:18  <jeremyrubin> run time v.s. compile time lock checking
 46 2020-06-18T01:35:52  <jeremyrubin> run time should be strictly more flexible, but also permits some undesirable behaviors
 47 2020-06-18T01:35:53  <sipa> (non-recursive mutexes are also slightly more efficient, but not enough to justify changing things just because of that imo)
 48 2020-06-18T01:35:54  <gwillen> luke-jr: recursive mutexes are often used when people want to call the same method while sometimes holding the lock it wants, and sometimes not
 49 2020-06-18T01:36:09  <gwillen> a better approach is to have two methods, and have them call the correct one
 50 2020-06-18T01:36:11  <luke-jr> sure, the lock annotations are a reasonable alternative to recursive mutex - but I don't think a wrapper for every method just to add a lock is reasonable
 51 2020-06-18T01:36:28  <sipa> luke-jr: most methods are only called in one context
 52 2020-06-18T01:36:34  <luke-jr> sipa: not all though
 53 2020-06-18T01:36:38  <sipa> fwiw, addrman has this design
 54 2020-06-18T01:36:49  <gwillen> right, the point is that you only need a wrapper for methods which are called in both contexts, not every method
 55 2020-06-18T01:37:00  <sipa> it has all code running inside the cs in the .cpp file
 56 2020-06-18T01:37:03  <luke-jr> gwillen: some abstractions would have it for most methods
 57 2020-06-18T01:37:08  <gwillen> it is relatively rare (and probably sometimes a code smell) to need this
 58 2020-06-18T01:37:10  <sipa> and then all publicly accessible code grabs the lock, and calls the internals
 59 2020-06-18T01:37:25  <gwillen> but if you do need it, having two methods is better than using recursive mutexes, the existence of which is a mistake
 60 2020-06-18T01:38:09  <gwillen> (instead of having two methods, you can also take a parameter indicating whether the lock is held or not, which is how some of the code under discussion does it, but I disprefer that approach)
 61 2020-06-18T01:38:14  <luke-jr> the benefit of annotations is that you force the caller to be aware it's using a lock
 62 2020-06-18T01:38:17  <luke-jr> you lose that with wrappers
 63 2020-06-18T01:38:21  <jeremyrubin> Everyone enjoy your evenings ;)
 64 2020-06-18T01:38:32  <sipa> gwillen: agree
 65 2020-06-18T01:38:35  <gwillen> wrappers and annotations are not mutually exclusive, you should definitely still use annotations
 66 2020-06-18T01:38:49  <luke-jr> you can't use annotations with a wrapper..
 67 2020-06-18T01:38:54  <sipa> luke-jr: huh?
 68 2020-06-18T01:38:56  <luke-jr> (unless it's a recursive mutex)
 69 2020-06-18T01:39:10  <jeremyrubin> I didn't realize this would be such a *contentious* topic
 70 2020-06-18T01:39:11  <sipa> you'd have the internal function annotated with require_lock, and and the wrapper with a lock_excluded annotation
 71 2020-06-18T01:39:20  <gwillen> is this a feature of the particular annotations that happen to be available in the bitcoin core codebase? It's certainly not a feature of annotations in general.
 72 2020-06-18T01:39:25  <luke-jr> sipa: okay, but that defeats the point
 73 2020-06-18T01:39:34  <sipa> luke-jr: i don't see how?
 74 2020-06-18T01:39:38  <sipa> this is my preferred approach
 75 2020-06-18T01:39:53  <luke-jr> sipa: the code calling the wrapper no longer self-documents/makes the developer aware of using the lock
 76 2020-06-18T01:40:12  <sipa> external code should only be seeing the wrapper
 77 2020-06-18T01:40:20  <sipa> internal code should only ever call the non-wrapped function
 78 2020-06-18T01:40:30  <sipa> thus providing a perfectly clear separation between the two
 79 2020-06-18T01:40:50  <luke-jr> and what if the external code needs to hold the lock longer than just the call?
 80 2020-06-18T01:41:10  <sipa> rewrite the code :p
 81 2020-06-18T01:41:19  <jeremyrubin> luke-jr: use an external lock?
 82 2020-06-18T01:41:24  <sipa> (i know that's not always possible - but in many cases it is)
 83 2020-06-18T01:41:58  <luke-jr> eg, with a wallet, it's pretty reasonable to want atomic operations
 84 2020-06-18T01:42:10  <luke-jr> doing multiple things to the wallet with the lock held
 85 2020-06-18T01:42:34  <luke-jr> you *could* just move the entire logic into the wallet, but that's a bad design in some cases
 86 2020-06-18T01:42:35  <sipa> luke-jr: yeah, that's a good example of an exception
 87 2020-06-18T01:43:02  <gwillen> btw jeremyrubin it's not switching to a homebrewed mutex, if you chase down the types it's switching from AnnotatedMixin<std::recursive_mutex> to AnnotatedMixin<std::mutex>, which seems like the right thing
 88 2020-06-18T01:43:47  <sipa> gwillen: i think it's referring to the "if locked then unlock else assertlocknotheld" pattern that i see some times
 89 2020-06-18T01:43:59  *** Highway61 has joined #bitcoin-core-dev
 90 2020-06-18T01:44:06  <jeremyrubin> sipa: gwillen: yes, that's what I meant
 91 2020-06-18T01:44:45  <sipa> luke-jr: i think a reasonable approach for that may be having a publicly visible lock for synchronizing a consistent view, which is distinct from the internal wallet's lock (which protects internal data structure correctness, not externally visible consistency)
 92 2020-06-18T01:44:50  <gwillen> well, adding an argument for whether the mutex is held is equivalent to a wrapper, just uglier, which I think is what's going on here
 93 2020-06-18T01:44:57  <gwillen> I dislike it because it means you are not using RAII
 94 2020-06-18T01:45:02  <sipa> gwillen: indeed
 95 2020-06-18T01:45:05  <gwillen> and if you take an exception the world ends
 96 2020-06-18T01:46:06  <jeremyrubin> I think it's basically getting rid of a recursive mutex for code that's still designed to take a recursive mutex
 97 2020-06-18T01:46:26  <gwillen> it's better than a true recursive mutex because it's not possible to recurse by accident, you have to declare at call time which behavior you want (although better if you had to declare statically at compile time)
 98 2020-06-18T01:46:26  <sipa> it looks like that
 99 2020-06-18T01:46:27  <jeremyrubin> The correct refactor would be to make the code not do anything fancy with locks, or to just leave it
100 2020-06-18T01:47:06  <jeremyrubin> gwillen: I think the chances of a bug or error in custom logic is higher than a recursive mutex
101 2020-06-18T01:47:18  <jeremyrubin> accidental recursion seems unlikely...
102 2020-06-18T01:47:39  <jeremyrubin> and accidental recursion would be a bug lock or no
103 2020-06-18T01:48:30  <gwillen> (sorry I mean, accidental mutex recursion, that is, calling a function while holding a mutex, not expecting the callee to also lock it, resulting in the callee violating the caller's invariants)
104 2020-06-18T01:48:31  *** promag has quit IRC
105 2020-06-18T01:48:45  <gwillen> (this is the fundamental problem of recursive mutexes)
106 2020-06-18T01:49:10  <gwillen> (and I assume the motivation behind hebasto's refactor)
107 2020-06-18T01:49:20  <jeremyrubin> Ah sure. But the code in the callee could also just not lock at all and modify the protected variables?
108 2020-06-18T01:49:32  * jeremyrubin pines for rust
109 2020-06-18T01:50:07  <gwillen> but that would be an obvious bug in the callee, whereas with recursive mutexes you can have a caller and a callee that both appear to be correct by local inspection (they take a mutex while modifying the protected variables)
110 2020-06-18T01:50:32  <gwillen> but if the caller calls the callee in the middle of doing so, the result can violate the mutex invariant surprisingly
111 2020-06-18T01:51:00  <jeremyrubin> would it be? it depends on how pervasive locking annotations are in your code
112 2020-06-18T01:51:17  <jeremyrubin> It's entirely reasonable to write a helper which doesn't assert which locks it expects
113 2020-06-18T01:51:30  <gwillen> Well, it would be nice if it weren't. :-)
114 2020-06-18T01:51:48  * jeremyrubin pines for rust
115 2020-06-18T01:51:50  <luke-jr> gwillen: it'd be nice if C/C++ added non-scoping conditionals :P
116 2020-06-18T01:52:22  <gwillen> anyway that's the story of the theoretical basis for getting rid of recursive mutexes, as I understand it... but adding annotations is probably a higher priority, yeah.
117 2020-06-18T01:52:56  <luke-jr> jeremyrubin: Rust needs to fix its problems with bootstrap and shared libraries
118 2020-06-18T01:53:55  <jeremyrubin> c++ needs to fix... everything else basically :p
119 2020-06-18T01:54:47  * sipa grabs popcorn
120 2020-06-18T01:54:57  *** justanotheruser has quit IRC
121 2020-06-18T01:56:29  <luke-jr> C++ isn't broken, even if it doesn't provide features some might idealise
122 2020-06-18T01:58:11  <jeremyrubin> anyways bootsrap stuff I think is more in dongcarl's weelhouse so I'll tag out for him ;)
123 2020-06-18T02:00:02  <luke-jr> IMO it's still in Rust developers' court; they haven't made it practical
124 2020-06-18T02:01:18  <luke-jr> and frankly seem to be actively trying to make it difficult
125 2020-06-18T02:01:21  <gwillen> my understanding is that bootstrapping from a C compiler using mrustc is annoying but functional, and guix has this working
126 2020-06-18T02:01:39  <luke-jr> gwillen: oh? it does?
127 2020-06-18T02:01:43  <fanquake> https://guix.gnu.org/blog/2018/bootstrapping-rust/
128 2020-06-18T02:01:45  <luke-jr> that's new progress I hadn't heard of
129 2020-06-18T02:01:51  <luke-jr> that's 2018..
130 2020-06-18T02:02:04  <luke-jr> and still convoluted
131 2020-06-18T02:02:45  <luke-jr> (things have gotten worse since 2018)
132 2020-06-18T02:03:14  <gwillen> it looks to me like they've gotten better, mrustc can build rust 1.29 now, so the entire chain of rustc-rustc bootstrapping from that page is outdated
133 2020-06-18T02:03:24  <gwillen> I don't know whether guix takes advantage of this, though, I have not used it
134 2020-06-18T02:03:52  *** justanotheruser has joined #bitcoin-core-dev
135 2020-06-18T02:04:50  <fanquake> I'd also like to know what has "gotten worse"
136 2020-06-18T02:05:14  <luke-jr> fanquake: Rust seems to make no effort to be backward compatible, so ~every release adds another step you have to compile
137 2020-06-18T02:05:32  <luke-jr> eg, you can't just mrustc a stable rustc, then use that to get the latest rustc
138 2020-06-18T02:05:38  <gwillen> in fact, assuming it still works, mrustc appears to ship a shell script that demos bootstrapping from a C compiler through mrustc and rustc 1.29.0 to rustc 1.30.0 (it stops there, but it's a proof of concept that you can build later versions)
139 2020-06-18T02:06:15  <gwillen> I assume you do not actually have to crawl one version at a time, but it would be nice to have a compatibility matrix to see how many compiles it takes
140 2020-06-18T02:06:47  <luke-jr> it would be nice if Rust devs stopped breaking the language compatibility :p
141 2020-06-18T02:08:18  <fanquake> There's also https://github.com/dtolnay/bootstrap, which seems to crawl through each version
142 2020-06-18T02:09:08  <gwillen> if you just wnat a proof of concept, probably easier to do that than to work out the full matrix
143 2020-06-18T02:09:50  <gwillen> oh, I do like the point made in the README here, which is that once there is full reproducibility, you don't need to do this every time, you just need to do it once and check that the hash of the result matches the official build
144 2020-06-18T02:13:36  <phantomcircuit> luke-jr, the issue of doing atomic things like that is more or less analogous to database consistency issues
145 2020-06-18T02:13:51  <phantomcircuit> no real solution here just a thought
146 2020-06-18T02:15:47  *** shesek has quit IRC
147 2020-06-18T02:16:10  *** shesek has joined #bitcoin-core-dev
148 2020-06-18T02:16:10  *** shesek has joined #bitcoin-core-dev
149 2020-06-18T02:27:39  *** promag has joined #bitcoin-core-dev
150 2020-06-18T02:31:10  <sipa> i was curious what the bootstrapping cycle for modern GCC is like
151 2020-06-18T02:37:05  <sipa> based on https://gcc.gnu.org/install/prerequisites.html, it seems K&R C compiler -> GCC 3.3 -> GCC 10 could work
152 2020-06-18T02:37:11  *** bitdex has joined #bitcoin-core-dev
153 2020-06-18T02:37:25  <sipa> potentially with GCC 4.7 in between (unless how good C++98 support in GCC 3.3 was)
154 2020-06-18T02:38:25  <gwillen> I assume C/C++ (as implementd in GCC) has changed substantially in that time, so the real issue is not so much language change, as the compiler being overly aggressive in taking advantage of the latest features of the language
155 2020-06-18T02:38:35  *** promag has quit IRC
156 2020-06-18T02:38:45  <gwillen> which GCC is presumably fairly careful to avoid, if you can really bootstrap it that directly
157 2020-06-18T02:39:45  <sipa> yeah, GCC switched to C89 in GCC 3.4, to C++98 in GCC 4.8, to C++11 in GCC 11
158 2020-06-18T02:40:08  <sipa> they're slower in adopting language changes than bitcoin core :p
159 2020-06-18T02:40:34  <fanquake> heh
160 2020-06-18T02:40:52  <sipa> though, that's an unfair comparison with rust, which just changes much more rapidly by virtue of being younger
161 2020-06-18T02:41:08  <fanquake> Somewhat related, there's also a shoutout to Carl in here: https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
162 2020-06-18T02:41:22  <fanquake> The Guix bootstrap seed is now even smaller
163 2020-06-18T02:41:54  <fanquake> Targeting another 50% reduction during the next round of work
164 2020-06-18T02:47:42  <sipa> nice
165 2020-06-18T03:00:02  *** Laat has quit IRC
166 2020-06-18T03:10:06  *** promag has joined #bitcoin-core-dev
167 2020-06-18T03:10:45  *** bitcoin-git has joined #bitcoin-core-dev
168 2020-06-18T03:10:45  <bitcoin-git> [bitcoin] jamesgmorgan opened pull request #19317: Add a left-justified width field to log2_work component for a uniform debug.log output (master...jmorgan-updatetipfmt) https://github.com/bitcoin/bitcoin/pull/19317
169 2020-06-18T03:10:46  *** bitcoin-git has left #bitcoin-core-dev
170 2020-06-18T03:14:37  *** promag has quit IRC
171 2020-06-18T03:14:49  *** Eagle[TM] has joined #bitcoin-core-dev
172 2020-06-18T03:16:42  *** dr-orlovsky has quit IRC
173 2020-06-18T03:17:07  *** EagleTM has quit IRC
174 2020-06-18T03:22:24  *** Alphi has joined #bitcoin-core-dev
175 2020-06-18T03:30:18  *** go11111111111 has joined #bitcoin-core-dev
176 2020-06-18T03:32:47  *** go121212 has quit IRC
177 2020-06-18T03:44:07  <luke-jr> sipa: compilers *should* be very slow with adopting new features
178 2020-06-18T03:44:28  <luke-jr> for anything else, you can always just upgrade the compiler so long as the new compiler builds
179 2020-06-18T04:01:17  *** S3RK has joined #bitcoin-core-dev
180 2020-06-18T04:05:06  *** S3RK has quit IRC
181 2020-06-18T04:05:33  *** S3RK has joined #bitcoin-core-dev
182 2020-06-18T04:05:41  *** ppisati has quit IRC
183 2020-06-18T04:10:01  *** S3RK has quit IRC
184 2020-06-18T04:12:19  *** ppisati has joined #bitcoin-core-dev
185 2020-06-18T04:16:44  *** AaronvanW has quit IRC
186 2020-06-18T04:21:03  *** vasild_ has joined #bitcoin-core-dev
187 2020-06-18T04:24:03  *** vasild has quit IRC
188 2020-06-18T04:24:07  *** vasild_ is now known as vasild
189 2020-06-18T04:35:29  *** davterra has quit IRC
190 2020-06-18T04:38:45  *** S3RK has joined #bitcoin-core-dev
191 2020-06-18T04:41:15  *** davterra has joined #bitcoin-core-dev
192 2020-06-18T04:48:27  *** AaronvanW has joined #bitcoin-core-dev
193 2020-06-18T04:52:59  *** AaronvanW has quit IRC
194 2020-06-18T05:00:52  *** Pavlenex has joined #bitcoin-core-dev
195 2020-06-18T05:19:24  *** bitcoin-git has joined #bitcoin-core-dev
196 2020-06-18T05:19:25  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/35ed88f187c9...931035b60830
197 2020-06-18T05:19:26  <bitcoin-git> bitcoin/master fa84edb fanquake: build: don't warn when doxygen isn't found
198 2020-06-18T05:19:26  <bitcoin-git> bitcoin/master 931035b fanquake: Merge #19301: build: don't warn when doxygen isn't found
199 2020-06-18T05:19:28  *** bitcoin-git has left #bitcoin-core-dev
200 2020-06-18T05:19:44  *** bitcoin-git has joined #bitcoin-core-dev
201 2020-06-18T05:19:45  <bitcoin-git> [bitcoin] fanquake merged pull request #19301: build: don't warn when doxygen isn't found (master...no_warn_doxygen_missing) https://github.com/bitcoin/bitcoin/pull/19301
202 2020-06-18T05:19:46  *** bitcoin-git has left #bitcoin-core-dev
203 2020-06-18T05:21:32  *** bitcoin-git has joined #bitcoin-core-dev
204 2020-06-18T05:21:32  <bitcoin-git> [bitcoin] fanquake closed pull request #18942: doc: Increase minimum required GCC to 5.1 (master...gcc_5_1_for_codecvt) https://github.com/bitcoin/bitcoin/pull/18942
205 2020-06-18T05:21:34  *** bitcoin-git has left #bitcoin-core-dev
206 2020-06-18T05:22:59  *** Guyver2 has joined #bitcoin-core-dev
207 2020-06-18T05:25:59  *** luke-jr has quit IRC
208 2020-06-18T05:26:47  *** luke-jr has joined #bitcoin-core-dev
209 2020-06-18T05:41:20  *** S3RK has quit IRC
210 2020-06-18T05:41:46  *** S3RK has joined #bitcoin-core-dev
211 2020-06-18T05:46:30  *** S3RK has quit IRC
212 2020-06-18T05:48:01  *** S3RK has joined #bitcoin-core-dev
213 2020-06-18T05:52:42  *** S3RK has quit IRC
214 2020-06-18T06:00:02  *** Alphi has quit IRC
215 2020-06-18T06:10:35  *** Kiminuo has joined #bitcoin-core-dev
216 2020-06-18T06:20:31  *** edit_21 has joined #bitcoin-core-dev
217 2020-06-18T06:48:45  *** S3RK has joined #bitcoin-core-dev
218 2020-06-18T06:49:58  *** AaronvanW has joined #bitcoin-core-dev
219 2020-06-18T06:50:45  *** marcoagner has joined #bitcoin-core-dev
220 2020-06-18T07:00:26  *** wiz has quit IRC
221 2020-06-18T07:08:52  <dburkett> A little late, but one "self-documenting" RAII way of handling locks is taking in a lock reference like: `void func_locked(const std::unique_lock<std::mutex>& lock)`
222 2020-06-18T07:09:12  <dburkett> It's not as easy to misuse, and doesn't require relying on non-compiler-enforced annotations. The only shortfall is you still need to document which mutex must be locked in cases where there are multiple.
223 2020-06-18T07:11:40  *** davterra_ has joined #bitcoin-core-dev
224 2020-06-18T07:12:05  <dburkett> You could even solve that by defining a unique type for each mutex or something, but that's going a little overboard.
225 2020-06-18T07:12:24  *** Soh has joined #bitcoin-core-dev
226 2020-06-18T07:13:43  *** davterra has quit IRC
227 2020-06-18T07:22:10  <aj> dburkett: having a unique type for each mutex would probably work fine for globals/module-level mutexes, but not for mutexes that are members of an object. could also do an AssertLockHeld(mutex,guard); that checks the guard corresponds to the mutex and isn't random garbage
228 2020-06-18T07:23:05  *** AaronvanW has quit IRC
229 2020-06-18T07:23:38  <dburkett> AssertLockHeld is only runtime enforceable, but yes that's an improvement.
230 2020-06-18T07:23:41  *** teca has joined #bitcoin-core-dev
231 2020-06-18T07:25:41  <dburkett> The mere existence of a lock parameter at all though is an improvement over the current situation. Any assertions/annotations/custom mutexes beyond that are a bonus
232 2020-06-18T07:42:51  *** CubicEarth has quit IRC
233 2020-06-18T07:43:23  *** Dean_Guss has quit IRC
234 2020-06-18T07:45:24  *** CubicEarth has joined #bitcoin-core-dev
235 2020-06-18T07:50:01  *** promag has joined #bitcoin-core-dev
236 2020-06-18T07:50:05  *** luke-jr has quit IRC
237 2020-06-18T07:51:29  *** luke-jr has joined #bitcoin-core-dev
238 2020-06-18T07:54:14  *** promag has quit IRC
239 2020-06-18T07:58:16  *** jarthur has quit IRC
240 2020-06-18T08:01:27  *** AaronvanW has joined #bitcoin-core-dev
241 2020-06-18T08:05:13  *** Livestradamus has quit IRC
242 2020-06-18T08:05:34  *** Livestradamus has joined #bitcoin-core-dev
243 2020-06-18T08:11:34  *** Pavlenex has quit IRC
244 2020-06-18T08:22:16  *** promag has joined #bitcoin-core-dev
245 2020-06-18T08:24:19  *** michagogo has quit IRC
246 2020-06-18T08:25:11  *** tryphe_ is now known as tryphe
247 2020-06-18T08:31:55  *** Soh has quit IRC
248 2020-06-18T08:39:00  *** S3RK has quit IRC
249 2020-06-18T08:39:33  *** S3RK has joined #bitcoin-core-dev
250 2020-06-18T08:40:28  *** MarcoFalke has quit IRC
251 2020-06-18T08:42:36  *** MarcoFalke has joined #bitcoin-core-dev
252 2020-06-18T08:43:54  *** S3RK has quit IRC
253 2020-06-18T08:54:19  *** nostrodamy has joined #bitcoin-core-dev
254 2020-06-18T08:55:15  *** Pavlenex has joined #bitcoin-core-dev
255 2020-06-18T09:00:02  *** edit_21 has quit IRC
256 2020-06-18T09:01:21  *** proofofkeags has quit IRC
257 2020-06-18T09:02:54  *** AaronvanW has quit IRC
258 2020-06-18T09:03:11  *** AaronvanW has joined #bitcoin-core-dev
259 2020-06-18T09:22:09  *** fabriceflorin has joined #bitcoin-core-dev
260 2020-06-18T09:28:35  *** S3RK has joined #bitcoin-core-dev
261 2020-06-18T09:30:56  *** Eagle[TM] has quit IRC
262 2020-06-18T09:33:13  *** S3RK has quit IRC
263 2020-06-18T09:46:03  *** dr-orlovsky has joined #bitcoin-core-dev
264 2020-06-18T09:58:01  *** S3RK has joined #bitcoin-core-dev
265 2020-06-18T09:58:02  *** dr-orlovsky has quit IRC
266 2020-06-18T09:59:22  *** EagleTM has joined #bitcoin-core-dev
267 2020-06-18T10:02:14  *** S3RK has quit IRC
268 2020-06-18T10:02:41  *** roconnor_ has quit IRC
269 2020-06-18T10:03:28  *** General90Hoppe has joined #bitcoin-core-dev
270 2020-06-18T10:04:50  *** dr-orlovsky has joined #bitcoin-core-dev
271 2020-06-18T10:09:25  *** Relis has quit IRC
272 2020-06-18T10:11:01  *** General90Hoppe has quit IRC
273 2020-06-18T10:13:00  *** arkosphilos has joined #bitcoin-core-dev
274 2020-06-18T10:17:40  *** belcher has joined #bitcoin-core-dev
275 2020-06-18T10:19:50  *** S3RK has joined #bitcoin-core-dev
276 2020-06-18T10:20:18  *** Pavlenex has quit IRC
277 2020-06-18T10:26:35  *** dr-orlovsky has quit IRC
278 2020-06-18T10:29:47  *** kvaciral has quit IRC
279 2020-06-18T10:49:16  *** dr-orlovsky has joined #bitcoin-core-dev
280 2020-06-18T10:49:41  *** arkosphilos is now known as arkos
281 2020-06-18T11:02:07  *** arkos has quit IRC
282 2020-06-18T11:05:49  *** Relis has joined #bitcoin-core-dev
283 2020-06-18T11:11:58  *** arkos has joined #bitcoin-core-dev
284 2020-06-18T11:16:47  *** S3RK has quit IRC
285 2020-06-18T11:17:16  *** S3RK has joined #bitcoin-core-dev
286 2020-06-18T11:25:03  *** S3RK has quit IRC
287 2020-06-18T11:26:56  *** S3RK has joined #bitcoin-core-dev
288 2020-06-18T11:31:38  *** S3RK has quit IRC
289 2020-06-18T11:41:56  *** bitcoin-git has joined #bitcoin-core-dev
290 2020-06-18T11:41:56  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/931035b60830...343c0bfbf1e5
291 2020-06-18T11:41:57  <bitcoin-git> bitcoin/master 80d4423 Troy Giorshev: Test buffered valid message
292 2020-06-18T11:41:58  <bitcoin-git> bitcoin/master 343c0bf MarcoFalke: Merge #19304: test: Check that message sends successfully when header is s...
293 2020-06-18T11:42:07  *** bitcoin-git has left #bitcoin-core-dev
294 2020-06-18T11:42:26  *** bitcoin-git has joined #bitcoin-core-dev
295 2020-06-18T11:42:26  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19304: test: Check that message sends successfully when header is split across two buffers (master...2020-06-test-partial) https://github.com/bitcoin/bitcoin/pull/19304
296 2020-06-18T11:42:27  *** bitcoin-git has left #bitcoin-core-dev
297 2020-06-18T11:43:26  *** diogorsergio has joined #bitcoin-core-dev
298 2020-06-18T12:00:02  *** fabriceflorin has quit IRC
299 2020-06-18T12:00:12  *** S3RK has joined #bitcoin-core-dev
300 2020-06-18T12:05:00  *** S3RK has quit IRC
301 2020-06-18T12:12:48  *** bitcoin-git has joined #bitcoin-core-dev
302 2020-06-18T12:12:49  <bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/343c0bfbf1e5...b8740d6737b4
303 2020-06-18T12:12:50  <bitcoin-git> bitcoin/master 1f790a1 Pieter Wuille: Make Span size type unsigned
304 2020-06-18T12:12:51  <bitcoin-git> bitcoin/master bb3d38f Pieter Wuille: Make pointer-based Span construction safer
305 2020-06-18T12:12:52  <bitcoin-git> bitcoin/master ab303a1 Pieter Wuille: Add Span constructors for arrays and vectors
306 2020-06-18T12:12:53  *** bitcoin-git has left #bitcoin-core-dev
307 2020-06-18T12:13:48  *** bitcoin-git has joined #bitcoin-core-dev
308 2020-06-18T12:13:49  <bitcoin-git> [bitcoin] laanwj merged pull request #18468: Span improvements (master...202003_conv_span) https://github.com/bitcoin/bitcoin/pull/18468
309 2020-06-18T12:13:50  *** bitcoin-git has left #bitcoin-core-dev
310 2020-06-18T12:21:16  *** jackalope has joined #bitcoin-core-dev
311 2020-06-18T12:22:18  <wumpus> achow101: is #19292 the next step in #18971? if so, would it make sense to put that in high prio for review first?
312 2020-06-18T12:22:20  <gribble> https://github.com/bitcoin/bitcoin/issues/19292 | wallet: Refactor BerkeleyBatch Read, Write, Erase, and Exists functions into non-template functions by achow101 · Pull Request #19292 · bitcoin/bitcoin · GitHub
313 2020-06-18T12:22:22  <gribble> https://github.com/bitcoin/bitcoin/issues/18971 | wallet: Refactor the classes in wallet/db.{cpp/h} by achow101 · Pull Request #18971 · bitcoin/bitcoin · GitHub
314 2020-06-18T12:22:25  *** jonatack has quit IRC
315 2020-06-18T12:24:31  *** jonatack has joined #bitcoin-core-dev
316 2020-06-18T12:36:53  *** S3RK has joined #bitcoin-core-dev
317 2020-06-18T12:41:20  *** arkos has quit IRC
318 2020-06-18T12:41:25  *** S3RK has quit IRC
319 2020-06-18T12:48:34  *** Mercury_Vapor has quit IRC
320 2020-06-18T12:51:24  *** Mercury_Vapor has joined #bitcoin-core-dev
321 2020-06-18T12:53:46  *** Guyver2 has quit IRC
322 2020-06-18T13:03:31  *** roconnor_ has joined #bitcoin-core-dev
323 2020-06-18T13:28:18  *** Kiminuo has quit IRC
324 2020-06-18T13:37:25  *** Kiminuo has joined #bitcoin-core-dev
325 2020-06-18T13:41:55  *** bitcoin-git has joined #bitcoin-core-dev
326 2020-06-18T13:41:55  <bitcoin-git> [bitcoin] fanquake opened pull request #19318: build: disable -stack-clash-protection on Windows (master...disable_stack_clash_windows) https://github.com/bitcoin/bitcoin/pull/19318
327 2020-06-18T13:41:56  *** bitcoin-git has left #bitcoin-core-dev
328 2020-06-18T13:42:32  *** promag has quit IRC
329 2020-06-18T14:14:00  *** davterra__ has joined #bitcoin-core-dev
330 2020-06-18T14:14:00  <achow101> wumpus: yes
331 2020-06-18T14:14:01  *** Kiminuo has quit IRC
332 2020-06-18T14:16:26  *** davterra_ has quit IRC
333 2020-06-18T14:17:47  *** promag has joined #bitcoin-core-dev
334 2020-06-18T14:19:23  *** davterra__ has quit IRC
335 2020-06-18T14:22:08  *** promag has quit IRC
336 2020-06-18T14:24:26  *** promag has joined #bitcoin-core-dev
337 2020-06-18T14:25:22  <wumpus> achow101: ok, replaced
338 2020-06-18T14:25:30  <achow101> although #19292, #19308, and #19310 shouldn't conflict with each other so they can be merged in any order
339 2020-06-18T14:25:32  <gribble> https://github.com/bitcoin/bitcoin/issues/19292 | wallet: Refactor BerkeleyBatch Read, Write, Erase, and Exists functions into non-template functions by achow101 · Pull Request #19292 · bitcoin/bitcoin · GitHub
340 2020-06-18T14:25:33  <gribble> https://github.com/bitcoin/bitcoin/issues/19308 | wallet: BerkeleyBatch Handle cursor internally by achow101 · Pull Request #19308 · bitcoin/bitcoin · GitHub
341 2020-06-18T14:25:35  <gribble> https://github.com/bitcoin/bitcoin/issues/19310 | wallet: BerkeleyDatabase make BerkeleyDatabase::Create, CreateMock, and CreateDummy non-static functions by achow101 · Pull Request #19310 · bitcoin/bitcoin · GitHub
342 2020-06-18T14:28:12  *** bitcoin-git has joined #bitcoin-core-dev
343 2020-06-18T14:28:12  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b8740d6737b4...c7ebab12f941
344 2020-06-18T14:28:13  <bitcoin-git> bitcoin/master a389ed5 Andrew Chow: walletdb: refactor Read, Write, Erase, and Exists into non-template func
345 2020-06-18T14:28:14  <bitcoin-git> bitcoin/master c7ebab1 MarcoFalke: Merge #19292: wallet: Refactor BerkeleyBatch Read, Write, Erase, and Exist...
346 2020-06-18T14:28:15  *** bitcoin-git has left #bitcoin-core-dev
347 2020-06-18T14:28:32  *** bitcoin-git has joined #bitcoin-core-dev
348 2020-06-18T14:28:32  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19292: wallet: Refactor BerkeleyBatch Read, Write, Erase, and Exists functions into non-template functions (master...refactor-bdb-read) https://github.com/bitcoin/bitcoin/pull/19292
349 2020-06-18T14:28:37  *** bitcoin-git has left #bitcoin-core-dev
350 2020-06-18T14:28:55  <wumpus> achow101: true, I do think that it's better to have a smaller PR on there if you have split up things anyway
351 2020-06-18T14:29:29  <achow101> next in line is 19308
352 2020-06-18T14:31:27  <wumpus> ok, I'll leave it to someone else to replace that, I'm done for it for a bit :)
353 2020-06-18T14:31:58  <achow101> i'll wait for the meeting
354 2020-06-18T14:44:50  <wumpus> nah already swapped it
355 2020-06-18T14:47:47  *** bitcoin-git has joined #bitcoin-core-dev
356 2020-06-18T14:47:48  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19320: wallet: Replace CDataStream& with Span<char> where possible (master...2006-walletSpan) https://github.com/bitcoin/bitcoin/pull/19320
357 2020-06-18T14:47:48  *** bitcoin-git has left #bitcoin-core-dev
358 2020-06-18T14:53:35  *** Guyver2 has joined #bitcoin-core-dev
359 2020-06-18T14:56:56  *** dr-orlovsky has quit IRC
360 2020-06-18T14:59:59  *** promag_ has joined #bitcoin-core-dev
361 2020-06-18T15:00:02  *** jackalope has quit IRC
362 2020-06-18T15:02:37  *** troygiorshev has quit IRC
363 2020-06-18T15:02:38  *** dr-orlovsky has joined #bitcoin-core-dev
364 2020-06-18T15:03:03  <wumpus> MarcoFalke: re:  #19033, you added the "waiting for author" tag, what is it waiting on?
365 2020-06-18T15:03:05  <gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
366 2020-06-18T15:03:23  *** troygiorshev has joined #bitcoin-core-dev
367 2020-06-18T15:03:42  *** S3RK has joined #bitcoin-core-dev
368 2020-06-18T15:04:47  *** promag_ has quit IRC
369 2020-06-18T15:05:26  <promag> for me to fix it
370 2020-06-18T15:08:12  *** S3RK has quit IRC
371 2020-06-18T15:10:41  <wumpus> it's broken? that wasn't clear to me
372 2020-06-18T15:11:02  <promag> yeah it is :(
373 2020-06-18T15:11:26  <wumpus> let's remove it from high priority for review for now, then
374 2020-06-18T15:11:36  <wumpus> doesn't make sense for people to review it if it's broken :)
375 2020-06-18T15:13:44  *** luke-jr has quit IRC
376 2020-06-18T15:16:38  *** luke-jr has joined #bitcoin-core-dev
377 2020-06-18T15:17:04  *** Talkless has joined #bitcoin-core-dev
378 2020-06-18T15:18:07  <wumpus> okay, yes I see why now
379 2020-06-18T15:21:53  *** kierank1 has joined #bitcoin-core-dev
380 2020-06-18T15:23:12  <wumpus> it's unfortunate that it turns out to be so difficult to get the http shutdown correct, I remember lots of times it was 'fixed', I wish libevent-http just came with a multi-threaded web server itself instead of us having to hack it on top of it
381 2020-06-18T15:23:54  *** Talkless has quit IRC
382 2020-06-18T15:24:10  <promag> wumpus: re HP, sure
383 2020-06-18T15:24:31  *** Talkless has joined #bitcoin-core-dev
384 2020-06-18T15:25:02  *** davec has quit IRC
385 2020-06-18T15:25:11  <promag> wumpus: there's also corner cases regarding shutdown and ongoing rpc responses
386 2020-06-18T15:25:16  *** davec has joined #bitcoin-core-dev
387 2020-06-18T15:25:22  *** Talkless has joined #bitcoin-core-dev
388 2020-06-18T15:25:36  <wumpus> yes, ther's always been
389 2020-06-18T15:25:36  *** troygiorshev has quit IRC
390 2020-06-18T15:25:53  <promag> and also not being able to discard lots of incoming requests
391 2020-06-18T15:25:53  *** troygiorshev has joined #bitcoin-core-dev
392 2020-06-18T15:26:46  <wumpus> or at the least, defer accept()
393 2020-06-18T15:27:31  <wumpus> but no it accepts every connection immediately without some kind of fd quota
394 2020-06-18T15:28:56  <wumpus> well, switching to it from boost::asio seemed like a good idea at the time (it at least solved some issues)
395 2020-06-18T15:34:21  *** braydonf has quit IRC
396 2020-06-18T15:34:37  <wumpus> I'll have a look at it too some time
397 2020-06-18T15:34:48  *** braydonf has joined #bitcoin-core-dev
398 2020-06-18T15:37:03  *** kabaum has joined #bitcoin-core-dev
399 2020-06-18T15:46:05  *** Pavlenex has joined #bitcoin-core-dev
400 2020-06-18T15:47:54  *** troygiorshev has quit IRC
401 2020-06-18T15:49:01  *** troygiorshev has joined #bitcoin-core-dev
402 2020-06-18T15:49:41  *** Pavlenex has quit IRC
403 2020-06-18T15:52:04  *** jarthur has joined #bitcoin-core-dev
404 2020-06-18T16:07:03  *** lightlike has joined #bitcoin-core-dev
405 2020-06-18T16:14:13  *** justanotheruser has quit IRC
406 2020-06-18T16:20:02  <luke-jr> #11082 rebased yet again
407 2020-06-18T16:20:04  <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
408 2020-06-18T16:24:23  *** vasild has quit IRC
409 2020-06-18T16:25:27  *** nobody123 has joined #bitcoin-core-dev
410 2020-06-18T16:25:49  *** vasild has joined #bitcoin-core-dev
411 2020-06-18T16:29:48  *** luke-jr has quit IRC
412 2020-06-18T16:30:09  *** luke-jr has joined #bitcoin-core-dev
413 2020-06-18T16:30:43  *** justanotheruser has joined #bitcoin-core-dev
414 2020-06-18T16:39:52  *** leinlawun[m] has joined #bitcoin-core-dev
415 2020-06-18T16:40:02  *** Kiminuo has joined #bitcoin-core-dev
416 2020-06-18T16:47:27  *** kristapsk has joined #bitcoin-core-dev
417 2020-06-18T16:47:57  *** jeremyrubin has quit IRC
418 2020-06-18T16:56:52  *** User0192 has joined #bitcoin-core-dev
419 2020-06-18T16:57:15  *** sipsorcery has quit IRC
420 2020-06-18T16:59:34  *** kabaum has quit IRC
421 2020-06-18T17:01:51  *** bitcoin-git has joined #bitcoin-core-dev
422 2020-06-18T17:01:52  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c7ebab12f941...0865a8881d39
423 2020-06-18T17:01:52  <bitcoin-git> bitcoin/master 25f3554 Hennadii Stepanov: scripted-diff: Make SeparatorStyle a scoped enum
424 2020-06-18T17:01:54  <bitcoin-git> bitcoin/master 0865a88 MarcoFalke: Merge bitcoin-core/gui#3: scripted-diff: Make SeparatorStyle a scoped enum...
425 2020-06-18T17:01:55  *** bitcoin-git has left #bitcoin-core-dev
426 2020-06-18T17:01:57  <MarcoFalke> Just merged the first pull from the gui repository. Hope nothing caught fire
427 2020-06-18T17:02:22  <achow101> oh noes my computer is on fire
428 2020-06-18T17:03:13  *** cryptapus has quit IRC
429 2020-06-18T17:03:52  *** cryptapus has joined #bitcoin-core-dev
430 2020-06-18T17:11:27  *** Dean_Guss has joined #bitcoin-core-dev
431 2020-06-18T17:19:18  <troygiorshev> does anyone have experience with our Optional?  I'm looking to use it with a CNetMessage but I'm worried about the performance.  Looks like it doesn't have move semantics until 1.56.0.  Has anyone run into this before?
432 2020-06-18T17:20:26  <provoostenator> So how does Gribble link to GUI issues now?
433 2020-06-18T17:21:48  <luke-jr> hrm, might be annoying to have a different # namespace :/
434 2020-06-18T17:23:18  <provoostenator> Maybe prefix it? E.g. #gui-2
435 2020-06-18T17:24:26  <MarcoFalke> In github the normalized and absolute identifier is "bitcoin-core/gui#3" or "bitcoin/bitcoin#3"
436 2020-06-18T17:24:30  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
437 2020-06-18T17:24:30  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
438 2020-06-18T17:24:38  <MarcoFalke> but indeed that seems a bit verbose for IRC
439 2020-06-18T17:24:49  <MarcoFalke> Might as well post the full link
440 2020-06-18T17:26:32  <provoostenator> Oh well at least the github normalized method works, TIL
441 2020-06-18T17:26:55  <provoostenator> Oh no it doesn't
442 2020-06-18T17:27:02  <MarcoFalke> not for gribble
443 2020-06-18T17:27:24  *** bitdex has quit IRC
444 2020-06-18T17:31:45  *** edd has joined #bitcoin-core-dev
445 2020-06-18T17:39:50  *** sipsorcery has joined #bitcoin-core-dev
446 2020-06-18T17:40:00  *** promag_ has joined #bitcoin-core-dev
447 2020-06-18T17:41:04  <luke-jr> gui#3?
448 2020-06-18T17:41:06  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
449 2020-06-18T17:41:21  <luke-jr> someone should fix gribble for whatever we do :P
450 2020-06-18T17:41:40  *** S3RK has joined #bitcoin-core-dev
451 2020-06-18T17:41:46  <provoostenator> Where does Gribble's source live?
452 2020-06-18T17:42:04  <luke-jr> nanotube's repo on gitlab iirc
453 2020-06-18T17:44:20  *** promag_ has quit IRC
454 2020-06-18T17:45:54  *** S3RK has quit IRC
455 2020-06-18T17:55:38  *** guest534543 has joined #bitcoin-core-dev
456 2020-06-18T17:59:10  *** Kiminuo has quit IRC
457 2020-06-18T17:59:14  <dongcarl> Looks like I have missed a fun, popcorn-worthy convo above, just to add what I know: the mrustc support is solid, and development of it is very active in Guix, and just 6 days after the release of mrustc 0.9 (equiv of rustc 1.29.0), patches were being reviewed for taking advantage of the newer version and shortening the bootstrap chain by 10 steps
458 2020-06-18T17:59:14  <dongcarl> (1.19.0...1.29.0).
459 2020-06-18T17:59:14  <dongcarl> The current method crawls through one minor version at a time (which is probably the safe way to do it), and there's a substantial number of rust package users in Guix who will notice if the bootstrap chain breaks.
460 2020-06-18T17:59:17  *** Kiminuo has joined #bitcoin-core-dev
461 2020-06-18T18:00:02  *** kierank1 has quit IRC
462 2020-06-18T18:00:19  *** guest534543 has quit IRC
463 2020-06-18T18:07:51  *** Guyver2_ has joined #bitcoin-core-dev
464 2020-06-18T18:09:34  *** Guyver2 has quit IRC
465 2020-06-18T18:09:42  *** Guyver2_ is now known as Guyver2
466 2020-06-18T18:12:22  *** bitcoin-git has joined #bitcoin-core-dev
467 2020-06-18T18:12:22  <bitcoin-git> [bitcoin] Sjors closed pull request #16546: External signer support - Wallet Box edition (master...2019/08/hww-box2) https://github.com/bitcoin/bitcoin/pull/16546
468 2020-06-18T18:12:24  *** bitcoin-git has left #bitcoin-core-dev
469 2020-06-18T18:12:42  *** bitcoin-git has joined #bitcoin-core-dev
470 2020-06-18T18:12:42  <bitcoin-git> [bitcoin] Sjors reopened pull request #16546: External signer support - Wallet Box edition (master...2019/08/hww-box2) https://github.com/bitcoin/bitcoin/pull/16546
471 2020-06-18T18:12:45  *** bitcoin-git has left #bitcoin-core-dev
472 2020-06-18T18:12:58  <provoostenator> ^ oops, wrong one
473 2020-06-18T18:16:57  <provoostenator> I moved the HWW GUI PR to  the GUI repo, since there wasn't much discussion on it yet
474 2020-06-18T18:17:57  *** jonatack has quit IRC
475 2020-06-18T18:19:39  <moneyball> #proposedmeetingtopic taproot implementation plan; is v0.21 realistic?
476 2020-06-18T18:20:08  *** jonatack has joined #bitcoin-core-dev
477 2020-06-18T18:21:46  *** bitcoin-git has joined #bitcoin-core-dev
478 2020-06-18T18:21:47  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/0865a8881d39...c2bcb99c1d11
479 2020-06-18T18:21:47  <bitcoin-git> bitcoin/master faceed7 MarcoFalke: doc: Add redirect for GUI issues and pull requests
480 2020-06-18T18:21:48  <bitcoin-git> bitcoin/master 66666d5 MarcoFalke: doc: Mention repo split in the READMEs
481 2020-06-18T18:21:48  <bitcoin-git> bitcoin/master c2bcb99 MarcoFalke: Merge #19071: doc: Separate repository for the gui
482 2020-06-18T18:21:50  *** bitcoin-git has left #bitcoin-core-dev
483 2020-06-18T18:22:15  *** meh` has joined #bitcoin-core-dev
484 2020-06-18T18:22:16  *** bitcoin-git has joined #bitcoin-core-dev
485 2020-06-18T18:22:16  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19071: doc: Separate repository for the gui (master...2005-splitRepoGui) https://github.com/bitcoin/bitcoin/pull/19071
486 2020-06-18T18:22:17  *** bitcoin-git has left #bitcoin-core-dev
487 2020-06-18T18:43:46  *** bitcoin-git has joined #bitcoin-core-dev
488 2020-06-18T18:43:46  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19321: ci: Run asan ci config on cirrus (master...2006-ciCirrusAsan) https://github.com/bitcoin/bitcoin/pull/19321
489 2020-06-18T18:43:48  *** bitcoin-git has left #bitcoin-core-dev
490 2020-06-18T19:00:14  <wumpus> #startmeeting
491 2020-06-18T19:00:14  <lightningbot> Meeting started Thu Jun 18 19:00:14 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
492 2020-06-18T19:00:14  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
493 2020-06-18T19:00:17  <jnewbery> hi
494 2020-06-18T19:00:19  <moneyball> hi
495 2020-06-18T19:00:30  <cfields> hi
496 2020-06-18T19:00:37  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
497 2020-06-18T19:00:39  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
498 2020-06-18T19:00:44  <sipa> hi
499 2020-06-18T19:00:46  <MarcoFalke> hi
500 2020-06-18T19:00:54  <achow101> hi
501 2020-06-18T19:00:59  <fjahr> Hi
502 2020-06-18T19:01:24  <ajonas> hi
503 2020-06-18T19:01:46  <meshcollider> hi
504 2020-06-18T19:01:51  <wumpus> one proposed meeting topic for today: taproot implementation plan (moneyball)
505 2020-06-18T19:01:56  <wumpus> any last minute topics?
506 2020-06-18T19:02:11  <ariard> hi
507 2020-06-18T19:02:29  <luke-jr> hi
508 2020-06-18T19:03:00  *** jeremyrubin has joined #bitcoin-core-dev
509 2020-06-18T19:03:01  <kanzure> hi
510 2020-06-18T19:03:05  <wumpus> #topic High priority for review
511 2020-06-18T19:03:15  <jeremyrubin> hola
512 2020-06-18T19:03:22  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  currently: 12 blockers, 3 chasing concept ACK
513 2020-06-18T19:03:31  <wumpus> anything to add/remove?
514 2020-06-18T19:03:33  <MarcoFalke> I'd like to add #19028
515 2020-06-18T19:03:35  <gribble> https://github.com/bitcoin/bitcoin/issues/19028 | test: Set -logthreadnames in unit tests by MarcoFalke · Pull Request #19028 · bitcoin/bitcoin · GitHub
516 2020-06-18T19:03:53  <luke-jr> wumpus: #18818 should probably be under Bugfixes, not Blockers? not sure on categorisation
517 2020-06-18T19:03:56  <gribble> https://github.com/bitcoin/bitcoin/issues/18818 | Fix release tarball generated by gitian by luke-jr · Pull Request #18818 · bitcoin/bitcoin · GitHub
518 2020-06-18T19:04:18  *** gzhao408 has joined #bitcoin-core-dev
519 2020-06-18T19:04:30  <wumpus> MarcoFalke: added
520 2020-06-18T19:04:33  <jamesob> hi
521 2020-06-18T19:04:35  <MarcoFalke> thx
522 2020-06-18T19:04:41  <wumpus> luke-jr: ok moved
523 2020-06-18T19:05:02  <cfields> luke-jr: gah, sorry, forgot about that one. Will take a look regardless of how it's tagged.
524 2020-06-18T19:05:10  <luke-jr> cfields: thanks
525 2020-06-18T19:05:19  <jonasschnelli> hi
526 2020-06-18T19:05:20  <jamesob> tangential to 19028, maybe we should set logthreadnames=1 by default if we can show there isn't a performance hit
527 2020-06-18T19:06:05  <luke-jr> I did notice #18818 was insufficient for Knots, but only because Knots is distributing files rendered from SVGs at dist-time - shouldn't affect Core's needs
528 2020-06-18T19:06:07  <gribble> https://github.com/bitcoin/bitcoin/issues/18818 | Fix release tarball generated by gitian by luke-jr · Pull Request #18818 · bitcoin/bitcoin · GitHub
529 2020-06-18T19:06:30  <wumpus> no strong opinion, but I'm not sure the thread names are useful to most non-developers
530 2020-06-18T19:06:51  <wumpus> for running the tests it makes sense though
531 2020-06-18T19:07:46  <jamesob> I'm thinking it could be useful when we ask for debug.logs in bug reports
532 2020-06-18T19:07:57  <wumpus> but we had a similar discussion at the time about adding microseconds by default to the log - like okay, for some things it might be useful, but it just widens the log messages
533 2020-06-18T19:07:59  <dongcarl> luke-jr: I think after exploring a bit in the `tarfiles` python module (quite powerful, and shipped with python by default), we can use it to "union" the `make dist` archive, and the `git-archive` archives, happy for yours to be merged in first, just wanted to mention it here.
534 2020-06-18T19:08:50  <luke-jr> dongcarl: GNU tar can do it too, but I'm not sure it's worth the complexity
535 2020-06-18T19:08:56  <wumpus> jamesob: can you show a specific example where it helps? are there many log messages that are ambigious as to where they originate?
536 2020-06-18T19:09:09  <wumpus> (especially of those enabled by default)
537 2020-06-18T19:09:16  <jamesob> wumpus: fair point, will raise again if I can
538 2020-06-18T19:09:54  <wumpus> jamesob: thanks
539 2020-06-18T19:10:22  <dongcarl> luke-jr: last time I tried it with GNU tar I remember it had weird behaviour, anyway, I'll shut up until I have code :-)
540 2020-06-18T19:10:45  <luke-jr> dongcarl: also, I had originally made 18818 to do that, but I was uncertain of the ramifications of having different timestamps for the modified files
541 2020-06-18T19:11:30  <luke-jr> (iirc, git-archive is using a timestamp potentially after the gitian reference timestamp, so the source files would appear "newer" possibly)
542 2020-06-18T19:11:33  <jnewbery> I don't see any downside to logging thread names by default (unless there's a performance hit). It does make tracing what's going on in the log files a lot easier
543 2020-06-18T19:12:13  <wumpus> jnewbery: do you have any specific examples where it wouldh elp or would have helped?
544 2020-06-18T19:12:48  <dongcarl> luke-jr: true, but with the `tarfiles` python module we can make decisions on that programmatically ourselves, instead of GNU tar doing what its default conflict resolution is
545 2020-06-18T19:12:56  <wumpus> the default amount of logging shouldn't be a performance hit in any way, adding a field isn't going to make it noticably worse
546 2020-06-18T19:13:31  <wumpus> so I'm more concerned about making the log unneceessarily spammy/verbose than performance hit here
547 2020-06-18T19:13:55  <gwillen> thread names are non-unique, right? it might be nice to log thread IDs in addition or instead.
548 2020-06-18T19:14:15  <gwillen> otherwise all the worker threads will log the same name and it still won't help to tell them apart.
549 2020-06-18T19:14:29  <wumpus> all the names are unique
550 2020-06-18T19:14:32  <jamesob> gwillen: I think they're unique at the moment; those that aren't have an increasing suffix
551 2020-06-18T19:14:45  <gwillen> ah okay great, nevermind
552 2020-06-18T19:15:08  <jnewbery> wumpus: it's just easier when you're eyeballing the log to get an idea of what's going on. Obviously if you know or look up the location of every log call in the source, you can work it out.
553 2020-06-18T19:15:25  <sipa> i just git grep the log message :)
554 2020-06-18T19:15:43  <wumpus> sipa: same, it's the only way to be sure :) log messages tend to be unique enough
555 2020-06-18T19:15:46  <sipa> (no objection to logging thread names by default if it has no performance impact, though)
556 2020-06-18T19:17:05  <provoostenator> (hi)
557 2020-06-18T19:17:07  <wumpus> but if everyone wants to add tghat field and I'm the only one slightly sceptical about it, just add it, no strong opinion
558 2020-06-18T19:17:59  <sipa> let's first benchmark?
559 2020-06-18T19:18:00  <jnewbery> validation interface logging is also super helpful if you haven't played around with it. It's nice to see when the signals being added to the callback queue and when they're serviced by the scheduler thread
560 2020-06-18T19:18:10  <wumpus> if looking up a thread name really causes a performance hit something is really wrong btw
561 2020-06-18T19:18:34  <wumpus> if logging is on the performance critical path (with the default amount of logging) in the first place
562 2020-06-18T19:18:38  <sipa> agree, but haven't we had surprising experiencing with this in the past?
563 2020-06-18T19:18:42  <jamesob> wumpus: yeah I reckon you're right. couldn't hurt to see if something's really wrong though
564 2020-06-18T19:19:03  <jamesob> MarcoFalke has proposed to add a logging benchmark re: the previous issue, which I think is still open?
565 2020-06-18T19:19:05  <sipa> make it it isn't looking up the thread name for log categories that are disbaled
566 2020-06-18T19:19:23  <wumpus> sipa: there was some worry about enabling TLS causing a performance hit (independent of whether it was actually used frequently)
567 2020-06-18T19:19:28  <wumpus> sipa: but this turned out not to be the case
568 2020-06-18T19:19:53  <wumpus> (TLS as in Thread Local Storage, not the other thing)
569 2020-06-18T19:20:07  <MarcoFalke> jup the log bench is still open
570 2020-06-18T19:20:19  <MarcoFalke> imo it can be merged. The risk should be zero
571 2020-06-18T19:20:22  <wumpus> I implemented the thread name lookup using a map but then it turned out to not be the problem at all
572 2020-06-18T19:20:30  <jamesob> MarcoFalke: agree, think I've acked it
573 2020-06-18T19:20:31  <sipa> ok
574 2020-06-18T19:20:32  <wumpus> in any case please do not log on the critical path
575 2020-06-18T19:20:41  <wumpus> definitely not by default (with debug flags is fine)
576 2020-06-18T19:21:19  <wumpus> but if it's logging in an inner loop or something that really affects, say, validation performance, that's not how logigng should be used
577 2020-06-18T19:22:07  <wumpus> it's why I find a logging benchmark kind of weird, we're not trying to optimize logging throughput
578 2020-06-18T19:23:08  <jamesob> it's less for optimization and more just an assurance we're not doing anything totally dumb
579 2020-06-18T19:23:24  <jnewbery> jamesob: agree
580 2020-06-18T19:23:32  <MarcoFalke> the benchmark also checks that *disabled* logs don't affect performance
581 2020-06-18T19:23:45  <MarcoFalke> maybe I should call is nolog bench
582 2020-06-18T19:23:50  <MarcoFalke> *it
583 2020-06-18T19:23:52  <wumpus> that's a good idea
584 2020-06-18T19:24:50  <wumpus> logprintf arguments shouldn't even be evaluated in that case
585 2020-06-18T19:25:06  <MarcoFalke> jup (I broke that once)
586 2020-06-18T19:25:09  * MarcoFalke hides
587 2020-06-18T19:25:24  <wumpus> heh
588 2020-06-18T19:26:31  <wumpus> #topic Taproot implementation plan (moneyball)
589 2020-06-18T19:26:48  <moneyball> Hi everyone, I wanted to check in here to get a sense for whether contributors are imagining the taproot implementation making it into v.21 or not. If yes, then it is likely the case that there needs to be pretty extreme focus in order to make it in time.
590 2020-06-18T19:27:02  <moneyball> Here is a draft document that compiles a list of things that (arguably) need to be done for taproot to be complete. Would love feedback on this: is everything listed required? Is anything missing? https://docs.google.com/document/d/1DAMV9csW9k7vDh118_e65-IPJd4AcCImkvsB0b3gbNw/edit
591 2020-06-18T19:28:05  *** wharm has joined #bitcoin-core-dev
592 2020-06-18T19:28:21  <moneyball> (feel free to comment in the doc)
593 2020-06-18T19:28:26  <moneyball> or here
594 2020-06-18T19:28:41  <luke-jr> moneyball: activation isn't required
595 2020-06-18T19:29:05  <moneyball> ok
596 2020-06-18T19:29:09  <sipa> typically our process would be merging in a 0.x.0 release, and then implementating activation whenever in a 0.x.1
597 2020-06-18T19:29:22  <wumpus> associated PR would be #17977 I guess
598 2020-06-18T19:29:25  <gribble> https://github.com/bitcoin/bitcoin/issues/17977 | [WIP] Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #17977 · bitcoin/bitcoin · GitHub
599 2020-06-18T19:29:35  <luke-jr> signet isn't required
600 2020-06-18T19:29:47  <jeremyrubin> yeah I think we don't usually aim for major releases to have forks, should be a minor
601 2020-06-18T19:30:08  <jeremyrubin> So there really isn't any release window time crunch to push for
602 2020-06-18T19:30:29  <jeremyrubin> But I agree in principal with trying to figure out a path for activation
603 2020-06-18T19:30:34  <moneyball> luke-jr, sipa: well there is including the activation code and then separately configuring the activation parameters. right?
604 2020-06-18T19:30:50  <sipa> moneyball: depends on the activation mechanism
605 2020-06-18T19:31:02  <sipa> if a new activation mechanism needs code, then yes that needs code :)
606 2020-06-18T19:31:07  *** vasild has quit IRC
607 2020-06-18T19:31:08  <moneyball> ha :)
608 2020-06-18T19:31:16  *** luke-jr has quit IRC
609 2020-06-18T19:31:19  *** vasild has joined #bitcoin-core-dev
610 2020-06-18T19:31:41  <jeremyrubin> One thing I'm curious to look at is if the recent changes to the sighash & the recent hardware wallet issues are informing or suggesting any other sighash changes we should be doing concurrently.
611 2020-06-18T19:31:49  <moneyball> ok my understanding of that is that a new activation method is planned to be proposed to the mailing list, and IF there is consensus around that, then yes, that code would need to be added to Core
612 2020-06-18T19:31:59  <ariard> haven't reviewed yet 17977 yet, what's the test coverage of it ? do we need to add more support for testing taproot tree composition in fuzzing or test framework?
613 2020-06-18T19:32:50  <sipa> ariard: the python code is effectively an extensive generate-random cases with lots of edge cases, and compare the python-created signatures against block/tx validation
614 2020-06-18T19:32:57  <sipa> ariard: more testing is absolutely welcome of course
615 2020-06-18T19:33:05  <jeremyrubin> moneyball: fwiw I've talked with a bunch of contributors and I think Modern Soft Fork Activation is far from a universally loved approach. That conversation should probably be had more exentsively before you hitch taproot onto that wagon
616 2020-06-18T19:33:11  <sipa> moneyball: that sounds like it needs ML discussion first
617 2020-06-18T19:33:13  <moneyball> luke-jr: ok i guess i understand that signet is not required per se, but, some kind of test plan would be. has there been much discussion and consensus for how to test this in Core?
618 2020-06-18T19:33:35  <moneyball> sipa: yes
619 2020-06-18T19:33:57  <sipa> it's hard to ask people here what they think about an approach that hasn't even been published yet
620 2020-06-18T19:34:38  *** luke-jr has joined #bitcoin-core-dev
621 2020-06-18T19:35:03  <moneyball> my hope was to focus on non-activation method work needed in Core
622 2020-06-18T19:35:11  <sipa> yeah, that makes sense
623 2020-06-18T19:35:13  <moneyball> perhaps it was a mistake having line item one in that doc
624 2020-06-18T19:35:41  <provoostenator> Although not required, it would be really nice to have a Taproot Signet.
625 2020-06-18T19:36:41  <sipa> i think implementation wise that list pretty much covers it
626 2020-06-18T19:36:55  <moneyball> ok i just deleted that line item from the doc :)
627 2020-06-18T19:37:32  <moneyball> i would love to hear more discussion about testing approach. what is there general agreement on? what are open questions that need to be discussed?
628 2020-06-18T19:37:43  *** andrewtoth has quit IRC
629 2020-06-18T19:39:39  <jeremyrubin> I think that running on signet doesn't really do anything by itself
630 2020-06-18T19:39:40  <luke-jr> provoostenator: sure, I was just answering moneyball's request for things not required :P
631 2020-06-18T19:39:48  <jeremyrubin> The real challenge is to get integration tests somewhere
632 2020-06-18T19:39:58  <provoostenator> moneyball: having a signet explorer somewhere can help with testing too
633 2020-06-18T19:40:03  *** promag_ has joined #bitcoin-core-dev
634 2020-06-18T19:40:03  <jeremyrubin> E.g., people attempting to integrate it and acutally use taproot
635 2020-06-18T19:40:31  <jeremyrubin> I would put more stock in, e.g., an LND fork with taproot support against regtest than signet (but signet would be great too)
636 2020-06-18T19:40:35  <sipa> jeremyrubin: that would be great, but i fear that it's a bit of a chicken and egg problem
637 2020-06-18T19:40:39  <luke-jr> segnet worked okay AFAIR
638 2020-06-18T19:40:40  <luke-jr> testing should be before merge anyway
639 2020-06-18T19:41:06  <provoostenator> luke-jr: signet could be in a release and completely changed in the next release though
640 2020-06-18T19:41:20  <ariard> sipa: does feature_taproot.py attempt any coverage-guided like a fuzzer?
641 2020-06-18T19:41:22  <sipa> yeah, if not signet we can create a (normal) testnet with it activated too (i think signet would be preferable, but if it somehow doesn't make it in time, i don't think that would be a blocker)
642 2020-06-18T19:41:25  <sipa> ariard: no
643 2020-06-18T19:41:27  <provoostenator> Or we could release a taproot signet binary seperately
644 2020-06-18T19:41:40  <jeremyrubin> sipa: indeed it's hard. I think if signet comes out then people will integrate test against it
645 2020-06-18T19:41:54  <luke-jr> provoostenator: that seems like a given
646 2020-06-18T19:42:00  <jeremyrubin> Just more noting that just getting signet out doesn't do anything in terms of progress alone
647 2020-06-18T19:42:19  <luke-jr> provoostenator: otherwise we'd be merging taproot before testing it
648 2020-06-18T19:42:19  <sipa> ariard: fuzzing definitely makes sense to test for things like memory violations and UB
649 2020-06-18T19:42:36  <wumpus> well if it helps getting more attention to testing taproot, that's progress
650 2020-06-18T19:42:44  <sipa> luke-jr: i think there are different stages of testing, and different stages of getting attention to it
651 2020-06-18T19:43:04  <ariard> sipa: right you may have nast edges cases we wide trees and oversized tapscripts?
652 2020-06-18T19:43:22  *** bitcoin-git has joined #bitcoin-core-dev
653 2020-06-18T19:43:22  <bitcoin-git> [bitcoin] jnewbery opened pull request #19322: [net] split PushInventory() (master...2020-06-split-push-inventory) https://github.com/bitcoin/bitcoin/pull/19322
654 2020-06-18T19:43:25  *** bitcoin-git has left #bitcoin-core-dev
655 2020-06-18T19:43:26  <sipa> ariard: there is a test for the max depth of the tree, if that's what you're asking for
656 2020-06-18T19:43:37  <sipa> luke-jr: and at some point it will need to be merged for people to test against a kind of testnet, which hopefully informs discussions on activation
657 2020-06-18T19:43:43  <ariard> okay great
658 2020-06-18T19:44:02  <sipa> it can't be testnet/signet tested before being merged - but different kinds of testing are obviously necessary before that point
659 2020-06-18T19:44:15  <jeremyrubin> I think the issue with signet is it doesn't add a new message type/storage place for the signatures
660 2020-06-18T19:44:24  <jeremyrubin> I understand why kallewoof did it that way and it makes sense
661 2020-06-18T19:44:36  <jeremyrubin> But it just makes it difficult for people to want to merge it
662 2020-06-18T19:44:40  <sipa> jeremyrubin: this seems orthogonal
663 2020-06-18T19:44:54  <jeremyrubin> slightly
664 2020-06-18T19:45:12  <sipa> i don't think taproot should be blocked by signet in any case
665 2020-06-18T19:45:16  <luke-jr> sipa: but I think we want tapnet before merging?
666 2020-06-18T19:45:18  <jonatack> hi... fwiw MarcoFalke, fjahr, brakmic and I were testing signet for some time and going back and forth with kallewoof on improvements... iirc it's the PR is in pretty good shape
667 2020-06-18T19:45:23  <sipa> luke-jr: perhaps
668 2020-06-18T19:45:31  <sipa> luke-jr: i think that may make sense
669 2020-06-18T19:45:39  <jeremyrubin> What about just flag daying testnet?
670 2020-06-18T19:45:54  <sipa> there aren't any associated P2P changes, so i think the need for that level of testing may be lower than with segwit
671 2020-06-18T19:46:19  <wumpus> as said, testnet needs to be compatible between releases, so there's not much scope for experimentation there
672 2020-06-18T19:46:29  * luke-jr glad to hear brakmic hasn't given up on us completely :x
673 2020-06-18T19:46:36  <luke-jr> wumpus: doesn't need to be..
674 2020-06-18T19:47:43  <ariard> do we expect to introduce new standard rules on taproot witness?
675 2020-06-18T19:47:45  <wumpus> I mean, I think there should be a flag day on testnet before considering activation on mainnet, but only after the protocol and implementation is virtually finalized
676 2020-06-18T19:47:49  <MarcoFalke> lol, wasn't testnet hardforked for segwit?
677 2020-06-18T19:48:21  <MarcoFalke> I mean silent hardfork. "hardfork" is probably the wrong word
678 2020-06-18T19:48:22  <jeremyrubin> wumpus: ah I see. I thought we can just reset testnet if we want. Does anyone care?
679 2020-06-18T19:48:41  <jeremyrubin> wumpus: you can also make a soft fork flag day that a rule is enforced for N blocks only
680 2020-06-18T19:48:43  <wumpus> jeremyrubin: it's possible but should probably be avoided
681 2020-06-18T19:48:58  <sipa> ariard: yes, though they're pretty weak; upgradability (annex, new leaf versions, ...), and max stack item size
682 2020-06-18T19:49:03  <sipa> ariard: https://github.com/bitcoin/bitcoin/pull/17977/commits/fa2b4fded614ef2424404b22a07bfbdb2d77ea6c
683 2020-06-18T19:49:18  <wumpus> doing things like 'reset testnet' isn't going to make changes more popular
684 2020-06-18T19:49:36  <jeremyrubin> wumpus: what about flag day testnet and rule only valid for 6 mos of blocks?
685 2020-06-18T19:50:30  <provoostenator> I find it hard to believe a non-trivial change to testnet is more difficult than signet.
686 2020-06-18T19:50:47  <jeremyrubin> Would make it easier to do sort of rolling releases on testnet if there's a worry about wanting to permanently be in step with core
687 2020-06-18T19:50:58  <sipa> meh, we can just create specialized testnets
688 2020-06-18T19:51:03  <sipa> before or after merge
689 2020-06-18T19:51:14  <luke-jr> contention to resetting testnet, is a reason to reset testnet :P
690 2020-06-18T19:51:24  <sipa> testnet has compatbility requirements
691 2020-06-18T19:51:29  <sipa> specialized things don't
692 2020-06-18T19:52:03  <wumpus> right, a specialized testnet would make sense, that's basically what signet is anyway (except the mining part)
693 2020-06-18T19:52:14  <sipa> indeed
694 2020-06-18T19:52:22  <moneyball> do we consider this PR required for taproot? https://github.com/bitcoin/bitcoin/pull/18044
695 2020-06-18T19:52:50  <moneyball> and this one? https://github.com/bitcoin/bitcoin/pull/19184
696 2020-06-18T19:52:50  <sipa> moneyball: i believe sdaftuar has some thoughts on that
697 2020-06-18T19:53:05  <ariard> sipa: indeed all of them are constraints on new data structure so no risk to tamper with network/break existent applications
698 2020-06-18T19:54:02  <jeremyrubin> network stuff isn't required
699 2020-06-18T19:54:06  <jeremyrubin> It can be done after
700 2020-06-18T19:54:18  <sipa> jeremyrubin: read the wtxid relay PR
701 2020-06-18T19:54:24  <sipa> it gives a justification
702 2020-06-18T19:55:23  <ariard> right because v0 segwit nodes are going to waste bandwidth constantly redownloading taproot txn they can't verify
703 2020-06-18T19:55:38  <sipa> indeed
704 2020-06-18T19:55:57  <sipa> this depends on how upgraded nodes are at the time of activation of course
705 2020-06-18T19:56:15  <sipa> so it may not be a big issue, but having a way to reduce that impact beforehand sounds like an improvement
706 2020-06-18T19:56:31  <ariard> ofc how long it takes to get 80% of segwit nodes ? or similar number based on previous forks?
707 2020-06-18T19:56:39  <jeremyrubin> yeah I am familiar. It's not great, but I personally don't think it's blocking
708 2020-06-18T19:56:57  <sipa> ok
709 2020-06-18T19:57:18  <jeremyrubin> I could be wrong on that though
710 2020-06-18T19:57:50  <sipa> moneyball: i think wtxid could be done before 19184
711 2020-06-18T19:58:10  <sipa> (but i'm obviously biased in liking 19184 to get in)
712 2020-06-18T19:58:20  <ariard> jeremyrubin: don't you have a bad effect as we see more taproot txn ande nodes relaying them the cost is increasing non-linearly for non-upgraded nodes?
713 2020-06-18T19:58:34  <wumpus> meeting time about to end
714 2020-06-18T19:58:50  <sipa> ariard: well, it's linear, but with a possibly big constant factor
715 2020-06-18T19:59:09  <moneyball> ok thank you for the feedback. this has been valuable. lots to follow-up on though!
716 2020-06-18T20:00:11  *** promag_ has quit IRC
717 2020-06-18T20:00:18  <wumpus> #endmeeting
718 2020-06-18T20:00:18  <lightningbot> Meeting ended Thu Jun 18 20:00:18 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
719 2020-06-18T20:00:18  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-18-19.00.html
720 2020-06-18T20:00:18  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-18-19.00.txt
721 2020-06-18T20:00:18  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-18-19.00.log.html
722 2020-06-18T20:00:26  *** Kiminuo has quit IRC
723 2020-06-18T20:00:53  *** bitcoin-git has joined #bitcoin-core-dev
724 2020-06-18T20:00:53  <bitcoin-git> [bitcoin] hebasto opened pull request #19323: gui: Fix regression in *txoutset* in GUI console (master...200618-utxo) https://github.com/bitcoin/bitcoin/pull/19323
725 2020-06-18T20:00:54  *** bitcoin-git has left #bitcoin-core-dev
726 2020-06-18T20:01:09  *** hebasto has quit IRC
727 2020-06-18T20:05:47  *** hebasto has joined #bitcoin-core-dev
728 2020-06-18T20:07:13  *** hebasto has joined #bitcoin-core-dev
729 2020-06-18T20:07:36  *** promag_ has joined #bitcoin-core-dev
730 2020-06-18T20:07:57  *** hebasto has quit IRC
731 2020-06-18T20:08:15  *** hebasto has joined #bitcoin-core-dev
732 2020-06-18T20:10:46  *** hebasto has quit IRC
733 2020-06-18T20:14:34  *** hebasto has joined #bitcoin-core-dev
734 2020-06-18T20:15:47  <jeremyrubin> I'll retract on 18044 being required; I was quibbling over whether or not we could release without it or whether we should. We should definitely release with a fix, I just don't think it's required insofar as it's a blocker for e.g. testnet
735 2020-06-18T20:21:59  <hebasto> MarcoFalke: could you suggest a comment for #19323?
736 2020-06-18T20:22:00  <gribble> https://github.com/bitcoin/bitcoin/issues/19323 | gui: Fix regression in *txoutset* in GUI console by hebasto · Pull Request #19323 · bitcoin/bitcoin · GitHub
737 2020-06-18T20:31:50  *** bitcoin-git has joined #bitcoin-core-dev
738 2020-06-18T20:31:52  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/c2bcb99c1d11...dbd7a91fdf3f
739 2020-06-18T20:31:53  <bitcoin-git> bitcoin/master 45c08f8 Andrew Chow: Add Create*WalletDatabase functions
740 2020-06-18T20:31:53  <bitcoin-git> bitcoin/master d6045d0 Andrew Chow: scripted-diff: Replace WalletDatabase::Create* with CreateWalletDatabase
741 2020-06-18T20:31:54  <bitcoin-git> bitcoin/master da7a83c Andrew Chow: Remove WalletDatabase::Create, CreateMock, and CreateDummy
742 2020-06-18T20:31:56  *** bitcoin-git has left #bitcoin-core-dev
743 2020-06-18T20:32:10  *** bitcoin-git has joined #bitcoin-core-dev
744 2020-06-18T20:32:11  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19310: wallet: BerkeleyDatabase make BerkeleyDatabase::Create, CreateMock, and CreateDummy non-static functions (master...bdb-refactor-create) https://github.com/bitcoin/bitcoin/pull/19310
745 2020-06-18T20:32:12  *** bitcoin-git has left #bitcoin-core-dev
746 2020-06-18T20:38:38  *** owowo has quit IRC
747 2020-06-18T20:39:18  *** promag_ has quit IRC
748 2020-06-18T20:47:20  *** owowo has joined #bitcoin-core-dev
749 2020-06-18T20:47:30  *** roconnor_ has left #bitcoin-core-dev
750 2020-06-18T20:47:44  *** roconnor_ has quit IRC
751 2020-06-18T20:48:50  *** harrigan has quit IRC
752 2020-06-18T20:49:00  *** harrigan has joined #bitcoin-core-dev
753 2020-06-18T20:49:23  *** roconnor has joined #bitcoin-core-dev
754 2020-06-18T20:51:53  *** dgenr8 has quit IRC
755 2020-06-18T20:53:43  *** Guyver2 has quit IRC
756 2020-06-18T20:56:02  *** nobody123 has quit IRC
757 2020-06-18T20:58:47  *** lightlike has quit IRC
758 2020-06-18T21:00:01  *** meh` has quit IRC
759 2020-06-18T21:02:54  *** bitcoin-git has joined #bitcoin-core-dev
760 2020-06-18T21:02:54  <bitcoin-git> [bitcoin] achow101 opened pull request #19324: wallet: Move BerkeleyBatch static functions to BerkeleyDatabase (master...bdb-batch-rm-statics) https://github.com/bitcoin/bitcoin/pull/19324
761 2020-06-18T21:03:05  *** bitcoin-git has left #bitcoin-core-dev
762 2020-06-18T21:03:19  *** bitcoin-git has joined #bitcoin-core-dev
763 2020-06-18T21:03:19  <bitcoin-git> [bitcoin] achow101 opened pull request #19325: wallet: Refactor BerkeleyDatabase to introduce DatabaseBatch abstract class (master...bdb-add-dbbatch) https://github.com/bitcoin/bitcoin/pull/19325
764 2020-06-18T21:03:20  *** bitcoin-git has left #bitcoin-core-dev
765 2020-06-18T21:04:50  *** dgenr8 has joined #bitcoin-core-dev
766 2020-06-18T21:10:42  *** Highway62 has joined #bitcoin-core-dev
767 2020-06-18T21:11:35  *** Highway61 has quit IRC
768 2020-06-18T21:12:17  *** Highway62 is now known as Highway61
769 2020-06-18T21:17:07  *** Highway62 has joined #bitcoin-core-dev
770 2020-06-18T21:18:32  *** Highway61 has quit IRC
771 2020-06-18T21:18:32  *** Highway62 is now known as Highway61
772 2020-06-18T21:21:01  *** promag_ has joined #bitcoin-core-dev
773 2020-06-18T21:22:23  *** Mikaku1 has joined #bitcoin-core-dev
774 2020-06-18T21:23:48  <dongcarl> Can someone with the right permissions move https://github.com/theuni/apple-sdk-tools over to the bitcoin-core org?
775 2020-06-18T21:24:51  <achow101> dongcarl: the current repo owner needs to initiaite it. then a bitcoin-core admin needs to approve it
776 2020-06-18T21:25:00  <dongcarl> I see
777 2020-06-18T21:25:09  <dongcarl> cfields: Could you initiate it?
778 2020-06-18T21:25:54  <achow101> oh and the repo owner needs to have create permissions in the bitcoin-core org
779 2020-06-18T21:25:58  <achow101> forgot the most important part
780 2020-06-18T21:26:51  <achow101> when I moved HWI, wumpus had to grant some permission to all members, then remove that permission
781 2020-06-18T21:27:27  <dongcarl> :-/
782 2020-06-18T21:27:44  <dongcarl> Seems easier just to start afresh and push to the repo?
783 2020-06-18T21:27:58  <achow101> then you lose any existing issues and PRs
784 2020-06-18T21:28:25  *** jarthur has quit IRC
785 2020-06-18T21:29:15  <cfields> It's just 1 file :p
786 2020-06-18T21:30:50  <achow101> maybe just add it to the packaging repo then? it's kind of packaging related
787 2020-06-18T21:33:21  <cfields> I have absolutely no preference. I only created a repo for it because I hoped someone better with python would take it and rewrite it, heh.
788 2020-06-18T21:34:32  <dongcarl> achow101: I think the hope is that other projects that cross-compile for mac might find this useful, as it does the job of 2 separate programs in one python script
789 2020-06-18T21:49:01  *** luke-jr has quit IRC
790 2020-06-18T21:49:20  *** gzhao408 has quit IRC
791 2020-06-18T21:49:24  *** luke-jr has joined #bitcoin-core-dev
792 2020-06-18T21:49:34  <cfields> I'll just initiate the xfer. Let me try to figure that out.
793 2020-06-18T21:50:27  <sipa> can i help?
794 2020-06-18T21:52:51  <cfields> "You don’t have the permission to create public repositories on bitcoin-core"
795 2020-06-18T21:53:23  <cfields> Yeah, let's not worry about moving it. It's not worth the effort.
796 2020-06-18T21:54:16  <cfields> Either new repo or packaging repo are fine.
797 2020-06-18T21:55:27  *** marcoagner has quit IRC
798 2020-06-18T21:55:44  <cfields> sipa: can you create a new repo in bitcoin-core ?
799 2020-06-18T21:58:41  <sipa> yes
800 2020-06-18T22:01:05  <cfields> sipa: eh on second thought, maybe best not to create some weird fork history. I'll just invite you as an owner of my repo and you can initiate the move?
801 2020-06-18T22:01:36  <sipa> sgtm
802 2020-06-18T22:07:35  <sipa> cfields: i don't have ownership rights on your repo
803 2020-06-18T22:09:03  *** kristapsk has quit IRC
804 2020-06-18T22:14:11  *** justanotheruser has quit IRC
805 2020-06-18T22:14:43  *** AaronvanW has quit IRC
806 2020-06-18T22:19:15  <dongcarl> sipa: many thanks!
807 2020-06-18T22:22:49  <sipa> ok, all done, i think
808 2020-06-18T22:24:01  <cfields> sipa: thanks!
809 2020-06-18T22:24:21  <cfields> I just commented on the lone migrated issue to make this all seem worthwhile.
810 2020-06-18T22:24:23  <sipa> yw
811 2020-06-18T22:32:18  *** justanotheruser has joined #bitcoin-core-dev
812 2020-06-18T22:47:24  *** filchef has joined #bitcoin-core-dev
813 2020-06-18T22:48:07  *** filchef has quit IRC
814 2020-06-18T22:56:20  *** Isthmus_ has left #bitcoin-core-dev
815 2020-06-18T22:57:05  *** Isthmus has joined #bitcoin-core-dev
816 2020-06-18T22:57:50  *** Chris_Stewart_5 has quit IRC
817 2020-06-18T23:05:58  *** troygiorshev has quit IRC
818 2020-06-18T23:14:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
819 2020-06-18T23:20:47  *** Chris_Stewart_5 has quit IRC
820 2020-06-18T23:43:56  *** S3RK has joined #bitcoin-core-dev
821 2020-06-18T23:48:23  *** S3RK has quit IRC