--- Log opened Thu Feb 06 00:00:31 2020
00:00 -!- r8921039 [~r8921039@2601:644:303:18c0:c590:bc8c:557e:c1bd] has joined #bitcoin-core-dev
00:01 -!- Highway61 [~Thunderbi@104.223.94.122] has joined #bitcoin-core-dev
00:05 -!- r8921039 [~r8921039@2601:644:303:18c0:c590:bc8c:557e:c1bd] has quit [Ping timeout: 272 seconds]
00:05 -!- Highway61 [~Thunderbi@104.223.94.122] has quit [Ping timeout: 260 seconds]
00:07 -!- r8921039 [~r8921039@2601:644:303:18c0:c117:6983:93a0:6fb2] has joined #bitcoin-core-dev
00:10 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
00:12 -!- r8921039 [~r8921039@2601:644:303:18c0:c117:6983:93a0:6fb2] has quit [Ping timeout: 260 seconds]
00:14 -!- michagogo [uid14316@wikia/Michagogo] has quit [Quit: Connection closed for inactivity]
00:40 -!- r8921039 [~r8921039@2601:644:303:18c0:25e8:dde0:9428:b663] has joined #bitcoin-core-dev
00:44 -!- r8921039 [~r8921039@2601:644:303:18c0:25e8:dde0:9428:b663] has quit [Ping timeout: 260 seconds]
00:47 -!- promag [~promag@a89-152-187-241.cpe.netcabo.pt] has joined #bitcoin-core-dev
00:52 -!- promag [~promag@a89-152-187-241.cpe.netcabo.pt] has quit [Ping timeout: 272 seconds]
01:00 -!- Cotillion [~Cotillion@195.206.169.238] has quit []
01:00 -!- r8921039 [~r8921039@2601:644:303:18c0:4c2c:5a05:ca92:b646] has joined #bitcoin-core-dev
01:01 -!- promag [~promag@188.250.106.244] has joined #bitcoin-core-dev
01:01 -!- promag_ [~promag@188.250.106.244] has joined #bitcoin-core-dev
01:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
01:03 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
01:05 -!- r8921039 [~r8921039@2601:644:303:18c0:4c2c:5a05:ca92:b646] has quit [Ping timeout: 272 seconds]
01:12 -!- r8921039 [~r8921039@2601:644:303:18c0:4df:b2b3:6808:19c8] has joined #bitcoin-core-dev
01:16 -!- r8921039 [~r8921039@2601:644:303:18c0:4df:b2b3:6808:19c8] has quit [Ping timeout: 260 seconds]
01:18 -!- shaunm [~shaunm@141.98.101.133] has joined #bitcoin-core-dev
01:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:18 < bitcoin-git> [bitcoin] promag opened pull request #18084: 0.19: gui: Fix unintialized WalletView::progressDialog (0.19...2020-02-backport-18062) https://github.com/bitcoin/bitcoin/pull/18084
01:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:30 -!- r8921039 [~r8921039@2601:644:303:18c0:7d58:575d:a02d:3435] has joined #bitcoin-core-dev
01:35 -!- r8921039 [~r8921039@2601:644:303:18c0:7d58:575d:a02d:3435] has quit [Ping timeout: 272 seconds]
01:38 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:25 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
02:27 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]
02:30 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
02:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:34 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:34 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
02:38 < jonasschnelli> goatpig: see DUST_RELAY_TX_FEE
02:38 < jonasschnelli> and -dustrelayfee= config value
02:38 < jonasschnelli> it's default is currently 3000sats in master AFAIK
02:39 < jonasschnelli> 3000sats/kB to be more precise
02:41 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]
02:43 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev
02:46 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]
02:48 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev
03:00 -!- promag_ [~promag@188.250.106.244] has quit [Remote host closed the connection]
03:00 -!- promag_ [~promag@188.250.106.244] has joined #bitcoin-core-dev
03:03 -!- Cleora81Stehr [~Cleora81S@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev
03:16 -!- Cleora81Stehr [~Cleora81S@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 268 seconds]
03:25 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
03:31 < wumpus> promag: I'm not aware of any plans to bump the minimum qt version again, if you want to propose that feel free to open a PR, make sure you check for various linux distributions, I don't think 5.10+ is realistic as ubuntu bionic (18.04) still has 5.9 and no doubt others
03:35 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]
03:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 252 seconds]
03:53 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
03:55 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-dev
04:00 -!- shaunm [~shaunm@141.98.101.133] has quit []
04:00 -!- Liliaceae [sid282374@gateway/web/irccloud.com/x-eappcemlffrewhfe] has quit [Quit: Connection closed for inactivity]
04:08 -!- Highway61 [~Thunderbi@104.223.94.122] has joined #bitcoin-core-dev
04:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:11 < bitcoin-git> [bitcoin] laanwj closed pull request #17807: net: Remove unnecessary portability typedef (master...akh_socket_arg_type) https://github.com/bitcoin/bitcoin/pull/17807
04:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:13 -!- Highway61 [~Thunderbi@104.223.94.122] has quit [Ping timeout: 272 seconds]
04:16 -!- ccdle12 [~ccdle12@188.29.165.77.threembb.co.uk] has joined #bitcoin-core-dev
04:18 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
04:19 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
04:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:20 < bitcoin-git> [bitcoin] laanwj reopened pull request #16995: Fix gcc 9 warnings (master...2019_09_resolve_gcc_warnings) https://github.com/bitcoin/bitcoin/pull/16995
04:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:28 -!- sipsorcery [~sipsorcer@37.228.255.208] has quit [Remote host closed the connection]
04:28 -!- sipsorcery [~sipsorcer@37.228.255.208] has joined #bitcoin-core-dev
04:30 -!- Highway61 [~Thunderbi@104.223.94.122] has joined #bitcoin-core-dev
04:31 -!- r8921039 [~r8921039@2601:644:303:18c0:4c8e:c3f0:200a:98af] has joined #bitcoin-core-dev
04:32 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #bitcoin-core-dev
04:32 -!- r8921039 [~r8921039@2601:644:303:18c0:4c8e:c3f0:200a:98af] has quit [Client Quit]
04:34 -!- Highway61 [~Thunderbi@104.223.94.122] has quit [Ping timeout: 260 seconds]
04:37 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 260 seconds]
04:37 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
04:37 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
04:44 -!- ccdle12 [~ccdle12@188.29.165.77.threembb.co.uk] has quit [Remote host closed the connection]
04:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:45 < bitcoin-git> [bitcoin] laanwj closed pull request #18053: Silence "redundant move in return statement" warning on GCC9 (master...gcc9-silence-redundant-move) https://github.com/bitcoin/bitcoin/pull/18053
04:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:49 -!- wimpunk [~wimpunk@77.243.177.38] has joined #bitcoin-core-dev
04:49 -!- Highway61 [~Thunderbi@104.223.94.122] has joined #bitcoin-core-dev
05:12 -!- promag [~promag@188.250.106.244] has quit [Remote host closed the connection]
05:13 -!- promag_ [~promag@188.250.106.244] has quit [Remote host closed the connection]
05:13 -!- amiti [sid373138@gateway/web/irccloud.com/x-gyaktgoytveykhne] has quit [Ping timeout: 248 seconds]
05:14 -!- promag_ [~promag@188.250.106.244] has joined #bitcoin-core-dev
05:19 -!- aerth [sid386971@gateway/web/irccloud.com/x-hwirpepkthpnwkwp] has quit [Ping timeout: 245 seconds]
05:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:19 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to 0.19: https://github.com/bitcoin/bitcoin/compare/755b0734bb50...7d53995ff2b4
05:19 < bitcoin-git> bitcoin/0.19 b4e5363 Joao Barbosa: gui: Fix unintialized WalletView::progressDialog
05:19 < bitcoin-git> bitcoin/0.19 7d53995 fanquake: Merge #18084: 0.19: gui: Fix unintialized WalletView::progressDialog
05:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:19 -!- promag_ [~promag@188.250.106.244] has quit [Ping timeout: 272 seconds]
05:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:19 < bitcoin-git> [bitcoin] fanquake merged pull request #18084: 0.19: gui: Fix unintialized WalletView::progressDialog (0.19...2020-02-backport-18062) https://github.com/bitcoin/bitcoin/pull/18084
05:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:19 -!- vfP56jSe [sid321684@gateway/web/irccloud.com/x-atiayuhwwtsjtmps] has quit [Ping timeout: 260 seconds]
05:19 -!- arik__ [sid402902@gateway/web/irccloud.com/x-eatkecsferiycvdj] has quit [Ping timeout: 248 seconds]
05:20 -!- Isthmus [uid302307@gateway/web/irccloud.com/x-icoxkloiwutndeot] has quit [Ping timeout: 260 seconds]
05:24 -!- petezz4 [sid2429@gateway/web/irccloud.com/x-nctsxpdbegykknls] has quit [Ping timeout: 245 seconds]
06:01 -!- aerth [sid386971@gateway/web/irccloud.com/x-zezcojapockekron] has joined #bitcoin-core-dev
06:01 -!- amiti [sid373138@gateway/web/irccloud.com/x-lbthmiefwmwhywun] has joined #bitcoin-core-dev
06:02 -!- petezz4 [sid2429@gateway/web/irccloud.com/x-futxxrikixpophrb] has joined #bitcoin-core-dev
06:04 -!- ccdle12 [~ccdle12@92.40.248.110.threembb.co.uk] has joined #bitcoin-core-dev
06:05 -!- Isthmus [uid302307@gateway/web/irccloud.com/x-auwwolykhrpgicxq] has joined #bitcoin-core-dev
06:06 < MarcoFalke> #proposedmeetingtopic (short topic) Remove i686 Linux download link from bitcoincore website
06:07 -!- arik__ [sid402902@gateway/web/irccloud.com/x-evhbfsozdxtfdipd] has joined #bitcoin-core-dev
06:08 -!- ar1el [~ariel@unaffiliated/ar1el] has joined #bitcoin-core-dev
06:08 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]
06:09 -!- vfP56jSe [sid321684@gateway/web/irccloud.com/x-frpbskzesqjzbpql] has joined #bitcoin-core-dev
06:09 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
06:10 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
06:15 -!- jonatack [~jon@109.232.227.133] has joined #bitcoin-core-dev
06:25 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev
06:27 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
06:29 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
06:31 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
06:36 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 260 seconds]
06:38 -!- ccdle12 [~ccdle12@92.40.248.110.threembb.co.uk] has quit [Remote host closed the connection]
06:40 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
06:41 < promag> wumpus: sure, too soon then, lets see next year
06:45 -!- ccdle12 [~ccdle12@92.40.174.242.threembb.co.uk] has joined #bitcoin-core-dev
06:51 -!- ccdle12 [~ccdle12@92.40.174.242.threembb.co.uk] has quit [Ping timeout: 260 seconds]
06:58 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 260 seconds]
07:00 -!- wimpunk [~wimpunk@77.243.177.38] has quit []
07:00 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
07:01 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
07:02 -!- nijynot [~nijynot@h-177-96.A785.priv.bahnhof.se] has joined #bitcoin-core-dev
07:05 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
07:06 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:13 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 245 seconds]
07:19 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
07:23 -!- nijynot [~nijynot@h-177-96.A785.priv.bahnhof.se] has quit [Ping timeout: 268 seconds]
07:26 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
07:48 -!- llamma1 [~llamma@141.98.101.133] has joined #bitcoin-core-dev
07:50 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 268 seconds]
08:05 -!- goatpig [~goat@blocksettle-gw.cust.31173.se] has quit [Quit: Konversation terminated!]
08:08 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
08:10 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
08:11 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
08:13 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev
08:16 -!- rafalcpp [~racalcppp@ip-178-211.ists.pl] has joined #bitcoin-core-dev
08:22 -!- jonatack [~jon@109.232.227.133] has quit [Ping timeout: 260 seconds]
08:28 -!- emzy [~quassel@raspberry.emzy.de] has quit [Changing host]
08:28 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-core-dev
08:37 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has quit [Remote host closed the connection]
08:57 -!- rafalcpp [~racalcppp@ip-178-211.ists.pl] has quit [Ping timeout: 265 seconds]
09:03 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 268 seconds]
09:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev
09:05 -!- Highway61 [~Thunderbi@104.223.94.122] has quit [Ping timeout: 260 seconds]
09:07 -!- SiAnDoG__ [~514nDoG@gateway/tor-sasl/siandog] has joined #bitcoin-core-dev
09:13 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
09:21 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
09:22 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
09:22 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-dev
09:23 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 245 seconds]
09:26 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 268 seconds]
09:32 -!- Highway61 [~Thunderbi@104.223.94.58] has joined #bitcoin-core-dev
09:33 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has quit [Ping timeout: 265 seconds]
09:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
09:34 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has joined #bitcoin-core-dev
09:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
09:39 -!- nitrow [6326f860@99-38-248-96.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
09:44 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
09:48 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
09:49 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 268 seconds]
09:52 < jonatack> Would someone kindly restart Travis for #17812
09:52 < gribble> https://github.com/bitcoin/bitcoin/issues/17812 | config, net, test: asmap functional tests and feature refinements by jonatack . Pull Request #17812 . bitcoin/bitcoin . GitHub
09:52 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
09:54 -!- nitrow [6326f860@99-38-248-96.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection]
09:59 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
10:00 -!- llamma1 [~llamma@141.98.101.133] has quit []
10:01 < luke-jr> jonatack: done
10:06 < jonatack> luke-jr: thank you
10:07 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev
10:09 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
10:12 -!- ar1el [~ariel@unaffiliated/ar1el] has quit [Remote host closed the connection]
10:14 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has quit [Quit: Ping timeout (120 seconds)]
10:14 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev
10:18 -!- mota1 [~mota@195.206.169.238] has joined #bitcoin-core-dev
10:26 -!- goatpig [~goat@h-2-155.A498.priv.bahnhof.se] has joined #bitcoin-core-dev
10:38 -!- zivl [~zivl@unaffiliated/zivl] has joined #bitcoin-core-dev
10:51 -!- Highway61 [~Thunderbi@104.223.94.58] has quit [Ping timeout: 272 seconds]
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Feb  6 19:00:00 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00 < MarcoFalke> ahoy
11:00 < wumpus> I don't expect many people to be here today with the London conference, but we can try...
11:00  * BlueMatt 
11:00 < sipsorcery> hi
11:00 < sipa> hi
11:00 < jonasschnelli> hi
11:00 < emilengler> hi
11:00 < amiti> hi
11:01 < hebasto> hi
11:01  * BlueMatt 
11:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
11:01 < wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
11:01 < fjahr> hi
11:01 < wumpus> one proposed topic on https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a: Remove i686 Linux download link from bitcoincore website (MarcoFalke)
11:01 < aj> hi
11:01 < wumpus> any last minute topic proposals?
11:02 < jeremyrubin> hi
11:02 < jeremyrubin> proposed topic: mempool project update
11:02 < jonatack> hi
11:02 < wumpus> jeremyrubin: ack
11:02 < moneyball> hi
11:02 < kanzure> hi
11:02 < jkczyz> hi
11:02 < kanzure> proposed topic: more topic selection (or actually, how about topics you don't want to hear about for march)
11:02 < promag> hi
11:03 < emilengler> proposed topic: the library for #17950, even if to use a library?
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/17950 | gui: Check the strength of an encryption password by emilengler . Pull Request #17950 . bitcoin/bitcoin . GitHub
11:03 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:03 < wumpus> #topic High priority for review
11:03 < wumpus> https://github.com/bitcoin/bitcoin/projects/8 -> 6 blockers, 1 bugfix, 6 chasing concept ACK
11:04 < wumpus> anything to add / remove or almost ready for merge?
11:04 < meshcollider> hi
11:04 < wumpus> hi
11:05 < MarcoFalke> The cs_main cs_wallet thing needs rebase and has something proposed by ryanofsky as a preparation pull request. Should these be  exchanged?
11:05  * luke-jr glances at some chirping crickets
11:05 < wumpus> MarcoFalke: I suppose that makes sense, if the other one is a blocker for this one
11:05 < wumpus> either that or add it too
11:06 < MarcoFalke> #17954 is the prep I think
11:06 < gribble> https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky . Pull Request #17954 . bitcoin/bitcoin . GitHub
11:06 < jonasschnelli> half of the PR in high-prio do fail CI 
11:06 < MarcoFalke> jonasschnelli: travis s390x?
11:07 < wumpus> ok, added
11:07 < luke-jr> maybe we should disable the s390x temporarily?
11:07 < ryanofsky> MarcoFalke, yes my preference would be to do 17954 first
11:07 < jonasschnelli> MarcoFalke: I don't know but makes people ignore CI (which is a QA issue in the long run
11:07 < MarcoFalke> Yes, maybe we should disable it on travis for now
11:07 < MarcoFalke> I do run it locally
11:08 < hebasto> How valuable is s390x tests?
11:08  * jonasschnelli think the CI should be less fragile
11:08 < wumpus> hebasto: big-endian testing
11:08 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
11:08 < MarcoFalke> jonasschnelli: travis is the only one that offers s390x native
11:08 < wumpus> that's basically the only reason s390x testinig is valuable
11:08 < luke-jr> too bad Travis doesn't have ppc64be
11:08 < jonasschnelli> I think its very valuable
11:08 < wumpus> no one runs bitcoind on that platfor mas far as I'm aware
11:09 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
11:09 < wumpus> so any other big-endian platform would do as well
11:09 < sipa> yeah, even if we expect literally noone ever to use bitcoin core in production on s390x, variety in test platforms can often expose bugs present but undetectable on other platforms
11:09 < MarcoFalke> I do run it, but it is through qemu 
11:10 < MarcoFalke> sipa: It did find a bug in the tests :)
11:10 < sipa> MarcoFalke: the best kind of bug
11:10 < MarcoFalke> +1
11:10 < wumpus> especially for serialization changes it's very useful to test big endian correctness
11:10 < jonasschnelli> Maybe its not ready for a per branch update/PR base but as a manual check?
11:10 < jonatack> jonasschnelli: btw thank you for https://bitcoinbuilds.org. it is the first place i look for CI results.
11:11 < jonasschnelli> jonatack: It's running again smoothly.. but no native s390x supper...
11:11 < jonasschnelli> could try to get a qemu be env up. But I guess it will be too slow
11:11 < sipa> may be useful to run s390x qemu on master on a regular basis, but not on every PR?
11:12 < wumpus> power can can be big-endian as well, though, it's fairly rare (and travis doesn't offer that)
11:12 < jonasschnelli> +1
11:12 < MarcoFalke> If someone is knowledged in docker, #18016 is the problem we need fixed
11:12 < gribble> https://github.com/bitcoin/bitcoin/issues/18016 | travis: s390x ci build fails on travis because disk is too small . Issue #18016 . bitcoin/bitcoin . GitHub
11:12 < wumpus> agree sipa 
11:12 < luke-jr> wumpus: not so rare; but can't be a simple chroot :/
11:12 < MarcoFalke> So I think #action is to either fix #18016 or remove it and run locally?
11:12 < gribble> https://github.com/bitcoin/bitcoin/issues/18016 | travis: s390x ci build fails on travis because disk is too small . Issue #18016 . bitcoin/bitcoin . GitHub
11:13 < wumpus> I don't think we can fix "disk too small" so that leaves removing it for now
11:13 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
11:13 < MarcoFalke> It can be fixed with some docker settings and restarting docker, but I don't know anything about this "docker" thing
11:14 < wumpus> me neither, I've always managed to avoid it
11:14 < MarcoFalke> There is a disk large enough in /var/snap/lxd/... on travis
11:14 < MarcoFalke> Anyway, next topic?
11:15 < wumpus> #topic Remove i686 Linux download link from bitcoincore website (MarcoFalke)
11:15 < wumpus> yes, let's do it
11:15 < jonasschnelli> ack
11:15 -!- Highway61 [~Thunderbi@104.223.94.58] has joined #bitcoin-core-dev
11:15 < MarcoFalke> So based on a twitter poll, a mailing list post, we only found one confrimed user of i686 #17504
11:15 < gribble> https://github.com/bitcoin/bitcoin/issues/17504 | Should we still ship 32-bit x86 Linux binaries? . Issue #17504 . bitcoin/bitcoin . GitHub
11:15 < wumpus> https://github.com/bitcoin-core/bitcoincore.org/pull/695
11:15 < MarcoFalke> So as a first step it could make sense to remove the i686 download link from the website
11:16 < emilengler> Shouldn't we wait until we don't produce any i686 anymore
11:16 < MarcoFalke> emilengler: Removing the link first gives everyone another chance to notice it
11:16 < luke-jr> ^
11:16 < emilengler> I think it's a better approach to add a note on the website and remove the link once the new version got released
11:16 < luke-jr> I'd like to be sure this doesn't turn into the Win32 situation
11:16 < MarcoFalke> emilengler: The i686 bin will still be uploaded for now
11:16 < luke-jr> the plan there afaik was simply to stop making binaries, but now we're removing the ability to even compile it
11:17 < MarcoFalke> luke-jr: That is not going to happen 
11:17 < wumpus> we need to support 32 bit for self-compiles, period
11:17 < luke-jr> k
11:17 < MarcoFalke> luke-jr: We have a i686 centos build in ci, that is not going to be removed
11:17 < wumpus> ARM 32 bit is not dead, and neither is RISC-V 32 bit, and some others
11:18 < jonasschnelli> Indeed. There are a lot of Odroid in the field (Cortex A15).
11:18 < wumpus> I think I've been very clear everywhere that this is about the shipped binaries
11:18 < wumpus> for x86 32 bit
11:18 < luke-jr> wumpus: right, but that was true for Win32 too
11:19 < wumpus> win32 is really dead anyhow
11:20 < emilengler> The topic was to remove it from the website and nothing else. I feel this discussion drives a bit away to a more general topic about x86 in general. Could we come back to the original point?
11:20 < hebasto> even not all libs are available for x86
11:20 < luke-jr> hebasto: ?!
11:20 < harding> Removing it from the website to see if anyone complains while it's still easy to add it back makes sense to me.
11:20 < hebasto> see Centos 32-bit repo
11:21 < luke-jr> hebasto: that's too vague to mean anything to me
11:21 < wumpus> yes, so let's remove it from the website, but still build x86_32 binaries for 0.19.1
11:22 < MarcoFalke> +1
11:22 < luke-jr> sgtm
11:22 < wumpus> then for 0.20 stop building them
11:22 < emilengler> ack
11:22 < wumpus> #topic Mempool project update (jeremyrubin)
11:23 < jeremyrubin> hola
11:23 < jeremyrubin> So the first PR of the epoch mempool series has been merged
11:23 < wumpus> congrats!
11:23 < jeremyrubin> Thanks!
11:23 < jeremyrubin> I've opened up the next step, which gets rid of this big cache we built during reorgs
11:23 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/18063
11:24 < jeremyrubin> Amiti's testing framework changes are making progress & seem good to go IMO
11:24 < wumpus> good to know
11:25 < jeremyrubin> It seems like there's been not too much attention on nanobench stuff, would be good to "just do it IMO" but I don't have many downstream toolchains
11:25 < wumpus> which PR is that?
11:25 < jeremyrubin> sorry scrambling for links...
11:25 < wumpus> (Amiti's changes, I mean)
11:25 < jeremyrubin> #18037
11:26 < gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar . Pull Request #18037 . bitcoin/bitcoin . GitHub
11:26 < jeremyrubin> and #18011
11:26 < gribble> https://github.com/bitcoin/bitcoin/issues/18011 | Replace current benchmarking framework with nanobench by martinus . Pull Request #18011 . bitcoin/bitcoin . GitHub
11:26 < jeremyrubin> Amiti has also opened up a new PR that carves out a good chunk of functionality for rebroadcasting
11:26 < jeremyrubin> is amiti here? I can ping her
11:26 < amiti> ya Im here 
11:26 < jeremyrubin> #18037
11:27 < gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar . Pull Request #18037 . bitcoin/bitcoin . GitHub
11:27 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit []
11:27 < wumpus> ok so add #18037 to high priority for review?
11:27 < jeremyrubin> amiti: should people be taking a look at 18037 now?
11:27 < amiti> #18038 is the rebroadcast subset
11:27 < gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar . Pull Request #18037 . bitcoin/bitcoin . GitHub
11:27 < gribble> https://github.com/bitcoin/bitcoin/issues/18038 | P2P: Mempool tracks locally submitted transactions to improve privacy by amitiuttarwar . Pull Request #18038 . bitcoin/bitcoin . GitHub
11:27 < jeremyrubin> Ah right sorry
11:28 < amiti> if 18038 builds on 18037, so if 18037 gets merged in current state then 18038 is ready for review
11:28 < jeremyrubin> yes so I think 18037 is hi prio and can be merged with another ack or two (it's just testing stuff)
11:28 < jeremyrubin> And then we can pull some ears (not yet hi-prio) for 18038
11:29 < jonatack> jeremyrubin: perhaps add #18044 to your mempool dashboard? https://github.com/bitcoin/bitcoin/projects/14
11:29 < gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar . Pull Request #18044 . bitcoin/bitcoin . GitHub
11:29 < wumpus> ok
11:29 < jeremyrubin> Same goes for #18063 -- once I get a reviewer or two I'd like to put it high priority so that progress can keep moving
11:29 < gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin . Pull Request #18063 . bitcoin/bitcoin . GitHub
11:30 < jeremyrubin> is 18044 needed for package relay?
11:30 < jonatack> no, part of it changes the mempool, up to you
11:30 < jeremyrubin> is sdaftuar here and can talk more about it?
11:31 < jeremyrubin> I'll add it but from what I can tell this one requires a BIP to move forward? 
11:31 < jonatack> yes, there is a wip bip draft for now
11:31 < sipa> i believe sdaftuar is working on one
11:32 < jeremyrubin> Ok great. I'll add it to the package relay track since that's mostly sdaftuar right now anyways, but I think logically it seems more on rebroadcasting
11:32 < jeremyrubin> amiti do you have any thoughts on that? Can you review 18044?
11:32 < jonatack> WIP BIP draft https://github.com/sdaftuar/bips/blob/2020-02-wtxid-relay/bip-wtxid-relay.mediawiki
11:33 < amiti> yeah I've started taking a look, its more about initial broadcast than rebroadcast 
11:33 < jeremyrubin> (and then I think we're good on mempool project unless anyone has any questions -- please see https://github.com/bitcoin/bitcoin/projects/14 to get references for what to review & look at)
11:34 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
11:34 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
11:34 < luke-jr> ...
11:35 < jeremyrubin> ?
11:35 < wumpus> #topic the library for #17950 (emilengler)
11:35 < gribble> https://github.com/bitcoin/bitcoin/issues/17950 | gui: Check the strength of an encryption password by emilengler . Pull Request #17950 . bitcoin/bitcoin . GitHub
11:35 < wumpus> I *really* do not like introducing a dependency for this
11:35 < emilengler> thanks
11:35 < emilengler> I agree with wumpus 
11:36 < jonasschnelli> Yes. Please no dependency for a gimmick feature
11:36 < wumpus> it's somewhat nice to display a measure of password strength (if people can ever agree on one), but it's not worth large changes to our build process for
11:36 < sipa> i feel that anything that self-written is going to be too ad-hoc to be useful
11:36 < wumpus> exactly
11:36 < jonasschnelli> It is already handholding...
11:36 < sipa> so either it's depending on a well-maintained library, or we don't do it at all
11:36 < jeremyrubin> I think i'd rather just *suggest* a strong password
11:36 < luke-jr> there's conceptual problems in the first place
11:36 < wumpus> maybe it's a bad idea in the first place, thinking of it, we don't want to encourage a specific kind of password scheme, this only reduces security
11:36 < luke-jr> this shouldn't be a "strong" password, it should be a memorable one
11:36 < jeremyrubin> e.g., here are 12 random words
11:37 < wumpus> that, too
11:37 < luke-jr> encrypted wallets won't stop malware, just little brother
11:37 < luke-jr> the risk of losing access outweighs the benefits of a string passphrase here
11:37 < jonasschnelli> Can we just have a short text to help people do the right thing? Or a link (less likely)?
11:37 < wumpus> it's not a brainwallet, not the entire internet can attack it, the security needed depends on how secure the wallet file is kept
11:37 < gwillen> it is very hard to make a password-strength indicator that is not at least sometimes very misleading
11:37 < wumpus> making it too strong might cause people to forgt it
11:38 < MarcoFalke> I think more people have lost coins due to forgetting too strong passwords than first getting their wallet stolen, but not their password, and then got their password cracked offline
11:38 < wumpus> which is much worse
11:38 < jonasschnelli> Indeed
11:38 < sipa> gwillen: zxcvbn seems pretty sophisticated already
11:38 < sipa> *actually
11:38 < wumpus> MarcoFalke: agree
11:38 < sipa> it's very hard because users probably don't have a good intuition for what the requirements are
11:38 < wumpus> what would be nice is a feature that makes people write down their HD seed
11:38 < wumpus> aid recovery, not make it worse
11:38 < jeremyrubin> (I'm actually recovering a wallet for someone who forgot their password, so I agree)
11:38 < MarcoFalke> yeah
11:39 < wumpus> a lot of people lose their coins either by losing their wallet or paspphrase
11:39 < sipa> if the wallet.dat file leaking is an attack vector you want to protect against, the password needs to be *far* stronger than common recommendations for website login passwords
11:39 < jonasschnelli> wumpus: you mean adding BIP39 support?
11:39 < jeremyrubin> * attempting that is, let's hope the fragments are good enough
11:39 < gwillen> sipa: as such things go, it's pretty sophisticated, but it does not know your dog's name, or your mother's maiden name, or your birthday, or your favorite book you're quoting from, or any of a number of stupid things users do that lower effective entropy
11:39 < gwillen> while not lowering apparent entropy relative to the tool's model
11:39 < luke-jr> sipa: but if the wallet.dat file leaks, you probably have a keylogger on your PC anyway, so..
11:39 < wumpus> jonasschnelli: yes I suppose
11:39 < sipa> gwillen: of course it can only give an upper bound
11:40 < gwillen> it's never presented that way, though
11:40 < sipa> anyway
11:40 < sipa> i'm in favor of just not pursuing that feature
11:40 < jeremyrubin> luke-jr: disagree with those priors
11:40 < sipa> it's too hard to do right
11:40 < luke-jr> jeremyrubin: ?
11:40 < jeremyrubin> [11:39] <luke-jr> sipa: but if the wallet.dat file leaks, you probably have a keylogger on your PC anyway, so..
11:40 < MarcoFalke> Yeah, we should recommend users use a shorter password, if anything
11:40 < sipa> luke-jr: wallet.dat files get backed up
11:40 < wumpus> luke-jr: they might copy it to a cloud service or something
11:41 < sipa> MarcoFalke: i disagree with that as well
11:41 < luke-jr> sipa: hopefully encrypted!
11:41 < jeremyrubin> I think it's relatively likely you leak your file but don't get a keylogger
11:41 < sipa> luke-jr: right, but in that case, the passphrase needs to be strong
11:41 < luke-jr> sipa: no, I mean encrpying the file itself
11:41 < jeremyrubin> e.g., keeping backups on thumb drives
11:41 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
11:42 < sipa> luke-jr: it's hard to assume that people will use a strong password for an encrypted backup, but then not one inside the file?
11:42 < luke-jr> perhaps we should put a suggestion to that effect somewhere
11:42 < wumpus> in any case, there's no disagreement about whether the wallet encryption is useful or not, that's not the topic
11:42 < sipa> i disagree that in general we should advise weak passwords
11:42 < wumpus> no, we shouldn't advise that
11:42 < MarcoFalke> ok, we shouldn't advise on weak passwords, but we might want to explain the tradeoffs
11:42 < sipa> MarcoFalke: yes
11:42 < wumpus> that would make sense, yes
11:43 < wumpus> add an explanation
11:43 < MarcoFalke> I.e. what the password protects against and what it does not protect against
11:43 < sipa> "Losing this password will make your funds irrecoverably lost"
11:43 < jeremyrubin> I think also saying "writing down the password in a notebook is probably better than not having one"
11:43 < jonatack> https://www.xkcd.com/936/
11:43 < jeremyrubin> Or something to that effect
11:43 < jonasschnelli> I'm all for informing (text based) rather then applying rules that only works for certain use cases
11:43 < luke-jr> jeremyrubin: it really depends on your risk exposure
11:43 < jeremyrubin> I think people don't know that the password is not a seed 
11:44 < jeremyrubin> if you just write down the password but they don't have the wallet.dat it's fine
11:44 < wumpus> jeremyrubin: yep, some people are confused by that
11:44 < jeremyrubin> luke-jr: if someone remote compromises your computer but you have a sticky note with a long password on your screen you're "fine"
11:45 < wumpus> because most wallets work with seeds nowadays
11:45 < jeremyrubin> (until you type it in, but let's assume read only compromise)
11:45 < jonasschnelli> The wallet encryption should be better explained. I would not wonder if some users encrypt their watch only wallets in the hope to not leak metadata to computer wide text pattern searches, etc.
11:45 < wumpus> agree with jonasschnelli on adding explanation text
11:45 < luke-jr> you can't encrypt watch-only I thought?
11:45 < emilengler> I think it may be a good way to add a way to encrypt the wallet in the intro dialog
11:45 < jonasschnelli> Can't you?
11:45 < hebasto> explanation is good
11:46 < wumpus> only private keys are encrypted, so encrypting watch-only would be a no-op
11:46 < luke-jr> jonasschnelli: what would it even do?
11:46 < sipa> jonasschnelli: of course not
11:46 < jonasschnelli> luke-jr: I guess you can because its mostly a mixed situation
11:46 < sipa> what would there be to encrypt?
11:46 < jonasschnelli> sipa: thats exactly the problem
11:46 < jonasschnelli> people expect things are encrypted
11:46 < wumpus> the metadata is never encrypted
11:46 < jonasschnelli> while we only encrypt the keys
11:46 < jonasschnelli> Yes. But we don't tell that to users
11:47 < sipa> jonasschnelli: a no-key wallet can't be encrypted, i think?
11:47 < luke-jr> it's obvious?
11:47 < jonasschnelli> So,.. IRS grabs wallet.dat file and reads transaction comments
11:47 < wumpus> this is why software needs documentation I guess
11:47 < sipa> luke-jr: don't assume things are obvious
11:47 < jeremyrubin> luke-jr: how is it obvious?
11:47 < jeremyrubin> That they can open the wallet and see stuff and only pw to sign?
11:47 < jonasschnelli> It's not obvious to most users
11:47 < luke-jr> you open Bitcoin Core and see your metadata, without entry of passphrase
11:47 < wumpus> jonasschnelli: well it doesn't ask th password at startup, only when you send
11:47 < jonasschnelli> encryption means for most users data can't be read by someone no knowing the secret
11:47 < jeremyrubin> Actually that sounds like a 2 birds one stone thing
11:48 < jonasschnelli> wumpus: sure. But novice users don't understand that either
11:48 < jeremyrubin> If people have to put their password in more often maybe they're less likely to forget it ;)
11:48 < luke-jr> jeremyrubin: hmm!
11:49 < jonasschnelli> I think adding more explanations on how the encryption work would be great in general
11:49 < jonasschnelli> works
11:49 < MarcoFalke> Opened an issue #18085
11:49 < gribble> https://github.com/bitcoin/bitcoin/issues/18085 | doc: Explain what the wallet password does . Issue #18085 . bitcoin/bitcoin . GitHub
11:49 < jonasschnelli> Nice
11:49 < wumpus> thanks
11:49 < jeremyrubin> I think there's also a lot of room for improvements in what users have available, e.g. shamir's secret shares
11:49 < jonasschnelli> We don't encrypt the wallet, we encrypt the keys
11:50 < jonatack> I sense new options/config args in our future here
11:50 < jeremyrubin> Even though we know multisig is better, user's are really struggling to do anything better than a plaintext wallet
11:51 < luke-jr> not sure it makes sense to put any effort into pre-Taproot multisig at this point?
11:51 < sipa> jeremyrubin: that's not really an option in a model where a wallet is a file and not a seed
11:51 < wumpus> we should be careful only to add features that are actually used and useful though, don't want to end up with some GPG-like tool that does a zillion things but with a lot of pitfalls
11:51 < jeremyrubin> Maybe organizing some discussion at coredev.tech would be good about conducting some user research to improve things.
11:51 < kanzure> i'll add that to the list then.
11:51 < kanzure> empirical user testing would be interesting
11:51 < sipa> luke-jr: multisig support at this point means improving PSBT integration, i think
11:52 < jeremyrubin> Can ask some of the ideo people to come by since they've been doing key managment UXs with a lot of projects
11:52 < sipa> luke-jr: which we should definitely work on
11:52 < luke-jr> good point
11:52 < kanzure> i'd prefer to forego ideo
11:52 < jeremyrubin> sipa: you can still do point-in-time non seed backups
11:52 < jeremyrubin> kanzure: Any specific reason?
11:53 < jonasschnelli> let's not sidetrack this topic. :)
11:53 < sipa> yes please
11:53 < wumpus> maybe more apprpriate for the wallet meeting, too
11:53 < sipa> yeah
11:54 < wumpus> not that we have any more topics for today
11:54 < sdaftuar> hi - i'm back, if anyone has questions about wtxid-relay i can discus
11:55 < jeremyrubin> yay! please do
11:55 < MarcoFalke> sdaftuar: There was a question whether it was needed for package relay
11:55 < sdaftuar> i think it's a nice-to-have, but non-essential
11:56 < sdaftuar> nice-to-have only because any tx-relay protocol change we make in the future (like erlay, or dandelion, etc) should be done on wtxid-based relay
11:56 < jeremyrubin> I guess more concretely where it fits into the https://github.com/bitcoin/bitcoin/projects/14 workflow and where you think it belongs timeline wise
11:56 < sdaftuar> well, i'm probably personally gated on it, as i don't want to work on more p2p relay things based on txid-relay at this point
11:57 < jeremyrubin> Like if new rebroadcasting stuff like what amiti is working on should be done on wtxids then do we try to slot this before it
11:57 < sdaftuar> barring some reason that wtxid-relay is a problem
11:57 < jeremyrubin> ah ok; so it slots before further package relay work for you
11:57 < luke-jr> I never really understood why we didn't do wtxid-relay from the start
11:57 < sdaftuar> luke-jr: we shoudl have! the second best time is now
11:57 < jeremyrubin> we didn't have wtxids before segwit
11:57 < luke-jr> (or if I did, I forgot)
11:58 < sdaftuar> it was just more work, and we were busy
11:58 < sdaftuar> but i think it's pretty straightforward, and we should do it, ideally before we make a standardness change to segwit transactions
11:58 < jonatack> ack
11:58 < sipa> i think initially it wasn't that clear that it was needed in the first place
11:58 < sipa> and when segwit was further along, it got pushed back to "later"
11:58 < sipa> seems later is now
11:58 < wumpus> 1 minute left
11:59 < sdaftuar> yeah i'm not sure how much anyone thought about it until petertodd pointed out the issues in #8279
11:59 < gribble> https://github.com/bitcoin/bitcoin/issues/8279 | Mempool DoS risk in segwit due to malleated transactions . Issue #8279 . bitcoin/bitcoin . GitHub
11:59 < jeremyrubin> My only concern looking at the code is that a new index in maptx kinda sucks
11:59 < sdaftuar> a bit more memory, but i don't see a way around it, and i think the tradeoff is well worth the benefit
12:00 < sipa> DING DONG
12:00 < wumpus> #endmeeting
12:00 < luke-jr> could we add both entries to the same index?
12:00 < lightningbot> Meeting ended Thu Feb  6 20:00:06 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-06-19.00.html
12:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-06-19.00.txt
12:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-06-19.00.log.html
12:00 < hebasto> luke-jr: missed 32-bit packages in CentOS 7 repos - https://github.com/bitcoin/bitcoin/pull/17900#issuecomment-572697411
12:00 < luke-jr> maybe no benefit
12:00 < sdaftuar> luke-jr: we need to look up by both txid and wtxid
12:00 < sdaftuar> so two keys
12:00 < gwillen> so while people are here, and speaking of PSBT which got mentioned earlier -- I would love to see more reviews of 18027
12:00 < sdaftuar> we use the boost multiindex already, which i think is pretty efficient?
12:00 < gwillen> er, #18027
12:00 < gribble> https://github.com/bitcoin/bitcoin/issues/18027 | "PSBT Operations" dialog by gwillen . Pull Request #18027 . bitcoin/bitcoin . GitHub
12:00 < jonatack> (fwiw... did we finish the blockers/hi-prio part?)
12:01 < jeremyrubin> sdaftuar: you can actually reuse the saltedtxid hasher across both indexes I think
12:01 < sipa> sdaftuar: i need to revive my use-allocator-to-count-multiindex-memory-use stuff... i'm not sure how accurate we currently are
12:01 < luke-jr> hebasto: I would assume anyone building for 32-bit is using 32-bit to do it
12:01 < luke-jr> hebasto: and not everyone uses CentOS
12:02 < sdaftuar> sipa: ah yes i have no idea how to do that, if you can advise on how to update the memory calculation better than i did in the PR, please let me know
12:02 < jonatack> ^ +1
12:02 < sdaftuar> jeremyrubin: i don't think i follow
12:02 < sipa> sdaftuar: i have some WIP code that i can probably use to verify whether or current heuristic is accurate... actually replacing it is probably harder
12:03 < aj> is #14895 really still chasing concept ack?
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14895 | Package relay design questions . Issue #14895 . bitcoin/bitcoin . GitHub
12:03 < jeremyrubin> sdaftuar: I need to think about it a little bit. Fundamentally you want to be able to index by either TXID or WTXID
12:04 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
12:04 < jeremyrubin> But because it's a hash table there's a lot of extra overhead (idk what load the boost table works well till)
12:05 < jeremyrubin> Just trying to think if there's a way to be able to index by either
12:06 < jeremyrubin> Do you envision that we ever remove the txid index?
12:07 < sdaftuar> we can't do that very easily
12:07 < jeremyrubin> Or you think it's there forever for compat
12:07 < sdaftuar> because transactions reference inputs by txid
12:07 < jeremyrubin> right
12:07 < sipa> jeremyrubin: UTXOs are indexed by txid
12:07 < luke-jr> hmm
12:07 < sdaftuar> so unless someone gave you a hint for what wtxid to look for, you're screwed
12:07 < luke-jr> sdaftuar: well, only for mempool-spending txs?
12:08 < jeremyrubin> OK I'm OK with it
12:08 < jeremyrubin> BUT
12:08 < sdaftuar> i think in the case of package relay though, i might imagine that we'll get those hints, but not in a generic enough way that we could ever git rid of the index
12:08 < sdaftuar> luke-jr: right
12:08 < jeremyrubin> You have to review my next two PRs first
12:08 < jeremyrubin> Because I get rid of mapTxLinks
12:08 < luke-jr> could hypothetically use wtxids in the tx structure there, and continue to use just the txids for signatures?
12:08 < jeremyrubin> which can pay for this new index ;)
12:08 < sdaftuar> luke-jr: that would be a big relay change though
12:08 < luke-jr> maybe worth it long-term
12:08 < sdaftuar> and it just seems like a lot of edge cases would break
12:08 < sdaftuar> yeah, i can't rule it out
12:09 < sipa> i don't understand what the point is
12:09 < luke-jr> gotta run
12:09 < sipa> not having wtxids in transactions is exactly what segwit made possible
12:09 < sdaftuar> yes :)
12:09 < sdaftuar> i think saving a little memory is not worth the effort here
12:10 < kanzure> i think the point was something about rebroadcast logic or first-seen issues?
12:10 < kanzure> right, bad witnesses or something?
12:10 < jeremyrubin> Yeah, I think given that we're going to kill mapTxLinks it's going to be fine (I just don't want people to have a reason not to upgrade to wtxid index)
12:10 < jeremyrubin> kanzure: anyone can malleate witnesses
12:10 < sdaftuar> jeremyrubin: i don't think this has anything to do with mapTxLinks though?  i didn't need to touch it for the wtxid-relay PR
12:11 < jeremyrubin> sdaftuar: I'm saying that one of the PRs I pinged you on kills mapTxLinks
12:11 < sdaftuar> (unless i am missing something!)
12:11 < sdaftuar> right, i imagine that should be fine
12:11 < jeremyrubin> so the memory/hashing overhead going away there is probably the same as a new index
12:12 < sdaftuar> one way to think about this is that only the net_processing layer needs to be able to look things up in the mempool by wtxid
12:12 < sdaftuar> as that's the only place in our code where we need to deteremine whether we already have a wtxid someone is offering
12:12 < jeremyrubin> So I'm OK with not introducing a regression
12:12 < sdaftuar> anything internal to the mempool is unaffected by this change
12:12 < jeremyrubin> Because we have a way to pay for it
12:12 < sdaftuar> oh, you're saying that the extra memory is a wash with those other changes?  even better :)
12:12 < jeremyrubin> Yes
12:13 < kanzure> sipa: i assume this https://github.com/bitcoin/bitcoin/pull/18044
12:13 < jeremyrubin> https://github.com/JeremyRubin/bitcoin/pull/7
12:13 < sipa> kanzure: yes that's what we're talking about
12:13 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
12:14 < sipa> jeremyrubin: seems completely unrelated; we need wtxid based relay i think, and even if the only way to do it is by adding memory, we should
12:14 < jeremyrubin> sdaftuar previously said it was nice ot have but not required
12:15 < sipa> and if we can get rid of mapTxLinks, we should, unrelated of wtxid based relay
12:15 < sdaftuar> jeremyrubin: that was for package relay
12:15 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
12:15 < jeremyrubin> ah
12:15 < sdaftuar> i think package relay could be done with or without wtxid relay
12:15 < sdaftuar> but wtxid relay is required to solve some bandwidth-waste issues
12:15 < jeremyrubin> I thought you meant in general
12:15 < jeremyrubin> sipa: I just don't want there to be a reason for economic nodes to not upgrade that's all
12:16 < jeremyrubin> the changes are obviously independent
12:16 < sdaftuar> the issue we have with txid relay is that when a peer announces a segwit transaction that doesn't pass your policy checks, then you don't know whether another peer announcing the same txid has the same transactionr or not
12:16 < sdaftuar> because maybe just the witness was malleated
12:16 < jeremyrubin> But that we're not increasing overheads overall means we can not worry at all
12:16 < sdaftuar> so you have to download it (otherwise, an attacker could malleate transactions to interfere with relay)
12:17 < sdaftuar> and this is wasteful, particularly after a policy change to segwit-transaction-acceptance (eg taproot, or any other policy change)
12:17 < sdaftuar> when you would expect old nodes to reject a certain category of new transaction
12:17 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 260 seconds]
12:18 < sdaftuar> there's also a related CPU DoS issue with how we determine whether a transaction is witness-stripped, which will be alleviated in the future when we no longer need to worry about adding txid's for segwit transactions to our reject filter
12:18 -!- alec [~alec@gateway/tor-sasl/alec] has quit [Remote host closed the connection]
12:18 < sdaftuar> so i think we definitely need wtxid relay, even if we support txid-based-relay indefinitely to support old software
12:20 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]
12:21 < jeremyrubin> I guess it's not clear to me why this has to be a new mempool index rather than a fixed size separate cache only in net_proc
12:21 < jeremyrubin> will look more closely
12:21 < sdaftuar> jeremyrubin: i think code simplicity?
12:21 < sipa> jeremyrubin: for my current mempool, the extra index would be a 0.55% memory usage increase
12:22 < sdaftuar> maintaining a separate data structure just to shave a few bytes doesn't seem worth the effort to me. the mempool is probably already too big
12:22 < jeremyrubin> sipa: I'm concerned with hashing too, we're slowing down all inserts 
12:22 < aj> yeah, extra indexes on multi_index are pretty cheap
12:22 < sdaftuar> inserts aren't in the critical path of block acceptance, i think they're small compared to transaction validation speeds
12:22 < sipa> yeah
12:23 < jeremyrubin> Cool -- these are all good things to document & measure in advocating this change
12:23 < sdaftuar> if you want to worry about CPU usage in transaction acceptance, we should reopen by parallel-script-check-thread PR for mempool acceptance
12:23 < sdaftuar> (i do worry about it, but i think the mempool data structures are far from our biggest concern)
12:23 < sipa> just assume all transactions are valid ethereum style
12:23 < sdaftuar> :)
12:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
12:24 < jeremyrubin> sdaftuar: after I finish the 100th epoch mempool patch I'll do that
12:25 < sdaftuar> sipa: we could just have every node randomly sample transactions to run script checking on, and turn back on sending reject messages, and whenever you learn of a reject from a peer you validate it yourself
12:25 < sdaftuar> <runs away>
12:25 < sipa> haha
12:30 < jeremyrubin> sdaftuar: actually you do a ZKP over your mempool proving it has no invalid txns
12:30 < jeremyrubin> you do a interactive setup with each peer so it's trustless
12:30 < sipa> lol
12:31 < aj> jeremyrubin: and that uses less cpu, right?
12:31 < sipa> aj: you do it in the cloud
12:32 < aj> sipa: i don't trust the cloud, that makes it trustless, right?
12:32 < jeremyrubin> aj: you don't care who generates the proof for your setup string
12:32 < jeremyrubin> so you outsource proving batches of transactions correct to the miners, who get paid for getting them accepted, or the users whose txns it is
12:32 < jeremyrubin> maybe this is better for #wizards ;)
12:33 < sipa> yes
12:35 < aj> sdaftuar: did you see https://github.com/bitcoin/bitcoin/pull/17303#issuecomment-581363980 ? there's a patch there that's a different approach for #15505 ; worth trying? (seems silly to add wtxid for mapRelay if we could just get rid of mapRelay first instead)
12:35 < gribble> https://github.com/bitcoin/bitcoin/issues/15505 | p2p: Request NOTFOUND transactions immediately from other outbound peers, when possible by sdaftuar . Pull Request #15505 . bitcoin/bitcoin . GitHub
12:36 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 265 seconds]
12:37 < sdaftuar> aj: i would definitely prefer to get rid of mapRelay, but i think the additional memory i propose using in #18044 is very minor, it's just an extra key
12:37 < gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar . Pull Request #18044 . bitcoin/bitcoin . GitHub
12:37 < sdaftuar> and it should be easy to remove either before or after the wtxid-relay PR
12:38 < sdaftuar> (if we can get rid of mapRelay before, i can easily pull that commit out of my branch)
12:39 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
12:39 < aj> sdaftuar: oh, yeah, not a meaningful criticism
12:40 < jeremyrubin> sdaftuar: btw can you re-run your reorg benchmark on #18063 for equal comparison to prior work?
12:40 < gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin . Pull Request #18063 . bitcoin/bitcoin . GitHub
12:41 < sdaftuar> jeremyrubin: uh i will try to dig it up again :)  thanks for reminding though, i'll take a look
12:41 < jeremyrubin> if you find it and can run it commit-by-commit that would help (there are only 2)
12:42 < sdaftuar> gotcha, will give it a try
12:51 -!- Netsplit *.net <-> *.split quits: bsm1175321
12:51 -!- bsm117532 [~bsm117532@unaffiliated/bsm117532] has joined #bitcoin-core-dev
12:53 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving]
13:00 -!- mota1 [~mota@195.206.169.238] has quit []
13:08 -!- goatpig [~goat@h-2-155.A498.priv.bahnhof.se] has quit [Quit: Konversation terminated!]
13:18 -!- mkrautz1 [~mkrautz@195.206.183.79] has joined #bitcoin-core-dev
13:19 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:36 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 268 seconds]
13:37 -!- manantial [~tecnecio_@unaffiliated/manantial] has quit [Ping timeout: 272 seconds]
13:43 -!- ccdle12 [~ccdle12@79.173.134.210] has joined #bitcoin-core-dev
14:04 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
14:23 -!- francisco_ [uid418144@gateway/web/irccloud.com/x-fcvwztnwmvnkoorc] has joined #bitcoin-core-dev
14:28 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
14:34 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
14:43 -!- ccdle12 [~ccdle12@79.173.134.210] has quit [Remote host closed the connection]
14:56 -!- Highway61 [~Thunderbi@104.223.94.58] has quit [Ping timeout: 260 seconds]
14:57 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
14:58 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-dev
15:02 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
15:06 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 260 seconds]
15:19 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
15:23 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 268 seconds]
15:24 -!- Highway61 [~Thunderbi@104.223.94.58] has joined #bitcoin-core-dev
15:25 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 268 seconds]
15:29 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 256 seconds]
15:35 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:36 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
15:38 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
15:56 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
16:00 -!- mkrautz1 [~mkrautz@195.206.183.79] has quit []
16:05 -!- ccdle12 [~ccdle12@79.173.134.210] has joined #bitcoin-core-dev
16:08 -!- tryphe_ is now known as tryphe
16:18 -!- kierank1 [~kierank@184.75.223.227] has joined #bitcoin-core-dev
16:22 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
16:23 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
16:26 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
16:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:39 -!- ccdle12 [~ccdle12@79.173.134.210] has quit [Ping timeout: 272 seconds]
16:54 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
17:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:00 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
17:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
18:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:06 < gwillen> where does appveyor/msbuild get dependency/link information from?
18:06 < gwillen> Does it use something other than the Makefiles?
18:06 < gwillen> (if I'm seeing a link error that _only_ happens on appveyor, not Travis, what does that mean?)
18:07 < gwillen> (https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/30501687)
18:11 < sipa> gwillen: i have no idea
18:13 < gwillen> there is a build_msvc/msvc-autogen.py script that appears to scrape them from the Makefiles and make visual studio projects
18:14 < gwillen> it looks like this may be a bug in that script, possibly it was not updated when something got refactored in how the build was done
18:15 < gwillen> curiously, it looks like the generated vcxproj files are BOTH checked-in AND .gitignored, which is not a usual configuration
18:16 < gwillen> so the script failing to regenerate one of them means that the stale one is used
18:20 < fanquake> gwillen There's some discussion in #17287, if you want to "fix" that somehow feel free.
18:20 < gribble> https://github.com/bitcoin/bitcoin/issues/17287 | Git ignore policy in build_msvc directory . Issue #17287 . bitcoin/bitcoin . GitHub
18:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:22 < bitcoin-git> [bitcoin] sipa opened pull request #18086: Accurately account for mempool index memory (master...201910_accounting_allocator) https://github.com/bitcoin/bitcoin/pull/18086
18:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:29 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]
18:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
18:57 < gwillen> fanquake: aha, thanks, I probably don't want to touch it at all :D but it's helpful to have context about it
18:57 < gwillen> it looks like the right thing for me to do is just update the bitcoin-qt windows dependencies in the checked-in msvc project file by hand, it looks like actually the script does not know how to rebuild that one anyway
19:00 -!- kierank1 [~kierank@184.75.223.227] has quit []
19:01 -!- abrissbi1ne [~abrissbir@unaffiliated/abrissbirne] has joined #bitcoin-core-dev
19:05 -!- abrissbirne [~abrissbir@unaffiliated/abrissbirne] has quit [Ping timeout: 256 seconds]
19:18 -!- beng-nl1 [~beng-nl@84.39.116.180] has joined #bitcoin-core-dev
19:46 -!- felixfoertsch [~felixfoer@2001:16b8:50ae:8700:61af:81c4:9c0f:7c8b] has quit [Ping timeout: 272 seconds]
19:46 -!- felixfoertsch [~felixfoer@2001:16b8:500c:9f00:e916:c2b0:b64a:fb14] has joined #bitcoin-core-dev
20:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:05 < bitcoin-git> [bitcoin] sipa opened pull request #18087: Get rid of VARINT default argument (master...202002_novarintvarmacro) https://github.com/bitcoin/bitcoin/pull/18087
20:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
20:06 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
20:06 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 265 seconds]
20:30 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-dev
20:35 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 240 seconds]
20:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
20:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:39 < bitcoin-git> [bitcoin] fanquake opened pull request #18088: build: ensure we aren't using GNU extensions (master...no_gnu_extensions) https://github.com/bitcoin/bitcoin/pull/18088
20:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
20:46 -!- turbo_choo [~turbo_cho@124.128.122.205] has quit [Remote host closed the connection]
21:04 -!- Highway61 [~Thunderbi@104.223.94.58] has quit [Ping timeout: 240 seconds]
21:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
21:11 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
21:12 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev
21:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
21:28 < bitcoin-git> [bitcoin] thorie7912 opened pull request #18089: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/18089
21:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
21:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
21:29 < bitcoin-git> [bitcoin] thorie7912 closed pull request #18089: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/18089
21:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
21:35 -!- turbo_choo [~turbo_cho@124.128.122.205] has joined #bitcoin-core-dev
21:39 -!- ccdle12 [~ccdle12@79.173.134.210] has joined #bitcoin-core-dev
21:41 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
21:44 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
22:00 -!- beng-nl1 [~beng-nl@84.39.116.180] has quit []
22:08 -!- ccdle12 [~ccdle12@79.173.134.210] has quit [Remote host closed the connection]
22:17 -!- Velociraptor1 [~Velocirap@141.98.101.133] has joined #bitcoin-core-dev
22:18 -!- ccdle12 [~ccdle12@79.173.134.210] has joined #bitcoin-core-dev
22:32 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-dev
22:35 -!- midnightmagic is now known as midnight
22:37 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 256 seconds]
22:40 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
22:53 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
22:57 -!- manantial [~tecnecio_@unaffiliated/manantial] has joined #bitcoin-core-dev
22:59 -!- Highway61 [~Thunderbi@104.223.94.58] has joined #bitcoin-core-dev
23:02 -!- ccdle12 [~ccdle12@79.173.134.210] has quit [Remote host closed the connection]
23:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
23:06 -!- goatpig [~goat@blocksettle-gw.cust.31173.se] has joined #bitcoin-core-dev
23:12 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
23:14 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
23:19 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
23:24 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 265 seconds]
23:35 -!- kabaum [~kabaum@2001:9b1:efd:9b00::281] has quit [Quit: Leaving]
23:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
23:47 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 272 seconds]
23:55 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
--- Log closed Fri Feb 07 00:00:32 2020