12020-06-18T00:00:02  *** slewis has quit IRC
  22020-06-18T00:08:59  *** jarthur has joined #bitcoin-core-dev
  32020-06-18T00:11:37  *** andrewtoth has quit IRC
  42020-06-18T00:12:21  *** andrewtoth has joined #bitcoin-core-dev
  52020-06-18T00:16:54  *** Highway61 has quit IRC
  62020-06-18T00:21:40  *** Laat has joined #bitcoin-core-dev
  72020-06-18T00:21:47  *** lightlike has quit IRC
  82020-06-18T00:38:08  *** jarthur has quit IRC
  92020-06-18T00:49:00  *** S3RK has joined #bitcoin-core-dev
 102020-06-18T00:53:35  *** S3RK has quit IRC
 112020-06-18T00:56:26  *** S3RK has joined #bitcoin-core-dev
 122020-06-18T01:00:20  *** jarthur has joined #bitcoin-core-dev
 132020-06-18T01:14:46  *** davterra has joined #bitcoin-core-dev
 142020-06-18T01:18:17  *** S3RK has quit IRC
 152020-06-18T01:19:32  <jeremyrubin> hebasto: is their a motivation for replacing recursivemutex with mutex?
 162020-06-18T01:19:51  <sipa> recursive mutexes are evil
 172020-06-18T01:20:01  <sipa> mutices?
 182020-06-18T01:20:26  *** Beta_ has joined #bitcoin-core-dev
 192020-06-18T01:21:15  <jeremyrubin> (context #19306)
 202020-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
 212020-06-18T01:21:22  <sipa> there is probably a place for them, like goto
 222020-06-18T01:21:34  <sipa> but almost always, they just lead to badly designed abstractions
 232020-06-18T01:22:01  <sipa> a clear design should have code that operates outside the critical section, and code that operates inside
 242020-06-18T01:22:16  <sipa> but not code that works in both
 252020-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
 262020-06-18T01:22:57  <sipa> indeed
 272020-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
 282020-06-18T01:23:03  *** davterra has quit IRC
 292020-06-18T01:23:23  <jeremyrubin> It seems to get rid of recursive mutex in favor of our own implementation of it
 302020-06-18T01:23:29  <jeremyrubin> which seems worse
 312020-06-18T01:23:32  <sipa> oh
 322020-06-18T01:23:58  <jeremyrubin> So I'm trying to understand hebasto's motive in the PR to be able to provide constructive feedback :)
 332020-06-18T01:23:59  <sipa> i have not looked at the code
 342020-06-18T01:24:48  <sipa> eh, i agree - that change isn't a step in the right direction
 352020-06-18T01:29:25  *** bitcoin-git has joined #bitcoin-core-dev
 362020-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
 372020-06-18T01:29:28  *** bitcoin-git has left #bitcoin-core-dev
 382020-06-18T01:30:53  *** ossifrage has joined #bitcoin-core-dev
 392020-06-18T01:33:47  <luke-jr> sipa: recursive mutexes just guarantees that <this> code always operates inside, no matter the scope of the lock
 402020-06-18T01:34:11  *** Beta_ has quit IRC
 412020-06-18T01:34:19  *** davterra has joined #bitcoin-core-dev
 422020-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?
 432020-06-18T01:35:00  <sipa> luke-jr: making the separation between inside/outside critical section clear
 442020-06-18T01:35:11  <jeremyrubin> I think recursive mutexs and lock annotations have a slight redundancy
 452020-06-18T01:35:18  <jeremyrubin> run time v.s. compile time lock checking
 462020-06-18T01:35:52  <jeremyrubin> run time should be strictly more flexible, but also permits some undesirable behaviors
 472020-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)
 482020-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
 492020-06-18T01:36:09  <gwillen> a better approach is to have two methods, and have them call the correct one
 502020-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
 512020-06-18T01:36:28  <sipa> luke-jr: most methods are only called in one context
 522020-06-18T01:36:34  <luke-jr> sipa: not all though
 532020-06-18T01:36:38  <sipa> fwiw, addrman has this design
 542020-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
 552020-06-18T01:37:00  <sipa> it has all code running inside the cs in the .cpp file
 562020-06-18T01:37:03  <luke-jr> gwillen: some abstractions would have it for most methods
 572020-06-18T01:37:08  <gwillen> it is relatively rare (and probably sometimes a code smell) to need this
 582020-06-18T01:37:10  <sipa> and then all publicly accessible code grabs the lock, and calls the internals
 592020-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
 602020-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)
 612020-06-18T01:38:14  <luke-jr> the benefit of annotations is that you force the caller to be aware it's using a lock
 622020-06-18T01:38:17  <luke-jr> you lose that with wrappers
 632020-06-18T01:38:21  <jeremyrubin> Everyone enjoy your evenings ;)
 642020-06-18T01:38:32  <sipa> gwillen: agree
 652020-06-18T01:38:35  <gwillen> wrappers and annotations are not mutually exclusive, you should definitely still use annotations
 662020-06-18T01:38:49  <luke-jr> you can't use annotations with a wrapper..
 672020-06-18T01:38:54  <sipa> luke-jr: huh?
 682020-06-18T01:38:56  <luke-jr> (unless it's a recursive mutex)
 692020-06-18T01:39:10  <jeremyrubin> I didn't realize this would be such a *contentious* topic
 702020-06-18T01:39:11  <sipa> you'd have the internal function annotated with require_lock, and and the wrapper with a lock_excluded annotation
 712020-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.
 722020-06-18T01:39:25  <luke-jr> sipa: okay, but that defeats the point
 732020-06-18T01:39:34  <sipa> luke-jr: i don't see how?
 742020-06-18T01:39:38  <sipa> this is my preferred approach
 752020-06-18T01:39:53  <luke-jr> sipa: the code calling the wrapper no longer self-documents/makes the developer aware of using the lock
 762020-06-18T01:40:12  <sipa> external code should only be seeing the wrapper
 772020-06-18T01:40:20  <sipa> internal code should only ever call the non-wrapped function
 782020-06-18T01:40:30  <sipa> thus providing a perfectly clear separation between the two
 792020-06-18T01:40:50  <luke-jr> and what if the external code needs to hold the lock longer than just the call?
 802020-06-18T01:41:10  <sipa> rewrite the code :p
 812020-06-18T01:41:19  <jeremyrubin> luke-jr: use an external lock?
 822020-06-18T01:41:24  <sipa> (i know that's not always possible - but in many cases it is)
 832020-06-18T01:41:58  <luke-jr> eg, with a wallet, it's pretty reasonable to want atomic operations
 842020-06-18T01:42:10  <luke-jr> doing multiple things to the wallet with the lock held
 852020-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
 862020-06-18T01:42:35  <sipa> luke-jr: yeah, that's a good example of an exception
 872020-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
 882020-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
 892020-06-18T01:43:59  *** Highway61 has joined #bitcoin-core-dev
 902020-06-18T01:44:06  <jeremyrubin> sipa: gwillen: yes, that's what I meant
 912020-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)
 922020-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
 932020-06-18T01:44:57  <gwillen> I dislike it because it means you are not using RAII
 942020-06-18T01:45:02  <sipa> gwillen: indeed
 952020-06-18T01:45:05  <gwillen> and if you take an exception the world ends
 962020-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
 972020-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)
 982020-06-18T01:46:26  <sipa> it looks like that
 992020-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
