12021-07-16T00:11:55  *** grettke is now known as grettke-away
  22021-07-16T00:13:22  *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 246 seconds)
  32021-07-16T00:14:47  *** sipa <sipa!~pw@user/sipa> has quit IRC (Quit: leaving)
  42021-07-16T00:21:46  *** lightlike <lightlike!~lightlike@user/lightlike> has quit IRC (Quit: Leaving)
  52021-07-16T00:23:38  *** sipa <sipa!~pw@user/sipa> has joined #bitcoin-core-dev
  62021-07-16T00:33:11  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 255 seconds)
  72021-07-16T00:33:41  *** grettke-away is now known as grettke
  82021-07-16T00:41:19  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
  92021-07-16T00:41:20  <bitcoin-git> [bitcoin] fanquake closed pull request #22463: [TESTBED][NO-MERGE] Verbosity level 3 getblock rebase (master...verbosity-level-3-getblock-rebase) https://github.com/bitcoin/bitcoin/pull/22463
 102021-07-16T00:41:21  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 112021-07-16T00:42:17  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 122021-07-16T00:42:18  <bitcoin-git> [bitcoin] fanquake closed pull request #22336: [TESTBED][NO-MERGE][POC] Use std::filesystem. Remove Boost Filesystem & System (master...feature/use_std_filesystem_testbed) https://github.com/bitcoin/bitcoin/pull/22336
 132021-07-16T00:42:19  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 142021-07-16T01:32:09  *** grettke is now known as grettke-away
 152021-07-16T01:45:49  *** nanotube <nanotube!~nanotube@user/nanotube> has quit IRC (Quit: *poof*)
 162021-07-16T01:48:49  *** nanotube <nanotube!~nanotube@user/nanotube> has joined #bitcoin-core-dev
 172021-07-16T01:50:40  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 182021-07-16T01:50:41  <bitcoin-git> [bitcoin] dongcarl opened pull request #22465: guix: Pin kernel-header version, time-machine to upstream 1.3.0 commit (master...2021-07-guix-kernel-old) https://github.com/bitcoin/bitcoin/pull/22465
 192021-07-16T01:50:41  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 202021-07-16T02:15:30  *** grettke-away is now known as grettke
 212021-07-16T02:25:34  *** {[o]} <{[o]}!~quassel@174-29-204-46.hlrn.qwest.net> has joined #bitcoin-core-dev
 222021-07-16T02:33:30  *** grettke is now known as grettke-away
 232021-07-16T02:42:21  *** grettke-away is now known as grettke
 242021-07-16T03:02:46  <fanquake> robertspigler: there are a number of benefits that come with using Guix as a release build environment (or just as a build system in general).
 252021-07-16T03:02:52  <fanquake> Using gitian, you have to pick a Linux distro to build on. This defines your toolchains, available packages, the glibc your building against etc.
 262021-07-16T03:02:59  <fanquake> This also means you're subject to choices of the upstream package maintainers. They control how/when package versions are updated, what patches are applied to them, how they are compiled etc. This has downsides.
 272021-07-16T03:03:07  <fanquake> As an example, our security-check tests rely on a number of -no-* options being present in mingw-w64 ld. These options were patched into the ld in the Ubuntu Bionic binutils-mingw-w64 package, however, the binutils maintainer chose to stop doing that in Ubuntu Focal, which meant our security-check tests would not have been able to run (they have since decided to re-patch them in Hirsute). See #18629 for more details.
 282021-07-16T03:03:09  <gribble> https://github.com/bitcoin/bitcoin/issues/18629 | scripts: add PE .reloc section check to security-check.py by fanquake · Pull Request #18629 · bitcoin/bitcoin · GitHub
 292021-07-16T03:03:16  <fanquake> In Guix, because we're in full control of our toolchains, we don't have to worry about issues like this, and can just directly apply the patches we want to use, and this is exactly what we've done in #22381, where we started patching the -no-* linker options into our mingw-w64 toolchain. Compiler / linker options or defaults that we may rely on, can no-longer be randomly changing out from underneath us.
 302021-07-16T03:03:18  <gribble> https://github.com/bitcoin/bitcoin/issues/22381 | guix: Test security-check sanity before performing them (with macOS) by fanquake · Pull Request #22381 · bitcoin/bitcoin · GitHub
 312021-07-16T03:03:23  <fanquake> To that, some might say "well just don't change the Ubuntu base image, and things won't change". To that, I'd say, I don't want the project to be in a position where we are "stuck", and can't update our base image to use new tools (i.e compilers), because by doing so we'll just break something else, like our security tests.
 322021-07-16T03:03:28  <fanquake> It would seem smarter to just remove the potential for those kinds of problem entirely, by constructing and using exactly the release build environment we want.
 332021-07-16T03:03:34  <fanquake> "Well why not just patch / change things in gitian" - I wont say much on this, except for, the gitian environment is not at all setup to do the same kind of patching that we can fairly trivially achieve in Guix. Trying to patch and compile, for example, the mingw-w64 toolchain in a gitian descriptor, would also just turn into a terrible mess.
 342021-07-16T03:03:39  <fanquake> The same can be said about trying to gitian build anything using a glibc different than what is already available on that version of Ubuntu.
 352021-07-16T03:03:44  <fanquake> This has backward-compatibility implications, as the version of glibc you're building against, essentially determines your runtime glibc compatiblity. However this can be extended by using the sorts of "workarounds" that we currently have in our glibc-back-compat code.
 362021-07-16T03:03:51  <fanquake> Now, similar to the situation where you might want to use a newer Ubuntu release (for any number of reasons), doing so will mean that you have to build against a newer glibc (you just get whatever version comes with that release of Ubuntu).
 372021-07-16T03:03:57  <fanquake> This means that as you use newer versions of glibc, the number of "workarounds" you need to maintain backwards compatibility pile up, get continually more complicated, and even start to leak out of Bitcoin Core code, and into our dependency system. See all the PRs linked in this comment: https://github.com/bitcoin/bitcoin/pull/22418#issuecomment-876379846.
 382021-07-16T03:04:07  <fanquake> Changes like that leaking into depends are bad, because now normals builders, using depends, are now being subject to the side-effects of patches that are only really necessary in our release build environment. Maybe you'd argue that in that case we should only apply the depends patches when building releases, however then you've got a situation where release builds are even more divergent from "normal"/developer builds, and this means
 392021-07-16T03:04:07  <fanquake> either maintaining an even more complex CI / testing routines, or they just end up less tested (guess which one is more likely to happen).
 402021-07-16T03:04:15  <fanquake> If that all just sounds like a complicated mess, it's basically because it is. However the solution, using Guix, is actually pretty straight forward.
 412021-07-16T03:04:22  <fanquake> When we are in complete control of our release environment, we can pick exactly the version of glibc we want to use (even at a per-HOST level), something that we definitely couldn't achieve, in any sort of straight forward fashion, if at all, using gitian.
 422021-07-16T03:04:28  <fanquake> This is something we've done recently, in #22365. We are now building using glibc 2.27 for the RISC-V HOST, and using glibc 2.24 for all others, while maintaining runtime compatibility with glibc 2.17. You'll note this this is achieved without needing to use any of the work arounds from our glibc-back-compat code (#22405), or any of the other PRs / changes mentioned in the comment above.
 432021-07-16T03:04:31  <gribble> https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
 442021-07-16T03:04:32  <gribble> https://github.com/bitcoin/bitcoin/issues/22405 | build: remove --enable-glibc-back-compat from Guix build by fanquake · Pull Request #22405 · bitcoin/bitcoin · GitHub
 452021-07-16T03:04:37  <fanquake> These are just two very practical benefits that using Guix provides (there are more), which ultimately all boil down to us being in much greater control of our release build environment. Something I am very happy about, and I think makes a lot of sense for a project like Bitcoin Core.
 462021-07-16T03:04:46  <fanquake> The fact that there are also many people in the Guix space actively working on bootstrapability is just another big bonus, and even if that doesn't work exactly like some may want it too right now, it is rapidly being improved, month on month.
 472021-07-16T03:04:52  <fanquake> Guix is also a much more likely pathway to fully bootstrapable Bitcoin Core builds that what gitian could ever provide.
 482021-07-16T03:06:20  *** earnestly <earnestly!~earnest@user/earnestly> has quit IRC (Ping timeout: 252 seconds)
 492021-07-16T03:10:58  *** grettke is now known as grettke-away
 502021-07-16T03:25:55  *** {[o]} <{[o]}!~quassel@174-29-204-46.hlrn.qwest.net> has quit IRC (Ping timeout: 265 seconds)
 512021-07-16T03:29:32  <dongcarl> 👏
 522021-07-16T03:45:33  *** grettke-away is now known as grettke
 532021-07-16T03:53:11  *** jarthur_ <jarthur_!~jarthur@2603-8080-1540-002d-6c53-2ea3-89b4-023b.res6.spectrum.com> has joined #bitcoin-core-dev
 542021-07-16T03:54:42  *** jarthur <jarthur!~jarthur@2603-8080-1540-002d-3440-ee66-189d-dbb7.res6.spectrum.com> has quit IRC (Ping timeout: 245 seconds)
 552021-07-16T03:56:28  *** davterra <davterra!~davterra@143.244.186.214> has quit IRC (Ping timeout: 272 seconds)
 562021-07-16T04:03:01  *** hex17or_ <hex17or_!~hex17or@gateway/tor-sasl/hex17or> has joined #bitcoin-core-dev
 572021-07-16T04:05:56  *** hex17or <hex17or!~hex17or@gateway/tor-sasl/hex17or> has quit IRC (Ping timeout: 244 seconds)
 582021-07-16T04:22:04  <robertspigler> fanquake: That's great, thanks for the detailed explanation! I didn't know there were benefits beyond bootstrappability. So that makes me even more confused re: why run guix in gitian?
 592021-07-16T04:27:28  *** davterra <davterra!~davterra@178.128.106.205> has joined #bitcoin-core-dev
 602021-07-16T04:47:25  *** davterra <davterra!~davterra@178.128.106.205> has quit IRC (Ping timeout: 246 seconds)
 612021-07-16T04:57:10  *** {[o]} <{[o]}!~quassel@174-29-204-46.hlrn.qwest.net> has joined #bitcoin-core-dev
 622021-07-16T05:08:40  <dongcarl> robertspigler: I don't think we're going to run Guix inside Gitian for the releases, but personally I think people are free to do whatever they think make sense if they're committed to maintaining it
 632021-07-16T05:09:20  <robertspigler> Sure, I agree with that
 642021-07-16T05:09:34  <robertspigler> I was wondering if I was missing something, but it doesn't seem that I am
 652021-07-16T05:23:49  *** davterra <davterra!~davterra@143.244.186.214> has joined #bitcoin-core-dev
 662021-07-16T05:24:54  *** {[o]} <{[o]}!~quassel@174-29-204-46.hlrn.qwest.net> has quit IRC (Ping timeout: 258 seconds)
 672021-07-16T05:36:45  *** {[o]} <{[o]}!~quassel@174-29-204-46.hlrn.qwest.net> has joined #bitcoin-core-dev
 682021-07-16T05:46:10  *** vnogueir- <vnogueir-!~vnogueira@user/vnogueira> has quit IRC (Ping timeout: 244 seconds)
 692021-07-16T06:01:49  *** babasancheti <babasancheti!~babasanch@43.249.232.35> has joined #bitcoin-core-dev
 702021-07-16T06:03:38  *** grettke is now known as grettke-away
 712021-07-16T06:05:25  *** {[o]} <{[o]}!~quassel@174-29-204-46.hlrn.qwest.net> has quit IRC (Ping timeout: 265 seconds)
 722021-07-16T06:05:33  *** jarthur_ <jarthur_!~jarthur@2603-8080-1540-002d-6c53-2ea3-89b4-023b.res6.spectrum.com> has quit IRC (Ping timeout: 255 seconds)
 732021-07-16T06:06:53  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 742021-07-16T06:06:54  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a88fa1a55519...f8b20fd35b0e
 752021-07-16T06:06:54  <bitcoin-git> bitcoin/master e49d50c Jon Atack: bench: fix 32-bit narrowing warning in bench/peer_eviction.cpp
 762021-07-16T06:06:54  <bitcoin-git> bitcoin/master f8b20fd MarcoFalke: Merge bitcoin/bitcoin#22464: bench: fix 32-bit narrowing warning in bench/...
 772021-07-16T06:06:55  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 782021-07-16T06:07:09  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 792021-07-16T06:07:10  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #22464: bench: fix 32-bit narrowing warning in bench/peer_eviction.cpp (master...fix-32bit-narrowing-warning) https://github.com/bitcoin/bitcoin/pull/22464
 802021-07-16T06:07:11  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 812021-07-16T06:10:58  *** gleb <gleb!~gleb@178.150.137.228> has quit IRC (Ping timeout: 240 seconds)
 822021-07-16T06:27:56  *** {[o]} <{[o]}!~quassel@174-29-204-46.hlrn.qwest.net> has joined #bitcoin-core-dev
 832021-07-16T06:32:55  *** jarthur <jarthur!~jarthur@2603-8080-1540-002d-b887-749f-7796-49c4.res6.spectrum.com> has joined #bitcoin-core-dev
 842021-07-16T06:41:49  *** vnogueira <vnogueira!~vnogueira@user/vnogueira> has joined #bitcoin-core-dev
 852021-07-16T06:47:12  *** belcher_ is now known as belcher
 862021-07-16T07:04:20  <luke-jr> robertspigler: you don't lose those Guix benefits by running it inside gitian; gitian just provides the isolation needed to avoid regressing on security
 872021-07-16T07:08:50  *** hex17or_ <hex17or_!~hex17or@gateway/tor-sasl/hex17or> has quit IRC (Ping timeout: 244 seconds)
 882021-07-16T07:09:08  *** hex17or <hex17or!~hex17or@gateway/tor-sasl/hex17or> has joined #bitcoin-core-dev
 892021-07-16T07:11:37  *** kiran <kiran!~quassel@43.225.167.10> has joined #bitcoin-core-dev
 902021-07-16T07:13:51  *** babasancheti <babasancheti!~babasanch@43.249.232.35> has quit IRC (Quit: Client closed)
 912021-07-16T07:22:09  *** grettke-away is now known as grettke
 922021-07-16T07:23:07  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
 932021-07-16T07:24:16  *** earnestly <earnestly!~earnest@user/earnestly> has joined #bitcoin-core-dev
 942021-07-16T07:43:00  <vasild> MarcoFalke: do you think that the fuzzer inputs from #22450 should be collected and added to bitcoin-core/qa-assets ?
 952021-07-16T07:43:01  <gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
 962021-07-16T07:43:59  *** grettke is now known as grettke-away
 972021-07-16T07:53:13  *** user__ <user__!~davterra@143.244.186.214> has joined #bitcoin-core-dev
 982021-07-16T07:53:14  *** davterra <davterra!~davterra@143.244.186.214> has quit IRC (Read error: Connection reset by peer)
 992021-07-16T07:54:00  *** cryptapus <cryptapus!~cryptapus@user/cryptapus> has quit IRC (Remote host closed the connection)
1002021-07-16T07:54:25  *** cryptapus <cryptapus!~cryptapus@user/cryptapus> has joined #bitcoin-core-dev
1012021-07-16T08:00:25  *** jarthur <jarthur!~jarthur@2603-8080-1540-002d-b887-749f-7796-49c4.res6.spectrum.com> has quit IRC (Quit: jarthur)
1022021-07-16T08:07:24  *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
1032021-07-16T08:08:55  <laanwj> as not much is left for rc1, we could branch off 22.0 so that the master branch is free for merging for 23.0
1042021-07-16T08:22:35  *** beshology <beshology!~beshology@197.54.237.95> has joined #bitcoin-core-dev
1052021-07-16T08:24:22  *** beshology <beshology!~beshology@197.54.237.95> has quit IRC (Client Quit)
1062021-07-16T08:25:35  *** Bilnon <Bilnon!~8iIn0n@2a01:4b00:8e07:7900:b6bd:82d9:48d3:acee> has joined #bitcoin-core-dev
1072021-07-16T08:26:31  *** Bilnon <Bilnon!~8iIn0n@2a01:4b00:8e07:7900:b6bd:82d9:48d3:acee> has quit IRC (Client Quit)
1082021-07-16T08:28:23  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 255 seconds)
1092021-07-16T08:32:52  *** dr-orlovsky <dr-orlovsky!~dr-orlovs@31.14.40.19> has joined #bitcoin-core-dev
1102021-07-16T08:34:15  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
1112021-07-16T08:43:42  *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
1122021-07-16T08:44:11  *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has joined #bitcoin-core-dev
1132021-07-16T08:48:22  *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has quit IRC (Client Quit)
1142021-07-16T08:48:54  *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has joined #bitcoin-core-dev
1152021-07-16T09:04:13  *** kexkey <kexkey!~kexkey@static-198-54-132-103.cust.tzulo.com> has quit IRC (Ping timeout: 268 seconds)
1162021-07-16T09:05:24  *** kexkey <kexkey!~kexkey@static-198-54-132-87.cust.tzulo.com> has joined #bitcoin-core-dev
1172021-07-16T09:23:48  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
1182021-07-16T09:26:34  *** lightlike <lightlike!~lightlike@user/lightlike> has joined #bitcoin-core-dev
1192021-07-16T09:29:29  <jnewbery> vasild: what do you think about just removing any non-port0 I2P addresses from addrman in RemoveInvalid()? Seems a lot safer than a bunch of new code in ResetI2PPorts()
1202021-07-16T09:32:51  <vasild> all of them are with port 8333, so that would be the same as just removing all I2P addresses from addrman (done just once)
1212021-07-16T09:33:38  <vasild> hmm, and because some peers will keep advertising themselves with port 8333, we will keep removing them
1222021-07-16T09:34:35  <vasild> jnewbery: actually removing from addrman was tricky, IIRC, there is no Delete() method
1232021-07-16T09:35:02  <vasild> if we are to remove them, we may as well re-add with port 0, like you suggested
1242021-07-16T09:35:55  <jnewbery> doesn't RemoveInvalid() delete entries?
1252021-07-16T09:37:04  <vasild> yes, and it does the same as ResetI2PPorts() - fiddle with addrman internals
1262021-07-16T09:37:48  <jonatack> One thought. This change was fairly well-tested over a period of time; 3 people ran it for several days each (in my case, with a number of added asserts and with -DDEBUG_ADDRMAN).  A re-do might see less testing.
1272021-07-16T09:38:19  <vasild> that's true
1282021-07-16T09:38:25  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1292021-07-16T09:38:26  <bitcoin-git> [bitcoin] jnewbery closed pull request #18685: consensus: Simplify ConnectTrace (master...2020-04-connecttrace-simplify) https://github.com/bitcoin/bitcoin/pull/18685
1302021-07-16T09:38:27  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1312021-07-16T09:39:18  <jonatack> (I ran it cumulatively for a couple of weeks that way.)
1322021-07-16T09:39:38  <jonatack> With a bunch of restarts and other tests.
1332021-07-16T09:40:05  <vasild> Notice that the problem reported in #22450 OP/description is not related to RemoveInvalid() or ResetI2PPorts() (IMO, jnewbery may disagree)
1342021-07-16T09:40:06  <gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
1352021-07-16T09:40:44  <vasild> I am now looking at https://github.com/bitcoin/bitcoin/issues/22450#issuecomment-880629375 which is a different issue, not sure yet where is the problem
1362021-07-16T09:41:29  <jnewbery> vasild: do you disagree that https://github.com/bitcoin/bitcoin/issues/22450#issuecomment-880602891 can cause corruption?
1372021-07-16T09:44:47  <vasild> jnewbery: https://github.com/bitcoin/bitcoin/issues/22450#issuecomment-880602891 is a 3rd issue, I have not confirmed it yet, but read the comment: yes, it looks like it can cause a corruption, but again that is a 3rd distinct problem. I suspect it may be resolved by just removing "addr_info.GetPort() == I2P_SAM31_PORT"
1382021-07-16T10:00:00  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 268 seconds)
1392021-07-16T10:40:31  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1402021-07-16T10:40:31  <bitcoin-git> [bitcoin] vasild opened pull request #22468: addrman: don't overwrite addr_info when resetting I2P ports (master...reset_i2p_ports_no_overwrite_pos) https://github.com/bitcoin/bitcoin/pull/22468
1412021-07-16T10:40:32  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1422021-07-16T11:05:36  <MarcoFalke> > [09:43] <vasild> MarcoFalke: do you think that the fuzzer inputs from #22450 should be collected and added to bitcoin-core/qa-assets ?
1432021-07-16T11:05:38  <gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
1442021-07-16T11:05:50  <MarcoFalke> Yes, but only after the bugfixes are in. Otherwise we have red CI
1452021-07-16T11:10:18  *** {[o]} <{[o]}!~quassel@174-29-204-46.hlrn.qwest.net> has quit IRC (Ping timeout: 272 seconds)
1462021-07-16T11:35:01  <vasild> right
1472021-07-16T11:53:30  *** roconnor <roconnor!~roconnor@host-45-58-195-5.dyn.295.ca> has joined #bitcoin-core-dev
1482021-07-16T11:58:19  <vasild> jnewbery: I said "there is no Delete() method", actually there is, but it only deletes entries from "new" which have 0 references.
1492021-07-16T12:08:46  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1502021-07-16T12:08:47  <bitcoin-git> [bitcoin] hebasto opened pull request #22469: build: Add support for Android NDK r22+ (master...210716-ndk) https://github.com/bitcoin/bitcoin/pull/22469
1512021-07-16T12:08:48  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1522021-07-16T12:21:54  <jnewbery> vasild: I think the entire approach in ResetI2PPorts() is scary. Even if you fix these corruption issues, how do you know there aren't more?
1532021-07-16T12:31:44  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
1542021-07-16T12:36:56  <vasild> jnewbery: I can't be sure there aren't more bugs. But that is also true for any software.
1552021-07-16T12:37:58  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
1562021-07-16T12:39:24  <vasild> Do you think RemoveInvalid() is ok (not scary)? It is very similar to ResetI2PPorts() in the way they iterate over the buckets and do something to relevant entries
1572021-07-16T12:51:23  <jnewbery> RemoveInvalid() seems better to me in that it's doing less to the internal data structures. I'd like it even more if Delete() was extended to support deleting tried entries, so there's less code duplication. It also got more review before being merged, which gives me some more confidence.
1582021-07-16T12:56:18  <vasild> "I'd like it even more if Delete() was extended..." me too! It need to be extended not only to delete tried entries but also new ones that have reference>0
1592021-07-16T12:57:09  <vasild> the current one should be called something like DeleteNewWithRef0OrIWillAssert()
1602021-07-16T13:10:05  *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
1612021-07-16T13:10:21  *** mekster6 <mekster6!~mekster@user/mekster> has joined #bitcoin-core-dev
1622021-07-16T13:10:48  *** darosior0 <darosior0!~darosior@194.36.189.246> has joined #bitcoin-core-dev
1632021-07-16T13:11:20  *** kexkey_ <kexkey_!~kexkey@static-198-54-132-87.cust.tzulo.com> has joined #bitcoin-core-dev
1642021-07-16T13:11:27  *** dr_orlovsky <dr_orlovsky!~dr-orlovs@31.14.40.19> has joined #bitcoin-core-dev
1652021-07-16T13:11:39  *** GIANTWORLDKEEPR_ <GIANTWORLDKEEPR_!~pjetcetal@128-71-13-182.broadband.corbina.ru> has joined #bitcoin-core-dev
1662021-07-16T13:12:42  *** jnewbery_ <jnewbery_!~john@user/jnewbery> has joined #bitcoin-core-dev
1672021-07-16T13:12:44  *** roconnor <roconnor!~roconnor@host-45-58-195-5.dyn.295.ca> has quit IRC (Ping timeout: 268 seconds)
1682021-07-16T13:13:45  *** andytosh1 <andytosh1!~apoelstra@s66-183-0-205.bc.hsia.telus.net> has joined #bitcoin-core-dev
1692021-07-16T13:13:52  <jonatack> yup, I called for more people to review in https://github.com/bitcoin/bitcoin/pull/22112#pullrequestreview-699042238, one can't be a review army by oneself but there are indeed few regular p2p contributors who look at work on privacy networks
1702021-07-16T13:14:16  *** gwillen1 <gwillen1!gwillen@user/gwillen> has joined #bitcoin-core-dev
1712021-07-16T13:14:24  *** pigeons_ <pigeons_!~pigeons@androzani.sysevolve.com> has joined #bitcoin-core-dev
1722021-07-16T13:14:26  *** sipa_ <sipa_!~pw@user/sipa> has joined #bitcoin-core-dev
1732021-07-16T13:18:49  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (*.net *.split)
1742021-07-16T13:18:49  *** kexkey <kexkey!~kexkey@static-198-54-132-87.cust.tzulo.com> has quit IRC (*.net *.split)
1752021-07-16T13:18:49  *** dr-orlovsky <dr-orlovsky!~dr-orlovs@31.14.40.19> has quit IRC (*.net *.split)
1762021-07-16T13:18:49  *** sipa <sipa!~pw@user/sipa> has quit IRC (*.net *.split)
1772021-07-16T13:18:49  *** GIANTWORLDKEEPER <GIANTWORLDKEEPER!~pjetcetal@128-71-13-182.broadband.corbina.ru> has quit IRC (*.net *.split)
1782021-07-16T13:18:49  *** jnewbery <jnewbery!~john@user/jnewbery> has quit IRC (*.net *.split)
1792021-07-16T13:18:49  *** Zenton <Zenton!~user@user/zenton> has quit IRC (*.net *.split)
1802021-07-16T13:18:49  *** hardtotell <hardtotell!~hardtotel@satyr.seedboxes.cc> has quit IRC (*.net *.split)
1812021-07-16T13:18:49  *** nathanael <nathanael!~nathanael@user/nathanael> has quit IRC (*.net *.split)
1822021-07-16T13:18:49  *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (*.net *.split)
1832021-07-16T13:18:49  *** pigeons <pigeons!~pigeons@androzani.sysevolve.com> has quit IRC (*.net *.split)
1842021-07-16T13:18:49  *** gwillen <gwillen!~gwillen@user/gwillen> has quit IRC (*.net *.split)
1852021-07-16T13:18:49  *** elichai2 <elichai2!sid212594@stonehaven.irccloud.com> has quit IRC (*.net *.split)
1862021-07-16T13:18:49  *** darosior <darosior!~darosior@194.36.189.246> has quit IRC (*.net *.split)
1872021-07-16T13:18:49  *** mekster <mekster!~mekster@user/mekster> has quit IRC (*.net *.split)
1882021-07-16T13:18:49  *** instagibbs <instagibbs!~instagibb@119247204116.ctinets.com> has quit IRC (*.net *.split)
1892021-07-16T13:18:49  *** andytoshi <andytoshi!~apoelstra@s66-183-0-205.bc.hsia.telus.net> has quit IRC (*.net *.split)
1902021-07-16T13:18:51  *** mekster6 is now known as mekster
1912021-07-16T13:18:51  *** darosior0 is now known as darosior
1922021-07-16T13:18:56  *** Guyver2_ is now known as Guyver2
1932021-07-16T13:19:07  *** hardtotell <hardtotell!~hardtotel@satyr.seedboxes.cc> has joined #bitcoin-core-dev
1942021-07-16T13:19:50  <jonatack> at any rate I continue to run and test the changes with Check_() e.g. DEBUG_ADDRMAN and some sanity check asserts added and will look at #22468.
1952021-07-16T13:19:51  <gribble> https://github.com/bitcoin/bitcoin/issues/22468 | addrman: dont overwrite addr_info when resetting I2P ports by vasild · Pull Request #22468 · bitcoin/bitcoin · GitHub
1962021-07-16T13:20:17  *** nathanael <nathanael!~nathanael@user/nathanael> has joined #bitcoin-core-dev
1972021-07-16T13:20:48  *** elichai2 <elichai2!sid212594@id-212594.stonehaven.irccloud.com> has joined #bitcoin-core-dev
1982021-07-16T13:24:59  *** instagibbs <instagibbs!~instagibb@119247204116.ctinets.com> has joined #bitcoin-core-dev
1992021-07-16T13:46:19  *** jespada <jespada!~jespada@90.254.247.46> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
2002021-07-16T13:46:52  *** jespada <jespada!~jespada@90.254.247.46> has joined #bitcoin-core-dev
2012021-07-16T13:50:41  *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
2022021-07-16T13:51:13  *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
2032021-07-16T13:59:40  *** grettke-away is now known as grettke
2042021-07-16T13:59:41  *** AaronvanW <AaronvanW!~AaronvanW@209.235.170.242> has joined #bitcoin-core-dev
2052021-07-16T14:23:54  *** kiran <kiran!~quassel@43.225.167.10> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2062021-07-16T14:30:46  *** babasancheti <babasancheti!~babasanch@43.249.232.35> has joined #bitcoin-core-dev
2072021-07-16T14:38:23  *** Zenton <Zenton!~user@user/zenton> has joined #bitcoin-core-dev
2082021-07-16T14:45:59  <vasild> jonatack: thanks!
2092021-07-16T14:54:53  *** AaronvanW <AaronvanW!~AaronvanW@209.235.170.242> has quit IRC (Quit: Leaving...)
2102021-07-16T15:35:40  <vasild> sipa_: https://github.com/bitcoin/bitcoin/pull/22455#issuecomment-881525272 -- that is a good question but I think you posted it in the wrong PR, that PR is not related to I2P at all. Maybe you intended to post to #22468 instead?
2112021-07-16T15:35:42  <gribble> https://github.com/bitcoin/bitcoin/issues/22468 | addrman: dont overwrite addr_info when resetting I2P ports by vasild · Pull Request #22468 · bitcoin/bitcoin · GitHub
2122021-07-16T15:38:58  <vasild> sipa_: if we revert that part (which changes ports in addrman from 8333 to 0) then we would break the existent i2p network in a subtle way: all i2p addresses in addrman are with port 8333 and we would refuse to connect to any of them. Then those peers run the new code and start advertising themselves with port=0 however when that gossip reaches a node that already has the address but with port
2132021-07-16T15:39:04  <vasild> 8333, that node will ignore the incoming entry with port=0 and keep the old one with port 8333 (to which it refuses to connect)
2142021-07-16T15:40:07  <vasild> the only solution (I see) would be for everybody to re-generate a new i2p address
2152021-07-16T15:43:54  <sipa_> vasild: but i2p support is only on master, right?
2162021-07-16T15:44:05  <vasild> It _should_ be possible to properly change the ports from 8333 to 0 in addrman.
2172021-07-16T15:44:38  <vasild> sipa_: yes, it is not in any previous releases, but there are already a bunch of nodes and in seeds.txt, so the i2p bitcoin network exists
2182021-07-16T15:44:55  <sipa_> sure, but it's just people running master
2192021-07-16T15:45:02  <vasild> correct
2202021-07-16T15:45:03  <sipa_> we can include a snippet in the release notes
2212021-07-16T15:45:10  *** sipa_ is now known as sipa
2222021-07-16T15:45:57  <sipa> i agree it ought to be possible to hotfix it directly in addrman, but i'm concerned about the fact that inconsistencies have been introduced already
2232021-07-16T15:47:43  <vasild> sipa: you mean that there are already bugs in that code or that some nodes already run with inconsistent addrmans?
2242021-07-16T15:48:37  <sipa> i'm wary about touching addrman more, as it has already been shown it's easy to corrupt
2252021-07-16T15:49:55  <sipa> though i'll have a deeper look at the issue and the proposed fixes too
2262021-07-16T15:51:30  <vasild> there are 3 issues reported in #22450 (sorry, that's messy): 1. the description/OP, fixed in #22455 (not relevant to I2P)
2272021-07-16T15:51:32  <gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
2282021-07-16T15:51:33  <gribble> https://github.com/bitcoin/bitcoin/issues/22455 | addrman: detect on-disk corrupted nNew and nTried during unserialization by vasild · Pull Request #22455 · bitcoin/bitcoin · GitHub
2292021-07-16T15:52:04  <vasild> 2. https://github.com/bitcoin/bitcoin/issues/22450#issuecomment-880629375 which I also reported separately in #22467, fixed in #22468
2302021-07-16T15:52:05  <gribble> https://github.com/bitcoin/bitcoin/issues/22467 | Assertion `nRndPos1 < vRandom.size() && nRndPos2 < vRandom.size() failed · Issue #22467 · bitcoin/bitcoin · GitHub
2312021-07-16T15:52:06  <gribble> https://github.com/bitcoin/bitcoin/issues/22468 | addrman: dont overwrite addr_info when resetting I2P ports by vasild · Pull Request #22468 · bitcoin/bitcoin · GitHub
2322021-07-16T15:53:13  <vasild> 3. https://github.com/bitcoin/bitcoin/issues/22450#issuecomment-880602891 - I am working on it now, will also report it separately and open PR with a fix
2332021-07-16T15:54:10  *** vysn <vysn!~vysn@user/vysn> has joined #bitcoin-core-dev
2342021-07-16T15:59:27  <vasild> A general note about feeding fuzzed input to addrman unserialize: it could result in some unexpected state, like negative nNew coming from disk or duplicate entries which are not allowed during normal operation. Surely it should not crash when unserialized from a random input, as a disk corruption could lead to that too.
2352021-07-16T16:01:17  <vasild> => I think there is a good chance fuzzing addrman unserialize will find more bugs
2362021-07-16T16:04:10  <sipa> definitely
2372021-07-16T16:29:19  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2382021-07-16T16:29:20  <bitcoin-git> [bitcoin] vasild opened pull request #22471: addrman: reset I2P ports in all "new" buckets (master...reset_all_new_i2p_ports) https://github.com/bitcoin/bitcoin/pull/22471
2392021-07-16T16:29:21  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2402021-07-16T16:30:24  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2412021-07-16T16:30:24  <bitcoin-git> [bitcoin] agroce opened pull request #22472: fuzz: Add environment option to keep /tmp/ clean (master...master) https://github.com/bitcoin/bitcoin/pull/22472
2422021-07-16T16:30:25  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2432021-07-16T16:31:15  <vasild> Reported 3. separately as #22470 with a fix in #22471
2442021-07-16T16:31:16  <gribble> https://github.com/bitcoin/bitcoin/issues/22470 | Changing I2P ports in addrman may wronly skip some entries from "new" buckets · Issue #22470 · bitcoin/bitcoin · GitHub
2452021-07-16T16:31:17  <gribble> https://github.com/bitcoin/bitcoin/issues/22471 | addrman: reset I2P ports in all "new" buckets by vasild · Pull Request #22471 · bitcoin/bitcoin · GitHub
2462021-07-16T16:48:22  <jnewbery_> vasild: I'll repeat that I think it's much safer to just delete these entries on startup using the existing RemoveInvalid() code. There are at least two addrman corruption bugs introduced by the ResetI2PPorts() code in #22112. What level of confidence do you have that there aren't more?
2472021-07-16T16:48:25  <gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub
2482021-07-16T16:48:31  *** jnewbery_ is now known as jnewbery
2492021-07-16T16:52:40  <vasild> jnewbery: now that we have a fix for everything, I will also look into that suggestion as an alternative fix for #22467 and #22470. But I don't have high hopes as I tried that and it was not simpler. So, "just delete" will expand to similar number of lines as now in ResetI2PPorts().
2502021-07-16T16:52:41  <gribble> https://github.com/bitcoin/bitcoin/issues/22467 | Assertion `nRndPos1 < vRandom.size() && nRndPos2 < vRandom.size() failed · Issue #22467 · bitcoin/bitcoin · GitHub
2512021-07-16T16:52:41  <gribble> https://github.com/bitcoin/bitcoin/issues/22470 | Changing I2P ports in addrman may wronly skip some entries from "new" buckets · Issue #22470 · bitcoin/bitcoin · GitHub
2522021-07-16T16:54:07  <vasild> notice also that RemoveInvalid() was also added recently, so it is not "sure" that it is safe either, e.g. it is not like it has been running for 5 years
2532021-07-16T16:56:57  <vasild> But I will look into that anyway, it is good to compare different solutions and pick the "better" one
2542021-07-16T16:57:51  *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
2552021-07-16T16:58:56  *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has joined #bitcoin-core-dev
2562021-07-16T17:11:10  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 246 seconds)
2572021-07-16T17:15:03  *** jarthur <jarthur!~jarthur@2603-8080-1540-002d-f52d-d440-e265-bac9.res6.spectrum.com> has joined #bitcoin-core-dev
2582021-07-16T17:17:45  *** murch <murch!~murch@user/murch> has quit IRC (Quit: WeeChat 1.9.1)
2592021-07-16T17:27:49  *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
2602021-07-16T17:29:01  *** lightlike <lightlike!~lightlike@user/lightlike> has quit IRC (Quit: Leaving)
2612021-07-16T17:30:45  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 258 seconds)
2622021-07-16T17:30:46  *** ufotofu <ufotofu!~ufotofu@user/ufotofu> has quit IRC (Ping timeout: 258 seconds)
2632021-07-16T17:30:50  *** Guyver2_ is now known as Guyver2
2642021-07-16T17:31:00  *** ufotofu_ <ufotofu_!~ufotofu@user/ufotofu> has joined #bitcoin-core-dev
2652021-07-16T17:48:39  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
2662021-07-16T17:49:41  *** AaronvanW <AaronvanW!~AaronvanW@50-207-231-44-static.hfc.comcastbusiness.net> has joined #bitcoin-core-dev
2672021-07-16T18:02:03  *** lightlike <lightlike!~lightlike@user/lightlike> has joined #bitcoin-core-dev
2682021-07-16T18:16:21  <BlueMatt> :q
2692021-07-16T18:16:55  <sipa> :q!
2702021-07-16T18:17:06  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
2712021-07-16T18:19:12  *** babasancheti <babasancheti!~babasanch@43.249.232.35> has quit IRC (Quit: Client closed)
2722021-07-16T18:21:49  *** grettke is now known as grettke-away
2732021-07-16T18:22:45  <dongcarl> To the point of Guix continually making progress on bootatrapping, live-bootstrap maintainer mentioned yesterday that: live-bootstrap can build all of the guix bootstrap binaries on i386 (including static guile) so we have an option of replacing bootstrap binaries with built in live-bootstrap.
2742021-07-16T18:23:08  <dongcarl> Here’s live-bootstrap: https://github.com/fosslinux/live-bootstrap
2752021-07-16T18:24:30  <dongcarl> We shall see if it can link up and be used to further minimize the bootstrap chain
2762021-07-16T18:33:27  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 255 seconds)
2772021-07-16T18:39:19  *** roconnor <roconnor!~roconnor@host-45-58-227-60.dyn.295.ca> has joined #bitcoin-core-dev
2782021-07-16T18:39:43  *** jesseposner <jesseposner!~jesse@c-24-4-88-184.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 246 seconds)
2792021-07-16T18:39:44  <roconnor> dongcarl: what is guix time-machine?  The man page is useless in typical GNU fashion.
2802021-07-16T18:41:29  *** jarthur_ <jarthur_!~jarthur@2603-8080-1540-002d-dcfa-1836-6c8e-0e77.res6.spectrum.com> has joined #bitcoin-core-dev
2812021-07-16T18:42:31  *** jarthur <jarthur!~jarthur@2603-8080-1540-002d-f52d-d440-e265-bac9.res6.spectrum.com> has quit IRC (Ping timeout: 246 seconds)
2822021-07-16T18:43:13  <vasild> If all (most?) nodes are already running master + #22112 (merged 3 days on on Jul 13)... that would mean I2P peers now advertise themselves with port 0 and ports have been changed in people's addrmans. If that is the case, then ResetI2PPorts() has achieved its purpose and can be removed. <-- jonatack, sipa, jnewbery, laanwj
2832021-07-16T18:43:17  <gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub
2842021-07-16T18:44:02  <vasild> I will add some monitoring to my node to see if I still receive gossip of i2p:8333
2852021-07-16T18:44:58  <sipa> vasild: that would be useful to know
2862021-07-16T18:46:04  * vasild zZzZ...
2872021-07-16T18:49:36  *** gene <gene!~gene@gateway/tor-sasl/gene> has joined #bitcoin-core-dev
2882021-07-16T19:00:25  <meshcollider> Anyone around for a wallet meeting?
2892021-07-16T19:00:35  <achow101> me
2902021-07-16T19:00:43  <michaelfolkson> Me too
2912021-07-16T19:00:46  <gene> hi
2922021-07-16T19:00:56  <meshcollider> #startmeeting
2932021-07-16T19:00:57  <core-meetingbot> Meeting started Fri Jul 16 19:00:56 2021 UTC.  The chair is meshcollider. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
2942021-07-16T19:00:57  <core-meetingbot> Available commands: action commands idea info link nick
2952021-07-16T19:01:05  <meshcollider> #bitcoin-core-dev Wallet Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag
2962021-07-16T19:01:05  <meshcollider> provoostenator ryanofsky sdaftuar sipa vasild wumpus
2972021-07-16T19:01:13  <meshcollider> Topics?
2982021-07-16T19:01:30  <jonatack> jnewbery: have you (a) been testing I2P on master, and (b) found cases of addrman corruption?  IIUC the ossfuzzer is naturally turning up cases we didn't know about before. ISTM that is to be expected.
2992021-07-16T19:01:38  <fjahr> hi
3002021-07-16T19:01:41  <achow101> hi
3012021-07-16T19:01:46  <jonatack> hi :)
3022021-07-16T19:01:49  <michaelfolkson> hi
3032021-07-16T19:02:19  <michaelfolkson> I have some general Taproot roadmap questions if there's nothing on the agenda
3042021-07-16T19:02:22  <kvaciral[m]> hi
3052021-07-16T19:02:32  <meshcollider> No more urgent wallet things found that need to go into 0.22 right?
3062021-07-16T19:02:36  <meshcollider> 22*
3072021-07-16T19:02:37  <kanzure> hi
3082021-07-16T19:02:58  <achow101> #22461 is the only wallet pr marked for 22.0
3092021-07-16T19:03:00  <gribble> https://github.com/bitcoin/bitcoin/issues/22461 | wallet: Change ScriptPubKeyMan::Upgrade default to True by achow101 · Pull Request #22461 · bitcoin/bitcoin · GitHub
3102021-07-16T19:03:46  <sipa> hi
3112021-07-16T19:04:19  <meshcollider> #topic general taproot roadmap questions (michaelfolkson)
3122021-07-16T19:04:20  <core-meetingbot> topic: general taproot roadmap questions (michaelfolkson)
3132021-07-16T19:05:10  <michaelfolkson> So perhaps starting with PSBT (and apologies if my understanding of PSBT has holes)
3142021-07-16T19:06:09  <achow101> There are proposed taproot fields for psbt PR'd to the bips repo: https://github.com/bitcoin/bips/pull/1139
3152021-07-16T19:06:10  <michaelfolkson> PSBT won't be supporting with MuSig. But to support Taproot multisig (CHECKSIGADD not MuSig) does this get included in PSBT spec?
3162021-07-16T19:06:59  <achow101> anything script based is supported by psbt
3172021-07-16T19:07:02  <sipa> PSBT doesn't need support for individual script types; that's up to individual singer implementations
3182021-07-16T19:07:20  <sipa> taproot support in general needs extensions (already proposed), and MuSig will need its own ones
3192021-07-16T19:07:27  <sipa> but scripts don't need anything
3202021-07-16T19:07:38  <sipa> *signer, not singer
3212021-07-16T19:08:04  <michaelfolkson> I guess I'm trying to unravel what is specs and what is the Core wallet. "Anything script based" but the Core wallet doesn't support Taproot scripts
3222021-07-16T19:08:29  <achow101> the psbt fields have fields for the leaft scripts
3232021-07-16T19:08:31  <sipa> as i said, that's up to the individual signer
3242021-07-16T19:08:33  <achow101> leaf scripts can be anything
3252021-07-16T19:08:46  <sipa> clearly you can't expect every signer to support every script
3262021-07-16T19:08:47  <achow101> it's up to the implementations to figure out what those scripts are doing, and what to do with them
3272021-07-16T19:08:54  <michaelfolkson> Ok I think I understand, thanks
3282021-07-16T19:09:11  <michaelfolkson> The PSBT part isn't doing much
3292021-07-16T19:09:18  <sipa> it's just an interchange format
3302021-07-16T19:09:33  <gene> do PSBT implementations need to validate scripts?
3312021-07-16T19:09:45  <sipa> and the Bitcoin Core wallet does support taproot scripts by the way, just only very limited ones (effectively just "<pubkey> OP_CHECKSIG")
3322021-07-16T19:10:11  <achow101> gene: PSBT implementation don't have to do anything with scripts. whether they should or should not depends on their role
3332021-07-16T19:10:44  <sipa> signers may want to check any number of properties of what they're signing before deciding that signing is right
3342021-07-16T19:10:48  <sipa> but what that is, is up to them
3352021-07-16T19:11:04  <sipa> PSBT just makes sure that data can be made available to them
3362021-07-16T19:11:18  <gene> achow101: so the PSBT impl can just treat scripts as opaque blobs, and then what's on the other side (e.g. a HW wallet) decides what to do with script?
3372021-07-16T19:11:51  <achow101> gene: yes, although both sides would be PSBT implementations, just different roles
3382021-07-16T19:12:00  <gene> +1
3392021-07-16T19:12:10  <sipa> it's a bit ambiguous what you call "PSBT impl"
3402021-07-16T19:12:20  <sipa> if you're just referring to the serializer/deserializer, yes, definitely
3412021-07-16T19:12:44  <sipa> but you probably mean "any software that interacts with PSBT", and they may or may not want to implement various checks, depending on their role and what things they support
3422021-07-16T19:12:45  <gene> yeah, the software/firmware that handles PSBT serialization
3432021-07-16T19:13:10  <gene> ok, that makes sense
3442021-07-16T19:13:13  <sipa> most hardware wallets don't actually handle PSBT directly - they have a software driver that converts between PSBT and the HW API calls
3452021-07-16T19:13:42  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
3462021-07-16T19:13:49  <michaelfolkson> Ok I will reread PSBT BIP with that understanding. That helps, thanks
3472021-07-16T19:13:53  <achow101> in terms of Core supporting more complicated taproot scripts, I think that will depend on miniscript (and more generally, descriptors)
3482021-07-16T19:14:24  <michaelfolkson> Right, and I read this from sipa which was very informative too https://github.com/sipa/miniscript/issues/56#issuecomment-876603384
3492021-07-16T19:15:14  <michaelfolkson> I was surprised that he thinks it is likely Miniscript gets merged into Core without supporting Taproot but I (kinda) understand the argument
3502021-07-16T19:16:03  <sipa> the goal is obviously to extend it at some point to support taproot
3512021-07-16T19:16:23  <sipa> but i don't think it's worth doing more spec work if the implementation isn't making progress
3522021-07-16T19:16:27  <michaelfolkson> To summarize the Taproot Miniscript syntax is easy to design but this will likely be supported by rust-miniscript before the C++ implementation
3532021-07-16T19:16:37  <sipa> it depends what people work on
3542021-07-16T19:17:01  <sipa> i don't know if anyone working on rust-miniscript is working on this either, but they may be in a better position to start doing so
3552021-07-16T19:17:07  <michaelfolkson> "implementation isn't making progress" <- you mean the C++ implementation of Miniscript here right?
3562021-07-16T19:17:11  <sipa> yes
3572021-07-16T19:17:43  <michaelfolkson> But there is this stepping stone between just supporting single key Taproot spends and Miniscript generic scripts
3582021-07-16T19:17:46  <meshcollider> I think we should definitely prioritise it after 22 is done
3592021-07-16T19:18:06  <michaelfolkson> Descriptor scripts could be supported without Miniscript
3602021-07-16T19:18:16  <sipa> they are
3612021-07-16T19:18:22  <sipa> they're just very minimal right now
3622021-07-16T19:18:38  <sipa>  we can add support for OP_CHECKSIGADD based scripts to descriptors and signing logic for them
3632021-07-16T19:18:45  <michaelfolkson> Taproot descriptor scripts beyond just Taproot single pubkey spends I mean
3642021-07-16T19:18:47  <sipa> outside of miniscript
3652021-07-16T19:18:57  <sipa> michaelfolkson: again **they are**
3662021-07-16T19:19:00  <sipa> read the spec
3672021-07-16T19:19:21  <michaelfolkson> I'm speaking from Core wallet perspective here
3682021-07-16T19:19:31  <sipa> just only <pubkey> OP_CHECKSIG ones
3692021-07-16T19:19:40  <sipa> we're not restricted to inner key only taproot
3702021-07-16T19:19:56  <michaelfolkson> So I think my statement is correct. Have to be clearer on when taking about the Core wallet and when talking about specs
3712021-07-16T19:19:56  <sipa> you can construct 1-of-n using what is supported today, for example
3722021-07-16T19:20:10  <sipa> i'm only talking about core as well
3732021-07-16T19:21:19  <michaelfolkson> Hmm ok, that is new information to me. I thought it was just 1-of-1 for key path and multiple script paths
3742021-07-16T19:21:28  <michaelfolkson> With 1-of-1 in each leaf
3752021-07-16T19:21:40  <sipa> yes, exactly
3762021-07-16T19:21:44  <sipa> that's 1-of-n
3772021-07-16T19:21:57  <achow101> michaelfolkson: each leaf is "1-of-1", but you can have as many leaves as you want
3782021-07-16T19:22:20  <michaelfolkson> Right, I knew that
3792021-07-16T19:23:01  <michaelfolkson> But not 2-of-3 or m-of-n
3802021-07-16T19:23:07  <michaelfolkson> m>1
3812021-07-16T19:23:18  <meshcollider> No, there's no support for threshold
3822021-07-16T19:23:23  <michaelfolkson> That needs CHECKSIGADD or MuSig
3832021-07-16T19:23:35  <sipa> or FROST, or other native threshold scheme
3842021-07-16T19:23:49  <michaelfolkson> Right
3852021-07-16T19:24:43  <michaelfolkson> But we can do thresholds without Miniscript
3862021-07-16T19:24:50  <michaelfolkson> So that is probably next step
3872021-07-16T19:24:55  <michaelfolkson> (for the wallet)
3882021-07-16T19:25:26  <michaelfolkson> Doing as much as possible without needing generic scripts that would need Miniscript
3892021-07-16T19:25:52  <meshcollider> Why? Why not just focus on getting miniscript in and then go from there?
3902021-07-16T19:26:03  *** AaronvanW <AaronvanW!~AaronvanW@50-207-231-44-static.hfc.comcastbusiness.net> has quit IRC (Remote host closed the connection)
3912021-07-16T19:26:05  *** grettke-away is now known as grettke
3922021-07-16T19:26:12  <achow101> I would actually prefer to add miniscript so that we don't have any incompatibilities and stop special casing things like multisig
3932021-07-16T19:26:21  <meshcollider> Exactly ^
3942021-07-16T19:27:07  <michaelfolkson> meshcollider: I'm just trying to read into sipa comments (or at least what he was thinking on that Miniscript issue)
3952021-07-16T19:27:28  <sipa> it'd be great to just integrate miniscript
3962021-07-16T19:27:28  <michaelfolkson> To add Miniscript that needs updating the C++ implementation for Taproot
3972021-07-16T19:27:40  <sipa> if people would want to work on that :)
3982021-07-16T19:28:20  <michaelfolkson> Are there difficulties ensuring the C++ implementation and the Rust implementation are equivalent?
3992021-07-16T19:28:26  <michaelfolkson> (for Miniscript)
4002021-07-16T19:28:43  <sipa> when we first wrote it, we did comparison testing
4012021-07-16T19:29:19  <sipa> if integrated into bitcoin core, it'd be also easy to e.g. produce test sets using fuzzing, which could be tested in other implementations
4022021-07-16T19:29:23  <sipa> or vice verse
4032021-07-16T19:29:32  <michaelfolkson> "I'd very much want to see it further along in integrating into Bitcoin Core" <- That sounded to me like you'd rather Miniscript was merged into Core before it supported Taproot
4042021-07-16T19:29:39  <sipa> yes
4052021-07-16T19:29:51  <sipa> but no reason why both can't happen if people work on it
4062021-07-16T19:30:17  <michaelfolkson> Do others agree with that viewpoint e.g. achow101 meshcollider? Miniscript into Core first before it is updated to support Taproot?
4072021-07-16T19:30:21  <achow101> It'd probably be easier to implement taproot into the c++ implementation once it in core
4082021-07-16T19:30:25  <gene> having a formal verification of miniscript (far future) would also allow mechanically verifying different implementations
4092021-07-16T19:30:38  <meshcollider> Like sipa said earlier, there's no point working on taproot support for it if it isn't going to get merged anyway, so better to focus on getting it merged first
4102021-07-16T19:30:53  <michaelfolkson> Cool, makes sense
4112021-07-16T19:30:59  <sipa> the miniscript c++ repository is currently somewhat in limbo; it works, but it heavily depends on code copied from bitcoin core
4122021-07-16T19:31:13  <sipa> and testing it is effectively dependent on being able to use bitcoin core's scripting engine
4132021-07-16T19:31:40  <sipa> so it's not very appealing to see them diverge further if more feature are added to miniscript, independently of bitcoin core's script code
4142021-07-16T19:32:04  <michaelfolkson> I see
4152021-07-16T19:32:41  <michaelfolkson> Ok so that should be the focus (if we want the Core wallet to support generic Taproot scripts which would be cool/ideal)
4162021-07-16T19:32:50  <michaelfolkson> *eventually support
4172021-07-16T19:33:17  <michaelfolkson> Ok that's all my questions. Thanks all
4182021-07-16T19:33:32  <meshcollider> Sweet, any other topics?
4192021-07-16T19:34:47  <meshcollider> #endmeeting
4202021-07-16T19:34:47  <core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
4212021-07-16T19:34:47  <core-meetingbot> Meeting ended Fri Jul 16 19:34:47 2021 UTC.
4222021-07-16T19:34:47  <core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-07-16-19.00.moin.txt
4232021-07-16T19:37:15  <meshcollider> sipa: where do we need to start in rebooting the miniscript work?
4242021-07-16T19:38:05  <meshcollider> #16800
4252021-07-16T19:38:08  <gribble> https://github.com/bitcoin/bitcoin/issues/16800 | Basic Miniscript support in output descriptors by sipa · Pull Request #16800 · bitcoin/bitcoin · GitHub
4262021-07-16T19:38:11  <sipa> yeah
4272021-07-16T19:47:31  <jonatack> 2019 o-O
4282021-07-16T19:51:00  *** grettke is now known as grettke-away
4292021-07-16T19:53:11  <michaelfolkson> And #17975 for functional test support
4302021-07-16T19:53:14  <gribble> https://github.com/bitcoin/bitcoin/issues/17975 | TestFramework: Add Python Miniscript Support by jachiang · Pull Request #17975 · bitcoin/bitcoin · GitHub
4312021-07-16T19:59:37  *** grettke-away is now known as grettke
4322021-07-16T20:00:07  *** grettke is now known as grettke-away
4332021-07-16T20:08:11  *** grettke-away is now known as grettke
4342021-07-16T20:21:32  *** Shbkgmbr <Shbkgmbr!~Shbkgmbr@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has joined #bitcoin-core-dev
4352021-07-16T20:23:57  *** Shbkgmbr52 <Shbkgmbr52!~Shbkgmbr@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has joined #bitcoin-core-dev
4362021-07-16T20:24:40  *** Shbkgmbr52 <Shbkgmbr52!~Shbkgmbr@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has quit IRC (Client Quit)
4372021-07-16T20:46:21  *** grettke is now known as grettke-away
4382021-07-16T20:52:04  *** Shbkgmbr <Shbkgmbr!~Shbkgmbr@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has quit IRC (Quit: Client closed)
4392021-07-16T20:58:46  *** Guest9 <Guest9!~Guest9@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has joined #bitcoin-core-dev
4402021-07-16T21:00:38  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
4412021-07-16T21:01:18  *** Guest9010 <Guest9010!~Guest90@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has joined #bitcoin-core-dev
4422021-07-16T21:02:12  *** Guest9010 <Guest9010!~Guest90@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has quit IRC (Client Quit)
4432021-07-16T21:02:44  *** Guest47 <Guest47!~Guest47@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has joined #bitcoin-core-dev
4442021-07-16T21:03:14  *** Guest47 <Guest47!~Guest47@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has quit IRC (Client Quit)
4452021-07-16T21:03:38  *** Guest9010 <Guest9010!~Guest9010@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has joined #bitcoin-core-dev
4462021-07-16T21:04:15  *** Guest9 <Guest9!~Guest9@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has quit IRC (Quit: Client closed)
4472021-07-16T21:04:20  *** Guest9010 <Guest9010!~Guest9010@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023> has quit IRC (Client Quit)
4482021-07-16T21:28:02  <lightlike> jonatack: the problem fixed by #22471 looks to me like it could have led to a crash in normal conditions, it's not fuzzing-related.
4492021-07-16T21:28:04  <gribble> https://github.com/bitcoin/bitcoin/issues/22471 | addrman: reset I2P ports in all "new" buckets by vasild · Pull Request #22471 · bitcoin/bitcoin · GitHub
4502021-07-16T21:55:44  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
4512021-07-16T22:08:46  *** jesseposner <jesseposner!~jesse@2601:647:0:89:bd08:313e:ac9:5189> has joined #bitcoin-core-dev
4522021-07-16T22:33:26  *** lightlike <lightlike!~lightlike@user/lightlike> has quit IRC (Quit: Leaving)
4532021-07-16T22:44:50  *** vysn <vysn!~vysn@user/vysn> has quit IRC (Remote host closed the connection)
4542021-07-16T22:48:38  *** AaronvanW <AaronvanW!~AaronvanW@209.235.170.242> has joined #bitcoin-core-dev
4552021-07-16T23:04:09  <dongcarl> roconnor: Oh, `guix time-machine --commit=abcdef -- build coreutils` means build guix at commit abcdef and run that older guix with the arguments ["build", "coreutils"]
4562021-07-16T23:06:47  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 255 seconds)
4572021-07-16T23:33:38  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
4582021-07-16T23:56:14  *** belcher_ <belcher_!~belcher@user/belcher> has joined #bitcoin-core-dev
4592021-07-16T23:57:13  *** grettke-away is now known as grettke
4602021-07-16T23:58:50  *** gene <gene!~gene@gateway/tor-sasl/gene> has quit IRC (Quit: gene)
4612021-07-16T23:59:36  *** belcher <belcher!~belcher@user/belcher> has quit IRC (Ping timeout: 252 seconds)