--- Log opened Fri May 07 00:00:47 2021
00:05 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
00:06 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
00:12 < hebasto> cirrus fuzzer job timed out recently
00:15 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
00:26 -!- jungly [~jungly@host-79-53-186-48.retail.telecomitalia.it] has joined #bitcoin-core-dev
00:55 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f06bf005df070562e8bb2ef.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:06 < jnewbery> jeremyrubin: I'm not familiar enough with the proposal to have an opinion. As the author, you should use whatever you think is the clearest and most concise name.
01:07 < jnewbery> (as long as it's not SecureTheBag!)
01:15 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
01:16 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
01:17 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-dev
01:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:25 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a0d1d487e93d...a33f360fcdd2
01:25 < bitcoin-git> bitcoin/master 2227fc4 windsok: test: minor fixes & improvements for files linter test
01:25 < bitcoin-git> bitcoin/master a33f360 MarcoFalke: Merge bitcoin/bitcoin#21873: test: minor fixes & improvements for files li...
01:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:26 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21873: test: minor fixes & improvements for files linter test (master...files-lint-fixups) https://github.com/bitcoin/bitcoin/pull/21873
01:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 276 seconds]
01:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:29 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a33f360fcdd2...eb9a1fe03779
01:29 < bitcoin-git> bitcoin/master fa09871 MarcoFalke: refactor: Avoid sign-compare compiler warning in util/asmap
01:29 < bitcoin-git> bitcoin/master eb9a1fe MarcoFalke: Merge bitcoin/bitcoin#21802: refactor: Avoid UB in util/asmap (advance a d...
01:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:29 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21802: refactor: Avoid UB in util/asmap (advance a dereferenceable iterator outside its valid range) (master...2104-asmapRefactor) https://github.com/bitcoin/bitcoin/pull/21802
01:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:39 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
01:47 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
01:56 -!- murch [~murch@gateway/tor-sasl/murch] has quit [Remote host closed the connection]
01:57 -!- murch [~murch@gateway/tor-sasl/murch] has joined #bitcoin-core-dev
02:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:03 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #21874: fuzz: Add WRITE_ALL_FUZZ_TARGETS_AND_ABORT (master...2105-fuzzWRITE_ALL_FUZZ_TARGETS_AND_ABORT) https://github.com/bitcoin/bitcoin/pull/21874
02:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:08 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
02:09 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
02:10 -!- vincenzopalazzo [~vincenzop@host-79-23-113-134.retail.telecomitalia.it] has joined #bitcoin-core-dev
02:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
02:27 -!- mutatrum [~quassel@2001:984:6da9:1:6566:e90a:80eb:155c] has quit [Remote host closed the connection]
02:28 -!- mutatrum [~quassel@2001:984:6da9:1:5be7:1f8e:eb85:2319] has joined #bitcoin-core-dev
02:31 -!- blap [~gk@86.106.143.124] has quit [Ping timeout: 252 seconds]
02:40 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
02:50 -!- xmj1 [~xmj@185.163.110.100] has quit [Remote host closed the connection]
02:53 -!- JonOsterman [~Rheanna@101.91.240.201] has joined #bitcoin-core-dev
02:53 -!- JonOsterman [~Rheanna@101.91.240.201] has left #bitcoin-core-dev []
02:57 -!- awesome_doge [~Thunderbi@2001-b400-e239-8cab-58b2-d5ca-cf98-2f4c.emome-ip6.hinet.net] has joined #bitcoin-core-dev
03:06 -!- iMast777 [~iMast777@185.204.1.185] has joined #bitcoin-core-dev
03:11 -!- awesome_doge [~Thunderbi@2001-b400-e239-8cab-58b2-d5ca-cf98-2f4c.emome-ip6.hinet.net] has quit [Ping timeout: 245 seconds]
03:18 -!- Jalon9Hermann [~Jalon9Her@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:23 -!- murch [~murch@gateway/tor-sasl/murch] has quit [Ping timeout: 240 seconds]
03:28 -!- murch [~murch@gateway/tor-sasl/murch] has joined #bitcoin-core-dev
03:37 -!- Jalon9Hermann [~Jalon9Her@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 246 seconds]
03:59 -!- roconnor [~roconnor@host-45-58-195-183.dyn.295.ca] has quit [Ping timeout: 252 seconds]
04:04 -!- conman [~con@unaffiliated/conman] has joined #bitcoin-core-dev
04:11 -!- roconnor [~roconnor@host-23-91-186-24.dyn.295.ca] has joined #bitcoin-core-dev
04:14 < conman> Hi all, for taproot mining pool support, apart from signalling in the version bits, is there anything new that is needed for constructing blocks once it's activated?
04:17 < michaelfolkson> conman: This is a question for ##taproot-activation. But in answer to your question, no just signaling in version bits. Assuming it successfully activates then Taproot rules are only enforced in November.
04:17 < conman> great thanks, will move to t's and a's
04:21 -!- murch [~murch@gateway/tor-sasl/murch] has quit [Remote host closed the connection]
04:22 -!- murch [~murch@gateway/tor-sasl/murch] has joined #bitcoin-core-dev
04:36 -!- awesome_doge [~Thunderbi@223-136-39-143.emome-ip.hinet.net] has joined #bitcoin-core-dev
04:38 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
04:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:43 < bitcoin-git> [bitcoin] jbampton opened pull request #21875: doc: fix spelling (master...fix-spelling) https://github.com/bitcoin/bitcoin/pull/21875
04:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:53 -!- awesome_doge [~Thunderbi@223-136-39-143.emome-ip.hinet.net] has quit [Read error: Connection reset by peer]
05:43 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:01 < jonatack> hebasto: seeing this too, fuzzer timing out since a day or so
06:05 -!- awesome_doge [~Thunderbi@223-136-39-143.emome-ip.hinet.net] has joined #bitcoin-core-dev
06:11 -!- awesome_doge [~Thunderbi@223-136-39-143.emome-ip.hinet.net] has quit [Read error: Connection reset by peer]
06:19 -!- ishaqm [~ishaqm@79-66-16-18.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
06:34 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
06:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:46 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/eb9a1fe03779...9313c4e6aa4b
06:46 < bitcoin-git> bitcoin/master fa5cb6b MarcoFalke: fuzz: Add WRITE_ALL_FUZZ_TARGETS_AND_ABORT
06:46 < bitcoin-git> bitcoin/master 9313c4e MarcoFalke: Merge bitcoin/bitcoin#21874: fuzz: Add WRITE_ALL_FUZZ_TARGETS_AND_ABORT
06:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:46 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21874: fuzz: Add WRITE_ALL_FUZZ_TARGETS_AND_ABORT (master...2105-fuzzWRITE_ALL_FUZZ_TARGETS_AND_ABORT) https://github.com/bitcoin/bitcoin/pull/21874
06:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:19 -!- infernix [nix@unaffiliated/infernix] has quit [Quit: ZNC - http://znc.sourceforge.net]
07:26 -!- nullptr| [~nullptr|@ip-94-112-13-119.net.upcbroadband.cz] has quit [Quit: ZNC - http://znc.in]
07:36 -!- xpto [599a28fa@a89-154-40-250.cpe.netcabo.pt] has joined #bitcoin-core-dev
07:37 -!- xpto [599a28fa@a89-154-40-250.cpe.netcabo.pt] has quit [Client Quit]
07:49 -!- nullptr| [~nullptr|@ip-94-112-13-119.net.upcbroadband.cz] has joined #bitcoin-core-dev
07:53 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
07:53 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
08:05 -!- infernix [~nix@unaffiliated/infernix] has joined #bitcoin-core-dev
08:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
08:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
08:36 -!- rimuru [bbfccf7f@187.252.207.127] has joined #bitcoin-core-dev
08:38 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f06bf005df070562e8bb2ef.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
08:38 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f17c5008a30c190d4134ffc.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
08:47 -!- proofofkeags [~proofofke@205.209.28.54] has joined #bitcoin-core-dev
08:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
09:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:04 < bitcoin-git> [bitcoin] vasild opened pull request #21878: fubar everything (master...Sock_all_over_the_place) https://github.com/bitcoin/bitcoin/pull/21878
09:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:08 < bitcoin-git> [bitcoin] vasild opened pull request #21879: Wrap accept() and extend usage of Sock (master...SockAccept) https://github.com/bitcoin/bitcoin/pull/21879
09:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:14 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f17c5008a30c190d4134ffc.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
09:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:18 < bitcoin-git> [bitcoin] vasild closed pull request #21700: net: expand Sock and fuzz-test more of CConnman (master...Sock_expand) https://github.com/bitcoin/bitcoin/pull/21700
09:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:21 -!- lightlike [~lightlike@p200300c7ef048200e89c0628485c51ee.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:22 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds]
09:26 < jeremyrubin> conman: I think the question is appropriate here fwiw. if you are running the latest core client your blocks will correctly mine all txns, if you don't upgrade you'll be SPV mining the tip, but you won't select any invalid txns but you won't include taproot spends in mempool
09:28 < gmaxwell> michaelfolkson: please don't direct people to ##taproot-activation for asking technical questions about how bitcoin works.
09:30 < gmaxwell> jeremyrubin: s/don't upgrade/don't upgrade by november/ to be pedantic, though I'm sure conman understands.
09:30 < gmaxwell> conman: yeah, it's not like segwit there is no pool software changes or anything like that.
09:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
09:31 < michaelfolkson> gmaxwell: Ok sorry. Just a habit by now after last 3 months. I won't do so again if people are happy to have Taproot activation related questions here from now on
09:31 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:33 < luke-jr> michaelfolkson: it's not a Taproot activation question
09:33 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
09:35 < michaelfolkson> luke-jr: Fair enough
09:43 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
09:45 -!- proofofkeags_ [~proofofke@205.209.24.233] has joined #bitcoin-core-dev
09:47 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 246 seconds]
09:52 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Remote host closed the connection]
09:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:57 < bitcoin-git> [bitcoin] klementtan opened pull request #21880: wallet: remove GetScriptPubKeyMan spam (master...GetScriptPubKeyMan-spam) https://github.com/bitcoin/bitcoin/pull/21880
09:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
10:12 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
10:14 -!- proofofkeags__ [~proofofke@205.209.28.54] has joined #bitcoin-core-dev
10:14 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
10:16 -!- proofofkeags_ [~proofofke@205.209.24.233] has quit [Ping timeout: 240 seconds]
10:18 -!- Guyver2__ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:21 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
10:26 -!- mekster [~mekster@li1564-239.members.linode.com] has quit [Quit: mekster]
10:27 -!- mekster [~mekster@li1564-239.members.linode.com] has joined #bitcoin-core-dev
10:33 -!- pergaminho [~Cleber@189.26.121.248] has joined #bitcoin-core-dev
10:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
10:45 -!- jungly [~jungly@host-79-53-186-48.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds]
10:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
10:53 -!- theprofessor0x [theprofess@bb121-6-182-56.singnet.com.sg] has joined #bitcoin-core-dev
10:54 -!- ishaqm [~ishaqm@79-66-16-18.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]
11:02 -!- blap [~gk@86.106.143.124] has joined #bitcoin-core-dev
11:04 -!- shlop [~gk@89.45.90.228] has joined #bitcoin-core-dev
11:08 -!- blap [~gk@86.106.143.124] has quit [Ping timeout: 240 seconds]
11:27 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has joined #bitcoin-core-dev
11:31 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-xuzoksuofurgtuuc] has quit [Ping timeout: 250 seconds]
11:32 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-qoehqptgekxbzzbo] has quit [Ping timeout: 250 seconds]
11:32 -!- wangchun [sid444603@gateway/web/irccloud.com/x-cvwwzexsldrfutra] has quit [Ping timeout: 250 seconds]
11:33 -!- felixweis [sid154231@gateway/web/irccloud.com/x-hhmrsbbnugoluvvj] has quit [Read error: Connection reset by peer]
11:34 -!- jungly [~jungly@host-79-53-186-48.retail.telecomitalia.it] has joined #bitcoin-core-dev
11:35 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-ypkxcxdtjhxqtqvp] has joined #bitcoin-core-dev
11:35 -!- wangchun [sid444603@gateway/web/irccloud.com/x-fhenbxnmcrfuvfxr] has joined #bitcoin-core-dev
11:35 -!- felixweis [sid154231@gateway/web/irccloud.com/x-ovlrtoqddraoappj] has joined #bitcoin-core-dev
11:35 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-tvrtepyvckaueaun] has joined #bitcoin-core-dev
11:41 -!- proofofkeags__ [~proofofke@205.209.28.54] has quit [Ping timeout: 240 seconds]
11:50 -!- theprofessor0x [theprofess@bb121-6-182-56.singnet.com.sg] has quit []
12:00 < achow101> wallet meeting?
12:01 < achow101> #startmeeting
12:01 < core-meetingbot> Meeting started Fri May  7 19:01:56 2021 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
12:01 < core-meetingbot> Available commands: action commands idea info link nick
12:02 < fjahr> hi
12:02 < sipa> hi
12:02 < meshcollider> Hi
12:03 < achow101> #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:03 < achow101> provoostenator ryanofsky sdaftuar sipa vasild wumpus
12:03 < achow101> any topics?
12:03 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Remote host closed the connection]
12:03 < sipa> none from me
12:03 < jonatack> hi
12:03 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
12:03 < meshcollider> Any wallet review begs?
12:04 < achow101> #17331 pls
12:04 < jonatack> yes!
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 · Pull Request #17331 · bitcoin/bitcoin · GitHub
12:04 < meshcollider> Theres a few things in the GUI repo I need to have a look at
12:04 < fjahr> will re-review 17331 this weekend
12:04 < jonatack> #21786 is my second proposal to fix #20534 from last year
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/21786 | wallet: ensure sat/vB feerates are in range (mantissa of 3) by jonatack · Pull Request #21786 · bitcoin/bitcoin · GitHub
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/20534 | sat/b values arent validated to be in-range · Issue #20534 · bitcoin/bitcoin · GitHub
12:05 < jonatack> it's simpler and more complete
12:06 < achow101> cool, I'll add it to my list
12:06 < jonatack> 17331 and follow-up are on my list
12:06 -!- jesseposner [~jesseposn@2601:645:200:162f:bcd4:42d8:7d4a:791f] has joined #bitcoin-core-dev
12:06 < jonatack> the review clubs were very good
12:07 < fjahr> Looking forward to a rebase on #21365 as well :)
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa · Pull Request #21365 · bitcoin/bitcoin · GitHub
12:08 < fjahr> jonatack: will check it out
12:08 < jonatack> fjahr: thanks. it's only a handful of lines and then tests
12:08 < achow101> Is it reasonable to try to get taproot wallets for 22.0?
12:10 < achow101> With feature freeze in June, I'm not sure that we can make it
12:10 < meshcollider> I think so?
12:10 < jonatack> five weeks until June 15 feature freeze
12:11 < meshcollider> Nothing is impossible if enough people are willing to make it happen :) 
12:11 < achow101> oh, it's only #21365, the prereqs were merged
12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa · Pull Request #21365 · bitcoin/bitcoin · GitHub
12:12 < fjahr> I guess if signalling goes well interest will be high enough, if not people will focus on activation discussions :-/
12:12 < fjahr> (by well at least going in the right direction towards lockin within the next 4 weeks)
12:12 < fjahr> *by well I mean
12:13 < achow101> hmm, there's also the question of how does the wallet behave if that is merged before taproot activates?
12:13 < achow101> definitely don't want to be giving out taproot addresses before activation
12:14 < achow101> 22.0 will definitely be released before activation
12:14 < sipa> we can merge taproot wallet support without by default construction such descriptors
12:15 < achow101> but what happens if someone imports a taproot descriptor?
12:15 < sipa> perhaps we additionally want a safeguard that prevents the creation of such addresses in general before activation
12:15 < sipa> but you can't prevent people from importing crazy descriptors in general
12:16 < meshcollider> I mean, it's not like someone can accidentally import a taproot descriptor if they didn't intend to
12:17 < achow101> indeed
12:18 < jonatack> address safeguard sounds good
12:18 < sipa> i'm not sure where such a safeguard should go
12:18 < sipa> prevent importing the descriptor?
12:18 < sipa> that's possible with some adhoc code i guess
12:18 < sipa> or prevent generating addresses with it?
12:19 < sipa> or outlaw the descriptor in general?
12:19 < achow101> I was thinking we should have a warning if someone imports a taproot descriptor
12:19 < luke-jr> maybe tr() shouldn't be valid until activation?
12:19 < achow101> and then something that disallows getting bech32m addresses
12:19 < jonatack> for mainnet
12:19 < sipa> luke-jr: a downside is that a wallet rescanning post activation might consider the descriptor invalid then
12:20 < luke-jr> hmm
12:20 < sipa> well, or a node reindexing, with a loaded wallet
12:20 < sipa> sec, brb
12:20 < luke-jr> I guess logically it should simply not be recognised as the sPK matching
12:20 < achow101> maybe just a scary warning on import then. just tell people what they're doing is not recommended because taproot isn't active
12:20 < luke-jr> since you don't want a wallet rescan to show pre-activation coins either
12:21 -!- lightlike [~lightlike@p200300c7ef048200e89c0628485c51ee.dip0.t-ipconnect.de] has quit [Quit: Leaving]
12:21 < sipa> luke-jr: hmm
12:22 -!- vincenzopalazzo [~vincenzop@host-79-23-113-134.retail.telecomitalia.it] has left #bitcoin-core-dev ["Leaving"]
12:24 < achow101> hmm, if we disallow import until after activation, then none of this would be a problem?
12:25 < achow101> even pre-activation coins are fine post-activation
12:25 < meshcollider> Yeah it seems a catch at import-time would be simplest then
12:25 < sipa> achow101: yeah, that seems reasonable
12:27 < achow101> anything else to discuss?
12:30 < achow101> #endmeeting
12:30 < 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:30 < core-meetingbot> Meeting ended Fri May  7 19:30:00 2021 UTC.  
12:30 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-05-07-19.01.moin.txt
12:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
12:35 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 260 seconds]
12:37 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
12:37 < gmaxwell> achow101: you could also ship with it disabled but have a conf setting to enable it, which can be set by users after activation... and then all the weird issues with rescan/etc. go away.
12:39 -!- Guyver2__ [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 265 seconds]
12:41 -!- proofofkeags__ [~proofofke@205.209.28.54] has joined #bitcoin-core-dev
12:48 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
12:55 < roconnor> achow101: do you wait for 120 blocks after activation? include special min-locktime logic?
12:57 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
12:58 -!- Highway61 [Thunderbir@gateway/vpn/protonvpn/highway61] has joined #bitcoin-core-dev
13:00 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.8.2 - https://znc.in]
13:00 < achow101> gmaxwell: that's one possibility, although I would be concerned about users setting the config option before activation
13:01 < achow101> roconnor: not implemented yet, so up for debate. I imagine it would just run the versionbits checker and see if it returns active
13:03 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-dev
13:03 -!- jungly [~jungly@host-79-53-186-48.retail.telecomitalia.it] has quit [Ping timeout: 268 seconds]
13:04 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
13:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
13:06 -!- Highway61 [Thunderbir@gateway/vpn/protonvpn/highway61] has quit [Quit: Highway61]
13:07 < gmaxwell> achow101: his point was that as soon as it activates its not safe to use due to reorgs.
13:08 < gmaxwell> achow101: any taproot payment should be locktimed the activation height, ideally-- at least until a few blocks after activation.
13:08 < achow101> but as the receiver, you can't make the sender locktime it, so it would be better to just wait
13:09 < gmaxwell> yeah, you shouldn't issue a taproot address until N blocks after activation, with N depending on how much value you're talking about.
13:17 -!- rimuru [bbfccf7f@187.252.207.127] has quit [Quit: Connection closed]
13:18 < jeremyrubin> i have ~generally thought about sender specified locktimes (it's something that CTV does let you do, in a roundabout way) as kind of useful
13:19 < jeremyrubin> E.g., if I set up a will and testament "on your 21st birthday you get X" is desirable.
13:19 -!- jungly [~jungly@host-79-53-186-48.retail.telecomitalia.it] has joined #bitcoin-core-dev
13:24 < roconnor> I'll suggest N = 120 which was the original default coinbase maturity policy.  Seems about as good as any other number.
13:24 < jeremyrubin> source?
13:24 < roconnor> source for what?
13:25 < sipa> i confirm roconnor's claim
13:25 < sipa> but i'm too lazy to go look in the source code now
13:27 < jeremyrubin> I think it's false
13:27 < jeremyrubin> https://github.com/JeremyRubin/satoshis-version/blob/2197a48a1432f567314ce6c6c4be9270518f882e/src/main.cpp#L826
13:27 < roconnor> the consensus rule was 100 blocks, but the policy was 120.
13:27 < jeremyrubin> correct
13:28 < roconnor> https://github.com/JeremyRubin/satoshis-version/blob/2197a48a1432f567314ce6c6c4be9270518f882e/src/main.cpp#L544
13:29 < jeremyrubin> yep but only for policy / wallet display
13:29 < sipa> that's what roconnor said
13:29 < roconnor> That's why I said "default coinbase maturity policy".
13:29 < jeremyrubin> Ah
13:30 < jeremyrubin> I think it was kinda confusing because there is only (afaiu?) a maturity consensus rule these days
13:30 < jeremyrubin> I thought you meant there used to be a diff consensus rule
13:31 < jeremyrubin> apologies
13:31 < roconnor> It seems like a good number in this case in that it is the most conservative historal value used in cases where we are worried about loss of funds due to reorgs.
13:33 < sipa> in reality, the most important part will just be when the wallet starts constructing such addresses by default (or even when it provides a moderately convenient way of choosing to do so), which will likely be 1000s of blocks after activation
13:33 < sipa> we're just talking about a extra anti-footgun measure
13:33 < sipa> here
13:35 < jeremyrubin> also note that it won't accidentally get into a block
13:36 < jeremyrubin> Nor relayed
13:36 < jeremyrubin> (the spends of it, not creation)
13:37 < jeremyrubin> I guess during a reorg that's already an edge case where priors of miner misbehavior are higher
13:38 < jeremyrubin> I think I've seen it proposed by someone that soft forks like taproot be preceded by a period where spending txns are invalid
13:39 < sipa> that has been the case for every softfork as far as i a can remmeber
13:40 < harding> jeremyrubin: I wouldn't be opposed to that, but it seems like overkill when software developers can just not release taproot-address-generating software until taproot is deployed, or they can gate address updates on a config flag or block height or whatever like being proposed here.
13:41 < jeremyrubin> oh yeah i'm not advocating it, just discussing what I've seen discussed
13:41 < jeremyrubin> let them eat cake
13:42 < jeremyrubin> I think where it's relevant is if we were to ever have a softfork where something that could get into the mempool became invalid... but that's a huge mess so I hope not
13:43 < gmaxwell> I don't think there is any advantage to making the spending temporarily invalid over simply enforcing the rule earlier.
13:44 < gmaxwell> not even in the case where a softfork is excluding previously policy-permitted txn.
13:45 < jeremyrubin> exlcuding previously policy permitted stuff feels a lot like stealing money
13:45 < gmaxwell> jeremyrubin: prior softforks have made invalid recently-policy-permitted txn, fwiw.  The DER encoding changes were one such example.
13:45 < gmaxwell> If you speak so generally you'll tend to say stuff thats just wrong.
13:45 < jeremyrubin> gmaxwell: that is a thin line -- those are at least re-encodable right?
13:45 < gmaxwell> There isn't any real basis to make that stement for der encoding changes, for example.
13:46 < gmaxwell> jeremyrubin: in some sense _ever_ softfork breaks your rule, because policy restrictions didn't extend back to day one.
13:46 < gmaxwell> er _every_.
13:46 < jeremyrubin> Hmm actually no they aren't reencodable
13:46 < gmaxwell> And have changed structure a few times.
13:46 < jeremyrubin> gmaxwell: sure, I'll exclude some stone-age stuff
13:46 < gmaxwell> jeremyrubin: yes they are unless you've intentionally done something moronic with OP_SIZE or comparisons. :P
13:46 < jeremyrubin> I think generally we should be very careful with it
13:47 < gmaxwell> Sure. Not news to anyone else.
13:47 < jeremyrubin> Even DER encodings would break e.g. things which are presigneds sitting somewhere with more than 1 hop\
13:47 < gmaxwell> That is why stuff explicit policy carveouts for future use even exist at all.
13:47 < jeremyrubin> because re-encoding would break the 2nd presign 
13:47 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]
13:47 < sipa> at least with segwit versioning, and taproot leaf versioning + op_success, there is generally no need for changing policy before introducing new (script) functionality
13:47 < gmaxwell> jeremyrubin: yes but anyone could break the chain regardless.
13:48 < jeremyrubin> that's a good point, malleability?
13:48 < gmaxwell> jeremyrubin: and malliation attacks on the network used to be a thing that actually happened.
13:49 < gmaxwell> Unclear why they stopped, other than maybe just that they failed to drop the bitcoin price.
13:49 < gmaxwell> (well some stopped because they were performed by non-miners, but some were miner performed)
13:50 < gmaxwell> In any case, indeed, one must be careful when adding new rules.  The specific forwards-compat policy carefouts (like NOPs, segwit versions, OP_SUCCESS) exists to make those as easy and safe as possible.  But sometimes, e.g. in the case of bug fixes, it may not be possible to use those mechenisms.
13:51 < sipa> ah, NOPs too, of course
13:51 -!- pergaminho [~Cleber@189.26.121.248] has quit [Quit: Saindo]
13:51 < gmaxwell> Fortunately "the rule stops people from triggerign a weird bug" itself starts off with relatively low risk.
13:52 < roconnor> Do we relay taproot spends with an annex? ...  I mean other than the fact that we don't relay taproot spends at all?
13:52 < gmaxwell> And setting something policy denyed well in advance makes things safer.
13:52 < sipa> roconnor: no, those are nonstandard
13:52 < jeremyrubin> roconnor: I think it's discouraged policy?
13:52 < roconnor> ok
13:53 < gmaxwell> In general, nothing without consensus meaning should get relayed-- without meaning there is no reason to set it... so the only reason it has for existing is to get assigned consensus meaning in the future. :P
13:54 < gmaxwell> Though some non-standard things are more obviously intended for future compat than others.
13:55 < gmaxwell> If you do something stupid with OP_SUCCESS or future segwit versions, well you get what you deserve for sure.
13:55 < gmaxwell> (or the NOPs)
13:56 < sipa> i think the insight here has been to construct things in a way such that so-far-unspecified features result in being equivalent to OP_TRUE at the consensus level, so that it is unambiguous the feature is useless before that point
13:57 < gmaxwell> yeah thats the OP_SUCCESS insight, particularly the fact that it first scans the script for _ANY_ use of them, so it doesn't matter where you put them.
13:58 < gmaxwell> OP_NOPs have the misfortune that you can stick them someplace in an otherwise working script and kaboom your funds are suddely frozen aftre two years of succesfully using the script.
13:59 < jeremyrubin> is that true for "well behaved" NOP upgrades?
13:59 < gmaxwell> jeremyrubin: I'm glad we've never had to go the route but it would be possible to make consensus rules depend on the nheight of the output.
13:59 < gmaxwell> jeremyrubin: it's not a property of the NOP upgrade, it's a property of the sufficiently advanced idiot using one before it has a consensus meaning.
14:00 < jeremyrubin> Well I just mean if it's OP_IF ... NOP OP_ELSE <sane thing> OP_ENDIF
14:00 < jeremyrubin> sane thing will keep on working
14:00 < jeremyrubin> even if it is NOP and not SUCCESSX
14:00 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Remote host closed the connection]
14:01 < gmaxwell> but then the nop likely served no purpose, since the script sig decided if it ever got executed at all.
14:01 < jeremyrubin> gmaxwell: even that is limited value since things like LN have multiple output hops precommitted
14:01 < gmaxwell> and as I said, that isn't a property of the upgrade-- it's a property of the user.
14:02 < jeremyrubin> well you claimed that it would break an otherwise working script, but it's ultimately policy of discouraging that protects successx and NOP today
14:02 < jeremyrubin> successx is just more agrressive about it?
14:02 < gmaxwell> I claimed what would break an otherwise working script?
14:03 < jeremyrubin> Yes, so the script wouldn't work (via policy / discouraged nops) if it executes..
14:03 < jeremyrubin> Unless it's a "aggressive NOP" that has odd semantics
14:03 -!- iMast777 [~iMast777@185.204.1.185] has quit [Remote host closed the connection]
14:03 < jeremyrubin> (which is what successx is designed to enable?)
14:03 < gmaxwell> I don't agree.
14:04 < jeremyrubin> I just can't think of an example of something that would not be rejected by policy before the SF if it's a typical NOP upgrade
14:04 < jeremyrubin> if it doesn't execute it has no effect
14:04 < jeremyrubin> Counterexample?
14:05 < gmaxwell> I see where your confusion comes from.  There wouldn't be because we intentionally created policy to protect upgrades.  But policy is a rather weak protection some miners bypass it, for example. (f2pool does, or at least has in the past).
14:05 < gmaxwell> OP_SUCCESS is anti-footgun even without policy protecting it.
14:06 -!- jungly [~jungly@host-79-53-186-48.retail.telecomitalia.it] has quit [Ping timeout: 265 seconds]
14:06 < jeremyrubin> Just in terms of what it implies to the user?
14:06 < jeremyrubin> Because f2pool can ignore policy on OPSUCCESSX too
14:07 < jeremyrubin> I don't mean to question that there is a benefit for safety, I just still don't quite see it
14:07 < jeremyrubin> and I'd like to!
14:08 < jeremyrubin> (I do see a benefit for flexibility though of course)
14:08 < gmaxwell> Say litecoin had some  OP_INPUT_WASNT_CREATED_IN_THE_SAME_BLOCK  which it used as OP_NOP3.    Then some exchange was using that on litecoin and starts using it on bitcoin, and f2pool is mining it.  It's harmless-- doesn't do anything.  Over the next year they assign 10,000 BTC to those outputs. 
14:08 < gmaxwell> then Bitcoin deploys a softfork that turns OP_NOP3 into some new relative timelock.  Boom all those outputs become forever unspendable and they lose 10,000 BTC.
14:09 < gmaxwell> Now, contrast this with OP_SUCCESS.  If they accidentally misuse an OP_SUCCESS in this manner, their coin on their first test transaction is just immediately (and probably automatically) stolen.
14:10 < gmaxwell> They'd have no incentive to try to block a OP_NOP3 softfork upgrade because they were depending on the do-nothing behavior.  ... because any use of an undefined OP_SUCCESS just gives away the coins.
14:11 < gmaxwell> The OP_SUCCESS also makes it much easier to analyize if the change is safe, because by definition the old rules just accept anything that has the OP_SUCCESS anywhere in it.
14:11 < jeremyrubin> I kinda see what you're saying, but I'd point out that both success and nop have local policy guarding things... so your own node should help you bounce the txn and so should the network. so it's really the case where you directly connect to those miners who ignore policy
14:11 < jeremyrubin> I now understand what you see, but it seems (to me) a far fetched case that someone would discover a defect this way
14:12 < gmaxwell> What node? Our superior idiot in this example has a team of Ruby experts that coded their own wallet.
14:12 < gmaxwell> If they weren't idiots to begin with they wouldn't have had a non-consensus defined operation in their script at all. :P
14:12 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
14:13 < jeremyrubin> yeah it's just too many hops of idiocy for me to care, but I admire your kind heart
14:13 < gmaxwell> Hm? we've had issues with people inserting meaningless crap in transactions before... part of the origin of policy protection is to protect the ability to use tx fields for upgrades so that broken software doesn't degrade it.
14:16 < sipa> it doesn't even need to be an unintentional thing like altcoin behavior accidentally being used on the wrong chain
14:17 < sipa> e.g. certain data-stuffing-in-transaction methods could also interfere with future upgrades, for example
14:18 < jeremyrubin> yeah; for the subsidy txs stuff I had to check carefully that OP_VER outputs aren't a thing
14:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:20 < bitcoin-git> [bitcoin] hebasto opened pull request #21882: build: Fix undefined reference to __mulodi4 (master...210507-fuzz32) https://github.com/bitcoin/bitcoin/pull/21882
14:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:21 < gmaxwell> there was a time when libbitcoin was spewing uninitilized memory in the nversion field of transactions.
14:21 < conman> gmaxwell: thanks, went to bed so couldn't respond immediately, but appreciate your response
14:21 -!- duringo [c11b0cfd@193.27.12.253] has joined #bitcoin-core-dev
14:21 < gmaxwell> conman: No problem!
14:22 < conman> can I ask about coinbaseaux whilst I'm at it? Nothing seems to actually be coming from there any more
14:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:23 < conman> are there any plans for any scriptsig strings to come from there or can I assume it will be blank with the current bitcoin core?
14:24 < luke-jr> welcome to 2012 https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki
14:24 < phantomcircuit> conman, i don't think coinbaseaux has been used in ages
14:25 < phantomcircuit> that was the very old way of signaling for a soft fork
14:25 < gmaxwell> conman: I *think* using tags in coinbaseaux isn't likely to be used in the future because there have been mining devices that are fairly particular about the structure of the coinbase scriptsig, unfortunately. (e.g. expect to be able to fuzz specific byte offsets via an fpga/asic).
14:26 < gmaxwell> If it were used again there would probably be some huge circus of figuring out which devices/firmware it's incompatible with. :(
14:26 < gmaxwell> (/pool software, but at least that is fixable)
14:29 < conman> I understand it's not been used, but it's still there and in the documentation as a requirement
14:29 < conman> but thanks, what I needed was whether it would ever be used again
14:30 < sipa> conman: i think it's there because of the protocol having been envisioned to be used for pool-hasher communication too
14:30 < conman> nod
14:30 < luke-jr> it's documented as NOT required..
14:31 < sipa> luke-jr: well, yes, but if it's present, it has to be obeyed?
14:31 < sipa> i guess it says "SHOULD"
14:31 < luke-jr> sipa: right
14:31 < conman> oh is he talking? sorry he's been on ignore for a decade
14:31 < sipa> anyway, i agree it's unlikely that bitcoin core would ever be in a position where it needs to set that field
14:31 < conman> perhaps it's time to unignore him
14:31 < conman> sipa: thanks
14:32 < phantomcircuit> sipa, as gmaxwell said i don't even think it can be set without significant chaos
14:32 < gmaxwell> conman: unfortunately bitcoin exposes far too much consensus innards to edge devices, it's a big problem... because it creates interactions with edge devices that ought not exist.
14:32 < sipa> phantomcircuit: agree
14:33 < conman> gmaxwell: gotcha
14:33 < luke-jr> conman: I was just pointing out it's been documented explicitly as *not* required since 2012 https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki
14:33 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
14:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:35 < bitcoin-git> [bitcoin] jaanauati opened pull request #21883: doc: remove 'experimental' word. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21883
14:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:38 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Ping timeout: 246 seconds]
15:04 < gmaxwell> heh. the see other PRs linked in the reply to that actually form a loop.
15:07 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]
15:16 -!- tummy [~tummy@185.204.1.185] has joined #bitcoin-core-dev
15:19 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 260 seconds]
15:20 -!- shlop [~gk@89.45.90.228] has quit [Quit: Leaving]
15:25 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
15:31 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 240 seconds]
15:32 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #bitcoin-core-dev
15:36 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
15:41 -!- roconnor [~roconnor@host-23-91-186-24.dyn.295.ca] has quit [Ping timeout: 268 seconds]
15:45 -!- doubleqp` [~doubleqp@188.166.79.22] has quit [Quit: bye bye]
15:45 -!- roconnor [~roconnor@host-23-91-186-24.dyn.295.ca] has joined #bitcoin-core-dev
15:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
16:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
16:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
16:08 -!- doubleqp [~doubleqp@unaffiliated/doubleqp] has joined #bitcoin-core-dev
16:22 -!- proofofkeags__ [~proofofke@205.209.28.54] has quit [Ping timeout: 252 seconds]
16:25 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 260 seconds]
16:28 -!- doubleqp [~doubleqp@unaffiliated/doubleqp] has quit [Quit: The Lounge - https://thelounge.chat]
16:28 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-dev
16:30 -!- doubleqp [~doubleqp@unaffiliated/doubleqp] has joined #bitcoin-core-dev
16:32 -!- doubleqp [~doubleqp@unaffiliated/doubleqp] has quit [Client Quit]
16:33 -!- doubleqp [~doubleqp@unaffiliated/doubleqp] has joined #bitcoin-core-dev
16:40 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
16:40 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:45 < bitcoin-git> [bitcoin] fanquake closed pull request #21883: doc: remove 'experimental' word. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21883
16:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:53 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Quit: Dump stack frame]
17:40 -!- pleromauser098 [pleromause@163.237.247.127] has joined #bitcoin-core-dev
17:41 -!- pleromauser098 [pleromause@163.237.247.127] has quit [Client Quit]
17:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
18:03 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev
18:05 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
18:06 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 260 seconds]
18:23 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
18:24 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
18:35 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has quit [Remote host closed the connection]
18:36 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has joined #bitcoin-core-dev
18:39 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
18:40 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has quit [Ping timeout: 268 seconds]
18:43 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
18:53 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has joined #bitcoin-core-dev
18:56 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-dev
19:06 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Quit: Dump stack frame]
19:13 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has quit [Ping timeout: 268 seconds]
19:17 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-fgtmrzupemmyxmhg] has quit [Ping timeout: 240 seconds]
19:23 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-bpuaepzwpugmdgnj] has joined #bitcoin-core-dev
19:36 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has joined #bitcoin-core-dev
19:41 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has quit [Ping timeout: 240 seconds]
19:44 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
19:55 -!- mekster [~mekster@li1564-239.members.linode.com] has quit [Remote host closed the connection]
19:56 -!- mekster [~mekster@li1564-239.members.linode.com] has joined #bitcoin-core-dev
19:56 -!- mekster [~mekster@li1564-239.members.linode.com] has quit [Remote host closed the connection]
19:56 -!- mekster [~mekster@li1564-239.members.linode.com] has joined #bitcoin-core-dev
19:56 -!- mekster [~mekster@li1564-239.members.linode.com] has quit [Remote host closed the connection]
19:56 -!- mekster [~mekster@li1564-239.members.linode.com] has joined #bitcoin-core-dev
19:56 -!- mekster [~mekster@li1564-239.members.linode.com] has quit [Remote host closed the connection]
19:57 -!- mekster [~mekster@li1564-239.members.linode.com] has joined #bitcoin-core-dev
19:57 -!- mekster [~mekster@li1564-239.members.linode.com] has quit [Remote host closed the connection]
20:11 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has joined #bitcoin-core-dev
20:11 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: Hmmm]
20:15 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has quit [Ping timeout: 246 seconds]
20:38 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
20:40 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
20:42 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Remote host closed the connection]
20:42 -!- p0x [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
20:42 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
20:45 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
20:54 -!- runfox [~runfoxrun@200.116.199.26] has joined #bitcoin-core-dev
20:55 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
20:56 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has joined #bitcoin-core-dev
20:59 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
21:00 -!- p0x [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
21:01 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has quit [Ping timeout: 240 seconds]
21:03 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
21:06 -!- someone235 [uid419897@gateway/web/irccloud.com/x-bgitevzzhinusaur] has quit [Quit: Connection closed for inactivity]
21:13 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
21:14 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
21:17 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Remote host closed the connection]
21:37 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
21:39 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
21:43 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has joined #bitcoin-core-dev
21:48 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has quit [Ping timeout: 252 seconds]
22:16 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
22:17 -!- tummy [~tummy@185.204.1.185] has quit [Remote host closed the connection]
22:19 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
22:30 -!- jungly [~jungly@host-212-171-254-246.pool212171.interbusiness.it] has joined #bitcoin-core-dev
22:36 -!- bandnyquist [~Rheanna@101.91.209.187] has joined #bitcoin-core-dev
22:55 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
22:58 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
22:59 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
23:01 -!- runfox [~runfoxrun@200.116.199.26] has quit [Remote host closed the connection]
23:15 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Quit: Lost terminal]
23:20 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
23:20 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has joined #bitcoin-core-dev
23:21 -!- jungly [~jungly@host-212-171-254-246.pool212171.interbusiness.it] has quit [Ping timeout: 260 seconds]
23:22 -!- jungly [~jungly@host-212-171-254-246.pool212171.interbusiness.it] has joined #bitcoin-core-dev
23:24 -!- hsjoberg [~hsjoberg@c-4dc672d5.445-1-64736c11.bbcust.telenor.se] has quit [Ping timeout: 246 seconds]
23:25 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
23:27 -!- jungly [~jungly@host-212-171-254-246.pool212171.interbusiness.it] has quit [Ping timeout: 252 seconds]
23:27 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
23:29 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
23:53 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 240 seconds]
--- Log closed Sat May 08 00:00:48 2021