--- Log opened Fri Jul 16 00:00:07 2021
00:04 < 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
00:08 -!- hex17or_ [~hex17or@gateway/tor-sasl/hex17or] has quit [Ping timeout: 244 seconds]
00:09 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-dev
00:11 -!- kiran [~quassel@43.225.167.10] has joined #bitcoin-core-dev
00:13 -!- babasancheti [~babasanch@43.249.232.35] has quit [Quit: Client closed]
00:22 -!- grettke-away is now known as grettke
00:23 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
00:24 -!- earnestly [~earnest@user/earnestly] has joined #bitcoin-core-dev
00:43 < vasild> MarcoFalke: do you think that the fuzzer inputs from #22450 should be collected and added to bitcoin-core/qa-assets ?
00:43 <@gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
00:43 -!- grettke is now known as grettke-away
00:53 -!- user__ [~davterra@143.244.186.214] has joined #bitcoin-core-dev
00:53 -!- davterra [~davterra@143.244.186.214] has quit [Read error: Connection reset by peer]
00:54 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Remote host closed the connection]
00:54 -!- cryptapus [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
01:00 -!- jarthur [~jarthur@2603-8080-1540-002d-b887-749f-7796-49c4.res6.spectrum.com] has quit [Quit: jarthur]
01:07 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
01:08 < 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
01:22 -!- beshology [~beshology@197.54.237.95] has joined #bitcoin-core-dev
01:24 -!- beshology [~beshology@197.54.237.95] has quit [Client Quit]
01:25 -!- Bilnon [~8iIn0n@2a01:4b00:8e07:7900:b6bd:82d9:48d3:acee] has joined #bitcoin-core-dev
01:26 -!- Bilnon [~8iIn0n@2a01:4b00:8e07:7900:b6bd:82d9:48d3:acee] has quit [Client Quit]
01:28 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 255 seconds]
01:32 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #bitcoin-core-dev
01:34 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
01:43 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
01:44 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev
01:48 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Client Quit]
01:48 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev
02:04 -!- kexkey [~kexkey@static-198-54-132-103.cust.tzulo.com] has quit [Ping timeout: 268 seconds]
02:05 -!- kexkey [~kexkey@static-198-54-132-87.cust.tzulo.com] has joined #bitcoin-core-dev
02:23 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
02:26 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-dev
02: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()
02:32 < 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)
02:33 < vasild> hmm, and because some peers will keep advertising themselves with port 8333, we will keep removing them
02:34 < vasild> jnewbery: actually removing from addrman was tricky, IIRC, there is no Delete() method
02:35 < vasild> if we are to remove them, we may as well re-add with port 0, like you suggested
02:35 < jnewbery> doesn't RemoveInvalid() delete entries?
02:37 < vasild> yes, and it does the same as ResetI2PPorts() - fiddle with addrman internals
02:37 < 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.
02:38 < vasild> that's true
02:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:38 < bitcoin-git> [bitcoin] jnewbery closed pull request #18685: consensus: Simplify ConnectTrace (master...2020-04-connecttrace-simplify) https://github.com/bitcoin/bitcoin/pull/18685
02:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:39 < jonatack> (I ran it cumulatively for a couple of weeks that way.)
02:39 < jonatack> With a bunch of restarts and other tests.
02:40 < vasild> Notice that the problem reported in #22450 OP/description is not related to RemoveInvalid() or ResetI2PPorts() (IMO, jnewbery may disagree)
02:40 <@gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
02:40 < 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
02:41 < jnewbery> vasild: do you disagree that https://github.com/bitcoin/bitcoin/issues/22450#issuecomment-880602891 can cause corruption?
02:44 < 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"
03:00 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 268 seconds]
03:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:40 < 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
03:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:05 < MarcoFalke> > [09:43] <vasild> MarcoFalke: do you think that the fuzzer inputs from #22450 should be collected and added to bitcoin-core/qa-assets ?
04:05 <@gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
04:05 < MarcoFalke> Yes, but only after the bugfixes are in. Otherwise we have red CI
04:10 -!- {[o]} [~quassel@174-29-204-46.hlrn.qwest.net] has quit [Ping timeout: 272 seconds]
04:35 < vasild> right
04:53 -!- roconnor [~roconnor@host-45-58-195-5.dyn.295.ca] has joined #bitcoin-core-dev
04:58 < vasild> jnewbery: I said "there is no Delete() method", actually there is, but it only deletes entries from "new" which have 0 references.
05:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:08 < 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
05:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:21 < 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?
05:31 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
05:36 < vasild> jnewbery: I can't be sure there aren't more bugs. But that is also true for any software.
05:37 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
05:39 < 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
05:51 < 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.
05:56 < 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
05:57 < vasild> the current one should be called something like DeleteNewWithRef0OrIWillAssert()
06:10 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:10 -!- mekster6 [~mekster@user/mekster] has joined #bitcoin-core-dev
06:10 -!- darosior0 [~darosior@194.36.189.246] has joined #bitcoin-core-dev
06:11 -!- kexkey_ [~kexkey@static-198-54-132-87.cust.tzulo.com] has joined #bitcoin-core-dev
06:11 -!- dr_orlovsky [~dr-orlovs@31.14.40.19] has joined #bitcoin-core-dev
06:11 -!- GIANTWORLDKEEPR_ [~pjetcetal@128-71-13-182.broadband.corbina.ru] has joined #bitcoin-core-dev
06:12 -!- jnewbery_ [~john@user/jnewbery] has joined #bitcoin-core-dev
06:12 -!- roconnor [~roconnor@host-45-58-195-5.dyn.295.ca] has quit [Ping timeout: 268 seconds]
06:13 -!- andytosh1 [~apoelstra@s66-183-0-205.bc.hsia.telus.net] has joined #bitcoin-core-dev
06:13 < 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
06:14 -!- gwillen1 [gwillen@user/gwillen] has joined #bitcoin-core-dev
06:14 -!- pigeons_ [~pigeons@androzani.sysevolve.com] has joined #bitcoin-core-dev
06:14 -!- sipa_ [~pw@user/sipa] has joined #bitcoin-core-dev
06:18 -!- Netsplit *.net <-> *.split quits: cmirror, Guyver2, kexkey, andytoshi, hardtotell, sipa, jnewbery, instagibbs, dr-orlovsky, mekster,  (+7 more, use /NETSPLIT to show all of them)
06:18 -!- mekster6 is now known as mekster
06:18 -!- darosior0 is now known as darosior
06:18 -!- Guyver2_ is now known as Guyver2
06:19 -!- Netsplit over, joins: hardtotell
06:19 < 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.
06:19 <@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
06:20 -!- nathanael [~nathanael@user/nathanael] has joined #bitcoin-core-dev
06:20 -!- elichai2 [sid212594@id-212594.stonehaven.irccloud.com] has joined #bitcoin-core-dev
06:24 -!- instagibbs [~instagibb@119247204116.ctinets.com] has joined #bitcoin-core-dev
06:46 -!- jespada [~jespada@90.254.247.46] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
06:46 -!- jespada [~jespada@90.254.247.46] has joined #bitcoin-core-dev
06:50 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
06:51 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:59 -!- grettke-away is now known as grettke
06:59 -!- AaronvanW [~AaronvanW@209.235.170.242] has joined #bitcoin-core-dev
07:23 -!- kiran [~quassel@43.225.167.10] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
07:30 -!- babasancheti [~babasanch@43.249.232.35] has joined #bitcoin-core-dev
07:38 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-dev
07:45 < vasild> jonatack: thanks!
07:54 -!- AaronvanW [~AaronvanW@209.235.170.242] has quit [Quit: Leaving...]
08:35 < 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?
08:35 <@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
08:38 < 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 
08:39 < 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)
08:40 < vasild> the only solution (I see) would be for everybody to re-generate a new i2p address
08:43 < sipa_> vasild: but i2p support is only on master, right?
08:44 < vasild> It _should_ be possible to properly change the ports from 8333 to 0 in addrman.
08:44 < 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
08:44 < sipa_> sure, but it's just people running master
08:45 < vasild> correct
08:45 < sipa_> we can include a snippet in the release notes
08:45 -!- sipa_ is now known as sipa
08:45 < 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
08:47 < vasild> sipa: you mean that there are already bugs in that code or that some nodes already run with inconsistent addrmans?
08:48 < sipa> i'm wary about touching addrman more, as it has already been shown it's easy to corrupt
08:49 < sipa> though i'll have a deeper look at the issue and the proposed fixes too
08:51 < vasild> there are 3 issues reported in #22450 (sorry, that's messy): 1. the description/OP, fixed in #22455 (not relevant to I2P)
08:51 <@gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
08:51 <@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
08:52 < vasild> 2. https://github.com/bitcoin/bitcoin/issues/22450#issuecomment-880629375 which I also reported separately in #22467, fixed in #22468
08:52 <@gribble> https://github.com/bitcoin/bitcoin/issues/22467 | Assertion `nRndPos1 < vRandom.size() && nRndPos2 < vRandom.size() failed · Issue #22467 · bitcoin/bitcoin · GitHub
08:52 <@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
08:53 < 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
08:54 -!- vysn [~vysn@user/vysn] has joined #bitcoin-core-dev
08:59 < 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.
09:01 < vasild> => I think there is a good chance fuzzing addrman unserialize will find more bugs
09:04 < sipa> definitely
09:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:29 < 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
09:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:30 < 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
09:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:31 < vasild> Reported 3. separately as #22470 with a fix in #22471
09:31 <@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
09:31 <@gribble> https://github.com/bitcoin/bitcoin/issues/22471 | addrman: reset I2P ports in all "new" buckets by vasild · Pull Request #22471 · bitcoin/bitcoin · GitHub
09:48 < 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?
09:48 <@gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub
09:48 -!- jnewbery_ is now known as jnewbery
09:52 < 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().
09:52 <@gribble> https://github.com/bitcoin/bitcoin/issues/22467 | Assertion `nRndPos1 < vRandom.size() && nRndPos2 < vRandom.size() failed · Issue #22467 · bitcoin/bitcoin · GitHub
09:52 <@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
09:54 < 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
09:56 < vasild> But I will look into that anyway, it is good to compare different solutions and pick the "better" one
09:57 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
09:58 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev
10:11 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 246 seconds]
10:15 -!- jarthur [~jarthur@2603-8080-1540-002d-f52d-d440-e265-bac9.res6.spectrum.com] has joined #bitcoin-core-dev
10:17 -!- murch [~murch@user/murch] has quit [Quit: WeeChat 1.9.1]
10:27 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:29 -!- lightlike [~lightlike@user/lightlike] has quit [Quit: Leaving]
10:30 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 258 seconds]
10:30 -!- ufotofu [~ufotofu@user/ufotofu] has quit [Ping timeout: 258 seconds]
10:30 -!- Guyver2_ is now known as Guyver2
10:31 -!- ufotofu_ [~ufotofu@user/ufotofu] has joined #bitcoin-core-dev
10:48 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
10:49 -!- AaronvanW [~AaronvanW@50-207-231-44-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
11:02 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-dev
11:16 < BlueMatt> :q
11:16 < sipa> :q!
11:17 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
11:19 -!- babasancheti [~babasanch@43.249.232.35] has quit [Quit: Client closed]
11:21 -!- grettke is now known as grettke-away
11:22 < 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.
11:23 < dongcarl> Here’s live-bootstrap: https://github.com/fosslinux/live-bootstrap
11:24 < dongcarl> We shall see if it can link up and be used to further minimize the bootstrap chain
11:33 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 255 seconds]
11:39 -!- roconnor [~roconnor@host-45-58-227-60.dyn.295.ca] has joined #bitcoin-core-dev
11:39 -!- jesseposner [~jesse@c-24-4-88-184.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]
11:39 < roconnor> dongcarl: what is guix time-machine?  The man page is useless in typical GNU fashion.
11:41 -!- jarthur_ [~jarthur@2603-8080-1540-002d-dcfa-1836-6c8e-0e77.res6.spectrum.com] has joined #bitcoin-core-dev
11:42 -!- jarthur [~jarthur@2603-8080-1540-002d-f52d-d440-e265-bac9.res6.spectrum.com] has quit [Ping timeout: 246 seconds]
11:43 < 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 
11:43 <@gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub
11:44 < vasild> I will add some monitoring to my node to see if I still receive gossip of i2p:8333
11:44 < sipa> vasild: that would be useful to know
11:46  * vasild zZzZ...
11:49 -!- gene [~gene@gateway/tor-sasl/gene] has joined #bitcoin-core-dev
12:00 < meshcollider> Anyone around for a wallet meeting?
12:00 < achow101> me
12:00 < michaelfolkson> Me too
12:00 < gene> hi
12:00 < meshcollider> #startmeeting
12:00 < 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.
12:00 < core-meetingbot> Available commands: action commands idea info link nick
12:01 < 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 
12:01 < meshcollider> provoostenator ryanofsky sdaftuar sipa vasild wumpus
12:01 < meshcollider> Topics?
12:01 < 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.  
12:01 < fjahr> hi
12:01 < achow101> hi
12:01 < jonatack> hi :)
12:01 < michaelfolkson> hi
12:02 < michaelfolkson> I have some general Taproot roadmap questions if there's nothing on the agenda
12:02 < kvaciral[m]> hi
12:02 < meshcollider> No more urgent wallet things found that need to go into 0.22 right?
12:02 < meshcollider> 22*
12:02 < kanzure> hi
12:02 < achow101> #22461 is the only wallet pr marked for 22.0
12:03 <@gribble> https://github.com/bitcoin/bitcoin/issues/22461 | wallet: Change ScriptPubKeyMan::Upgrade default to True by achow101 · Pull Request #22461 · bitcoin/bitcoin · GitHub
12:03 < sipa> hi
12:04 < meshcollider> #topic general taproot roadmap questions (michaelfolkson)
12:04 < core-meetingbot> topic: general taproot roadmap questions (michaelfolkson)
12:05 < michaelfolkson> So perhaps starting with PSBT (and apologies if my understanding of PSBT has holes)
12:06 < achow101> There are proposed taproot fields for psbt PR'd to the bips repo: https://github.com/bitcoin/bips/pull/1139
12:06 < michaelfolkson> PSBT won't be supporting with MuSig. But to support Taproot multisig (CHECKSIGADD not MuSig) does this get included in PSBT spec?
12:06 < achow101> anything script based is supported by psbt
12:07 < sipa> PSBT doesn't need support for individual script types; that's up to individual singer implementations
12:07 < sipa> taproot support in general needs extensions (already proposed), and MuSig will need its own ones
12:07 < sipa> but scripts don't need anything
12:07 < sipa> *signer, not singer
12:08 < 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
12:08 < achow101> the psbt fields have fields for the leaft scripts
12:08 < sipa> as i said, that's up to the individual signer
12:08 < achow101> leaf scripts can be anything
12:08 < sipa> clearly you can't expect every signer to support every script
12:08 < achow101> it's up to the implementations to figure out what those scripts are doing, and what to do with them
12:08 < michaelfolkson> Ok I think I understand, thanks
12:09 < michaelfolkson> The PSBT part isn't doing much
12:09 < sipa> it's just an interchange format
12:09 < gene> do PSBT implementations need to validate scripts?
12:09 < sipa> and the Bitcoin Core wallet does support taproot scripts by the way, just only very limited ones (effectively just "<pubkey> OP_CHECKSIG")
12:10 < achow101> gene: PSBT implementation don't have to do anything with scripts. whether they should or should not depends on their role
12:10 < sipa> signers may want to check any number of properties of what they're signing before deciding that signing is right
12:10 < sipa> but what that is, is up to them
12:11 < sipa> PSBT just makes sure that data can be made available to them
12:11 < 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?
12:11 < achow101> gene: yes, although both sides would be PSBT implementations, just different roles
12:12 < gene> +1
12:12 < sipa> it's a bit ambiguous what you call "PSBT impl"
12:12 < sipa> if you're just referring to the serializer/deserializer, yes, definitely
12:12 < 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
12:12 < gene> yeah, the software/firmware that handles PSBT serialization
12:13 < gene> ok, that makes sense
12: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
12:13 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
12:13 < michaelfolkson> Ok I will reread PSBT BIP with that understanding. That helps, thanks
12:13 < achow101> in terms of Core supporting more complicated taproot scripts, I think that will depend on miniscript (and more generally, descriptors)
12:14 < michaelfolkson> Right, and I read this from sipa which was very informative too https://github.com/sipa/miniscript/issues/56#issuecomment-876603384
12:15 < michaelfolkson> I was surprised that he thinks it is likely Miniscript gets merged into Core without supporting Taproot but I (kinda) understand the argument
12:16 < sipa> the goal is obviously to extend it at some point to support taproot
12:16 < sipa> but i don't think it's worth doing more spec work if the implementation isn't making progress
12:16 < michaelfolkson> To summarize the Taproot Miniscript syntax is easy to design but this will likely be supported by rust-miniscript before the C++ implementation
12:16 < sipa> it depends what people work on
12:17 < 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
12:17 < michaelfolkson> "implementation isn't making progress" <- you mean the C++ implementation of Miniscript here right?
12:17 < sipa> yes
12:17 < michaelfolkson> But there is this stepping stone between just supporting single key Taproot spends and Miniscript generic scripts
12:17 < meshcollider> I think we should definitely prioritise it after 22 is done
12:18 < michaelfolkson> Descriptor scripts could be supported without Miniscript
12:18 < sipa> they are
12:18 < sipa> they're just very minimal right now
12:18 < sipa>  we can add support for OP_CHECKSIGADD based scripts to descriptors and signing logic for them
12:18 < michaelfolkson> Taproot descriptor scripts beyond just Taproot single pubkey spends I mean
12:18 < sipa> outside of miniscript
12:18 < sipa> michaelfolkson: again **they are**
12:19 < sipa> read the spec
12:19 < michaelfolkson> I'm speaking from Core wallet perspective here
12:19 < sipa> just only <pubkey> OP_CHECKSIG ones
12:19 < sipa> we're not restricted to inner key only taproot
12:19 < michaelfolkson> So I think my statement is correct. Have to be clearer on when taking about the Core wallet and when talking about specs
12:19 < sipa> you can construct 1-of-n using what is supported today, for example
12:20 < sipa> i'm only talking about core as well
12:21 < michaelfolkson> Hmm ok, that is new information to me. I thought it was just 1-of-1 for key path and multiple script paths
12:21 < michaelfolkson> With 1-of-1 in each leaf
12:21 < sipa> yes, exactly
12:21 < sipa> that's 1-of-n
12:21 < achow101> michaelfolkson: each leaf is "1-of-1", but you can have as many leaves as you want
12:22 < michaelfolkson> Right, I knew that
12:23 < michaelfolkson> But not 2-of-3 or m-of-n
12:23 < michaelfolkson> m>1
12:23 < meshcollider> No, there's no support for threshold 
12:23 < michaelfolkson> That needs CHECKSIGADD or MuSig
12:23 < sipa> or FROST, or other native threshold scheme
12:23 < michaelfolkson> Right
12:24 < michaelfolkson> But we can do thresholds without Miniscript
12:24 < michaelfolkson> So that is probably next step
12:24 < michaelfolkson> (for the wallet)
12:25 < michaelfolkson> Doing as much as possible without needing generic scripts that would need Miniscript
12:25 < meshcollider> Why? Why not just focus on getting miniscript in and then go from there?
12:26 -!- AaronvanW [~AaronvanW@50-207-231-44-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
12:26 -!- grettke-away is now known as grettke
12:26 < achow101> I would actually prefer to add miniscript so that we don't have any incompatibilities and stop special casing things like multisig
12:26 < meshcollider> Exactly ^
12:27 < michaelfolkson> meshcollider: I'm just trying to read into sipa comments (or at least what he was thinking on that Miniscript issue)
12:27 < sipa> it'd be great to just integrate miniscript
12:27 < michaelfolkson> To add Miniscript that needs updating the C++ implementation for Taproot
12:27 < sipa> if people would want to work on that :)
12:28 < michaelfolkson> Are there difficulties ensuring the C++ implementation and the Rust implementation are equivalent?
12:28 < michaelfolkson> (for Miniscript)
12:28 < sipa> when we first wrote it, we did comparison testing
12:29 < 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
12:29 < sipa> or vice verse
12:29 < 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
12:29 < sipa> yes
12:29 < sipa> but no reason why both can't happen if people work on it
12:30 < michaelfolkson> Do others agree with that viewpoint e.g. achow101 meshcollider? Miniscript into Core first before it is updated to support Taproot?
12:30 < achow101> It'd probably be easier to implement taproot into the c++ implementation once it in core
12:30 < gene> having a formal verification of miniscript (far future) would also allow mechanically verifying different implementations
12:30 < 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 
12:30 < michaelfolkson> Cool, makes sense
12:30 < sipa> the miniscript c++ repository is currently somewhat in limbo; it works, but it heavily depends on code copied from bitcoin core
12:31 < sipa> and testing it is effectively dependent on being able to use bitcoin core's scripting engine
12:31 < 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
12:32 < michaelfolkson> I see
12:32 < michaelfolkson> Ok so that should be the focus (if we want the Core wallet to support generic Taproot scripts which would be cool/ideal)
12:32 < michaelfolkson> *eventually support
12:33 < michaelfolkson> Ok that's all my questions. Thanks all
12:33 < meshcollider> Sweet, any other topics?
12:34 < meshcollider> #endmeeting
12:34 < 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
12:34 < core-meetingbot> Meeting ended Fri Jul 16 19:34:47 2021 UTC.  
12:34 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-07-16-19.00.moin.txt
12:37 < meshcollider> sipa: where do we need to start in rebooting the miniscript work?
12:38 < meshcollider> #16800
12:38 <@gribble> https://github.com/bitcoin/bitcoin/issues/16800 | Basic Miniscript support in output descriptors by sipa · Pull Request #16800 · bitcoin/bitcoin · GitHub
12:38 < sipa> yeah
12:47 < jonatack> 2019 o-O
12:50 -!- grettke is now known as grettke-away
12:53 < michaelfolkson> And #17975 for functional test support
12:53 <@gribble> https://github.com/bitcoin/bitcoin/issues/17975 | TestFramework: Add Python Miniscript Support by jachiang · Pull Request #17975 · bitcoin/bitcoin · GitHub
12:59 -!- grettke-away is now known as grettke
13:00 -!- grettke is now known as grettke-away
13:08 -!- grettke-away is now known as grettke
13:21 -!- Shbkgmbr [~Shbkgmbr@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has joined #bitcoin-core-dev
13:23 -!- Shbkgmbr52 [~Shbkgmbr@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has joined #bitcoin-core-dev
13:24 -!- Shbkgmbr52 [~Shbkgmbr@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has quit [Client Quit]
13:46 -!- grettke is now known as grettke-away
13:52 -!- Shbkgmbr [~Shbkgmbr@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has quit [Quit: Client closed]
13:58 -!- Guest9 [~Guest9@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has joined #bitcoin-core-dev
14:00 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
14:01 -!- Guest9010 [~Guest90@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has joined #bitcoin-core-dev
14:02 -!- Guest9010 [~Guest90@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has quit [Client Quit]
14:02 -!- Guest47 [~Guest47@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has joined #bitcoin-core-dev
14:03 -!- Guest47 [~Guest47@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has quit [Client Quit]
14:03 -!- Guest9010 [~Guest9010@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has joined #bitcoin-core-dev
14:04 -!- Guest9 [~Guest9@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has quit [Quit: Client closed]
14:04 -!- Guest9010 [~Guest9010@2401:4900:3106:6c5b:1dfb:b0a1:6cd5:4023] has quit [Client Quit]
14:28 < 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.
14:28 <@gribble> https://github.com/bitcoin/bitcoin/issues/22471 | addrman: reset I2P ports in all "new" buckets by vasild · Pull Request #22471 · bitcoin/bitcoin · GitHub
14:55 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
15:08 -!- jesseposner [~jesse@2601:647:0:89:bd08:313e:ac9:5189] has joined #bitcoin-core-dev
15:33 -!- lightlike [~lightlike@user/lightlike] has quit [Quit: Leaving]
15:44 -!- vysn [~vysn@user/vysn] has quit [Remote host closed the connection]
15:48 -!- AaronvanW [~AaronvanW@209.235.170.242] has joined #bitcoin-core-dev
16:04 < 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"]
16:06 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 255 seconds]
16:33 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
16:56 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-core-dev
16:57 -!- grettke-away is now known as grettke
16:58 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
16:59 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:05 < sipa> fanquake: what aarch64 hardware do you have?
17:05 < fanquake> sipa: Apple M1 mac-mini
17:06 < sipa> oh, and you run a linux env in a VM on that?
17:07 < fanquake> Yea
17:10 < fanquake> I'll probably track down some other hardware too. However this box was sponsored, and is handy to test the M1 cross-compile and aarch64 things.
17:10 < sipa> i'm pretty happy with my Odroid N2+, fwiw
17:12 -!- jarthur_ is now known as jarthur
17:17 < dongcarl> I've heard good things about the HoneyComb LX2 and the Socionext Developerbox... Supposedly Socionext runs very well with vanilla aarch64 debian
17:19 < sipa> being able to run vanilla debian is nice
17:20 < roconnor> dongcarl: that feels ... a bit overkill.
17:21 < roconnor> hopefully the build of Bitcoin is independent of which version of guix you are using?  Or maybe the specific bootstrap data is tied to guix versions, and that is what you are worried about?
17:22 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 255 seconds]
17:33 < dongcarl> roconnor: So Guix's package definitions are in the same tree as itself, so basically you want to pin the version of Guix in order to pin the packages. There is also the "inferiors" feature (https://guix.gnu.org/manual/en/html_node/Inferiors.html), however, that API is subject to change... Just like Guix's command line invocation is subject to
17:33 < dongcarl> change... So I went with the most fail-proof thing: just use `time-machine`
17:47 -!- {[o]} [~quassel@174-29-204-46.hlrn.qwest.net] has joined #bitcoin-core-dev
17:47 -!- earnestly [~earnest@user/earnestly] has quit [Ping timeout: 265 seconds]
17:49 < fanquake> sipa: I might just buy one of those
17:49 < fanquake> Also can you block saadbitcoin
17:55 < sipa> in a few hours; not at conputer right now
17:57 < roconnor> dongcarl: oh so there is no nix / nixpkgs distinction in guix? ... if you are familiar with nix.
18:09 -!- Guest27 [~Guest27@92.223.89.57] has joined #bitcoin-core-dev
18:33 -!- Guest27 [~Guest27@92.223.89.57] has quit [Quit: Client closed]
18:49 -!- grettke is now known as grettke-away
18:49 -!- grettke-away [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:57 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-dev
20:29 -!- grettke is now known as grettke-away
20:45 -!- jarthur [~jarthur@2603-8080-1540-002d-dcfa-1836-6c8e-0e77.res6.spectrum.com] has quit [Ping timeout: 240 seconds]
21:02 < dongcarl> roconnor: Right, it's all one monorepo
21:04 -!- grettke-away is now known as grettke
21:04 < sipa> dongcarl: is that just a temporary measure, so they can easily make tree-wide refactorings while not all of the structure/internal API is stable?
21:04 < sipa> or will that stay?
21:07 < dongcarl> sipa: I honestly don't know much about the particular rationale behind this structuring... I'm guessing it was just convenient and they never found a desperate need to change it (especially not if the inferior interface matures)
21:17 -!- jarthur [~jarthur@2603-8080-1540-002d-35cb-7aa5-ce54-31ee.res6.spectrum.com] has joined #bitcoin-core-dev
21:39 -!- Alexandme [~Alexandme@37.223.87.168] has joined #bitcoin-core-dev
21:51 -!- vysn [~vysn@user/vysn] has joined #bitcoin-core-dev
22:02 -!- grettke is now known as grettke-away
22:09 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Read error: Connection reset by peer]
22:17 -!- Alexandme [~Alexandme@37.223.87.168] has quit [Remote host closed the connection]
22:45 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-dev
22:49 -!- jarthur [~jarthur@2603-8080-1540-002d-35cb-7aa5-ce54-31ee.res6.spectrum.com] has quit [Quit: jarthur]
23:01 -!- grettke-away is now known as grettke
23:52 -!- belcher_ is now known as belcher
23:56 -!- grettke is now known as grettke-away
--- Log closed Sat Jul 17 00:00:08 2021