1002020-06-18T01:47:06  <jeremyrubin> gwillen: I think the chances of a bug or error in custom logic is higher than a recursive mutex
1012020-06-18T01:47:18  <jeremyrubin> accidental recursion seems unlikely...
1022020-06-18T01:47:39  <jeremyrubin> and accidental recursion would be a bug lock or no
1032020-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)
1042020-06-18T01:48:31  *** promag has quit IRC
1052020-06-18T01:48:45  <gwillen> (this is the fundamental problem of recursive mutexes)
1062020-06-18T01:49:10  <gwillen> (and I assume the motivation behind hebasto's refactor)
1072020-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?
1082020-06-18T01:49:32  * jeremyrubin pines for rust
1092020-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)
1102020-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
1112020-06-18T01:51:00  <jeremyrubin> would it be? it depends on how pervasive locking annotations are in your code
1122020-06-18T01:51:17  <jeremyrubin> It's entirely reasonable to write a helper which doesn't assert which locks it expects
1132020-06-18T01:51:30  <gwillen> Well, it would be nice if it weren't. :-)
1142020-06-18T01:51:48  * jeremyrubin pines for rust
1152020-06-18T01:51:50  <luke-jr> gwillen: it'd be nice if C/C++ added non-scoping conditionals :P
1162020-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.
1172020-06-18T01:52:56  <luke-jr> jeremyrubin: Rust needs to fix its problems with bootstrap and shared libraries
1182020-06-18T01:53:55  <jeremyrubin> c++ needs to fix... everything else basically :p
1192020-06-18T01:54:47  * sipa grabs popcorn
1202020-06-18T01:54:57  *** justanotheruser has quit IRC
1212020-06-18T01:56:29  <luke-jr> C++ isn't broken, even if it doesn't provide features some might idealise
1222020-06-18T01:58:11  <jeremyrubin> anyways bootsrap stuff I think is more in dongcarl's weelhouse so I'll tag out for him ;)
1232020-06-18T02:00:02  <luke-jr> IMO it's still in Rust developers' court; they haven't made it practical
1242020-06-18T02:01:18  <luke-jr> and frankly seem to be actively trying to make it difficult
1252020-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
1262020-06-18T02:01:39  <luke-jr> gwillen: oh? it does?
1272020-06-18T02:01:43  <fanquake> https://guix.gnu.org/blog/2018/bootstrapping-rust/
1282020-06-18T02:01:45  <luke-jr> that's new progress I hadn't heard of
1292020-06-18T02:01:51  <luke-jr> that's 2018..
1302020-06-18T02:02:04  <luke-jr> and still convoluted
1312020-06-18T02:02:45  <luke-jr> (things have gotten worse since 2018)
1322020-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
1332020-06-18T02:03:24  <gwillen> I don't know whether guix takes advantage of this, though, I have not used it
1342020-06-18T02:03:52  *** justanotheruser has joined #bitcoin-core-dev
1352020-06-18T02:04:50  <fanquake> I'd also like to know what has "gotten worse"
1362020-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
1372020-06-18T02:05:32  <luke-jr> eg, you can't just mrustc a stable rustc, then use that to get the latest rustc
1382020-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)
1392020-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
1402020-06-18T02:06:47  <luke-jr> it would be nice if Rust devs stopped breaking the language compatibility :p
1412020-06-18T02:08:18  <fanquake> There's also https://github.com/dtolnay/bootstrap, which seems to crawl through each version
1422020-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
1432020-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
1442020-06-18T02:13:36  <phantomcircuit> luke-jr, the issue of doing atomic things like that is more or less analogous to database consistency issues
1452020-06-18T02:13:51  <phantomcircuit> no real solution here just a thought
1462020-06-18T02:15:47  *** shesek has quit IRC
1472020-06-18T02:16:10  *** shesek has joined #bitcoin-core-dev
1482020-06-18T02:16:10  *** shesek has joined #bitcoin-core-dev
1492020-06-18T02:27:39  *** promag has joined #bitcoin-core-dev
1502020-06-18T02:31:10  <sipa> i was curious what the bootstrapping cycle for modern GCC is like
1512020-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
1522020-06-18T02:37:11  *** bitdex has joined #bitcoin-core-dev
1532020-06-18T02:37:25  <sipa> potentially with GCC 4.7 in between (unless how good C++98 support in GCC 3.3 was)
1542020-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
1552020-06-18T02:38:35  *** promag has quit IRC
1562020-06-18T02:38:45  <gwillen> which GCC is presumably fairly careful to avoid, if you can really bootstrap it that directly
1572020-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
1582020-06-18T02:40:08  <sipa> they're slower in adopting language changes than bitcoin core :p
1592020-06-18T02:40:34  <fanquake> heh
1602020-06-18T02:40:52  <sipa> though, that's an unfair comparison with rust, which just changes much more rapidly by virtue of being younger
1612020-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/
1622020-06-18T02:41:22  <fanquake> The Guix bootstrap seed is now even smaller
1632020-06-18T02:41:54  <fanquake> Targeting another 50% reduction during the next round of work
1642020-06-18T02:47:42  <sipa> nice
1652020-06-18T03:00:02  *** Laat has quit IRC
1662020-06-18T03:10:06  *** promag has joined #bitcoin-core-dev
1672020-06-18T03:10:45  *** bitcoin-git has joined #bitcoin-core-dev
1682020-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
1692020-06-18T03:10:46  *** bitcoin-git has left #bitcoin-core-dev
1702020-06-18T03:14:37  *** promag has quit IRC
1712020-06-18T03:14:49  *** Eagle[TM] has joined #bitcoin-core-dev
1722020-06-18T03:16:42  *** dr-orlovsky has quit IRC
1732020-06-18T03:17:07  *** EagleTM has quit IRC
1742020-06-18T03:22:24  *** Alphi has joined #bitcoin-core-dev
1752020-06-18T03:30:18  *** go11111111111 has joined #bitcoin-core-dev
1762020-06-18T03:32:47  *** go121212 has quit IRC
1772020-06-18T03:44:07  <luke-jr> sipa: compilers *should* be very slow with adopting new features
1782020-06-18T03:44:28  <luke-jr> for anything else, you can always just upgrade the compiler so long as the new compiler builds
1792020-06-18T04:01:17  *** S3RK has joined #bitcoin-core-dev
1802020-06-18T04:05:06  *** S3RK has quit IRC
1812020-06-18T04:05:33  *** S3RK has joined #bitcoin-core-dev
1822020-06-18T04:05:41  *** ppisati has quit IRC
1832020-06-18T04:10:01  *** S3RK has quit IRC
1842020-06-18T04:12:19  *** ppisati has joined #bitcoin-core-dev
1852020-06-18T04:16:44  *** AaronvanW has quit IRC
1862020-06-18T04:21:03  *** vasild_ has joined #bitcoin-core-dev
1872020-06-18T04:24:03  *** vasild has quit IRC
1882020-06-18T04:24:07  *** vasild_ is now known as vasild
1892020-06-18T04:35:29  *** davterra has quit IRC
1902020-06-18T04:38:45  *** S3RK has joined #bitcoin-core-dev
1912020-06-18T04:41:15  *** davterra has joined #bitcoin-core-dev
1922020-06-18T04:48:27  *** AaronvanW has joined #bitcoin-core-dev
1932020-06-18T04:52:59  *** AaronvanW has quit IRC
1942020-06-18T05:00:52  *** Pavlenex has joined #bitcoin-core-dev
1952020-06-18T05:19:24  *** bitcoin-git has joined #bitcoin-core-dev
1962020-06-18T05:19:25  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/35ed88f187c9...931035b60830
1972020-06-18T05:19:26  <bitcoin-git> bitcoin/master fa84edb fanquake: build: don't warn when doxygen isn't found
1982020-06-18T05:19:26  <bitcoin-git> bitcoin/master 931035b fanquake: Merge #19301: build: don't warn when doxygen isn't found
1992020-06-18T05:19:28  *** bitcoin-git has left #bitcoin-core-dev
2002020-06-18T05:19:44  *** bitcoin-git has joined #bitcoin-core-dev
2012020-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
2022020-06-18T05:19:46  *** bitcoin-git has left #bitcoin-core-dev
2032020-06-18T05:21:32  *** bitcoin-git has joined #bitcoin-core-dev
2042020-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
2052020-06-18T05:21:34  *** bitcoin-git has left #bitcoin-core-dev
2062020-06-18T05:22:59  *** Guyver2 has joined #bitcoin-core-dev
2072020-06-18T05:25:59  *** luke-jr has quit IRC
2082020-06-18T05:26:47  *** luke-jr has joined #bitcoin-core-dev
2092020-06-18T05:41:20  *** S3RK has quit IRC
2102020-06-18T05:41:46  *** S3RK has joined #bitcoin-core-dev
2112020-06-18T05:46:30  *** S3RK has quit IRC
2122020-06-18T05:48:01  *** S3RK has joined #bitcoin-core-dev
2132020-06-18T05:52:42  *** S3RK has quit IRC
2142020-06-18T06:00:02  *** Alphi has quit IRC
2152020-06-18T06:10:35  *** Kiminuo has joined #bitcoin-core-dev
2162020-06-18T06:20:31  *** edit_21 has joined #bitcoin-core-dev
2172020-06-18T06:48:45  *** S3RK has joined #bitcoin-core-dev
2182020-06-18T06:49:58  *** AaronvanW has joined #bitcoin-core-dev
2192020-06-18T06:50:45  *** marcoagner has joined #bitcoin-core-dev
2202020-06-18T07:00:26  *** wiz has quit IRC
2212020-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)`
2222020-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.
2232020-06-18T07:11:40  *** davterra_ has joined #bitcoin-core-dev
2242020-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.
2252020-06-18T07:12:24  *** Soh has joined #bitcoin-core-dev
2262020-06-18T07:13:43  *** davterra has quit IRC
2272020-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
2282020-06-18T07:23:05  *** AaronvanW has quit IRC
2292020-06-18T07:23:38  <dburkett> AssertLockHeld is only runtime enforceable, but yes that's an improvement.
2302020-06-18T07:23:41  *** teca has joined #bitcoin-core-dev
2312020-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
2322020-06-18T07:42:51  *** CubicEarth has quit IRC
2332020-06-18T07:43:23  *** Dean_Guss has quit IRC
2342020-06-18T07:45:24  *** CubicEarth has joined #bitcoin-core-dev
2352020-06-18T07:50:01  *** promag has joined #bitcoin-core-dev
2362020-06-18T07:50:05  *** luke-jr has quit IRC
2372020-06-18T07:51:29  *** luke-jr has joined #bitcoin-core-dev
2382020-06-18T07:54:14  *** promag has quit IRC
2392020-06-18T07:58:16  *** jarthur has quit IRC
2402020-06-18T08:01:27  *** AaronvanW has joined #bitcoin-core-dev
2412020-06-18T08:05:13  *** Livestradamus has quit IRC
2422020-06-18T08:05:34  *** Livestradamus has joined #bitcoin-core-dev
2432020-06-18T08:11:34  *** Pavlenex has quit IRC
2442020-06-18T08:22:16  *** promag has joined #bitcoin-core-dev
2452020-06-18T08:24:19  *** michagogo has quit IRC
2462020-06-18T08:25:11  *** tryphe_ is now known as tryphe
2472020-06-18T08:31:55  *** Soh has quit IRC
2482020-06-18T08:39:00  *** S3RK has quit IRC
2492020-06-18T08:39:33  *** S3RK has joined #bitcoin-core-dev
2502020-06-18T08:40:28  *** MarcoFalke has quit IRC
2512020-06-18T08:42:36  *** MarcoFalke has joined #bitcoin-core-dev
2522020-06-18T08:43:54  *** S3RK has quit IRC
2532020-06-18T08:54:19  *** nostrodamy has joined #bitcoin-core-dev
2542020-06-18T08:55:15  *** Pavlenex has joined #bitcoin-core-dev
2552020-06-18T09:00:02  *** edit_21 has quit IRC
2562020-06-18T09:01:21  *** proofofkeags has quit IRC
2572020-06-18T09:02:54  *** AaronvanW has quit IRC
2582020-06-18T09:03:11  *** AaronvanW has joined #bitcoin-core-dev
2592020-06-18T09:22:09  *** fabriceflorin has joined #bitcoin-core-dev
2602020-06-18T09:28:35  *** S3RK has joined #bitcoin-core-dev
2612020-06-18T09:30:56  *** Eagle[TM] has quit IRC
2622020-06-18T09:33:13  *** S3RK has quit IRC
2632020-06-18T09:46:03  *** dr-orlovsky has joined #bitcoin-core-dev
2642020-06-18T09:58:01  *** S3RK has joined #bitcoin-core-dev
2652020-06-18T09:58:02  *** dr-orlovsky has quit IRC
2662020-06-18T09:59:22  *** EagleTM has joined #bitcoin-core-dev
2672020-06-18T10:02:14  *** S3RK has quit IRC
2682020-06-18T10:02:41  *** roconnor_ has quit IRC
2692020-06-18T10:03:28  *** General90Hoppe has joined #bitcoin-core-dev
2702020-06-18T10:04:50  *** dr-orlovsky has joined #bitcoin-core-dev
2712020-06-18T10:09:25  *** Relis has quit IRC
2722020-06-18T10:11:01  *** General90Hoppe has quit IRC
2732020-06-18T10:13:00  *** arkosphilos has joined #bitcoin-core-dev
2742020-06-18T10:17:40  *** belcher has joined #bitcoin-core-dev
2752020-06-18T10:19:50  *** S3RK has joined #bitcoin-core-dev
2762020-06-18T10:20:18  *** Pavlenex has quit IRC
2772020-06-18T10:26:35  *** dr-orlovsky has quit IRC
2782020-06-18T10:29:47  *** kvaciral has quit IRC
2792020-06-18T10:49:16  *** dr-orlovsky has joined #bitcoin-core-dev
2802020-06-18T10:49:41  *** arkosphilos is now known as arkos
2812020-06-18T11:02:07  *** arkos has quit IRC
2822020-06-18T11:05:49  *** Relis has joined #bitcoin-core-dev
2832020-06-18T11:11:58  *** arkos has joined #bitcoin-core-dev
2842020-06-18T11:16:47  *** S3RK has quit IRC
2852020-06-18T11:17:16  *** S3RK has joined #bitcoin-core-dev
2862020-06-18T11:25:03  *** S3RK has quit IRC
2872020-06-18T11:26:56  *** S3RK has joined #bitcoin-core-dev
2882020-06-18T11:31:38  *** S3RK has quit IRC
2892020-06-18T11:41:56  *** bitcoin-git has joined #bitcoin-core-dev
2902020-06-18T11:41:56  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/931035b60830...343c0bfbf1e5
2912020-06-18T11:41:57  <bitcoin-git> bitcoin/master 80d4423 Troy Giorshev: Test buffered valid message
2922020-06-18T11:41:58  <bitcoin-git> bitcoin/master 343c0bf MarcoFalke: Merge #19304: test: Check that message sends successfully when header is s...
2932020-06-18T11:42:07  *** bitcoin-git has left #bitcoin-core-dev
2942020-06-18T11:42:26  *** bitcoin-git has joined #bitcoin-core-dev
2952020-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
2962020-06-18T11:42:27  *** bitcoin-git has left #bitcoin-core-dev
2972020-06-18T11:43:26  *** diogorsergio has joined #bitcoin-core-dev
2982020-06-18T12:00:02  *** fabriceflorin has quit IRC
2992020-06-18T12:00:12  *** S3RK has joined #bitcoin-core-dev
3002020-06-18T12:05:00  *** S3RK has quit IRC
3012020-06-18T12:12:48  *** bitcoin-git has joined #bitcoin-core-dev
3022020-06-18T12:12:49  <bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/343c0bfbf1e5...b8740d6737b4
3032020-06-18T12:12:50  <bitcoin-git> bitcoin/master 1f790a1 Pieter Wuille: Make Span size type unsigned
3042020-06-18T12:12:51  <bitcoin-git> bitcoin/master bb3d38f Pieter Wuille: Make pointer-based Span construction safer
3052020-06-18T12:12:52  <bitcoin-git> bitcoin/master ab303a1 Pieter Wuille: Add Span constructors for arrays and vectors
3062020-06-18T12:12:53  *** bitcoin-git has left #bitcoin-core-dev
3072020-06-18T12:13:48  *** bitcoin-git has joined #bitcoin-core-dev
3082020-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
3092020-06-18T12:13:50  *** bitcoin-git has left #bitcoin-core-dev
3102020-06-18T12:21:16  *** jackalope has joined #bitcoin-core-dev
3112020-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?
3122020-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
3132020-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
3142020-06-18T12:22:25  *** jonatack has quit IRC
3152020-06-18T12:24:31  *** jonatack has joined #bitcoin-core-dev
3162020-06-18T12:36:53  *** S3RK has joined #bitcoin-core-dev
3172020-06-18T12:41:20  *** arkos has quit IRC
3182020-06-18T12:41:25  *** S3RK has quit IRC
3192020-06-18T12:48:34  *** Mercury_Vapor has quit IRC
3202020-06-18T12:51:24  *** Mercury_Vapor has joined #bitcoin-core-dev
3212020-06-18T12:53:46  *** Guyver2 has quit IRC
3222020-06-18T13:03:31  *** roconnor_ has joined #bitcoin-core-dev
3232020-06-18T13:28:18  *** Kiminuo has quit IRC
3242020-06-18T13:37:25  *** Kiminuo has joined #bitcoin-core-dev
3252020-06-18T13:41:55  *** bitcoin-git has joined #bitcoin-core-dev
3262020-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
3272020-06-18T13:41:56  *** bitcoin-git has left #bitcoin-core-dev
3282020-06-18T13:42:32  *** promag has quit IRC
3292020-06-18T14:14:00  *** davterra__ has joined #bitcoin-core-dev
3302020-06-18T14:14:00  <achow101> wumpus: yes
3312020-06-18T14:14:01  *** Kiminuo has quit IRC
3322020-06-18T14:16:26  *** davterra_ has quit IRC
3332020-06-18T14:17:47  *** promag has joined #bitcoin-core-dev
3342020-06-18T14:19:23  *** davterra__ has quit IRC
3352020-06-18T14:22:08  *** promag has quit IRC
3362020-06-18T14:24:26  *** promag has joined #bitcoin-core-dev
3372020-06-18T14:25:22  <wumpus> achow101: ok, replaced
3382020-06-18T14:25:30  <achow101> although #19292, #19308, and #19310 shouldn't conflict with each other so they can be merged in any order
3392020-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
3402020-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
3412020-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
3422020-06-18T14:28:12  *** bitcoin-git has joined #bitcoin-core-dev
3432020-06-18T14:28:12  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b8740d6737b4...c7ebab12f941
3442020-06-18T14:28:13  <bitcoin-git> bitcoin/master a389ed5 Andrew Chow: walletdb: refactor Read, Write, Erase, and Exists into non-template func
3452020-06-18T14:28:14  <bitcoin-git> bitcoin/master c7ebab1 MarcoFalke: Merge #19292: wallet: Refactor BerkeleyBatch Read, Write, Erase, and Exist...
3462020-06-18T14:28:15  *** bitcoin-git has left #bitcoin-core-dev
3472020-06-18T14:28:32  *** bitcoin-git has joined #bitcoin-core-dev
3482020-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
3492020-06-18T14:28:37  *** bitcoin-git has left #bitcoin-core-dev
3502020-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
3512020-06-18T14:29:29  <achow101> next in line is 19308
3522020-06-18T14:31:27  <wumpus> ok, I'll leave it to someone else to replace that, I'm done for it for a bit :)
3532020-06-18T14:31:58  <achow101> i'll wait for the meeting
3542020-06-18T14:44:50  <wumpus> nah already swapped it
3552020-06-18T14:47:47  *** bitcoin-git has joined #bitcoin-core-dev
3562020-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
3572020-06-18T14:47:48  *** bitcoin-git has left #bitcoin-core-dev
3582020-06-18T14:53:35  *** Guyver2 has joined #bitcoin-core-dev
3592020-06-18T14:56:56  *** dr-orlovsky has quit IRC
3602020-06-18T14:59:59  *** promag_ has joined #bitcoin-core-dev
3612020-06-18T15:00:02  *** jackalope has quit IRC
3622020-06-18T15:02:37  *** troygiorshev has quit IRC
3632020-06-18T15:02:38  *** dr-orlovsky has joined #bitcoin-core-dev
3642020-06-18T15:03:03  <wumpus> MarcoFalke: re:  #19033, you added the "waiting for author" tag, what is it waiting on?
3652020-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
3662020-06-18T15:03:23  *** troygiorshev has joined #bitcoin-core-dev
3672020-06-18T15:03:42  *** S3RK has joined #bitcoin-core-dev
3682020-06-18T15:04:47  *** promag_ has quit IRC
3692020-06-18T15:05:26  <promag> for me to fix it
3702020-06-18T15:08:12  *** S3RK has quit IRC
3712020-06-18T15:10:41  <wumpus> it's broken? that wasn't clear to me
3722020-06-18T15:11:02  <promag> yeah it is :(
3732020-06-18T15:11:26  <wumpus> let's remove it from high priority for review for now, then
3742020-06-18T15:11:36  <wumpus> doesn't make sense for people to review it if it's broken :)
3752020-06-18T15:13:44  *** luke-jr has quit IRC
3762020-06-18T15:16:38  *** luke-jr has joined #bitcoin-core-dev
3772020-06-18T15:17:04  *** Talkless has joined #bitcoin-core-dev
3782020-06-18T15:18:07  <wumpus> okay, yes I see why now
3792020-06-18T15:21:53  *** kierank1 has joined #bitcoin-core-dev
3802020-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
3812020-06-18T15:23:54  *** Talkless has quit IRC
3822020-06-18T15:24:10  <promag> wumpus: re HP, sure
3832020-06-18T15:24:31  *** Talkless has joined #bitcoin-core-dev
3842020-06-18T15:25:02  *** davec has quit IRC
3852020-06-18T15:25:11  <promag> wumpus: there's also corner cases regarding shutdown and ongoing rpc responses
3862020-06-18T15:25:16  *** davec has joined #bitcoin-core-dev
3872020-06-18T15:25:22  *** Talkless has joined #bitcoin-core-dev
3882020-06-18T15:25:36  <wumpus> yes, ther's always been
3892020-06-18T15:25:36  *** troygiorshev has quit IRC
3902020-06-18T15:25:53  <promag> and also not being able to discard lots of incoming requests
3912020-06-18T15:25:53  *** troygiorshev has joined #bitcoin-core-dev
3922020-06-18T15:26:46  <wumpus> or at the least, defer accept()
3932020-06-18T15:27:31  <wumpus> but no it accepts every connection immediately without some kind of fd quota
3942020-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)
3952020-06-18T15:34:21  *** braydonf has quit IRC
3962020-06-18T15:34:37  <wumpus> I'll have a look at it too some time
3972020-06-18T15:34:48  *** braydonf has joined #bitcoin-core-dev
3982020-06-18T15:37:03  *** kabaum has joined #bitcoin-core-dev
3992020-06-18T15:46:05  *** Pavlenex has joined #bitcoin-core-dev
4002020-06-18T15:47:54  *** troygiorshev has quit IRC
4012020-06-18T15:49:01  *** troygiorshev has joined #bitcoin-core-dev
4022020-06-18T15:49:41  *** Pavlenex has quit IRC
4032020-06-18T15:52:04  *** jarthur has joined #bitcoin-core-dev
4042020-06-18T16:07:03  *** lightlike has joined #bitcoin-core-dev
4052020-06-18T16:14:13  *** justanotheruser has quit IRC
4062020-06-18T16:20:02  <luke-jr> #11082 rebased yet again
4072020-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
4082020-06-18T16:24:23  *** vasild has quit IRC
4092020-06-18T16:25:27  *** nobody123 has joined #bitcoin-core-dev
4102020-06-18T16:25:49  *** vasild has joined #bitcoin-core-dev
4112020-06-18T16:29:48  *** luke-jr has quit IRC
4122020-06-18T16:30:09  *** luke-jr has joined #bitcoin-core-dev
4132020-06-18T16:30:43  *** justanotheruser has joined #bitcoin-core-dev
4142020-06-18T16:39:52  *** leinlawun[m] has joined #bitcoin-core-dev
4152020-06-18T16:40:02  *** Kiminuo has joined #bitcoin-core-dev
4162020-06-18T16:47:27  *** kristapsk has joined #bitcoin-core-dev
4172020-06-18T16:47:57  *** jeremyrubin has quit IRC
4182020-06-18T16:56:52  *** User0192 has joined #bitcoin-core-dev
4192020-06-18T16:57:15  *** sipsorcery has quit IRC
4202020-06-18T16:59:34  *** kabaum has quit IRC
4212020-06-18T17:01:51  *** bitcoin-git has joined #bitcoin-core-dev
4222020-06-18T17:01:52  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c7ebab12f941...0865a8881d39
4232020-06-18T17:01:52  <bitcoin-git> bitcoin/master 25f3554 Hennadii Stepanov: scripted-diff: Make SeparatorStyle a scoped enum
4242020-06-18T17:01:54  <bitcoin-git> bitcoin/master 0865a88 MarcoFalke: Merge bitcoin-core/gui#3: scripted-diff: Make SeparatorStyle a scoped enum...
4252020-06-18T17:01:55  *** bitcoin-git has left #bitcoin-core-dev
4262020-06-18T17:01:57  <MarcoFalke> Just merged the first pull from the gui repository. Hope nothing caught fire
4272020-06-18T17:02:22  <achow101> oh noes my computer is on fire
4282020-06-18T17:03:13  *** cryptapus has quit IRC
4292020-06-18T17:03:52  *** cryptapus has joined #bitcoin-core-dev
4302020-06-18T17:11:27  *** Dean_Guss has joined #bitcoin-core-dev
4312020-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?
4322020-06-18T17:20:26  <provoostenator> So how does Gribble link to GUI issues now?
4332020-06-18T17:21:48  <luke-jr> hrm, might be annoying to have a different # namespace :/
4342020-06-18T17:23:18  <provoostenator> Maybe prefix it? E.g. #gui-2
4352020-06-18T17:24:26  <MarcoFalke> In github the normalized and absolute identifier is "bitcoin-core/gui#3" or "bitcoin/bitcoin#3"
4362020-06-18T17:24:30  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
4372020-06-18T17:24:30  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
4382020-06-18T17:24:38  <MarcoFalke> but indeed that seems a bit verbose for IRC
4392020-06-18T17:24:49  <MarcoFalke> Might as well post the full link
4402020-06-18T17:26:32  <provoostenator> Oh well at least the github normalized method works, TIL
4412020-06-18T17:26:55  <provoostenator> Oh no it doesn't
4422020-06-18T17:27:02  <MarcoFalke> not for gribble
4432020-06-18T17:27:24  *** bitdex has quit IRC
4442020-06-18T17:31:45  *** edd has joined #bitcoin-core-dev
4452020-06-18T17:39:50  *** sipsorcery has joined #bitcoin-core-dev
4462020-06-18T17:40:00  *** promag_ has joined #bitcoin-core-dev
4472020-06-18T17:41:04  <luke-jr> gui#3?
4482020-06-18T17:41:06  <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
4492020-06-18T17:41:21  <luke-jr> someone should fix gribble for whatever we do :P
4502020-06-18T17:41:40  *** S3RK has joined #bitcoin-core-dev
4512020-06-18T17:41:46  <provoostenator> Where does Gribble's source live?
4522020-06-18T17:42:04  <luke-jr> nanotube's repo on gitlab iirc
4532020-06-18T17:44:20  *** promag_ has quit IRC
4542020-06-18T17:45:54  *** S3RK has quit IRC
4552020-06-18T17:55:38  *** guest534543 has joined #bitcoin-core-dev
4562020-06-18T17:59:10  *** Kiminuo has quit IRC
4572020-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
4582020-06-18T17:59:14  <dongcarl> (1.19.0...1.29.0).
4592020-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.
4602020-06-18T17:59:17  *** Kiminuo has joined #bitcoin-core-dev
4612020-06-18T18:00:02  *** kierank1 has quit IRC
4622020-06-18T18:00:19  *** guest534543 has quit IRC
4632020-06-18T18:07:51  *** Guyver2_ has joined #bitcoin-core-dev
4642020-06-18T18:09:34  *** Guyver2 has quit IRC
4652020-06-18T18:09:42  *** Guyver2_ is now known as Guyver2
4662020-06-18T18:12:22  *** bitcoin-git has joined #bitcoin-core-dev
4672020-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
4682020-06-18T18:12:24  *** bitcoin-git has left #bitcoin-core-dev
4692020-06-18T18:12:42  *** bitcoin-git has joined #bitcoin-core-dev
4702020-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
4712020-06-18T18:12:45  *** bitcoin-git has left #bitcoin-core-dev
4722020-06-18T18:12:58  <provoostenator> ^ oops, wrong one
4732020-06-18T18:16:57  <provoostenator> I moved the HWW GUI PR to  the GUI repo, since there wasn't much discussion on it yet
4742020-06-18T18:17:57  *** jonatack has quit IRC
4752020-06-18T18:19:39  <moneyball> #proposedmeetingtopic taproot implementation plan; is v0.21 realistic?
4762020-06-18T18:20:08  *** jonatack has joined #bitcoin-core-dev
4772020-06-18T18:21:46  *** bitcoin-git has joined #bitcoin-core-dev
4782020-06-18T18:21:47  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/0865a8881d39...c2bcb99c1d11
4792020-06-18T18:21:47  <bitcoin-git> bitcoin/master faceed7 MarcoFalke: doc: Add redirect for GUI issues and pull requests
4802020-06-18T18:21:48  <bitcoin-git> bitcoin/master 66666d5 MarcoFalke: doc: Mention repo split in the READMEs
4812020-06-18T18:21:48  <bitcoin-git> bitcoin/master c2bcb99 MarcoFalke: Merge #19071: doc: Separate repository for the gui
4822020-06-18T18:21:50  *** bitcoin-git has left #bitcoin-core-dev
4832020-06-18T18:22:15  *** meh` has joined #bitcoin-core-dev
4842020-06-18T18:22:16  *** bitcoin-git has joined #bitcoin-core-dev
4852020-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
4862020-06-18T18:22:17  *** bitcoin-git has left #bitcoin-core-dev
4872020-06-18T18:43:46  *** bitcoin-git has joined #bitcoin-core-dev
4882020-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
4892020-06-18T18:43:48  *** bitcoin-git has left #bitcoin-core-dev
4902020-06-18T19:00:14  <wumpus> #startmeeting
4912020-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.
4922020-06-18T19:00:14  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4932020-06-18T19:00:17  <jnewbery> hi
4942020-06-18T19:00:19  <moneyball> hi
4952020-06-18T19:00:30  <cfields> hi
4962020-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
4972020-06-18T19:00:39  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
4982020-06-18T19:00:44  <sipa> hi
4992020-06-18T19:00:46  <MarcoFalke> hi
5002020-06-18T19:00:54  <achow101> hi
5012020-06-18T19:00:59  <fjahr> Hi
5022020-06-18T19:01:24  <ajonas> hi
5032020-06-18T19:01:46  <meshcollider> hi
5042020-06-18T19:01:51  <wumpus> one proposed meeting topic for today: taproot implementation plan (moneyball)
5052020-06-18T19:01:56  <wumpus> any last minute topics?
5062020-06-18T19:02:11  <ariard> hi
5072020-06-18T19:02:29  <luke-jr> hi
5082020-06-18T19:03:00  *** jeremyrubin has joined #bitcoin-core-dev
5092020-06-18T19:03:01  <kanzure> hi
5102020-06-18T19:03:05  <wumpus> #topic High priority for review
5112020-06-18T19:03:15  <jeremyrubin> hola
5122020-06-18T19:03:22  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  currently: 12 blockers, 3 chasing concept ACK
5132020-06-18T19:03:31  <wumpus> anything to add/remove?
5142020-06-18T19:03:33  <MarcoFalke> I'd like to add #19028
5152020-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
5162020-06-18T19:03:53  <luke-jr> wumpus: #18818 should probably be under Bugfixes, not Blockers? not sure on categorisation
5172020-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
5182020-06-18T19:04:18  *** gzhao408 has joined #bitcoin-core-dev
5192020-06-18T19:04:30  <wumpus> MarcoFalke: added
5202020-06-18T19:04:33  <jamesob> hi
5212020-06-18T19:04:35  <MarcoFalke> thx
5222020-06-18T19:04:41  <wumpus> luke-jr: ok moved
5232020-06-18T19:05:02  <cfields> luke-jr: gah, sorry, forgot about that one. Will take a look regardless of how it's tagged.
5242020-06-18T19:05:10  <luke-jr> cfields: thanks
5252020-06-18T19:05:19  <jonasschnelli> hi
5262020-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
5272020-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
5282020-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
5292020-06-18T19:06:30  <wumpus> no strong opinion, but I'm not sure the thread names are useful to most non-developers
5302020-06-18T19:06:51  <wumpus> for running the tests it makes sense though
5312020-06-18T19:07:46  <jamesob> I'm thinking it could be useful when we ask for debug.logs in bug reports
5322020-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
5332020-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.
5342020-06-18T19:08:50  <luke-jr> dongcarl: GNU tar can do it too, but I'm not sure it's worth the complexity
5352020-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?
5362020-06-18T19:09:09  <wumpus> (especially of those enabled by default)
5372020-06-18T19:09:16  <jamesob> wumpus: fair point, will raise again if I can
5382020-06-18T19:09:54  <wumpus> jamesob: thanks
5392020-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 :-)
5402020-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
5412020-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)
5422020-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
5432020-06-18T19:12:13  <wumpus> jnewbery: do you have any specific examples where it wouldh elp or would have helped?
5442020-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
5452020-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
5462020-06-18T19:13:31  <wumpus> so I'm more concerned about making the log unneceessarily spammy/verbose than performance hit here
5472020-06-18T19:13:55  <gwillen> thread names are non-unique, right? it might be nice to log thread IDs in addition or instead.
5482020-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.
5492020-06-18T19:14:29  <wumpus> all the names are unique
5502020-06-18T19:14:32  <jamesob> gwillen: I think they're unique at the moment; those that aren't have an increasing suffix
5512020-06-18T19:14:45  <gwillen> ah okay great, nevermind
5522020-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.
5532020-06-18T19:15:25  <sipa> i just git grep the log message :)
5542020-06-18T19:15:43  <wumpus> sipa: same, it's the only way to be sure :) log messages tend to be unique enough
5552020-06-18T19:15:46  <sipa> (no objection to logging thread names by default if it has no performance impact, though)
5562020-06-18T19:17:05  <provoostenator> (hi)
5572020-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
5582020-06-18T19:17:59  <sipa> let's first benchmark?
5592020-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
5602020-06-18T19:18:10  <wumpus> if looking up a thread name really causes a performance hit something is really wrong btw
5612020-06-18T19:18:34  <wumpus> if logging is on the performance critical path (with the default amount of logging) in the first place
5622020-06-18T19:18:38  <sipa> agree, but haven't we had surprising experiencing with this in the past?
5632020-06-18T19:18:42  <jamesob> wumpus: yeah I reckon you're right. couldn't hurt to see if something's really wrong though
5642020-06-18T19:19:03  <jamesob> MarcoFalke has proposed to add a logging benchmark re: the previous issue, which I think is still open?
5652020-06-18T19:19:05  <sipa> make it it isn't looking up the thread name for log categories that are disbaled
5662020-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)
5672020-06-18T19:19:28  <wumpus> sipa: but this turned out not to be the case
5682020-06-18T19:19:53  <wumpus> (TLS as in Thread Local Storage, not the other thing)
5692020-06-18T19:20:07  <MarcoFalke> jup the log bench is still open
5702020-06-18T19:20:19  <MarcoFalke> imo it can be merged. The risk should be zero
5712020-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
5722020-06-18T19:20:30  <jamesob> MarcoFalke: agree, think I've acked it
5732020-06-18T19:20:31  <sipa> ok
5742020-06-18T19:20:32  <wumpus> in any case please do not log on the critical path
5752020-06-18T19:20:41  <wumpus> definitely not by default (with debug flags is fine)
5762020-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
5772020-06-18T19:22:07  <wumpus> it's why I find a logging benchmark kind of weird, we're not trying to optimize logging throughput
5782020-06-18T19:23:08  <jamesob> it's less for optimization and more just an assurance we're not doing anything totally dumb
5792020-06-18T19:23:24  <jnewbery> jamesob: agree
5802020-06-18T19:23:32  <MarcoFalke> the benchmark also checks that *disabled* logs don't affect performance
5812020-06-18T19:23:45  <MarcoFalke> maybe I should call is nolog bench
5822020-06-18T19:23:50  <MarcoFalke> *it
5832020-06-18T19:23:52  <wumpus> that's a good idea
5842020-06-18T19:24:50  <wumpus> logprintf arguments shouldn't even be evaluated in that case
5852020-06-18T19:25:06  <MarcoFalke> jup (I broke that once)
5862020-06-18T19:25:09  * MarcoFalke hides
5872020-06-18T19:25:24  <wumpus> heh
5882020-06-18T19:26:31  <wumpus> #topic Taproot implementation plan (moneyball)
5892020-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.
5902020-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
5912020-06-18T19:28:05  *** wharm has joined #bitcoin-core-dev
5922020-06-18T19:28:21  <moneyball> (feel free to comment in the doc)
5932020-06-18T19:28:26  <moneyball> or here
5942020-06-18T19:28:41  <luke-jr> moneyball: activation isn't required
5952020-06-18T19:29:05  <moneyball> ok
5962020-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
5972020-06-18T19:29:22  <wumpus> associated PR would be #17977 I guess
5982020-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
5992020-06-18T19:29:35  <luke-jr> signet isn't required
6002020-06-18T19:29:47  <jeremyrubin> yeah I think we don't usually aim for major releases to have forks, should be a minor
6012020-06-18T19:30:08  <jeremyrubin> So there really isn't any release window time crunch to push for
6022020-06-18T19:30:29  <jeremyrubin> But I agree in principal with trying to figure out a path for activation
6032020-06-18T19:30:34  <moneyball> luke-jr, sipa: well there is including the activation code and then separately configuring the activation parameters. right?
6042020-06-18T19:30:50  <sipa> moneyball: depends on the activation mechanism
6052020-06-18T19:31:02  <sipa> if a new activation mechanism needs code, then yes that needs code :)
6062020-06-18T19:31:07  *** vasild has quit IRC
6072020-06-18T19:31:08  <moneyball> ha :)
6082020-06-18T19:31:16  *** luke-jr has quit IRC
6092020-06-18T19:31:19  *** vasild has joined #bitcoin-core-dev
6102020-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.
6112020-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
6122020-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?
6132020-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
6142020-06-18T19:32:57  <sipa> ariard: more testing is absolutely welcome of course
6152020-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
6162020-06-18T19:33:11  <sipa> moneyball: that sounds like it needs ML discussion first
6172020-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?
6182020-06-18T19:33:35  <moneyball> sipa: yes
6192020-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
6202020-06-18T19:34:38  *** luke-jr has joined #bitcoin-core-dev
6212020-06-18T19:35:03  <moneyball> my hope was to focus on non-activation method work needed in Core
6222020-06-18T19:35:11  <sipa> yeah, that makes sense
6232020-06-18T19:35:13  <moneyball> perhaps it was a mistake having line item one in that doc
6242020-06-18T19:35:41  <provoostenator> Although not required, it would be really nice to have a Taproot Signet.
6252020-06-18T19:36:41  <sipa> i think implementation wise that list pretty much covers it
6262020-06-18T19:36:55  <moneyball> ok i just deleted that line item from the doc :)
6272020-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?
6282020-06-18T19:37:43  *** andrewtoth has quit IRC
6292020-06-18T19:39:39  <jeremyrubin> I think that running on signet doesn't really do anything by itself
6302020-06-18T19:39:40  <luke-jr> provoostenator: sure, I was just answering moneyball's request for things not required :P
6312020-06-18T19:39:48  <jeremyrubin> The real challenge is to get integration tests somewhere
6322020-06-18T19:39:58  <provoostenator> moneyball: having a signet explorer somewhere can help with testing too
6332020-06-18T19:40:03  *** promag_ has joined #bitcoin-core-dev
6342020-06-18T19:40:03  <jeremyrubin> E.g., people attempting to integrate it and acutally use taproot
6352020-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)
6362020-06-18T19:40:35  <sipa> jeremyrubin: that would be great, but i fear that it's a bit of a chicken and egg problem
6372020-06-18T19:40:39  <luke-jr> segnet worked okay AFAIR
6382020-06-18T19:40:40  <luke-jr> testing should be before merge anyway
6392020-06-18T19:41:06  <provoostenator> luke-jr: signet could be in a release and completely changed in the next release though
6402020-06-18T19:41:20  <ariard> sipa: does feature_taproot.py attempt any coverage-guided like a fuzzer?
6412020-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)
6422020-06-18T19:41:25  <sipa> ariard: no
6432020-06-18T19:41:27  <provoostenator> Or we could release a taproot signet binary seperately
6442020-06-18T19:41:40  <jeremyrubin> sipa: indeed it's hard. I think if signet comes out then people will integrate test against it
6452020-06-18T19:41:54  <luke-jr> provoostenator: that seems like a given
6462020-06-18T19:42:00  <jeremyrubin> Just more noting that just getting signet out doesn't do anything in terms of progress alone
6472020-06-18T19:42:19  <luke-jr> provoostenator: otherwise we'd be merging taproot before testing it
6482020-06-18T19:42:19  <sipa> ariard: fuzzing definitely makes sense to test for things like memory violations and UB
6492020-06-18T19:42:36  <wumpus> well if it helps getting more attention to testing taproot, that's progress
6502020-06-18T19:42:44  <sipa> luke-jr: i think there are different stages of testing, and different stages of getting attention to it
6512020-06-18T19:43:04  <ariard> sipa: right you may have nast edges cases we wide trees and oversized tapscripts?
6522020-06-18T19:43:22  *** bitcoin-git has joined #bitcoin-core-dev
6532020-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
6542020-06-18T19:43:25  *** bitcoin-git has left #bitcoin-core-dev
6552020-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
6562020-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
6572020-06-18T19:43:43  <ariard> okay great
6582020-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
6592020-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
6602020-06-18T19:44:24  <jeremyrubin> I understand why kallewoof did it that way and it makes sense
6612020-06-18T19:44:36  <jeremyrubin> But it just makes it difficult for people to want to merge it
6622020-06-18T19:44:40  <sipa> jeremyrubin: this seems orthogonal
6632020-06-18T19:44:54  <jeremyrubin> slightly
6642020-06-18T19:45:12  <sipa> i don't think taproot should be blocked by signet in any case
6652020-06-18T19:45:16  <luke-jr> sipa: but I think we want tapnet before merging?
6662020-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
6672020-06-18T19:45:23  <sipa> luke-jr: perhaps
6682020-06-18T19:45:31  <sipa> luke-jr: i think that may make sense
6692020-06-18T19:45:39  <jeremyrubin> What about just flag daying testnet?
6702020-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
6712020-06-18T19:46:19  <wumpus> as said, testnet needs to be compatible between releases, so there's not much scope for experimentation there
6722020-06-18T19:46:29  * luke-jr glad to hear brakmic hasn't given up on us completely :x
6732020-06-18T19:46:36  <luke-jr> wumpus: doesn't need to be..
6742020-06-18T19:47:43  <ariard> do we expect to introduce new standard rules on taproot witness?
6752020-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
6762020-06-18T19:47:49  <MarcoFalke> lol, wasn't testnet hardforked for segwit?
6772020-06-18T19:48:21  <MarcoFalke> I mean silent hardfork. "hardfork" is probably the wrong word
6782020-06-18T19:48:22  <jeremyrubin> wumpus: ah I see. I thought we can just reset testnet if we want. Does anyone care?
6792020-06-18T19:48:41  <jeremyrubin> wumpus: you can also make a soft fork flag day that a rule is enforced for N blocks only
6802020-06-18T19:48:43  <wumpus> jeremyrubin: it's possible but should probably be avoided
6812020-06-18T19:48:58  <sipa> ariard: yes, though they're pretty weak; upgradability (annex, new leaf versions, ...), and max stack item size
6822020-06-18T19:49:03  <sipa> ariard: https://github.com/bitcoin/bitcoin/pull/17977/commits/fa2b4fded614ef2424404b22a07bfbdb2d77ea6c
6832020-06-18T19:49:18  <wumpus> doing things like 'reset testnet' isn't going to make changes more popular
6842020-06-18T19:49:36  <jeremyrubin> wumpus: what about flag day testnet and rule only valid for 6 mos of blocks?
6852020-06-18T19:50:30  <provoostenator> I find it hard to believe a non-trivial change to testnet is more difficult than signet.
6862020-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
6872020-06-18T19:50:58  <sipa> meh, we can just create specialized testnets
6882020-06-18T19:51:03  <sipa> before or after merge
6892020-06-18T19:51:14  <luke-jr> contention to resetting testnet, is a reason to reset testnet :P
6902020-06-18T19:51:24  <sipa> testnet has compatbility requirements
6912020-06-18T19:51:29  <sipa> specialized things don't
6922020-06-18T19:52:03  <wumpus> right, a specialized testnet would make sense, that's basically what signet is anyway (except the mining part)
6932020-06-18T19:52:14  <sipa> indeed
6942020-06-18T19:52:22  <moneyball> do we consider this PR required for taproot? https://github.com/bitcoin/bitcoin/pull/18044
6952020-06-18T19:52:50  <moneyball> and this one? https://github.com/bitcoin/bitcoin/pull/19184
6962020-06-18T19:52:50  <sipa> moneyball: i believe sdaftuar has some thoughts on that
6972020-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
6982020-06-18T19:54:02  <jeremyrubin> network stuff isn't required
6992020-06-18T19:54:06  <jeremyrubin> It can be done after
7002020-06-18T19:54:18  <sipa> jeremyrubin: read the wtxid relay PR
7012020-06-18T19:54:24  <sipa> it gives a justification
7022020-06-18T19:55:23  <ariard> right because v0 segwit nodes are going to waste bandwidth constantly redownloading taproot txn they can't verify
7032020-06-18T19:55:38  <sipa> indeed
7042020-06-18T19:55:57  <sipa> this depends on how upgraded nodes are at the time of activation of course
7052020-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
7062020-06-18T19:56:31  <ariard> ofc how long it takes to get 80% of segwit nodes ? or similar number based on previous forks?
7072020-06-18T19:56:39  <jeremyrubin> yeah I am familiar. It's not great, but I personally don't think it's blocking
7082020-06-18T19:56:57  <sipa> ok
7092020-06-18T19:57:18  <jeremyrubin> I could be wrong on that though
7102020-06-18T19:57:50  <sipa> moneyball: i think wtxid could be done before 19184
7112020-06-18T19:58:10  <sipa> (but i'm obviously biased in liking 19184 to get in)
7122020-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?
7132020-06-18T19:58:34  <wumpus> meeting time about to end
7142020-06-18T19:58:50  <sipa> ariard: well, it's linear, but with a possibly big constant factor
7152020-06-18T19:59:09  <moneyball> ok thank you for the feedback. this has been valuable. lots to follow-up on though!
7162020-06-18T20:00:11  *** promag_ has quit IRC
7172020-06-18T20:00:18  <wumpus> #endmeeting
7182020-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)
7192020-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
7202020-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
7212020-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
7222020-06-18T20:00:26  *** Kiminuo has quit IRC
7232020-06-18T20:00:53  *** bitcoin-git has joined #bitcoin-core-dev
7242020-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
7252020-06-18T20:00:54  *** bitcoin-git has left #bitcoin-core-dev
7262020-06-18T20:01:09  *** hebasto has quit IRC
7272020-06-18T20:05:47  *** hebasto has joined #bitcoin-core-dev
7282020-06-18T20:07:13  *** hebasto has joined #bitcoin-core-dev
7292020-06-18T20:07:36  *** promag_ has joined #bitcoin-core-dev
7302020-06-18T20:07:57  *** hebasto has quit IRC
7312020-06-18T20:08:15  *** hebasto has joined #bitcoin-core-dev
7322020-06-18T20:10:46  *** hebasto has quit IRC
7332020-06-18T20:14:34  *** hebasto has joined #bitcoin-core-dev
7342020-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
7352020-06-18T20:21:59  <hebasto> MarcoFalke: could you suggest a comment for #19323?
7362020-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
7372020-06-18T20:31:50  *** bitcoin-git has joined #bitcoin-core-dev
7382020-06-18T20:31:52  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/c2bcb99c1d11...dbd7a91fdf3f
7392020-06-18T20:31:53  <bitcoin-git> bitcoin/master 45c08f8 Andrew Chow: Add Create*WalletDatabase functions
7402020-06-18T20:31:53  <bitcoin-git> bitcoin/master d6045d0 Andrew Chow: scripted-diff: Replace WalletDatabase::Create* with CreateWalletDatabase
7412020-06-18T20:31:54  <bitcoin-git> bitcoin/master da7a83c Andrew Chow: Remove WalletDatabase::Create, CreateMock, and CreateDummy
7422020-06-18T20:31:56  *** bitcoin-git has left #bitcoin-core-dev
7432020-06-18T20:32:10  *** bitcoin-git has joined #bitcoin-core-dev
7442020-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
7452020-06-18T20:32:12  *** bitcoin-git has left #bitcoin-core-dev
7462020-06-18T20:38:38  *** owowo has quit IRC
7472020-06-18T20:39:18  *** promag_ has quit IRC
7482020-06-18T20:47:20  *** owowo has joined #bitcoin-core-dev
7492020-06-18T20:47:30  *** roconnor_ has left #bitcoin-core-dev
7502020-06-18T20:47:44  *** roconnor_ has quit IRC
7512020-06-18T20:48:50  *** harrigan has quit IRC
7522020-06-18T20:49:00  *** harrigan has joined #bitcoin-core-dev
7532020-06-18T20:49:23  *** roconnor has joined #bitcoin-core-dev
7542020-06-18T20:51:53  *** dgenr8 has quit IRC
7552020-06-18T20:53:43  *** Guyver2 has quit IRC
7562020-06-18T20:56:02  *** nobody123 has quit IRC
7572020-06-18T20:58:47  *** lightlike has quit IRC
7582020-06-18T21:00:01  *** meh` has quit IRC
7592020-06-18T21:02:54  *** bitcoin-git has joined #bitcoin-core-dev
7602020-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
7612020-06-18T21:03:05  *** bitcoin-git has left #bitcoin-core-dev
7622020-06-18T21:03:19  *** bitcoin-git has joined #bitcoin-core-dev
7632020-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
7642020-06-18T21:03:20  *** bitcoin-git has left #bitcoin-core-dev
7652020-06-18T21:04:50  *** dgenr8 has joined #bitcoin-core-dev
7662020-06-18T21:10:42  *** Highway62 has joined #bitcoin-core-dev
7672020-06-18T21:11:35  *** Highway61 has quit IRC
7682020-06-18T21:12:17  *** Highway62 is now known as Highway61
7692020-06-18T21:17:07  *** Highway62 has joined #bitcoin-core-dev
7702020-06-18T21:18:32  *** Highway61 has quit IRC
7712020-06-18T21:18:32  *** Highway62 is now known as Highway61
7722020-06-18T21:21:01  *** promag_ has joined #bitcoin-core-dev
7732020-06-18T21:22:23  *** Mikaku1 has joined #bitcoin-core-dev
7742020-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?
7752020-06-18T21:24:51  <achow101> dongcarl: the current repo owner needs to initiaite it. then a bitcoin-core admin needs to approve it
7762020-06-18T21:25:00  <dongcarl> I see
7772020-06-18T21:25:09  <dongcarl> cfields: Could you initiate it?
7782020-06-18T21:25:54  <achow101> oh and the repo owner needs to have create permissions in the bitcoin-core org
7792020-06-18T21:25:58  <achow101> forgot the most important part
7802020-06-18T21:26:51  <achow101> when I moved HWI, wumpus had to grant some permission to all members, then remove that permission
7812020-06-18T21:27:27  <dongcarl> :-/
7822020-06-18T21:27:44  <dongcarl> Seems easier just to start afresh and push to the repo?
7832020-06-18T21:27:58  <achow101> then you lose any existing issues and PRs
7842020-06-18T21:28:25  *** jarthur has quit IRC
7852020-06-18T21:29:15  <cfields> It's just 1 file :p
7862020-06-18T21:30:50  <achow101> maybe just add it to the packaging repo then? it's kind of packaging related
7872020-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.
7882020-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
7892020-06-18T21:49:01  *** luke-jr has quit IRC
7902020-06-18T21:49:20  *** gzhao408 has quit IRC
7912020-06-18T21:49:24  *** luke-jr has joined #bitcoin-core-dev
7922020-06-18T21:49:34  <cfields> I'll just initiate the xfer. Let me try to figure that out.
7932020-06-18T21:50:27  <sipa> can i help?
7942020-06-18T21:52:51  <cfields> "You don’t have the permission to create public repositories on bitcoin-core"
7952020-06-18T21:53:23  <cfields> Yeah, let's not worry about moving it. It's not worth the effort.
7962020-06-18T21:54:16  <cfields> Either new repo or packaging repo are fine.
7972020-06-18T21:55:27  *** marcoagner has quit IRC
7982020-06-18T21:55:44  <cfields> sipa: can you create a new repo in bitcoin-core ?
7992020-06-18T21:58:41  <sipa> yes
8002020-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?
8012020-06-18T22:01:36  <sipa> sgtm
8022020-06-18T22:07:35  <sipa> cfields: i don't have ownership rights on your repo
8032020-06-18T22:09:03  *** kristapsk has quit IRC
8042020-06-18T22:14:11  *** justanotheruser has quit IRC
8052020-06-18T22:14:43  *** AaronvanW has quit IRC
8062020-06-18T22:19:15  <dongcarl> sipa: many thanks!
8072020-06-18T22:22:49  <sipa> ok, all done, i think
8082020-06-18T22:24:01  <cfields> sipa: thanks!
8092020-06-18T22:24:21  <cfields> I just commented on the lone migrated issue to make this all seem worthwhile.
8102020-06-18T22:24:23  <sipa> yw
8112020-06-18T22:32:18  *** justanotheruser has joined #bitcoin-core-dev
8122020-06-18T22:47:24  *** filchef has joined #bitcoin-core-dev
8132020-06-18T22:48:07  *** filchef has quit IRC
8142020-06-18T22:56:20  *** Isthmus_ has left #bitcoin-core-dev
8152020-06-18T22:57:05  *** Isthmus has joined #bitcoin-core-dev
8162020-06-18T22:57:50  *** Chris_Stewart_5 has quit IRC
8172020-06-18T23:05:58  *** troygiorshev has quit IRC
8182020-06-18T23:14:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8192020-06-18T23:20:47  *** Chris_Stewart_5 has quit IRC
8202020-06-18T23:43:56  *** S3RK has joined #bitcoin-core-dev
8212020-06-18T23:48:23  *** S3RK has quit IRC